Contribution on Location for Emergency Calls

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

N= o – I mean the source of the “location=0D=0Ainformation” = – not the source of the call.

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

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

Cheers,

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

= Martin

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

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

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

From:=0D=0ABrian Rosen [mail= to:br@brianrosen.net]
=0D=0ASent: Thursday, 8 March 2007 9:46=0D=0AAM
=0D=0ATo: Dawson, Martin; 'Andrew=0D=0ANewton'
=0D=0A= Cc: geopriv@ietf.org; 'Marc=0D= =0ALinsner'
=0D=0ASubject: RE:=0D=0A[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsig= natures)

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

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

=0D=0A=0D=0A
Umm, source identity=0D=0Achecking won’t work. The id= entity the LIS understands may not be=0D=0Athe identity in the call (becaus= e, for example a NAT or VPN is in the path).=0D=0A The endpoint may ha= ve a valid location or reference to give to the=0D=0Acalling network, but y= ou can’t check that the identity related to the=0D=0Alocation is the = same as that in the call. We could come up with other=0D=0Aidentities= that could be used, but the one we keep talking about (IP Address)=0D=0Awo= n’t work. We would need to do some kind of shared secret=0D=0Ap= rocessing between the triad of the LIS, the endpoint and the calling=0D=0An= etwork. That could prove that the entity getting the location was the=0D= =0Asame entity sending the call.
=0D=0A=0D=0A = ;
=0D=0A=0D=0A
Brian
=0D=0A=0D=0A=
&nb= sp;
=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=0ADawson, Martin [mailto:Martin.Dawson@andrew.com]
=0D=0A<= span style=3D'font-weight:bold'>Sent: Wednesday, March 07, 2007=0D= =0A4:55 PM
=0D=0ATo: Andr= ew Newton; Brian Rosen
=0D=0ACc: geopriv@ietf.org; Marc Linsner
=0D=0ASubject: RE:=0D=0A[Geopriv]WGLCondraft-ietf-geopriv-l7-= lcp-ps-00(PIDF-LOdigitalsignatures)
=0D=0A=0D=0A
=0D=0A=0D=0A

=0D=0A=0D=0A
Gee – I got bagged out for=0D=0A= suggesting that the dereferencing mechanism obviated the concern about temp= oral=0D=0Aand identity integrity for location information quite some time a= go. Must be OK=0D=0Anow.
=0D=0A=0D=0A
=
=0D=0A=0D=0A
Dere= ferencing does remove the concerns=0D=0Awith respect to knowing that the lo= cation really does apply now (temporal) and=0D=0Athat it is applicable to a= specific end-device (identity) – which=0D=0Aaddresses the main repla= y concerns. The other component of location=0D=0Adependability is the ̶= 0;source identity”. That is, that the LIS=0D=0Aoperator is a recognis= ed and trusted access operator. This can be achieved by=0D=0Asome independe= nt certificate exchange process – or it could be achieved=0D=0Ajust b= y having the dereferencer request a signed location anyway; that would be=0D= =0Athe same process for the LIS on the northbound and southbound interfaces= =2E
=0D=0A=0D=0A

=0D=0A=0D=0A
Cheers,
=0D=0A=0D=0A
Martin
=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=0AAndrew Newton [mailto:andy@hxr.us]
=0D=0A= Sent: Thursday, 8 March 2007= 5:39=0D=0AAM
=0D=0ATo: B= rian Rosen
=0D=0ACc: geop= riv@ietf.org; 'Marc=0D=0ALinsner'
=0D=0ASubject: Re: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(= PIDF-LOdigitalsignatures)<= /span>
=0D=0A=0D=0A
=0D=0A=0D=0A
= ;
=0D=0A=0D=0A

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
On Mar 7, 2007, at 1:32 PM, Brian Rosen wrote:=
=0D=0A=0D=0A
=0D=0A=0D=0A

=0D=0A=0D=0AI'd guess we wo= uld be better off=0D=0Ajust using a location reference though.
=0D=0A=0D=0A
=0D=0A=0D=0A

=0D=0A=0D=0A
=0D=0A=0D=0A
That's an interesting thought. The channel security of the=0D= =0Adereference means that you don't have to sign the location to trust it.<= 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
-andy
=0D=0A=0D=0A
=0D=0A=0D=0A

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

=0D=0A ------------------------------------------------------------= ------------------------------------
=0D=0A This message is&n= bsp;for the designated recipient only and may=
=0D=0A contain privileged, proprietary, or otherwi= se private information.
=0D=0A If you h= ave received it in error, please notify = the sender
=0D=0A immediately and delete the o= riginal.  Any unauthorized use of
=0D=0A this&= nbsp;email is prohibited.
=0D=0A ----------------------------= --------------------------------------------------------------------
=0D= =0A [mf2]
=0D=0A =0D=0A =0D=0A=0D=0A=0D=0A

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

-------------------------= -----------------------------------------------------------------------
=0D= =0AThis message is for the designated recipie= nt only and may
=0D=0Acontain privileged, propr= ietary, or otherwise private information.  =0D=0AIf you have received it in error,&nbs= p;please notify the sender
=0D=0Aimmediately and&nbs= p;delete the original.  Any unauthorized use&= nbsp;of
=0D=0Athis email is prohibited.
=0D=0A--------= ---------------------------------------------------------------------------= -------------
=0D=0A[mf2]
=0D=0A=0D=0A=0D= =0A ------_=_NextPart_001_01C7610E.8F876C20-- --===============1187717707== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1187717707==-- From geopriv-bounces@ietf.org Wed Mar 07 18:28:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP5Yg-0007sF-I7; Wed, 07 Mar 2007 18:28:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP52A-0002gu-Gh for geopriv@ietf.org; Wed, 07 Mar 2007 17:54:58 -0500 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP4SQ-0005Mc-Gp for geopriv@ietf.org; Wed, 07 Mar 2007 17:18:05 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 07 Mar 2007 17:16:11 -0500 id 0158841F.45EF39AB.00000DB4 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <79F982FE-7D94-4012-808E-33EE6BC3CFEF@hxr.us> From: Andrew Newton Subject: Re: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Wed, 7 Mar 2007 17:18:00 -0500 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: geopriv@ietf.org, Marc Linsner X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1693528664==" Errors-To: geopriv-bounces@ietf.org --===============1693528664== Content-Type: multipart/alternative; boundary=Apple-Mail-15--422331509 --Apple-Mail-15--422331509 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Mar 7, 2007, at 4:56 PM, Dawson, Martin wrote: > What's the patent encumbrance? Can someone enlighten me? http://www1.ietf.org/mail-archive/web/geopriv/current/msg02505.html -andy --Apple-Mail-15--422331509 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=US-ASCII
On Mar 7, 2007, at 4:56 PM, Dawson, Martin wrote:

What's the patent encumbrance? Can someone enlighten me?

http://www1.ietf.org/mail-archive/web/geopriv/current/msg02505.html

-andy
--Apple-Mail-15--422331509-- --===============1693528664== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1693528664==-- From geopriv-bounces@ietf.org Wed Mar 07 18:35:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP5f1-0002fZ-2y; Wed, 07 Mar 2007 18:35:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP52m-0006Aw-CL for geopriv@ietf.org; Wed, 07 Mar 2007 17:55:36 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP46T-0002UC-Ng for geopriv@ietf.org; Wed, 07 Mar 2007 16:55:23 -0500 X-SEF-Processed: 5_0_0_910__2007_03_07_16_01_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); Wed, 07 Mar 2007 16:01:13 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 15:55:20 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Wed, 7 Mar 2007 15:55:18 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Thread-Index: Acdg5/my996YsFy6RKa06aFOHXzCiQAGk+ow From: "Dawson, Martin" To: "Andrew Newton" , "Brian Rosen" X-OriginalArrivalTime: 07 Mar 2007 21:55:20.0825 (UTC) FILETIME=[4D03F690:01C76103] X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: geopriv@ietf.org, Marc Linsner X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0839673753==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============0839673753== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76103.4C75E471" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76103.4C75E471 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Gee - I got bagged out for suggesting that the dereferencing mechanism=0D=0A= obviated the concern about temporal and identity integrity for location=0D=0A= information quite some time ago. Must be OK now.=0D=0A=0D=0A=20=0D=0A=0D=0A= Dereferencing does remove the concerns with respect to knowing that the=0D=0A= location really does apply now (temporal) and that it is applicable to a=0D= =0Aspecific end-device (identity) - which addresses the main replay=0D=0Aco= ncerns. The other component of location dependability is the "source=0D=0Ai= dentity". That is, that the LIS operator is a recognised and trusted=0D=0Aa= ccess operator. This can be achieved by some independent certificate=0D=0Ae= xchange process - or it could be achieved just by having the=0D=0Adereferen= cer request a signed location anyway; that would be the same=0D=0Aprocess f= or the LIS on the northbound and southbound interfaces.=0D=0A=0D=0A=20=0D=0A=0D= =0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A____________________= ____________=0D=0A=0D=0AFrom: Andrew Newton [mailto:andy@hxr.us]=20=0D=0ASe= nt: Thursday, 8 March 2007 5:39 AM=0D=0ATo: Brian Rosen=0D=0ACc: geopriv@ie= tf.org; 'Marc Linsner'=0D=0ASubject: Re:=0D=0A[Geopriv]WGLCondraft-ietf-geo= priv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D= =0A=0D=0AOn Mar 7, 2007, at 1:32 PM, Brian Rosen wrote:=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0AI'd guess we would be better off just using a location refer= ence though.=0D=0A=0D=0A=20=0D=0A=0D=0AThat's an interesting thought. The = channel security of the dereference=0D=0Ameans that you don't have to sign = the location to trust it.=0D=0A=0D=0A=20=0D=0A=0D=0A-andy=0D=0A=0D=0A------= ---------------------------------------------------------------------------= ---------------=0D=0AThis message is for the designated recipient only and = may=0D=0Acontain privileged, proprietary, or otherwise private information.= =20=0D=0AIf you have received it in error, please notify the sender=0D=0Ai= mmediately and delete the original. Any unauthorized use of=0D=0Athis emai= l is prohibited.=0D=0A-----------------------------------------------------= -------------------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C76103.4C75E471 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=
=0D=0A=0D=0A
Gee – I got bagged out for=0D=0Asuggesting that the der= eferencing mechanism obviated the concern about temporal=0D=0Aand identity = integrity for location information quite some time ago. Must be OK=0D=0Anow= =2E
=0D=0A=0D=0A

=0D=0A=0D=0A
Dereferencing does remov= e the concerns=0D=0Awith respect to knowing that the location really does a= pply now (temporal) and=0D=0Athat it is applicable to a specific end-device= (identity) – which addresses=0D=0Athe main replay concerns. The othe= r component of location dependability is the “source=0D=0Aidentity= 221;. That is, that the LIS operator is a recognised and trusted=0D=0Aacces= s operator. This can be achieved by some independent certificate exchange=0D= =0Aprocess – or it could be achieved just by having the dereferencer = request=0D=0Aa signed location anyway; that would be the same process for t= he LIS on the=0D=0Anorthbound and southbound interfaces.<= /font>
=0D=0A=0D=0A

=0D=0A=0D=0A
Cheers,
=0D=0A=0D=0A=
Martin
=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= =0AAndrew Newton [mailto:andy@hxr.us]
=0D=0ASent: Thursday, 8 March 2007 5:39=0D=0AAM
=0D=0A<= span style=3D'font-weight:bold'>To: Brian Rosen
=0D=0ACc: geopriv@ietf.org; 'Marc=0D=0ALi= nsner'
=0D=0ASubject: Re:=0D= =0A[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)=
=0D=0A=0D=0A=0D=0A=0D=0A

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

=0D=0A=0D= =0A
=0D=0A=0D=0A
=0D=0A=0D=0A
On Mar 7, 200= 7, at 1:32 PM, Brian Rosen wrote:
=0D=0A=0D=0A<= /div>=0D=0A=0D=0A

=0D=0A
=0D=0A
=0D=0A=0D=0A
<= font size=3D1 face=3DHelvetica>I'd guess we would be better off=0D=0Ajust using a location = reference though.
=0D=0A=0D=0A
=0D=0A=0D=0A=

=0D=0A=0D=0A=0D=0A=0D=0A
= That's an interesting thought. = The channel security of the=0D=0Adereference means that you don't have to = sign the location to trust it.
=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
-andy
=0D=0A=0D=0A
=0D=0A=0D=0A=
=0D=0A=0D=0A

= =0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01C76103.4C75E471-- --===============0839673753== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0839673753==-- From geopriv-bounces@ietf.org Wed Mar 07 18:50:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP5tU-00040S-O0; Wed, 07 Mar 2007 18:50:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP5tS-0003zw-Pv; Wed, 07 Mar 2007 18:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP5tS-0003XX-Ft; Wed, 07 Mar 2007 18:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 70FD832A77; Wed, 7 Mar 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HP5tS-0003qc-AG; Wed, 07 Mar 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Mar 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: geopriv@ietf.org Subject: [Geopriv] I-D ACTION:draft-ietf-geopriv-pdif-lo-profile-06.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Geographic Location/Privacy Working Group of the IETF. Title : GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations Author(s) : H. Tschofenig, et al. Filename : draft-ietf-geopriv-pdif-lo-profile-06.txt Pages : 28 Date : 2007-3-7 The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented so that the number of options that need to be implemented in order to make use of it are reduced. There is growing interest in being able to use location information contained in a PIDF-LO for routing applications. To allow successfully interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in the PIDF-LO. This document makes recommendations on how to constrain, represent and interpret locations in a PIDF-LO. It further recommends a subset of GML that MUST be implemented by applications involved in location based routing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-geopriv-pdif-lo-profile-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-geopriv-pdif-lo-profile-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-7154035.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-geopriv-pdif-lo-profile-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-geopriv-pdif-lo-profile-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-7154035.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --NextPart-- From geopriv-bounces@ietf.org Wed Mar 07 19:03: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 1HP66K-0001so-BW; Wed, 07 Mar 2007 19:03:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP539-0006FR-Km for geopriv@ietf.org; Wed, 07 Mar 2007 17:55:59 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP3yu-0001Sn-Dh for geopriv@ietf.org; Wed, 07 Mar 2007 16:47:32 -0500 X-SEF-Processed: 5_0_0_910__2007_03_07_15_53_24 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, 07 Mar 2007 15:53:24 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 15:47:31 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Wed, 7 Mar 2007 15:47:29 -0600 Message-ID: In-Reply-To: <337B3765-4A4F-4FF5-8EBD-232DED760594@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Thread-Index: AcdgyyYxhDG2Il7GSyeWSMqXyenc7QANWFqQ From: "Dawson, Martin" To: "Andrew Newton" X-OriginalArrivalTime: 07 Mar 2007 21:47:31.0381 (UTC) FILETIME=[35347E50:01C76102] X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: GEOPRIV , Marc Linsner X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1454360156==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============1454360156== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76102.34D0675E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76102.34D0675E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The assertion test is a matter of local policy for the LIS - it=0D=0Aunders= tands the constraints appropriate to the access network it=0D=0Aprovides se= rvice for.=0D=0A=0D=0A=20=0D=0A=0D=0AThe premise was that a device can work= out its own location and it can't=0D=0Aapply a signature for this result. = This was supposed to mean that we=0D=0Ashould just give up on the concept o= f location signatures altogether.=0D=0AThe LIS can apply its policy, where = the requestor would like the=0D=0Alocation underwritten with a signature, i= n deciding whether the=0D=0Aproffered location passes the assertion test. A= more precise version of=0D=0Alocation information, that is still going to = be routed to the same=0D=0Aemergency call destination, be trusted enough to= pass through any policy=0D=0Afilters, be handled by the operators in the s= ame way, but which may be=0D=0Amore helpful than a location with a bigger a= rea of uncertainty can be=0D=0Adeemed to be worthy of a signature.=0D=0A=0D= =0A=20=0D=0A=0D=0AThe choice is to send the location without a signature an= d without=0D=0Avalidation of any kind. This cannot be considered secure eno= ugh while at=0D=0Athe same time suggesting that obtaining an asserted locat= ion opens a big=0D=0Asecurity hole. And I don't buy into any arguments that= the "implied=0D=0Aintegrity" somehow makes things less secure. As long as = the recipients=0D=0Aunderstand the nature of location information this is n= ot an issue - and=0D=0Ait's certainly no more significant an issue than the= fact that the=0D=0Arecipient may think the center of an area of uncertaint= y is somehow more=0D=0Acorrect than every other point in that area of uncer= tainty.=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D= =0A=0D=0A________________________________=0D=0A=0D=0AFrom: Andrew Newton [m= ailto:andy@hxr.us]=20=0D=0ASent: Thursday, 8 March 2007 2:13 AM=0D=0ATo: Da= wson, Martin=0D=0ACc: Marc Linsner; Brian Rosen; GEOPRIV=0D=0ASubject: Re:=0D= =0A[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)=0D= =0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0AOn Feb 28, 2007, at 9:03 PM, Dawson,= Martin wrote:=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0AThe assertion mechanism p= ermits the device to submit its own opinion of=0D=0A=0D=0Athe location as p= art of the request. The LIS can apply the assertion=0D=0A=0D=0Atest and, if= it passes, this location is returned as the actual result.=0D=0A=0D=0AIf i= t fails, then the LIS returns its opinion of the location. This=0D=0A=0D=0A= provides the simple function of permitting the device to test its own=0D=0A=0D= =0Alocation determination against that provided by the network. However, it=0D= =0A=0D=0Abecomes especially useful when used in conjunction with a signed=0D= =0A=0D=0Alocation request. Then the result is a signed location either way = - and=0D=0A=0D=0Ait will be the device determined location or the LIS deter= mined location=0D=0A=0D=0Adepending on the result of the assertion test.=0D= =0A=0D=0A=20=0D=0A=0D=0AHow does the assertion test work=3F This seems lik= e a big security hole.=0D=0A=0D=0A=20=0D=0A=0D=0A-andy=0D=0A=0D=0A---------= ---------------------------------------------------------------------------= ------------=0D=0AThis message is for the designated recipient only and may=0D= =0Acontain privileged, proprietary, or otherwise private information. =20=0D= =0AIf you have received it in error, please notify the sender=0D=0Aimmediat= ely and delete the original. Any unauthorized use of=0D=0Athis email is pr= ohibited.=0D=0A------------------------------------------------------------= ------------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C76102.34D0675E 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<= div class=3DSection1>=0D=0A=0D=0A
The assertion test is a matter of local=0D=0Apolicy for the LIS = – it understands the constraints appropriate to the=0D=0Aaccess netwo= rk it provides service for.
=0D=0A=0D=0A

=0D=0A=0D=0A
T= he premise was that a device can work out=0D=0Aits own location and it can&= #8217;t apply a signature for this result. This was=0D=0Asupposed to mean t= hat we should just give up on the concept of location=0D=0Asignatures altog= ether. The LIS can apply its policy, where the requestor would=0D=0Alike th= e location underwritten with a signature, in deciding whether the=0D=0Aprof= fered location passes the assertion test. A more precise version of=0D=0Alo= cation information, that is still going to be routed to the same emergency=0D= =0Acall destination, be trusted enough to pass through any policy filters, = be=0D=0Ahandled by the operators in the same way, but which may be more hel= pful than a=0D=0Alocation with a bigger area of uncertainty can be deemed t= o be worthy of a=0D=0Asignature.
=0D=0A=0D=0A
=0D=0A=0D=0A
The choice is to send the location without=0D=0Aa signature and withou= t validation of any kind. This cannot be considered=0D=0Asecure enough whil= e at the same time suggesting that obtaining an asserted=0D=0Alocation open= s a big security hole. And I don’t buy into any arguments=0D=0Athat t= he “implied integrity” somehow makes things less secure. As=0D=0A= long as the recipients understand the nature of location information this i= s=0D=0Anot an issue – and it’s certainly no more significant an= issue than=0D=0Athe fact that the recipient may think the center of an are= a of uncertainty is=0D=0Asomehow more correct than every other point in tha= t area of uncertainty.
=0D=0A=0D=0A

=0D= =0A=0D=0A
Cheers,
=0D=0A=0D=0A
Martin
=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=0AAndrew Newton [mailto:andy@hxr.= us]
=0D=0ASent: Thursday= , 8 March 2007 2:13=0D=0AAM
=0D=0ATo= : Dawson, Martin
=0D=0ACc= : Marc Linsner; Brian Rosen;=0D=0AGEOPRIV
=0D=0ASubject: Re:=0D=0A[Geopriv]WGLCondraft-ie= tf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)
=0D=0A=0D=0A
=0D=0A=0D=0A

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

=0D=0A=0D=0A
=0D=0A=0D=0A=0D=0A=0D=0A
= On Feb 28, 2007, at 9:03 PM, Dawson,=0D=0AM= artin wrote:
=0D=0A=0D=0A
=0D=0A=0D=0A

=0D=0A
=0D=0A
=0D=0A=0D= =0A
The assert= ion mechanism permits=0D=0Athe device to submit its own opinion of
=0D=0A=0D=0A
the location as part of the=0D=0Arequest. The LIS can ap= ply the assertion
=0D=0A=0D=0A
test and, if it passes, this=0D= =0Alocation is returned as the actual result.
=0D= =0A=0D=0A
If it = fails, then the LIS returns=0D=0Aits opinion of the location. This
=0D=0A=0D=0A
provides the simple function of=0D=0Apermitting the devi= ce to test its own
=0D=0A=0D=0A
location determination agains= t=0D=0Athat provided by the network. However, it=0D=0A=0D=0A
becomes especially useful when=0D=0Aused in conjunction with a signed
=0D=0A=0D=0A
location request. Then the result=0D=0Ais a signed l= ocation either way - and
=0D=0A=0D=0A
it will be the device de= termined=0D=0Alocation or the LIS determined location
=0D=0A=0D=0A
depending on the result of the=0D=0Aassertion test.
=0D=0A=0D=0A=0D=0A=0D=0A
&nbs= p;
=0D=0A=0D=0A
=0D=0A=0D=0A
How does the assertion test work=3F This seems like a big securi= ty=0D=0Ahole.
=0D=0A=0D=0A
=0D=0A=0D=0A=0D=0A=0D=0A
=
=0D= =0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A
-andy<= o:p>
=0D=0A=0D=0A
=0D=0A=0D=0A=0D=0A=0D=0A=

-------------------------------------------------------------------= -----------------------------
=0D=0AThis message is for&n= bsp;the designated recipient only and may
=0D=0A= contain privileged, proprietary, or otherwise priv= ate information.
=0D=0AIf you have recei= ved it in error, please notify the sende= r
=0D=0Aimmediately and delete the original. &n= bsp;Any unauthorized use of
=0D=0Athis email is= prohibited.
=0D=0A------------------------------------------------= ------------------------------------------------
=0D=0A[mf2]

----------= ---------------------------------------------------------------------------= -----------
=0D=0AThis message is for the desig= nated recipient only and may
=0D=0Acontain priv= ileged, proprietary, or otherwise private informat= ion.
=0D=0AIf you have received it = in error, please notify the sender
=0D=0Aimmedi= ately and delete the original.  Any unau= thorized use of
=0D=0Athis email is prohibited.=
=0D=0A-----------------------------------------------------------------= -------------------------------
=0D=0A[mf2]
=0D=0A=0D= =0A=0D=0A ------_=_NextPart_001_01C76102.34D0675E-- --===============1454360156== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1454360156==-- From geopriv-bounces@ietf.org Wed Mar 07 19:21: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 1HP6Nd-00011h-7i; Wed, 07 Mar 2007 19:21:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP51Z-000307-FJ for geopriv@ietf.org; Wed, 07 Mar 2007 17:54:21 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP4tM-0001uo-SL for geopriv@ietf.org; Wed, 07 Mar 2007 17:45:54 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HP4t5-0000uX-DS; Wed, 07 Mar 2007 16:45:39 -0600 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Andrew Newton'" Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Wed, 7 Mar 2007 17:45:42 -0500 Message-ID: <05f901c7610a$5a2f1230$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdg5/my996YsFy6RKa06aFOHXzCiQAGk+owAAHFA7A= 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: 231d7929942febf3be8fd5be2903302f Cc: geopriv@ietf.org, 'Marc Linsner' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1342301437==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============1342301437== Content-Type: multipart/alternative; boundary="----=_NextPart_000_05FA_01C760E0.71590A30" This is a multi-part message in MIME format. ------=_NextPart_000_05FA_01C760E0.71590A30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Umm, source identity checking won't work. The identity the LIS understands may not be the identity in the call (because, for example a NAT or VPN is in the path). The endpoint may have a valid location or reference to give to the calling network, but you can't check that the identity related to the location is the same as that in the call. We could come up with other identities that could be used, but the one we keep talking about (IP Address) won't work. We would need to do some kind of shared secret processing between the triad of the LIS, the endpoint and the calling network. That could prove that the entity getting the location was the same entity sending the call. Brian _____ From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] Sent: Wednesday, March 07, 2007 4:55 PM To: Andrew Newton; Brian Rosen Cc: geopriv@ietf.org; Marc Linsner Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Gee - I got bagged out for suggesting that the dereferencing mechanism obviated the concern about temporal and identity integrity for location information quite some time ago. Must be OK now. Dereferencing does remove the concerns with respect to knowing that the location really does apply now (temporal) and that it is applicable to a specific end-device (identity) - which addresses the main replay concerns. The other component of location dependability is the "source identity". That is, that the LIS operator is a recognised and trusted access operator. This can be achieved by some independent certificate exchange process - or it could be achieved just by having the dereferencer request a signed location anyway; that would be the same process for the LIS on the northbound and southbound interfaces. Cheers, Martin _____ From: Andrew Newton [mailto:andy@hxr.us] Sent: Thursday, 8 March 2007 5:39 AM To: Brian Rosen Cc: geopriv@ietf.org; 'Marc Linsner' Subject: Re: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) On Mar 7, 2007, at 1:32 PM, Brian Rosen wrote: I'd guess we would be better off just using a location reference though. That's an interesting thought. The channel security of the dereference means that you don't have to sign the location to trust it. -andy ---------------------------------------------------------------------------- -------------------- 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] ------=_NextPart_000_05FA_01C760E0.71590A30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Umm, source identity checking = won’t work. The identity the LIS understands may not be the identity in the = call (because, for example a NAT or VPN is in the path). The endpoint = may have a valid location or reference to give to the calling network, but you = can’t check that the identity related to the location is the same as that in = the call. We could come up with other identities that could be used, = but the one we keep talking about (IP Address) won’t work. We would = need to do some kind of shared secret processing between the triad of the LIS, = the endpoint and the calling network. That could prove that the entity getting the location was the same entity sending the = call.

Brian

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Wednesday, March = 07, 2007 4:55 PM
To: Andrew Newton; Brian = Rosen
Cc: geopriv@ietf.org; = Marc Linsner
Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)<= /span>

Gee – I = got bagged out for suggesting that the dereferencing mechanism obviated the concern = about temporal and identity integrity for location information quite some time = ago. Must be OK now.

=

Dereferencing = does remove the concerns with respect to knowing that the location really does apply = now (temporal) and that it is applicable to a specific end-device (identity) – which addresses the main replay concerns. The other component of location dependability is the “source identity”. That is, = that the LIS operator is a recognised and trusted access operator. This can be = achieved by some independent certificate exchange process – or it could be achieved just by having the dereferencer request a signed location = anyway; that would be the same process for the LIS on the northbound and southbound interfaces.

=

Cheers,

Martin=

=

From: = Andrew Newton [mailto:andy@hxr.us]
Sent: Thursday, 8 March = 2007 5:39 AM
To: Brian Rosen
Cc: geopriv@ietf.org; = 'Marc Linsner'
Subject: Re: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)<= /span>

On Mar 7, 2007, at 1:32 PM, Brian Rosen = wrote:

I'd guess = we would be better off just using a location reference though.

That's an interesting thought. The = channel security of the dereference means that you don't have to sign the = location to trust it.

-andy

= -------------------------------------------------------------------------= -----------------------
= This message is for the designated recipien= t only and may
= contain privileged, proprietary, or otherwise pr= ivate information.
= If you have received it in error, plea= se notify the sender
= immediately and delete the original.  Any&n= bsp;unauthorized use of
this email is prohibited.
= -------------------------------------------------------------------------= -----------------------
[mf2]

------=_NextPart_000_05FA_01C760E0.71590A30-- --===============1342301437== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1342301437==-- From geopriv-bounces@ietf.org Wed Mar 07 19:45: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 1HP6lS-0001l5-40; Wed, 07 Mar 2007 19:45:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP53V-0006TK-Iy for geopriv@ietf.org; Wed, 07 Mar 2007 17:56:21 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP3n6-0007lQ-AK for geopriv@ietf.org; Wed, 07 Mar 2007 16:35:24 -0500 X-SEF-Processed: 5_0_0_910__2007_03_07_15_41_10 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, 07 Mar 2007 15:41:10 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 15:35:17 -0600 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: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Wed, 7 Mar 2007 15:35:15 -0600 Message-ID: In-Reply-To: <055501c760d6$b43ef080$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Thread-Index: Acdg1PE9SPP/2RA5TkumDJRtiRQTngAASa4QAApdADA= From: "Dawson, Martin" To: "Brian Rosen" , "Andrew Newton" X-OriginalArrivalTime: 07 Mar 2007 21:35:17.0418 (UTC) FILETIME=[7FBAA0A0:01C76100] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: geopriv@ietf.org, mlinsner@cisco.com X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Actually, I don't see how the question of "accredited" VSPs is pertinent=0D= =0Ato this issue to begin with (and I mean apart from the fact that this is=0D= =0Aexactly the sort of constraint I've been told is anathema to the IETF=0D= =0Aand that a US policy is being quoted as a generic basis for=0D=0Adecisio= n-making - must be a goose and gander thing).=0D=0A=0D=0AAccredited VSPs ha= ve some linkage to the subscriber identity - they can=0D=0Aapply whatever a= udit trail they can to who it is that is making the=0D=0Acalls. They can do= nothing about the trustability of the location=0D=0Ainformation. Oh - unle= ss you'd like to go down the 3GPP[2]/IMS route and=0D=0Asay that VoIP calls= can only be made from your home network or from a=0D=0Aroaming partner net= work (forget being able to use arbitrary hot spots,=0D=0Amunicipal WiFi, or= hotel broadband connections - that would rule out,=0D=0Asay, Skype and Von= age) - so VoIP is just traditional cellular with an IP=0D=0Abearer for the = voice=3F=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message---= --=0D=0AFrom: Brian Rosen [mailto:br@brianrosen.net]=20=0D=0ASent: Thursday= , 8 March 2007 3:36 AM=0D=0ATo: 'Andrew Newton'=0D=0ACc: g.caron@bell.ca; g= eopriv@ietf.org; Dawson, Martin;=0D=0Amlinsner@cisco.com=0D=0ASubject: RE:=0D= =0A[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)=0D= =0A=0D=0AUnless you can show that this is significantly different from the=0D= =0Acurrent=0D=0Asituation where you DO get suspicious data, and we DO handl= e it=0D=0Asatisfactorily, then I believe that we know the cure won't be wor= se than=0D=0Athe=0D=0Adisease. The benefit is known, and we have experienc= e that the downside=0D=0Ais=0D=0Anot harmful. =20=0D=0A=0D=0AYour suggestio= n that only "accredited" VSPs can send calls to PSAPs is=0D=0Aunworkable, a= lthough, again, there can be some suspicion associated with=0D=0Acalls orig= inating from an entity not known to the PSAP. However, that=0D=0Ahas=0D=0A= nothing to do with the problem at hand, since the VSP doesn't supply=0D=0Al= ocation, the access network does.=0D=0A=0D=0ABrian=0D=0A=0D=0A> -----Origin= al Message-----=0D=0A> From: Andrew Newton [mailto:andy@hxr.us]=0D=0A> Sent= : Wednesday, March 07, 2007 11:24 AM=0D=0A> To: Brian Rosen=0D=0A> Cc: g.ca= ron@bell.ca; geopriv@ietf.org; Martin.Dawson@andrew.com;=0D=0A> mlinsner@ci= sco.com=0D=0A> Subject: Re: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(= PIDF-=0D=0A> LOdigitalsignatures)=0D=0A>=20=0D=0A> Brian,=0D=0A>=20=0D=0A> = The problem is that the cure may end up worse than the disease. The=0D=0A>= benefit is unknown or negligible, and the down sides can be downright=0D=0A= > harmful. Place that against the added technical complexity and the=0D=0A= > fact that the solution is patent encumbered with an unknown right to=0D=0A= > use, and it is easy to see that the costs exceed the benefits.=0D=0A>=20=0D= =0A> As for another way, NENA has already provided that answer: only=0D=0A>= accredited VSPs can talk to PSAPs. That puts the problem on par with=0D=0A= > the current solution of the PSTN.=0D=0A>=20=0D=0A> -andy=0D=0A>=20=0D=0A>= On Mar 7, 2007, at 10:50 AM, Brian Rosen wrote:=0D=0A>=20=0D=0A> > Andy=0D= =0A> >=0D=0A> > In all of this discussion, you seem unconvinced that the 9-= 1-1 call=0D=0A> > taker=0D=0A> > can deal with information that is marked s= uspicious, but may be=0D=0A> > correct.=0D=0A> > This happens already, they= do handle it okay, and they are=0D=0A> > comfortable with=0D=0A> > informa= tion that may or not be correct. A typical example is that=0D=0A> > the AL= I=0D=0A> > screen says one thing, the caller insists on another. This is=0D= =0A> > suspicious,=0D=0A> > but permitted. The response will always go to = where the caller=0D=0A> > said to go.=0D=0A> > There will be some follow up= to determine how the discrepancy=0D=0A> > happened if it=0D=0A> > turns ou= t the caller was right.=0D=0A> >=0D=0A> > Again, they do this now. It work= s. They want it.=0D=0A> >=0D=0A> > We're chasing our tail on this, and we = need to figure a way out. I=0D=0A> > get that=0D=0A> > there are people wh= o don't believe we get a sufficiently good=0D=0A> > defense to an=0D=0A> > = acknowledged threat out of signing location. There are a group of=0D=0A> >= us who=0D=0A> > think we do. Those of us who think so readily agree that = unsigned=0D=0A> > location=0D=0A> > can be valid. However, we think the me= chanism will effectively=0D=0A> > deter a very=0D=0A> > large class of not-= highly-skilled and not-well-financed attackers.=0D=0A> >=0D=0A> > The large= st problem continues to be that we are very significantly=0D=0A> > weakenin= g=0D=0A> > the security of location as we move to the geopriv way of doing=0D= =0A> > things.=0D=0A> > What used to be locked inside a wireline/wireless c= arrier's domain,=0D=0A> > with no=0D=0A> > access by end users is turning i= nto an end user controlled=0D=0A> > environment.=0D=0A> > We're opening a h= uge security hole. We need some effective=0D=0A> > strategies to=0D=0A> > = minimize this hole. We can't close it as securely as it was. We=0D=0A> > = think=0D=0A> > signatures are one way to significantly help. You don't agr= ee, I=0D=0A> > get it,=0D=0A> > but it sure would help if you had a better = way. You are saying=0D=0A> > "no, no no"=0D=0A> > and not "not that way, u= se this way".=0D=0A> >=0D=0A> > Brian=0D=0A> >=0D=0A> >> -----Original Mess= age-----=0D=0A> >> From: Andrew Newton [mailto:andy@hxr.us]=0D=0A> >> Sent:= Wednesday, March 07, 2007 10:20 AM=0D=0A> >> To: g.caron@bell.ca=0D=0A> >>= Cc: geopriv@ietf.org; Martin.Dawson@andrew.com; mlinsner@cisco.com=0D=0A> = >> Subject: Re: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-=0D=0A>= >> LOdigitalsignatures)=0D=0A> >>=0D=0A> >>=0D=0A> >> On Feb 27, 2007, at = 10:10 PM, g.caron@bell.ca wrote:=0D=0A> >>> - If the location provided verb= ally matches with the automated un-=0D=0A> >>> signed/fail-signed location,= be suspicious before dispatching.=0D=0APost-=0D=0A> >>> call investigation= is required.=0D=0A> >>>=0D=0A> >>> - If the location provided verbally don= 't match with the automated=0D=0A> >>> signed location, process the call an= d report the error afterward=0D=0Ato=0D=0A> >>> the location source (presum= ably the LIS operator).=0D=0A> >>=0D=0A> >> Guy,=0D=0A> >>=0D=0A> >> Here's= the problem with that logic. Administrative screw-ups can=0D=0A> >> cause= both of those problems, yet one type of screw up is=0D=0Aconsidered=0D=0A>= >> suspicious while the other type is not. From a security=0D=0Aperspecti= ve,=0D=0A> >> this opens up a social engineering attack... the caller needs= no=0D=0A> >> technical skill to defeat the signed location. All they need= to do=0D=0A> >> is just verbally disagree with it.=0D=0A> >>=0D=0A> >> -an= dy=0D=0A> >> _______________________________________________=0D=0A> >> Geop= riv mailing list=0D=0A> >> Geopriv@ietf.org=0D=0A> >> https://www1.ietf.org= /mailman/listinfo/geopriv=0D=0A> >=0D=0A> >=0D=0A> > ______________________= _________________________=0D=0A> > Geopriv mailing list=0D=0A> > Geopriv@ie= tf.org=0D=0A> > https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A=0D=0A=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 07 20:02: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 1HP71S-0007YQ-5M; Wed, 07 Mar 2007 20:02:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP52l-0004Tp-39 for geopriv@ietf.org; Wed, 07 Mar 2007 17:55:35 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP47j-0002Z9-D2 for geopriv@ietf.org; Wed, 07 Mar 2007 16:56:40 -0500 X-SEF-Processed: 5_0_0_910__2007_03_07_16_02_32 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, 07 Mar 2007 16:02:31 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 15:56:39 -0600 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: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Wed, 7 Mar 2007 15:56:37 -0600 Message-ID: In-Reply-To: <6CC7A6A1-5A93-41E6-81AF-6372380BC481@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Thread-Index: Acdg6yWQzr5SnY3VTcO/9I+pQM2EHAAGEoKw From: "Dawson, Martin" To: "Andrew Newton" , "Brian Rosen" X-OriginalArrivalTime: 07 Mar 2007 21:56:39.0013 (UTC) FILETIME=[7B9E8150:01C76103] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: geopriv@ietf.org, Marc Linsner X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org What's the patent encumbrance=3F Can someone enlighten me=3F=0D=0A=0D=0AChe= ers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Andrew Ne= wton [mailto:andy@hxr.us]=20=0D=0ASent: Thursday, 8 March 2007 6:02 AM=0D=0A= To: Brian Rosen=0D=0ACc: geopriv@ietf.org; 'Marc Linsner'=0D=0ASubject: Re:=0D= =0A[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)=0D= =0A=0D=0A=0D=0AOn Mar 7, 2007, at 1:53 PM, Brian Rosen wrote:=0D=0A=0D=0A> = Yes, it works. I don't think it's any better or worse than signing =20=0D=0A= > the=0D=0A> location value, but the operations required (dereference at ev= ery =20=0D=0A> step) is a=0D=0A> pain. It's functional. Consider that the= TLS operation needs the =20=0D=0A> very same=0D=0A> cert that you would us= e to sign, the crypto operations are roughly =20=0D=0A> similar,=0D=0A> and= the security is pretty much the same.=0D=0A=0D=0ANo. You missed one cruci= al and important operation: data =20=0D=0Acanonicalization. Signing the da= ta requires it, using TLS does not. =20=0D=0AAnd replay attacks can be thw= arted. Plus, it isn't patent encumbered.=0D=0A=0D=0A> Let's look at the ca= ses you seem to care about: enterprise and Marc=0D=0A> Linsner's boat-as-ac= cess-network.=0D=0A>=0D=0A> The enterprise can sign a cert or use it's cert= to create a TLS =20=0D=0A> connection.=0D=0A> To trust it, the cert it use= s has to be signed by someone you trust.=0D=0A> Signatures have the same ch= aracteristics as TLS. If it won't =20=0D=0A> accept a TLS=0D=0A> (or only = offers digest authentication) then you could be suspicious,=0D=0A> although= you would proceed.=0D=0A>=0D=0A> The boat is unlikely to have a cert you t= rust for either TLS or =20=0D=0A> signing.=0D=0A> Best you could do is to v= erify that the domain is owned by the =20=0D=0A> signer, if=0D=0A> the cert= was in the DNS.=0D=0A=0D=0AIt offers no new trust relationship, that is co= rrect.=0D=0A=0D=0A-andy=0D=0A=0D=0A________________________________________= _______=0D=0AGeopriv mailing list=0D=0AGeopriv@ietf.org=0D=0Ahttps://www1.i= etf.org/mailman/listinfo/geopriv=0D=0A=0D=0A-------------------------------= -----------------------------------------------------------------=0D=0AThis= message is for the designated recipient only and may=0D=0Acontain privileg= ed, proprietary, or otherwise private information. =20=0D=0AIf you have rec= eived 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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 07 20:11:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP79z-0003af-7Y; Wed, 07 Mar 2007 20:11:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP79y-0003aY-Ef for geopriv@ietf.org; Wed, 07 Mar 2007 20:11:10 -0500 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP79w-0002UK-SP for geopriv@ietf.org; Wed, 07 Mar 2007 20:11:10 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 07 Mar 2007 20:09:08 -0500 id 01588162.45EF6234.000039A4 Mime-Version: 1.0 To: GEOPRIV WG Message-Id: <6F1F5C05-5579-46EF-A86C-647B0667466E@hxr.us> References: From: Andrew Newton Date: Wed, 7 Mar 2007 20:10:59 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Subject: [Geopriv] Fwd: I-D ACTION:draft-marshall-geopriv-lbyr-requirements-01.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0128950540==" Errors-To: geopriv-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0128950540== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-14759-1173316156-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-14759-1173316156-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit FYI Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: March 7, 2007 3:50:02 PM EST > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-marshall-geopriv-lbyr-requirements-01.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Requirements for a Location-by-Reference Mechanism used > in Location Configuration and Conveyance > Author(s) : R. Marshall > Filename : draft-marshall-geopriv-lbyr-requirements-01.txt > Pages : 21 > Date : 2007-3-7 > > This document defines terminology and enumerates requirements for a > location-by-reference approach to location configuration and > conveyance interactions useful for emergency call routing for > voice- > over-IP (VoIP) and general Internet multimedia systems, where > Internet protocols are used end-to-end. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-marshall-geopriv-lbyr- > requirements-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-marshall-geopriv-lbyr-requirements-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-marshall-geopriv-lbyr- > requirements-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-3-7105923.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce --=_zeke.ecotroph.net-14759-1173316156-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.54.2 FYI

Begin forwarded = message:

From: Internet-Drafts@ietf.org
Date: Ma= rch 7, 2007 3:50:02 PM EST
To: i-d-ann= ounce@ietf.org
Subject: I-D ACTION:draft-marshall-geopriv-lbyr-require= ments-01.txt=A0
Reply-To: = internet-drafts@ietf.org

A = New Internet-Draft is available from the on-line Internet-Drafts=A0
directories= .

=09Title=09=09: Requirements for a Location-by-Reference Mec= hanism used in Location Configuration and Conveyance
=09Auth= or(s)=09: = R. Marshall
=09Filename=09: draft-marshall-geopriv-lbyr-requirements-01= .txt
=09Pages=09=09: 21
=09Date=09=09: 2007-3-7
=09
This document defines terminology and enumerates requirements = for a
=A0=A0 = location-by-reference approach to location configuration and
=
=A0=A0 conv= eyance interactions useful for emergency call routing for voice-
=A0=A0 over-IP = (VoIP) and general Internet multimedia systems, where
=A0=A0 Internet protocols = are used end-to-end.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-marshall-ge= opriv-lbyr-requirements-01.txt
To remove yourself from the I-D Announcement = list, send a message to=A0
i-d-= announce-request@ietf.org with the word unsubscribe in the body of=A0
the m= essage.=A0
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=A0
to cha= nge your subscription settings.
<= BR>
Internet-Drafts are also available by anonymous = FTP. Login with the=A0
=
username "anonymous" and a password of your e-mail addre= ss. After=A0
logging in, type "cd internet-drafts" and then=A0
"get draft-marshall-ge= opriv-lbyr-requirements-01.txt".
=
A list of Internet-Drafts directories can be f= ound in
http://www.ietf.org/shadow.html=A0
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts = can also be obtained by e-mail.
<= BR>
Send a message to:
=09mailserv@ietf.org.
In t= he body type:
=09"FILE /internet-drafts/draft-marshall-geopriv= -lbyr-requirements-01.txt".
=09
NOTE:=09The mail server at ietf.org can return the document in
=09MIME-encoded form by using the "mpack" utility.=A0 To use this
=09feature, insert the c= ommand "ENCODING mime" before the "FILE"
=09command.=A0 To decode the response(s), you w= ill need "munpack" or
=09a MIME-compliant mail reader.=A0 Different MIME-compliant mail = readers
=09exhibit different behavior, especially when deali= ng with
=09"multipart" MIME messages (i.e. documents which h= ave been split
=09up into multiple messages), so check your = local documentation on
=09how to manipulate these messages.<= /DIV>

Below = is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the<= /DIV>
Internet-Draft.
Content-Type: = text/plain
Content-ID: <2007-3-7105923.I-D@ietf.org>

_____________________= __________________________
I-D-Announce mailing lis= t
I-D-Anno= unce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d= -announce

--=_zeke.ecotroph.net-14759-1173316156-0001-2-- --===============0128950540== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0128950540==-- From geopriv-bounces@ietf.org Wed Mar 07 20:25:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP7Nq-0008Av-00; Wed, 07 Mar 2007 20:25:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP7No-000896-JY for geopriv@ietf.org; Wed, 07 Mar 2007 20:25:28 -0500 Received: from [206.173.41.176] (helo=sea-mimesweep-1.telecomsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP7Nn-0004i9-IS for geopriv@ietf.org; Wed, 07 Mar 2007 20:25:28 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.5) with ESMTP id ; Wed, 7 Mar 2007 17:25:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] Fwd: I-DACTION:draft-marshall-geopriv-lbyr-requirements-01.txt Date: Wed, 7 Mar 2007 17:25:25 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657506F8DCE6@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <6F1F5C05-5579-46EF-A86C-647B0667466E@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Fwd: I-DACTION:draft-marshall-geopriv-lbyr-requirements-01.txt Thread-Index: AcdhHrliGjsz6UfbSj6exE8Z8YD8lQAALzag References: <6F1F5C05-5579-46EF-A86C-647B0667466E@hxr.us> From: "Roger Marshall" To: "Andrew Newton" , "GEOPRIV WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7cb76adb986247703cbb5582da68b5fc Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0238855619==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============0238855619== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76120.A671169F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76120.A671169F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This updated version of the lbyr requirements, much to my chagrin, has a fair bit of roughness compared to what I had intended (mostly the Intro, which is full of borrowed text!). I hope to do another update to an -02 soon, so if you take a look, ignore the Introduction altogether, and focus on the requirements list itself, and the included diagrams, which were based on list comments and contributions. * Please ignore the borrowed geopriv-sip-conveyance text for reference, in the Intro - will be culled and the Intro revamped * I've pared down the list of requirements -- still mulling over the target of lbyr requirements - seems like they might apply only to the dereferencing protocol - (i.e., it seemed awkward to place requirements onto what a conveyance protocol, a location server, or a configuration protocol would do, so I attempted to keep only those req's that targeted the dereference protocol) -- jettisoned requirements that targeted what a 'conveyance' protocol would do -- deleted requirements that dictated the behaviour of what a 'location server' would do * aligned actor terminology with what is already in RFC3693 (for the most part) * replaced original SIP example diagram with four new diagrams - these are for discussion, and are based on contributions from R. Barnes & M. Thompson. regards, =20 Roger Marshall. =20 ________________________________ From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Wednesday, March 07, 2007 5:11 PM To: GEOPRIV WG Subject: [Geopriv] Fwd: I-DACTION:draft-marshall-geopriv-lbyr-requirements-01.txt=20 =09 =09 FYI =09 Begin forwarded message: From: Internet-Drafts@ietf.org Date: March 7, 2007 3:50:02 PM EST To: i-d-announce@ietf.org Subject: I-D ACTION:draft-marshall-geopriv-lbyr-requirements-01.txt=20 Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : Requirements for a Location-by-Reference Mechanism used in Location Configuration and Conveyance Author(s) : R. Marshall Filename : draft-marshall-geopriv-lbyr-requirements-01.txt Pages : 21 Date : 2007-3-7 =09 =09 This document defines terminology and enumerates requirements for a location-by-reference approach to location configuration and conveyance interactions useful for emergency call routing for voice- over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. A URL for this Internet-Draft is: =09 http://www.ietf.org/internet-drafts/draft-marshall-geopriv-lbyr-requirem ents-01.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-marshall-geopriv-lbyr-requirements-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-marshall-geopriv-lbyr-requirements-01.txt". =09 =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2007-3-7105923.I-D@ietf.org> _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce The information contained in this message may be privileged and/or confiden= tial. If you are not the intended recipient, or responsible for delivering = this message to the intended recipient, any review, forwarding, disseminati= on, distribution or copying of this communication or any attachment(s) is s= trictly prohibited. If you have received this message in error, please so n= otify the sender immediately, and delete it and all attachments from your c= omputer and network. ------_=_NextPart_001_01C76120.A671169F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This updated version of the lbyr=20 requirements, much to my=20 chagrin, has a fair bit of roughness= =20 compared to what I had intended (mostly the Intro, which is full of borrowe= d=20 text!). I hope to do another u= pdate=20 to an -02 soon, so if you take a look, ignore the Introduction altogether, and focus<= /SPAN>=20 on the requirements list itself, and the included diagrams, which were based on list comments and=20 contributions.

* Please ignore the borrowed= =20 geopriv-sip-conveyance text for reference, in the Intro - will be culled an= d the=20 Intro revamped

* I've pared down the list o= f=20 requirements

-- still mulling= over the=20 target of lbyr requirements - seems like they might apply only to the=20 dereferencing protocol - (i.e., it seemed = awkward=20 to place requirements onto what a conveyance protocol, a location server, o= r a=20 configuration protocol would do, so I attempted to keep only thos= e=20 req's that targeted the dereference protocol)
-- jettisoned requirements t= hat=20 targeted what a 'conveyance' protocol would do

-- deleted requirements that= dictated=20 the behaviour of what a 'location server' would do

* aligned actor terminology = with what=20 is already in RFC3693 (for the most part)

* replaced original SIP exam= ple diagram=20 with four new diagrams - these are for discussion, and are based on=20 contributions from R. Barnes & M. Thompson.

regards,

Roger=20 Marshall.

From: Andrew Newton [mailto:andy@hxr.= us]=20
Sent: Wednesday, March 07, 2007 5:11 PM
To: GEOPRIV= =20 WG
Subject: [Geopriv] Fwd:=20 I-DACTION:draft-marshall-geopriv-lbyr-requirements-01.txt=20

FYI

Begin forwarded message:

From: Internet-Drafts@ietf.org

Date: March 7, 2007 = 3:50:02 PM=20 EST

To: i-d-announce@ietf.org<= /DIV>
Subject: I-D=20 ACTION:draft-marshall-geopriv-lbyr-requirements-01.txt

Reply-To: internet-drafts@ietf.org

A New Internet-Draft is available from the o= n-line=20 Internet-Drafts

directories.

Title : Requirements for a Location-by-Refe= rence=20 Mechanism used in Location Configuration and Conveyance

Author(s) : R. Marshall

Filename :=20 draft-marshall-geopriv-lbyr-requirements-01.txt

Pages : 21

Date : 2007-3-7

<= /P>
This document defines terminology and enumer= ates=20 requirements for a

&n= bsp;=20 location-by-reference approach to location configuration and
&n= bsp;=20 conveyance interactions useful for emergency call routing for=20 voice-

&n= bsp;=20 over-IP (VoIP) and general Internet multimedia systems, where
&n= bsp;=20 Internet protocols are used end-to-end.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-marshall-ge= opriv-lbyr-requirements-01.txt

To remove yourself from the I-D Announcement= list,=20 send a message to

i-d-announce-request@ietf= .org=20 with the word unsubscribe in the body of

the message.

You can also visit https://ww= w1.ietf.org/mailman/listinfo/I-D-announce

to change your subscription settings.

Internet-Drafts are also available by anonym= ous=20 FTP. Login with the
username "anonymous" and a password of your = e-mail=20 address. After

logging in, type "cd internet-drafts" and th= en

"get=20 draft-marshall-geopriv-lbyr-requirements-01.txt".

A list of Internet-Drafts directories can be= found=20 in

http://www.ietf.org/shadow.htm= l

or ftp://ftp.ietf.org/i= etf/1shadow-sites.txt

Internet-Drafts can also be obtained by=20 e-mail.

Send a message to:

mailserv@ietf.org.

In the body type:

"FILE=20 /internet-drafts/draft-marshall-geopriv-lbyr-requirements-01.txt".

<= /P>
NOTE: The mail server at ietf.org can retu= rn the=20 document in

MIME-encoded form by using the "mpack= "=20 utility. To use this
feature, insert the command "ENCODING= mime"=20 before the "FILE"

command. To decode the response(s), = you=20 will need "munpack" or

a MIME-compliant mail reader. Different MIME-compliant ma= il=20 readers

exhibit different behavior, especiall= y when=20 dealing with

"multipart" MIME messages (i.e. docum= ents=20 which have been split

up into multiple messages), so check = your=20 local documentation on

how to manipulate these messages.

Below is the data which will enable a MIME=20 compliant mail reader

implementation to automatically retrieve the= ASCII=20 version of the

Internet-Draft.

Content-Type: text/plain

Content-ID: <2007-3-7105923.I-D@ietf.org= >

_______________________________________________
I-D-Announce mailing list

I-D-Announce@ietf.org

https://ww= w1.ietf.org/mailman/listinfo/i-d-announce

<= /BLOCKQUOTE>

The information cont= ained in this message may be privileged and/or confidential. If you are not= the intended recipient, or responsible for delivering this message to the = intended recipient, any review, forwarding, dissemination, distribution or = copying of this communication or any attachment(s) is strictly prohibited. = If you have received this message in error, please so notify the sender imm= ediately, and delete it and all attachments from your computer and network.=

------_=_NextPart_001_01C76120.A671169F-- --===============0238855619== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0238855619==-- From geopriv-bounces@ietf.org Wed Mar 07 20:37: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 1HP7ZQ-0003er-UR; Wed, 07 Mar 2007 20:37:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP7ZQ-0003em-3A for geopriv@ietf.org; Wed, 07 Mar 2007 20:37:28 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP7ZO-0006oG-MW for geopriv@ietf.org; Wed, 07 Mar 2007 20:37:28 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l281b59H010795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Mar 2007 17:37:06 -0800 Received: from [[192.168.1.13]] (vpn-10-50-0-51.qualcomm.com [10.50.0.51]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l281b3ru026305; Wed, 7 Mar 2007 17:37:04 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <044401c760d0$4d296110$640fa8c0@cis.neustar.com> References: <044401c760d0$4d296110$640fa8c0@cis.neustar.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 7 Mar 2007 17:35:58 -0800 To: "Brian Rosen" , "'Andrew Newton'" , From: Randall Gellens Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignature s) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: geopriv@ietf.org, Martin.Dawson@andrew.com, mlinsner@cisco.com X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org At 10:50 AM -0500 3/7/07, Brian Rosen wrote: > The largest problem continues to be that we are very significantly weakening > the security of location as we move to the geopriv way of doing things. > What used to be locked inside a wireline/wireless carrier's domain, with no > access by end users is turning into an end user controlled environment. Well-said. (This is, of course, a general problem occurring in different areas as domains shift to IP.) > We're opening a huge security hole. We need some effective strategies to > minimize this hole. We can't close it as securely as it was. We think > signatures are one way to significantly help. Speaking personally, I'm undecided how effective the proposed signature mechanisms will be. I'm also concerned that techniques might be selected because they are known to us and thus fairly easy to add, as opposed to being effective. I'm not saying that's the case here, but I'm not convinced it isn't. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The best way to have a good idea is to have lots of ideas. --Linus Pauling _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 07 21:01:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP7w1-0001i4-32; Wed, 07 Mar 2007 21:00:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP7w0-0001hz-EB for geopriv@ietf.org; Wed, 07 Mar 2007 21:00:48 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP7vz-0001vW-3N for geopriv@ietf.org; Wed, 07 Mar 2007 21:00:48 -0500 Received: from [192.168.0.41] (pool-138-89-19-159.mad.east.verizon.net [138.89.19.159]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2820Xds019509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 7 Mar 2007 21:00:34 -0500 (EST) 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: <09D112E7-77E9-4FDC-B1C0-F14BB8B62E33@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Wed, 7 Mar 2007 21:00:30 -0500 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org As a side note, the 'accredited' thing is a red herring, either way. Signed location information is only meaningful if the location signer is 'accredited', i.e., known to be reputable, to the PSAP. After all, anybody, with a stolen credit card if necessary, can buy a certificate, based solely on possession of a domain name, from reputable CAs. That certificate can be used to sign any location information. Thus, signing is only meaningful if the signer is known and accountable. Now, it may well be that the number of signers is lower or more easily knowable in one or the other case, but the principle is the same. We have gone through the 'who can sign' before, so I won't repeat that particular discussion. On Mar 7, 2007, at 4:35 PM, Dawson, Martin wrote: > Actually, I don't see how the question of "accredited" VSPs is > pertinent > to this issue to begin with (and I mean apart from the fact that > this is > exactly the sort of constraint I've been told is anathema to the IETF > and that a US policy is being quoted as a generic basis for > decision-making - must be a goose and gander thing). > > Accredited VSPs have some linkage to the subscriber identity - they > can > apply whatever audit trail they can to who it is that is making the > calls. They can do nothing about the trustability of the location > information. Oh - unless you'd like to go down the 3GPP[2]/IMS > route and > say that VoIP calls can only be made from your home network or from a > roaming partner network (forget being able to use arbitrary hot spots, > municipal WiFi, or hotel broadband connections - that would rule out, > say, Skype and Vonage) - so VoIP is just traditional cellular with > an IP > bearer for the voice? > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 07 22:10:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP90o-0000Mj-8M; Wed, 07 Mar 2007 22:09:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP90n-0000ML-2t for geopriv@ietf.org; Wed, 07 Mar 2007 22:09:49 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP90l-0000rV-Mf for geopriv@ietf.org; Wed, 07 Mar 2007 22:09:48 -0500 X-SEF-Processed: 5_0_0_910__2007_03_07_21_15_39 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, 07 Mar 2007 21:15:39 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 21:09:46 -0600 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: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignature s) Date: Wed, 7 Mar 2007 21:09:44 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignature s) Thread-Index: AcdhIkrLVo/n6R38QOuIV9MzOlm5XQADCZQA From: "Dawson, Martin" To: "Randall Gellens" , "Brian Rosen" , "Andrew Newton" , X-OriginalArrivalTime: 08 Mar 2007 03:09:46.0065 (UTC) FILETIME=[39932410:01C7612F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: geopriv@ietf.org, mlinsner@cisco.com X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I certainly agree that it's a generic issue Randy. The Internet creates=0D=0A= a decoupling that didn't exist previously and more, not less,=0D=0Aapplicat= ions will rely on certificate and other private key based=0D=0Amechanisms. = Any of the objections being raised against its use for=0D=0Alocation depend= ability could be raised against any other solution that=0D=0Auses certs. It= can only be a matter of degree between any given case -=0D=0Aand that's a = very subjective distinction.=0D=0A=0D=0AThe thing is, it's the state of the= art. I'm not aware of any solution=0D=0Ato the general problem that repres= ents a quantum leap and I'm not aware=0D=0Aof one being on the horizon. If = somebody is sitting on a better=0D=0Asolution, then it would be great to he= ar from them. In the mean time,=0D=0Athough, the state of the art is what w= e can offer.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Messag= e-----=0D=0AFrom: Randall Gellens [mailto:randy@qualcomm.com]=20=0D=0ASent:= Thursday, 8 March 2007 12:36 PM=0D=0ATo: Brian Rosen; 'Andrew Newton'; g.c= aron@bell.ca=0D=0ACc: geopriv@ietf.org; Dawson, Martin; mlinsner@cisco.com=0D= =0ASubject: RE:=0D=0A[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LO= digitalsignature=0D=0As)=0D=0A=0D=0AAt 10:50 AM -0500 3/7/07, Brian Rosen w= rote:=0D=0A=0D=0A> The largest problem continues to be that we are very si= gnificantly=0D=0Aweakening=0D=0A> the security of location as we move to t= he geopriv way of doing=0D=0Athings.=0D=0A> What used to be locked inside = a wireline/wireless carrier's domain,=0D=0Awith no=0D=0A> access by end us= ers is turning into an end user controlled=0D=0Aenvironment.=0D=0A=0D=0AWel= l-said.=0D=0A=0D=0A(This is, of course, a general problem occurring in diff= erent areas=20=0D=0Aas domains shift to IP.)=0D=0A=0D=0A> We're opening a = huge security hole. We need some effective=0D=0Astrategies to=0D=0A> mini= mize this hole. We can't close it as securely as it was. We=0D=0Athink=0D= =0A> signatures are one way to significantly help.=0D=0A=0D=0ASpeaking per= sonally, I'm undecided how effective the proposed=20=0D=0Asignature mechani= sms will be. I'm also concerned that techniques=20=0D=0Amight be selected = because they are known to us and thus fairly easy=20=0D=0Ato add, as oppose= d to being effective. I'm not saying that's the=20=0D=0Acase here, but I'm= not convinced it isn't.=0D=0A=0D=0A=0D=0A--=20=0D=0ARandall Gellens=0D=0AO= pinions are personal; facts are suspect; I speak for myself only=0D=0A= -------------- Randomly-selected tag: ---------------=0D=0AThe best way to = have a good idea is to have lots of ideas.=0D=0A = --Linus Pauling=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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 07 23:39:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPAP1-0006Ho-N3; Wed, 07 Mar 2007 23:38:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPAOz-0006HY-M8 for geopriv@ietf.org; Wed, 07 Mar 2007 23:38:53 -0500 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPAOy-0002NS-DP for geopriv@ietf.org; Wed, 07 Mar 2007 23:38:53 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 07 Mar 2007 23:36:54 -0500 id 015880EB.45EF92E6.00005DB2 In-Reply-To: <09D112E7-77E9-4FDC-B1C0-F14BB8B62E33@cs.columbia.edu> References: <09D112E7-77E9-4FDC-B1C0-F14BB8B62E33@cs.columbia.edu> Mime-Version: 1.0 Message-Id: <66DEE6CF-7DE9-4848-A2CF-A88A8971FD68@hxr.us> From: Andrew Newton Subject: Re: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Wed, 7 Mar 2007 23:38:47 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: GEOPRIV , "Dawson, Martin" X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0980195062==" Errors-To: geopriv-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0980195062== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-23989-1173328619-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-23989-1173328619-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Mar 7, 2007, at 9:00 PM, Henning Schulzrinne wrote: > As a side note, the 'accredited' thing is a red herring, either > way. Signed location information is only meaningful if the location > signer is 'accredited', i.e., known to be reputable, to the PSAP. > After all, anybody, with a stolen credit card if necessary, can buy > a certificate, based solely on possession of a domain name, from > reputable CAs. That certificate can be used to sign any location > information. Thus, signing is only meaningful if the signer is > known and accountable. > > Now, it may well be that the number of signers is lower or more > easily knowable in one or the other case, but the principle is the > same. We have gone through the 'who can sign' before, so I won't > repeat that particular discussion. As you have described it, I agree. However, what I've heard in NENA meetings is that accreditation would be more than just a public cert. I suspect that there are a lot more mechanics around that than have been uncovered, and NENA will find out that they will need to be their own CA -- which I do not think they intend. -andy --=_zeke.ecotroph.net-23989-1173328619-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.54.2
On Mar 7, 2007, at 9:00 = PM, Henning Schulzrinne wrote:

As = a side note, the 'accredited' thing is a red herring, either way. Signed = location information is only meaningful if the location signer is 'accred= ited', i.e., known to be reputable, to the PSAP. After all, anybody, with = a stolen credit card if necessary, can buy a certificate, based solely on = possession of a domain name, from reputable CAs. That certificate can be = used to sign any location information. Thus, signing is only meaningful i= f the signer is known and accountable.

Now, it may well be that the n= umber of signers is lower or more easily knowable in one or the other cas= e, but the principle is the same. We have gone through the 'who can sign' = before, so I won't repeat that particular discussion.

As you have described it, I agree.=A0 However, what I= 've heard in NENA meetings is that accreditation would be more than just = a public cert.=A0 I suspect that there are a lot more mechanics around th= at than have been uncovered, and NENA will find out that they will need t= o be their own CA -- which I do not think they intend.

-andy
--=_zeke.ecotroph.net-23989-1173328619-0001-2-- --===============0980195062== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0980195062==-- From geopriv-bounces@ietf.org Thu Mar 08 00:22: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 1HPB54-0003Rm-S3; Thu, 08 Mar 2007 00:22:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPB53-0003Rg-8A for geopriv@ietf.org; Thu, 08 Mar 2007 00:22:21 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPB52-0003oc-M7 for geopriv@ietf.org; Thu, 08 Mar 2007 00:22:21 -0500 X-SEF-Processed: 5_0_0_910__2007_03_07_23_28_12 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, 07 Mar 2007 23:28:12 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 23:22:19 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Wed, 7 Mar 2007 23:22:17 -0600 Message-ID: In-Reply-To: <66DEE6CF-7DE9-4848-A2CF-A88A8971FD68@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Thread-Index: AcdhO6uIV02uFKWuSLGTaY+KKhYJ/AABLmCg From: "Dawson, Martin" To: "Andrew Newton" , "Henning Schulzrinne" X-OriginalArrivalTime: 08 Mar 2007 05:22:19.0139 (UTC) FILETIME=[BDF9ED30:01C76141] X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0604747471==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============0604747471== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76141.BDB713D8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76141.BDB713D8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NENA identified the Valid Emergency Services Authority (VESA) agency as=0D=0A= part of the i2 architecture. It was already acknowledged that NENA was=0D=0A= one candidate for providing the VESA function - there are numerous other=0D= =0Apossibilities including authorized commercial enterprise. At the TDC/ODC=0D= =0Ain Nashville in January, I explicitly asked the chair of the=0D=0A"certi= fication committee" whether there was a possibility that they=0D=0Acould fo= rm the basis for VESA - they acknowledged that they could,=0D=0Athough it's= not decided by any means. The main goal of the=0D=0Acertification/accredit= ation committee is to provide a set of processes=0D=0Aand standards by whic= h the various entities in the emergency=0D=0Aarchitecture (access providers= , VoIP providers, VPC operators, ESGW=0D=0Aoperators, ALI operators, PSAPs.= =2E..) can be assessed for satisfactory=0D=0Acompliance to the requirements= of the emergency industry. It's an=0D=0Aindependent audit of capabilities = including infrastructure and=0D=0Aprocesses. There is no decision about wha= t the implications of being=0D=0A"accredited" are yet. It establishes a ben= chmark for capabilities - the=0D=0Aimplications may eventually be defined b= y regulatory bodies or through=0D=0Aindividual industry body policy - or ma= ybe it'll be left to the market=0D=0Ato decide whether they want to sign up= with "NENA preferred" providers=0D=0Aor not.=0D=0A=0D=0A=20=0D=0A=0D=0AThe= intent of i2 is that the LIS certificate used for signing location=0D=0Ais= , in turn, signed by VESA. Getting a certificate from VESA is not just=0D=0A= a case of whacking down a credit card.=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D= =0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A________________________________=0D= =0A=0D=0AFrom: Andrew Newton [mailto:andy@hxr.us]=20=0D=0ASent: Thursday, 8= March 2007 3:39 PM=0D=0ATo: Henning Schulzrinne=0D=0ACc: Dawson, Martin; G= EOPRIV=0D=0ASubject: Re:=0D=0A[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-0= 0(PIDF-LOdigitalsignatures)=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0AOn Mar= 7, 2007, at 9:00 PM, Henning Schulzrinne wrote:=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0AAs a side note, the 'accredited' thing is a red herring, either wa= y.=0D=0ASigned location information is only meaningful if the location sign= er is=0D=0A'accredited', i.e., known to be reputable, to the PSAP. After al= l,=0D=0Aanybody, with a stolen credit card if necessary, can buy a certific= ate,=0D=0Abased solely on possession of a domain name, from reputable CAs. = That=0D=0Acertificate can be used to sign any location information. Thus, s= igning=0D=0Ais only meaningful if the signer is known and accountable.=0D=0A=0D= =0A=20=0D=0A=0D=0ANow, it may well be that the number of signers is lower o= r more easily=0D=0Aknowable in one or the other case, but the principle is = the same. We=0D=0Ahave gone through the 'who can sign' before, so I won't r= epeat that=0D=0Aparticular discussion.=0D=0A=0D=0A=20=0D=0A=0D=0AAs you hav= e described it, I agree. However, what I've heard in NENA=0D=0Ameetings is= that accreditation would be more than just a public cert. I=0D=0Asuspect = that there are a lot more mechanics around that than have been=0D=0Auncover= ed, and NENA will find out that they will need to be their own CA=0D=0A-- w= hich I do not think they intend.=0D=0A=0D=0A=20=0D=0A=0D=0A-andy=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_01C76141.BDB713D8 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<= div class=3DSection1>=0D=0A=0D=0A
NENA identified the Valid Emergency=0D=0AServices Authority (VES= A) agency as part of the i2 architecture. It was already=0D=0Aacknowledged = that NENA was one candidate for providing the VESA function –=0D=0Ath= ere are numerous other possibilities including authorized commercial=0D=0Ae= nterprise. At the TDC/ODC in N= ashville=0D=0Ain January, I explicitly asked the cha= ir of the “certification committee”=0D=0Awhether there was a po= ssibility that they could form the basis for VESA –=0D=0Athey acknowl= edged that they could, though it’s not decided by any means. The=0D=0A= main goal of the certification/accreditation committee is to provide a set = of=0D=0Aprocesses and standards by which the various entities in the emerge= ncy=0D=0Aarchitecture (access providers, VoIP providers, VPC operators, ESG= W operators, ALI=0D=0Aoperators, PSAPs….) can be assessed for satisfa= ctory compliance to the requirements=0D=0Aof the emergency industry. ItR= 17;s an independent audit of capabilities=0D=0Aincluding infrastructure and= processes. There is no decision about what the=0D=0Aimplications of being = “accredited” are yet. It establishes a=0D=0Abenchmark for capab= ilities – the implications may eventually be defined=0D=0Aby regulato= ry bodies or through individual industry body policy – or maybe=0D=0A= it’ll be left to the market to decide whether they want to sign up wi= th “NENA=0D=0Apreferred” providers or not.
=0D=0A=0D=0A
<= o:p>
=0D=0A=0D=0A
The intent of i2 is that the LIS=0D=0Acertificate= used for signing location is, in turn, signed by VESA. Getting a=0D=0Acert= ificate from VESA is not just a case of whacking down a credit card.
=0D=0A=0D=0A

=0D=0A=0D=0A
Cheers,=0D=0A=0D=0A
= Martin<= 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=0AAndrew Newton [mailto:andy@hxr.us]
=0D=0ASent: Thursday, 8 March 2007 3:39=0D= =0APM
=0D=0ATo: Henning S= chulzrinne
=0D=0ACc: Daws= on, Martin; GEOPRIV
=0D=0ASubject: Re:=0D=0A[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdi= gitalsignatures)=0D=0A=0D=0A
=0D=0A=0D=0A

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

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
On Mar 7, 2007, at 9:00 PM, Henning Schulzrinne wrote:
=0D=0A=0D=0A
=0D=0A=0D=0A

=0D= =0A
=0D=0A
=0D=0A=0D=0A
As a side note, the 'accredited'=0D= =0Athing is a red herring, either way. Signed location information is only=0D= =0Ameaningful if the location signer is 'accredited', i.e., known to be rep= utable,=0D=0Ato the PSAP. After all, anybody, with a stolen credit card if = necessary, can=0D=0Abuy a certificate, based solely on possession of a doma= in name, from reputable=0D=0ACAs. That certificate can be used to sign any = location information. Thus,=0D=0Asigning is only meaningful if the signer i= s known and accountable.
=0D=0A=0D=0A
=
=0D=0A=0D=0A
Now, it may well be that the=0D=0Anumber of si= gners is lower or more easily knowable in one or the other case,=0D=0Abut t= he principle is the same. We have gone through the 'who can sign' before,=0D= =0Aso I won't repeat that particular discussion.=0D=0A=0D=0A
=0D=0A=0D=0A
<= /span>
=0D=0A=0D=0A
=0D=0A=0D=0A
As y= ou have described it, I agree. However, what I've heard in=0D=0ANENA = meetings is that accreditation would be more than just a public=0D=0Acert.&= nbsp; I suspect that there are a lot more mechanics around that than have=0D= =0Abeen uncovered, and NENA will find out that they will need to be their o= wn CA=0D=0A-- which I do not think they intend.=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D= =0A
-andy
=0D=0A=0D=0A<= /div>=0D=0A=0D=0A
=0D=0A=0D=0A

--------------------------------------------------= ----------------------------------------------
=0D=0AThis message&n= bsp;is for the designated recipient only and&= nbsp;may
=0D=0Acontain privileged, proprietary, or o= therwise private information.
=0D=0AIf you&nb= sp;have received it in error, please notify&n= bsp;the sender
=0D=0Aimmediately and delete the = ;original.  Any unauthorized use of
=0D=0Athis&= nbsp;email is prohibited.
=0D=0A------------------------------= ------------------------------------------------------------------
=0D=0A= [mf2]
=0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01C76141.BDB713D8-- --===============0604747471== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0604747471==-- From geopriv-bounces@ietf.org Thu Mar 08 00:29: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 1HPBCI-0006Lp-3o; Thu, 08 Mar 2007 00:29:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPBCH-0006Lj-8j for geopriv@ietf.org; Thu, 08 Mar 2007 00:29:49 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPBCE-0006Nj-MF for geopriv@ietf.org; Thu, 08 Mar 2007 00:29:49 -0500 X-SEF-Processed: 5_0_0_910__2007_03_07_23_35_39 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, 07 Mar 2007 23:35:39 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 23:29:45 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Wed, 7 Mar 2007 23:29:42 -0600 Message-ID: In-Reply-To: <79F982FE-7D94-4012-808E-33EE6BC3CFEF@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Thread-Index: AcdhBoSNTMlirw9zRCWDg6I6rnVHNwAO0ZHQ From: "Dawson, Martin" To: "Andrew Newton" X-OriginalArrivalTime: 08 Mar 2007 05:29:45.0620 (UTC) FILETIME=[C8198540:01C76142] X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: geopriv@ietf.org, Marc Linsner X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1097626388==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============1097626388== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76142.C7DDE72A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76142.C7DDE72A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Wow - what a surprise, these just happen to be patents with my name on=0D=0A= them; though they are not owned by me or my current employer.=0D=0A=0D=0A =0D= =0A=0D=0AUS2006161967=0D=0A=0D=0AIs about transitive trust relationships an= d represents no encumbrance on=0D=0Athe use of digital signatures for locat= ion integrity. It might mention=0D=0Athis but that is as context and not as= part of a claim. In fact, if=0D=0Aanybody wants, I can provide public disc= losed material from NENA=0D=0Ameetings that discuss digital signatures for = location integrity and=0D=0Awhich predates this patent. This demonstrates t= he patent can't imply any=0D=0Aencumbrance because said prior public disclo= sure would invalidate any=0D=0Aclaim.=0D=0A=0D=0A=20=0D=0A=0D=0AUS200613517= 7=0D=0A=0D=0AThis presents an architecture for privacy control and is not r= elated to=0D=0Alocation integrity or digital signatures at all.=0D=0A=0D=0A= =20=0D=0A=0D=0ADoes that address the question of whether there is any IPR e= ncumbrance=0D=0Aon digital signatures for location=3F=0D=0A=0D=0A=20=0D=0A=0D= =0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A____________________= ____________=0D=0A=0D=0AFrom: Andrew Newton [mailto:andy@hxr.us]=20=0D=0ASe= nt: Thursday, 8 March 2007 9:18 AM=0D=0ATo: Dawson, Martin=0D=0ACc: Brian R= osen; geopriv@ietf.org; Marc Linsner=0D=0ASubject: Re:=0D=0A[Geopriv]WGLCon= draft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)=0D=0A=0D=0A=20=0D= =0A=0D=0A=20=0D=0A=0D=0AOn Mar 7, 2007, at 4:56 PM, Dawson, Martin wrote:=0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0AWhat's the patent encumbrance=3F Can someo= ne enlighten me=3F=0D=0A=0D=0A=20=0D=0A=0D=0Ahttp://www1.ietf.org/mail-arch= ive/web/geopriv/current/msg02505.html=0D=0A=0D=0A=20=0D=0A=0D=0A-andy=0D=0A=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C76142.C7DDE72A 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
=0D=0A=0D=0A
Wow – what a surp= rise, these just=0D=0Ahappen to be patents with my name on them; though the= y are not owned by me or=0D=0Amy current employer.=
=0D=0A=0D=0A

=0D=0A=0D=0A
US20061= 61967<= /font>
=0D=0A=0D=0A
Is about transitive trust relationships=0D=0Aand represents no encumbranc= e on the use of digital signatures for location=0D=0Aintegrity. It might me= ntion this but that is as context and not as part of a=0D=0Aclaim. In fact,= if anybody wants, I can provide public disclosed material from=0D=0ANENA m= eetings that discuss digital signatures for location integrity and which pr= edates=0D=0Athis patent. This demonstrates the patent can’t imply any= encumbrance because=0D=0Asaid prior public disclosure would invalidate any= claim.
=0D=0A=0D=0A

=0D=0A=0D=0A=
US2006135177
=0D=0A=0D=0A
This presents an architecture for priv= acy=0D=0Acontrol and is not related to location integrity or digital signat= ures at all.
=0D=0A=0D=0A
<= font size=3D2 color=3Dnavy face=3DArial>
=0D=0A=0D= =0A
Does that address= the question of whether=0D=0Athere is any IPR encumbrance on digital signa= tures for location=3F
=0D=0A=0D=0A

=0D= =0A=0D=0A
Cheers,
=0D=0A=0D=0A
Martin
=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=0AAndrew Newton [mailto:andy@hxr.= us]
=0D=0ASent: Thursday= , 8 March 2007 9:18=0D=0AAM
=0D=0ATo= : Dawson, Martin
=0D=0ACc= : Brian Rosen; geopriv@ietf.org;=0D=0AMarc Linsner
=0D=0A<= span style=3D'font-weight:bold'>Subject: Re:=0D=0A[Geopriv]WGLCo= ndraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A

=0D=0A=0D=0A
=0D= =0A=0D=0A
=0D=0A=0D=0A
On Mar 7, 2007, at 4:56 = PM, Dawson,=0D=0AMartin wrote:
=0D=0A=0D=0A
=0D=0A=0D= =0A

=0D=0A
=0D=0A=0D=0A=0D=0A
What's the patent encumbrance=3F=0D=0ACan someone enlighten me=3F
=0D=0A=0D=0A
=0D=0A=0D=0A
=
=0D=0A=0D=0A
=0D=0A=0D=0A
http://www1.ietf.org/mail-archive/web/geopriv/current/= msg02505.html
=0D=0A=0D=0A
=0D=0A=0D=0A=
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
-= andy
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D= =0A

-------= ---------------------------------------------------------------------------= --------------
=0D=0AThis message is for the de= signated recipient only and may
=0D=0Acontain p= rivileged, proprietary, or otherwise private infor= mation.
=0D=0AIf you have received it&nb= sp;in error, please notify the sender
=0D=0Aimm= ediately and delete the original.  Any u= nauthorized use of
=0D=0Athis email is prohibit= ed.
=0D=0A--------------------------------------------------------------= ----------------------------------
=0D=0A[mf2]
=0D= =0A=0D=0A=0D=0A ------_=_NextPart_001_01C76142.C7DDE72A-- --===============1097626388== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1097626388==-- From geopriv-bounces@ietf.org Thu Mar 08 00:38:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPBKp-00006i-C9; Thu, 08 Mar 2007 00:38:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPBKo-00006d-Q8 for geopriv@ietf.org; Thu, 08 Mar 2007 00:38:38 -0500 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPBKn-0000jd-Jm for geopriv@ietf.org; Thu, 08 Mar 2007 00:38:38 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 08 Mar 2007 00:36:41 -0500 id 0158841F.45EFA0E9.00006811 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable Message-Id: <634B16CC-F231-4DB6-9A77-15264BE0FE85@hxr.us> From: Andrew Newton Subject: Re: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Thu, 8 Mar 2007 00:38:34 -0500 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: geopriv@ietf.org, Marc Linsner X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org On Mar 8, 2007, at 12:29 AM, Dawson, Martin wrote: > Wow =96 what a surprise, these just happen to be patents with my name =20= > on them; though they are not owned by me or my current employer. Indeed. > US2006161967 > > Is about transitive trust relationships and represents no =20 > encumbrance on the use of digital signatures for location =20 > integrity. It might mention this but that is as context and not as =20 > part of a claim. In fact, if anybody wants, I can provide public =20 > disclosed material from NENA meetings that discuss digital =20 > signatures for location integrity and which predates this patent. =20 > This demonstrates the patent can=92t imply any encumbrance because =20 > said prior public disclosure would invalidate any claim. Knowledge of prior art by a patent inventor is probably something =20 that should be taken up with the patent office. > Does that address the question of whether there is any IPR =20 > encumbrance on digital signatures for location? Notice from the patent holder would be much more satisfactory. -andy= _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 08 00:41: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 1HPBNe-0003x6-Qs; Thu, 08 Mar 2007 00:41:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPBNd-0003p5-6s for geopriv@ietf.org; Thu, 08 Mar 2007 00:41:33 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPBNb-0001R5-RH for geopriv@ietf.org; Thu, 08 Mar 2007 00:41:33 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l285fIFo017227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Mar 2007 21:41:19 -0800 Received: from [71.204.158.100] (vpn-10-50-16-83.qualcomm.com [10.50.16.83]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l285fHZ5010302; Wed, 7 Mar 2007 21:41:18 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <09D112E7-77E9-4FDC-B1C0-F14BB8B62E33@cs.columbia.edu> References: <09D112E7-77E9-4FDC-B1C0-F14BB8B62E33@cs.columbia.edu> Date: Wed, 7 Mar 2007 21:41:16 -0800 To: Henning Schulzrinne , "Dawson, Martin" From: Ted Hardie Subject: Re: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org At 9:00 PM -0500 3/7/07, Henning Schulzrinne wrote: >As a side note, the 'accredited' thing is a red herring, either way. Signed location information is only meaningful if the location signer is 'accredited', i.e., known to be reputable, to the PSAP. After all, anybody, with a stolen credit card if necessary, can buy a certificate, based solely on possession of a domain name, from reputable CAs. That certificate can be used to sign any location information. Thus, signing is only meaningful if the signer is known and accountable. As Steve Bellovin has put it: "A general-purpose CA will protect you from anyone that they won't take money from". >Now, it may well be that the number of signers is lower or more easily knowable in one or the other case, but the principle is the same. We have gone through the 'who can sign' before, so I won't repeat that particular discussion. > What we still don't seem to have is common understanding of how the threat model has changed. For the purposes of DDOS, folks understand very well how the change in access models has changed the threat model: in the previous system the access network topology circumscribed who could send calls to a PSAP, in a way that related fairly well to local geography; that is no longer true for the new access network model, and the result is we now need to manage a different threat (as the pool of attackers is higher and the ddos risk higher). But the same change has a consequence for trust relationships between network providers and PSAP: where the number of network providers was bounded, basically anyone can now put up an access network that has sufficient to allow access to a VSP. Extending trust to the access networks in that model is difficult, time-consuming, and either market-limiting or so weak as to be nearly useless. We need to manage that change. Doing so by adding cryptographic mechanisms *does no good if they do not reflect the trust relationships*. Define the trust relationships first, and it will get a lot easier to make the right choice of mechanism. Choosing a mechanism and then forcing the external parties to tailor their relationships to the mechanism is procrustean programming of the worst sort, and it tends to leave the attackers lots of room to wiggle in. Ted _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 08 00:43: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 1HPBPU-0005LE-3h; Thu, 08 Mar 2007 00:43:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPBPS-0005Fa-Mt for geopriv@ietf.org; Thu, 08 Mar 2007 00:43:26 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPBPR-0001au-E0 for geopriv@ietf.org; Thu, 08 Mar 2007 00:43:26 -0500 X-SEF-Processed: 5_0_0_910__2007_03_07_23_49_17 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, 07 Mar 2007 23:49:17 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 23:43:24 -0600 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: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Wed, 7 Mar 2007 23:43:20 -0600 Message-ID: In-Reply-To: <634B16CC-F231-4DB6-9A77-15264BE0FE85@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Thread-Index: AcdhRAR8RSlY+WMwRmCStnsq8NGilgAAFMlQ From: "Dawson, Martin" To: "Andrew Newton" X-OriginalArrivalTime: 08 Mar 2007 05:43:24.0530 (UTC) FILETIME=[B0354520:01C76144] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: geopriv@ietf.org, Marc Linsner X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org > Knowledge of prior art by a patent inventor is probably something =20=0D=0A=0D= =0ANo - you miss the point again. The patent office won't be interested=0D=0A= because the patent isn't about the thing you're suggesting it represents=0D= =0Aan encumbrance on. The prior art is not pertinent to the invention; it's=0D= =0Apertinent to the topic that we've been discussing. I'm emphasising that=0D= =0Athey are two different things.=0D=0A=0D=0A> Notice from the patent holde= r would be much more satisfactory.=0D=0A=0D=0AI believe that's been pursued= ad nauseum and the ball is certainly in=0D=0Athe owner's court if they wan= t to say something.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original= Message-----=0D=0AFrom: Andrew Newton [mailto:andy@hxr.us]=20=0D=0ASent: T= hursday, 8 March 2007 4:39 PM=0D=0ATo: Dawson, Martin=0D=0ACc: Brian Rosen;= geopriv@ietf.org; Marc Linsner=0D=0ASubject: Re:=0D=0A[Geopriv]WGLCondraft= -ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)=0D=0A=0D=0A=0D=0AOn Ma= r 8, 2007, at 12:29 AM, Dawson, Martin wrote:=0D=0A=0D=0A> Wow - what a sur= prise, these just happen to be patents with my name =20=0D=0A> on them; tho= ugh they are not owned by me or my current employer.=0D=0AIndeed.=0D=0A> US= 2006161967=0D=0A>=0D=0A> Is about transitive trust relationships and repres= ents no =20=0D=0A> encumbrance on the use of digital signatures for locatio= n =20=0D=0A> integrity. It might mention this but that is as context and no= t as =20=0D=0A> part of a claim. In fact, if anybody wants, I can provide p= ublic =20=0D=0A> disclosed material from NENA meetings that discuss digital= =20=0D=0A> signatures for location integrity and which predates this paten= t. =20=0D=0A> This demonstrates the patent can't imply any encumbrance beca= use =20=0D=0A> said prior public disclosure would invalidate any claim.=0D=0A= Knowledge of prior art by a patent inventor is probably something =20=0D=0A= that should be taken up with the patent office.=0D=0A> Does that address th= e question of whether there is any IPR =20=0D=0A> encumbrance on digital si= gnatures for location=3F=0D=0ANotice from the patent holder would be much m= ore satisfactory.=0D=0A=0D=0A-andy=0D=0A-----------------------------------= -------------------------------------------------------------=0D=0AThis mes= sage is for the designated recipient only and may=0D=0Acontain privileged, = proprietary, or otherwise private information. =20=0D=0AIf you have receive= d it in error, please notify the sender=0D=0Aimmediately and delete the ori= ginal. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-------= ---------------------------------------------------------------------------= --------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 08 01:04:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPBju-0004Cw-Po; Thu, 08 Mar 2007 01:04:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPBjt-0004Cr-36 for geopriv@ietf.org; Thu, 08 Mar 2007 01:04:33 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPBjs-0007Se-MO for geopriv@ietf.org; Thu, 08 Mar 2007 01:04:33 -0500 X-SEF-Processed: 5_0_0_910__2007_03_08_00_10_25 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); Thu, 08 Mar 2007 00:10:25 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 00:04:32 -0600 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: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Thu, 8 Mar 2007 00:04:29 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Thread-Index: AcdhRGZu6PrQQf7aT+GaJ+AmQb9slAAAOtHg From: "Dawson, Martin" To: "GEOPRIV" X-OriginalArrivalTime: 08 Mar 2007 06:04:32.0359 (UTC) FILETIME=[A3E49F70:01C76147] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I'd like to challenge the following premise:=0D=0A=0D=0A"... where the numb= er of network providers was=0D=0Abounded, basically anyone can now put up a= n access network that has=0D=0Asufficient to allow access to a VSP."=0D=0A=0D= =0AIn fact, the number of physical public access infrastructure providers=0D= =0Ais comparable for Internet access as it is for PSTN, including cellular.=0D= =0AUntil somebody invents and deploys subspace internet access technology,=0D= =0Athe same constraint of geographic co-location applies just as it did for=0D= =0Athe PSTN.=0D=0A=0D=0A(if this degenerates into the Pringle can debate ag= ain, then I'd refer=0D=0Apeople to the NENA archives)=0D=0A=0D=0AIncluding = ISPs certainly blows the number out but there is no strict=0D=0Arequirement= for them to be included in the trust model - any more than=0D=0Athere is f= or the PSAP to know that a cellular call that appears to come=0D=0Afrom the= Verizon network is really one coming from a subscriber of any=0D=0Aone of = a squillion MVNOs - MVNOs who don't actually own their own access=0D=0Ainfr= astructure.=0D=0A=0D=0AAs long as the location is signed by a trusted publi= c access=0D=0Ainfrastructure provider then dependability is established. Th= e=0D=0Ainfrastructure operator has the audit records that show who the actu= al=0D=0AISP for a given location was. The recent liaison document on locati= on=0D=0Aacquisition protocols that came from ESIF described this relationsh= ip=0D=0Amodel between ISPs and infrastructure providers. It's a recommended=0D= =0Aread.=0D=0A=0D=0AIf we wanted to extend the PIDF-LO to include a chain o= f provider=0D=0Aidentities so the location recipient had direct access to a= signed=0D=0Arecord of provider identities then that's certainly a good opt= ion to=0D=0Adiscuss.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Origina= l Message-----=0D=0AFrom: Ted Hardie [mailto:hardie@qualcomm.com]=20=0D=0AS= ent: Thursday, 8 March 2007 4:41 PM=0D=0ATo: Henning Schulzrinne; Dawson, M= artin=0D=0ACc: GEOPRIV=0D=0ASubject: Re:=0D=0A[Geopriv]WGLCondraft-ietf-geo= priv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)=0D=0A=0D=0AAt 9:00 PM -0500 3/7= /07, Henning Schulzrinne wrote:=0D=0A>As a side note, the 'accredited' thin= g is a red herring, either way.=0D=0ASigned location information is only me= aningful if the location signer is=0D=0A'accredited', i.e., known to be rep= utable, to the PSAP. After all,=0D=0Aanybody, with a stolen credit card if = necessary, can buy a certificate,=0D=0Abased solely on possession of a doma= in name, from reputable CAs. That=0D=0Acertificate can be used to sign any = location information. Thus, signing=0D=0Ais only meaningful if the signer i= s known and accountable.=0D=0A=0D=0AAs Steve Bellovin has put it: "A gener= al-purpose CA will protect you=0D=0Afrom anyone=0D=0Athat they won't take m= oney from".=0D=0A=0D=0A=0D=0A>Now, it may well be that the number of signer= s is lower or more easily=0D=0Aknowable in one or the other case, but the p= rinciple is the same. We=0D=0Ahave gone through the 'who can sign' before, = so I won't repeat that=0D=0Aparticular discussion.=0D=0A>=0D=0A=0D=0AWhat w= e still don't seem to have is common understanding of how the=0D=0Athreat m= odel has=0D=0Achanged. For the purposes of DDOS, folks understand very wel= l how the=0D=0Achange in=0D=0Aaccess models has changed the threat model: = in the previous system the=0D=0Aaccess network topology circumscribed who c= ould send calls to a PSAP,=0D=0Ain a way=0D=0Athat related fairly well to l= ocal geography; that is no longer true for=0D=0Athe new access=0D=0Anetwork= model, and the result is we now need to manage a different=0D=0Athreat=0D=0A= (as the pool of attackers is higher and the ddos risk higher).=20=0D=0A=0D=0A= But the same change has a consequence for trust relationships between=0D=0A= network providers and PSAP: where the number of network providers was=0D=0A= bounded, basically anyone can now put up an access network that has=0D=0Asu= fficient=0D=0Ato allow access to a VSP. Extending trust to the access netw= orks in=0D=0Athat model=0D=0Ais difficult, time-consuming, and either marke= t-limiting or so weak as=0D=0Ato be=0D=0Anearly useless. We need to manage= that change. Doing so by adding=0D=0Acryptographic mechanisms *does no go= od if they do not reflect the trust=0D=0Arelationships*.=20=0D=0A=0D=0ADefi= ne the trust relationships first, and it will get a lot easier to=0D=0Amake= the right=0D=0Achoice of mechanism. Choosing a mechanism and then forcing= the external=0D=0Aparties to tailor their relationships to the mechanism i= s procrustean=0D=0Aprogramming=0D=0Aof the worst sort, and it tends to leav= e the attackers lots of room to=0D=0Awiggle in.=0D=0A=0D=0A=09=09=09=09Ted=0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A------------------------------------= ------------------------------------------------------------=0D=0AThis mess= age is for the designated recipient only and may=0D=0Acontain privileged, p= roprietary, or otherwise private information. =20=0D=0AIf you have received= it in error, please notify the sender=0D=0Aimmediately and delete the orig= inal. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A--------= ---------------------------------------------------------------------------= -------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 08 01:18: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 1HPBx8-0008Lg-Dw; Thu, 08 Mar 2007 01:18:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPBx7-0008Lb-8h for geopriv@ietf.org; Thu, 08 Mar 2007 01:18:13 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPBx3-0005yv-T5 for geopriv@ietf.org; Thu, 08 Mar 2007 01:18:13 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 08 Mar 2007 01:16:06 -0500 id 01588431.45EFAA27.00007327 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: GEOPRIV WG From: Andrew Newton Date: Thu, 8 Mar 2007 01:18:00 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Geopriv] GEOPRIV and location signing patent (applications) X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Links to the relevant patent applications are here: 20060161967 http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=% 2Fnetahtml%2FPTO%2Fsearch- adv.html&r=2&p=1&f=G&l=50&d=PG01&S1=Winterbottom.IN.&OS=IN/ Winterbottom&RS=IN/Winterbottom or http://tinyurl.com/ysrppe 20050190892 http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=% 2Fnetahtml%2FPTO%2Fsearch- adv.html&r=161&p=4&f=G&l=50&d=PG01&S1=Dawson.IN.&OS=IN/Dawson&RS=IN/ Dawson or http://tinyurl.com/2frxrh 20060135177 http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=% 2Fnetahtml%2FPTO%2Fsearch- adv.html&r=4&p=1&f=G&l=50&d=PG01&S1=Winterbottom.IN.&OS=IN/ Winterbottom&RS=IN/Winterbottom or http://tinyurl.com/yrryez Also be advised of this disclosure: http://www.ietf.org/ietf/IPR/nortel-ipr-draft-ietf-geopriv-pres.txt -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 08 02:39:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPDDB-0001rj-1z; Thu, 08 Mar 2007 02:38:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPDD9-0001re-J2 for geopriv@ietf.org; Thu, 08 Mar 2007 02:38:51 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPDD8-0007wH-8q for geopriv@ietf.org; Thu, 08 Mar 2007 02:38:51 -0500 X-SEF-Processed: 5_0_0_910__2007_03_08_01_44_43 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); Thu, 08 Mar 2007 01:44:42 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 01:38:49 -0600 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: [Geopriv] GEOPRIV and location signing patent (applications) Date: Thu, 8 Mar 2007 01:38:47 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] GEOPRIV and location signing patent (applications) Thread-Index: AcdhSaYxdB6Qmq1cTmykC4WVe7IVdAACh5MQ From: "Dawson, Martin" To: "Andrew Newton" , "GEOPRIV WG" X-OriginalArrivalTime: 08 Mar 2007 07:38:49.0485 (UTC) FILETIME=[CFCD8BD0:01C76154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Andy,=0D=0A=0D=0AYour tinyurl reference for 20050190892 appears to point to= an invention=0D=0Arelated to data access management on a SAN. The only com= mon thread is=0D=0Athat one of the inventor's names is Dawson. It's apparen= t that you've=0D=0Asearch for patents by Dawson and Winterbottom - despite = what the subject=0D=0Aof the email may imply.=0D=0A=0D=0AI think this has g= one beyond a discussion about IPR encumbrance on=0D=0Alocation signing and = is probably something I need to pursue through=0D=0Aother avenues.=0D=0A=0D= =0AFor the benefit of others, I'll also state 20050190892 does not cover=0D= =0Alocation signing. I don't know about whatever it is that the Nortel=0D=0A= letter refers to but I'll hazard a guess that it isn't about location=0D=0A= signing either.=0D=0A=0D=0ARegards,=0D=0AMartin=0D=0A=0D=0A-----Original Me= ssage-----=0D=0AFrom: Andrew Newton [mailto:andy@hxr.us]=20=0D=0ASent: Thur= sday, 8 March 2007 5:18 PM=0D=0ATo: GEOPRIV WG=0D=0ASubject: [Geopriv] GEOP= RIV and location signing patent (applications)=0D=0A=0D=0ALinks to the rele= vant patent applications are here:=0D=0A=0D=0A20060161967=0D=0Ahttp://appft= 1.uspto.gov/netacgi/nph-Parser=3FSect1=3DPTO2&Sect2=3DHITOFF&u=3D%=20=0D=0A= 2Fnetahtml%2FPTO%2Fsearch-=20=0D=0Aadv.html&r=3D2&p=3D1&f=3DG&l=3D50&d=3DPG= 01&S1=3DWinterbottom.IN.&OS=3DIN/=20=0D=0AWinterbottom&RS=3DIN/Winterbottom=0D= =0A=0D=0Aor=0D=0A=0D=0Ahttp://tinyurl.com/ysrppe=0D=0A=0D=0A20050190892=0D=0A= http://appft1.uspto.gov/netacgi/nph-Parser=3FSect1=3DPTO2&Sect2=3DHITOFF&u=3D= %=20=0D=0A2Fnetahtml%2FPTO%2Fsearch-=20=0D=0Aadv.html&r=3D161&p=3D4&f=3DG&l= =3D50&d=3DPG01&S1=3DDawson.IN.&OS=3DIN/Dawson&RS=3DIN/=20=0D=0ADawson=0D=0A=0D= =0Aor=0D=0A=0D=0Ahttp://tinyurl.com/2frxrh=0D=0A=0D=0A20060135177=0D=0Ahttp= ://appft1.uspto.gov/netacgi/nph-Parser=3FSect1=3DPTO2&Sect2=3DHITOFF&u=3D% =0D= =0A2Fnetahtml%2FPTO%2Fsearch-=20=0D=0Aadv.html&r=3D4&p=3D1&f=3DG&l=3D50&d=3D= PG01&S1=3DWinterbottom.IN.&OS=3DIN/=20=0D=0AWinterbottom&RS=3DIN/Winterbott= om=0D=0A=0D=0Aor=0D=0A=0D=0Ahttp://tinyurl.com/yrryez=0D=0A=0D=0A=0D=0AAlso= be advised of this disclosure:=0D=0Ahttp://www.ietf.org/ietf/IPR/nortel-ip= r-draft-ietf-geopriv-pres.txt=0D=0A=0D=0A-andy=0D=0A=0D=0A_________________= ______________________________=0D=0AGeopriv mailing list=0D=0AGeopriv@ietf.= org=0D=0Ahttps://www1.ietf.org/mailman/listinfo/geopriv=0D=0A=0D=0A--------= ---------------------------------------------------------------------------= -------------=0D=0AThis message is for the designated recipient only and ma= y=0D=0Acontain privileged, proprietary, or otherwise private information. =0D= =0AIf you have received it in error, please notify the sender=0D=0Aimmediat= ely and delete the original. Any unauthorized use of=0D=0Athis email is pr= ohibited.=0D=0A------------------------------------------------------------= ------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 08 07:51:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPI5k-0004iw-CX; Thu, 08 Mar 2007 07:51:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPI5i-0004hM-IV for geopriv@ietf.org; Thu, 08 Mar 2007 07:51:30 -0500 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPI5h-000152-Bw for geopriv@ietf.org; Thu, 08 Mar 2007 07:51:30 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 08 Mar 2007 07:49:24 -0500 id 0158801C.45F00654.00004C83 In-Reply-To: References: 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: [Geopriv] GEOPRIV and location signing patent (applications) Date: Thu, 8 Mar 2007 07:51:19 -0500 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org On Mar 8, 2007, at 2:38 AM, Dawson, Martin wrote: > Your tinyurl reference for 20050190892 appears to point to an > invention > related to data access management on a SAN. The only common thread is > that one of the inventor's names is Dawson. It's apparent that you've > search for patents by Dawson and Winterbottom - despite what the > subject > of the email may imply. I'm not an expert on navigating that patent websites, so I have to resort to parlor tricks. The application numbers easily come up via Google on a European patent summary site listing the title and inventors. However, the actual patent (application) was not available. Using the summary information, I searched the USPTO to get to the actual patent applications. I can't figure out how to get the USPTO to search by the application numbers (help is welcomed). Nothing nefarious. I don't know why tinyurl doesn't get it right, but perhaps the whole long URL works. 20050190892 is entitled "Determining the geographical location from which an emergency call originates in a packet-based communications network" with inventors Dawson, Martin C.; (West Wollongong, AU) ; Lewis, Mark; (Aurora, IL) ; Broda, Maciej; (Ottawa, CA). Even if you are not the Martin Dawson on the application, the title implies that it is relevant to the current discussion in GEOPRIV and ECRIT. > For the benefit of others, I'll also state 20050190892 does not cover > location signing. I don't know about whatever it is that the Nortel > letter refers to but I'll hazard a guess that it isn't about location > signing either. No, but 20050190892 does seem relevant to the primary use case on location signing. The Nortel disclosure is about GEOPRIV and not location signing specifically, hence the "GEOPRIV" part of the subject title. -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 08 09:02: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 1HPJBg-00085m-PC; Thu, 08 Mar 2007 09:01:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJBf-00085h-L1 for geopriv@ietf.org; Thu, 08 Mar 2007 09:01:43 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPJBe-0001RV-Az for geopriv@ietf.org; Thu, 08 Mar 2007 09:01:43 -0500 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l28E1YD7006390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 8 Mar 2007 09:01:36 -0500 (EST) In-Reply-To: <66DEE6CF-7DE9-4848-A2CF-A88A8971FD68@hxr.us> References: <09D112E7-77E9-4FDC-B1C0-F14BB8B62E33@cs.columbia.edu> <66DEE6CF-7DE9-4848-A2CF-A88A8971FD68@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <8950D8B0-62EF-4796-B816-3C0AAC9C8DAB@cs.columbia.edu> From: Henning Schulzrinne Subject: Re: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Thu, 8 Mar 2007 09:02:08 -0500 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.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: GEOPRIV , "Dawson, Martin" X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1233952288==" Errors-To: geopriv-bounces@ietf.org --===============1233952288== Content-Type: multipart/alternative; boundary=Apple-Mail-2--365683590 --Apple-Mail-2--365683590 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed All I meant to say is that regardless of whether the LO is signed, the caller ID is signed or the LIS identity is verified via some reference mechanism, you will need an "accreditation" mechanism, i.e., a mechanism where an entity approved by the local authorities restricts who can sign. The signature or TLS mechanics are the easy part; the logistical and political arrangements are probably beyond the expertise of the IETF and likely highly dependent on the jurisdiction, given that they have obvious intersections with telecom competition, privacy laws and a host of other non-technical issues. On Mar 7, 2007, at 11:38 PM, Andrew Newton wrote: > > On Mar 7, 2007, at 9:00 PM, Henning Schulzrinne wrote: > >> As a side note, the 'accredited' thing is a red herring, either >> way. Signed location information is only meaningful if the >> location signer is 'accredited', i.e., known to be reputable, to >> the PSAP. After all, anybody, with a stolen credit card if >> necessary, can buy a certificate, based solely on possession of a >> domain name, from reputable CAs. That certificate can be used to >> sign any location information. Thus, signing is only meaningful if >> the signer is known and accountable. >> >> Now, it may well be that the number of signers is lower or more >> easily knowable in one or the other case, but the principle is the >> same. We have gone through the 'who can sign' before, so I won't >> repeat that particular discussion. > > As you have described it, I agree. However, what I've heard in > NENA meetings is that accreditation would be more than just a > public cert. I suspect that there are a lot more mechanics around > that than have been uncovered, and NENA will find out that they > will need to be their own CA -- which I do not think they intend. > > -andy --Apple-Mail-2--365683590 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
All I meant to say is that = regardless of whether the LO is signed, the caller ID is signed or the = LIS identity is verified via some reference mechanism, you will need an = "accreditation" mechanism, i.e., a mechanism where an entity approved by = the local authorities restricts who can sign. The signature or TLS = mechanics are the easy part; the logistical and political arrangements = are probably beyond the expertise of the IETF and likely highly = dependent on the jurisdiction, given that they have obvious = intersections with telecom competition, privacy laws and a host of other = non-technical issues.

On Mar 7, 2007, at 11:38 PM, = Andrew Newton wrote:

On Mar 7, 2007, at 9:00 PM, Henning = Schulzrinne wrote:

As a side note, the 'accredited' thing is a red = herring, either way. Signed location information is only meaningful if = the location signer is 'accredited', i.e., known to be reputable, to the = PSAP. After all, anybody, with a stolen credit card if necessary, can = buy a certificate, based solely on possession of a domain name, from = reputable CAs. That certificate can be used to sign any location = information. Thus, signing is only meaningful if the signer is known and = accountable.

Now, it may well be that the number of signers is = lower or more easily knowable in one or the other case, but the = principle is the same. We have gone through the 'who can sign' before, = so I won't repeat that particular discussion.
=

As you have described it, I agree.=A0 = However, what I've heard in NENA meetings is that accreditation would be = more than just a public cert.=A0 I suspect that there are a lot more = mechanics around that than have been uncovered, and NENA will find out = that they will need to be their own CA -- which I do not think they = intend.

-andy

= --Apple-Mail-2--365683590-- --===============1233952288== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1233952288==-- From geopriv-bounces@ietf.org Thu Mar 08 09:07:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJGr-0003WH-RA; Thu, 08 Mar 2007 09:07:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJGq-0003WC-O5 for geopriv@ietf.org; Thu, 08 Mar 2007 09:07:04 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPJGp-0002Kc-6y for geopriv@ietf.org; Thu, 08 Mar 2007 09:07:04 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HPJGg-0002f4-9c; Thu, 08 Mar 2007 08:06:54 -0600 From: "Brian Rosen" To: "'Andrew Newton'" , "'Henning Schulzrinne'" Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Thu, 8 Mar 2007 09:05:43 -0500 Message-ID: <09f301c7618b$0b57f290$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <66DEE6CF-7DE9-4848-A2CF-A88A8971FD68@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdhO7RYxah0rzccThCKuSL0wMMX+wATkB8A 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: 3b3709b7fb3320c78bd7b1555081f0fc Cc: 'GEOPRIV' , "'Dawson, Martin'" X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0598414263==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============0598414263== Content-Type: multipart/alternative; boundary="----=_NextPart_000_09F4_01C76161.2281EA90" This is a multi-part message in MIME format. ------=_NextPart_000_09F4_01C76161.2281EA90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The plan for a while is that NENA will create a Certificate Authority and issue certs to 9-1-1 Authorities. In the i2 plan, the CA also issues certs to the specialized service providers that assist in processing calls on the existing network, and they in turn could issue certs to carriers they supply services to. In the i3 (all-IP) environment, this has not yet been decided, but in general, a local 9-1-1 authority knows the local access network providers. Enterprise is a problem. I have some ideas, but they are just ideas. The i3 specs say calls can come from anyone, including the Internet. They ask for TLS connections, and I expect will recommend VPN or dedicated IP paths to what we call the Emergency Services IP network for carriers who deliver significant numbers of calls to the ESInet, probably at something like the state level. There will be certs involved in those. Brian _____ From: Andrew Newton [mailto:andy@hxr.us] Sent: Wednesday, March 07, 2007 11:39 PM To: Henning Schulzrinne Cc: GEOPRIV; Dawson, Martin Subject: Re: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) On Mar 7, 2007, at 9:00 PM, Henning Schulzrinne wrote: As a side note, the 'accredited' thing is a red herring, either way. Signed location information is only meaningful if the location signer is 'accredited', i.e., known to be reputable, to the PSAP. After all, anybody, with a stolen credit card if necessary, can buy a certificate, based solely on possession of a domain name, from reputable CAs. That certificate can be used to sign any location information. Thus, signing is only meaningful if the signer is known and accountable. Now, it may well be that the number of signers is lower or more easily knowable in one or the other case, but the principle is the same. We have gone through the 'who can sign' before, so I won't repeat that particular discussion. As you have described it, I agree. However, what I've heard in NENA meetings is that accreditation would be more than just a public cert. I suspect that there are a lot more mechanics around that than have been uncovered, and NENA will find out that they will need to be their own CA -- which I do not think they intend. -andy ------=_NextPart_000_09F4_01C76161.2281EA90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The plan for a while is that NENA = will create a Certificate Authority and issue certs to 9-1-1 Authorities. In = the i2 plan, the CA also issues certs to the specialized service providers that = assist in processing calls on the existing network, and they in turn could = issue certs to carriers they supply services to. In the i3 (all-IP) = environment, this has not yet been decided, but in general, a local 9-1-1 authority knows = the local access network providers. Enterprise is a problem. I have some ideas, but they are just = ideas.

The i3 specs say calls can come = from anyone, including the Internet. They ask for TLS connections, and = I expect will recommend VPN or dedicated IP paths to what we call the = Emergency Services IP network for carriers who deliver significant numbers of = calls to the ESInet, probably at something like the state level. There will = be certs involved in those.

Brian

From: = Andrew Newton [mailto:andy@hxr.us]
Sent: Wednesday, March = 07, 2007 11:39 PM
To: Henning = Schulzrinne
Cc: GEOPRIV; Dawson, = Martin
Subject: Re: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)<= /span>

On Mar 7, 2007, at 9:00 PM, Henning Schulzrinne = wrote:

As a side note, the = 'accredited' thing is a red herring, either way. Signed location information is only meaningful if the location signer is 'accredited', i.e., known to be = reputable, to the PSAP. After all, anybody, with a stolen credit card if necessary, = can buy a certificate, based solely on possession of a domain name, from = reputable CAs. That certificate can be used to sign any location information. = Thus, signing is only meaningful if the signer is known and = accountable.

<= /font>

Now, it may well be that = the number of signers is lower or more easily knowable in one or the other = case, but the principle is the same. We have gone through the 'who can sign' = before, so I won't repeat that particular = discussion.

As you have described it, I agree. However, what I've heard in = NENA meetings is that accreditation would be more than just a public cert. I = suspect that there are a lot more mechanics around that than have been = uncovered, and NENA will find out that they will need to be their own CA -- which I do = not think they intend.

-andy

------=_NextPart_000_09F4_01C76161.2281EA90-- --===============0598414263== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0598414263==-- From geopriv-bounces@ietf.org Thu Mar 08 09:29: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 1HPJcl-0002Sq-6s; Thu, 08 Mar 2007 09:29:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJck-0002Sl-SL for geopriv@ietf.org; Thu, 08 Mar 2007 09:29:42 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPJci-0005gQ-KY for geopriv@ietf.org; Thu, 08 Mar 2007 09:29:42 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 08 Mar 2007 09:27:38 -0500 id 0158844B.45F01D5A.0000609C In-Reply-To: References: Mime-Version: 1.0 Message-Id: <3DE10B63-4056-4392-9C08-AE224A2C99A0@hxr.us> From: Andrew Newton Subject: Re: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Thu, 8 Mar 2007 09:29:34 -0500 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: geopriv@ietf.org, Marc Linsner X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1724660552==" Errors-To: geopriv-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1724660552== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-24734-1173364063-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-24734-1173364063-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Mar 8, 2007, at 12:43 AM, Dawson, Martin wrote: >> Knowledge of prior art by a patent inventor is probably something > > No - you miss the point again. The patent office won't be interested > because the patent isn't about the thing you're suggesting it > represents > an encumbrance on. The prior art is not pertinent to the invention; > it's > pertinent to the topic that we've been discussing. I'm emphasising > that > they are two different things. Actually, if you have information on prior art related to these patents or any IPR relevant to GEOPRIV, it would be helpful if you share that information with the working group. -andy --=_zeke.ecotroph.net-24734-1173364063-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.54.2
On Mar 8, 2007, at 12:4= 3 AM, Dawson, Martin wrote:

=
Knowledge of prior art by a patent inventor is proba= bly something =A0
=

No - you miss the point again. The patent office won't be intereste= d

because the patent = isn't about the thing you're suggesting it represents

an encumbrance on. The prior art is not = pertinent to the invention; it's

pertinent to the topic that we've been discussing. I'm emphasi= sing that

they are tw= o different things.

Actually, if y= ou have information on prior art related to these patents or any IPR rele= vant to GEOPRIV, it would be helpful if you share that information with t= he working group.

<= DIV>-andy
--=_zeke.ecotroph.net-24734-1173364063-0001-2-- --===============1724660552== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1724660552==-- From geopriv-bounces@ietf.org Thu Mar 08 09:37: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 1HPJkb-0001MJ-JI; Thu, 08 Mar 2007 09:37:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJka-0001KQ-1r for geopriv@ietf.org; Thu, 08 Mar 2007 09:37:48 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPJkY-0006cI-Gu for geopriv@ietf.org; Thu, 08 Mar 2007 09:37:48 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-6.cisco.com with ESMTP; 08 Mar 2007 06:37:45 -0800 X-IronPort-AV: i="4.14,264,1170662400"; d="scan'208,217"; a="119177013:sNHT103118067" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l28Ebjrx011803; Thu, 8 Mar 2007 09:37:45 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l28EbfZR020682; Thu, 8 Mar 2007 14:37:41 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 09:37:41 -0500 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 09:37:40 -0500 From: "Marc Linsner" To: "'Brian Rosen'" Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Thu, 8 Mar 2007 09:37:40 -0500 Message-ID: <00ad01c7618f$53952790$230d0d0a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <09f301c7618b$0b57f290$640fa8c0@cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdhO7RYxah0rzccThCKuSL0wMMX+wATkB8AAADejZA= X-OriginalArrivalTime: 08 Mar 2007 14:37:40.0626 (UTC) FILETIME=[53215720:01C7618F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5119; t=1173364665; x=1174228665; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-L Odigitalsignatures) |Sender:=20 |To:=20=22'Brian=20Rosen'=22=20; bh=3514H0jyJL5BBpMovlX6VSnpq+xif7dtIGkKmNnpPtY=; b=vocQCcFTtL6IsAS30v3PusG4ajDIC/Sdot3Mj6cdO8pbn73PadGiaj4k1Uc5BHBxdsAzQkCm MnpYKyfhZRan8upQ7wSeRFjpAcwWlVzkAWTWMHBXA/A9TnpNrSqOYPDc; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0612788835==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============0612788835== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AE_01C76165.6ABF1F90" This is a multi-part message in MIME format. ------=_NextPart_000_00AE_01C76165.6ABF1F90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Brian, 'a local 9-1-1 authority knows the local access network providers' Do you actually believe this going forward? Yes, there is the assertion made about a limited set of physical access providers and I agree that NYC 9-1-1 authority probably knows about the <10 legacy providers. But a 10 second search for public Internet access in NYC produces nothing short of hundreds of providers. As you state, Enterprise is a problem. Are you considering the 100s of providers my search produced as Enterprise? -Marc- ------=_NextPart_000_00AE_01C76165.6ABF1F90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Brian,

'a local 9-1-1 authority = knows the=20 local access network providers'

Do you actually believe this going=20 forward?

Yes, there is the assertion made about a = limited set=20 of physical access providers and I agree that NYC 9-1-1 = authority=20 probably knows about the <10 legacy providers. But a = 10=20 second search for public Internet access in NYC produces nothing = short of=20 hundreds of providers. As you state, Enterprise is a = problem. Are=20 you considering the 100s of providers my search produced as=20 Enterprise?

-Marc-
------=_NextPart_000_00AE_01C76165.6ABF1F90-- --===============0612788835== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0612788835==-- From geopriv-bounces@ietf.org Thu Mar 08 09:39:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJmL-0006hX-TV; Thu, 08 Mar 2007 09:39:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJmK-0006hS-Lq for geopriv@ietf.org; Thu, 08 Mar 2007 09:39:36 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPJmJ-0006mS-Ab for geopriv@ietf.org; Thu, 08 Mar 2007 09:39:36 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HPJmA-0007s6-A8; Thu, 08 Mar 2007 08:39:26 -0600 From: "Brian Rosen" To: "'Ted Hardie'" , "'Henning Schulzrinne'" , "'Dawson, Martin'" Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Thu, 8 Mar 2007 09:39:30 -0500 Message-ID: <000b01c7618f$96fc6750$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcdhRHh1Q3vPY8ClTtKdPnT25BnODQASaOcg 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: 10d3e4e3c32e363f129e380e644649be Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org The one thing you miss in this discussion is that it's a LOCAL access provider providing location to a LOCAL PSAP. That is what makes this situation different from the general case. Yes, anyone can put up an access network, but it's always LOCAL to the PSAP. Also, we have provided a test capability. This will tell an end user that the location is somehow not pluperfect in advance of needing it. Again, I ask that instead of saying "no, no, no" you instead somehow say "no not that, use this". You acknowledge we have a problem. We need solutions. We'll acknowledge that it's not going to be great, because the world has changed and the threats have changed, but it should be possible to put sufficient controls in place to make the threat manageable. Brian > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Thursday, March 08, 2007 12:41 AM > To: Henning Schulzrinne; Dawson, Martin > Cc: GEOPRIV > Subject: Re:[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF- > LOdigitalsignatures) > > At 9:00 PM -0500 3/7/07, Henning Schulzrinne wrote: > >As a side note, the 'accredited' thing is a red herring, either way. > Signed location information is only meaningful if the location signer is > 'accredited', i.e., known to be reputable, to the PSAP. After all, > anybody, with a stolen credit card if necessary, can buy a certificate, > based solely on possession of a domain name, from reputable CAs. That > certificate can be used to sign any location information. Thus, signing is > only meaningful if the signer is known and accountable. > > As Steve Bellovin has put it: "A general-purpose CA will protect you from > anyone > that they won't take money from". > > > >Now, it may well be that the number of signers is lower or more easily > knowable in one or the other case, but the principle is the same. We have > gone through the 'who can sign' before, so I won't repeat that particular > discussion. > > > > What we still don't seem to have is common understanding of how the threat > model has > changed. For the purposes of DDOS, folks understand very well how the > change in > access models has changed the threat model: in the previous system the > access network topology circumscribed who could send calls to a PSAP, in > a way > that related fairly well to local geography; that is no longer true for > the new access > network model, and the result is we now need to manage a different threat > (as the pool of attackers is higher and the ddos risk higher). > > But the same change has a consequence for trust relationships between > network providers and PSAP: where the number of network providers was > bounded, basically anyone can now put up an access network that has > sufficient > to allow access to a VSP. Extending trust to the access networks in that > model > is difficult, time-consuming, and either market-limiting or so weak as to > be > nearly useless. We need to manage that change. Doing so by adding > cryptographic mechanisms *does no good if they do not reflect the trust > relationships*. > > Define the trust relationships first, and it will get a lot easier to make > the right > choice of mechanism. Choosing a mechanism and then forcing the external > parties to tailor their relationships to the mechanism is procrustean > programming > of the worst sort, and it tends to leave the attackers lots of room to > wiggle in. > > Ted > > > > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 08 09:43:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJpi-0007sF-E9; Thu, 08 Mar 2007 09:43:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPJpg-0007pg-IV for geopriv@ietf.org; Thu, 08 Mar 2007 09:43:04 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPJpf-0007CY-2X for geopriv@ietf.org; Thu, 08 Mar 2007 09:43:04 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HPJpW-00012x-DU; Thu, 08 Mar 2007 08:42:54 -0600 From: "Brian Rosen" To: "'Dawson, Martin'" , "'GEOPRIV'" Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Thu, 8 Mar 2007 09:42:59 -0500 Message-ID: <000f01c76190$13094cf0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcdhRGZu6PrQQf7aT+GaJ+AmQb9slAAAOtHgABKiiiA= 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: 93e7fb8fef2e780414389440f367c879 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I think the key word below is "public" in the phrase "public access infrastructure". The reality of the Internet is that not all access is public. That limits what we can do. It's still local. That helps a lot. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Thursday, March 08, 2007 1:04 AM > To: GEOPRIV > Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF- > LOdigitalsignatures) > > I'd like to challenge the following premise: > > "... where the number of network providers was > bounded, basically anyone can now put up an access network that has > sufficient to allow access to a VSP." > > In fact, the number of physical public access infrastructure providers > is comparable for Internet access as it is for PSTN, including cellular. > Until somebody invents and deploys subspace internet access technology, > the same constraint of geographic co-location applies just as it did for > the PSTN. > > (if this degenerates into the Pringle can debate again, then I'd refer > people to the NENA archives) > > Including ISPs certainly blows the number out but there is no strict > requirement for them to be included in the trust model - any more than > there is for the PSAP to know that a cellular call that appears to come > from the Verizon network is really one coming from a subscriber of any > one of a squillion MVNOs - MVNOs who don't actually own their own access > infrastructure. > > As long as the location is signed by a trusted public access > infrastructure provider then dependability is established. The > infrastructure operator has the audit records that show who the actual > ISP for a given location was. The recent liaison document on location > acquisition protocols that came from ESIF described this relationship > model between ISPs and infrastructure providers. It's a recommended > read. > > If we wanted to extend the PIDF-LO to include a chain of provider > identities so the location recipient had direct access to a signed > record of provider identities then that's certainly a good option to > discuss. > > Cheers, > Martin > > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Thursday, 8 March 2007 4:41 PM > To: Henning Schulzrinne; Dawson, Martin > Cc: GEOPRIV > Subject: Re: > [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) > > At 9:00 PM -0500 3/7/07, Henning Schulzrinne wrote: > >As a side note, the 'accredited' thing is a red herring, either way. > Signed location information is only meaningful if the location signer is > 'accredited', i.e., known to be reputable, to the PSAP. After all, > anybody, with a stolen credit card if necessary, can buy a certificate, > based solely on possession of a domain name, from reputable CAs. That > certificate can be used to sign any location information. Thus, signing > is only meaningful if the signer is known and accountable. > > As Steve Bellovin has put it: "A general-purpose CA will protect you > from anyone > that they won't take money from". > > > >Now, it may well be that the number of signers is lower or more easily > knowable in one or the other case, but the principle is the same. We > have gone through the 'who can sign' before, so I won't repeat that > particular discussion. > > > > What we still don't seem to have is common understanding of how the > threat model has > changed. For the purposes of DDOS, folks understand very well how the > change in > access models has changed the threat model: in the previous system the > access network topology circumscribed who could send calls to a PSAP, > in a way > that related fairly well to local geography; that is no longer true for > the new access > network model, and the result is we now need to manage a different > threat > (as the pool of attackers is higher and the ddos risk higher). > > But the same change has a consequence for trust relationships between > network providers and PSAP: where the number of network providers was > bounded, basically anyone can now put up an access network that has > sufficient > to allow access to a VSP. Extending trust to the access networks in > that model > is difficult, time-consuming, and either market-limiting or so weak as > to be > nearly useless. We need to manage that change. Doing so by adding > cryptographic mechanisms *does no good if they do not reflect the trust > relationships*. > > Define the trust relationships first, and it will get a lot easier to > make the right > choice of mechanism. Choosing a mechanism and then forcing the external > parties to tailor their relationships to the mechanism is procrustean > programming > of the worst sort, and it tends to leave the attackers lots of room to > wiggle in. > > Ted > > > > > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 08 09:54: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 1HPK0J-0007Er-Fr; Thu, 08 Mar 2007 09:54:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPK0H-0007El-Th for geopriv@ietf.org; Thu, 08 Mar 2007 09:54:01 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPK0G-0000Ym-Fe for geopriv@ietf.org; Thu, 08 Mar 2007 09:54:01 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HPK07-0003Bl-Hz; Thu, 08 Mar 2007 08:53:51 -0600 From: "Brian Rosen" To: "'Marc Linsner'" Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Thu, 8 Mar 2007 09:53:56 -0500 Message-ID: <001501c76191$9ac76720$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <00ad01c7618f$53952790$230d0d0a@amer.cisco.com> Thread-Index: AcdhO7RYxah0rzccThCKuSL0wMMX+wATkB8AAADejZAAAKw2sA== 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: f60fbf3dbcaca652b6d10036f0630412 Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0005490321==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============0005490321== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C76167.B1F15F20" This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C76167.B1F15F20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We're going to require ALL access providers to provide location. ALL of them. It's not unreasonable to ask them to get a cert from the local 9-1-1 authority (or some contractor they appoint) as part of that obligation. We probably are going to have regulation to make "ALL" work. Getting the cert can be part of that. There will be extenuating circumstances. They will create exploitable holes. I think we can manage that reasonably well, but some threat will remain. Brian. _____ From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Thursday, March 08, 2007 9:38 AM To: 'Brian Rosen' Cc: 'GEOPRIV' Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Brian, 'a local 9-1-1 authority knows the local access network providers' Do you actually believe this going forward? Yes, there is the assertion made about a limited set of physical access providers and I agree that NYC 9-1-1 authority probably knows about the <10 legacy providers. But a 10 second search for public Internet access in NYC produces nothing short of hundreds of providers. As you state, Enterprise is a problem. Are you considering the 100s of providers my search produced as Enterprise? -Marc- ------=_NextPart_000_0016_01C76167.B1F15F20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We’re going to require ALL = access providers to provide location. ALL of them. It’s not unreasonable to ask them to get a cert from the local 9-1-1 authority = (or some contractor they appoint) as part of that obligation. We probably = are going to have regulation to make “ALL” work. Getting = the cert can be part of that. There will be extenuating circumstances. = They will create exploitable holes. I think we can manage that = reasonably well, but some threat will remain.

Brian.

From: Marc = Linsner [mailto:mlinsner@cisco.com]
Sent: Thursday, March 08, = 2007 9:38 AM
To: 'Brian Rosen'
Cc: 'GEOPRIV'
Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)<= /span>

Brian,

'a local 9-1-1 authority knows the = local access network providers'

Do you actually believe this going forward?

Yes, there is the assertion = made about a limited set of physical access providers and I agree that NYC 9-1-1 authority probably knows about the <10 legacy providers. But a 10 second search for public Internet = access in NYC produces nothing short of hundreds of providers. As you state, = Enterprise is = a problem. Are you considering the 100s of providers my search = produced as Enterprise?

-Marc-

------=_NextPart_000_0016_01C76167.B1F15F20-- --===============0005490321== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0005490321==-- From geopriv-bounces@ietf.org Thu Mar 08 10:41: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 1HPKk1-0000R8-H6; Thu, 08 Mar 2007 10:41:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPKjz-0000Qf-La for geopriv@ietf.org; Thu, 08 Mar 2007 10:41:15 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPKjx-0007Uo-0F for geopriv@ietf.org; Thu, 08 Mar 2007 10:41:15 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l28Ff2e20195; Thu, 8 Mar 2007 15:41:03 GMT Received: from [47.130.25.129] ([47.130.25.129] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 10:40:47 -0500 Message-ID: <45F02E5B.2040506@nortel.com> Date: Thu, 08 Mar 2007 10:40:11 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) References: <001501c76191$9ac76720$640fa8c0@cis.neustar.com> In-Reply-To: <001501c76191$9ac76720$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2007 15:40:47.0806 (UTC) FILETIME=[247725E0:01C76198] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: GEOPRIV , Marc Linsner X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I think what this thread is leading to is that: -- national/regional regulatory authorities will impose regulations that imply a particular technical means of defence against fraudulent calls -- that means national/regional rather than IETF standardization of these technical means -- the role of the IETF is limited to provision of the toolkit and making sure they don't get in the way. Brian Rosen wrote: > We're going to require ALL access providers to provide location. ALL of > them. It's not unreasonable to ask them to get a cert from the local 9-1-1 > authority (or some contractor they appoint) as part of that obligation. We > probably are going to have regulation to make "ALL" work. Getting the cert > can be part of that. There will be extenuating circumstances. They will > create exploitable holes. I think we can manage that reasonably well, but > some threat will remain. > > > > Brian. > > > > > > > > ________________________________ > > From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Thursday, March 08, 2007 > 9:38 AM To: 'Brian Rosen' Cc: 'GEOPRIV' Subject: RE: > [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) > > > > Brian, > > > > 'a local 9-1-1 authority knows the local access network providers' > > > > Do you actually believe this going forward? > > > > Yes, there is the assertion made about a limited set of physical access > providers and I agree that NYC 9-1-1 authority probably knows about the <10 > legacy providers. But a 10 second search for public Internet access in NYC > produces nothing short of hundreds of providers. As you state, Enterprise is > a problem. Are you considering the 100s of providers my search produced as > Enterprise? > > > > -Marc- > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 08 10:59: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 1HPL1B-0007jU-Cn; Thu, 08 Mar 2007 10:59:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPL19-0007j9-MY for geopriv@ietf.org; Thu, 08 Mar 2007 10:59:00 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPL15-0002ZX-QT for geopriv@ietf.org; Thu, 08 Mar 2007 10:58:59 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 8B8054CEC5; Thu, 8 Mar 2007 16:58:42 +0100 (CET) Date: Thu, 8 Mar 2007 16:58:42 +0100 From: Otmar Lendl To: geopriv@ietf.org Subject: Re: [Geopriv] Draft agenda for IETF 68 Message-ID: <20070308155842.GA27137@nic.at> Mail-Followup-To: Otmar Lendl , geopriv@ietf.org References: <7C322386-4BC3-4E9F-9D45-3C8C5F2921E2@hxr.us> <45EE98B3.6010402@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45EE98B3.6010402@gmx.net> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org On 2007/03/07 11:03, Hannes Tschofenig wrote: > Hi Andy, > > we should spend more time on the Geopriv L7 work rather than spending a > long time on new topics. I second the desire to spend more time on the L7 work. More than just devoting agenda-time on that issue, I'd like to ask the chairs what kind of decisions we want to reach in Prague. Will we finish the requirements? Adopt one proposal as WG item? In other words: what do we want to have achieved when we travel back from Prague? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 08 15:09: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 1HPOuz-0003f1-DV; Thu, 08 Mar 2007 15:08:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPOux-0003em-MD for geopriv@ietf.org; Thu, 08 Mar 2007 15:08:51 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPOuw-0000WS-9x for geopriv@ietf.org; Thu, 08 Mar 2007 15:08:51 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l28K8fAL025850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Mar 2007 12:08:42 -0800 Received: from [71.204.158.100] (vpn-10-50-16-14.qualcomm.com [10.50.16.14]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l28K8cun030993; Thu, 8 Mar 2007 12:08:40 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <001501c76191$9ac76720$640fa8c0@cis.neustar.com> References: <001501c76191$9ac76720$640fa8c0@cis.neustar.com> Date: Thu, 8 Mar 2007 12:08:37 -0800 To: "Brian Rosen" , "'Marc Linsner'" From: Ted Hardie Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org At 9:53 AM -0500 3/8/07, Brian Rosen wrote: >We're going to require ALL access providers to provide location. ALL of them. It's not unreasonable to ask them to get a cert from the local 9-1-1 authority (or some contractor they appoint) as part of that obligation. I would appreciate your stating who "we" is in the sentence above. I assume it is someone with the regulatory power in a specific jurisdiction mentioned below, but I'd rather have a clear statement as to whom. >We probably are going to have regulation to make "ALL" work. Getting the cert can be part of that. There will be extenuating circumstances. They will create exploitable holes. I think we can manage that reasonably well, but some threat will remain. > >Brian. Martin doesn't believe that I can stand up an access network sufficient to reach a VSP, and I think he believes that my upstream is the "real" network. Do you agree, and would it be the upstream of the enterprise, SOHO, and home networks who gets this requirement? This is important because it changes how the trust model works--it means the PSAP has to have relationships with transit networks, rather than access networks, and it will have regulatory power to extend that trust from the transit network to the access network (presumably through the customer relationship, by presuming that involves payment even if the access network provides free service). Does that fit the model, as you understand it? Note that multi-homing the enterprise and other access networks is both burgeoning business and of serious concern to other parts of the IETF. Each one of those that gets PI space and starts making its own BGP announcement becomes something like a transit upstream, but isn't exactly the same. Where do they fit? Does taking on additional upstream turn you into someone who has to meet this requirement, or does it only occur if you carry prefixes originated by someone else? As Marc has noted, lots of enterprises may fall into this. An enterprise may have multiple campuses, with multiple upstream providers (either per campus, in a mesh, or with a star topology with multiple upstreams from the center). Getting them to provide location is one thing. Getting them to associate the topology, location, and the right signing authority for a specific 911 authority is far more complex. I realize that this comes across as failing your "tell us what to do instead" test, but I'm trying to get across that "make it act like it used to" is a requirement that creates very serious burdens. If the requirement is to allow calls from anyone (and that is the requirement, as I understand you), there may be a fundamental trade-off between meeting that requirement and the security concerns here. Ted _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 09 04:19:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbGA-00056z-Fd; Fri, 09 Mar 2007 04:19:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPRnr-0006A6-5D for geopriv@ietf.org; Thu, 08 Mar 2007 18:13:43 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPRnp-0006JU-Gs for geopriv@ietf.org; Thu, 08 Mar 2007 18:13:42 -0500 X-SEF-Processed: 5_0_0_910__2007_03_08_17_19_32 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); Thu, 08 Mar 2007 17:19:32 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 17:13:37 -0600 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: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Thu, 8 Mar 2007 17:13:35 -0600 Message-ID: In-Reply-To: <45F02E5B.2040506@nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Thread-Index: AcdhmEj46EaqGB4+Q5WoYcv/YgycjgAPl9OA From: "Dawson, Martin" To: "Tom-PT Taylor" , "Brian Rosen" X-OriginalArrivalTime: 08 Mar 2007 23:13:37.0506 (UTC) FILETIME=[66DE5C20:01C761D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: GEOPRIV , Marc Linsner X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hear hear.=0D=0A=0D=0AThere are continually arguments about what we are req= uiring the=0D=0Aimplementors to implement. Despite the undoubted brain powe= r in the=0D=0Aroom, it's not going to be possible to assess the needs and=0D= =0Aapplicability for every emergency jurisdiction in the world and come up=0D= =0Awith an exact fit for everyone. Not every jurisdiction may require=0D=0A= location from access operators, not every one of those may require it be=0D= =0Asigned, and those that do will establish their own organizations and=0D=0A= processes around certificate management.=20=0D=0A=0D=0AThe toolkit to build= to their regional policies is exactly what we are=0D=0Agiving them.=0D=0A=0D= =0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Tom= -PT Taylor [mailto:taylor@nortel.com]=20=0D=0ASent: Friday, 9 March 2007 2:= 40 AM=0D=0ATo: Brian Rosen=0D=0ACc: GEOPRIV; Marc Linsner=0D=0ASubject: Re:=0D= =0A[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)=0D= =0A=0D=0AI think what this thread is leading to is that:=0D=0A=0D=0A-- nati= onal/regional regulatory authorities will impose regulations that=0D=0Aimpl= y a=20=0D=0Aparticular technical means of defence against fraudulent calls=0D= =0A=0D=0A-- that means national/regional rather than IETF standardization o= f=0D=0Athese=20=0D=0Atechnical means=0D=0A=0D=0A-- the role of the IETF is = limited to provision of the toolkit and=0D=0Amaking sure=20=0D=0Athey don't= get in the way.=0D=0A=0D=0ABrian Rosen wrote:=0D=0A> We're going to requir= e ALL access providers to provide location. ALL=0D=0Aof=0D=0A> them. It's= not unreasonable to ask them to get a cert from the local=0D=0A9-1-1=0D=0A= > authority (or some contractor they appoint) as part of that=0D=0Aobligati= on. We=0D=0A> probably are going to have regulation to make "ALL" work. G= etting the=0D=0Acert=0D=0A> can be part of that. There will be extenuating= circumstances. They=0D=0Awill=0D=0A> create exploitable holes. I think w= e can manage that reasonably well,=0D=0Abut=0D=0A> some threat will remain.=0D= =0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> Brian.=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A= >=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> ________________________________=0D= =0A>=20=0D=0A> From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Thursda= y, March=0D=0A08, 2007=0D=0A> 9:38 AM To: 'Brian Rosen' Cc: 'GEOPRIV' Subje= ct: RE:=0D=0A>=0D=0A[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOd= igitalsignatures)=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> Brian,=0D=0A>=20=0D=0A= >=20=0D=0A>=20=0D=0A> 'a local 9-1-1 authority knows the local access netwo= rk providers'=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> Do you actually believe = this going forward=3F=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> Yes, there is th= e assertion made about a limited set of physical=0D=0Aaccess=0D=0A> provide= rs and I agree that NYC 9-1-1 authority probably knows about=0D=0Athe <10=0D= =0A> legacy providers. But a 10 second search for public Internet access=0D= =0Ain NYC=0D=0A> produces nothing short of hundreds of providers. As you s= tate,=0D=0AEnterprise is=0D=0A> a problem. Are you considering the 100s of= providers my search=0D=0Aproduced as=0D=0A> Enterprise=3F=0D=0A>=20=0D=0A>= =20=0D=0A>=20=0D=0A> -Marc-=0D=0A>=20=0D=0A>=20=0D=0A=0D=0A________________= _______________________________=0D=0AGeopriv mailing list=0D=0AGeopriv@ietf= =2Eorg=0D=0Ahttps://www1.ietf.org/mailman/listinfo/geopriv=0D=0A=0D=0A-----= ---------------------------------------------------------------------------= ----------------=0D=0AThis message is for the designated recipient only and= may=0D=0Acontain privileged, proprietary, or otherwise private information= =2E =20=0D=0AIf you have received it in error, please notify the sender=0D=0A= immediately and delete the original. Any unauthorized use of=0D=0Athis ema= il is prohibited.=0D=0A----------------------------------------------------= --------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 09 04:19: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 1HPbGY-000605-UN; Fri, 09 Mar 2007 04:19:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPS9U-0001qh-Vy for geopriv@ietf.org; Thu, 08 Mar 2007 18:36:04 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPS9S-0006Zy-JW for geopriv@ietf.org; Thu, 08 Mar 2007 18:36:04 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HPS97-0006FB-Sf; Thu, 08 Mar 2007 17:35:42 -0600 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Tom-PT Taylor'" Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Thu, 8 Mar 2007 18:35:52 -0500 Message-ID: <035a01c761da$8474cb40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcdhmEj46EaqGB4+Q5WoYcv/YgycjgAPl9OAAADczeA= 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: 36b1f8810cb91289d885dc8ab4fc8172 Cc: 'GEOPRIV' , 'Marc Linsner' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Well, no, I don't think so. If I look at the skill set available in, say, NENA, they can't make good technical judgments on this level of security mechanisms. The IETF really has the right expertise to do this, and it should. It may not specify how to, for example, establish a PKI. It should specify the protocols and crypto mechanisms. We could have options if the rationale for choosing was explained. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Thursday, March 08, 2007 6:14 PM > To: Tom-PT Taylor; Brian Rosen > Cc: GEOPRIV; Marc Linsner > Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF- > LOdigitalsignatures) > > Hear hear. > > There are continually arguments about what we are requiring the > implementors to implement. Despite the undoubted brain power in the > room, it's not going to be possible to assess the needs and > applicability for every emergency jurisdiction in the world and come up > with an exact fit for everyone. Not every jurisdiction may require > location from access operators, not every one of those may require it be > signed, and those that do will establish their own organizations and > processes around certificate management. > > The toolkit to build to their regional policies is exactly what we are > giving them. > > Cheers, > Martin > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortel.com] > Sent: Friday, 9 March 2007 2:40 AM > To: Brian Rosen > Cc: GEOPRIV; Marc Linsner > Subject: Re: > [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) > > I think what this thread is leading to is that: > > -- national/regional regulatory authorities will impose regulations that > imply a > particular technical means of defence against fraudulent calls > > -- that means national/regional rather than IETF standardization of > these > technical means > > -- the role of the IETF is limited to provision of the toolkit and > making sure > they don't get in the way. > > Brian Rosen wrote: > > We're going to require ALL access providers to provide location. ALL > of > > them. It's not unreasonable to ask them to get a cert from the local > 9-1-1 > > authority (or some contractor they appoint) as part of that > obligation. We > > probably are going to have regulation to make "ALL" work. Getting the > cert > > can be part of that. There will be extenuating circumstances. They > will > > create exploitable holes. I think we can manage that reasonably well, > but > > some threat will remain. > > > > > > > > Brian. > > > > > > > > > > > > > > > > ________________________________ > > > > From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Thursday, March > 08, 2007 > > 9:38 AM To: 'Brian Rosen' Cc: 'GEOPRIV' Subject: RE: > > > [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) > > > > > > > > Brian, > > > > > > > > 'a local 9-1-1 authority knows the local access network providers' > > > > > > > > Do you actually believe this going forward? > > > > > > > > Yes, there is the assertion made about a limited set of physical > access > > providers and I agree that NYC 9-1-1 authority probably knows about > the <10 > > legacy providers. But a 10 second search for public Internet access > in NYC > > produces nothing short of hundreds of providers. As you state, > Enterprise is > > a problem. Are you considering the 100s of providers my search > produced as > > Enterprise? > > > > > > > > -Marc- > > > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 09 04:22: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 1HPbJB-0002Zf-Bl; Fri, 09 Mar 2007 04:22:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPU1y-0006jf-Ad for geopriv@ietf.org; Thu, 08 Mar 2007 20:36:26 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPU1w-0003Tv-V7 for geopriv@ietf.org; Thu, 08 Mar 2007 20:36:26 -0500 X-SEF-Processed: 5_0_0_910__2007_03_08_19_42_18 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, 08 Mar 2007 19:42:18 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 19:36:24 -0600 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: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Thu, 8 Mar 2007 19:36:21 -0600 Message-ID: In-Reply-To: <035a01c761da$8474cb40$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Thread-Index: AcdhmEj46EaqGB4+Q5WoYcv/YgycjgAPl9OAAADczeAABDxIMA== From: "Dawson, Martin" To: "Brian Rosen" , "Tom-PT Taylor" X-OriginalArrivalTime: 09 Mar 2007 01:36:24.0327 (UTC) FILETIME=[59178170:01C761EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: GEOPRIV , Marc Linsner X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I'm agreeing with you Brian. So - we provide the mechanisms with the=0D=0Ac= rypto set at state of the art etc. Then each jurisdiction gets to=0D=0Adeci= de whether signatures are appropriate to their environment.=0D=0A=0D=0AWe d= on't make a unilateral decision that signatures are not appropriate=0D=0Afo= r emergency service environments globally and then exclude that tool=0D=0Af= rom the kit.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Messag= e-----=0D=0AFrom: Brian Rosen [mailto:br@brianrosen.net]=20=0D=0ASent: Frid= ay, 9 March 2007 10:36 AM=0D=0ATo: Dawson, Martin; 'Tom-PT Taylor'=0D=0ACc:= 'GEOPRIV'; 'Marc Linsner'=0D=0ASubject: RE:=0D=0A[Geopriv]WGLCondraft-ietf= -geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)=0D=0A=0D=0AWell, no, I don'= t think so. If I look at the skill set available in,=0D=0Asay,=0D=0ANENA, = they can't make good technical judgments on this level of security=0D=0Amec= hanisms. The IETF really has the right expertise to do this, and it=0D=0As= hould.=0D=0A=0D=0AIt may not specify how to, for example, establish a PKI. = It should=0D=0Aspecify=0D=0Athe protocols and crypto mechanisms. We could= have options if the=0D=0Arationale=0D=0Afor choosing was explained.=0D=0A=0D= =0ABrian=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Dawson, Marti= n [mailto:Martin.Dawson@andrew.com]=0D=0A> Sent: Thursday, March 08, 2007 6= :14 PM=0D=0A> To: Tom-PT Taylor; Brian Rosen=0D=0A> Cc: GEOPRIV; Marc Linsn= er=0D=0A> Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-=0D= =0A> LOdigitalsignatures)=0D=0A>=20=0D=0A> Hear hear.=0D=0A>=20=0D=0A> Ther= e are continually arguments about what we are requiring the=0D=0A> implemen= tors to implement. Despite the undoubted brain power in the=0D=0A> room, it= 's not going to be possible to assess the needs and=0D=0A> applicability fo= r every emergency jurisdiction in the world and come=0D=0Aup=0D=0A> with an= exact fit for everyone. Not every jurisdiction may require=0D=0A> location= from access operators, not every one of those may require it=0D=0Abe=0D=0A= > signed, and those that do will establish their own organizations and=0D=0A= > processes around certificate management.=0D=0A>=20=0D=0A> The toolkit to = build to their regional policies is exactly what we are=0D=0A> giving them.=0D= =0A>=20=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=20=0D=0A> -----Original Message= -----=0D=0A> From: Tom-PT Taylor [mailto:taylor@nortel.com]=0D=0A> Sent: Fr= iday, 9 March 2007 2:40 AM=0D=0A> To: Brian Rosen=0D=0A> Cc: GEOPRIV; Marc = Linsner=0D=0A> Subject: Re:=0D=0A>=0D=0A[Geopriv]WGLCondraft-ietf-geopriv-l= 7-lcp-ps-00(PIDF-LOdigitalsignatures)=0D=0A>=20=0D=0A> I think what this th= read is leading to is that:=0D=0A>=20=0D=0A> -- national/regional regulator= y authorities will impose regulations=0D=0Athat=0D=0A> imply a=0D=0A> parti= cular technical means of defence against fraudulent calls=0D=0A>=20=0D=0A> = -- that means national/regional rather than IETF standardization of=0D=0A> = these=0D=0A> technical means=0D=0A>=20=0D=0A> -- the role of the IETF is li= mited to provision of the toolkit and=0D=0A> making sure=0D=0A> they don't = get in the way.=0D=0A>=20=0D=0A> Brian Rosen wrote:=0D=0A> > We're going to= require ALL access providers to provide location.=0D=0AALL=0D=0A> of=0D=0A= > > them. It's not unreasonable to ask them to get a cert from the=0D=0Alo= cal=0D=0A> 9-1-1=0D=0A> > authority (or some contractor they appoint) as pa= rt of that=0D=0A> obligation. We=0D=0A> > probably are going to have regul= ation to make "ALL" work. Getting=0D=0Athe=0D=0A> cert=0D=0A> > can be par= t of that. There will be extenuating circumstances. They=0D=0A> will=0D=0A= > > create exploitable holes. I think we can manage that reasonably=0D=0Aw= ell,=0D=0A> but=0D=0A> > some threat will remain.=0D=0A> >=0D=0A> >=0D=0A> = >=0D=0A> > Brian.=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A= > >=0D=0A> > ________________________________=0D=0A> >=0D=0A> > From: Marc = Linsner [mailto:mlinsner@cisco.com] Sent: Thursday, March=0D=0A> 08, 2007=0D= =0A> > 9:38 AM To: 'Brian Rosen' Cc: 'GEOPRIV' Subject: RE:=0D=0A> >=0D=0A>=0D= =0A[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)=0D= =0A> >=0D=0A> >=0D=0A> >=0D=0A> > Brian,=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> = > 'a local 9-1-1 authority knows the local access network providers'=0D=0A>= >=0D=0A> >=0D=0A> >=0D=0A> > Do you actually believe this going forward=3F=0D= =0A> >=0D=0A> >=0D=0A> >=0D=0A> > Yes, there is the assertion made about a = limited set of physical=0D=0A> access=0D=0A> > providers and I agree that N= YC 9-1-1 authority probably knows about=0D=0A> the <10=0D=0A> > legacy prov= iders. But a 10 second search for public Internet access=0D=0A> in NYC=0D=0A= > > produces nothing short of hundreds of providers. As you state,=0D=0A> = Enterprise is=0D=0A> > a problem. Are you considering the 100s of provider= s my search=0D=0A> produced as=0D=0A> > Enterprise=3F=0D=0A> >=0D=0A> >=0D=0A= > >=0D=0A> > -Marc-=0D=0A> >=0D=0A> >=0D=0A>=20=0D=0A> ____________________= ___________________________=0D=0A> Geopriv mailing list=0D=0A> Geopriv@ietf= =2Eorg=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A>=20=0D=0A= >=0D=0A--------------------------------------------------------------------= ----=0D=0A--=0D=0A> ----------------------=0D=0A> This message is for the d= esignated recipient only and may=0D=0A> contain privileged, proprietary, or= otherwise private information.=0D=0A> If you have received it in error, pl= ease notify the sender=0D=0A> immediately and delete the original. Any una= uthorized use of=0D=0A> this email is prohibited.=0D=0A>=0D=0A-------------= -----------------------------------------------------------=0D=0A--=0D=0A> = ----------------------=0D=0A> [mf2]=0D=0A=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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 09 04:25:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbLY-000060-Ig; Fri, 09 Mar 2007 04:25:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPVH5-0004Ze-3t for geopriv@ietf.org; Thu, 08 Mar 2007 21:56:07 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPVH4-00007P-LW for geopriv@ietf.org; Thu, 08 Mar 2007 21:56:07 -0500 X-SEF-Processed: 5_0_0_910__2007_03_08_21_01_59 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); Thu, 08 Mar 2007 21:01:59 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 20:56:06 -0600 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: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Date: Thu, 8 Mar 2007 20:56:04 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Thread-Index: AcdhvcF4dtP4TBD8QCSpHJSZxxtZzAALc+PA From: "Dawson, Martin" To: "Ted Hardie" , "Brian Rosen" , "Marc Linsner" X-OriginalArrivalTime: 09 Mar 2007 02:56:06.0223 (UTC) FILETIME=[7B52EDF0:01C761F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Ted,=0D=0A=0D=0AThis is a good opportunity to address the specifics of a= t least one=0D=0Apatent question that's been bandied about in the last day.=0D= =0A=0D=0AYour analysis is excellent and, yes, the question of transitive tr= ust=0D=0A*can* come up and you've homed in on the large and multi-site camp= us=0D=0Ascenarios that may lead to this issue.=0D=0A=0D=0AAgain - I'd refer= people to the ATIS document that looks at geo-point=0D=0Aand geo-distribut= ed LANs as different LIS environments. I believe the=0D=0Ascenarios can be = categorized in a manageable way - as opposed to=0D=0Athrowing up the hands = and saying it's all too complicated, let's just=0D=0Anot provide any locati= on dependability mechanism.=0D=0A=0D=0AAn Internet access point may be:=0D=0A=0D= =0A1. On a LAN of a constrained enough nature that the location determined=0D= =0Aby the infrastructure provider is of sufficient accuracy. This covers=0D= =0Adomestic broadband connections, coffee shop hotspots, and the majority=0D= =0Aof shop front enterprises - where the civic address associated with the=0D= =0Aservice is adequate.=0D=0A=0D=0A2. Part of a LAN that has an extensive g= eographical area *and* where it=0D=0Ais important that location be somethin= g more precise than the external=0D=0Aprovider would determine. This is ana= logous to the POTS requirement that=0D=0Aexists in at least six US states n= ow, where the owner of the premises is=0D=0Arequired to provide emergency c= all location within, for example, 400 sq=0D=0Afeet and to the right floor f= or the site.=0D=0A=0D=0A3. A combination of 1 and 2 where an enterprise is = actually multi-site=0D=0Aand each site connects by VPN over the public Inte= rnet.=0D=0A=0D=0A4. A combination of 1 and 2 where the enterprise owns its = own=0D=0Ainfrastructure across multiple sites - via leased dark fiber and s= imilar=0D=0Amechanisms that bypass local public Internet carriers.=0D=0A=0D= =0AFor (1) there is no additional trust issue. The carrier LIS is the=0D=0A= entity determining location and signing it.=0D=0A=0D=0AFor (2) there is a p= ossible issue. In this case a "campus" LIS is=0D=0Arequired that can determ= ine a more precise location than the carrier LIS=0D=0Ais able to. If a clie= nt device on this LAN asks for a signed location,=0D=0Athe campus LIS needs= a recognized certificate. Alternatively, and this=0D=0Aladies and gentleme= n is what the Nortel patent application US2006161967=0D=0Acovers, the devic= e could ask the campus LIS for a signed location, the=0D=0Acampus LIS could= determine the location, then the campus LIS could send=0D=0Aan assertion r= equest to the carrier LIS asking it to sign that location.=0D=0AThis requir= es an explicit transitive trust relationship from the device=0D=0Athrough t= he campus LIS to the carrier LIS with the result being a=0D=0Alocation dete= rmined and signed based on the trust relationship between=0D=0Athe campus L= IS operator and the carrier LIS operator.=0D=0A=0D=0AI have an email from B= rian Rosen from about three years ago saying "nope=0D=0Athis won't work". H= owever, I sense Brian's thinking has moved on a good=0D=0Adeal since then s= o perhaps he has a different opinion now. In any case,=0D=0Athe purpose was= to provide a mechanism whereby the certificate authority=0D=0Adid not have= to evaluate every enterprise with a large enough premises=0D=0Ato justify = requiring a certificate but, instead, place the=0D=0Aresponsibility on the = public carrier to provide the proxy-signature and=0D=0Aassertion service on= behalf of those enterprises.=0D=0A=0D=0AFor (3) the requirement is that ea= ch enterprise site use the local=0D=0Apublic carrier LIS before sending any= location information, for example,=0D=0Athrough the centralized SIP server= =2E Each site then becomes a particular=0D=0Acase of (1) or (2).=0D=0A=0D=0A= For (4) the problem is that there is no local carrier involved to vet=0D=0A= the location. We're talking about *big* enterprises here (and probably=0D=0A= decreasingly so since site interconnectivity via VPN on the public=0D=0AInt= ernet is an increasing trend). Examples are transnationals (GE, IBM=0D=0Afo= r example) or educational research or other government type networks.=0D=0A= The sites in these networks could get a local carrier connection just=0D=0A= for the purpose of obtaining signed location. Alternatively, these sorts=0D= =0Aof enterprises are big enough and ugly enough to warrant being issued=0D= =0Aand securely managing their own certificates. For truly global examples,=0D= =0AI suggest they would need to obtain certificates from each national=0D=0A= jurisdiction that they operate within and ensure they used the correct=0D=0A= one whenever they sign location - generally this would only mean that=0D=0A= the LIS in a particular national location would need the local=0D=0Ajurisdi= ction certificate.=0D=0A=0D=0AGoing back to the analogy mentioned in the de= scription of 2, scenario 4=0D=0Ahas had this issue for telephony VPNs for m= any years. Where all sites=0D=0Ashare a common PABX, emergency calls do not= work where the only public=0D=0APSTN access is via the central PABX trunks= =2E Location information, and=0D=0Arouting, ends up being compromised. For = large companies, the option was=0D=0Agenerally to have a local switch that = directed emergency calls via a=0D=0Alocal phone service. This is the equiva= lent to the option above, of=0D=0Ahaving a local Internet access for gettin= g local provider signed=0D=0Alocation. In the old days, and today, this anc= illary public service=0D=0Aconnection was/is typically used for backup anyw= ay.=0D=0A=0D=0ANote that "the number of upstream providers" is not an issue= - any given=0D=0Asite is only concerned with who the upstream provider at = that site is.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Messa= ge-----=0D=0AFrom: Ted Hardie [mailto:hardie@qualcomm.com]=20=0D=0ASent: Fr= iday, 9 March 2007 7:09 AM=0D=0ATo: Brian Rosen; 'Marc Linsner'=0D=0ACc: 'G= EOPRIV'=0D=0ASubject:=0D=0ARE:[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-0= 0(PIDF-LOdigitalsignatur=0D=0Aes)=0D=0A=0D=0AAt 9:53 AM -0500 3/8/07, Brian= Rosen wrote:=0D=0A>We're going to require ALL access providers to provide = location. ALL=0D=0Aof them. It's not unreasonable to ask them to get a ce= rt from the local=0D=0A9-1-1 authority (or some contractor they appoint) as= part of that=0D=0Aobligation. =20=0D=0A=0D=0AI would appreciate your stati= ng who "we" is in the sentence above. I=0D=0Aassume it=0D=0Ais someone wit= h the regulatory power in a specific jurisdiction=0D=0Amentioned below,=0D=0A= but I'd rather have a clear statement as to whom.=0D=0A=0D=0A>We probably a= re going to have regulation to make "ALL" work. Getting=0D=0Athe cert can = be part of that. There will be extenuating circumstances.=0D=0AThey will c= reate exploitable holes. I think we can manage that=0D=0Areasonably well, = but some threat will remain.=0D=0A>=20=0D=0A>Brian.=0D=0A=0D=0AMartin doesn= 't believe that I can stand up an access network sufficient=0D=0Ato reach=0D= =0Aa VSP, and I think he believes that my upstream is the "real" network.=0D= =0ADo you agree,=0D=0Aand would it be the upstream of the enterprise, SOHO,= and home networks=0D=0Awho=0D=0Agets this requirement=3F This is importan= t because it changes how the=0D=0Atrust=0D=0Amodel works--it means the PSAP= has to have relationships with transit=0D=0Anetworks, rather than access n= etworks, and it will have regulatory power=0D=0Ato extend that trust from t= he transit network to the access network=0D=0A(presumably=0D=0Athrough the = customer relationship, by presuming that involves payment=0D=0Aeven=0D=0Aif= the access network provides free service). Does that fit the model,=0D=0A= as=0D=0Ayou understand it=3F=0D=0A=0D=0ANote that multi-homing the enterpri= se and other access networks is both=0D=0Aburgeoning business and of seriou= s concern to other parts of the IETF.=0D=0AEach=0D=0Aone of those that gets= PI space and starts making its own BGP=0D=0Aannouncement=0D=0Abecomes some= thing like a transit upstream, but isn't exactly the same.=20=0D=0AWhere do= they fit=3F Does taking on additional upstream turn you into=0D=0Asomeone=0D= =0Awho has to meet this requirement, or does it only occur if you carry=0D=0A= prefixes=0D=0Aoriginated by someone else=3F=0D=0A=0D=0AAs Marc has noted, l= ots of enterprises may fall into this. An=0D=0Aenterprise may=0D=0Ahave mu= ltiple campuses, with multiple upstream providers (either per=0D=0Acampus, = in a mesh, or with a star topology with multiple upstreams from=0D=0Athe ce= nter). Getting them to provide location is one thing. Getting=0D=0Athem=0D= =0Ato associate the topology, location, and the right signing authority for=0D= =0Aa specific 911 authority is far more complex.=0D=0A=0D=0AI realize that = this comes across as failing your "tell us what to do=0D=0Ainstead"=0D=0Ate= st, but I'm trying to get across that "make it act like it used to" is=0D=0A= a requirement=0D=0Athat creates very serious burdens. If the requirement = is to allow=0D=0Acalls from anyone (and that is the requirement, as I under= stand you),=0D=0Athere may be a fundamental trade-off between meeting that = requirement=0D=0Aand the security concerns here.=20=0D=0A=0D=0A=09=09=09=09= Ted=0D=0A=0D=0A=0D=0A_______________________________________________=0D=0AG= eopriv mailing list=0D=0AGeopriv@ietf.org=0D=0Ahttps://www1.ietf.org/mailma= n/listinfo/geopriv=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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 09 14:45:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPl1Q-0004q4-0B; Fri, 09 Mar 2007 14:45:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPl1O-0004or-S5 for geopriv@ietf.org; Fri, 09 Mar 2007 14:44:58 -0500 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPl1N-0006DI-JJ for geopriv@ietf.org; Fri, 09 Mar 2007 14:44:58 -0500 Received: from [192.168.1.74] ([::ffff:65.74.225.172]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 09 Mar 2007 14:42:46 -0500 id 01588664.45F1B8B7.00007D7D Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: GEOPRIV WG From: Andrew Newton Date: Fri, 9 Mar 2007 14:44:54 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Geopriv] Where we are / are we with L7-LCP X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org In reviewing the comments on the L7-LCP problem statement and requirements draft, I see three areas of conversation: 1) The name: location configuration protocol vs. location acquisition protocol. 2) The On-behalf-of feature. 3) Location signing. With respect with #1, I have to say that discussion over the name of the effort is a distraction. I would ask that participants refrain from this discussion. I understand that one of the protocol proposals goes by the name LCP, but that is a consequence of the authors of that proposal helping the working group come to the conclusion that LCP is a separate issue than L-by-R. For #2, some of the participants have come to the conclusion that OBO is also a separable issue, in that it is an LS-to-LS (LIS-to-LIS) issue and not an LCP issue, and that OBO should influence the requirements for L-by-R. I realize that not everybody agrees with this, but for those who wish to have OBO constrained to the LCP problem it should be noted that there is no consensus for this position, and that OBO with regard to L-by-R and LS-to-LS would likely find consensus with their support. Finally, there is #3... by far the thorniest issue with many differing views. Here is my attempt to enumerate the positions (putting aside any IPR conversation): a) Those that don't support it. There are many reasons, from complexity to disbelief about the use case to issues about administrative overhead. b) Those that support it only for L7-LCP. c) Those that support it for all types location configuration protocols. Have I missed any angles? -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 09 14:50: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 1HPl77-0004nv-5I; Fri, 09 Mar 2007 14:50:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPl75-0004mm-3F for geopriv@ietf.org; Fri, 09 Mar 2007 14:50:51 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPl6Q-00079z-3c for geopriv@ietf.org; Fri, 09 Mar 2007 14:50:13 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HPl6E-0008TS-PS; Fri, 09 Mar 2007 13:49:58 -0600 From: "Brian Rosen" To: "'Andrew Newton'" , "'GEOPRIV WG'" Subject: RE: [Geopriv] Where we are / are we with L7-LCP Date: Fri, 9 Mar 2007 14:50:06 -0500 Message-ID: <068501c76284$24b2a100$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Acdig2d/OwdPZRF/RpGxl/zq7oh09wAAIKzA 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: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I think you forgot the big gorilla in the room on L7 LCP, which is the choice of identifiers, and the issues associated with using IP addresses on those identifiers in some circumstances. I think your summary of the other three issues is good. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Friday, March 09, 2007 2:45 PM > To: GEOPRIV WG > Subject: [Geopriv] Where we are / are we with L7-LCP > > In reviewing the comments on the L7-LCP problem statement and > requirements draft, I see three areas of conversation: > > 1) The name: location configuration protocol vs. location acquisition > protocol. > 2) The On-behalf-of feature. > 3) Location signing. > > With respect with #1, I have to say that discussion over the name of > the effort is a distraction. I would ask that participants refrain > from this discussion. I understand that one of the protocol > proposals goes by the name LCP, but that is a consequence of the > authors of that proposal helping the working group come to the > conclusion that LCP is a separate issue than L-by-R. > > For #2, some of the participants have come to the conclusion that OBO > is also a separable issue, in that it is an LS-to-LS (LIS-to-LIS) > issue and not an LCP issue, and that OBO should influence the > requirements for L-by-R. I realize that not everybody agrees with > this, but for those who wish to have OBO constrained to the LCP > problem it should be noted that there is no consensus for this > position, and that OBO with regard to L-by-R and LS-to-LS would > likely find consensus with their support. > > Finally, there is #3... by far the thorniest issue with many > differing views. Here is my attempt to enumerate the positions > (putting aside any IPR conversation): > > a) Those that don't support it. There are many reasons, from > complexity to disbelief about the use case to issues about > administrative overhead. > > b) Those that support it only for L7-LCP. > > c) Those that support it for all types location configuration > protocols. > > > > Have I missed any angles? > > -andy > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 09 15:33: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 1HPlmV-0001ye-Jp; Fri, 09 Mar 2007 15:33:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPlmU-0001yZ-CA for geopriv@ietf.org; Fri, 09 Mar 2007 15:33:38 -0500 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPlmR-0004gx-JZ for geopriv@ietf.org; Fri, 09 Mar 2007 15:33:38 -0500 Received: from [192.168.1.74] ([::ffff:65.74.225.172]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 09 Mar 2007 15:31:25 -0500 id 01588663.45F1C41D.0000092E Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <33E5EEC5-667C-49C2-87AA-90A3DD1C97C2@hxr.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: GEOPRIV WG From: Andrew Newton Date: Fri, 9 Mar 2007 15:33:31 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Geopriv] Brian Rosen on location signing X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Since I just spent the last half hour reviewing the mailing list traffic on location signing in my role as co-chair, I found that Brian Rosen made a couple of points that were very interesting but also lightly supported. And I tend to wonder why, since he supports location signing. Point 1. Location signing is much more than an L7-LCP issue. It also changes location conveyance and de-referenced locations. Is there anybody that disagrees with this? Do participants realize this? Point 2. Brian has asserted that location signing should be applied to all location configuration protocols, not just L7-LCP. His assertion is that location signing for the emergency use case is applicable no matter how a UA acquires their location information. This brings up the question, if the other proponents of location signing feel it is important to deter spoofing, DoS, etc, why isn't location signing always important no matter how it is required? -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 09 16:12: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 1HPmOM-0000CZ-GX; Fri, 09 Mar 2007 16:12:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPmO1-0007rW-Fi for geopriv@ietf.org; Fri, 09 Mar 2007 16:12:25 -0500 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPm9j-0000GB-GD for geopriv@ietf.org; Fri, 09 Mar 2007 15:58:01 -0500 Received: from po2.bbn.com ([128.33.0.56]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HPm9j-0002TA-3F; Fri, 09 Mar 2007 15:57:39 -0500 Received: from [127.0.0.1] (col-dhcp33-244-160.bbn.com [128.33.244.160]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l29Kvcw21865; Fri, 9 Mar 2007 15:57:38 -0500 (EST) Message-ID: <45F1CA41.4030806@bbn.com> Date: Fri, 09 Mar 2007 15:57:37 -0500 From: Richard Barnes User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Geopriv] Brian Rosen on location signing References: <33E5EEC5-667C-49C2-87AA-90A3DD1C97C2@hxr.us> In-Reply-To: <33E5EEC5-667C-49C2-87AA-90A3DD1C97C2@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I would second Brian on those points. If we can agree that signed location objects are useful, then we should have a signed location object structure that's common across protocols, just like PIDF-LO is used for location across protocols. --RB Andrew Newton wrote: > Since I just spent the last half hour reviewing the mailing list traffic > on location signing in my role as co-chair, I found that Brian Rosen > made a couple of points that were very interesting but also lightly > supported. And I tend to wonder why, since he supports location signing. > > Point 1. Location signing is much more than an L7-LCP issue. It also > changes location conveyance and de-referenced locations. Is there > anybody that disagrees with this? Do participants realize this? > > Point 2. Brian has asserted that location signing should be applied to > all location configuration protocols, not just L7-LCP. His assertion is > that location signing for the emergency use case is applicable no matter > how a UA acquires their location information. This brings up the > question, if the other proponents of location signing feel it is > important to deter spoofing, DoS, etc, why isn't location signing always > important no matter how it is required? > > -andy > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 09 17:10: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 1HPnHp-00060p-0b; Fri, 09 Mar 2007 17:10:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPnHn-0005tJ-Fs for geopriv@ietf.org; Fri, 09 Mar 2007 17:10:03 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPnHm-0005GP-3U for geopriv@ietf.org; Fri, 09 Mar 2007 17:10:03 -0500 X-SEF-Processed: 5_0_0_910__2007_03_09_16_15_51 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); Fri, 09 Mar 2007 16:14:15 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 16:08:20 -0600 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: [Geopriv] Where we are / are we with L7-LCP Date: Fri, 9 Mar 2007 16:08:19 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Where we are / are we with L7-LCP Thread-Index: Acdig4liXakusPGNSFODJdWMB/gOOwAE8Hiw From: "Winterbottom, James" To: "Andrew Newton" , "GEOPRIV WG" X-OriginalArrivalTime: 09 Mar 2007 22:08:20.0548 (UTC) FILETIME=[7297C040:01C76297] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org There is also the specification of a response time by the requesting=0D=0An= ode.=0D=0A=0D=0AI have posted on this item 3 times and have had no response= , my=0D=0Aassumption therefore was that it was agreed to without opposition= =2E=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Andrew= Newton [mailto:andy@hxr.us]=0D=0A> Sent: Saturday, 10 March 2007 6:45 AM=0D= =0A> To: GEOPRIV WG=0D=0A> Subject: [Geopriv] Where we are / are we with L7= -LCP=0D=0A>=20=0D=0A> In reviewing the comments on the L7-LCP problem state= ment and=0D=0A> requirements draft, I see three areas of conversation:=0D=0A= >=20=0D=0A> 1) The name: location configuration protocol vs. location acqui= sition=0D=0A> protocol.=0D=0A> 2) The On-behalf-of feature.=0D=0A> 3) Locat= ion signing.=0D=0A>=20=0D=0A> With respect with #1, I have to say that disc= ussion over the name of=0D=0A> the effort is a distraction. I would ask th= at participants refrain=0D=0A> from this discussion. I understand that one= of the protocol=0D=0A> proposals goes by the name LCP, but that is a conse= quence of the=0D=0A> authors of that proposal helping the working group com= e to the=0D=0A> conclusion that LCP is a separate issue than L-by-R.=0D=0A>= =20=0D=0A> For #2, some of the participants have come to the conclusion tha= t OBO=0D=0A> is also a separable issue, in that it is an LS-to-LS (LIS-to-L= IS)=0D=0A> issue and not an LCP issue, and that OBO should influence the=0D= =0A> requirements for L-by-R. I realize that not everybody agrees with=0D=0A= > this, but for those who wish to have OBO constrained to the LCP=0D=0A> pr= oblem it should be noted that there is no consensus for this=0D=0A> positio= n, and that OBO with regard to L-by-R and LS-to-LS would=0D=0A> likely find= consensus with their support.=0D=0A>=20=0D=0A> Finally, there is #3... by = far the thorniest issue with many=0D=0A> differing views. Here is my attem= pt to enumerate the positions=0D=0A> (putting aside any IPR conversation):=0D= =0A>=20=0D=0A> a) Those that don't support it. There are many reasons, = from=0D=0A> complexity to disbelief about the use case to issues about=0D=0A= > administrative overhead.=0D=0A>=20=0D=0A> b) Those that support it onl= y for L7-LCP.=0D=0A>=20=0D=0A> c) Those that support it for all types lo= cation configuration=0D=0A> protocols.=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>= Have I missed any angles=3F=0D=0A>=20=0D=0A> -andy=0D=0A>=20=0D=0A> ______= _________________________________________=0D=0A> Geopriv mailing list=0D=0A= > Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 09 17:13: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 1HPnLJ-0005T4-OE; Fri, 09 Mar 2007 17:13:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPnLG-0005SB-V7 for geopriv@ietf.org; Fri, 09 Mar 2007 17:13:38 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HPnL8-0000lJ-0O for geopriv@ietf.org; Fri, 09 Mar 2007 17:13:38 -0500 Received: (qmail invoked by alias); 09 Mar 2007 22:13:28 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp042) with SMTP; 09 Mar 2007 23:13:28 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+C8F1zh5mCKK31nkzk/E3NvurXPIq8p3OYk93OzY 6joCn44DCgpq72 Message-ID: <45F1DC03.9030609@gmx.net> Date: Sat, 10 Mar 2007 00:13:23 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: ECRIT , GEOPRIV , sip@ietf.org, es-coordination@cs.columbia.edu, iab@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Geopriv] SDO Emergency Services Workshop 2007 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi all, we would like to inform you about the progress of the preparation of the 2nd SDO Emergency Services Workshop hosted by the U.S. Department of Transportation (DOT). The workshop will be held April 10, 11 & 12, 2007, from 8:30 am � 6:00 pm., in the Jefferson Building of the Library of Congress, located at 101 Independence Avenue SE in Washington, D.C. Please find updated information at this webpage: http://www.emergency-services-coordination.info/2007/ Best regards, Jenny Hansen Marc Linsner Stephen McCann Christian Militeau Atle Monrad Henning Schulzrinne Hannes Tschofenig Harry Worstell _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 09 17:52:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPnx2-0001RL-DK; Fri, 09 Mar 2007 17:52:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPnx1-0001RG-0t for geopriv@ietf.org; Fri, 09 Mar 2007 17:52:39 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPnwz-0002mS-JW for geopriv@ietf.org; Fri, 09 Mar 2007 17:52:38 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l29MqVlM011615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Mar 2007 14:52:31 -0800 Received: from [71.204.158.100] (carbuncle.qualcomm.com [129.46.226.191]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l29MqT2o001620; Fri, 9 Mar 2007 14:52:30 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 9 Mar 2007 14:52:26 -0800 To: Andrew Newton , GEOPRIV WG From: Ted Hardie Subject: Re: [Geopriv] Where we are / are we with L7-LCP Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org At 2:44 PM -0500 3/9/07, Andrew Newton wrote: >Finally, there is #3... by far the thorniest issue with many differing views. Here is my attempt to enumerate the positions (putting aside any IPR conversation): > > a) Those that don't support it. There are many reasons, from complexity to disbelief about the use case to issues about administrative overhead. > > b) Those that support it only for L7-LCP. > > c) Those that support it for all types location configuration protocols. > > > >Have I missed any angles? > >-andy Hmm, my complex, nuanced view of the engineering and social trade-offs between making it possible for anyone to call a PSAP and making it possible for the PSAP to determine if the call's originator is in their service area seems to have collapsed into "don't support it". I don't think a) quite captures the issue I keep trying to raise. PSAPs want to limit the ability of attackers to use their resources. One way they do that now is to limit who can talk to the PSAP to those within their service area. PSAPs can no longer use network topology to identify who is in their service area. They would like to use something else. The location asserted by the end user/network is used to identify a PSAP which serves the area, but the PSAPs are concerned that bad actors can assert false information to discover/target PSAPs. They would like the information used in those assertions to be vouched for by someone they trust or with whom they can build trust, and the information to be carried through to the PSAP. Rather than have the clients doing the assertion being vouched for (now *there's a problem*), they want one piece of information in the assertion to be vouched for--the location. If that is vouched for, the PSAP has higher confidence that the call is from someone within their service area; that means that they are no more likely to be an attacker than they would be with the existing system (which allows for attackers to call from within the service area). The issue that I'm raising is that while the primary aim,"limit the ability of attackers to use their resources", is laudable, useful, and strongly associated with apple pie, good beer, and the comic-book hero of your choice, doing so by "limiting the geographic range from which attacks may come" is only a strategy for achieving it. There are other potential strategies (including things like associative IDS systems that do not work on single calls but work on patterns) that might be more effective at thwarting the efforts of attackers to consume PSAP resources. Recreating the old strategy in the new system might be possible (with a large, likely unfunded mandate), but it will take a lot of time and cruft to get it going. Balancing the effort that goes into this strategy has to be weighed against whether this strategy is effective in and of itself and whether it is the best use of the community's resources. Put another way, we need to focus on the real goal, rather than on whether this strategy is the right way to achieve it. Brian has been saying this in some ways all along, but I think we've been hearing him say "how else can I limit callers to a specific geographic area" rather than "how else can I preserve PSAPs against attackers looking to consume their resources." All that now said, I remind folks that it has all along been possible to sign a PIDF-LO object using S/MIME; that's in the base standard. Anyone looking to create method for carrying location with a signature has only to pick PIDF-LO as their format and that mechanism comes along for the ride. That won't tell you who ought to sign it, when that signature out to be checked, or what actions to take when it fails, but as I understand it folks want that to be a matter of policy anyway. Ted _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 09 18:00:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPo4M-0000aZ-EC; Fri, 09 Mar 2007 18:00:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPo4K-0000NU-Vi for geopriv@ietf.org; Fri, 09 Mar 2007 18:00:12 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPo4I-0003Vm-FH for geopriv@ietf.org; Fri, 09 Mar 2007 18:00:12 -0500 X-SEF-Processed: 5_0_0_910__2007_03_09_17_06_02 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); Fri, 09 Mar 2007 17:06:02 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 17:00:07 -0600 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: [Geopriv] Brian Rosen on location signing Date: Fri, 9 Mar 2007 17:00:06 -0600 Message-ID: In-Reply-To: <45F1CA41.4030806@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Brian Rosen on location signing Thread-Index: Acdij8/xTAku5d0JTamohUzf7z/UiwADLIcg From: "Winterbottom, James" To: "Richard Barnes" , "Andrew Newton" X-OriginalArrivalTime: 09 Mar 2007 23:00:07.0589 (UTC) FILETIME=[AE889550:01C7629E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I am not in complete agreement with this position though I am a=0D=0Apropon= ent of location signing.=0D=0AThe standard container for location informati= on in this forum is the=0D=0APIDF-LO, and this is something that we can eas= ily address the signing=0D=0Aof.=0D=0A=0D=0AAttempting to come up with a si= gning mechanism that can support any=0D=0Anumber of binary encoding schemes= seems to me to be counter productive=0D=0Aand will likely have problems fr= om a future-proofing perspective.=0D=0A=0D=0ASigning a PIDF-LO can provide = the following characteristics:=0D=0A1) ties location to end-device=0D=0A2) = ties signature to access provider=0D=0A3) ties end-device to location at sp= ecific point in time=0D=0A4) ties location to end-device for recipient if u= sed with a conveyance=0D=0Aidentity mechanism.=0D=0A=0D=0AIt is unclear to = me how you can achieve these things if all you get is a=0D=0Alocation eleme= nt and a signature. There is a proposal on the table now=0D=0Afor how this = can be done with a PIDF-LO, there has been talk over=0D=0Asigning LCI for n= early 2 years but not proposal has yet been made, and=0D=0Ait has is unclea= r precisely what would be signed, and how it would=0D=0Aaddress the 4 point= s above.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A> -----Original Message-----=0D=0A> From: Richard Barnes [mailto:r= barnes@bbn.com]=0D=0A> Sent: Saturday, 10 March 2007 7:58 AM=0D=0A> To: And= rew Newton=0D=0A> Cc: GEOPRIV WG=0D=0A> Subject: Re: [Geopriv] Brian Rosen = on location signing=0D=0A>=20=0D=0A> I would second Brian on those points. = If we can agree that signed=0D=0A> location objects are useful, then we sh= ould have a signed location=0D=0A> object structure that's common across pr= otocols, just like PIDF-LO is=0D=0A> used for location across protocols.=0D= =0A> --RB=0D=0A>=20=0D=0A> Andrew Newton wrote:=0D=0A> > Since I just spent= the last half hour reviewing the mailing list=0D=0Atraffic=0D=0A> > on loc= ation signing in my role as co-chair, I found that Brian Rosen=0D=0A> > mad= e a couple of points that were very interesting but also lightly=0D=0A> > s= upported. And I tend to wonder why, since he supports location=0D=0A> sign= ing.=0D=0A> >=0D=0A> > Point 1. Location signing is much more than an L7-LC= P issue. It=0D=0Aalso=0D=0A> > changes location conveyance and de-referenc= ed locations. Is there=0D=0A> > anybody that disagrees with this=3F Do pa= rticipants realize this=3F=0D=0A> >=0D=0A> > Point 2. Brian has asserted th= at location signing should be applied=0D=0Ato=0D=0A> > all location configu= ration protocols, not just L7-LCP. His=0D=0Aassertion is=0D=0A> > that loc= ation signing for the emergency use case is applicable no=0D=0Amatter=0D=0A= > > how a UA acquires their location information. This brings up the=0D=0A= > > question, if the other proponents of location signing feel it is=0D=0A>= > important to deter spoofing, DoS, etc, why isn't location signing=0D=0Aa= lways=0D=0A> > important no matter how it is required=3F=0D=0A> >=0D=0A> > = -andy=0D=0A> >=0D=0A> > _______________________________________________=0D=0A= > > Geopriv mailing list=0D=0A> > Geopriv@ietf.org=0D=0A> > https://www1.ie= tf.org/mailman/listinfo/geopriv=0D=0A> >=0D=0A> >=0D=0A>=20=0D=0A>=20=0D=0A= > _______________________________________________=0D=0A> Geopriv mailing li= st=0D=0A> Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/ge= opriv=0D=0A=0D=0A----------------------------------------------------------= --------------------------------------=0D=0AThis message is for the designa= ted recipient only and may=0D=0Acontain privileged, proprietary, or otherwi= se private information. =20=0D=0AIf you have received it in error, please n= otify the sender=0D=0Aimmediately and delete the original. Any unauthorize= d use of=0D=0Athis email is prohibited.=0D=0A------------------------------= ------------------------------------------------------------------=0D=0A[mf= 2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 09 19:12:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPpCA-0003Vx-4k; Fri, 09 Mar 2007 19:12:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPpC8-0003Vs-UI for geopriv@ietf.org; Fri, 09 Mar 2007 19:12:20 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPpC7-0001Cf-JG for geopriv@ietf.org; Fri, 09 Mar 2007 19:12:20 -0500 X-SEF-Processed: 5_0_0_910__2007_03_09_18_17_58 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); Fri, 09 Mar 2007 18:17:57 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 18:12:03 -0600 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: [Geopriv] Brian Rosen on location signing Date: Fri, 9 Mar 2007 18:12:00 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Brian Rosen on location signing Thread-Index: Acdij8/xTAku5d0JTamohUzf7z/UiwADLIcgAALqCPA= From: "Dawson, Martin" To: "Winterbottom, James" , "Richard Barnes" , "Andrew Newton" X-OriginalArrivalTime: 10 Mar 2007 00:12:03.0380 (UTC) FILETIME=[BAF20740:01C762A8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Yes - it seems to me that I could similarly argue that we all agree=0D=0At= hat location conveyance is of critical importance, therefore the SIP=0D=0Ac= onveyance specification should go back to the drawing board and cover=0D=0A= location provided in other forms as well.=0D=0A=0D=0AThe assertion mechanis= m is available for location obtained from a link=0D=0Alayer source - curren= tly LLDP-MED or DHCP but also possible according to=0D=0Athe latest IEEE sp= ecs for WiFi. The device can obtain the precise=0D=0Alocation from the link= and ask the LIS to sign it via assertion. This=0D=0Amakes it equivalent to= any self-determination capability such as GPS or=0D=0ARFID beacon measurem= ent.=0D=0A=0D=0ABTW, assertion is another function to add to the list Andy.=0D= =0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFro= m: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20=0D=0ASent:= Saturday, 10 March 2007 10:00 AM=0D=0ATo: Richard Barnes; Andrew Newton=0D= =0ACc: GEOPRIV WG=0D=0ASubject: RE: [Geopriv] Brian Rosen on location signi= ng=0D=0A=0D=0AI am not in complete agreement with this position though I am= a=0D=0Aproponent of location signing.=0D=0AThe standard container for loca= tion information in this forum is the=0D=0APIDF-LO, and this is something t= hat we can easily address the signing=0D=0Aof.=0D=0A=0D=0AAttempting to com= e up with a signing mechanism that can support any=0D=0Anumber of binary en= coding schemes seems to me to be counter productive=0D=0Aand will likely ha= ve problems from a future-proofing perspective.=0D=0A=0D=0ASigning a PIDF-L= O can provide the following characteristics:=0D=0A1) ties location to end-d= evice=0D=0A2) ties signature to access provider=0D=0A3) ties end-device to = location at specific point in time=0D=0A4) ties location to end-device for = recipient if used with a conveyance=0D=0Aidentity mechanism.=0D=0A=0D=0AIt = is unclear to me how you can achieve these things if all you get is a=0D=0A= location element and a signature. There is a proposal on the table now=0D=0A= for how this can be done with a PIDF-LO, there has been talk over=0D=0Asign= ing LCI for nearly 2 years but not proposal has yet been made, and=0D=0Ait = has is unclear precisely what would be signed, and how it would=0D=0Aaddres= s the 4 points above.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Richard Barn= es [mailto:rbarnes@bbn.com]=0D=0A> Sent: Saturday, 10 March 2007 7:58 AM=0D= =0A> To: Andrew Newton=0D=0A> Cc: GEOPRIV WG=0D=0A> Subject: Re: [Geopriv] = Brian Rosen on location signing=0D=0A>=20=0D=0A> I would second Brian on th= ose points. If we can agree that signed=0D=0A> location objects are useful= , then we should have a signed location=0D=0A> object structure that's comm= on across protocols, just like PIDF-LO is=0D=0A> used for location across p= rotocols.=0D=0A> --RB=0D=0A>=20=0D=0A> Andrew Newton wrote:=0D=0A> > Since = I just spent the last half hour reviewing the mailing list=0D=0Atraffic=0D=0A= > > on location signing in my role as co-chair, I found that Brian Rosen=0D= =0A> > made a couple of points that were very interesting but also lightly=0D= =0A> > supported. And I tend to wonder why, since he supports location=0D=0A= > signing.=0D=0A> >=0D=0A> > Point 1. Location signing is much more than an= L7-LCP issue. It=0D=0Aalso=0D=0A> > changes location conveyance and de-re= ferenced locations. Is there=0D=0A> > anybody that disagrees with this=3F = Do participants realize this=3F=0D=0A> >=0D=0A> > Point 2. Brian has asser= ted that location signing should be applied=0D=0Ato=0D=0A> > all location c= onfiguration protocols, not just L7-LCP. His=0D=0Aassertion is=0D=0A> > th= at location signing for the emergency use case is applicable no=0D=0Amatter=0D= =0A> > how a UA acquires their location information. This brings up the=0D= =0A> > question, if the other proponents of location signing feel it is=0D=0A= > > important to deter spoofing, DoS, etc, why isn't location signing=0D=0A= always=0D=0A> > important no matter how it is required=3F=0D=0A> >=0D=0A> >= -andy=0D=0A> >=0D=0A> > _______________________________________________=0D= =0A> > Geopriv mailing list=0D=0A> > Geopriv@ietf.org=0D=0A> > https://www1= =2Eietf.org/mailman/listinfo/geopriv=0D=0A> >=0D=0A> >=0D=0A>=20=0D=0A>=20=0D= =0A> _______________________________________________=0D=0A> Geopriv mailing= list=0D=0A> Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo= /geopriv=0D=0A=0D=0A-------------------------------------------------------= -----------------=0D=0A------------------------=0D=0AThis message is for th= e designated recipient only and may=0D=0Acontain privileged, proprietary, o= r otherwise private information. =20=0D=0AIf you have received it in error,= please notify the sender=0D=0Aimmediately and delete the original. Any un= authorized use of=0D=0Athis email is prohibited.=0D=0A---------------------= ---------------------------------------------------=0D=0A------------------= ------=0D=0A[mf2]=0D=0A=0D=0A=0D=0A________________________________________= _______=0D=0AGeopriv mailing list=0D=0AGeopriv@ietf.org=0D=0Ahttps://www1.i= etf.org/mailman/listinfo/geopriv=0D=0A=0D=0A-------------------------------= -----------------------------------------------------------------=0D=0AThis= message is for the designated recipient only and may=0D=0Acontain privileg= ed, proprietary, or otherwise private information. =20=0D=0AIf you have rec= eived 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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 09 19:33: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 1HPpWa-00058F-An; Fri, 09 Mar 2007 19:33:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPpWZ-00057T-J5 for geopriv@ietf.org; Fri, 09 Mar 2007 19:33:27 -0500 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPpWY-000375-90 for geopriv@ietf.org; Fri, 09 Mar 2007 19:33:27 -0500 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 1HPpWR-0004ZA-4c; Fri, 09 Mar 2007 19:33:19 -0500 Message-ID: <45F1FCCF.9050107@bbn.com> Date: Fri, 09 Mar 2007 19:33:19 -0500 From: Richard Barnes User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Geopriv] Brian Rosen on location signing 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: 944ecb6e61f753561f559a497458fb4f Cc: GEOPRIV WG , Andrew Newton X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org James, Maybe not with just a LO and a signature. But there's only a few interesting bindings that one might want to indicate with these structures (you give four), so it seems like we could come up with something sufficiently expressive to cover those. --RB Winterbottom, James wrote: > I am not in complete agreement with this position though I am a > proponent of location signing. > The standard container for location information in this forum is the > PIDF-LO, and this is something that we can easily address the signing > of. > > Attempting to come up with a signing mechanism that can support any > number of binary encoding schemes seems to me to be counter productive > and will likely have problems from a future-proofing perspective. > > Signing a PIDF-LO can provide the following characteristics: > 1) ties location to end-device > 2) ties signature to access provider > 3) ties end-device to location at specific point in time > 4) ties location to end-device for recipient if used with a conveyance > identity mechanism. > > It is unclear to me how you can achieve these things if all you get is a > location element and a signature. There is a proposal on the table now > for how this can be done with a PIDF-LO, there has been talk over > signing LCI for nearly 2 years but not proposal has yet been made, and > it has is unclear precisely what would be signed, and how it would > address the 4 points above. > > Cheers > James > > > > > > > >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Saturday, 10 March 2007 7:58 AM >> To: Andrew Newton >> Cc: GEOPRIV WG >> Subject: Re: [Geopriv] Brian Rosen on location signing >> >> I would second Brian on those points. If we can agree that signed >> location objects are useful, then we should have a signed location >> object structure that's common across protocols, just like PIDF-LO is >> used for location across protocols. >> --RB >> >> Andrew Newton wrote: >>> Since I just spent the last half hour reviewing the mailing list > traffic >>> on location signing in my role as co-chair, I found that Brian Rosen >>> made a couple of points that were very interesting but also lightly >>> supported. And I tend to wonder why, since he supports location >> signing. >>> Point 1. Location signing is much more than an L7-LCP issue. It > als > ed locations. Is there >>> anybody that disagrees with this? Do participants realize this? >>> >>> Point 2. Brian has asserted that location signing should be applied > to >>> all location configuration protocols, not just L7-LCP. His > assertion is >>> that location signing for the emergency use case is applicable no > matter >>> how a UA acquires their location information. This brings up the >>> question, if the other proponents of location signing feel it is >>> important to deter spoofing, DoS, etc, why isn't location signing > always >>> important no matter how it is required? >>> >>> -andy >>> >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www1.ietf.org/mailman/listinfo/geopriv >>> >>> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 09 19:37:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPpaP-0008SS-1x; Fri, 09 Mar 2007 19:37:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPpaO-0008SM-B6 for geopriv@ietf.org; Fri, 09 Mar 2007 19:37:24 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPpaM-0003W8-Ud for geopriv@ietf.org; Fri, 09 Mar 2007 19:37:24 -0500 X-SEF-Processed: 5_0_0_910__2007_03_09_18_43_16 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); Fri, 09 Mar 2007 18:43:16 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 18:37:21 -0600 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: [Geopriv] Where we are / are we with L7-LCP Date: Fri, 9 Mar 2007 18:37:19 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Where we are / are we with L7-LCP Thread-Index: AcdincDZwaU5x75zRR6pV1mv8EGU7AAC3okA From: "Dawson, Martin" To: "Ted Hardie" , "Andrew Newton" , "GEOPRIV WG" X-OriginalArrivalTime: 10 Mar 2007 00:37:21.0608 (UTC) FILETIME=[43E13C80:01C762AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Currently PSAPs can be called from anywhere in their service area and=0D=0A= they have processes and resources to deal with hoax calls. Not providing=0D= =0Athem a mechanism to provide priority to calls arising from their service=0D= =0Aarea puts those processes and resources in peril by several orders of=0D= =0Amagnitude. There is a precedent for the former and none for the latter.=0D= =0A=0D=0AIt is quickly going to become common knowledge that a SIP call ini= tiated=0D=0Awith a PIDF-LO value of your choosing can go to the emergency c= all=0D=0Acentre for that location. Unfortunately emergency calling is going= to be=0D=0Aone of the first IP telephony location based routing services. = We aren't=0D=0Agoing to get the opportunity to find out how badly Pizza Hut= gets=0D=0Aimpacted first.=0D=0A=0D=0AYour argument is just another rehash = of the "if it's not perfect than=0D=0Ait's not worth having." This is makin= g perfect the enemy of good.=0D=0A=0D=0ASigning the whole PIDF-LO per the S= /MIME mechanism has been suggested=0D=0Abefore. There are a couple of probl= ems.=0D=0A=0D=0A1. The signature also needs to cover the time of applicabil= ity and the=0D=0Aunique LIS client identity. These aren't, currently, part = of the=0D=0APIDF-LO.=0D=0A=0D=0A2. There are parts of the PIDF-LO that shou= ld still be able to be=0D=0Achanged by the location object recipient and, p= otentially, some proxies.=0D=0AIf the signature applies to the whole object= then this won't be=0D=0Apossible.=0D=0A=0D=0AIn addition to the source of = the location, the signature covers the time=0D=0Aof applicability of the lo= cation information and the identity of the LIS=0D=0Aclient. These provide a= dditional criteria for an automatic policy filter=0D=0Ato use depending on = PSAP congestion. Without a signature mechanism, you=0D=0Aare dooming the PS= AP operators - the human beings - to having to apply=0D=0Athose policies ma= nually; if you get to that point you've already lost.=0D=0A=0D=0ACheers,=0D= =0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Ted Hardie [mail= to:hardie@qualcomm.com]=20=0D=0ASent: Saturday, 10 March 2007 9:52 AM=0D=0A= To: Andrew Newton; GEOPRIV WG=0D=0ASubject: Re: [Geopriv] Where we are / ar= e we with L7-LCP=0D=0A=0D=0AAt 2:44 PM -0500 3/9/07, Andrew Newton wrote:=0D= =0A>Finally, there is #3... by far the thorniest issue with many differing=0D= =0Aviews. Here is my attempt to enumerate the positions (putting aside any=0D= =0AIPR conversation):=0D=0A>=0D=0A> a) Those that don't support it. There= are many reasons, from=0D=0Acomplexity to disbelief about the use case to = issues about=0D=0Aadministrative overhead.=0D=0A>=0D=0A> b) Those that sup= port it only for L7-LCP.=0D=0A>=0D=0A> c) Those that support it for all ty= pes location configuration=0D=0Aprotocols.=0D=0A>=0D=0A>=0D=0A>=0D=0A>Have = I missed any angles=3F=0D=0A>=0D=0A>-andy=0D=0A=0D=0AHmm, my complex, nuanc= ed view of the engineering and social trade-offs=0D=0Abetween making it pos= sible for anyone to call a PSAP and making it=0D=0Apossible for the PSAP to= determine if the call's originator is in their=0D=0Aservice=0D=0Aarea seem= s to have collapsed into "don't support it".=0D=0A=0D=0A=0D=0A=0D=0AI don't think a) quite captures the issue I keep = trying to raise.=20=0D=0A=0D=0APSAPs want to limit the ability of attackers= to use their resources.=0D=0AOne way they do that now is to limit who can = talk to the PSAP to those=0D=0Awithin their service area.=0D=0A=0D=0APSAPs = can no longer use network topology to identify who is in their=0D=0Aservice=0D= =0Aarea. They would like to use something else. The location asserted by=0D= =0Athe end user/network is used to identify a PSAP which serves the area,=0D= =0Abut=0D=0Athe PSAPs are concerned that bad actors can assert false inform= ation to=0D=0Adiscover/target PSAPs. They would like the information used = in those=0D=0Aassertions to be vouched for by someone they trust or with wh= om they=0D=0Acan build trust, and the information to be carried through to = the PSAP.=0D=0A=0D=0ARather than have the clients doing the assertion being= vouched for (now=0D=0A*there's=0D=0Aa problem*), they want one piece of in= formation in the assertion to be=0D=0Avouched for--the location. If that i= s vouched for, the PSAP has higher=0D=0Aconfidence=0D=0Athat the call is fr= om someone within their service area; that means that=0D=0Athey are no more= likely to be an attacker than they would be with the=0D=0Aexisting system = (which allows for attackers to call from within the=0D=0Aservice=0D=0Aarea)= =2E=0D=0A=0D=0AThe issue that I'm raising is that while the primary aim,"li= mit the=0D=0Aability of attackers=0D=0Ato use their resources", is laudable= , useful, and strongly associated=0D=0Awith apple=0D=0Apie, good beer, and = the comic-book hero of your choice, doing so by=0D=0A"limiting=0D=0Athe g= eographic range from which attacks may come" is only a strategy for=0D=0Aac= hieving it. There are other potential strategies (including things=0D=0Ali= ke associative=0D=0AIDS systems that do not work on single calls but work o= n patterns) that=0D=0Amight=0D=0Abe more effective at thwarting the efforts= of attackers to consume PSAP=0D=0Aresources.=0D=0ARecreating the old strat= egy in the new system might be possible (with a=0D=0Alarge,=0D=0Alikely unf= unded mandate), but it will take a lot of time and cruft to=0D=0Aget it go= ing.=0D=0ABalancing the effort that goes into this strategy has to be weigh= ed=0D=0Aagainst whether=0D=0Athis strategy is effective in and of itself an= d whether it is the best=0D=0Ause of the=0D=0Acommunity's resources.=0D=0A=0D= =0APut another way, we need to focus on the real goal, rather than on=0D=0A= whether this=0D=0Astrategy is the right way to achieve it. Brian has been = saying this in=0D=0Asome ways=0D=0Aall along, but I think we've been hearin= g him say "how else can I limit=0D=0Acallers=0D=0Ato a specific geographic = area" rather than "how else can I preserve=0D=0APSAPs=0D=0Aagainst attacker= s looking to consume their resources."=0D=0A=0D=0A=0D=0AAll that now said, = I remind folks that it has all along been possible to=0D=0Asign=0D=0Aa PIDF= -LO object using S/MIME; that's in the base standard. Anyone=0D=0Alooking=0D= =0Ato create method for carrying location with a signature has only to pick=0D= =0APIDF-LO as their format and that mechanism comes along for the ride.=0D=0A= That won't tell you who ought to sign it, when that signature out to be=0D=0A= checked,=0D=0Aor what actions to take when it fails, but as I understand it= folks want=0D=0Athat=0D=0Ato be a matter of policy anyway.=0D=0A=0D=0A=09=09= =09=09=09Ted=0D=0A=0D=0A=0D=0A_____________________________________________= __=0D=0AGeopriv mailing list=0D=0AGeopriv@ietf.org=0D=0Ahttps://www1.ietf.o= rg/mailman/listinfo/geopriv=0D=0A=0D=0A------------------------------------= ------------------------------------------------------------=0D=0AThis mess= age is for the designated recipient only and may=0D=0Acontain privileged, p= roprietary, or otherwise private information. =20=0D=0AIf you have received= it in error, please notify the sender=0D=0Aimmediately and delete the orig= inal. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A--------= ---------------------------------------------------------------------------= -------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 09 20:22:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPqHv-0006Fg-Pm; Fri, 09 Mar 2007 20:22:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPqHu-0006Fa-0E for geopriv@ietf.org; Fri, 09 Mar 2007 20:22:22 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPqHs-0001HE-BE for geopriv@ietf.org; Fri, 09 Mar 2007 20:22:21 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l2A1MFRD001306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Mar 2007 17:22:16 -0800 Received: from [71.204.158.100] (carbuncle.qualcomm.com [129.46.226.191]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2A1MEVm006576; Fri, 9 Mar 2007 17:22:15 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 9 Mar 2007 17:22:12 -0800 To: "Dawson, Martin" , "Andrew Newton" , "GEOPRIV WG" From: Ted Hardie Subject: RE: [Geopriv] Where we are / are we with L7-LCP Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org At 6:37 PM -0600 3/9/07, Dawson, Martin wrote: >Currently PSAPs can be called from anywhere in their service area and >they have processes and resources to deal with hoax calls. Not providing >them a mechanism to provide priority to calls arising from their service >area puts those processes and resources in peril by several orders of >magnitude. There is a precedent for the former and none for the latter. > Agreed, though I prefer the formulation I gave below, as it retains the distinction between network topology and service area that gives rise to this change. >It is quickly going to become common knowledge that a SIP call initiated >with a PIDF-LO value of your choosing can go to the emergency call >centre for that location. Unfortunately emergency calling is going to be >one of the first IP telephony location based routing services. We aren't >going to get the opportunity to find out how badly Pizza Hut gets >impacted first. > >Your argument is just another rehash of the "if it's not perfect than >it's not worth having." This is making perfect the enemy of good. > No, it isn't, and if you read it that way I obviously need to put more work into it. It's saying that the *real* goal is "help PSAPs limit attacks", not "help PSAPs limit callers to those within a service area". The latter is one among several possible strategies to achieve the first. >Signing the whole PIDF-LO per the S/MIME mechanism has been suggested >before. There are a couple of problems. > >1. The signature also needs to cover the time of applicability and the >unique LIS client identity. These aren't, currently, part of the >PIDF-LO. > What do you mean by LIS client identity? If you mean the client requesting the location, in what frame of reference is this going to be meaningful to a PSAP? Or do you really mean to take on the "vouch for the client" problem? If you do, I note you likely don't have to do anything to vouch for the location itself, as in that system you would have something directly traceable to the attacker. I am skeptical of that being developed or deployed, but having both is just needless. It is not at all clear how that would work, by the way, in a system in which the immediate service supplier (my home network, Qualcomm's enterprise, Peet's free wifi-using customer) validates the user's acceptance of the terms of service, but the upstream validates the location. There are lots of times when there is no unique user identity there even at the "retail" level-- maybe a MAC address associated with a hotspot, but no user-level identity; even where there is, the upstream is in no position to validate that identity, as it is the customer's customer. >2. There are parts of the PIDF-LO that should still be able to be >changed by the location object recipient and, potentially, some proxies. >If the signature applies to the whole object then this won't be >possible. > Adding PIDF-LO objects with the changes and retaining the original would be one way around that, but it consumes a lot of bytes. If you are going to permit proxies and recipients to change values, though, any system based on the originator's signature will have this problem. >In addition to the source of the location, the signature covers the time >of applicability of the location information and the identity of the LIS >client. These provide additional criteria for an automatic policy filter >to use depending on PSAP congestion. Without a signature mechanism, you >are dooming the PSAP operators - the human beings - to having to apply >those policies manually; if you get to that point you've already lost. > You seem to believe that the only strategy is the one in place now. That's not an attitude that has worked in other efforts to thwart DDoS. In particular, it ignores the fairly substantial amount of work on pattern-based responses. Those work off of the collection of attacking traffic, rather than individual flows, and they might well work here for DDoS. They will not thwart the random call from the teenager in Tennessee to the PSAP in California, playing an unfunny prank, but that is, honestly, not where I see the real danger lying. It likely will help in thwarting the zombie-host network of 10k unpatched PCs trying to bring down a PSAP, and it will likely help a lot more than forcing that PSAP into attempting the computationally expensive work of validating the cryptographic signatures on objects that were meant to be cachable and re-distributable in the first place. Ted >Cheers, >Martin > >-----Original Message----- >From: Ted Hardie [mailto:hardie@qualcomm.com] >Sent: Saturday, 10 March 2007 9:52 AM >To: Andrew Newton; GEOPRIV WG >Subject: Re: [Geopriv] Where we are / are we with L7-LCP > >At 2:44 PM -0500 3/9/07, Andrew Newton wrote: >>Finally, there is #3... by far the thorniest issue with many differing >views. Here is my attempt to enumerate the positions (putting aside any >IPR conversation): >> >> a) Those that don't support it. There are many reasons, from >complexity to disbelief about the use case to issues about >administrative overhead. >> >> b) Those that support it only for L7-LCP. >> >> c) Those that support it for all types location configuration >protocols. >> >> >> >>Have I missed any angles? >> >>-andy > >Hmm, my complex, nuanced view of the engineering and social trade-offs >between making it possible for anyone to call a PSAP and making it >possible for the PSAP to determine if the call's originator is in their >service >area seems to have collapsed into "don't support it". > > > >I don't think a) quite captures the issue I keep trying to raise. > >PSAPs want to limit the ability of attackers to use their resources. >One way they do that now is to limit who can talk to the PSAP to those >within their service area. > >PSAPs can no longer use network topology to identify who is in their >service >area. They would like to use something else. The location asserted by >the end user/network is used to identify a PSAP which serves the area, >but >the PSAPs are concerned that bad actors can assert false information to >discover/target PSAPs. They would like the information used in those >assertions to be vouched for by someone they trust or with whom they >can build trust, and the information to be carried through to the PSAP. > >Rather than have the clients doing the assertion being vouched for (now >*there's >a problem*), they want one piece of information in the assertion to be >vouched for--the location. If that is vouched for, the PSAP has higher >confidence >that the call is from someone within their service area; that means that >they are no more likely to be an attacker than they would be with the >existing system (which allows for attackers to call from within the >service >area). > >The issue that I'm raising is that while the primary aim,"limit the >ability of attackers >to use their resources", is laudable, useful, and strongly associated >with apple >pie, good beer, and the comic-book hero of your choice, doing so by >"limiting >the geographic range from which attacks may come" is only a strategy for >achieving it. There are other potential strategies (including things >like associative >IDS systems that do not work on single calls but work on patterns) that >might >be more effective at thwarting the efforts of attackers to consume PSAP >resources. >Recreating the old strategy in the new system might be possible (with a >large, >likely unfunded mandate), but it will take a lot of time and cruft to >get it going. >Balancing the effort that goes into this strategy has to be weighed >against whether >this strategy is effective in and of itself and whether it is the best >use of the >community's resources. > >Put another way, we need to focus on the real goal, rather than on >whether this >strategy is the right way to achieve it. Brian has been saying this in >some ways >all along, but I think we've been hearing him say "how else can I limit >callers >to a specific geographic area" rather than "how else can I preserve >PSAPs >against attackers looking to consume their resources." > > >All that now said, I remind folks that it has all along been possible to >sign >a PIDF-LO object using S/MIME; that's in the base standard. Anyone >looking >to create method for carrying location with a signature has only to pick >PIDF-LO as their format and that mechanism comes along for the ride. >That won't tell you who ought to sign it, when that signature out to be >checked, >or what actions to take when it fails, but as I understand it folks want >that >to be a matter of policy anyway. > > Ted > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 09 20:58: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 1HPqqK-000370-UJ; Fri, 09 Mar 2007 20:57:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPqqJ-00036u-MD for geopriv@ietf.org; Fri, 09 Mar 2007 20:57:55 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPqqJ-00068h-3k for geopriv@ietf.org; Fri, 09 Mar 2007 20:57:55 -0500 X-SEF-Processed: 5_0_0_910__2007_03_09_20_03_43 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); Fri, 09 Mar 2007 20:03:42 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 19:57:48 -0600 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: [Geopriv] Where we are / are we with L7-LCP Date: Fri, 9 Mar 2007 19:57:46 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Where we are / are we with L7-LCP Thread-Index: AcdisouHXY9Hd5PqTteP9uWC/LDy6AAAsQGg From: "Dawson, Martin" To: "Ted Hardie" , "Andrew Newton" , "GEOPRIV WG" X-OriginalArrivalTime: 10 Mar 2007 01:57:48.0245 (UTC) FILETIME=[80C79850:01C762B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I think that characterizing a PSAP the same as a web server and trying=0D=0A= to apply standard DDOS strategies to it will not work. Or rather, it=0D=0Aw= ill work, but I think that it is not sufficient without additional=0D=0Acri= teria being added to the heuristics and that includes an indication=0D=0Aof= location source, time, and client device identity.=0D=0A=0D=0AClient devic= e identity - We've had this discussion several times already=0D=0Aon this l= ist. I am not referring to the user identity; I am not=0D=0Areferring to a = VoIP client identity. I am referring to the presence of=0D=0Athe device on = the access network and the fact that, apart from working=0D=0Aout its locat= ion, the LIS can attribute a single identity to the target=0D=0Ait is calcu= lating location for. This is an anonymous identity - it is=0D=0A"identity" = in its truest abstract sense - uniqueness.=0D=0A=0D=0AThe inclusion of this= identity as part of the signature, allows the=0D=0Aautomatic heuristics to= detect multiple calls that are apparently coming=0D=0Afrom the same target= =2E=0D=0A=0D=0AYes - that's right, multiple devices on the other side of a = NAT will=0D=0Ahave the same identity as far as a LIS is concerned. That's a= second=0D=0Aorder discussion that speaks to how the heuristics need to ope= rate. It's=0D=0Aalso a factor in the question of whether an enterprise need= s its own LIS=0D=0Aor not - just how many concurrent requests to a service = is it reasonable=0D=0Ato expect it to be making (without it being reasonabl= e that some of them=0D=0Aget deprioritized relative to emergency calls orig= inating from other=0D=0Alocations).=0D=0A=0D=0AIn terms of signing just par= t of the PIDF-LO, the DSIG draft that has=0D=0Abeen referenced a couple of = times identifies those components that the=0D=0ALIS has something to say ab= out - primarily the location itself, and time=0D=0Aand the client identity = (as described above). This is how it is=0D=0Adifferent to just using S/MIME= =2E=0D=0A=0D=0AAn alternative is to use the assertion mechanism - the clien= t proffers=0D=0Aits PIDF-LO, the LIS sets the bits that it is concerned abo= ut and then=0D=0Asigns the whole thing with S/MIME. That's consistent with = using the same=0D=0Amechanism to validate location obtained from link layer= sources.=0D=0AHowever, this still locks the rest of the content away from = downstream=0D=0Aproxies.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Ori= ginal Message-----=0D=0AFrom: Ted Hardie [mailto:hardie@qualcomm.com]=20=0D= =0ASent: Saturday, 10 March 2007 12:22 PM=0D=0ATo: Dawson, Martin; Andrew N= ewton; GEOPRIV WG=0D=0ASubject: RE: [Geopriv] Where we are / are we with L7= -LCP=0D=0A=0D=0AAt 6:37 PM -0600 3/9/07, Dawson, Martin wrote:=0D=0A>Curren= tly PSAPs can be called from anywhere in their service area and=0D=0A>they = have processes and resources to deal with hoax calls. Not=0D=0Aproviding=0D= =0A>them a mechanism to provide priority to calls arising from their=0D=0As= ervice=0D=0A>area puts those processes and resources in peril by several or= ders of=0D=0A>magnitude. There is a precedent for the former and none for t= he latter.=0D=0A>=0D=0A=0D=0AAgreed, though I prefer the formulation I gave= below, as it retains the=0D=0Adistinction between network topology and ser= vice area that gives=0D=0Arise to this change.=0D=0A=0D=0A>It is quickly go= ing to become common knowledge that a SIP call=0D=0Ainitiated=0D=0A>with a = PIDF-LO value of your choosing can go to the emergency call=0D=0A>centre fo= r that location. Unfortunately emergency calling is going to=0D=0Abe=0D=0A>= one of the first IP telephony location based routing services. We=0D=0Aaren= 't=0D=0A>going to get the opportunity to find out how badly Pizza Hut gets=0D= =0A>impacted first.=0D=0A>=0D=0A>Your argument is just another rehash of th= e "if it's not perfect than=0D=0A>it's not worth having." This is making pe= rfect the enemy of good.=0D=0A>=0D=0A=0D=0ANo, it isn't, and if you read it= that way I obviously need to put more=0D=0Awork into it. It's saying that= the *real* goal is "help PSAPs limit=0D=0Aattacks", not "help PSAPs limit = callers to those within a service area".=0D=0AThe latter is one among sever= al possible strategies to achieve the=0D=0Afirst.=0D=0A=0D=0A>Signing the w= hole PIDF-LO per the S/MIME mechanism has been suggested=0D=0A>before. Ther= e are a couple of problems.=0D=0A>=0D=0A>1. The signature also needs to cov= er the time of applicability and the=0D=0A>unique LIS client identity. Thes= e aren't, currently, part of the=0D=0A>PIDF-LO.=0D=0A>=0D=0A=0D=0AWhat do y= ou mean by LIS client identity=3F If you mean the client=0D=0Arequesting=0D= =0Athe location, in what frame of reference is this going to be meaningful=0D= =0Ato=0D=0Aa PSAP=3F Or do you really mean to take on the "vouch for the c= lient"=0D=0Aproblem=3F=0D=0AIf you do, I note you likely don't have to do a= nything to vouch for the=0D=0Alocation=0D=0Aitself, as in that system you w= ould have something directly traceable to=0D=0Athe=0D=0Aattacker. I am ske= ptical of that being developed or deployed, but=0D=0Ahaving=0D=0Aboth is ju= st needless.=0D=0A=0D=0AIt is not at all clear how that would work, by the = way, in a system in=0D=0Awhich=0D=0Athe immediate service supplier (my home= network, Qualcomm's enterprise,=0D=0APeet's free wifi-using customer) vali= dates the user's acceptance of the=0D=0Aterms=0D=0Aof service, but the upst= ream validates the location. There are lots of=0D=0Atimes=0D=0Awhen there = is no unique user identity there even at the "retail" level--=0D=0Amaybe a = MAC address associated with a hotspot, but no user-level=0D=0Aidentity;=0D=0A= even where there is, the upstream is in no position to validate that=0D=0Ai= dentity,=0D=0Aas it is the customer's customer.=0D=0A=0D=0A>2. There are pa= rts of the PIDF-LO that should still be able to be=0D=0A>changed by the loc= ation object recipient and, potentially, some=0D=0Aproxies.=0D=0A>If the si= gnature applies to the whole object then this won't be=0D=0A>possible.=0D=0A= >=0D=0A=0D=0AAdding PIDF-LO objects with the changes and retaining the ori= ginal=0D=0Awould be one way around that, but it consumes a lot of bytes. I= f=0D=0Ayou are going to permit proxies and recipients to change values,=0D=0A= though, any system based on the originator's signature will have this=0D=0A= problem.=0D=0A=0D=0A>In addition to the source of the location, the signatu= re covers the=0D=0Atime=0D=0A>of applicability of the location information = and the identity of the=0D=0ALIS=0D=0A>client. These provide additional cri= teria for an automatic policy=0D=0Afilter=0D=0A>to use depending on PSAP co= ngestion. Without a signature mechanism, you=0D=0A>are dooming the PSAP ope= rators - the human beings - to having to apply=0D=0A>those policies manuall= y; if you get to that point you've already lost.=0D=0A>=0D=0A=0D=0AYou seem= to believe that the only strategy is the one in place now.=0D=0AThat's=0D=0A= not an attitude that has worked in other efforts to thwart DDoS. In=0D=0Ap= articular,=0D=0Ait ignores the fairly substantial amount of work on pattern= -based=0D=0Aresponses.=0D=0AThose work off of the collection of attacking t= raffic, rather than=0D=0Aindividual=0D=0Aflows, and they might well work he= re for DDoS. They will not thwart the=0D=0Arandom call from the teenager i= n Tennessee to the PSAP in California,=0D=0Aplaying an unfunny prank, but t= hat is, honestly, not where I see the=0D=0Areal=0D=0Adanger lying. It likel= y will help in thwarting the zombie-host network=0D=0Aof=0D=0A10k unpatched= PCs trying to bring down a PSAP, and it will likely help a=0D=0Alot more t= han forcing that PSAP into attempting the computationally=0D=0Aexpensive wo= rk of validating the cryptographic signatures on objects=0D=0Athat were mea= nt to be cachable and re-distributable in the first place.=0D=0A=0D=0A=09=09= =09Ted=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A>Cheers,=0D=0A>Martin=0D=0A>=0D=0A>----= -Original Message-----=0D=0A>From: Ted Hardie [mailto:hardie@qualcomm.com]=0D= =0A>Sent: Saturday, 10 March 2007 9:52 AM=0D=0A>To: Andrew Newton; GEOPRIV = WG=0D=0A>Subject: Re: [Geopriv] Where we are / are we with L7-LCP=0D=0A>=0D= =0A>At 2:44 PM -0500 3/9/07, Andrew Newton wrote:=0D=0A>>Finally, there is = #3... by far the thorniest issue with many differing=0D=0A>views. Here is = my attempt to enumerate the positions (putting aside=0D=0Aany=0D=0A>IPR con= versation):=0D=0A>>=0D=0A>> a) Those that don't support it. There are man= y reasons, from=0D=0A>complexity to disbelief about the use case to issues = about=0D=0A>administrative overhead.=0D=0A>>=0D=0A>> b) Those that support= it only for L7-LCP.=0D=0A>>=0D=0A>> c) Those that support it for all type= s location configuration=0D=0A>protocols.=0D=0A>>=0D=0A>>=0D=0A>>=0D=0A>>Ha= ve I missed any angles=3F=0D=0A>>=0D=0A>>-andy=0D=0A>=0D=0A>Hmm, my complex= , nuanced view of the engineering and social trade-offs=0D=0A>between makin= g it possible for anyone to call a PSAP and making it=0D=0A>possible for th= e PSAP to determine if the call's originator is in their=0D=0A>service=0D=0A= >area seems to have collapsed into "don't support it".=0D=0A>=0D=0A>=0D=0A>=0D=0A>I don't think a) quite captures the= issue I keep trying to raise.=0D=0A>=0D=0A>PSAPs want to limit the ability= of attackers to use their resources.=0D=0A>One way they do that now is to = limit who can talk to the PSAP to those=0D=0A>within their service area.=0D= =0A>=0D=0A>PSAPs can no longer use network topology to identify who is in t= heir=0D=0A>service=0D=0A>area. They would like to use something else. The= location asserted by=0D=0A>the end user/network is used to identify a PSA= P which serves the area,=0D=0A>but=0D=0A>the PSAPs are concerned that bad a= ctors can assert false information to=0D=0A>discover/target PSAPs. They wo= uld like the information used in those=0D=0A>assertions to be vouched for b= y someone they trust or with whom they=0D=0A>can build trust, and the infor= mation to be carried through to the PSAP.=0D=0A>=0D=0A>Rather than have the= clients doing the assertion being vouched for (now=0D=0A>*there's=0D=0A>a = problem*), they want one piece of information in the assertion to be=0D=0A>= vouched for--the location. If that is vouched for, the PSAP has higher=0D=0A= >confidence=0D=0A>that the call is from someone within their service area; = that means=0D=0Athat=0D=0A>they are no more likely to be an attacker than t= hey would be with the=0D=0A>existing system (which allows for attackers to = call from within the=0D=0A>service=0D=0A>area).=0D=0A>=0D=0A>The issue that= I'm raising is that while the primary aim,"limit the=0D=0A>ability of atta= ckers=0D=0A>to use their resources", is laudable, useful, and strongly asso= ciated=0D=0A>with apple=0D=0A>pie, good beer, and the comic-book hero of y= our choice, doing so by=0D=0A>"limiting=0D=0A>the geographic range from wh= ich attacks may come" is only a strategy=0D=0Afor=0D=0A>achieving it. Ther= e are other potential strategies (including things=0D=0A>like associative=0D= =0A>IDS systems that do not work on single calls but work on patterns) that=0D= =0A>might=0D=0A>be more effective at thwarting the efforts of attackers to = consume PSAP=0D=0A>resources.=0D=0A>Recreating the old strategy in the new = system might be possible (with a=0D=0A>large,=0D=0A>likely unfunded mandate= ), but it will take a lot of time and cruft to=0D=0A>get it going.=0D=0A>B= alancing the effort that goes into this strategy has to be weighed=0D=0A>ag= ainst whether=0D=0A>this strategy is effective in and of itself and whether= it is the best=0D=0A>use of the=0D=0A>community's resources.=0D=0A>=0D=0A>= Put another way, we need to focus on the real goal, rather than on=0D=0A>wh= ether this=0D=0A>strategy is the right way to achieve it. Brian has been s= aying this in=0D=0A>some ways=0D=0A>all along, but I think we've been heari= ng him say "how else can I limit=0D=0A>callers=0D=0A>to a specific geograph= ic area" rather than "how else can I preserve=0D=0A>PSAPs=0D=0A>against att= ackers looking to consume their resources."=0D=0A>=0D=0A>=0D=0A>All that no= w said, I remind folks that it has all along been possible=0D=0Ato=0D=0A>si= gn=0D=0A>a PIDF-LO object using S/MIME; that's in the base standard. Anyon= e=0D=0A>looking=0D=0A>to create method for carrying location with a signatu= re has only to=0D=0Apick=0D=0A>PIDF-LO as their format and that mechanism c= omes along for the ride.=0D=0A>That won't tell you who ought to sign it, wh= en that signature out to be=0D=0A>checked,=0D=0A>or what actions to take wh= en it fails, but as I understand it folks=0D=0Awant=0D=0A>that=0D=0A>to be = a matter of policy anyway.=0D=0A>=0D=0A>=09=09=09=09=09Ted=0D=0A>=0D=0A>=0D= =0A>_______________________________________________=0D=0A>Geopriv mailing l= ist=0D=0A>Geopriv@ietf.org=0D=0A>https://www1.ietf.org/mailman/listinfo/geo= priv=0D=0A>=0D=0A>---------------------------------------------------------= --------------=0D=0A-------------------------=0D=0A>This message is for the= designated recipient only and may=0D=0A>contain privileged, proprietary, o= r otherwise private information.=20=0D=0A>If you have received it in error,= please notify the sender=0D=0A>immediately and delete the original. Any u= nauthorized use of=0D=0A>this email is prohibited.=0D=0A>------------------= -----------------------------------------------------=0D=0A----------------= ---------=0D=0A>[mf2]=0D=0A>=0D=0A>=0D=0A>_________________________________= ______________=0D=0A>Geopriv mailing list=0D=0A>Geopriv@ietf.org=0D=0A>http= s://www1.ietf.org/mailman/listinfo/geopriv=0D=0A=0D=0A=0D=0A---------------= ---------------------------------------------------------------------------= ------=0D=0AThis message is for the designated recipient only and may=0D=0A= contain privileged, proprietary, or otherwise private information. =20=0D=0A= If you have received it in error, please notify the sender=0D=0Aimmediately= and delete the original. Any unauthorized use of=0D=0Athis email is prohi= bited.=0D=0A---------------------------------------------------------------= ---------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 09 21:05: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 1HPqxp-0004dd-M5; Fri, 09 Mar 2007 21:05:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPqxp-0004dX-26 for geopriv@ietf.org; Fri, 09 Mar 2007 21:05:41 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPqxn-00073R-3m for geopriv@ietf.org; Fri, 09 Mar 2007 21:05:41 -0500 Received: from [192.168.0.41] (pool-141-153-174-50.mad.east.verizon.net [141.153.174.50]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2A25TVO021694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 9 Mar 2007 21:05:30 -0500 (EST) 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: <385EA9CA-151C-4333-A41B-CF6F3ECE6775@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Where we are / are we with L7-LCP Date: Fri, 9 Mar 2007 21:05:29 -0500 To: "Dawson, Martin" 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: d6b246023072368de71562c0ab503126 Cc: Ted Hardie , GEOPRIV WG , Andrew Newton X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org > > Client device identity - We've had this discussion several times > already > on this list. I am not referring to the user identity; I am not > referring to a VoIP client identity. I am referring to the presence of > the device on the access network and the fact that, apart from working > out its location, the LIS can attribute a single identity to the > target > it is calculating location for. This is an anonymous identity - it is > "identity" in its truest abstract sense - uniqueness. Unless you are worried about lots of devices at one physical address (which are likely behind one NAT), I don't see how this adds significant value. Also, the PIDF-LO already contains such an identity (entity), if you really want it. Similarly, the validity periods is also already in PIDF (expires). _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 09 23:30: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 1HPtDe-0006tU-4l; Fri, 09 Mar 2007 23:30:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPtDb-0006sb-0H for geopriv@ietf.org; Fri, 09 Mar 2007 23:30:08 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPtDZ-0004pu-OK for geopriv@ietf.org; Fri, 09 Mar 2007 23:30:06 -0500 X-SEF-Processed: 5_0_0_910__2007_03_09_22_36_00 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); Fri, 09 Mar 2007 22:35:59 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 22:30:05 -0600 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: [Geopriv] Where we are / are we with L7-LCP Date: Fri, 9 Mar 2007 22:30:03 -0600 Message-ID: In-Reply-To: <385EA9CA-151C-4333-A41B-CF6F3ECE6775@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Where we are / are we with L7-LCP Thread-Index: AcdiuJcIkzxKMgzmTx6XvKin/a1wxgAE0/Rw From: "Dawson, Martin" To: "Henning Schulzrinne" X-OriginalArrivalTime: 10 Mar 2007 04:30:05.0086 (UTC) FILETIME=[C6C2E3E0:01C762CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Ted Hardie , GEOPRIV WG , Andrew Newton X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org The opposite - I'm concerned about just one device making lots of calls=0D=0A= using different CLIs and VoIP service identities. The LIS is capable of=0D=0A= marking the location objects as being associated with the same physical=0D=0A= device regardless of how they appear as phone calls. I have no problem=0D=0A= with using an existing information element as long as this use isn't=0D=0Ac= ontrary to what that information element is intended for.=0D=0A=0D=0AI'm no= t so sure about "expires". I would prefer to see the time at which=0D=0Athe= location was actually associated with the device and let the=0D=0Arecipien= t apply their own policy about what constitutes expiry. Does the=0D=0Aprofi= le have that.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Messa= ge-----=0D=0AFrom: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20=0D=0A= Sent: Saturday, 10 March 2007 1:05 PM=0D=0ATo: Dawson, Martin=0D=0ACc: Ted = Hardie; Andrew Newton; GEOPRIV WG=0D=0ASubject: Re: [Geopriv] Where we are = / are we with L7-LCP=0D=0A=0D=0A>=0D=0A> Client device identity - We've had= this discussion several times =20=0D=0A> already=0D=0A> on this list. I am= not referring to the user identity; I am not=0D=0A> referring to a VoIP cl= ient identity. I am referring to the presence of=0D=0A> the device on the a= ccess network and the fact that, apart from working=0D=0A> out its location= , the LIS can attribute a single identity to the =20=0D=0A> target=0D=0A> i= t is calculating location for. This is an anonymous identity - it is=0D=0A>= "identity" in its truest abstract sense - uniqueness.=0D=0A=0D=0AUnless yo= u are worried about lots of devices at one physical address =20=0D=0A(which= are likely behind one NAT), I don't see how this adds =20=0D=0Asignificant= value.=0D=0A=0D=0AAlso, the PIDF-LO already contains such an identity (ent= ity), if you =20=0D=0Areally want it.=0D=0A=0D=0ASimilarly, the validity pe= riods is also already in PIDF (expires).=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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 03:41:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPx83-0002tD-2x; Sat, 10 Mar 2007 03:40:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPx81-0002qP-9q for geopriv@ietf.org; Sat, 10 Mar 2007 03:40:37 -0500 Received: from [2001:858:745:a0e4:20b:dbff:fe95:d83a] (helo=sil1.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPx7k-0006iF-K4 for geopriv@ietf.org; Sat, 10 Mar 2007 03:40:37 -0500 Received: from [86.59.64.45] (helo=[192.168.0.133]) by sil1.mah.priv.at with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1HPx7Y-0003Te-3R; Sat, 10 Mar 2007 09:40:08 +0100 In-Reply-To: <45F1CA41.4030806@bbn.com> References: <33E5EEC5-667C-49C2-87AA-90A3DD1C97C2@hxr.us> <45F1CA41.4030806@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: Michael Haberler Date: Sat, 10 Mar 2007 09:40:03 +0100 To: Richard Barnes X-Mailer: Apple Mail (2.752.3) X-SA-Exim-Connect-IP: 86.59.64.45 X-SA-Exim-Mail-From: mah@inode.at X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on sil1.mah.priv.at X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7-deb Subject: Re: [Geopriv] Brian Rosen on location signing X-SA-Exim-Version: 4.2.1 (built Tue, 09 Jan 2007 17:23:22 +0000) X-SA-Exim-Scanned: Yes (on sil1.mah.priv.at) X-Spam-Score: -2.8 (--) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: GEOPRIV WG , Andrew Newton X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I would second Brian on signing as well. I've done a back-of-the-envelope calculation - 10 certificates would cover more than 97% of all IP-capable public access in Austria. That approach looks manageable - thanks to PSAP/access locality (and market consolidation ;-). As for the corporate network and occasional access point - well a certificate with *some* local recognition already helps, I dont think every plastic box needs a cert from the PSAP CA proper. It's an 80/20 thing - or more like to give 99/1 with modest effort. -Michael I'd love a check "I have set up my new access point and added a certificate - I click the "verify setup" button and would see if/how much the signed location would be trusted". how could that be done? Am 09.03.2007 um 21:57 schrieb Richard Barnes: > I would second Brian on those points. If we can agree that signed > location objects are useful, then we should have a signed location > object structure that's common across protocols, just like PIDF-LO > is used for location across protocols. > --RB > > Andrew Newton wrote: >> Since I just spent the last half hour reviewing the mailing list >> traffic on location signing in my role as co-chair, I found that >> Brian Rosen made a couple of points that were very interesting but >> also lightly supported. And I tend to wonder why, since he >> supports location signing. >> Point 1. Location signing is much more than an L7-LCP issue. It >> also changes location conveyance and de-referenced locations. Is >> there anybody that disagrees with this? Do participants realize >> this? >> Point 2. Brian has asserted that location signing should be >> applied to all location configuration protocols, not just L7-LCP. >> His assertion is that location signing for the emergency use case >> is applicable no matter how a UA acquires their location >> information. This brings up the question, if the other proponents >> of location signing feel it is important to deter spoofing, DoS, >> etc, why isn't location signing always important no matter how it >> is required? >> -andy >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 07:55:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ15d-0006Oh-4y; Sat, 10 Mar 2007 07:54:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ15b-0006Ob-N3 for geopriv@ietf.org; Sat, 10 Mar 2007 07:54:23 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ15a-0000C3-Bm for geopriv@ietf.org; Sat, 10 Mar 2007 07:54:23 -0500 X-SEF-Processed: 5_0_0_910__2007_03_10_07_00_16 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); Sat, 10 Mar 2007 07:00:16 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Mar 2007 06:54:21 -0600 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: [Geopriv] Brian Rosen on location signing Date: Sat, 10 Mar 2007 06:54:18 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Brian Rosen on location signing Thread-Index: Acdi8CGA4hr+dklbQMeId3nZvYql/gAIXUZA From: "Dawson, Martin" To: "Michael Haberler" , "Richard Barnes" X-OriginalArrivalTime: 10 Mar 2007 12:54:21.0555 (UTC) FILETIME=[3905AC30:01C76313] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: GEOPRIV WG , Andrew Newton X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Michael,=0D=0A=0D=0AHow are you connecting your access point to the Inte= rnet=3F If it's with a=0D=0Apublic provider, you probably don't need to do = anything with=0D=0Acertificates. Devices will discover the provider's LIS a= nd it will look=0D=0Aafter getting the location signed. Oh - I see, you're = talking about a=0D=0Apublic provider setting up a point of access - presuma= bly for the first=0D=0Atime with LIS functionality=3F=0D=0A=0D=0AAs for an = automatic test - yes, that would be nice. In testing 9-1-1 for=0D=0Acellula= r these days, we (including the cellular operator) have to set up=0D=0Aa fa= ir bit of infrastructure and network configuration to be able to=0D=0Adial = an emergency call from arbitrary network locations and test as much=0D=0Aof= the emergency application (call initiation, location determination,=0D=0Ar= outing, and location reporting) as possible without actually bothering=0D=0A= the PSAPs.=0D=0A=0D=0AIt would certainly be nice if you could do an "emerge= ncy services" ping=0D=0Athat did everything other than bother any humans - = perhaps get a report=0D=0Aback indicating where it thought you were, who yo= ur network provider=0D=0Awas, if your location information looked valid and= trusted and anything=0D=0Aelse they thought would be safe to tell you.=0D=0A=0D= =0AAll of which would have been a more appropriate aside for the ECRIT list=0D= =0AI suppose.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Messa= ge-----=0D=0AFrom: Michael Haberler [mailto:mah@inode.at]=20=0D=0ASent: Sat= urday, 10 March 2007 7:40 PM=0D=0ATo: Richard Barnes=0D=0ACc: GEOPRIV WG; A= ndrew Newton=0D=0ASubject: Re: [Geopriv] Brian Rosen on location signing=0D= =0A=0D=0AI would second Brian on signing as well.=0D=0A=0D=0AI've done a ba= ck-of-the-envelope calculation - 10 certificates would =20=0D=0Acover more = than 97% of all IP-capable public access in Austria. That =20=0D=0Aapproac= h looks manageable - thanks to PSAP/access locality (and =20=0D=0Amarket c= onsolidation ;-).=0D=0A=0D=0AAs for the corporate network and occasional ac= cess point - well a =20=0D=0Acertificate with *some* local recognition alre= ady helps, I dont think =20=0D=0Aevery plastic box needs a cert from the PS= AP CA proper. It's an 80/20 =20=0D=0Athing - or more like to give 99/1 with= modest effort.=0D=0A=0D=0A-Michael=0D=0A=0D=0AI'd love a check "I have se= t up my new access point and added a =20=0D=0Acertificate - I click the "ve= rify setup" button and would see if/how =20=0D=0Amuch the signed location w= ould be trusted". how could that be done=3F=0D=0A=0D=0A=0D=0A=0D=0AAm 09.03= =2E2007 um 21:57 schrieb Richard Barnes:=0D=0A=0D=0A> I would second Brian = on those points. If we can agree that signed =20=0D=0A> location objects a= re useful, then we should have a signed location =20=0D=0A> object structur= e that's common across protocols, just like PIDF-LO =20=0D=0A> is used for = location across protocols.=0D=0A> --RB=0D=0A>=0D=0A> Andrew Newton wrote:=0D= =0A>> Since I just spent the last half hour reviewing the mailing list =20=0D= =0A>> traffic on location signing in my role as co-chair, I found that =20=0D= =0A>> Brian Rosen made a couple of points that were very interesting but =0D= =0A>> also lightly supported. And I tend to wonder why, since he =20=0D=0A= >> supports location signing.=0D=0A>> Point 1. Location signing is much mor= e than an L7-LCP issue. It =20=0D=0A>> also changes location conveyance an= d de-referenced locations. Is =20=0D=0A>> there anybody that disagrees wit= h this=3F Do participants realize =20=0D=0A>> this=3F=0D=0A>> Point 2. Bri= an has asserted that location signing should be =20=0D=0A>> applied to all = location configuration protocols, not just L7-LCP. =20=0D=0A>> His asserti= on is that location signing for the emergency use case =20=0D=0A>> is appli= cable no matter how a UA acquires their location =20=0D=0A>> information. = This brings up the question, if the other proponents =20=0D=0A>> of locatio= n signing feel it is important to deter spoofing, DoS, =20=0D=0A>> etc, why= isn't location signing always important no matter how it =20=0D=0A>> is re= quired=3F=0D=0A>> -andy=0D=0A>> ___________________________________________= ____=0D=0A>> Geopriv mailing list=0D=0A>> Geopriv@ietf.org=0D=0A>> https://= www1.ietf.org/mailman/listinfo/geopriv=0D=0A>=0D=0A>=0D=0A> _______________= ________________________________=0D=0A> Geopriv mailing list=0D=0A> Geopriv= @ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A=0D=0A=0D= =0A_______________________________________________=0D=0AGeopriv mailing lis= t=0D=0AGeopriv@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/listinfo/geopriv=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 08:10: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 1HQ1LI-0005l4-30; Sat, 10 Mar 2007 08:10:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ1LG-0005kR-Ph for geopriv@ietf.org; Sat, 10 Mar 2007 08:10:34 -0500 Received: from [2001:858:745:a0e4:20b:dbff:fe95:d83a] (helo=sil1.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ1LD-0004FL-8G for geopriv@ietf.org; Sat, 10 Mar 2007 08:10:34 -0500 Received: from [86.59.64.45] (helo=[192.168.0.133]) by sil1.mah.priv.at with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1HQ1L7-0003gi-Ps; Sat, 10 Mar 2007 14:10:26 +0100 In-Reply-To: References: 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: Michael Haberler Date: Sat, 10 Mar 2007 14:10:21 +0100 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.3) X-SA-Exim-Connect-IP: 86.59.64.45 X-SA-Exim-Mail-From: mah@inode.at X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on sil1.mah.priv.at X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7-deb Subject: Re: [Geopriv] Brian Rosen on location signing X-SA-Exim-Version: 4.2.1 (built Tue, 09 Jan 2007 17:23:22 +0000) X-SA-Exim-Scanned: Yes (on sil1.mah.priv.at) X-Spam-Score: -2.8 (--) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Am 10.03.2007 um 13:54 schrieb Dawson, Martin: > Hi Michael, > > How are you connecting your access point to the Internet? If it's > with a > public provider, you probably don't need to do anything with > certificates. Devices will discover the provider's LIS and it will > look You are right. I was implicitely thinking about an standalone early deployment/demo scenario. Takeup with access providers will take its time, and it might be handy to have say an OpenWRT package to demo/deploy the whole chain without assuming public provider LIS availability. That could be turned off eventually. -Michael _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 08:55:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ22Q-0000Gt-J8; Sat, 10 Mar 2007 08:55:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ22L-000052-51 for geopriv@ietf.org; Sat, 10 Mar 2007 08:55:05 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ1yl-0006bo-TP for geopriv@ietf.org; Sat, 10 Mar 2007 08:51:26 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HQ1yd-0005Ng-Nn; Sat, 10 Mar 2007 07:51:16 -0600 From: "Brian Rosen" To: "'Michael Haberler'" , "'Richard Barnes'" Subject: RE: [Geopriv] Brian Rosen on location signing Date: Sat, 10 Mar 2007 08:51:19 -0500 Message-ID: <081e01c7631b$303f4c70$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Acdi79X6n0Gh7We1REyqfVc9ehz9ngAKwR3Q 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: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: 'GEOPRIV WG' , 'Andrew Newton' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org > I'd love a check "I have set up my new access point and added a > certificate - I click the "verify setup" button and would see if/how > much the signed location would be trusted". how could that be done? Please see "Chapter 13 Testing" in draft-ietf-ecrit-framework-01 Probably we need some more error resolution. _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 14:45:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ7VH-0001PA-SP; Sat, 10 Mar 2007 14:45:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ7VH-0001P4-9Y for geopriv@ietf.org; Sat, 10 Mar 2007 14:45:19 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQ7VF-0008Oe-Tx for geopriv@ietf.org; Sat, 10 Mar 2007 14:45:19 -0500 Received: (qmail invoked by alias); 10 Mar 2007 19:45:16 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp020) with SMTP; 10 Mar 2007 20:45:16 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19kidg4G5pk3U24p9mDNujiwna+M4s093AbOIQlHx mcy8ADL1cKf+zB Message-ID: <45F30AC9.5000304@gmx.net> Date: Sat, 10 Mar 2007 21:45:13 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: jerome.grenier@bell.ca References: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A027236@toroondc912><7582BC68E4994F4ABF0BD4723975C3FA0268D983@crexc41p><8668B32D-DA78-4D46-A300-977B47DFECB0@hxr.us><7582BC68E4994F4ABF0BD4723975C3FA0268D98A@crexc41p><20070214102924.GA19828@nic.at><6B623AF5-0590-4B4D-9FC8-128CAFF7F6E6@hxr.us><20070214163901.GA27679@nic.at><86A33432-51F1-4CAB-9F7E-70715907A358@hxr.us><7582BC68E4994F4ABF0BD4723975C3FA0268D996@crexc41p><7582BC68E4994F4ABF0BD4723975C3FA0268D999@crexc41p><04E35B55-6446-436B-B6AE-751EDAC0885F@hxr.us> <7582BC68E4994F4ABF0BD4723975C3FA0268D9A0@crexc41p> <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A0276AC@toroondc912> In-Reply-To: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A0276AC@toroondc912> 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: 9466e0365fc95844abaf7c3f15a05c7d Cc: geopriv@ietf.org, Barbara.Stark@BellSouth.com, lendl@nic.at, andy@hxr.us Subject: [Geopriv] Geopriv L7 LCP: New Requirement: Summary X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi all, I went through the mailing list discussion and here is my summary with the respect to the impact for the . If we would add this new requirement to the draft then the following additions are needed: * Terminology: It might be useful to add LIS-to-LIS (and maybe OBO) terminology. The discussions focused mostly on LIS-to-LIS. * Maybe add an architecture figure that describes the concept. Not needed but could be helpful for the reader (I think). * Requirements: I believe that requirement L7-1 covers the functionality already but one might want to be more explicit by saying - the request for location information needs to be able to support other forms of client identifiers than the IP address (typically access technology dependent) - multiple identifiers may be added to the request I couldn't see any other new requirement. Ciao Hannes PS: From a solution point of view I noticed there is the classical protocol choice dispute. The SIP functionality is already RFC or very close in the progress but some folks favor an HTTP based approach. _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 14:53:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ7d1-0004Wf-Fx; Sat, 10 Mar 2007 14:53:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ7d0-0004Wa-Gu for geopriv@ietf.org; Sat, 10 Mar 2007 14:53:18 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQ7cy-0001m6-Tx for geopriv@ietf.org; Sat, 10 Mar 2007 14:53:18 -0500 Received: (qmail invoked by alias); 10 Mar 2007 19:46:36 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp034) with SMTP; 10 Mar 2007 20:46:36 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+vyGMYq5KvBIkbrHmx6R9AnmheAxHwVbTK3xvaSb nZnw5pgMoW9cnw Message-ID: <45F30B1B.9030205@gmx.net> Date: Sat, 10 Mar 2007 21:46:35 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: GEOPRIV 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: 79899194edc4f33a41f49410777972f8 Subject: [Geopriv] I am not amused. X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi all, I am reading through all the comments we received for the draft. I am not amused about the way how the work in the design team (and subsequently) was done. I chaired the design team and I asked everyone to put their requirements on the table. Some folks, however, decided not todo so. The document that was developed in the working group was sent to the working group and 4 versions got published, got presented during the face-to-face meetings and nobody recognized that some of their requirements were not met. Instead, the requirements are being brought up during the WGLC. The same people complain about the slow progress. Isn't that interesting? Ciao Hannes _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 14:53:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ7dU-0005Wa-Pd; Sat, 10 Mar 2007 14:53:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ7dT-0005W4-6k for geopriv@ietf.org; Sat, 10 Mar 2007 14:53:47 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQ7dP-0001uJ-Rf for geopriv@ietf.org; Sat, 10 Mar 2007 14:53:47 -0500 Received: (qmail invoked by alias); 10 Mar 2007 19:47:01 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp039) with SMTP; 10 Mar 2007 20:47:01 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/3TEteWAD3kJm3XT+v1ASDf9wTxj1JMtF5MKRjY0 fVJL8bQApwAs6D Message-ID: <45F30B32.9050901@gmx.net> Date: Sat, 10 Mar 2007 21:46:58 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Richard Barnes Subject: Re: [Geopriv] Naive question: LCP == LbyR? References: <45E320D7.4080301@bbn.com> In-Reply-To: <45E320D7.4080301@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: 73734d43604d52d23b3eba644a169745 Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Richard, you raised a very good question and I have a short story for you. Other SDOs look at the location-based services in a different fashion by assuming that the network understands the application. Consider the 3GPP IMS emergency service architecture as one more detailed example. You need a protocol to fetch the location of an end host. The identification of the end host for location determination might use a variety of different identifiers, as we all know (MAC address, IP address, etc. see draft-ietf-geopriv-l7-lcp-ps-00.txt). The end host provides these identifier via, for example, SIP signaling to the respective nodes that perform the lookup. No new identifier needs to be "invented" there since the existing onces do the job, namely the identifiers are resolvable to the location of the end host within this given realm. Now, we have assumed a different architecture where the entity that needs todo the lookup is from a different identifier realm (i.e., it cannot resolve the existing identifiers to the location of the end host). (Note that by realm I mean that an identifier has a specific validity domain and semantic within this domain. We phrased this quite fuzzy, for example, by saying that the LIS is in the access network and somehow knows how to determine the location of the end host even though we encountered cases where this is not true.) What did we do? We came up with a different identifier that has a much larger validity domain, a SIP URI or an HTTP URI. This is not a big thing but quite important. This identifier that is used as a replacement of other identifiers that have a limited scope allows everyone on the Internet (with some assumptions behind it) to perform the lookup and to determine the location of the end host. Ironically, if you demand authorization for the resolution process you almost destroy all benefits of the newly introduced new identifier since you artificially re-create the relationship between the entity that is able to perform the resolution and the entity that knows where the end host is. So, how does this all relate to your question regarding LCP == LbyR? Ignoring some terminology aspects, and comparing LCP that retrieves an LO based on IP address/MAC address/etc. and a protocol that uses an HTTP reference to retrieve an LO one might notice that they do very similar, if not the same things (ignoring the scope of the identifier validity). Does this make sense? Ciao Hannes Richard Barnes wrote: > I've got a simple question, that's basically captured by the subject > line: What's the difference between a Location Configuration Protocol > and an L-by-R Dereference Protocol? Compare two use cases: > > LCP: > Step 1. Discover LIS > Step 2. Send query to LIS > Step 3. Receive LO / URL > > L-by-R: > Step 1. Receive location URL > Step 2. Send query to dereference server > Step 3. Receive LO / URL > > I realize that with an LCP, there's a additional need to identify the > target, but it seems just as easy to embed this into a URI or > dereference request as to use another protocol mechanism. And it > seems like using a single protocol for both would save us all some > time and effort. > > Cheers, > --Richard > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 14:54:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ7dr-0005jQ-D0; Sat, 10 Mar 2007 14:54:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ7dp-0005jD-W3 for geopriv@ietf.org; Sat, 10 Mar 2007 14:54:09 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQ7dl-0001yO-Gk for geopriv@ietf.org; Sat, 10 Mar 2007 14:54:09 -0500 Received: (qmail invoked by alias); 10 Mar 2007 19:47:22 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp045) with SMTP; 10 Mar 2007 20:47:22 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19Hq4gyMXtHG5Q9FTGGyg6CUpXnl2m5B6ywVBc1Ty W9lv++qtecNk1x Message-ID: <45F30B49.90700@gmx.net> Date: Sat, 10 Mar 2007 21:47:21 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: GEOPRIV Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Subject: [Geopriv] NENA Requirements X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Some reviewers of note that the requirements in http://www.nena.org/media/files/08-505_20061221.pdf also have to be considered. Interestingly, this document was published long after the design team work took place were these requirements could have been introduced. Here are the requirements and I will copy them in a separate mail: 4 Requirements These requirements are excerpted from the NENA TRD, NENA Requirements for Location Information to Support Emergency Services, for the convenience of the reader. If this document should inadvertently differ from the TRD, the TRD is to be considered the normative reference. As defined in the TRD, and as excerpted here, the terms "shall", "must ", and "required" are used in this section to indicate requirements and to differentiate from those parameters that are recommendations. Recommendations are identified by the word �should.� Optional, desirable capabilities are identified by the words "desirable" or "preferably". 4.1 Location Determination and Acquisition DA1 � The access network shall provide a mechanism for determination and acquisition of location information, and support queries for location. DA2 � The location estimate used shall be that associated with the physically (wire, fiber, air) connected network. DA3 � Location may be requested at any time. Location information must be associated with the device at the time the location is requested. DA4 � Location acquisition should be provided by a consistent method across all network configurations. DA5 � Location determination and acquisition mechanisms must be applicable to emergency calling, and may also be applicable to a wide range of value-added location-based services. DA6 � Location determination and acquisition techniques shall support both NENA i2 and i3 network architectures. DA7 (Location 1400-0100 from LTD WG i3 rqmts) � When measurement based-location determination mechanisms fail, the most accurate location information available should be provided. Examples include: For mobile, the Wireless Service Provider might provide tower/Access Point location, last known fix, etc. For wireline, a LIS might provide a civic location that defines the serving area of an access point, e.g., the State of Texas. DA8 � Location determination and acquisition must provide minimal impact to call setup time in the event that location is not known ahead of time. DA9 � Where a device is not location aware the IP Access network should have the ability to provide a location estimate on behalf of the device. DA10 � Location acquisition methods should not require modification of hardware/firmware in home-routers/modems. DA11 � A location determination method must exist that does not require network hardware replacement. DA12 -- The location acquisition protocol shall allow the requesting device to specify a response time requirement to the LIS when requesting location information. The response time is expressed as the maximum time that the requesting node is prepared to wait for location information. The LIS is required to provide the most accurate location fix it can within the specified response time. 4.2 Location Representation Location Representation refers to the form and contents that are used to represent the geographic location of an Endpoint. Rep1 � Location information may be provided as location-by-value or location-by-reference and the form is subject to the nature of the request. Rep2 � Location determination and acquisition mechanisms must support all location information fields defined within a PIDF-LO. Rep3 � Location acquisition mechanisms must allow for easy backwards compatibility as the representation of location information evolves. Rep4 � All representations of location shall include the ability to carry altitude and/or floor designation. This requirement does not imply altitude and/or floor designation is always used or supplied. 4.3 Location Security and Dependability LocSec1 � Location information shall only be provided to authenticated and authorized network devices. The degree of authentication and authorization required may vary depending on the network. LocSec2 � Location determination and acquisition methods should preserve privacy of location information, subject to local laws and regulations. LocSec3 � The location or location estimate of a caller should be dependable. LocSec4 � The location acquisition protocol must support authentication of the Location Information Server, integrity protection of the Location Information, and protection against replay. LocSec5 � The location source shall be identified and should be authenticated. This includes manually entered location1. LocSec6 � Where a location is acquired and cached prior to an emergency call, it should be refreshed at regular intervals to ensure that it is as current as possible, in the event location information cannot be obtained in real time. LocSec7 � Where location by-reference is used the appropriate privacy policies must be implemented and enforced by the LIS operator. _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 14:57:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ7h8-0006Mu-Gl; Sat, 10 Mar 2007 14:57:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ7h7-0006Mp-Ns for geopriv@ietf.org; Sat, 10 Mar 2007 14:57:33 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQ7h6-00036R-AR for geopriv@ietf.org; Sat, 10 Mar 2007 14:57:33 -0500 Received: (qmail invoked by alias); 10 Mar 2007 19:57:31 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp018) with SMTP; 10 Mar 2007 20:57:31 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19l7ps+xmVlxnOdNbqy7yHG7AqcXFyU+3PtaPMDES 3ZGB3D2GhyftCR Message-ID: <45F30DA9.7010409@gmx.net> Date: Sat, 10 Mar 2007 21:57:29 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Geopriv] Draft agenda for IETF 68 References: <7C322386-4BC3-4E9F-9D45-3C8C5F2921E2@hxr.us> <45EE98B3.6010402@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Andy, Andrew Newton wrote: > > On Mar 7, 2007, at 5:49 AM, Hannes Tschofenig wrote: > >> we should spend more time on the Geopriv L7 work rather than spending >> a long time on new topics. > > Hannes, > > Proposals are welcome, but I think at this point the co-chairs need to > show some leadership and figure out how to steer the working group > through the L7-LCP work. An unstructured discussion is unlikely to > help. Proposals are welcomed. I was not proposing to spend time for unstructured discussions. If someone can make quick decisions then that's fine with me as well. > > It looks like we will be removing the SIP location conveyance draft >> from our agenda since it is in WGLC in SIP, and all comments on that > draft really need to be made there. We could yield the remainder of > our time to the ECRIT working group since they have been shafted by > the schedule this time around. I realize that arrangements had been > made to commandeer SIPPING time, but perhaps this might work better. > In the meanwhile we got time from SIPPING already. Thanks anyway. Ciao Hannes > -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 15:00:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ7jU-0006yS-CW; Sat, 10 Mar 2007 15:00:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ7jS-0006yN-TO for geopriv@ietf.org; Sat, 10 Mar 2007 14:59:58 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQ7jR-0003OM-9D for geopriv@ietf.org; Sat, 10 Mar 2007 14:59:58 -0500 Received: (qmail invoked by alias); 10 Mar 2007 19:59:56 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp033) with SMTP; 10 Mar 2007 20:59:56 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+dVbRTS0idjcENaK/ILlPBllHpS0jjgoBpvjQOdK SVN40hxTv2Eqo3 Message-ID: <45F30E39.3010601@gmx.net> Date: Sat, 10 Mar 2007 21:59:53 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: jerome.grenier@bell.ca Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement References: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A027236@toroondc912><7582BC68E4994F4ABF0BD4723975C3FA0268D983@crexc41p><8668B32D-DA78-4D46-A300-977B47DFECB0@hxr.us><7582BC68E4994F4ABF0BD4723975C3FA0268D98A@crexc41p><20070214102924.GA19828@nic.at><6B623AF5-0590-4B4D-9FC8-128CAFF7F6E6@hxr.us><20070214163901.GA27679@nic.at><86A33432-51F1-4CAB-9F7E-70715907A358@hxr.us><7582BC68E4994F4ABF0BD4723975C3FA0268D996@crexc41p><7582BC68E4994F4ABF0BD4723975C3FA0268D999@crexc41p><04E35B55-6446-436B-B6AE-751EDAC0885F@hxr.us> <7582BC68E4994F4ABF0BD4723975C3FA0268D9A0@crexc41p> <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A0276AC@toroondc912> In-Reply-To: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A0276AC@toroondc912> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: geopriv@ietf.org, Barbara.Stark@BellSouth.com, lendl@nic.at, andy@hxr.us X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Jerome, jerome.grenier@bell.ca wrote: > I agree with Barbara and would also add : > > - ability to request geo and/or civic location > Barbara previously said that geo-location does not make sense in the DSL environment. I guess you are pointing to a different environment. The question is only: Is the LIS-to-LIS communication needed there as well? > The "ability to specify how quickly a response is needed" would also be really helpful to us. > I don't think that this is useful for this particular application. > Having a BCP (one or more) that recommends a syntax to express various identifier types for common protocols like SIP/PRES and HTTP would be great! > > Ciao Hanes > J�r�me > > -----Message d'origine----- > De : Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > Envoy� : 16 f�vrier 2007 10:05 > � : Andrew Newton > Cc : geopriv@ietf.org; Otmar Lendl > Objet : RE: [Geopriv] Geopriv L7 LCP: New Requirement > > I hate to break ranks, but if we could get the user part figured out > (and I do think we would need some standardization, even if it's just a > BCP), I kind of like this proposed solution. It has a certain simplicity > to it. > > Since we've been pushing for these LISs to support LbyR, anyway, and > this is really just LbyR, I don't see it as being a different protocol, > yet again. This is a protocol we'd expect to be supported by a LIS in > any case. The only change is that the URI may require careful parsing by > the queried LIS, and the querier LIS needs to support LbyR queries in > both directions. > > When I look at the functions in HELD (and RELO has a subset of these), > and think through which of those functions would I really need for > LIS-LIS or OBO, I come up with: > - ability to request reference -- not needed, since, as pointed out, > I've already got a perfectly good non-expiring reference; OBO querier or > LIS doesn't need to ask for references to hand off to others, it should > create its own references for that, as appropriate [aside: a > non-expiring reference and a "LCP" are rather equal in the privacy > debate from the OBO/LIS-LIS perspective.] > - ability to assert location -- not needed for OBO or LIS-LIS; only an > end device should be able to do this, if even that is allowed > - ability to provide rules/profile for privacy -- not needed for OBO or > LIS-LIS; only the device should be able to do this > - ability to sign location -- if this is part of PIDF-LO, then this is > independent of request mechanism > - ability to request that location be signed -- I think we can assume > that the location should be signed if it can be signed > - ability to specify how quickly a response is needed -- this would be > useful, but it may be possible to design around the issue > - have I missed anything? > > Supporting URI formats other than SIP (e.g., HTTP) would still need to > be worked. But that format would be common to all LbyR usages. > This in no way removes the requirement for a device-to-LIS "LCP". I > haven't read that into the suggestion at all. > > So, I think this idea warrants consideration. > Barbara > > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Thursday, February 15, 2007 3:51 PM > To: Stark, Barbara > Cc: geopriv@ietf.org; Otmar Lendl > Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement > > > On Feb 15, 2007, at 12:50 PM, Stark, Barbara wrote: > > >> What is difficult, is figuring out a standard format for a URI user >> part that would allow for all the variations in combinations of IDs >> that exist, so that a standard format could be defined that would >> cover all interconnection models. Section 8 of the NENA Location TID >> (http://www.nena.org/media/files/08-505_20061221.pdf) provides 5 >> different examples of interconnection models, and the IDs that would >> need to be used in each of these cases. In this document, scenario 1 >> uses the IP address, scenario 2 uses NAS-ID and ATM PVC, scenario 3 >> uses >> 2 VLAN tags, scenario 4 uses IP address, and scenario 5 uses L2TP >> tunnel ID (source and destination) and PPPoE session ID. These are >> just 5 possible examples, and should not be considered exhaustive. >> Interconnection models are still evolving. >> > > Well, that's easily solved with a BCP for formulating URIs based on the > ID. You don't need a new protocol or to conflate the LCP protocol with > this functionality. > > -andy > > ***** > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 15:01: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 1HQ7lD-0000Iu-8A; Sat, 10 Mar 2007 15:01:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ7lC-0000Ip-NT for geopriv@ietf.org; Sat, 10 Mar 2007 15:01:46 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQ7l7-0003bZ-MF for geopriv@ietf.org; Sat, 10 Mar 2007 15:01:46 -0500 Received: (qmail invoked by alias); 10 Mar 2007 19:55:00 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp020) with SMTP; 10 Mar 2007 20:55:00 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX187SAR/Axc7/MpXGQxHitSp6PACwFqBuJlBQvSIfG xT9xS1FcRiS94m Message-ID: <45F30D11.7010605@gmx.net> Date: Sat, 10 Mar 2007 21:54:57 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Brian Rosen References: <03e301c760b6$a2b3b870$640fa8c0@cis.neustar.com> In-Reply-To: <03e301c760b6$a2b3b870$640fa8c0@cis.neustar.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: c3a18ef96977fc9bcc21a621cbf1174b Cc: 'GEOPRIV' Subject: [Geopriv] l-by-r X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Brian, Brian Rosen wrote: > I think -lbyr-requirements talks about any protocol that handles l-by-r. > SIP (via location conveyance) would be an example. I hope we are not working on a requirements document for the SIP Location Conveyance draft (which is also in WGLC). > An L7 LCP may be another > example. Who knows, we could have a DHCP option that could retrieve one. True. > L7 lcp talks about a location configuration protocol working at Layer 7. > That protocol could return a location value, or a reference. There is > probably some opportunity to remove l-by-r language from lcp-ps and make > reference to lbyr-requirements. > The only requirements that we came up with in the GEOPRIV L7 LCP DT with respect to l-by-r are the following (and they do not have anything in there that ties them specifically to a L7 protocol). ----------- The following requirements are placed on the location-by-reference approach: o The reference MUST be valid for a limited amount of time. o The reference MUST be hard to guess, i.e., it MUST contain a cryptographically random component. o The reference MUST NOT contain any information that identifies the user, device or address of record o The Location Recipient MUST be able to resolve the reference more than once (i.e., there is no implicit limit on the number of dereferencing actions). o Possessing a reference to location information allows a Location Recipient to repeately obtain the latest information about the Target with the same granularity. o The Target MUST be able to resolve the reference itself. ----------- Ciao Hannes > Brian > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Wednesday, March 07, 2007 6:22 AM >> To: GEOPRIV >> Subject: [Geopriv] Re: [Sip] WGLC on draft-ietf-sip-location-conveyance >> >> Hi all, >> >> I would like to understand what the relationship between >> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-00.txt >> and >> http://www.ietf.org/internet-drafts/draft-marshall-geopriv-lbyr- >> requirements-00.txt >> is. >> >> Can someone help me? >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 15:31: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 1HQ8EF-00039P-Rk; Sat, 10 Mar 2007 15:31:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ8EE-00039K-OX for geopriv@ietf.org; Sat, 10 Mar 2007 15:31:46 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQ8ED-0001XA-3u for geopriv@ietf.org; Sat, 10 Mar 2007 15:31:46 -0500 Received: (qmail invoked by alias); 10 Mar 2007 20:31:41 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp032) with SMTP; 10 Mar 2007 21:31:41 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19GUZQeMIdGtRgnrmyEDpQMgDQsPTdL2wFe44Q2SN CNBW6ohaxcZmg7 Message-ID: <45F315AC.1040407@gmx.net> Date: Sat, 10 Mar 2007 22:31:40 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: GEOPRIV Subject: Re: [Geopriv] NENA Requirements References: <45F30B49.90700@gmx.net> In-Reply-To: <45F30B49.90700@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi all, I went through the requirements and most of them seem to be pretty irrelevant. Please find a few minor comments below: Hannes Tschofenig wrote: > Some reviewers of note that the > requirements in > http://www.nena.org/media/files/08-505_20061221.pdf also have to be > considered. > > Interestingly, this document was published long after the design team > work took place were these requirements could have been introduced. > > > Here are the requirements and I will copy them in a separate mail: > > > 4 Requirements > > These requirements are excerpted from the NENA TRD, NENA Requirements > for Location Information to Support Emergency Services, for the > convenience of the reader. If this document should inadvertently differ >> from the TRD, the TRD is to be considered the normative reference. > As defined in the TRD, and as excerpted here, the terms "shall", "must ", > and "required" are used in this section to indicate requirements and > to differentiate from those parameters that are recommendations. > > Recommendations are identified by the word �should.� Optional, > desirable capabilities are identified by the words "desirable" or > "preferably". > > 4.1 Location Determination and Acquisition > > DA1 � The access network shall provide a mechanism for determination > and acquisition of location information, and support queries for > location. > > DA2 � The location estimate used shall be that associated with the > physically (wire, fiber, air) connected network. > > DA3 � Location may be requested at any time. Location information must > be associated with the device at the time the location is requested. > > DA4 � Location acquisition should be provided by a consistent method > across all network configurations. > > DA5 � Location determination and acquisition mechanisms must be > applicable to emergency calling, and may also be applicable to a wide > range of value-added location-based services. > > DA6 � Location determination and acquisition techniques shall support > both NENA i2 and i3 network architectures. > > DA7 (Location 1400-0100 from LTD WG i3 rqmts) � When measurement > based-location determination mechanisms fail, the most accurate > location information available should be provided. Examples include: > For mobile, the Wireless Service Provider might provide tower/Access > Point location, last known fix, etc. For wireline, a LIS might provide > a civic location that defines the serving area of an access point, > e.g., the State of Texas. > > DA8 � Location determination and acquisition must provide minimal > impact to call setup time in the event that location is not known ahead > of time. > > DA9 � Where a device is not location aware the IP Access network should > have the ability to provide a location estimate on behalf of the > device. > > DA10 � Location acquisition methods should not require modification of > hardware/firmware in home-routers/modems. > > DA11 � A location determination method must exist that does not require > network hardware replacement. > > DA12 -- The location acquisition protocol shall allow the requesting > device to specify a response time requirement to the LIS when > requesting location information. The response time is expressed as the > maximum time that the requesting node is prepared to wait for location > information. The LIS is required to provide the most accurate location > fix it can within the specified response time. I think that this is the wrong concept. I think what you really want is an indication about the granularity of the returned location information. > > 4.2 Location Representation > > Location Representation refers to the form and contents that are used > to represent the geographic location of an Endpoint. > > Rep1 � Location information may be provided as location-by-value or > location-by-reference and the form is subject to the nature of the > request. > > Rep2 � Location determination and acquisition mechanisms must support > all location information fields defined within a PIDF-LO. > > Rep3 � Location acquisition mechanisms must allow for easy backwards > compatibility as the representation of location information evolves. > > Rep4 � All representations of location shall include the ability to > carry altitude and/or floor designation. This requirement does not > imply altitude and/or floor designation is always used or supplied. > > 4.3 Location Security and Dependability > > LocSec1 � Location information shall only be provided to authenticated > and authorized network devices. The degree of authentication and > authorization required may vary depending on the network. > I guess that this refers to location-by-reference only. > LocSec2 � Location determination and acquisition methods should > preserve privacy of location information, subject to local laws and > regulations. > > LocSec3 � The location or location estimate of a caller should be > dependable. What does "dependable" mean in this context? > > LocSec4 � The location acquisition protocol must support authentication > of the Location Information Server, integrity protection of the > Location Information, and protection against replay. > > LocSec5 � The location source shall be identified and should be > authenticated. This includes manually entered location1. I wonder how this would look like. > > LocSec6 � Where a location is acquired and cached prior to an emergency > call, it should be refreshed at regular intervals to ensure that it is > as current as possible, in the event location information cannot be > obtained in real time. > This is not a security requirement. > LocSec7 � Where location by-reference is used the appropriate privacy > policies must be implemented and enforced by the LIS operator. What does this mean in context of requirement LocSec2 ? Ciao Hannes > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 15:32:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ8F1-0003Ps-7v; Sat, 10 Mar 2007 15:32:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ8Ez-0003Pn-T3 for geopriv@ietf.org; Sat, 10 Mar 2007 15:32:33 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ8Ey-0001ew-LM for geopriv@ietf.org; Sat, 10 Mar 2007 15:32:33 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 10 Mar 2007 12:32:34 -0800 X-IronPort-AV: i="4.14,270,1170662400"; d="scan'208"; a="399802332:sNHT40001988" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l2AKWWtk008187 for ; Sat, 10 Mar 2007 12:32:32 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l2AKVnxT010509 for ; Sat, 10 Mar 2007 20:32:31 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <4D288EAE-77F9-4D27-B07A-3716F2E3F97F@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: geopriv@ietf.org From: Cullen Jennings Date: Sat, 10 Mar 2007 12:32:13 -0800 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=190; t=1173558752; x=1174422752; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20DHCP=20Size |Sender:=20; bh=luJ60j9Fe5v9wPN/QxHX87zTRaYsNENf+lolGO2xlKA=; b=anqNri8jrPeqHdcKirHQOPmbVup6bjU8rgrMvoMW1C9P6AgMM20WbWf87UB1CV1EMpxvvZsy P9JBuM+HuzD0Jfk6xvBeLDW/whF6tiOT6p0bd1D23AATyKTLCujdsj2F; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Geopriv] DHCP Size X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org One thing I have been getting concerned with is the size of DHCP responses with all the SIP/ECRIT/GEOPRIV etc usages of them. Has anyone looked at how big one could reasonable get? _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 15:44:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ8QV-0005Qt-Hc; Sat, 10 Mar 2007 15:44:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ8QU-0005Ov-Rx for geopriv@ietf.org; Sat, 10 Mar 2007 15:44:26 -0500 Received: from bellwecs1.srvr.bell.ca ([207.236.237.113]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQ8QP-0004rR-AZ for geopriv@ietf.org; Sat, 10 Mar 2007 15:44:26 -0500 Received: (qmail 9329 invoked from network); 10 Mar 2007 20:44:16 -0000 Received: from jerome.grenier@bell.ca by bellwecs1.srvr.bell.ca with EntrustECS-Server-7.4; 10 Mar 2007 20:44:16 -0000 Received: from bellwfep1.bellnexxia.net (HELO bellwfep1-srv.bellnexxia.net) (207.236.237.107) by bellwecs1.srvr.bell.ca with SMTP; 10 Mar 2007 20:44:16 -0000 Received: from TOROONDC918.bell.corp.bce.ca ([142.182.89.79]) by bellwfep1-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20070310204416.CDNN1603.bellwfep1-srv.bellnexxia.net@TOROONDC918.bell.corp.bce.ca>; Sat, 10 Mar 2007 15:44:16 -0500 Received: from toroondc912.bell.corp.bce.ca ([142.182.89.15]) by TOROONDC918.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Mar 2007 15:44: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement Date: Sat, 10 Mar 2007 15:44:14 -0500 Message-ID: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A258329@toroondc912> In-Reply-To: <45F30E39.3010601@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Geopriv L7 LCP: New Requirement Thread-Index: AcdjTq6oCwwLP31aSO2XSVgOtXM5owABAxhQ References: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A027236@toroondc912><7582BC68E4994F4ABF0BD4723975C3FA0268D983@crexc41p><8668B32D-DA78-4D46-A300-977B47DFECB0@hxr.us><7582BC68E4994F4ABF0BD4723975C3FA0268D98A@crexc41p><20070214102924.GA19828@nic.at><6B623AF5-0590-4B4D-9FC8-128CAFF7F6E6@hxr.us><20070214163901.GA27679@nic.at><86A33432-51F1-4CAB-9F7E-70715907A358@hxr.us><7582BC68E4994F4ABF0BD4723975C3FA0268D996@crexc41p><7582BC68E4994F4ABF0BD4723975C3FA0268D999@crexc41p><04E35B55-6446-436B-B6AE-751EDAC0885F@hxr.us> <7582BC68E4994F4ABF0BD4723975C3FA0268D9A0@crexc41p> <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A0276AC@toroondc912> <45F30E39.3010601@gmx.net> From: To: X-OriginalArrivalTime: 10 Mar 2007 20:44:15.0997 (UTC) FILETIME=[DE381AD0:01C76354] X-Spam-Score: 0.2 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: geopriv@ietf.org, Barbara.Stark@BellSouth.com, lendl@nic.at, andy@hxr.us X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Hannes, Indeed, the scenario I had in mind did not involve LIS-to-LIS in a DSL = environment. It is the mobile access to the Internet scenario (3G cell = phones / PDAs, PC cards, etc). The deployment I know involves only one = entity as both the Internet Service Provider and the (mobile) Access = Service Provider, therefore only one LIS is needed. Of course, the = LIS-to-LIS issues would apply to deployments where those two providers = would be different organizations (I don't know if such deployments = actually exist). In this mobile environment, the ability to specify how quickly a = response is needed seems useful. Note that this makes more sense from an = OBO perspective as well as if the mobile device itself tries to acquire = its location just in time for an emergency call, for example. J=E9r=F4me -----Message d'origine----- De=A0: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Envoy=E9=A0: 10 mars 2007 15:00 =C0=A0: Grenier, Jerome (6002687) Cc=A0: Barbara.Stark@BellSouth.com; andy@hxr.us; geopriv@ietf.org; = lendl@nic.at Objet=A0: Re: [Geopriv] Geopriv L7 LCP: New Requirement Hi Jerome, jerome.grenier@bell.ca wrote: > I agree with Barbara and would also add :=20 > > - ability to request geo and/or civic location > =20 Barbara previously said that geo-location does not make sense in the DSL = environment. I guess you are pointing to a different environment. The question is=20 only: Is the LIS-to-LIS communication needed there as well? > The "ability to specify how quickly a response is needed" would also = be really helpful to us. > =20 I don't think that this is useful for this particular application. > Having a BCP (one or more) that recommends a syntax to express various = identifier types for common protocols like SIP/PRES and HTTP would be = great! > > =20 Ciao Hanes > J=E9r=F4me > > -----Message d'origine----- > De : Stark, Barbara [mailto:Barbara.Stark@BellSouth.com]=20 > Envoy=E9 : 16 f=E9vrier 2007 10:05 > =C0 : Andrew Newton > Cc : geopriv@ietf.org; Otmar Lendl > Objet : RE: [Geopriv] Geopriv L7 LCP: New Requirement > > I hate to break ranks, but if we could get the user part figured out > (and I do think we would need some standardization, even if it's just = a > BCP), I kind of like this proposed solution. It has a certain = simplicity > to it. > > Since we've been pushing for these LISs to support LbyR, anyway, and > this is really just LbyR, I don't see it as being a different = protocol, > yet again. This is a protocol we'd expect to be supported by a LIS in > any case. The only change is that the URI may require careful parsing = by > the queried LIS, and the querier LIS needs to support LbyR queries in > both directions. > > When I look at the functions in HELD (and RELO has a subset of these), > and think through which of those functions would I really need for > LIS-LIS or OBO, I come up with: > - ability to request reference -- not needed, since, as pointed out, > I've already got a perfectly good non-expiring reference; OBO querier = or > LIS doesn't need to ask for references to hand off to others, it = should > create its own references for that, as appropriate [aside: a > non-expiring reference and a "LCP" are rather equal in the privacy > debate from the OBO/LIS-LIS perspective.] > - ability to assert location -- not needed for OBO or LIS-LIS; only an > end device should be able to do this, if even that is allowed > - ability to provide rules/profile for privacy -- not needed for OBO = or > LIS-LIS; only the device should be able to do this > - ability to sign location -- if this is part of PIDF-LO, then this is > independent of request mechanism > - ability to request that location be signed -- I think we can assume > that the location should be signed if it can be signed > - ability to specify how quickly a response is needed -- this would be > useful, but it may be possible to design around the issue > - have I missed anything? > > Supporting URI formats other than SIP (e.g., HTTP) would still need to > be worked. But that format would be common to all LbyR usages. > This in no way removes the requirement for a device-to-LIS "LCP". I > haven't read that into the suggestion at all. > > So, I think this idea warrants consideration. > Barbara > > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us]=20 > Sent: Thursday, February 15, 2007 3:51 PM > To: Stark, Barbara > Cc: geopriv@ietf.org; Otmar Lendl > Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement > > > On Feb 15, 2007, at 12:50 PM, Stark, Barbara wrote: > > =20 >> What is difficult, is figuring out a standard format for a URI user=20 >> part that would allow for all the variations in combinations of IDs=20 >> that exist, so that a standard format could be defined that would=20 >> cover all interconnection models. Section 8 of the NENA Location TID >> (http://www.nena.org/media/files/08-505_20061221.pdf) provides 5=20 >> different examples of interconnection models, and the IDs that would=20 >> need to be used in each of these cases. In this document, scenario 1=20 >> uses the IP address, scenario 2 uses NAS-ID and ATM PVC, scenario 3=20 >> uses >> 2 VLAN tags, scenario 4 uses IP address, and scenario 5 uses L2TP=20 >> tunnel ID (source and destination) and PPPoE session ID. These are=20 >> just 5 possible examples, and should not be considered exhaustive. >> Interconnection models are still evolving. >> =20 > > Well, that's easily solved with a BCP for formulating URIs based on = the > ID. You don't need a new protocol or to conflate the LCP protocol = with > this functionality. > > -andy > > ***** > > The information transmitted is intended only for the person or entity = to which it is addressed and may contain confidential, proprietary, = and/or privileged material. Any review, retransmission, dissemination or = other use of, or taking of any action in reliance upon this information = by persons or entities other than the intended recipient is prohibited. = If you received this in error, please contact the sender and delete the = material from all computers. GA621 > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > =20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 15:56: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 1HQ8bf-0007kE-EH; Sat, 10 Mar 2007 15:55:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ8bd-0007h2-Uq for geopriv@ietf.org; Sat, 10 Mar 2007 15:55:57 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ8bc-0007P3-CK for geopriv@ietf.org; Sat, 10 Mar 2007 15:55:57 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 10 Mar 2007 12:55:52 -0800 X-IronPort-AV: i="4.14,270,1170662400"; d="scan'208"; a="399804475:sNHT40582084" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l2AKtpfP005950 for ; Sat, 10 Mar 2007 12:55:51 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l2AKtpxS013743 for ; Sat, 10 Mar 2007 20:55:51 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <86C9C582-BD1A-49E0-ACA3-A1EA5C3599E1@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: geopriv@ietf.org From: Cullen Jennings Date: Sat, 10 Mar 2007 12:55:27 -0800 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=411; t=1173560151; x=1174424151; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20thomson-geopriv-3825bis |Sender:=20; bh=TOnSOTW819Mc09fFeNDmcU3wjnr5Fn/1ew6cTYWNVMo=; b=bmbW+ws1dOa3Xw1Kz81yIT+qhwPqvoKLg55icJ72X194eyYi4vSZisV7yyeQLUBxujt/q/81 K9iCa828AHy6yLrYES2FFTzDNIcL8ATE0O4zECCLdxl9yrQssaTTPZaU; Authentication-Results: sj-dkim-5; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Geopriv] thomson-geopriv-3825bis X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org This reports the location of the wirejack not the DHCP client. How will the client know what assumptions to make about the additional uncertainty form the wirejack? What does this mean for WAP that don't have additional wireless location support. I think that reporting the approximated client location and approximated uncertainty might work out better. Cullen _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 16:09: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 1HQ8ot-0000lL-5l; Sat, 10 Mar 2007 16:09:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ8os-0000io-KS for geopriv@ietf.org; Sat, 10 Mar 2007 16:09:38 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ8or-0001mD-Cv for geopriv@ietf.org; Sat, 10 Mar 2007 16:09:38 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 10 Mar 2007 13:09:36 -0800 X-IronPort-AV: i="4.14,270,1170662400"; d="scan'208"; a="47295324:sNHT508139136" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l2AL9at1008861 for ; Sat, 10 Mar 2007 13:09:36 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l2AL9Za4014377 for ; Sat, 10 Mar 2007 21:09:35 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <2EE96B90-FBD5-4C77-B382-14E9DC60B71B@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: geopriv@ietf.org From: Cullen Jennings Date: Sat, 10 Mar 2007 13:09:11 -0800 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=196; t=1173560976; x=1174424976; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20draft-marshall-geopriv-lbyr-requirements-01 |Sender:=20; bh=SVS9yJLmZ/qjQ2BJd3csqV4zRMBJjaP7+d8w/2DH7jA=; b=hIG0E78WO2fF7Z6cK1jiFgN03DpQmjldaiDlf9j3Fjwgf8DIrQyPxXXhAyNEby5GPYaIyDTI MOuYr4CrTbtojELNCUp7eFgZ6VPtsxEUkFHYGmdNAKQDnO4As88619Kx; Authentication-Results: sj-dkim-5; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Geopriv] draft-marshall-geopriv-lbyr-requirements-01 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Is there a requirement for the LR to be asynchronously notified about location changes for an LRI that has not expired and that the LR dereferences? Cullen _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 16:35: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 1HQ9EL-0000ul-Gz; Sat, 10 Mar 2007 16:35:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ9EL-0000ug-1C for geopriv@ietf.org; Sat, 10 Mar 2007 16:35:57 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ9EG-00070G-3k for geopriv@ietf.org; Sat, 10 Mar 2007 16:35:57 -0500 X-SEF-Processed: 5_0_0_910__2007_03_10_15_41_46 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); Sat, 10 Mar 2007 15:41:46 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Mar 2007 15:35:51 -0600 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: [Geopriv] NENA Requirements Date: Sat, 10 Mar 2007 15:35:48 -0600 Message-ID: In-Reply-To: <45F315AC.1040407@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] NENA Requirements Thread-Index: AcdjU0ZlXBGWFWV0RRmhWvhwF4UYhwAB7GsQ From: "Winterbottom, James" To: "Hannes Tschofenig" , "GEOPRIV" X-OriginalArrivalTime: 10 Mar 2007 21:35:51.0317 (UTC) FILETIME=[132C7450:01C7635C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org =0D=0AHannes,=0D=0A=0D=0ASpecifically your comment in the snippet below:=0D= =0A> DA12 -- The location acquisition protocol shall allow the requesting =0D= =0A> device to specify a response time requirement to the LIS when=20=0D=0A= > requesting location information. The response time is expressed as the=0D= =0A=0D=0A> maximum time that the requesting node is prepared to wait for lo= cation=0D=0A=0D=0A> information. The LIS is required to provide the most ac= curate location=0D=0A=0D=0A> fix it can within the specified response time.=0D= =0A=0D=0A"I think that this is the wrong concept.=0D=0A=0D=0AI think what y= ou really want is an indication about the granularity of=0D=0Athe returned = location information."=0D=0A=0D=0AWireless systems today provide for severa= l types of "quality of=0D=0Aservice". They allow you to specify the horizon= tal and vertical accuracy=0D=0Athat you want determination within, and a ti= me delay, no-delay,=0D=0Alow-delay, delay-tolerant. In reality most systems= in the network use=0D=0Aonly the latter 3. The problem with this approach = is however that there=0D=0Ais no definitive value that you can place on wha= t low-delay or=0D=0Adelay-tolerant means, they are arbitrary. This requirem= ent seeks to=0D=0Aprovide a LIS with a means of making a definitive choice.= If there is an=0D=0Aalternative am pretty keen to hear it, but basing requ= est purely on=0D=0Aaccuracy only address half the problem, and probably not= the critical=0D=0Ahalf.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A----------------= ---------------------------------------------------------------------------= -----=0D=0AThis message is for the designated recipient only and may=0D=0Ac= ontain privileged, proprietary, or otherwise private information. =20=0D=0A= If you have received it in error, please notify the sender=0D=0Aimmediately= and delete the original. Any unauthorized use of=0D=0Athis email is prohi= bited.=0D=0A---------------------------------------------------------------= ---------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 16:59:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ9bC-0008Th-Cy; Sat, 10 Mar 2007 16:59:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ9bB-0008Tc-4k for geopriv@ietf.org; Sat, 10 Mar 2007 16:59:33 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ9b9-0003hM-TS for geopriv@ietf.org; Sat, 10 Mar 2007 16:59:33 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 10 Mar 2007 13:59:32 -0800 X-IronPort-AV: i="4.14,270,1170662400"; d="scan'208"; a="399812825:sNHT38267000" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l2ALxVLF017622 for ; Sat, 10 Mar 2007 13:59:31 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l2ALxUxS024581 for ; Sat, 10 Mar 2007 21:59:31 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: geopriv@ietf.org From: Cullen Jennings Date: Sat, 10 Mar 2007 13:59:07 -0800 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=108; t=1173563971; x=1174427971; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20draft-thomson-geopriv-held-beep |Sender:=20; bh=0Mh1mmA+9LI9cV+0+L3Yr9gXOyeB/V/2+06H6+qglYE=; b=R7z7ZTqvNUCEgobgIt43ll3zBNktn3w9hkmwxhT9nyi70F1kzgTbdyAUD1JTKdnYx+d/esON jjpCYLnKPEr79u26CImQqP4d0qqecYjxBSX0QmgsK7LQ5VrGHSk/fgZD; Authentication-Results: sj-dkim-5; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [Geopriv] draft-thomson-geopriv-held-beep X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org What credential will the client use to authenticate to the server? Cullen _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 17:00:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ9c7-0000zh-QU; Sat, 10 Mar 2007 17:00:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ9c7-0000zc-5F for geopriv@ietf.org; Sat, 10 Mar 2007 17:00:31 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ9c5-0003og-SH for geopriv@ietf.org; Sat, 10 Mar 2007 17:00:31 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 10 Mar 2007 14:00:30 -0800 X-IronPort-AV: i="4.14,270,1170662400"; d="scan'208"; a="399813051:sNHT43287592" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l2AM0Tp2008854 for ; Sat, 10 Mar 2007 14:00:29 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l2ALxUxT024581 for ; Sat, 10 Mar 2007 22:00:28 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <70101239-BB7A-4195-A0FD-91ABFF22E15F@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: geopriv@ietf.org From: Cullen Jennings Date: Sat, 10 Mar 2007 14:00:10 -0800 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=125; t=1173564029; x=1174428029; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20draft-thomson-geopriv-lis-discovery-00 |Sender:=20; bh=Ocmw9OH1KHkk/ZBtK9FPW6DDWpZ0QC9rZxtmNwSB95A=; b=NcGExoBrOZULu9c3C1gIfoUXrBSH1ew6WCG+8Hzht9YWQFLxjF9eXVI4o0WNcpQgwnT/lW7N NXwtFrA6yKPexAj9pMD7AHC1IMMALatUORxID9jJ5hpM+ZOwAy2wXU9r; Authentication-Results: sj-dkim-7; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Geopriv] draft-thomson-geopriv-lis-discovery-00 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org UPnP will not discover the outer most NAT so I don think it should be used here. Cullen _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 17:06: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 1HQ9hm-0006y3-6p; Sat, 10 Mar 2007 17:06:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ9hl-0006xy-2u for geopriv@ietf.org; Sat, 10 Mar 2007 17:06:21 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ9hh-00056q-NS for geopriv@ietf.org; Sat, 10 Mar 2007 17:06:21 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 10 Mar 2007 14:06:18 -0800 X-IronPort-AV: i="4.14,270,1170662400"; d="scan'208"; a="399813835:sNHT45040940" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l2AM6HpI025327 for ; Sat, 10 Mar 2007 14:06:17 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2AM6G1T029473 for ; Sat, 10 Mar 2007 22:06:16 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Mar 2007 14:06:16 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.152.81]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Mar 2007 14:06:16 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 10 Mar 2007 16:05:01 -0600 To: Cullen Jennings , geopriv@ietf.org From: "James M. Polk" Subject: Re: [Geopriv] DHCP Size In-Reply-To: <4D288EAE-77F9-4D27-B07A-3716F2E3F97F@cisco.com> References: <4D288EAE-77F9-4D27-B07A-3716F2E3F97F@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 10 Mar 2007 22:06:16.0289 (UTC) FILETIME=[52F11510:01C76360] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1626; t=1173564377; x=1174428377; c=relaxed/simple; s=sjdkim4002; 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=20[Geopriv]=20DHCP=20Size |Sender:=20; bh=ZB9cLDnEjAi3KLgXhIH1sYPqrmFMV2rH+ONDLAauKfE=; b=cVlEB80HQ+AhpNL7kvcbEoAqJanerLVgl5UakAbw6fYaW7cf88EtgV3pTGvYIL7sXVuIFDS4 ZwWetUrWPDMzwrortnopgV6FYEeHJPxcB9C2YnYvFh+3aMiJif+MmJt0; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org At 02:32 PM 3/10/2007, Cullen Jennings wrote: >One thing I have been getting concerned with is the size of DHCP >responses with all the SIP/ECRIT/GEOPRIV etc usages of them. Has >anyone looked at how big one could reasonable get? DHCP has some interesting limitations to Option size (RFC2131), including * the size limitation of any individual Option response (255 bytes I believe) * the size of the aggregate of all responses within a message * and how to concatenate Options (RFC3396) But generally, DHCP responses are limited to 576 bytes for all options (i.e. not just location), unless something special has occurred. This WG cannot assume that only location will be in a DHCP (OFFER or ACK) response, even if that is all that was requested in a DISCOVER, REQUEST or INFORM message. Often many more options will be in that same response message - which is out of the control of the client, but under the control of the server. All of this is capped at 576 bytes (unless something special has occurred). Generally, if an OFFER or ACK response is received in consecutive packets, the second packet's values overwrite the first packets values. In fact, I think any subsequence response with a new value within a specific Option overwrites what was there from the previous response. I think it is possible some folks on this list assume DHCP has the normal MTU of 1500 bytes - and that isn't the case. >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 19:15: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 1HQBic-0002ai-8o; Sat, 10 Mar 2007 19:15:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQBib-0002Ze-KF for geopriv@ietf.org; Sat, 10 Mar 2007 19:15:21 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQBia-0002Mw-9l for geopriv@ietf.org; Sat, 10 Mar 2007 19:15:21 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-6.cisco.com with ESMTP; 10 Mar 2007 16:15:19 -0800 X-IronPort-AV: i="4.14,270,1170662400"; d="scan'208"; a="119889792:sNHT43347591" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l2B0FJJe028917; Sat, 10 Mar 2007 16:15:19 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l2B0FHa4011067; Sun, 11 Mar 2007 00:15:18 GMT In-Reply-To: References: <4D288EAE-77F9-4D27-B07A-3716F2E3F97F@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <22EF0D6F-6FA0-40E0-AA6D-E13BD915ADB1@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Geopriv] DHCP Size Date: Sat, 10 Mar 2007 16:14:53 -0800 To: "James M. Polk" X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2073; t=1173572119; x=1174436119; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Geopriv]=20DHCP=20Size |Sender:=20; bh=cfktCxaB6OXDTsjJYMgdl3pLXbKA92trRYGr3rfGj/s=; b=Hr4e1uQhaZsJ5orj/UhGiBfbUgD0U50PvhMTRmU+I8h0/14DkZekhrUppbz+2D1i1Hf62X/U 19kSUsHNPNlaDB+g/PhoTpkWxu8gCgMj1CHeSVT5W3hT3dCUCxDxqA6K; Authentication-Results: sj-dkim-7; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Makes sense - I was just starting to get a little worried that all the options together might be getting close to too big. Could we try listing all the options that we can imagine might reasonable get put in the response to DHCP request from a SIP UA and check that there are no surprises. On Mar 10, 2007, at 2:05 PM, James M. Polk wrote: > At 02:32 PM 3/10/2007, Cullen Jennings wrote: > >> One thing I have been getting concerned with is the size of DHCP >> responses with all the SIP/ECRIT/GEOPRIV etc usages of them. Has >> anyone looked at how big one could reasonable get? > > DHCP has some interesting limitations to Option size (RFC2131), > including > > * the size limitation of any individual Option response > (255 bytes I believe) > * the size of the aggregate of all responses within a message > * and how to concatenate Options (RFC3396) > > But generally, DHCP responses are limited to 576 bytes for all > options (i.e. not just location), unless something special has > occurred. This WG cannot assume that only location will be in a > DHCP (OFFER or ACK) response, even if that is all that was > requested in a DISCOVER, REQUEST or INFORM message. Often many more > options will be in that same response message - which is out of the > control of the client, but under the control of the server. All of > this is capped at 576 bytes (unless something special has > occurred). Generally, if an OFFER or ACK response is received in > consecutive packets, the second packet's values overwrite the first > packets values. In fact, I think any subsequence response with a > new value within a specific Option overwrites what was there from > the previous response. > > I think it is possible some folks on this list assume DHCP has the > normal MTU of 1500 bytes - and that isn't the case. > > > >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 22:04:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQELl-0000Bi-Mv; Sat, 10 Mar 2007 22:03:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQELj-0008Vk-Gf for geopriv@ietf.org; Sat, 10 Mar 2007 22:03:55 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQELf-0004Qx-2z for geopriv@ietf.org; Sat, 10 Mar 2007 22:03:55 -0500 X-SEF-Processed: 5_0_0_910__2007_03_10_21_09_37 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); Sat, 10 Mar 2007 21:09:37 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Mar 2007 21:03:41 -0600 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: [Geopriv] NENA Requirements Date: Sat, 10 Mar 2007 21:03:38 -0600 Message-ID: In-Reply-To: <45F30B49.90700@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] NENA Requirements Thread-Index: AcdjTeBAtyKST3eMTvyeug/JBnGIcwAOsaoA From: "Dawson, Martin" To: "Hannes Tschofenig" , "GEOPRIV" X-OriginalArrivalTime: 11 Mar 2007 03:03:41.0560 (UTC) FILETIME=[DF8D5780:01C76389] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Well, I do take exception to the suggestion that the NENA requirements=0D=0A= were introduced long after the design team work was done. The NENA=0D=0Areq= uirements were available in draft long before geopriv even came to=0D=0Agri= ps with beginning to accept the idea of an "L7" protocol.=0D=0A=0D=0AI cert= ainly tried to get people to consider the requirements from NENA -=0D=0Abut= spent most of my time responding to arguments about why opinions=0D=0Adriv= en by the i2 architecture weren't relevant ("architecture is broken"=0D=0Aa= s one commentator put it). It's impossible to discuss requirements=0D=0Apro= ductively if some group of people simply think the source is=0D=0Aunqualifi= ed to present any and spend all their time trying to discredit=0D=0Aproposa= ls on that basis. Thank you for not smoking anyone=3F As I recall,=0D=0Athe= specific point was about why LbyR was needed and it was before=0D=0Ageopri= v had begun to assimilate the value of that concept as well.=0D=0A=0D=0AI t= hink all of the NENA requirements have been raised and discussed -=0D=0Athe= latest concept to cause indigestion is location signing.=0D=0A=0D=0AI will= put together a list of what I think all the requirements are that=0D=0Ahav= e been raised - including the NENA ones and others subsequently=0D=0Amentio= ned and try to get it out in a succinct form this week.=0D=0A=0D=0ACheers,=0D= =0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Hannes Tschofeni= g [mailto:Hannes.Tschofenig@gmx.net]=20=0D=0ASent: Sunday, 11 March 2007 6:= 47 AM=0D=0ATo: GEOPRIV=0D=0ASubject: [Geopriv] NENA Requirements=0D=0A=0D=0A= Some reviewers of note that the=20=0D= =0Arequirements in=0D=0Ahttp://www.nena.org/media/files/08-505_20061221.pdf= also have to be=20=0D=0Aconsidered.=0D=0A=0D=0AInterestingly, this documen= t was published long after the design=20=0D=0Ateam work took place were the= se requirements could have been=20=0D=0Aintroduced.=0D=0A=0D=0A=0D=0AHere a= re the requirements and I will copy them in a separate mail:=0D=0A=0D=0A=0D= =0A4 Requirements=0D=0A=0D=0AThese requirements are excerpted from the NENA= TRD, NENA Requirements=0D=0Afor Location Information to Support Emergency = Services, for the=0D=0Aconvenience of the reader. If this document should i= nadvertently differ=0D=0Afrom the TRD, the TRD is to be considered the norm= ative reference.=0D=0AAs defined in the TRD, and as excerpted here, the ter= ms "shall", "must=0D=0A",=0D=0Aand "required" are used in this section to i= ndicate requirements and=0D=0Ato differentiate from those parameters that a= re recommendations.=0D=0A=0D=0ARecommendations are identified by the word "= should." Optional,=0D=0Adesirable capabilities are identified by the words = "desirable" or=0D=0A"preferably".=0D=0A=0D=0A4.1 Location Determination and= Acquisition=0D=0A=0D=0ADA1 - The access network shall provide a mechanism = for determination=0D=0Aand acquisition of location information, and support= queries for=0D=0Alocation.=0D=0A=0D=0ADA2 - The location estimate used sha= ll be that associated with the=0D=0Aphysically (wire, fiber, air) connected= network.=0D=0A=0D=0ADA3 - Location may be requested at any time. Location = information must=0D=0Abe associated with the device at the time the locatio= n is requested.=0D=0A=0D=0ADA4 - Location acquisition should be provided by= a consistent method=0D=0Aacross all network configurations.=0D=0A=0D=0ADA5= - Location determination and acquisition mechanisms must be=0D=0Aapplicabl= e to emergency calling, and may also be applicable to a wide=0D=0Arange of = value-added location-based services.=0D=0A=0D=0ADA6 - Location determinatio= n and acquisition techniques shall support=0D=0Aboth NENA i2 and i3 network= architectures.=0D=0A=0D=0ADA7 (Location 1400-0100 from LTD WG i3 rqmts) - = When measurement=0D=0Abased-location determination mechanisms fail, the mos= t accurate=0D=0Alocation information available should be provided. Examples= include:=0D=0AFor mobile, the Wireless Service Provider might provide towe= r/Access=0D=0APoint location, last known fix, etc. For wireline, a LIS migh= t provide=0D=0Aa civic location that defines the serving area of an access = point,=0D=0Ae.g., the State of Texas.=0D=0A=0D=0ADA8 - Location determinati= on and acquisition must provide minimal=0D=0Aimpact to call setup time in t= he event that location is not known ahead=0D=0Aof time.=0D=0A=0D=0ADA9 - Wh= ere a device is not location aware the IP Access network should=0D=0Ahave t= he ability to provide a location estimate on behalf of the=0D=0Adevice.=0D=0A=0D= =0ADA10 - Location acquisition methods should not require modification of=0D= =0Ahardware/firmware in home-routers/modems.=0D=0A=0D=0ADA11 - A location d= etermination method must exist that does not require=0D=0Anetwork hardware = replacement.=0D=0A=0D=0ADA12 -- The location acquisition protocol shall all= ow the requesting=0D=0Adevice to specify a response time requirement to the= LIS when=0D=0Arequesting location information. The response time is expres= sed as the=0D=0Amaximum time that the requesting node is prepared to wait f= or location=0D=0Ainformation. The LIS is required to provide the most accur= ate location=0D=0Afix it can within the specified response time.=0D=0A=0D=0A= 4.2 Location Representation=0D=0A=0D=0ALocation Representation refers to th= e form and contents that are used=0D=0Ato represent the geographic location= of an Endpoint.=0D=0A=0D=0ARep1 - Location information may be provided as = location-by-value or=0D=0Alocation-by-reference and the form is subject to = the nature of the=0D=0Arequest.=0D=0A=0D=0ARep2 - Location determination an= d acquisition mechanisms must support=0D=0Aall location information fields = defined within a PIDF-LO.=0D=0A=0D=0ARep3 - Location acquisition mechanisms= must allow for easy backwards=0D=0Acompatibility as the representation of = location information evolves.=0D=0A=0D=0ARep4 - All representations of loca= tion shall include the ability to=0D=0Acarry altitude and/or floor designat= ion. This requirement does not=0D=0Aimply altitude and/or floor designation= is always used or supplied.=0D=0A=0D=0A4.3 Location Security and Dependabi= lity=0D=0A=0D=0ALocSec1 - Location information shall only be provided to au= thenticated=0D=0Aand authorized network devices. The degree of authenticati= on and=0D=0Aauthorization required may vary depending on the network.=0D=0A=0D= =0ALocSec2 - Location determination and acquisition methods should=0D=0Apre= serve privacy of location information, subject to local laws and=0D=0Aregul= ations.=0D=0A=0D=0ALocSec3 - The location or location estimate of a caller = should be=0D=0Adependable.=0D=0A=0D=0ALocSec4 - The location acquisition pr= otocol must support authentication=0D=0Aof the Location Information Server,= integrity protection of the=0D=0ALocation Information, and protection agai= nst replay.=0D=0A=0D=0ALocSec5 - The location source shall be identified an= d should be=0D=0Aauthenticated. This includes manually entered location1.=0D= =0A=0D=0ALocSec6 - Where a location is acquired and cached prior to an emer= gency=0D=0Acall, it should be refreshed at regular intervals to ensure that= it is=0D=0Aas current as possible, in the event location information canno= t be=0D=0Aobtained in real time.=0D=0A=0D=0ALocSec7 - Where location by-ref= erence is used the appropriate privacy=0D=0Apolicies must be implemented an= d enforced by the LIS operator.=0D=0A=0D=0A=0D=0A=0D=0A____________________= ___________________________=0D=0AGeopriv mailing list=0D=0AGeopriv@ietf.org=0D= =0Ahttps://www1.ietf.org/mailman/listinfo/geopriv=0D=0A=0D=0A--------------= ---------------------------------------------------------------------------= -------=0D=0AThis message is for the designated recipient only and may=0D=0A= contain privileged, proprietary, or otherwise private information. =20=0D=0A= If you have received it in error, please notify the sender=0D=0Aimmediately= and delete the original. Any unauthorized use of=0D=0Athis email is prohi= bited.=0D=0A---------------------------------------------------------------= ---------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 22:08: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 1HQEQQ-0004XQ-KN; Sat, 10 Mar 2007 22:08:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQEQP-0004XI-6W for geopriv@ietf.org; Sat, 10 Mar 2007 22:08:45 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQEQO-0005PL-PH for geopriv@ietf.org; Sat, 10 Mar 2007 22:08:45 -0500 X-SEF-Processed: 5_0_0_910__2007_03_10_21_14_38 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); Sat, 10 Mar 2007 21:14:38 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Mar 2007 21:08:42 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement Date: Sat, 10 Mar 2007 21:08:40 -0600 Message-ID: In-Reply-To: <45F30E39.3010601@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Geopriv L7 LCP: New Requirement Thread-Index: AcdjTsOILWsAysT6RM6RD5gOOmmjpwAO0woQ From: "Dawson, Martin" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 11 Mar 2007 03:08:42.0888 (UTC) FILETIME=[93285880:01C7638A] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: geopriv@ietf.org, Barbara.Stark@BellSouth.com, lendl@nic.at, andy@hxr.us X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Using civic for routing may work in the US where the MSAG is part of the le= gacy infrastructure. In other jurisdictions that I have spoken with, they w= ould hate to have to develop this just for routing calls. As such a nominal= geo associated with fixed wireline access points is also a requirement. He= nce the need to be able to get both forms if possible.=0D=0A=0D=0AThere is = plenty of demand for a response time parameter and it is in the NENA requir= ements. It has a very valid application in doing location technology arbitr= ation in wireless location measurement - it is used already in 2G and 3G lo= cation determination. There is nothing in IP Location that removes this req= uirement - your opinion not withstanding being valid as your opinion.=0D=0A=0D= =0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Han= nes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20=0D=0ASent: Sunday, 11 = March 2007 7:00 AM=0D=0ATo: jerome.grenier@bell.ca=0D=0ACc: geopriv@ietf.or= g; Barbara.Stark@BellSouth.com; lendl@nic.at; andy@hxr.us=0D=0ASubject: Re:= [Geopriv] Geopriv L7 LCP: New Requirement=0D=0A=0D=0AHi Jerome,=0D=0A=0D=0A= jerome.grenier@bell.ca wrote:=0D=0A> I agree with Barbara and would also ad= d :=20=0D=0A>=0D=0A> - ability to request geo and/or civic location=0D=0A> = =20=0D=0A=0D=0ABarbara previously said that geo-location does not make sen= se in the DSL=20=0D=0Aenvironment.=0D=0AI guess you are pointing to a diffe= rent environment. The question is=20=0D=0Aonly: Is the LIS-to-LIS communica= tion needed there as well=3F=0D=0A=0D=0A> The "ability to specify how quick= ly a response is needed" would also be really helpful to us.=0D=0A> =20=0D= =0AI don't think that this is useful for this particular application.=0D=0A=0D= =0A> Having a BCP (one or more) that recommends a syntax to express various= identifier types for common protocols like SIP/PRES and HTTP would be grea= t!=0D=0A>=0D=0A> =20=0D=0ACiao=0D=0AHanes=0D=0A=0D=0A> J=E9r=F4me=0D=0A>=0D= =0A> -----Message d'origine-----=0D=0A> De : Stark, Barbara [mailto:Barbara= =2EStark@BellSouth.com]=20=0D=0A> Envoy=E9 : 16 f=E9vrier 2007 10:05=0D=0A>= =C0 : Andrew Newton=0D=0A> Cc : geopriv@ietf.org; Otmar Lendl=0D=0A> Objet= : RE: [Geopriv] Geopriv L7 LCP: New Requirement=0D=0A>=0D=0A> I hate to br= eak ranks, but if we could get the user part figured out=0D=0A> (and I do t= hink we would need some standardization, even if it's just a=0D=0A> BCP), I= kind of like this proposed solution. It has a certain simplicity=0D=0A> to= it.=0D=0A>=0D=0A> Since we've been pushing for these LISs to support LbyR,= anyway, and=0D=0A> this is really just LbyR, I don't see it as being a dif= ferent protocol,=0D=0A> yet again. This is a protocol we'd expect to be sup= ported by a LIS in=0D=0A> any case. The only change is that the URI may req= uire careful parsing by=0D=0A> the queried LIS, and the querier LIS needs t= o support LbyR queries in=0D=0A> both directions.=0D=0A>=0D=0A> When I look= at the functions in HELD (and RELO has a subset of these),=0D=0A> and thin= k through which of those functions would I really need for=0D=0A> LIS-LIS o= r OBO, I come up with:=0D=0A> - ability to request reference -- not needed,= since, as pointed out,=0D=0A> I've already got a perfectly good non-expiri= ng reference; OBO querier or=0D=0A> LIS doesn't need to ask for references = to hand off to others, it should=0D=0A> create its own references for that,= as appropriate [aside: a=0D=0A> non-expiring reference and a "LCP" are rat= her equal in the privacy=0D=0A> debate from the OBO/LIS-LIS perspective.]=0D= =0A> - ability to assert location -- not needed for OBO or LIS-LIS; only an=0D= =0A> end device should be able to do this, if even that is allowed=0D=0A> -= ability to provide rules/profile for privacy -- not needed for OBO or=0D=0A= > LIS-LIS; only the device should be able to do this=0D=0A> - ability to si= gn location -- if this is part of PIDF-LO, then this is=0D=0A> independent = of request mechanism=0D=0A> - ability to request that location be signed --= I think we can assume=0D=0A> that the location should be signed if it can = be signed=0D=0A> - ability to specify how quickly a response is needed -- t= his would be=0D=0A> useful, but it may be possible to design around the iss= ue=0D=0A> - have I missed anything=3F=0D=0A>=0D=0A> Supporting URI formats = other than SIP (e.g., HTTP) would still need to=0D=0A> be worked. But that = format would be common to all LbyR usages.=0D=0A> This in no way removes th= e requirement for a device-to-LIS "LCP". I=0D=0A> haven't read that into th= e suggestion at all.=0D=0A>=0D=0A> So, I think this idea warrants considera= tion.=0D=0A> Barbara=0D=0A>=0D=0A> -----Original Message-----=0D=0A> From: = Andrew Newton [mailto:andy@hxr.us]=20=0D=0A> Sent: Thursday, February 15, 2= 007 3:51 PM=0D=0A> To: Stark, Barbara=0D=0A> Cc: geopriv@ietf.org; Otmar Le= ndl=0D=0A> Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement=0D=0A>=0D= =0A>=0D=0A> On Feb 15, 2007, at 12:50 PM, Stark, Barbara wrote:=0D=0A>=0D=0A= > =20=0D=0A>> What is difficult, is figuring out a standard format for a U= RI user=20=0D=0A>> part that would allow for all the variations in combinat= ions of IDs=20=0D=0A>> that exist, so that a standard format could be defin= ed that would=20=0D=0A>> cover all interconnection models. Section 8 of the= NENA Location TID=0D=0A>> (http://www.nena.org/media/files/08-505_20061221= =2Epdf) provides 5=20=0D=0A>> different examples of interconnection models,= and the IDs that would=20=0D=0A>> need to be used in each of these cases. = In this document, scenario 1=20=0D=0A>> uses the IP address, scenario 2 use= s NAS-ID and ATM PVC, scenario 3=20=0D=0A>> uses=0D=0A>> 2 VLAN tags, scena= rio 4 uses IP address, and scenario 5 uses L2TP=20=0D=0A>> tunnel ID (sourc= e and destination) and PPPoE session ID. These are=20=0D=0A>> just 5 possib= le examples, and should not be considered exhaustive.=0D=0A>> Interconnecti= on models are still evolving.=0D=0A>> =20=0D=0A>=0D=0A> Well, that's eas= ily solved with a BCP for formulating URIs based on the=0D=0A> ID. You don= 't need a new protocol or to conflate the LCP protocol with=0D=0A> this fun= ctionality.=0D=0A>=0D=0A> -andy=0D=0A>=0D=0A> *****=0D=0A>=0D=0A> The infor= mation transmitted is intended only for the person or entity to which it is= addressed and may contain confidential, proprietary, and/or privileged mat= erial. Any review, retransmission, dissemination or other use of, or taking= of any action in reliance upon this information by persons or entities oth= er than the intended recipient is prohibited. If you received this in error= , please contact the sender and delete the material from all computers. GA6= 21=0D=0A>=0D=0A>=0D=0A>=0D=0A> ____________________________________________= ___=0D=0A> Geopriv mailing list=0D=0A> Geopriv@ietf.org=0D=0A> https://www1= =2Eietf.org/mailman/listinfo/geopriv=0D=0A>=0D=0A> ________________________= _______________________=0D=0A> Geopriv mailing list=0D=0A> Geopriv@ietf.org=0D= =0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A>=0D=0A> =20=0D=0A=0D= =0A=0D=0A_______________________________________________=0D=0AGeopriv maili= ng list=0D=0AGeopriv@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/listinfo/g= eopriv=0D=0A=0D=0A---------------------------------------------------------= ---------------------------------------=0D=0AThis message is for the design= ated recipient only and may=0D=0Acontain privileged, proprietary, or otherw= ise private information. =20=0D=0AIf you have received it in error, please = notify the sender=0D=0Aimmediately and delete the original. Any unauthoriz= ed use of=0D=0Athis email is prohibited.=0D=0A-----------------------------= -------------------------------------------------------------------=0D=0A[m= f2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 22:54: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 1HQF93-0002lL-VW; Sat, 10 Mar 2007 22:54:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQF93-0002lG-Fw for geopriv@ietf.org; Sat, 10 Mar 2007 22:54:53 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQF92-00043L-0N for geopriv@ietf.org; Sat, 10 Mar 2007 22:54:53 -0500 X-SEF-Processed: 5_0_0_910__2007_03_10_22_00_47 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); Sat, 10 Mar 2007 22:00:47 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Mar 2007 21:54:51 -0600 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: [Geopriv] NENA Requirements Date: Sat, 10 Mar 2007 21:54:49 -0600 Message-ID: In-Reply-To: <45F315AC.1040407@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] NENA Requirements Thread-Index: AcdjU0Yh/Wnh8neSQJeyHFkHJ1G/RgAOLWxg From: "Dawson, Martin" To: "Hannes Tschofenig" , "GEOPRIV" X-OriginalArrivalTime: 11 Mar 2007 03:54:51.0627 (UTC) FILETIME=[057463B0:01C76391] X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org =0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Hannes Tschofenig [mailto= :Hannes.Tschofenig@gmx.net]=20=0D=0ASent: Sunday, 11 March 2007 7:32 AM=0D=0A= To: GEOPRIV=0D=0ASubject: Re: [Geopriv] NENA Requirements=0D=0A=0D=0AHi all= ,=0D=0A=0D=0AI went through the requirements and most of them seem to be pr= etty=20=0D=0Airrelevant. Please find a few minor comments below:=0D=0A=0D=0A= Hannes Tschofenig wrote:=0D=0A> Some reviewers of note that the=20=0D=0A> requirements in=0D=0A> http://www.nena= =2Eorg/media/files/08-505_20061221.pdf also have to be=20=0D=0A> considered= =2E=0D=0A>=0D=0A> Interestingly, this document was published long after the= design team=20=0D=0A> work took place were these requirements could have b= een introduced.=0D=0A>=0D=0A>=0D=0A> Here are the requirements and I will c= opy them in a separate mail:=0D=0A>=0D=0A>=0D=0A> 4 Requirements=0D=0A>=0D=0A= > These requirements are excerpted from the NENA TRD, NENA Requirements=0D=0A= > for Location Information to Support Emergency Services, for the=0D=0A> co= nvenience of the reader. If this document should inadvertently=0D=0Adiffer=0D= =0A>> from the TRD, the TRD is to be considered the normative reference.=0D= =0A> As defined in the TRD, and as excerpted here, the terms "shall", "must=0D= =0A",=0D=0A> and "required" are used in this section to indicate requiremen= ts and=0D=0A> to differentiate from those parameters that are recommendatio= ns.=0D=0A>=0D=0A> Recommendations are identified by the word "should." Opti= onal,=0D=0A> desirable capabilities are identified by the words "desirable"= or=0D=0A> "preferably".=0D=0A>=0D=0A> 4.1 Location Determination and Acqui= sition=0D=0A>=0D=0A> DA1 - The access network shall provide a mechanism for= determination=0D=0A> and acquisition of location information, and support = queries for=0D=0A> location.=0D=0A>=0D=0A> DA2 - The location estimate used= shall be that associated with the=0D=0A> physically (wire, fiber, air) con= nected network.=0D=0A>=0D=0A> DA3 - Location may be requested at any time. = Location information must=0D=0A> be associated with the device at the time = the location is requested.=0D=0A>=0D=0A> DA4 - Location acquisition should = be provided by a consistent method=0D=0A> across all network configurations= =2E=0D=0A>=0D=0A> DA5 - Location determination and acquisition mechanisms m= ust be=0D=0A> applicable to emergency calling, and may also be applicable t= o a wide=0D=0A> range of value-added location-based services.=0D=0A>=0D=0A>= DA6 - Location determination and acquisition techniques shall support=0D=0A= > both NENA i2 and i3 network architectures.=0D=0A>=0D=0A> DA7 (Location 14= 00-0100 from LTD WG i3 rqmts) - When measurement=0D=0A> based-location dete= rmination mechanisms fail, the most accurate=0D=0A> location information av= ailable should be provided. Examples include:=0D=0A> For mobile, the Wirele= ss Service Provider might provide tower/Access=0D=0A> Point location, last = known fix, etc. For wireline, a LIS might provide=0D=0A> a civic location t= hat defines the serving area of an access point,=0D=0A> e.g., the State of = Texas.=0D=0A>=0D=0A> DA8 - Location determination and acquisition must prov= ide minimal=0D=0A> impact to call setup time in the event that location is = not known=0D=0Aahead=0D=0A> of time.=0D=0A>=0D=0A> DA9 - Where a device is = not location aware the IP Access network=0D=0Ashould=0D=0A> have the abilit= y to provide a location estimate on behalf of the=0D=0A> device.=0D=0A>=0D=0A= > DA10 - Location acquisition methods should not require modification of=0D= =0A> hardware/firmware in home-routers/modems.=0D=0A>=0D=0A> DA11 - A locat= ion determination method must exist that does not=0D=0Arequire=0D=0A> netwo= rk hardware replacement.=0D=0A>=0D=0A> DA12 -- The location acquisition pro= tocol shall allow the requesting=0D=0A> device to specify a response time r= equirement to the LIS when=0D=0A> requesting location information. The resp= onse time is expressed as the=0D=0A> maximum time that the requesting node = is prepared to wait for location=0D=0A> information. The LIS is required to= provide the most accurate location=0D=0A> fix it can within the specified = response time.=0D=0A=0D=0AI think that this is the wrong concept.=0D=0A=0D=0A= I think what you really want is an indication about the granularity of=20=0D= =0Athe returned location information.=0D=0A=0D=0A[[MCD]] That would be inco= rrect. The people who need to implement and=0D=0Ause this desire that they = can prescribe a response time and the systems=0D=0Aprovide *the best accura= cy they can within the prescribed response=0D=0Atime*. I don't know if you'= re saying that the request should include a=0D=0Aguideline for preferred gr= anularity or whether you are saying that=0D=0Aresponse should just indicate= uncertainty. The latter is orthogonal and,=0D=0Ayes, it should return an i= ndication of uncertainty. These considerations=0D=0Aare all especially pert= inent to mobile wireless access.=20=0D=0A=0D=0A>=0D=0A> 4.2 Location Repres= entation=0D=0A>=0D=0A> Location Representation refers to the form and conte= nts that are used=0D=0A> to represent the geographic location of an Endpoin= t.=0D=0A>=0D=0A> Rep1 - Location information may be provided as location-by= -value or=0D=0A> location-by-reference and the form is subject to the natur= e of the=0D=0A> request.=0D=0A>=0D=0A> Rep2 - Location determination and ac= quisition mechanisms must support=0D=0A> all location information fields de= fined within a PIDF-LO.=0D=0A>=0D=0A> Rep3 - Location acquisition mechanism= s must allow for easy backwards=0D=0A> compatibility as the representation = of location information evolves.=0D=0A>=0D=0A> Rep4 - All representations o= f location shall include the ability to=0D=0A> carry altitude and/or floor = designation. This requirement does not=0D=0A> imply altitude and/or floor d= esignation is always used or supplied.=0D=0A>=0D=0A> 4.3 Location Security = and Dependability=0D=0A>=0D=0A> LocSec1 - Location information shall only b= e provided to authenticated=0D=0A> and authorized network devices. The degr= ee of authentication and=0D=0A> authorization required may vary depending o= n the network.=0D=0A>=0D=0AI guess that this refers to location-by-referenc= e only.=0D=0A=0D=0A[[MCD]] No, it's really a generic requirement. A device = asking for its=0D=0Aown location on the access network covered by the LIS m= ay be implicitly=0D=0Aauthorized, an OBO request for that same device may r= equire a different=0D=0Alevel of authorization and, as you say, it may also= apply to the=0D=0Adereferencing request applied for that target. The appli= cable degree of=0D=0Aauthorization for each scenario may be domain-specific= =2E=20=0D=0A=0D=0A> LocSec2 - Location determination and acquisition method= s should=0D=0A> preserve privacy of location information, subject to local = laws and=0D=0A> regulations.=0D=0A>=0D=0A> LocSec3 - The location or locati= on estimate of a caller should be=0D=0A> dependable.=0D=0AWhat does "depend= able" mean in this context=3F=0D=0A=0D=0A[[MCD]] I am sure that this has be= en described numerous times already.=0D=0AIt's what we have been talking ab= out viz location signing. It covers the=0D=0Acharacteristics that the locat= ion information:=0D=0A=0D=0A* Can be attributed to a recognized source=0D=0A= * Has not been tampered with since generated at that source=0D=0A* Is appli= cable to a specific target identity=0D=0A* Is applicable at a particular po= int in time=0D=0A=0D=0A>=0D=0A> LocSec4 - The location acquisition protocol= must support=0D=0Aauthentication=0D=0A> of the Location Information Server= , integrity protection of the=0D=0A> Location Information, and protection a= gainst replay.=0D=0A>=0D=0A> LocSec5 - The location source shall be identif= ied and should be=0D=0A> authenticated. This includes manually entered loca= tion1.=0D=0A=0D=0AI wonder how this would look like.=0D=0A[[MCD]] How what = would look like=3F As discussed, the proposal is to=0D=0Ainclude certificat= e mechanisms to make the source of the location=0D=0Ainformation explicit. = For location entered into a device, the assertion=0D=0Amechanism may be use= d to have the LIS do this. More prosaically, and=0D=0Aconsistent with the c= urrent FCC requirement that VoIP providers allow=0D=0Atheir subscribers to = enter their current location via a service provider=0D=0Aweb page or equiva= lent, the location proffered on the call may similarly=0D=0Aidentify the so= urce of the location information. This is not actually a=0D=0ALIS protocol = requirement but I'm sure it was what was on a lot of=0D=0Apeople's minds wh= en the requirement was being discussed - you know what=0D=0Acommittees are = like.=0D=0A=0D=0A>=0D=0A> LocSec6 - Where a location is acquired and cached= prior to an=0D=0Aemergency=0D=0A> call, it should be refreshed at regular = intervals to ensure that it is=0D=0A> as current as possible, in the event = location information cannot be=0D=0A> obtained in real time.=0D=0A>=0D=0ATh= is is not a security requirement.=0D=0A[[MCD]] Yes, it's not very well cate= gorized - can't argue with that.=0D=0AGenerally speaking, it's a function o= f LIS implementation as well and=0D=0Atends to be independent of the acquis= ition protocol used - though not=0D=0Acompletely.=0D=0A=0D=0A> LocSec7 - Wh= ere location by-reference is used the appropriate privacy=0D=0A> policies m= ust be implemented and enforced by the LIS operator.=0D=0A=0D=0AWhat does t= his mean in context of requirement LocSec2 =3F=0D=0A[[MCD]] The device requ= esting the reference can provide its privacy=0D=0Apolicies and LIS must hon= our them. LocSec2 acknowledges that certain=0D=0Asome jurisdictions may nee= d to override these (e.g. location for=0D=0Aemergency services).=0D=0A=0D=0A= Ciao=0D=0AHannes=0D=0A=0D=0A>=0D=0A>=0D=0A> _______________________________= ________________=0D=0A> Geopriv mailing list=0D=0A> Geopriv@ietf.org=0D=0A>= https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A=0D=0A=0D=0A__________= _____________________________________=0D=0AGeopriv mailing list=0D=0AGeopri= v@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/listinfo/geopriv=0D=0A=0D=0A-= ---------------------------------------------------------------------------= --------------------=0D=0AThis message is for the designated recipient only= and may=0D=0Acontain privileged, proprietary, or otherwise private informa= tion. =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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 10 22:57: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 1HQFBt-0005Gv-RF; Sat, 10 Mar 2007 22:57:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQFBs-0005Ge-L8 for geopriv@ietf.org; Sat, 10 Mar 2007 22:57:48 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQFBr-0004QL-Kc for geopriv@ietf.org; Sat, 10 Mar 2007 22:57:48 -0500 X-SEF-Processed: 5_0_0_910__2007_03_10_22_03_43 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); Sat, 10 Mar 2007 22:03:42 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Mar 2007 21:57:47 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement Date: Sat, 10 Mar 2007 21:57:44 -0600 Message-ID: In-Reply-To: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A258329@toroondc912> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Geopriv L7 LCP: New Requirement Thread-Index: AcdjTq6oCwwLP31aSO2XSVgOtXM5owABAxhQAA+cyeA= From: "Dawson, Martin" To: , X-OriginalArrivalTime: 11 Mar 2007 03:57:47.0173 (UTC) FILETIME=[6E169550:01C76391] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: geopriv@ietf.org, Barbara.Stark@BellSouth.com, lendl@nic.at, andy@hxr.us X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org If we consider that the LIS-LIS scenario is typically an ISP LIS gatewaying= the request to the infrastructure operator LIS, then the response time par= ameter still gets carried across that interface. I think the question of LI= S-LIS versus target-LIS versus OBO, versus dereference are all orthogonal t= o the question of the utility of the response time parameter.=0D=0A=0D=0ACh= eers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: jerome.g= renier@bell.ca [mailto:jerome.grenier@bell.ca]=20=0D=0ASent: Sunday, 11 Mar= ch 2007 7:44 AM=0D=0ATo: Hannes.Tschofenig@gmx.net=0D=0ACc: geopriv@ietf.or= g; Barbara.Stark@BellSouth.com; lendl@nic.at; andy@hxr.us=0D=0ASubject: RE:= [Geopriv] Geopriv L7 LCP: New Requirement=0D=0A=0D=0AHi Hannes,=0D=0A=0D=0A= Indeed, the scenario I had in mind did not involve LIS-to-LIS in a DSL envi= ronment. It is the mobile access to the Internet scenario (3G cell phones /= PDAs, PC cards, etc). The deployment I know involves only one entity as bo= th the Internet Service Provider and the (mobile) Access Service Provider, = therefore only one LIS is needed. Of course, the LIS-to-LIS issues would ap= ply to deployments where those two providers would be different organizatio= ns (I don't know if such deployments actually exist).=0D=0A=0D=0AIn this mo= bile environment, the ability to specify how quickly a response is needed s= eems useful. Note that this makes more sense from an OBO perspective as wel= l as if the mobile device itself tries to acquire its location just in time= for an emergency call, for example.=0D=0A=0D=0AJ=E9r=F4me=0D=0A=0D=0A-----= Message d'origine-----=0D=0ADe=A0: Hannes Tschofenig [mailto:Hannes.Tschofe= nig@gmx.net]=20=0D=0AEnvoy=E9=A0: 10 mars 2007 15:00=0D=0A=C0=A0: Grenier, = Jerome (6002687)=0D=0ACc=A0: Barbara.Stark@BellSouth.com; andy@hxr.us; geop= riv@ietf.org; lendl@nic.at=0D=0AObjet=A0: Re: [Geopriv] Geopriv L7 LCP: New= Requirement=0D=0A=0D=0AHi Jerome,=0D=0A=0D=0Ajerome.grenier@bell.ca wrote:=0D= =0A> I agree with Barbara and would also add :=20=0D=0A>=0D=0A> - ability t= o request geo and/or civic location=0D=0A> =20=0D=0A=0D=0ABarbara previous= ly said that geo-location does not make sense in the DSL=20=0D=0Aenvironmen= t.=0D=0AI guess you are pointing to a different environment. The question i= s=20=0D=0Aonly: Is the LIS-to-LIS communication needed there as well=3F=0D=0A=0D= =0A> The "ability to specify how quickly a response is needed" would also b= e really helpful to us.=0D=0A> =20=0D=0AI don't think that this is useful = for this particular application.=0D=0A=0D=0A> Having a BCP (one or more) th= at recommends a syntax to express various identifier types for common proto= cols like SIP/PRES and HTTP would be great!=0D=0A>=0D=0A> =20=0D=0ACiao=0D= =0AHanes=0D=0A=0D=0A> J=E9r=F4me=0D=0A>=0D=0A> -----Message d'origine-----=0D= =0A> De : Stark, Barbara [mailto:Barbara.Stark@BellSouth.com]=20=0D=0A> Env= oy=E9 : 16 f=E9vrier 2007 10:05=0D=0A> =C0 : Andrew Newton=0D=0A> Cc : geop= riv@ietf.org; Otmar Lendl=0D=0A> Objet : RE: [Geopriv] Geopriv L7 LCP: New = Requirement=0D=0A>=0D=0A> I hate to break ranks, but if we could get the us= er part figured out=0D=0A> (and I do think we would need some standardizati= on, even if it's just a=0D=0A> BCP), I kind of like this proposed solution.= It has a certain simplicity=0D=0A> to it.=0D=0A>=0D=0A> Since we've been p= ushing for these LISs to support LbyR, anyway, and=0D=0A> this is really ju= st LbyR, I don't see it as being a different protocol,=0D=0A> yet again. Th= is is a protocol we'd expect to be supported by a LIS in=0D=0A> any case. T= he only change is that the URI may require careful parsing by=0D=0A> the qu= eried LIS, and the querier LIS needs to support LbyR queries in=0D=0A> both= directions.=0D=0A>=0D=0A> When I look at the functions in HELD (and RELO h= as a subset of these),=0D=0A> and think through which of those functions wo= uld I really need for=0D=0A> LIS-LIS or OBO, I come up with:=0D=0A> - abili= ty to request reference -- not needed, since, as pointed out,=0D=0A> I've a= lready got a perfectly good non-expiring reference; OBO querier or=0D=0A> L= IS doesn't need to ask for references to hand off to others, it should=0D=0A= > create its own references for that, as appropriate [aside: a=0D=0A> non-e= xpiring reference and a "LCP" are rather equal in the privacy=0D=0A> debate= from the OBO/LIS-LIS perspective.]=0D=0A> - ability to assert location -- = not needed for OBO or LIS-LIS; only an=0D=0A> end device should be able to = do this, if even that is allowed=0D=0A> - ability to provide rules/profile = for privacy -- not needed for OBO or=0D=0A> LIS-LIS; only the device should= be able to do this=0D=0A> - ability to sign location -- if this is part of= PIDF-LO, then this is=0D=0A> independent of request mechanism=0D=0A> - abi= lity to request that location be signed -- I think we can assume=0D=0A> tha= t the location should be signed if it can be signed=0D=0A> - ability to spe= cify how quickly a response is needed -- this would be=0D=0A> useful, but i= t may be possible to design around the issue=0D=0A> - have I missed anythin= g=3F=0D=0A>=0D=0A> Supporting URI formats other than SIP (e.g., HTTP) would= still need to=0D=0A> be worked. But that format would be common to all Lby= R usages.=0D=0A> This in no way removes the requirement for a device-to-LIS= "LCP". I=0D=0A> haven't read that into the suggestion at all.=0D=0A>=0D=0A= > So, I think this idea warrants consideration.=0D=0A> Barbara=0D=0A>=0D=0A= > -----Original Message-----=0D=0A> From: Andrew Newton [mailto:andy@hxr.us= ]=20=0D=0A> Sent: Thursday, February 15, 2007 3:51 PM=0D=0A> To: Stark, Bar= bara=0D=0A> Cc: geopriv@ietf.org; Otmar Lendl=0D=0A> Subject: Re: [Geopriv]= Geopriv L7 LCP: New Requirement=0D=0A>=0D=0A>=0D=0A> On Feb 15, 2007, at 1= 2:50 PM, Stark, Barbara wrote:=0D=0A>=0D=0A> =20=0D=0A>> What is difficult= , is figuring out a standard format for a URI user=20=0D=0A>> part that wou= ld allow for all the variations in combinations of IDs=20=0D=0A>> that exis= t, so that a standard format could be defined that would=20=0D=0A>> cover a= ll interconnection models. Section 8 of the NENA Location TID=0D=0A>> (http= ://www.nena.org/media/files/08-505_20061221.pdf) provides 5=20=0D=0A>> diff= erent examples of interconnection models, and the IDs that would=20=0D=0A>>= need to be used in each of these cases. In this document, scenario 1=20=0D= =0A>> uses the IP address, scenario 2 uses NAS-ID and ATM PVC, scenario 3 =0D= =0A>> uses=0D=0A>> 2 VLAN tags, scenario 4 uses IP address, and scenario 5 = uses L2TP=20=0D=0A>> tunnel ID (source and destination) and PPPoE session I= D. These are=20=0D=0A>> just 5 possible examples, and should not be conside= red exhaustive.=0D=0A>> Interconnection models are still evolving.=0D=0A>> = =20=0D=0A>=0D=0A> Well, that's easily solved with a BCP for formulating = URIs based on the=0D=0A> ID. You don't need a new protocol or to conflate = the LCP protocol with=0D=0A> this functionality.=0D=0A>=0D=0A> -andy=0D=0A>=0D= =0A> *****=0D=0A>=0D=0A> The information transmitted is intended only for t= he person or entity to which it is addressed and may contain confidential, = proprietary, and/or privileged material. Any review, retransmission, dissem= ination or other use of, or taking of any action in reliance upon this info= rmation by persons or entities other than the intended recipient is prohibi= ted. If you received this in error, please contact the sender and delete th= e material from all computers. GA621=0D=0A>=0D=0A>=0D=0A>=0D=0A> __________= _____________________________________=0D=0A> Geopriv mailing list=0D=0A> Ge= opriv@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A>=0D= =0A> _______________________________________________=0D=0A> Geopriv mailing= list=0D=0A> Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo= /geopriv=0D=0A>=0D=0A> =20=0D=0A=0D=0A=0D=0A______________________________= _________________=0D=0AGeopriv mailing list=0D=0AGeopriv@ietf.org=0D=0Ahttp= s://www1.ietf.org/mailman/listinfo/geopriv=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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sun Mar 11 16:35: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 1HQUlL-0001U3-Pf; Sun, 11 Mar 2007 16:35:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQUlK-0001Tv-HF for geopriv@ietf.org; Sun, 11 Mar 2007 16:35:26 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQUlG-0006IS-0v for geopriv@ietf.org; Sun, 11 Mar 2007 16:35:26 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HQUl0-0001Bv-Bo; Sun, 11 Mar 2007 15:35:06 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Hannes Tschofenig'" , Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement Date: Sun, 11 Mar 2007 16:35:14 -0400 Message-ID: <020a01c7641c$c7a0bb10$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcdjTsOILWsAysT6RM6RD5gOOmmjpwAO0woQACSEByA= 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 - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: geopriv@ietf.org, Barbara.Stark@BellSouth.com, lendl@nic.at, andy@hxr.us X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Is there really a use for more response time requests that "immediate" = and "eventually"? I certainly don't see any use for more than those two in = the emergency case (recognizing that current systems don't have any such options). I can see "immediate" as needed for call routing, while "eventually" is the "get me an accurate fix" that you use to send responders. I don't see why anyone would need more than that, and I = think the direction of the technology is to moving towards faster accurate = fixes, so the need to have intermediate states is clearly going to go down over time. I also think this is another case where the requirement doesn't have anything to do with L7, although it does seem to have to do with mobile devices. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Saturday, March 10, 2007 10:09 PM > To: Hannes Tschofenig; jerome.grenier@bell.ca > Cc: geopriv@ietf.org; Barbara.Stark@BellSouth.com; lendl@nic.at; > andy@hxr.us > Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement >=20 > Using civic for routing may work in the US where the MSAG is part of = the > legacy infrastructure. In other jurisdictions that I have spoken with, > they would hate to have to develop this just for routing calls. As = such a > nominal geo associated with fixed wireline access points is also a > requirement. Hence the need to be able to get both forms if possible. >=20 > There is plenty of demand for a response time parameter and it is in = the > NENA requirements. It has a very valid application in doing location > technology arbitration in wireless location measurement - it is used > already in 2G and 3G location determination. There is nothing in IP > Location that removes this requirement - your opinion not withstanding > being valid as your opinion. >=20 > Cheers, > Martin >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Sunday, 11 March 2007 7:00 AM > To: jerome.grenier@bell.ca > Cc: geopriv@ietf.org; Barbara.Stark@BellSouth.com; lendl@nic.at; > andy@hxr.us > Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement >=20 > Hi Jerome, >=20 > jerome.grenier@bell.ca wrote: > > I agree with Barbara and would also add : > > > > - ability to request geo and/or civic location > > >=20 > Barbara previously said that geo-location does not make sense in the = DSL > environment. > I guess you are pointing to a different environment. The question is > only: Is the LIS-to-LIS communication needed there as well? >=20 > > The "ability to specify how quickly a response is needed" would also = be > really helpful to us. > > > I don't think that this is useful for this particular application. >=20 > > Having a BCP (one or more) that recommends a syntax to express = various > identifier types for common protocols like SIP/PRES and HTTP would be > great! > > > > > Ciao > Hanes >=20 > > J=E9r=F4me > > > > -----Message d'origine----- > > De : Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > > Envoy=E9 : 16 f=E9vrier 2007 10:05 > > =C0 : Andrew Newton > > Cc : geopriv@ietf.org; Otmar Lendl > > Objet : RE: [Geopriv] Geopriv L7 LCP: New Requirement > > > > I hate to break ranks, but if we could get the user part figured out > > (and I do think we would need some standardization, even if it's = just a > > BCP), I kind of like this proposed solution. It has a certain = simplicity > > to it. > > > > Since we've been pushing for these LISs to support LbyR, anyway, and > > this is really just LbyR, I don't see it as being a different = protocol, > > yet again. This is a protocol we'd expect to be supported by a LIS = in > > any case. The only change is that the URI may require careful = parsing by > > the queried LIS, and the querier LIS needs to support LbyR queries = in > > both directions. > > > > When I look at the functions in HELD (and RELO has a subset of = these), > > and think through which of those functions would I really need for > > LIS-LIS or OBO, I come up with: > > - ability to request reference -- not needed, since, as pointed out, > > I've already got a perfectly good non-expiring reference; OBO = querier or > > LIS doesn't need to ask for references to hand off to others, it = should > > create its own references for that, as appropriate [aside: a > > non-expiring reference and a "LCP" are rather equal in the privacy > > debate from the OBO/LIS-LIS perspective.] > > - ability to assert location -- not needed for OBO or LIS-LIS; only = an > > end device should be able to do this, if even that is allowed > > - ability to provide rules/profile for privacy -- not needed for OBO = or > > LIS-LIS; only the device should be able to do this > > - ability to sign location -- if this is part of PIDF-LO, then this = is > > independent of request mechanism > > - ability to request that location be signed -- I think we can = assume > > that the location should be signed if it can be signed > > - ability to specify how quickly a response is needed -- this would = be > > useful, but it may be possible to design around the issue > > - have I missed anything? > > > > Supporting URI formats other than SIP (e.g., HTTP) would still need = to > > be worked. But that format would be common to all LbyR usages. > > This in no way removes the requirement for a device-to-LIS "LCP". I > > haven't read that into the suggestion at all. > > > > So, I think this idea warrants consideration. > > Barbara > > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Thursday, February 15, 2007 3:51 PM > > To: Stark, Barbara > > Cc: geopriv@ietf.org; Otmar Lendl > > Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement > > > > > > On Feb 15, 2007, at 12:50 PM, Stark, Barbara wrote: > > > > > >> What is difficult, is figuring out a standard format for a URI user > >> part that would allow for all the variations in combinations of IDs > >> that exist, so that a standard format could be defined that would > >> cover all interconnection models. Section 8 of the NENA Location = TID > >> (http://www.nena.org/media/files/08-505_20061221.pdf) provides 5 > >> different examples of interconnection models, and the IDs that = would > >> need to be used in each of these cases. In this document, scenario = 1 > >> uses the IP address, scenario 2 uses NAS-ID and ATM PVC, scenario 3 > >> uses > >> 2 VLAN tags, scenario 4 uses IP address, and scenario 5 uses L2TP > >> tunnel ID (source and destination) and PPPoE session ID. These are > >> just 5 possible examples, and should not be considered exhaustive. > >> Interconnection models are still evolving. > >> > > > > Well, that's easily solved with a BCP for formulating URIs based on = the > > ID. You don't need a new protocol or to conflate the LCP protocol = with > > this functionality. > > > > -andy > > > > ***** > > > > The information transmitted is intended only for the person or = entity to > which it is addressed and may contain confidential, proprietary, = and/or > privileged material. Any review, retransmission, dissemination or = other > use of, or taking of any action in reliance upon this information by > persons or entities other than the intended recipient is prohibited. = If > you received this in error, please contact the sender and delete the > material from all computers. GA621 > > > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > = -------------------------------------------------------------------------= - > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > = -------------------------------------------------------------------------= - > ---------------------- > [mf2] >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sun Mar 11 18:17: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 1HQWLj-00035H-Ot; Sun, 11 Mar 2007 18:17:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQWLi-000352-HV for geopriv@ietf.org; Sun, 11 Mar 2007 18:17:06 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQWLg-0005IO-4r for geopriv@ietf.org; Sun, 11 Mar 2007 18:17:06 -0400 X-SEF-Processed: 5_0_0_910__2007_03_11_17_22_59 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); Sun, 11 Mar 2007 17:22:58 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Mar 2007 17:17:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement Date: Sun, 11 Mar 2007 17:16:49 -0500 Message-ID: In-Reply-To: <020a01c7641c$c7a0bb10$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Geopriv L7 LCP: New Requirement Thread-Index: AcdjTsOILWsAysT6RM6RD5gOOmmjpwAO0woQACSEByAAA31kIA== From: "Winterbottom, James" To: "Brian Rosen" , "Dawson, Martin" , "Hannes Tschofenig" , X-OriginalArrivalTime: 11 Mar 2007 22:17:02.0809 (UTC) FILETIME=[FEB5F490:01C7642A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: geopriv@ietf.org, Barbara.Stark@BellSouth.com, lendl@nic.at, andy@hxr.us X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I have to disagree with you on almost all counts below Brian, except possib= ly with more accurate results are coming more quickly.=0D=0A=0D=0AJSTD-036B= has specifically move away from the immediate request scenario for routing= to a low-delay one, as immediate will give you cell only routing, and low-= delay will give you a timing advance solution which substantially improves = accuracy, and hence reduces misroutes.=20=0D=0A=0D=0AYour last comment I th= ink gets to the crux of the matter. You are thinking a wireline solution on= ly for the L7 protocol, I am not. I think that what we want, and what we ar= e trying to come up with requirements for, is an acquisition protocol cover= s all access networks. So precluding wireless is a very significant exclusi= on.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Mes= sage-----=0D=0A> From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: = Monday, 12 March 2007 7:35 AM=0D=0A> To: Dawson, Martin; 'Hannes Tschofenig= '; jerome.grenier@bell.ca=0D=0A> Cc: geopriv@ietf.org; Barbara.Stark@BellSo= uth.com; lendl@nic.at;=0D=0A> andy@hxr.us=0D=0A> Subject: RE: [Geopriv] Geo= priv L7 LCP: New Requirement=0D=0A>=20=0D=0A> Is there really a use for mor= e response time requests that "immediate" and=0D=0A> "eventually"=3F I cer= tainly don't see any use for more than those two in=0D=0A> the=0D=0A> emerg= ency case (recognizing that current systems don't have any such=0D=0A> opti= ons). I can see "immediate" as needed for call routing, while=0D=0A> "even= tually" is the "get me an accurate fix" that you use to send=0D=0A> respond= ers. I don't see why anyone would need more than that, and I think=0D=0A> = the direction of the technology is to moving towards faster accurate=0D=0A>= fixes,=0D=0A> so the need to have intermediate states is clearly going to = go down over=0D=0A> time.=0D=0A>=20=0D=0A> I also think this is another cas= e where the requirement doesn't have=0D=0A> anything to do with L7, althoug= h it does seem to have to do with mobile=0D=0A> devices.=0D=0A>=20=0D=0A> B= rian=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> > -----Original Message-----=0D=0A= > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> > Sent: S= aturday, March 10, 2007 10:09 PM=0D=0A> > To: Hannes Tschofenig; jerome.gre= nier@bell.ca=0D=0A> > Cc: geopriv@ietf.org; Barbara.Stark@BellSouth.com; le= ndl@nic.at;=0D=0A> > andy@hxr.us=0D=0A> > Subject: RE: [Geopriv] Geopriv L7= LCP: New Requirement=0D=0A> >=0D=0A> > Using civic for routing may work in= the US where the MSAG is part of the=0D=0A> > legacy infrastructure. In ot= her jurisdictions that I have spoken with,=0D=0A> > they would hate to have= to develop this just for routing calls. As such=0D=0A> a=0D=0A> > nominal = geo associated with fixed wireline access points is also a=0D=0A> > require= ment. Hence the need to be able to get both forms if possible.=0D=0A> >=0D=0A= > > There is plenty of demand for a response time parameter and it is in th= e=0D=0A> > NENA requirements. It has a very valid application in doing loca= tion=0D=0A> > technology arbitration in wireless location measurement - it = is used=0D=0A> > already in 2G and 3G location determination. There is noth= ing in IP=0D=0A> > Location that removes this requirement - your opinion no= t withstanding=0D=0A> > being valid as your opinion.=0D=0A> >=0D=0A> > Chee= rs,=0D=0A> > Martin=0D=0A> >=0D=0A> > -----Original Message-----=0D=0A> > F= rom: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> > Sent: Su= nday, 11 March 2007 7:00 AM=0D=0A> > To: jerome.grenier@bell.ca=0D=0A> > Cc= : geopriv@ietf.org; Barbara.Stark@BellSouth.com; lendl@nic.at;=0D=0A> > and= y@hxr.us=0D=0A> > Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement=0D= =0A> >=0D=0A> > Hi Jerome,=0D=0A> >=0D=0A> > jerome.grenier@bell.ca wrote:=0D= =0A> > > I agree with Barbara and would also add :=0D=0A> > >=0D=0A> > > - = ability to request geo and/or civic location=0D=0A> > >=0D=0A> >=0D=0A> > B= arbara previously said that geo-location does not make sense in the DSL=0D=0A= > > environment.=0D=0A> > I guess you are pointing to a different environme= nt. The question is=0D=0A> > only: Is the LIS-to-LIS communication needed t= here as well=3F=0D=0A> >=0D=0A> > > The "ability to specify how quickly a r= esponse is needed" would also=0D=0A> be=0D=0A> > really helpful to us.=0D=0A= > > >=0D=0A> > I don't think that this is useful for this particular applic= ation.=0D=0A> >=0D=0A> > > Having a BCP (one or more) that recommends a syn= tax to express various=0D=0A> > identifier types for common protocols like = SIP/PRES and HTTP would be=0D=0A> > great!=0D=0A> > >=0D=0A> > >=0D=0A> > C= iao=0D=0A> > Hanes=0D=0A> >=0D=0A> > > J=E9r=F4me=0D=0A> > >=0D=0A> > > ---= --Message d'origine-----=0D=0A> > > De : Stark, Barbara [mailto:Barbara.Sta= rk@BellSouth.com]=0D=0A> > > Envoy=E9 : 16 f=E9vrier 2007 10:05=0D=0A> > > = =C0 : Andrew Newton=0D=0A> > > Cc : geopriv@ietf.org; Otmar Lendl=0D=0A> > = > Objet : RE: [Geopriv] Geopriv L7 LCP: New Requirement=0D=0A> > >=0D=0A> >= > I hate to break ranks, but if we could get the user part figured out=0D=0A= > > > (and I do think we would need some standardization, even if it's just=0D= =0A> a=0D=0A> > > BCP), I kind of like this proposed solution. It has a cer= tain=0D=0A> simplicity=0D=0A> > > to it.=0D=0A> > >=0D=0A> > > Since we've = been pushing for these LISs to support LbyR, anyway, and=0D=0A> > > this is= really just LbyR, I don't see it as being a different=0D=0A> protocol,=0D=0A= > > > yet again. This is a protocol we'd expect to be supported by a LIS in=0D= =0A> > > any case. The only change is that the URI may require careful pars= ing=0D=0A> by=0D=0A> > > the queried LIS, and the querier LIS needs to supp= ort LbyR queries in=0D=0A> > > both directions.=0D=0A> > >=0D=0A> > > When = I look at the functions in HELD (and RELO has a subset of these),=0D=0A> > = > and think through which of those functions would I really need for=0D=0A>= > > LIS-LIS or OBO, I come up with:=0D=0A> > > - ability to request refere= nce -- not needed, since, as pointed out,=0D=0A> > > I've already got a per= fectly good non-expiring reference; OBO querier=0D=0A> or=0D=0A> > > LIS do= esn't need to ask for references to hand off to others, it=0D=0A> should=0D= =0A> > > create its own references for that, as appropriate [aside: a=0D=0A= > > > non-expiring reference and a "LCP" are rather equal in the privacy=0D= =0A> > > debate from the OBO/LIS-LIS perspective.]=0D=0A> > > - ability to = assert location -- not needed for OBO or LIS-LIS; only an=0D=0A> > > end de= vice should be able to do this, if even that is allowed=0D=0A> > > - abilit= y to provide rules/profile for privacy -- not needed for OBO=0D=0A> or=0D=0A= > > > LIS-LIS; only the device should be able to do this=0D=0A> > > - abili= ty to sign location -- if this is part of PIDF-LO, then this is=0D=0A> > > = independent of request mechanism=0D=0A> > > - ability to request that locat= ion be signed -- I think we can assume=0D=0A> > > that the location should = be signed if it can be signed=0D=0A> > > - ability to specify how quickly a= response is needed -- this would be=0D=0A> > > useful, but it may be possi= ble to design around the issue=0D=0A> > > - have I missed anything=3F=0D=0A= > > >=0D=0A> > > Supporting URI formats other than SIP (e.g., HTTP) would s= till need to=0D=0A> > > be worked. But that format would be common to all L= byR usages.=0D=0A> > > This in no way removes the requirement for a device-= to-LIS "LCP". I=0D=0A> > > haven't read that into the suggestion at all.=0D= =0A> > >=0D=0A> > > So, I think this idea warrants consideration.=0D=0A> > = > Barbara=0D=0A> > >=0D=0A> > > -----Original Message-----=0D=0A> > > From:= Andrew Newton [mailto:andy@hxr.us]=0D=0A> > > Sent: Thursday, February 15,= 2007 3:51 PM=0D=0A> > > To: Stark, Barbara=0D=0A> > > Cc: geopriv@ietf.org= ; Otmar Lendl=0D=0A> > > Subject: Re: [Geopriv] Geopriv L7 LCP: New Require= ment=0D=0A> > >=0D=0A> > >=0D=0A> > > On Feb 15, 2007, at 12:50 PM, Stark, = Barbara wrote:=0D=0A> > >=0D=0A> > >=0D=0A> > >> What is difficult, is figu= ring out a standard format for a URI user=0D=0A> > >> part that would allow= for all the variations in combinations of IDs=0D=0A> > >> that exist, so t= hat a standard format could be defined that would=0D=0A> > >> cover all int= erconnection models. Section 8 of the NENA Location TID=0D=0A> > >> (http:/= /www.nena.org/media/files/08-505_20061221.pdf) provides 5=0D=0A> > >> diffe= rent examples of interconnection models, and the IDs that would=0D=0A> > >>= need to be used in each of these cases. In this document, scenario 1=0D=0A= > > >> uses the IP address, scenario 2 uses NAS-ID and ATM PVC, scenario 3=0D= =0A> > >> uses=0D=0A> > >> 2 VLAN tags, scenario 4 uses IP address, and sce= nario 5 uses L2TP=0D=0A> > >> tunnel ID (source and destination) and PPPoE = session ID. These are=0D=0A> > >> just 5 possible examples, and should not = be considered exhaustive.=0D=0A> > >> Interconnection models are still evol= ving.=0D=0A> > >>=0D=0A> > >=0D=0A> > > Well, that's easily solved with a B= CP for formulating URIs based on=0D=0A> the=0D=0A> > > ID. You don't need = a new protocol or to conflate the LCP protocol=0D=0A> with=0D=0A> > > this = functionality.=0D=0A> > >=0D=0A> > > -andy=0D=0A> > >=0D=0A> > > *****=0D=0A= > > >=0D=0A> > > The information transmitted is intended only for the perso= n or entity=0D=0A> to=0D=0A> > which it is addressed and may contain confid= ential, proprietary, and/or=0D=0A> > privileged material. Any review, retra= nsmission, dissemination or other=0D=0A> > use of, or taking of any action = in reliance upon this information by=0D=0A> > persons or entities other tha= n the intended recipient is prohibited. If=0D=0A> > you received this in er= ror, please contact the sender and delete the=0D=0A> > material from all co= mputers. GA621=0D=0A> > >=0D=0A> > >=0D=0A> > >=0D=0A> > > ________________= _______________________________=0D=0A> > > Geopriv mailing list=0D=0A> > > = Geopriv@ietf.org=0D=0A> > > https://www1.ietf.org/mailman/listinfo/geopriv=0D= =0A> > >=0D=0A> > > _______________________________________________=0D=0A> = > > Geopriv mailing list=0D=0A> > > Geopriv@ietf.org=0D=0A> > > https://www= 1.ietf.org/mailman/listinfo/geopriv=0D=0A> > >=0D=0A> > >=0D=0A> >=0D=0A> >=0D= =0A> > _______________________________________________=0D=0A> > Geopriv mai= ling list=0D=0A> > Geopriv@ietf.org=0D=0A> > https://www1.ietf.org/mailman/= listinfo/geopriv=0D=0A> >=0D=0A> > ----------------------------------------= --------------------------------=0D=0A> --=0D=0A> > ----------------------=0D= =0A> > This message is for the designated recipient only and may=0D=0A> > c= ontain privileged, proprietary, or otherwise private information.=0D=0A> > = If you have received it in error, please notify the sender=0D=0A> > immedia= tely and delete the original. Any unauthorized use of=0D=0A> > this email = is prohibited.=0D=0A> > ---------------------------------------------------= ---------------------=0D=0A> --=0D=0A> > ----------------------=0D=0A> > [m= f2]=0D=0A> >=0D=0A> >=0D=0A> > ____________________________________________= ___=0D=0A> > Geopriv mailing list=0D=0A> > Geopriv@ietf.org=0D=0A> > https:= //www1.ietf.org/mailman/listinfo/geopriv=0D=0A>=20=0D=0A>=20=0D=0A> _______= ________________________________________=0D=0A> Geopriv mailing list=0D=0A>= Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sun Mar 11 18:52: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 1HQWto-0002Xx-FS; Sun, 11 Mar 2007 18:52:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQWtm-0002Xm-Og for geopriv@ietf.org; Sun, 11 Mar 2007 18:52:18 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HQWtl-00054R-Bo for geopriv@ietf.org; Sun, 11 Mar 2007 18:52:18 -0400 X-SEF-Processed: 5_0_0_910__2007_03_11_17_58_06 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, 11 Mar 2007 17:58:06 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Mar 2007 17:52:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] Where we are / are we with L7-LCP Date: Sun, 11 Mar 2007 17:52:09 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Where we are / are we with L7-LCP Thread-Index: AcdiuJcIkzxKMgzmTx6XvKin/a1wxgAE0/RwAFjvdWA= From: "Thomson, Martin" To: "Dawson, Martin" , "Henning Schulzrinne" X-OriginalArrivalTime: 11 Mar 2007 22:52:10.0784 (UTC) FILETIME=[E7296A00:01C7642F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Ted Hardie , GEOPRIV WG , Andrew Newton X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1914803988==" Errors-To: geopriv-bounces@ietf.org --===============1914803988== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHRoYXQgdXNpbmcgdGhlIGVudGl0eSBhdHRyaWJ1dGUgaGFzIGFscmVhZHkgYmVl biBwcm9wb3NlZC4NCg0KSGVubmluZywgd2hpY2ggb2YgdGhlIHBsZXRob3JhIG9mIFBJREYgc3Rh bmRhcmRzIGNvbnRhaW5zICJleHBpcmVzIj8gIDM4NjMgaGFzIGEgdGltZXN0YW1wLCBidXQgbm90 aGluZyBvZiB0aGUgImV4cGlyZXMiIG5hdHVyZS4NCg0KTQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IERhd3NvbiwgTWFydGluIFttYWlsdG86TWFydGluLkRhd3NvbkBh bmRyZXcuY29tXQ0KPiBTZW50OiBTYXR1cmRheSwgMTAgTWFyY2ggMjAwNyAzOjMwIFBNDQo+IFRv OiBIZW5uaW5nIFNjaHVsenJpbm5lDQo+IENjOiBUZWQgSGFyZGllOyBHRU9QUklWIFdHOyBBbmRy ZXcgTmV3dG9uDQo+IFN1YmplY3Q6IFJFOiBbR2VvcHJpdl0gV2hlcmUgd2UgYXJlIC8gYXJlIHdl IHdpdGggTDctTENQDQo+IA0KPiBUaGUgb3Bwb3NpdGUgLSBJJ20gY29uY2VybmVkIGFib3V0IGp1 c3Qgb25lIGRldmljZSBtYWtpbmcgbG90cyBvZiBjYWxscw0KPiB1c2luZyBkaWZmZXJlbnQgQ0xJ cyBhbmQgVm9JUCBzZXJ2aWNlIGlkZW50aXRpZXMuIFRoZSBMSVMgaXMgY2FwYWJsZSBvZg0KPiBt YXJraW5nIHRoZSBsb2NhdGlvbiBvYmplY3RzIGFzIGJlaW5nIGFzc29jaWF0ZWQgd2l0aCB0aGUg c2FtZSBwaHlzaWNhbA0KPiBkZXZpY2UgcmVnYXJkbGVzcyBvZiBob3cgdGhleSBhcHBlYXIgYXMg cGhvbmUgY2FsbHMuIEkgaGF2ZSBubyBwcm9ibGVtDQo+IHdpdGggdXNpbmcgYW4gZXhpc3Rpbmcg aW5mb3JtYXRpb24gZWxlbWVudCBhcyBsb25nIGFzIHRoaXMgdXNlIGlzbid0DQo+IGNvbnRyYXJ5 IHRvIHdoYXQgdGhhdCBpbmZvcm1hdGlvbiBlbGVtZW50IGlzIGludGVuZGVkIGZvci4NCj4gDQo+ IEknbSBub3Qgc28gc3VyZSBhYm91dCAiZXhwaXJlcyIuIEkgd291bGQgcHJlZmVyIHRvIHNlZSB0 aGUgdGltZSBhdCB3aGljaA0KPiB0aGUgbG9jYXRpb24gd2FzIGFjdHVhbGx5IGFzc29jaWF0ZWQg d2l0aCB0aGUgZGV2aWNlIGFuZCBsZXQgdGhlDQo+IHJlY2lwaWVudCBhcHBseSB0aGVpciBvd24g cG9saWN5IGFib3V0IHdoYXQgY29uc3RpdHV0ZXMgZXhwaXJ5LiBEb2VzIHRoZQ0KPiBwcm9maWxl IGhhdmUgdGhhdC4NCj4gDQo+IENoZWVycywNCj4gTWFydGluDQo+IA0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBIZW5uaW5nIFNjaHVsenJpbm5lIFttYWlsdG86aGdzQGNz LmNvbHVtYmlhLmVkdV0NCj4gU2VudDogU2F0dXJkYXksIDEwIE1hcmNoIDIwMDcgMTowNSBQTQ0K PiBUbzogRGF3c29uLCBNYXJ0aW4NCj4gQ2M6IFRlZCBIYXJkaWU7IEFuZHJldyBOZXd0b247IEdF T1BSSVYgV0cNCj4gU3ViamVjdDogUmU6IFtHZW9wcml2XSBXaGVyZSB3ZSBhcmUgLyBhcmUgd2Ug d2l0aCBMNy1MQ1ANCj4gDQo+ID4NCj4gPiBDbGllbnQgZGV2aWNlIGlkZW50aXR5IC0gV2UndmUg aGFkIHRoaXMgZGlzY3Vzc2lvbiBzZXZlcmFsIHRpbWVzDQo+ID4gYWxyZWFkeQ0KPiA+IG9uIHRo aXMgbGlzdC4gSSBhbSBub3QgcmVmZXJyaW5nIHRvIHRoZSB1c2VyIGlkZW50aXR5OyBJIGFtIG5v dA0KPiA+IHJlZmVycmluZyB0byBhIFZvSVAgY2xpZW50IGlkZW50aXR5LiBJIGFtIHJlZmVycmlu ZyB0byB0aGUgcHJlc2VuY2Ugb2YNCj4gPiB0aGUgZGV2aWNlIG9uIHRoZSBhY2Nlc3MgbmV0d29y ayBhbmQgdGhlIGZhY3QgdGhhdCwgYXBhcnQgZnJvbSB3b3JraW5nDQo+ID4gb3V0IGl0cyBsb2Nh dGlvbiwgdGhlIExJUyBjYW4gYXR0cmlidXRlIGEgc2luZ2xlIGlkZW50aXR5IHRvIHRoZQ0KPiA+ IHRhcmdldA0KPiA+IGl0IGlzIGNhbGN1bGF0aW5nIGxvY2F0aW9uIGZvci4gVGhpcyBpcyBhbiBh bm9ueW1vdXMgaWRlbnRpdHkgLSBpdCBpcw0KPiA+ICJpZGVudGl0eSIgaW4gaXRzIHRydWVzdCBh YnN0cmFjdCBzZW5zZSAtIHVuaXF1ZW5lc3MuDQo+IA0KPiBVbmxlc3MgeW91IGFyZSB3b3JyaWVk IGFib3V0IGxvdHMgb2YgZGV2aWNlcyBhdCBvbmUgcGh5c2ljYWwgYWRkcmVzcw0KPiAod2hpY2gg YXJlIGxpa2VseSBiZWhpbmQgb25lIE5BVCksIEkgZG9uJ3Qgc2VlIGhvdyB0aGlzIGFkZHMNCj4g c2lnbmlmaWNhbnQgdmFsdWUuDQo+IA0KPiBBbHNvLCB0aGUgUElERi1MTyBhbHJlYWR5IGNvbnRh aW5zIHN1Y2ggYW4gaWRlbnRpdHkgKGVudGl0eSksIGlmIHlvdQ0KPiByZWFsbHkgd2FudCBpdC4N Cj4gDQo+IFNpbWlsYXJseSwgdGhlIHZhbGlkaXR5IHBlcmlvZHMgaXMgYWxzbyBhbHJlYWR5IGlu IFBJREYgKGV4cGlyZXMpLg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiBUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVu dCBvbmx5IGFuZCBtYXkNCj4gY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3Ro ZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uDQo+IElmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCj4gaW1tZWRpYXRlbHkgYW5kIGRlbGV0 ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KPiB0aGlzIGVtYWlsIGlz IHByb2hpYml0ZWQuDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gW21mMl0NCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBHZW9wcml2IG1haWxpbmcgbGlzdA0KPiBHZW9wcml2QGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dlb3ByaXYNCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9y IHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdl ZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5 b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQpp bW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNl IG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClttZjJdDQo= --===============1914803988== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1914803988==-- From geopriv-bounces@ietf.org Sun Mar 11 19:03:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQX4F-0008CA-3K; Sun, 11 Mar 2007 19:03:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQX4C-00086W-2s for geopriv@ietf.org; Sun, 11 Mar 2007 19:03:05 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQX47-0006re-FB for geopriv@ietf.org; Sun, 11 Mar 2007 19:03:04 -0400 X-SEF-Processed: 5_0_0_910__2007_03_11_18_08_54 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, 11 Mar 2007 18:08:54 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Mar 2007 18:02:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement Date: Sun, 11 Mar 2007 18:02:56 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Geopriv L7 LCP: New Requirement Thread-Index: AcdjTsOILWsAysT6RM6RD5gOOmmjpwAO0woQACSEByAAA31kIAABjtrQ From: "Thomson, Martin" To: "Winterbottom, James" , "Brian Rosen" , "Dawson, Martin" , "Hannes Tschofenig" , X-OriginalArrivalTime: 11 Mar 2007 23:02:58.0156 (UTC) FILETIME=[69068AC0:01C76431] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: geopriv@ietf.org, Barbara.Stark@BellSouth.com, lendl@nic.at, andy@hxr.us X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0376878094==" Errors-To: geopriv-bounces@ietf.org --===============0376878094== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHByb2JsZW0gd2l0aCB0aGUgY29uY2VwdCBvZiBjbGFzc2VzIG9mIHNlcnZpY2UgaXMgdGhh dCB0aGV5IHJlcXVpcmUgY29udmVudGlvbnMgdG8gZGVmaW5lIGV4cGVjdGF0aW9ucy4NCg0KM0dQ UCAoYW5kIHJlbGF0ZWQpIHVzZSB0d28gY2F0ZWdvcmllczogIkxvdyBEZWxheSIgYW5kICJEZWxh eSBUb2xlcmFudCIuICBUaGVzZSB3b3VsZCBtYXRjaCB3aGF0IEJyaWFuIGhhcyBhc2tlZCBmb3Iu ICBJbiBwcmFjdGljZSwgdGhlc2UgY2xhc3NlcyBuZWVkIHRvIGJlIGRlZmluZWQsIHdpdGggcmVh c29uYWJsZSB0aW1lIGxpbWl0cyBhbmQgc28gZm9ydGguICBObyBwb2ludCBhc2tpbmcgZm9yICJM b3cgRGVsYXkiIGlmIHlvdXIgZGVmaW5pdGlvbiBpcyAxIHNlY29uZCBhbmQgdGhlIHNlcnZpbmcg bm9kZSB0aGlua3MgMyBzZWNvbmRzIGlzIE9LLiAgVGhlc2UgY2FuIGJlIGNvbnRyb2xsZWQgaW4g YSBjbG9zZWQgbmV0d29yayAtIHRoZSB2YWx1ZXMgY29tbXVuaWNhdGVkIGJldHdlZW4gYWxsIHJl c3BlY3RpdmUgbm9kZXMuICBIYXZpbmcgYSBudW1iZXIgaXMgc2ltcGxlIGFuZCB1bmFtYmlndW91 cy4NCg0KVGEsDQpNYXJ0aW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBXaW50ZXJib3R0b20sIEphbWVzIFttYWlsdG86SmFtZXMuV2ludGVyYm90dG9tQGFuZHJldy5j b21dDQo+IFNlbnQ6IE1vbmRheSwgMTIgTWFyY2ggMjAwNyA5OjE3IEFNDQo+IFRvOiBCcmlhbiBS b3NlbjsgRGF3c29uLCBNYXJ0aW47IEhhbm5lcyBUc2Nob2ZlbmlnOyBqZXJvbWUuZ3JlbmllckBi ZWxsLmNhDQo+IENjOiBnZW9wcml2QGlldGYub3JnOyBCYXJiYXJhLlN0YXJrQEJlbGxTb3V0aC5j b207IGxlbmRsQG5pYy5hdDsNCj4gYW5keUBoeHIudXMNCj4gU3ViamVjdDogUkU6IFtHZW9wcml2 XSBHZW9wcml2IEw3IExDUDogTmV3IFJlcXVpcmVtZW50DQo+IA0KPiBJIGhhdmUgdG8gZGlzYWdy ZWUgd2l0aCB5b3Ugb24gYWxtb3N0IGFsbCBjb3VudHMgYmVsb3cgQnJpYW4sIGV4Y2VwdA0KPiBw b3NzaWJseSB3aXRoIG1vcmUgYWNjdXJhdGUgcmVzdWx0cyBhcmUgY29taW5nIG1vcmUgcXVpY2ts eS4NCj4gDQo+IEpTVEQtMDM2QiBoYXMgc3BlY2lmaWNhbGx5IG1vdmUgYXdheSBmcm9tIHRoZSBp bW1lZGlhdGUgcmVxdWVzdCBzY2VuYXJpbw0KPiBmb3Igcm91dGluZyB0byBhIGxvdy1kZWxheSBv bmUsIGFzIGltbWVkaWF0ZSB3aWxsIGdpdmUgeW91IGNlbGwgb25seQ0KPiByb3V0aW5nLCBhbmQg bG93LWRlbGF5IHdpbGwgZ2l2ZSB5b3UgYSB0aW1pbmcgYWR2YW5jZSBzb2x1dGlvbiB3aGljaA0K PiBzdWJzdGFudGlhbGx5IGltcHJvdmVzIGFjY3VyYWN5LCBhbmQgaGVuY2UgcmVkdWNlcyBtaXNy b3V0ZXMuDQo+IA0KPiBZb3VyIGxhc3QgY29tbWVudCBJIHRoaW5rIGdldHMgdG8gdGhlIGNydXgg b2YgdGhlIG1hdHRlci4gWW91IGFyZSB0aGlua2luZw0KPiBhIHdpcmVsaW5lIHNvbHV0aW9uIG9u bHkgZm9yIHRoZSBMNyBwcm90b2NvbCwgSSBhbSBub3QuIEkgdGhpbmsgdGhhdCB3aGF0DQo+IHdl IHdhbnQsIGFuZCB3aGF0IHdlIGFyZSB0cnlpbmcgdG8gY29tZSB1cCB3aXRoIHJlcXVpcmVtZW50 cyBmb3IsIGlzIGFuDQo+IGFjcXVpc2l0aW9uIHByb3RvY29sIGNvdmVycyBhbGwgYWNjZXNzIG5l dHdvcmtzLiBTbyBwcmVjbHVkaW5nIHdpcmVsZXNzIGlzDQo+IGEgdmVyeSBzaWduaWZpY2FudCBl eGNsdXNpb24uDQo+IA0KPiBDaGVlcnMNCj4gSmFtZXMNCj4gDQo+IA0KPiANCj4gPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEJyaWFuIFJvc2VuIFttYWlsdG86YnJAYnJp YW5yb3Nlbi5uZXRdDQo+ID4gU2VudDogTW9uZGF5LCAxMiBNYXJjaCAyMDA3IDc6MzUgQU0NCj4g PiBUbzogRGF3c29uLCBNYXJ0aW47ICdIYW5uZXMgVHNjaG9mZW5pZyc7IGplcm9tZS5ncmVuaWVy QGJlbGwuY2ENCj4gPiBDYzogZ2VvcHJpdkBpZXRmLm9yZzsgQmFyYmFyYS5TdGFya0BCZWxsU291 dGguY29tOyBsZW5kbEBuaWMuYXQ7DQo+ID4gYW5keUBoeHIudXMNCj4gPiBTdWJqZWN0OiBSRTog W0dlb3ByaXZdIEdlb3ByaXYgTDcgTENQOiBOZXcgUmVxdWlyZW1lbnQNCj4gPg0KPiA+IElzIHRo ZXJlIHJlYWxseSBhIHVzZSBmb3IgbW9yZSByZXNwb25zZSB0aW1lIHJlcXVlc3RzIHRoYXQgImlt bWVkaWF0ZSINCj4gYW5kDQo+ID4gImV2ZW50dWFsbHkiPyAgSSBjZXJ0YWlubHkgZG9uJ3Qgc2Vl IGFueSB1c2UgZm9yIG1vcmUgdGhhbiB0aG9zZSB0d28gaW4NCj4gPiB0aGUNCj4gPiBlbWVyZ2Vu Y3kgY2FzZSAocmVjb2duaXppbmcgdGhhdCBjdXJyZW50IHN5c3RlbXMgZG9uJ3QgaGF2ZSBhbnkg c3VjaA0KPiA+IG9wdGlvbnMpLiAgSSBjYW4gc2VlICJpbW1lZGlhdGUiIGFzIG5lZWRlZCBmb3Ig Y2FsbCByb3V0aW5nLCB3aGlsZQ0KPiA+ICJldmVudHVhbGx5IiBpcyB0aGUgImdldCBtZSBhbiBh Y2N1cmF0ZSBmaXgiIHRoYXQgeW91IHVzZSB0byBzZW5kDQo+ID4gcmVzcG9uZGVycy4gIEkgZG9u J3Qgc2VlIHdoeSBhbnlvbmUgd291bGQgbmVlZCBtb3JlIHRoYW4gdGhhdCwgYW5kIEkNCj4gdGhp bmsNCj4gPiB0aGUgZGlyZWN0aW9uIG9mIHRoZSB0ZWNobm9sb2d5IGlzIHRvIG1vdmluZyB0b3dh cmRzIGZhc3RlciBhY2N1cmF0ZQ0KPiA+IGZpeGVzLA0KPiA+IHNvIHRoZSBuZWVkIHRvIGhhdmUg aW50ZXJtZWRpYXRlIHN0YXRlcyBpcyBjbGVhcmx5IGdvaW5nIHRvIGdvIGRvd24gb3Zlcg0KPiA+ IHRpbWUuDQo+ID4NCj4gPiBJIGFsc28gdGhpbmsgdGhpcyBpcyBhbm90aGVyIGNhc2Ugd2hlcmUg dGhlIHJlcXVpcmVtZW50IGRvZXNuJ3QgaGF2ZQ0KPiA+IGFueXRoaW5nIHRvIGRvIHdpdGggTDcs IGFsdGhvdWdoIGl0IGRvZXMgc2VlbSB0byBoYXZlIHRvIGRvIHdpdGggbW9iaWxlDQo+ID4gZGV2 aWNlcy4NCj4gPg0KPiA+IEJyaWFuDQo+ID4NCj4gPg0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogRGF3c29uLCBNYXJ0aW4gW21haWx0bzpNYXJ0aW4u RGF3c29uQGFuZHJldy5jb21dDQo+ID4gPiBTZW50OiBTYXR1cmRheSwgTWFyY2ggMTAsIDIwMDcg MTA6MDkgUE0NCj4gPiA+IFRvOiBIYW5uZXMgVHNjaG9mZW5pZzsgamVyb21lLmdyZW5pZXJAYmVs bC5jYQ0KPiA+ID4gQ2M6IGdlb3ByaXZAaWV0Zi5vcmc7IEJhcmJhcmEuU3RhcmtAQmVsbFNvdXRo LmNvbTsgbGVuZGxAbmljLmF0Ow0KPiA+ID4gYW5keUBoeHIudXMNCj4gPiA+IFN1YmplY3Q6IFJF OiBbR2VvcHJpdl0gR2VvcHJpdiBMNyBMQ1A6IE5ldyBSZXF1aXJlbWVudA0KPiA+ID4NCj4gPiA+ IFVzaW5nIGNpdmljIGZvciByb3V0aW5nIG1heSB3b3JrIGluIHRoZSBVUyB3aGVyZSB0aGUgTVNB RyBpcyBwYXJ0IG9mDQo+IHRoZQ0KPiA+ID4gbGVnYWN5IGluZnJhc3RydWN0dXJlLiBJbiBvdGhl ciBqdXJpc2RpY3Rpb25zIHRoYXQgSSBoYXZlIHNwb2tlbiB3aXRoLA0KPiA+ID4gdGhleSB3b3Vs ZCBoYXRlIHRvIGhhdmUgdG8gZGV2ZWxvcCB0aGlzIGp1c3QgZm9yIHJvdXRpbmcgY2FsbHMuIEFz DQo+IHN1Y2gNCj4gPiBhDQo+ID4gPiBub21pbmFsIGdlbyBhc3NvY2lhdGVkIHdpdGggZml4ZWQg d2lyZWxpbmUgYWNjZXNzIHBvaW50cyBpcyBhbHNvIGENCj4gPiA+IHJlcXVpcmVtZW50LiBIZW5j ZSB0aGUgbmVlZCB0byBiZSBhYmxlIHRvIGdldCBib3RoIGZvcm1zIGlmIHBvc3NpYmxlLg0KPiA+ ID4NCj4gPiA+IFRoZXJlIGlzIHBsZW50eSBvZiBkZW1hbmQgZm9yIGEgcmVzcG9uc2UgdGltZSBw YXJhbWV0ZXIgYW5kIGl0IGlzIGluDQo+IHRoZQ0KPiA+ID4gTkVOQSByZXF1aXJlbWVudHMuIEl0 IGhhcyBhIHZlcnkgdmFsaWQgYXBwbGljYXRpb24gaW4gZG9pbmcgbG9jYXRpb24NCj4gPiA+IHRl Y2hub2xvZ3kgYXJiaXRyYXRpb24gaW4gd2lyZWxlc3MgbG9jYXRpb24gbWVhc3VyZW1lbnQgLSBp dCBpcyB1c2VkDQo+ID4gPiBhbHJlYWR5IGluIDJHIGFuZCAzRyBsb2NhdGlvbiBkZXRlcm1pbmF0 aW9uLiBUaGVyZSBpcyBub3RoaW5nIGluIElQDQo+ID4gPiBMb2NhdGlvbiB0aGF0IHJlbW92ZXMg dGhpcyByZXF1aXJlbWVudCAtIHlvdXIgb3BpbmlvbiBub3Qgd2l0aHN0YW5kaW5nDQo+ID4gPiBi ZWluZyB2YWxpZCBhcyB5b3VyIG9waW5pb24uDQo+ID4gPg0KPiA+ID4gQ2hlZXJzLA0KPiA+ID4g TWFydGluDQo+ID4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZy b206IEhhbm5lcyBUc2Nob2ZlbmlnIFttYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldF0N Cj4gPiA+IFNlbnQ6IFN1bmRheSwgMTEgTWFyY2ggMjAwNyA3OjAwIEFNDQo+ID4gPiBUbzogamVy b21lLmdyZW5pZXJAYmVsbC5jYQ0KPiA+ID4gQ2M6IGdlb3ByaXZAaWV0Zi5vcmc7IEJhcmJhcmEu U3RhcmtAQmVsbFNvdXRoLmNvbTsgbGVuZGxAbmljLmF0Ow0KPiA+ID4gYW5keUBoeHIudXMNCj4g PiA+IFN1YmplY3Q6IFJlOiBbR2VvcHJpdl0gR2VvcHJpdiBMNyBMQ1A6IE5ldyBSZXF1aXJlbWVu dA0KPiA+ID4NCj4gPiA+IEhpIEplcm9tZSwNCj4gPiA+DQo+ID4gPiBqZXJvbWUuZ3JlbmllckBi ZWxsLmNhIHdyb3RlOg0KPiA+ID4gPiBJIGFncmVlIHdpdGggQmFyYmFyYSBhbmQgd291bGQgYWxz byBhZGQgOg0KPiA+ID4gPg0KPiA+ID4gPiAtIGFiaWxpdHkgdG8gcmVxdWVzdCBnZW8gYW5kL29y IGNpdmljIGxvY2F0aW9uDQo+ID4gPiA+DQo+ID4gPg0KPiA+ID4gQmFyYmFyYSBwcmV2aW91c2x5 IHNhaWQgdGhhdCBnZW8tbG9jYXRpb24gZG9lcyBub3QgbWFrZSBzZW5zZSBpbiB0aGUNCj4gRFNM DQo+ID4gPiBlbnZpcm9ubWVudC4NCj4gPiA+IEkgZ3Vlc3MgeW91IGFyZSBwb2ludGluZyB0byBh IGRpZmZlcmVudCBlbnZpcm9ubWVudC4gVGhlIHF1ZXN0aW9uIGlzDQo+ID4gPiBvbmx5OiBJcyB0 aGUgTElTLXRvLUxJUyBjb21tdW5pY2F0aW9uIG5lZWRlZCB0aGVyZSBhcyB3ZWxsPw0KPiA+ID4N Cj4gPiA+ID4gVGhlICJhYmlsaXR5IHRvIHNwZWNpZnkgaG93IHF1aWNrbHkgYSByZXNwb25zZSBp cyBuZWVkZWQiIHdvdWxkIGFsc28NCj4gPiBiZQ0KPiA+ID4gcmVhbGx5IGhlbHBmdWwgdG8gdXMu DQo+ID4gPiA+DQo+ID4gPiBJIGRvbid0IHRoaW5rIHRoYXQgdGhpcyBpcyB1c2VmdWwgZm9yIHRo aXMgcGFydGljdWxhciBhcHBsaWNhdGlvbi4NCj4gPiA+DQo+ID4gPiA+IEhhdmluZyBhIEJDUCAo b25lIG9yIG1vcmUpIHRoYXQgcmVjb21tZW5kcyBhIHN5bnRheCB0byBleHByZXNzDQo+IHZhcmlv dXMNCj4gPiA+IGlkZW50aWZpZXIgdHlwZXMgZm9yIGNvbW1vbiBwcm90b2NvbHMgbGlrZSBTSVAv UFJFUyBhbmQgSFRUUCB3b3VsZCBiZQ0KPiA+ID4gZ3JlYXQhDQo+ID4gPiA+DQo+ID4gPiA+DQo+ ID4gPiBDaWFvDQo+ID4gPiBIYW5lcw0KPiA+ID4NCj4gPiA+ID4gSsOpcsO0bWUNCj4gPiA+ID4N Cj4gPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gPiA+IERlIDogU3Rhcmss IEJhcmJhcmEgW21haWx0bzpCYXJiYXJhLlN0YXJrQEJlbGxTb3V0aC5jb21dDQo+ID4gPiA+IEVu dm95w6kgOiAxNiBmw6l2cmllciAyMDA3IDEwOjA1DQo+ID4gPiA+IMOAIDogQW5kcmV3IE5ld3Rv bg0KPiA+ID4gPiBDYyA6IGdlb3ByaXZAaWV0Zi5vcmc7IE90bWFyIExlbmRsDQo+ID4gPiA+IE9i amV0IDogUkU6IFtHZW9wcml2XSBHZW9wcml2IEw3IExDUDogTmV3IFJlcXVpcmVtZW50DQo+ID4g PiA+DQo+ID4gPiA+IEkgaGF0ZSB0byBicmVhayByYW5rcywgYnV0IGlmIHdlIGNvdWxkIGdldCB0 aGUgdXNlciBwYXJ0IGZpZ3VyZWQgb3V0DQo+ID4gPiA+IChhbmQgSSBkbyB0aGluayB3ZSB3b3Vs ZCBuZWVkIHNvbWUgc3RhbmRhcmRpemF0aW9uLCBldmVuIGlmIGl0J3MNCj4ganVzdA0KPiA+IGEN Cj4gPiA+ID4gQkNQKSwgSSBraW5kIG9mIGxpa2UgdGhpcyBwcm9wb3NlZCBzb2x1dGlvbi4gSXQg aGFzIGEgY2VydGFpbg0KPiA+IHNpbXBsaWNpdHkNCj4gPiA+ID4gdG8gaXQuDQo+ID4gPiA+DQo+ ID4gPiA+IFNpbmNlIHdlJ3ZlIGJlZW4gcHVzaGluZyBmb3IgdGhlc2UgTElTcyB0byBzdXBwb3J0 IExieVIsIGFueXdheSwgYW5kDQo+ID4gPiA+IHRoaXMgaXMgcmVhbGx5IGp1c3QgTGJ5UiwgSSBk b24ndCBzZWUgaXQgYXMgYmVpbmcgYSBkaWZmZXJlbnQNCj4gPiBwcm90b2NvbCwNCj4gPiA+ID4g eWV0IGFnYWluLiBUaGlzIGlzIGEgcHJvdG9jb2wgd2UnZCBleHBlY3QgdG8gYmUgc3VwcG9ydGVk IGJ5IGEgTElTDQo+IGluDQo+ID4gPiA+IGFueSBjYXNlLiBUaGUgb25seSBjaGFuZ2UgaXMgdGhh dCB0aGUgVVJJIG1heSByZXF1aXJlIGNhcmVmdWwNCj4gcGFyc2luZw0KPiA+IGJ5DQo+ID4gPiA+ IHRoZSBxdWVyaWVkIExJUywgYW5kIHRoZSBxdWVyaWVyIExJUyBuZWVkcyB0byBzdXBwb3J0IExi eVIgcXVlcmllcw0KPiBpbg0KPiA+ID4gPiBib3RoIGRpcmVjdGlvbnMuDQo+ID4gPiA+DQo+ID4g PiA+IFdoZW4gSSBsb29rIGF0IHRoZSBmdW5jdGlvbnMgaW4gSEVMRCAoYW5kIFJFTE8gaGFzIGEg c3Vic2V0IG9mDQo+IHRoZXNlKSwNCj4gPiA+ID4gYW5kIHRoaW5rIHRocm91Z2ggd2hpY2ggb2Yg dGhvc2UgZnVuY3Rpb25zIHdvdWxkIEkgcmVhbGx5IG5lZWQgZm9yDQo+ID4gPiA+IExJUy1MSVMg b3IgT0JPLCBJIGNvbWUgdXAgd2l0aDoNCj4gPiA+ID4gLSBhYmlsaXR5IHRvIHJlcXVlc3QgcmVm ZXJlbmNlIC0tIG5vdCBuZWVkZWQsIHNpbmNlLCBhcyBwb2ludGVkIG91dCwNCj4gPiA+ID4gSSd2 ZSBhbHJlYWR5IGdvdCBhIHBlcmZlY3RseSBnb29kIG5vbi1leHBpcmluZyByZWZlcmVuY2U7IE9C Tw0KPiBxdWVyaWVyDQo+ID4gb3INCj4gPiA+ID4gTElTIGRvZXNuJ3QgbmVlZCB0byBhc2sgZm9y IHJlZmVyZW5jZXMgdG8gaGFuZCBvZmYgdG8gb3RoZXJzLCBpdA0KPiA+IHNob3VsZA0KPiA+ID4g PiBjcmVhdGUgaXRzIG93biByZWZlcmVuY2VzIGZvciB0aGF0LCBhcyBhcHByb3ByaWF0ZSBbYXNp ZGU6IGENCj4gPiA+ID4gbm9uLWV4cGlyaW5nIHJlZmVyZW5jZSBhbmQgYSAiTENQIiBhcmUgcmF0 aGVyIGVxdWFsIGluIHRoZSBwcml2YWN5DQo+ID4gPiA+IGRlYmF0ZSBmcm9tIHRoZSBPQk8vTElT LUxJUyBwZXJzcGVjdGl2ZS5dDQo+ID4gPiA+IC0gYWJpbGl0eSB0byBhc3NlcnQgbG9jYXRpb24g LS0gbm90IG5lZWRlZCBmb3IgT0JPIG9yIExJUy1MSVM7IG9ubHkNCj4gYW4NCj4gPiA+ID4gZW5k IGRldmljZSBzaG91bGQgYmUgYWJsZSB0byBkbyB0aGlzLCBpZiBldmVuIHRoYXQgaXMgYWxsb3dl ZA0KPiA+ID4gPiAtIGFiaWxpdHkgdG8gcHJvdmlkZSBydWxlcy9wcm9maWxlIGZvciBwcml2YWN5 IC0tIG5vdCBuZWVkZWQgZm9yIE9CTw0KPiA+IG9yDQo+ID4gPiA+IExJUy1MSVM7IG9ubHkgdGhl IGRldmljZSBzaG91bGQgYmUgYWJsZSB0byBkbyB0aGlzDQo+ID4gPiA+IC0gYWJpbGl0eSB0byBz aWduIGxvY2F0aW9uIC0tIGlmIHRoaXMgaXMgcGFydCBvZiBQSURGLUxPLCB0aGVuIHRoaXMNCj4g aXMNCj4gPiA+ID4gaW5kZXBlbmRlbnQgb2YgcmVxdWVzdCBtZWNoYW5pc20NCj4gPiA+ID4gLSBh YmlsaXR5IHRvIHJlcXVlc3QgdGhhdCBsb2NhdGlvbiBiZSBzaWduZWQgLS0gSSB0aGluayB3ZSBj YW4NCj4gYXNzdW1lDQo+ID4gPiA+IHRoYXQgdGhlIGxvY2F0aW9uIHNob3VsZCBiZSBzaWduZWQg aWYgaXQgY2FuIGJlIHNpZ25lZA0KPiA+ID4gPiAtIGFiaWxpdHkgdG8gc3BlY2lmeSBob3cgcXVp Y2tseSBhIHJlc3BvbnNlIGlzIG5lZWRlZCAtLSB0aGlzIHdvdWxkDQo+IGJlDQo+ID4gPiA+IHVz ZWZ1bCwgYnV0IGl0IG1heSBiZSBwb3NzaWJsZSB0byBkZXNpZ24gYXJvdW5kIHRoZSBpc3N1ZQ0K PiA+ID4gPiAtIGhhdmUgSSBtaXNzZWQgYW55dGhpbmc/DQo+ID4gPiA+DQo+ID4gPiA+IFN1cHBv cnRpbmcgVVJJIGZvcm1hdHMgb3RoZXIgdGhhbiBTSVAgKGUuZy4sIEhUVFApIHdvdWxkIHN0aWxs IG5lZWQNCj4gdG8NCj4gPiA+ID4gYmUgd29ya2VkLiBCdXQgdGhhdCBmb3JtYXQgd291bGQgYmUg Y29tbW9uIHRvIGFsbCBMYnlSIHVzYWdlcy4NCj4gPiA+ID4gVGhpcyBpbiBubyB3YXkgcmVtb3Zl cyB0aGUgcmVxdWlyZW1lbnQgZm9yIGEgZGV2aWNlLXRvLUxJUyAiTENQIi4gSQ0KPiA+ID4gPiBo YXZlbid0IHJlYWQgdGhhdCBpbnRvIHRoZSBzdWdnZXN0aW9uIGF0IGFsbC4NCj4gPiA+ID4NCj4g PiA+ID4gU28sIEkgdGhpbmsgdGhpcyBpZGVhIHdhcnJhbnRzIGNvbnNpZGVyYXRpb24uDQo+ID4g PiA+IEJhcmJhcmENCj4gPiA+ID4NCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPiA+ID4gRnJvbTogQW5kcmV3IE5ld3RvbiBbbWFpbHRvOmFuZHlAaHhyLnVzXQ0KPiA+ID4g PiBTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTUsIDIwMDcgMzo1MSBQTQ0KPiA+ID4gPiBUbzog U3RhcmssIEJhcmJhcmENCj4gPiA+ID4gQ2M6IGdlb3ByaXZAaWV0Zi5vcmc7IE90bWFyIExlbmRs DQo+ID4gPiA+IFN1YmplY3Q6IFJlOiBbR2VvcHJpdl0gR2VvcHJpdiBMNyBMQ1A6IE5ldyBSZXF1 aXJlbWVudA0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBPbiBGZWIgMTUsIDIwMDcsIGF0IDEy OjUwIFBNLCBTdGFyaywgQmFyYmFyYSB3cm90ZToNCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4+ IFdoYXQgaXMgZGlmZmljdWx0LCBpcyBmaWd1cmluZyBvdXQgYSBzdGFuZGFyZCBmb3JtYXQgZm9y IGEgVVJJIHVzZXINCj4gPiA+ID4+IHBhcnQgdGhhdCB3b3VsZCBhbGxvdyBmb3IgYWxsIHRoZSB2 YXJpYXRpb25zIGluIGNvbWJpbmF0aW9ucyBvZiBJRHMNCj4gPiA+ID4+IHRoYXQgZXhpc3QsIHNv IHRoYXQgYSBzdGFuZGFyZCBmb3JtYXQgY291bGQgYmUgZGVmaW5lZCB0aGF0IHdvdWxkDQo+ID4g PiA+PiBjb3ZlciBhbGwgaW50ZXJjb25uZWN0aW9uIG1vZGVscy4gU2VjdGlvbiA4IG9mIHRoZSBO RU5BIExvY2F0aW9uDQo+IFRJRA0KPiA+ID4gPj4gKGh0dHA6Ly93d3cubmVuYS5vcmcvbWVkaWEv ZmlsZXMvMDgtNTA1XzIwMDYxMjIxLnBkZikgcHJvdmlkZXMgNQ0KPiA+ID4gPj4gZGlmZmVyZW50 IGV4YW1wbGVzIG9mIGludGVyY29ubmVjdGlvbiBtb2RlbHMsIGFuZCB0aGUgSURzIHRoYXQNCj4g d291bGQNCj4gPiA+ID4+IG5lZWQgdG8gYmUgdXNlZCBpbiBlYWNoIG9mIHRoZXNlIGNhc2VzLiBJ biB0aGlzIGRvY3VtZW50LCBzY2VuYXJpbw0KPiAxDQo+ID4gPiA+PiB1c2VzIHRoZSBJUCBhZGRy ZXNzLCBzY2VuYXJpbyAyIHVzZXMgTkFTLUlEIGFuZCBBVE0gUFZDLCBzY2VuYXJpbyAzDQo+ID4g PiA+PiB1c2VzDQo+ID4gPiA+PiAyIFZMQU4gdGFncywgc2NlbmFyaW8gNCB1c2VzIElQIGFkZHJl c3MsIGFuZCBzY2VuYXJpbyA1IHVzZXMgTDJUUA0KPiA+ID4gPj4gdHVubmVsIElEIChzb3VyY2Ug YW5kIGRlc3RpbmF0aW9uKSBhbmQgUFBQb0Ugc2Vzc2lvbiBJRC4gVGhlc2UgYXJlDQo+ID4gPiA+ PiBqdXN0IDUgcG9zc2libGUgZXhhbXBsZXMsIGFuZCBzaG91bGQgbm90IGJlIGNvbnNpZGVyZWQg ZXhoYXVzdGl2ZS4NCj4gPiA+ID4+IEludGVyY29ubmVjdGlvbiBtb2RlbHMgYXJlIHN0aWxsIGV2 b2x2aW5nLg0KPiA+ID4gPj4NCj4gPiA+ID4NCj4gPiA+ID4gV2VsbCwgdGhhdCdzIGVhc2lseSBz b2x2ZWQgd2l0aCBhIEJDUCBmb3IgZm9ybXVsYXRpbmcgVVJJcyBiYXNlZCBvbg0KPiA+IHRoZQ0K PiA+ID4gPiBJRC4gIFlvdSBkb24ndCBuZWVkIGEgbmV3IHByb3RvY29sIG9yIHRvIGNvbmZsYXRl IHRoZSBMQ1AgcHJvdG9jb2wNCj4gPiB3aXRoDQo+ID4gPiA+IHRoaXMgZnVuY3Rpb25hbGl0eS4N Cj4gPiA+ID4NCj4gPiA+ID4gLWFuZHkNCj4gPiA+ID4NCj4gPiA+ID4gKioqKioNCj4gPiA+ID4N Cj4gPiA+ID4gVGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGlzIGludGVuZGVkIG9ubHkgZm9y IHRoZSBwZXJzb24gb3INCj4gZW50aXR5DQo+ID4gdG8NCj4gPiA+IHdoaWNoIGl0IGlzIGFkZHJl c3NlZCBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsLCBwcm9wcmlldGFyeSwNCj4gYW5kL29y DQo+ID4gPiBwcml2aWxlZ2VkIG1hdGVyaWFsLiBBbnkgcmV2aWV3LCByZXRyYW5zbWlzc2lvbiwg ZGlzc2VtaW5hdGlvbiBvcg0KPiBvdGhlcg0KPiA+ID4gdXNlIG9mLCBvciB0YWtpbmcgb2YgYW55 IGFjdGlvbiBpbiByZWxpYW5jZSB1cG9uIHRoaXMgaW5mb3JtYXRpb24gYnkNCj4gPiA+IHBlcnNv bnMgb3IgZW50aXRpZXMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hp Yml0ZWQuDQo+IElmDQo+ID4gPiB5b3UgcmVjZWl2ZWQgdGhpcyBpbiBlcnJvciwgcGxlYXNlIGNv bnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoZQ0KPiA+ID4gbWF0ZXJpYWwgZnJvbSBhbGwg Y29tcHV0ZXJzLiBHQTYyMQ0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiBHZW9w cml2IG1haWxpbmcgbGlzdA0KPiA+ID4gPiBHZW9wcml2QGlldGYub3JnDQo+ID4gPiA+IGh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dlb3ByaXYNCj4gPiA+ID4NCj4gPiA+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ ID4gR2VvcHJpdiBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gR2VvcHJpdkBpZXRmLm9yZw0KPiA+ID4g PiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nZW9wcml2DQo+ID4gPiA+ DQo+ID4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBHZW9wcml2IG1haWxpbmcgbGlzdA0KPiA+ID4g R2VvcHJpdkBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZ2VvcHJpdg0KPiA+ID4NCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gPiAtLQ0K PiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gVGhpcyBtZXNzYWdlIGlzIGZvciB0 aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQo+ID4gPiBjb250YWluIHByaXZp bGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4NCj4g PiA+IElmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXINCj4gPiA+IGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVu YXV0aG9yaXplZCB1c2Ugb2YNCj4gPiA+IHRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCj4gPiA+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gPiAtLQ0KPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA+ID4gW21mMl0NCj4gPiA+DQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IEdlb3ByaXYgbWFpbGluZyBsaXN0DQo+ ID4gPiBHZW9wcml2QGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9nZW9wcml2DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gR2VvcHJpdiBtYWlsaW5nIGxpc3QNCj4gPiBH ZW9wcml2QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZ2VvcHJpdg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiBUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5 IGFuZCBtYXkNCj4gY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNl IHByaXZhdGUgaW5mb3JtYXRpb24uDQo+IElmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCj4gaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUg b3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KPiB0aGlzIGVtYWlsIGlzIHByb2hp Yml0ZWQuDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g W21mMl0NCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBHZW9wcml2IG1haWxpbmcgbGlzdA0KPiBHZW9wcml2QGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dlb3ByaXYNCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBk ZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJv cHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2 ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlh dGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0 aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClttZjJdDQo= --===============0376878094== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0376878094==-- From geopriv-bounces@ietf.org Sun Mar 11 19:11: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 1HQXCC-0004Df-5l; Sun, 11 Mar 2007 19:11:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQXCA-0004DY-Bh for geopriv@ietf.org; Sun, 11 Mar 2007 19:11:18 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQXC9-0000DN-2z for geopriv@ietf.org; Sun, 11 Mar 2007 19:11:18 -0400 X-SEF-Processed: 5_0_0_910__2007_03_11_18_17_12 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, 11 Mar 2007 18:17:12 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Mar 2007 18:11:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] thomson-geopriv-3825bis Date: Sun, 11 Mar 2007 18:11:15 -0500 Message-ID: In-Reply-To: <86C9C582-BD1A-49E0-ACA3-A1EA5C3599E1@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] thomson-geopriv-3825bis Thread-Index: AcdjVrAwhfGifjqsQi+zXzdKUn06CgA2u72g From: "Thomson, Martin" To: "Cullen Jennings" , X-OriginalArrivalTime: 11 Mar 2007 23:11:16.0803 (UTC) FILETIME=[923E0930:01C76432] X-Spam-Score: 1.1 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1739595610==" Errors-To: geopriv-bounces@ietf.org --===============1739595610== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ3VsbGVuLA0KDQpUaGF0IHdhcyB3cml0dGVuIHVuZGVyIHRoZSBhc3N1bXB0aW9uIHRoYXQg d2lyZWphY2sgPC0+IGNsaWVudCBpcyBub3Qgc2lnbmlmaWNhbnRseSBkaWZmZXJlbnQ7IGFuZCB0 aGF0IHRoZSB3aXJlamFjayBpcyB0aGUgb25seSBpbW1vYmlsZSBpdGVtLiAgKEkgdGhpbmsgaXQg d2FzIGFsc28gY29waWVkIGZyb20gUkZDIDQ3NzYuKQ0KDQpUaGUgYXV0aG9ycyBkb24ndCBiZWxp ZXZlIHRoYXQgREhDUCBpcyBzdWl0YWJsZSBmb3Igd2lyZWxlc3MgY2xpZW50cy4gIEkgdGVuZCB0 byBhZ3JlZSwgdGhlIGxpc3Qgb2YgY2F2ZWF0cyBpcyB0b28gbG9uZy4gIChCdXQgdG8gYW5zd2Vy IHlvdXIgcXVlc3Rpb24sIHRoZSBhcHByb3hpbWF0ZWQgY2xpZW50IGxvY2F0aW9uIGFuZCB1bmNl cnRhaW50eSB3b3VsZCBiZSBiZXR0ZXIpLg0KDQpJZiB0aGUgZG9jdW1lbnQgaXMgcmV2aXNlZCwg d2hpY2ggaXMgdW5saWtlbHkgZ2l2ZW4gdGhlIGhvc3RpbGUgcmVzcG9uc2UgaXQgZ2VuZXJhdGVk IG9uIHRoZSBsaXN0LCBJIHRoaW5rIHRoYXQgeW91ciBzdWdnZXN0aW9ucyB3b3VsZCBiZSBnb29k Lg0KDQpDaGVlcnMsDQpNYXJ0aW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBDdWxsZW4gSmVubmluZ3MgW21haWx0bzpmbHVmZnlAY2lzY28uY29tXQ0KPiBTZW50OiBT dW5kYXksIDExIE1hcmNoIDIwMDcgNzo1NSBBTQ0KPiBUbzogZ2VvcHJpdkBpZXRmLm9yZw0KPiBT dWJqZWN0OiBbR2VvcHJpdl0gdGhvbXNvbi1nZW9wcml2LTM4MjViaXMNCj4gDQo+IA0KPiBUaGlz IHJlcG9ydHMgdGhlIGxvY2F0aW9uIG9mIHRoZSB3aXJlamFjayBub3QgdGhlIERIQ1AgY2xpZW50 LiBIb3cNCj4gd2lsbCB0aGUgY2xpZW50IGtub3cgd2hhdCBhc3N1bXB0aW9ucyB0byBtYWtlIGFi b3V0IHRoZSBhZGRpdGlvbmFsDQo+IHVuY2VydGFpbnR5IGZvcm0gdGhlIHdpcmVqYWNrPyBXaGF0 IGRvZXMgdGhpcyBtZWFuIGZvciBXQVAgdGhhdCBkb24ndA0KPiBoYXZlIGFkZGl0aW9uYWwgd2ly ZWxlc3MgbG9jYXRpb24gc3VwcG9ydC4gSSB0aGluayB0aGF0IHJlcG9ydGluZyB0aGUNCj4gYXBw cm94aW1hdGVkIGNsaWVudCBsb2NhdGlvbiBhbmQgYXBwcm94aW1hdGVkIHVuY2VydGFpbnR5IG1p Z2h0IHdvcmsNCj4gb3V0IGJldHRlci4NCj4gDQo+IEN1bGxlbiA8d2l0aCBteSBpbmRpdmlkdWFs IGhhdCBvbj4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IEdlb3ByaXYgbWFpbGluZyBsaXN0DQo+IEdlb3ByaXZAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2VvcHJpdg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRl c2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9w cmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZl IHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0 ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRo aXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KW21mMl0NCg== --===============1739595610== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1739595610==-- From geopriv-bounces@ietf.org Sun Mar 11 19:19:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQXK5-0001xJ-8R; Sun, 11 Mar 2007 19:19:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQXK4-0001xE-FE for geopriv@ietf.org; Sun, 11 Mar 2007 19:19:28 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQXK3-0001Ff-6h for geopriv@ietf.org; Sun, 11 Mar 2007 19:19:28 -0400 X-SEF-Processed: 5_0_0_910__2007_03_11_18_25_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); Sun, 11 Mar 2007 18:25:22 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Mar 2007 18:19:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] draft-thomson-geopriv-lis-discovery-00 Date: Sun, 11 Mar 2007 18:19:25 -0500 Message-ID: In-Reply-To: <70101239-BB7A-4195-A0FD-91ABFF22E15F@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] draft-thomson-geopriv-lis-discovery-00 Thread-Index: AcdjX4cE2nX45O9bR9+AD5jGG0GxTgA00SNQ From: "Thomson, Martin" To: "Cullen Jennings" , X-OriginalArrivalTime: 11 Mar 2007 23:19:26.0856 (UTC) FILETIME=[B6563080:01C76433] X-Spam-Score: 1.1 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1064496266==" Errors-To: geopriv-bounces@ietf.org --===============1064496266== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ3VsbGVuLA0KDQpUaGUgaW50ZW50IGlzIG5vdCB0byBkaXNjb3ZlciB0aGUgb3V0ZXJtb3N0 IE5BVCwgYXQgbGVhc3Qgbm90IGFsd2F5cy4gIElmIHlvdSBsb29rIGF0IHRoZSBjYXNlcyB3aGVy ZSB0d28gbGF5ZXJzIG9mIE5BVCBhcmUgdXNlZCwgYSBMSVMgaXMgbGlrZWx5IHRvIGV4aXN0IHdp dGhpbiB0aGUgc2Vjb25kIGxheWVyLg0KDQpJJ20gdGhpbmtpbmcgcHJpbWFyaWx5IG9mIGNhYmxl IG5ldHdvcmtzIHdoZXJlIGl0IGlzIGNvbW1vbiB0byBoYXZlIGEgTkFUIG9uIHRoZSBjdXN0b21l ciBwcmVtaXNlcyBhbmQgYW5vdGhlciBOQVQgZm9yIHRoZSBlbnRpcmUgSVNQIG5ldHdvcmsgKG9y IHBhcnRzIHRoZXJlb2YpLiAgU2F5IHRoZXNlIGFyZSBhIDE5Mi4xNjgueC54IChpbiBteSBob3Vz ZSkgYW5kIGEgMTAueC54LnggKGZvciBteSBJU1ApLiAgVGhlIElTUCBMSVMgbmVlZHMgdG8gZXhp c3QgaW4gdGhlIGxhcmdlciBuZXR3b3JrIHNvIHRoYXQgaXQgY2FuIHNlZSB0aGUgbmVjZXNzYXJ5 IGlkZW50aWZpZXJzIChwcmltYXJseSwgdGhlIDEwLngueC54IGFkZHJlc3MgdGhhdCBpcyBnaXZl biB0byB5b3VyIGhvdXNlL21vZGVtL3JvdXRlci9OQVQpLiAgSW4gdGhpcyBjYXNlLCByZXNvbHZp bmcgdGhlIElQIG9mIHRoZSBvdXRlcm1vc3QgTkFUIGlzIGNvdW50ZXJwcm9kdWN0aXZlLg0KDQpQ ZXJoYXBzIHRoaXMgZGlzY3Vzc2lvbiBpcyB3b3J0aCBpbmNsdWRpbmcgaW4gdGhlIGRyYWZ0Lg0K DQpDaGVlcnMsDQpNYXJ0aW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBDdWxsZW4gSmVubmluZ3MgW21haWx0bzpmbHVmZnlAY2lzY28uY29tXQ0KPiBTZW50OiBTdW5k YXksIDExIE1hcmNoIDIwMDcgOTowMCBBTQ0KPiBUbzogZ2VvcHJpdkBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBbR2VvcHJpdl0gZHJhZnQtdGhvbXNvbi1nZW9wcml2LWxpcy1kaXNjb3ZlcnktMDANCj4g DQo+IA0KPiBVUG5QIHdpbGwgbm90IGRpc2NvdmVyIHRoZSBvdXRlciBtb3N0IE5BVCBzbyBJIGRv biB0aGluayBpdCBzaG91bGQgYmUNCj4gdXNlZCBoZXJlLg0KPiANCj4gQ3VsbGVuIDx3aXRoIG15 IGluZGl2aWR1YWwgaGF0IG9uPg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IEdlb3ByaXYgbWFpbGluZyBsaXN0DQo+IEdlb3ByaXZA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2VvcHJp dg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2Fn ZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBw cml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24u ICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9y aXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0NCg== --===============1064496266== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1064496266==-- From geopriv-bounces@ietf.org Sun Mar 11 19:24: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 1HQXOl-0007dz-Vm; Sun, 11 Mar 2007 19:24:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQXOk-0007ds-Uu for geopriv@ietf.org; Sun, 11 Mar 2007 19:24:18 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQXOj-00021x-L5 for geopriv@ietf.org; Sun, 11 Mar 2007 19:24:18 -0400 X-SEF-Processed: 5_0_0_910__2007_03_11_18_30_13 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); Sun, 11 Mar 2007 18:30:13 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Mar 2007 18:24:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] DHCP Size Date: Sun, 11 Mar 2007 18:24:15 -0500 Message-ID: In-Reply-To: <22EF0D6F-6FA0-40E0-AA6D-E13BD915ADB1@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] DHCP Size Thread-Index: AcdjcoWDPHxjenLoT7+9fKpqhDLAkgAwVsSQ From: "Thomson, Martin" To: "Cullen Jennings" , "James M. Polk" X-OriginalArrivalTime: 11 Mar 2007 23:24:17.0356 (UTC) FILETIME=[637CF8C0:01C76434] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2052637512==" Errors-To: geopriv-bounces@ietf.org --===============2052637512== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgaXMgbm90aGluZyBwcmV2ZW50aW5nIGEgY2xpZW50IGZyb20gcmVxdWVzdGluZyBvcHRp b25zIHNlcGFyYXRlbHk7IGJ1dCB0aGVuIHRoZXJlIGlzIGEgbmVlZCB0byBkZXRlcm1pbmUgaG93 IGxpa2VseSB0aGF0IGlzLg0KDQpUaGUgb25seSBvcHRpb24gSSdkIGJlIGNvbmNlcm5lZCBhYm91 dCBpcyB0aGUgY2l2aWMgYWRkcmVzcyBvcHRpb24uICBMYW5ndWFnZXMgdGhhdCByZXF1aXJlIG11 bHRpLWJ5dGUgY2hhcmFjdGVycyBjb3VsZCBiZSBhIHByb2JsZW0uICBJbiBwYXJ0aWN1bGFyLCBJ IHRoaW5rIGFib3V0IHRoZSBUYWl3YW5lc2UgYWRkcmVzc2VzIHdoaWNoIGFsc28gaGF2ZSBhIG11 bHRpLWxheWVyIHN0cmVldCBoaWVyYXJjaHkuICBUaGF0IHdvdWxkIGJlIG1vcmUgb2YgSGVubmlu ZydzIGRvbWFpbi4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBDdWxs ZW4gSmVubmluZ3MgW21haWx0bzpmbHVmZnlAY2lzY28uY29tXQ0KPiBTZW50OiBTdW5kYXksIDEx IE1hcmNoIDIwMDcgMTE6MTUgQU0NCj4gVG86IEphbWVzIE0uIFBvbGsNCj4gQ2M6IGdlb3ByaXZA aWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtHZW9wcml2XSBESENQIFNpemUNCj4gDQo+IA0KPiBN YWtlcyBzZW5zZSAtIEkgd2FzIGp1c3Qgc3RhcnRpbmcgdG8gZ2V0IGEgbGl0dGxlIHdvcnJpZWQg dGhhdCBhbGwNCj4gdGhlIG9wdGlvbnMgdG9nZXRoZXIgbWlnaHQgYmUgZ2V0dGluZyBjbG9zZSB0 byB0b28gYmlnLg0KPiANCj4gQ291bGQgd2UgdHJ5IGxpc3RpbmcgYWxsIHRoZSBvcHRpb25zIHRo YXQgd2UgY2FuIGltYWdpbmUgbWlnaHQNCj4gcmVhc29uYWJsZSBnZXQgcHV0IGluIHRoZSByZXNw b25zZSB0byBESENQIHJlcXVlc3QgZnJvbSBhIFNJUCBVQSBhbmQNCj4gY2hlY2sgdGhhdCB0aGVy ZSBhcmUgbm8gc3VycHJpc2VzLg0KPiANCj4gDQo+IE9uIE1hciAxMCwgMjAwNywgYXQgMjowNSBQ TSwgSmFtZXMgTS4gUG9sayB3cm90ZToNCj4gDQo+ID4gQXQgMDI6MzIgUE0gMy8xMC8yMDA3LCBD dWxsZW4gSmVubmluZ3Mgd3JvdGU6DQo+ID4NCj4gPj4gT25lIHRoaW5nIEkgaGF2ZSBiZWVuIGdl dHRpbmcgY29uY2VybmVkIHdpdGggaXMgdGhlIHNpemUgb2YgREhDUA0KPiA+PiByZXNwb25zZXMg d2l0aCBhbGwgdGhlIFNJUC9FQ1JJVC9HRU9QUklWIGV0YyB1c2FnZXMgb2YgdGhlbS4gSGFzDQo+ ID4+IGFueW9uZSBsb29rZWQgYXQgaG93IGJpZyBvbmUgY291bGQgcmVhc29uYWJsZSBnZXQ/DQo+ ID4NCj4gPiBESENQIGhhcyBzb21lIGludGVyZXN0aW5nIGxpbWl0YXRpb25zIHRvIE9wdGlvbiBz aXplIChSRkMyMTMxKSwNCj4gPiBpbmNsdWRpbmcNCj4gPg0KPiA+ICAgICAgICAgKiB0aGUgc2l6 ZSBsaW1pdGF0aW9uIG9mIGFueSBpbmRpdmlkdWFsIE9wdGlvbiByZXNwb25zZQ0KPiA+ICgyNTUg Ynl0ZXMgSSBiZWxpZXZlKQ0KPiA+ICAgICAgICAgKiB0aGUgc2l6ZSBvZiB0aGUgYWdncmVnYXRl IG9mIGFsbCByZXNwb25zZXMgd2l0aGluIGEgbWVzc2FnZQ0KPiA+ICAgICAgICAgKiBhbmQgaG93 IHRvIGNvbmNhdGVuYXRlIE9wdGlvbnMgKFJGQzMzOTYpDQo+ID4NCj4gPiBCdXQgZ2VuZXJhbGx5 LCBESENQIHJlc3BvbnNlcyBhcmUgbGltaXRlZCB0byA1NzYgYnl0ZXMgZm9yIGFsbA0KPiA+IG9w dGlvbnMgKGkuZS4gbm90IGp1c3QgbG9jYXRpb24pLCB1bmxlc3Mgc29tZXRoaW5nIHNwZWNpYWwg aGFzDQo+ID4gb2NjdXJyZWQuICBUaGlzIFdHIGNhbm5vdCBhc3N1bWUgdGhhdCBvbmx5IGxvY2F0 aW9uIHdpbGwgYmUgaW4gYQ0KPiA+IERIQ1AgKE9GRkVSIG9yIEFDSykgcmVzcG9uc2UsIGV2ZW4g aWYgdGhhdCBpcyBhbGwgdGhhdCB3YXMNCj4gPiByZXF1ZXN0ZWQgaW4gYSBESVNDT1ZFUiwgUkVR VUVTVCBvciBJTkZPUk0gbWVzc2FnZS4gT2Z0ZW4gbWFueSBtb3JlDQo+ID4gb3B0aW9ucyB3aWxs IGJlIGluIHRoYXQgc2FtZSByZXNwb25zZSBtZXNzYWdlIC0gd2hpY2ggaXMgb3V0IG9mIHRoZQ0K PiA+IGNvbnRyb2wgb2YgdGhlIGNsaWVudCwgYnV0IHVuZGVyIHRoZSBjb250cm9sIG9mIHRoZSBz ZXJ2ZXIuIEFsbCBvZg0KPiA+IHRoaXMgaXMgY2FwcGVkIGF0IDU3NiBieXRlcyAodW5sZXNzIHNv bWV0aGluZyBzcGVjaWFsIGhhcw0KPiA+IG9jY3VycmVkKS4gIEdlbmVyYWxseSwgaWYgYW4gT0ZG RVIgb3IgQUNLICByZXNwb25zZSBpcyByZWNlaXZlZCBpbg0KPiA+IGNvbnNlY3V0aXZlIHBhY2tl dHMsIHRoZSBzZWNvbmQgcGFja2V0J3MgdmFsdWVzIG92ZXJ3cml0ZSB0aGUgZmlyc3QNCj4gPiBw YWNrZXRzIHZhbHVlcy4gSW4gZmFjdCwgSSB0aGluayBhbnkgc3Vic2VxdWVuY2UgcmVzcG9uc2Ug d2l0aCBhDQo+ID4gbmV3IHZhbHVlIHdpdGhpbiBhIHNwZWNpZmljIE9wdGlvbiBvdmVyd3JpdGVz IHdoYXQgd2FzIHRoZXJlIGZyb20NCj4gPiB0aGUgcHJldmlvdXMgcmVzcG9uc2UuDQo+ID4NCj4g PiBJIHRoaW5rIGl0IGlzIHBvc3NpYmxlIHNvbWUgZm9sa3Mgb24gdGhpcyBsaXN0IGFzc3VtZSBE SENQIGhhcyB0aGUNCj4gPiBub3JtYWwgTVRVIG9mIDE1MDAgYnl0ZXMgLSBhbmQgdGhhdCBpc24n dCB0aGUgY2FzZS4NCj4gPg0KPiA+DQo+ID4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gR2VvcHJpdiBtYWlsaW5nIGxpc3QNCj4gPj4g R2VvcHJpdkBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9nZW9wcml2DQo+ID4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IEdlb3ByaXYgbWFpbGluZyBsaXN0DQo+IEdlb3ByaXZAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2VvcHJpdg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBm b3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxl Z2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklm IHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIN CmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1 c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0NCg== --===============2052637512== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============2052637512==-- From geopriv-bounces@ietf.org Sun Mar 11 19:39: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 1HQXcw-0005Di-Ki; Sun, 11 Mar 2007 19:38:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQXcv-0005Dd-Qi for geopriv@ietf.org; Sun, 11 Mar 2007 19:38:57 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQXcu-00055T-Jh for geopriv@ietf.org; Sun, 11 Mar 2007 19:38:57 -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 1HQXco-00037k-3h; Sun, 11 Mar 2007 19:38:50 -0400 Message-ID: <45F4930A.1040606@bbn.com> Date: Sun, 11 Mar 2007 19:38:50 -0400 From: Richard Barnes User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Geopriv] draft-marshall-geopriv-lbyr-requirements-01 References: <2EE96B90-FBD5-4C77-B382-14E9DC60B71B@cisco.com> In-Reply-To: <2EE96B90-FBD5-4C77-B382-14E9DC60B71B@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I don't know of any such requirement, but it wouldn't be inconsistent with the existing requirements: I think concept of a "dereference protocol" discussed in the requirements is large enough to cover both synchronous and asynchronous delivery. And I don't think any of the requirements contradict an asynchronous model. --RB Cullen Jennings wrote: > > Is there a requirement for the LR to be asynchronously notified about > location changes for an LRI that has not expired and that the LR > dereferences? > > Cullen > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sun Mar 11 20:20:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQYGw-0003hm-J3; Sun, 11 Mar 2007 20:20:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQYGu-0003aH-LD for geopriv@ietf.org; Sun, 11 Mar 2007 20:20:16 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQYGq-0003ZR-Du for geopriv@ietf.org; Sun, 11 Mar 2007 20:20:16 -0400 Received: from [192.168.0.41] (pool-141-153-174-50.mad.east.verizon.net [141.153.174.50]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2C0K6JG015879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 11 Mar 2007 20:20:09 -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: <1E26B824-0392-43DF-A27F-EB791B9DF15E@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] DHCP Size Date: Sun, 11 Mar 2007 20:20:05 -0400 To: "Thomson, Martin" 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: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org > > The only option I'd be concerned about is the civic address > option. Languages that require multi-byte characters could be a > problem. In particular, I think about the Taiwanese addresses > which also have a multi-layer street hierarchy. That would be more > of Henning's domain. I don't have good statistical data on Taiwanese or Chinese address sizes, but, in general, I don't think multi-byte characters change much, compared to the Latin representation, since each Chinese character typically represents two or three Latin characters, which just happens to the UTF-8 expansion factor. http://www.bitboost.com/ref/international-address-formats.html#PRC gives some examples, including multi-layer street names, all of which are similar in length to US or European addresses. I'm guessing (and I'm sure there are Chinese-speaking contributors on this list who can correct me...) that, say, Jiu Shi Fu Xin in one of the examples represents no more than 4 Chinese characters. The longest address in that small sample has 125 bytes (including the occupant name), so this is not likely to cause problems. If there's a multi-byte problem, it would be more likely with alphabetic languages, say Russian or Greek. With the typical expansion by a factor of 2, we'd still be around 200, i.e., well south of DHCP limitations. Henning _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sun Mar 11 20:33:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQYTK-0005zo-Ux; Sun, 11 Mar 2007 20:33:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQYTJ-0005yG-DP for geopriv@ietf.org; Sun, 11 Mar 2007 20:33:05 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQYTI-0005f9-4s for geopriv@ietf.org; Sun, 11 Mar 2007 20:33:05 -0400 X-SEF-Processed: 5_0_0_910__2007_03_11_19_39_00 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, 11 Mar 2007 19:38:59 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Mar 2007 19:33:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] DHCP Size Date: Sun, 11 Mar 2007 19:33:02 -0500 Message-ID: In-Reply-To: <1E26B824-0392-43DF-A27F-EB791B9DF15E@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] DHCP Size Thread-Index: AcdkPDNyswlpmxnmRHeTRTDia13bYQAAQX3w From: "Thomson, Martin" To: "Henning Schulzrinne" , "James M. Polk" X-OriginalArrivalTime: 12 Mar 2007 00:33:03.0787 (UTC) FILETIME=[FF085FB0:01C7643D] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0370026980==" Errors-To: geopriv-bounces@ietf.org --===============0370026980== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCBzb3VuZHMgc2Vuc2libGUuICBUaGUgb25seSBwb3RlbnRpYWwgcHJvYmxlbSBvY2N1cnMg d2hlbiBjaXZpYyBhZGRyZXNzZXMgYXJlIHJlcXVlc3RlZCBpbiBjb21iaW5hdGlvbiB3aXRoIG90 aGVyIG9wdGlvbnMuDQoNCkZvciBjdXJpb3NpdHkncyBzYWtlLCBkb2VzIHRoZSA1NzYgYnl0ZSBs aW1pdCBpbmNsdWRlIHRoZSAyMzYgYnl0ZSBmaXhlZCBwYXJ0LCBvciBpcyBpdCBpbiBhZGRpdGlv biB0byB0aGF0PyAgQSAyMDAgYnl0ZSBhZGRyZXNzIGlzIGEgc2lnbmlmaWNhbnQgY2h1bmsgb3V0 IG9mIDU3NiBieXRlcywgYnV0IGl0J3MgZXZlbiBtb3JlIHdoZW4gdGFrZW4gZnJvbSAzNDAgYnl0 ZXMuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSGVubmluZyBTY2h1 bHpyaW5uZSBbbWFpbHRvOmhnc0Bjcy5jb2x1bWJpYS5lZHVdDQo+IFNlbnQ6IE1vbmRheSwgMTIg TWFyY2ggMjAwNyAxMToyMCBBTQ0KPiBUbzogVGhvbXNvbiwgTWFydGluDQo+IENjOiBHRU9QUklW DQo+IFN1YmplY3Q6IFJlOiBbR2VvcHJpdl0gREhDUCBTaXplDQo+IA0KPiA+DQo+ID4gVGhlIG9u bHkgb3B0aW9uIEknZCBiZSBjb25jZXJuZWQgYWJvdXQgaXMgdGhlIGNpdmljIGFkZHJlc3MNCj4g PiBvcHRpb24uICBMYW5ndWFnZXMgdGhhdCByZXF1aXJlIG11bHRpLWJ5dGUgY2hhcmFjdGVycyBj b3VsZCBiZSBhDQo+ID4gcHJvYmxlbS4gIEluIHBhcnRpY3VsYXIsIEkgdGhpbmsgYWJvdXQgdGhl IFRhaXdhbmVzZSBhZGRyZXNzZXMNCj4gPiB3aGljaCBhbHNvIGhhdmUgYSBtdWx0aS1sYXllciBz dHJlZXQgaGllcmFyY2h5LiAgVGhhdCB3b3VsZCBiZSBtb3JlDQo+ID4gb2YgSGVubmluZydzIGRv bWFpbi4NCj4gDQo+IEkgZG9uJ3QgaGF2ZSBnb29kIHN0YXRpc3RpY2FsIGRhdGEgb24gVGFpd2Fu ZXNlIG9yIENoaW5lc2UgYWRkcmVzcw0KPiBzaXplcywgYnV0LCBpbiBnZW5lcmFsLCBJIGRvbid0 IHRoaW5rIG11bHRpLWJ5dGUgY2hhcmFjdGVycyBjaGFuZ2UNCj4gbXVjaCwgY29tcGFyZWQgdG8g dGhlIExhdGluIHJlcHJlc2VudGF0aW9uLCBzaW5jZSBlYWNoIENoaW5lc2UNCj4gY2hhcmFjdGVy IHR5cGljYWxseSByZXByZXNlbnRzIHR3byBvciB0aHJlZSBMYXRpbiBjaGFyYWN0ZXJzLCB3aGlj aA0KPiBqdXN0IGhhcHBlbnMgdG8gdGhlIFVURi04IGV4cGFuc2lvbiBmYWN0b3IuDQo+IA0KPiBo dHRwOi8vd3d3LmJpdGJvb3N0LmNvbS9yZWYvaW50ZXJuYXRpb25hbC1hZGRyZXNzLWZvcm1hdHMu aHRtbCNQUkMNCj4gDQo+IGdpdmVzIHNvbWUgZXhhbXBsZXMsIGluY2x1ZGluZyBtdWx0aS1sYXll ciBzdHJlZXQgbmFtZXMsIGFsbCBvZiB3aGljaA0KPiBhcmUgc2ltaWxhciBpbiBsZW5ndGggdG8g VVMgb3IgRXVyb3BlYW4gYWRkcmVzc2VzLg0KPiANCj4gSSdtIGd1ZXNzaW5nIChhbmQgSSdtIHN1 cmUgdGhlcmUgYXJlIENoaW5lc2Utc3BlYWtpbmcgY29udHJpYnV0b3JzIG9uDQo+IHRoaXMgbGlz dCB3aG8gY2FuIGNvcnJlY3QgbWUuLi4pIHRoYXQsIHNheSwgSml1IFNoaSBGdSBYaW4gaW4gb25l IG9mDQo+IHRoZSBleGFtcGxlcyByZXByZXNlbnRzIG5vIG1vcmUgdGhhbiA0IENoaW5lc2UgY2hh cmFjdGVycy4NCj4gDQo+IFRoZSBsb25nZXN0IGFkZHJlc3MgaW4gdGhhdCBzbWFsbCBzYW1wbGUg aGFzIDEyNSBieXRlcyAoaW5jbHVkaW5nIHRoZQ0KPiBvY2N1cGFudCBuYW1lKSwgc28gdGhpcyBp cyBub3QgbGlrZWx5IHRvIGNhdXNlIHByb2JsZW1zLg0KPiANCj4gSWYgdGhlcmUncyBhIG11bHRp LWJ5dGUgcHJvYmxlbSwgaXQgd291bGQgYmUgbW9yZSBsaWtlbHkgd2l0aA0KPiBhbHBoYWJldGlj IGxhbmd1YWdlcywgc2F5IFJ1c3NpYW4gb3IgR3JlZWsuIFdpdGggdGhlIHR5cGljYWwNCj4gZXhw YW5zaW9uIGJ5IGEgZmFjdG9yIG9mIDIsIHdlJ2Qgc3RpbGwgYmUgYXJvdW5kIDIwMCwgaS5lLiwg d2VsbA0KPiBzb3V0aCBvZiBESENQIGxpbWl0YXRpb25zLg0KPiANCj4gSGVubmluZw0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3Ig dGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2Vk LCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlv dSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmlt bWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ug b2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KW21mMl0NCg== --===============0370026980== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0370026980==-- From geopriv-bounces@ietf.org Sun Mar 11 20:43: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 1HQYdL-0004Hp-Hx; Sun, 11 Mar 2007 20:43:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQYdK-0004Hj-PL for geopriv@ietf.org; Sun, 11 Mar 2007 20:43:26 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQYdJ-0007y2-Hp for geopriv@ietf.org; Sun, 11 Mar 2007 20:43:26 -0400 Received: from [192.168.0.41] (pool-141-153-174-50.mad.east.verizon.net [141.153.174.50]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2C0hOn4018309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 11 Mar 2007 20:43:24 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] DHCP Size Date: Sun, 11 Mar 2007 20:43:22 -0400 To: "Thomson, Martin" 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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org On Mar 11, 2007, at 8:33 PM, Thomson, Martin wrote: > That sounds sensible. The only potential problem occurs when civic > addresses are requested in combination with other options. > > For curiosity's sake, does the 576 byte limit include the 236 byte > fixed part, or is it in addition to that? A 200 byte address is a > significant chunk out of 576 bytes, but it's even more when taken > from 340 bytes. I don't see this as a major problem, for two reasons: "DHCP clients may negotiate the use of larger DHCP messages through the 'maximum DHCP message size' option. The options field may be further extended into the 'file' and 'sname' fields." [RFC 2131] In other words, the 'file' and 'sname' fields that contribute to the 236 bytes you mention aren't really wasted and the real fixed header is only 44 bytes. Since DHCPINFORM can specifically ask for one option at a time, I see few problems here. Henning _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sun Mar 11 20:53:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQYmi-0004h7-AN; Sun, 11 Mar 2007 20:53:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQYmh-0004h1-NN for geopriv@ietf.org; Sun, 11 Mar 2007 20:53:07 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQYmd-0001Qg-3P for geopriv@ietf.org; Sun, 11 Mar 2007 20:53:07 -0400 Received: from [192.168.0.41] (pool-141-153-174-50.mad.east.verizon.net [141.153.174.50]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2C0qruJ026992 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 11 Mar 2007 20:52:57 -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: <226BC9E7-F571-43E3-A9ED-611F2B124A94@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Where we are / are we with L7-LCP Date: Sun, 11 Mar 2007 20:52:49 -0400 To: "Thomson, Martin" 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: d17f825e43c9aed4fd65b7edddddec89 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org RFC 4481 has the equivalent of expiration functionality. On Mar 11, 2007, at 6:52 PM, Thomson, Martin wrote: > I believe that using the entity attribute has already been proposed. > > Henning, which of the plethora of PIDF standards contains > "expires"? 3863 has a timestamp, but nothing of the "expires" nature. > With that, the whole object can be signed, if desired. _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Mar 12 07:55: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 1HQj82-00025Y-5u; Mon, 12 Mar 2007 07:55:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQj80-00024y-OG for geopriv@ietf.org; Mon, 12 Mar 2007 07:55:48 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HQj7w-0006iq-0q for geopriv@ietf.org; Mon, 12 Mar 2007 07:55:48 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HQj7q-0008QX-IK; Mon, 12 Mar 2007 06:55:38 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Dawson, Martin'" , "'Hannes Tschofenig'" , Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement Date: Mon, 12 Mar 2007 07:55:35 -0400 Message-ID: <02ea01c7649d$5a643c30$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcdjTsOILWsAysT6RM6RD5gOOmmjpwAO0woQACSEByAAA31kIAActZyA 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: 55503977758b6a5197d8a2b5141eae86 Cc: geopriv@ietf.org, Barbara.Stark@BellSouth.com, lendl@nic.at, andy@hxr.us X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Okay then is there a reason for anything other than "low delay" vs "most accurate"? I see a single bit requirement, but do we really need more = than that? You have misconstrued my last comment. I am observing that a delay parameter is not specific to L7 LCPs. It applies to any LCP that could reasonably be used with a mobile device. In this regard, it is somewhat like signatures, which are not specific to L7 LCPs but apply to them = all. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Sunday, March 11, 2007 6:17 PM > To: Brian Rosen; Dawson, Martin; Hannes Tschofenig; = jerome.grenier@bell.ca > Cc: geopriv@ietf.org; Barbara.Stark@BellSouth.com; lendl@nic.at; > andy@hxr.us > Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement >=20 > I have to disagree with you on almost all counts below Brian, except > possibly with more accurate results are coming more quickly. >=20 > JSTD-036B has specifically move away from the immediate request = scenario > for routing to a low-delay one, as immediate will give you cell only > routing, and low-delay will give you a timing advance solution which > substantially improves accuracy, and hence reduces misroutes. >=20 > Your last comment I think gets to the crux of the matter. You are = thinking > a wireline solution only for the L7 protocol, I am not. I think that = what > we want, and what we are trying to come up with requirements for, is = an > acquisition protocol covers all access networks. So precluding = wireless is > a very significant exclusion. >=20 > Cheers > James >=20 >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Monday, 12 March 2007 7:35 AM > > To: Dawson, Martin; 'Hannes Tschofenig'; jerome.grenier@bell.ca > > Cc: geopriv@ietf.org; Barbara.Stark@BellSouth.com; lendl@nic.at; > > andy@hxr.us > > Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement > > > > Is there really a use for more response time requests that = "immediate" > and > > "eventually"? I certainly don't see any use for more than those two = in > > the > > emergency case (recognizing that current systems don't have any such > > options). I can see "immediate" as needed for call routing, while > > "eventually" is the "get me an accurate fix" that you use to send > > responders. I don't see why anyone would need more than that, and I > think > > the direction of the technology is to moving towards faster accurate > > fixes, > > so the need to have intermediate states is clearly going to go down = over > > time. > > > > I also think this is another case where the requirement doesn't have > > anything to do with L7, although it does seem to have to do with = mobile > > devices. > > > > Brian > > > > > > > > > -----Original Message----- > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > Sent: Saturday, March 10, 2007 10:09 PM > > > To: Hannes Tschofenig; jerome.grenier@bell.ca > > > Cc: geopriv@ietf.org; Barbara.Stark@BellSouth.com; lendl@nic.at; > > > andy@hxr.us > > > Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement > > > > > > Using civic for routing may work in the US where the MSAG is part = of > the > > > legacy infrastructure. In other jurisdictions that I have spoken = with, > > > they would hate to have to develop this just for routing calls. As > such > > a > > > nominal geo associated with fixed wireline access points is also a > > > requirement. Hence the need to be able to get both forms if = possible. > > > > > > There is plenty of demand for a response time parameter and it is = in > the > > > NENA requirements. It has a very valid application in doing = location > > > technology arbitration in wireless location measurement - it is = used > > > already in 2G and 3G location determination. There is nothing in = IP > > > Location that removes this requirement - your opinion not = withstanding > > > being valid as your opinion. > > > > > > Cheers, > > > Martin > > > > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: Sunday, 11 March 2007 7:00 AM > > > To: jerome.grenier@bell.ca > > > Cc: geopriv@ietf.org; Barbara.Stark@BellSouth.com; lendl@nic.at; > > > andy@hxr.us > > > Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement > > > > > > Hi Jerome, > > > > > > jerome.grenier@bell.ca wrote: > > > > I agree with Barbara and would also add : > > > > > > > > - ability to request geo and/or civic location > > > > > > > > > > Barbara previously said that geo-location does not make sense in = the > DSL > > > environment. > > > I guess you are pointing to a different environment. The question = is > > > only: Is the LIS-to-LIS communication needed there as well? > > > > > > > The "ability to specify how quickly a response is needed" would = also > > be > > > really helpful to us. > > > > > > > I don't think that this is useful for this particular application. > > > > > > > Having a BCP (one or more) that recommends a syntax to express > various > > > identifier types for common protocols like SIP/PRES and HTTP would = be > > > great! > > > > > > > > > > > Ciao > > > Hanes > > > > > > > J=E9r=F4me > > > > > > > > -----Message d'origine----- > > > > De : Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > > > > Envoy=E9 : 16 f=E9vrier 2007 10:05 > > > > =C0 : Andrew Newton > > > > Cc : geopriv@ietf.org; Otmar Lendl > > > > Objet : RE: [Geopriv] Geopriv L7 LCP: New Requirement > > > > > > > > I hate to break ranks, but if we could get the user part figured = out > > > > (and I do think we would need some standardization, even if it's > just > > a > > > > BCP), I kind of like this proposed solution. It has a certain > > simplicity > > > > to it. > > > > > > > > Since we've been pushing for these LISs to support LbyR, anyway, = and > > > > this is really just LbyR, I don't see it as being a different > > protocol, > > > > yet again. This is a protocol we'd expect to be supported by a = LIS > in > > > > any case. The only change is that the URI may require careful > parsing > > by > > > > the queried LIS, and the querier LIS needs to support LbyR = queries > in > > > > both directions. > > > > > > > > When I look at the functions in HELD (and RELO has a subset of > these), > > > > and think through which of those functions would I really need = for > > > > LIS-LIS or OBO, I come up with: > > > > - ability to request reference -- not needed, since, as pointed = out, > > > > I've already got a perfectly good non-expiring reference; OBO > querier > > or > > > > LIS doesn't need to ask for references to hand off to others, it > > should > > > > create its own references for that, as appropriate [aside: a > > > > non-expiring reference and a "LCP" are rather equal in the = privacy > > > > debate from the OBO/LIS-LIS perspective.] > > > > - ability to assert location -- not needed for OBO or LIS-LIS; = only > an > > > > end device should be able to do this, if even that is allowed > > > > - ability to provide rules/profile for privacy -- not needed for = OBO > > or > > > > LIS-LIS; only the device should be able to do this > > > > - ability to sign location -- if this is part of PIDF-LO, then = this > is > > > > independent of request mechanism > > > > - ability to request that location be signed -- I think we can > assume > > > > that the location should be signed if it can be signed > > > > - ability to specify how quickly a response is needed -- this = would > be > > > > useful, but it may be possible to design around the issue > > > > - have I missed anything? > > > > > > > > Supporting URI formats other than SIP (e.g., HTTP) would still = need > to > > > > be worked. But that format would be common to all LbyR usages. > > > > This in no way removes the requirement for a device-to-LIS = "LCP". I > > > > haven't read that into the suggestion at all. > > > > > > > > So, I think this idea warrants consideration. > > > > Barbara > > > > > > > > -----Original Message----- > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > Sent: Thursday, February 15, 2007 3:51 PM > > > > To: Stark, Barbara > > > > Cc: geopriv@ietf.org; Otmar Lendl > > > > Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement > > > > > > > > > > > > On Feb 15, 2007, at 12:50 PM, Stark, Barbara wrote: > > > > > > > > > > > >> What is difficult, is figuring out a standard format for a URI = user > > > >> part that would allow for all the variations in combinations of = IDs > > > >> that exist, so that a standard format could be defined that = would > > > >> cover all interconnection models. Section 8 of the NENA = Location > TID > > > >> (http://www.nena.org/media/files/08-505_20061221.pdf) provides = 5 > > > >> different examples of interconnection models, and the IDs that > would > > > >> need to be used in each of these cases. In this document, = scenario > 1 > > > >> uses the IP address, scenario 2 uses NAS-ID and ATM PVC, = scenario 3 > > > >> uses > > > >> 2 VLAN tags, scenario 4 uses IP address, and scenario 5 uses = L2TP > > > >> tunnel ID (source and destination) and PPPoE session ID. These = are > > > >> just 5 possible examples, and should not be considered = exhaustive. > > > >> Interconnection models are still evolving. > > > >> > > > > > > > > Well, that's easily solved with a BCP for formulating URIs based = on > > the > > > > ID. You don't need a new protocol or to conflate the LCP = protocol > > with > > > > this functionality. > > > > > > > > -andy > > > > > > > > ***** > > > > > > > > The information transmitted is intended only for the person or > entity > > to > > > which it is addressed and may contain confidential, proprietary, > and/or > > > privileged material. Any review, retransmission, dissemination or > other > > > use of, or taking of any action in reliance upon this information = by > > > persons or entities other than the intended recipient is = prohibited. > If > > > you received this in error, please contact the sender and delete = the > > > material from all computers. GA621 > > > > > > > > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > = ---------------------------------------------------------------------- > -- > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > = ---------------------------------------------------------------------- > -- > > -- > > > ---------------------- > > > [mf2] > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > = -------------------------------------------------------------------------= - > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > = -------------------------------------------------------------------------= - > ---------------------- > [mf2] _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Mar 12 07:58: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 1HQjAL-00033q-KU; Mon, 12 Mar 2007 07:58:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQjAK-00033h-E1 for geopriv@ietf.org; Mon, 12 Mar 2007 07:58:12 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HQjAC-00071x-O3 for geopriv@ietf.org; Mon, 12 Mar 2007 07:58:12 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HQjAA-0008WN-9e; Mon, 12 Mar 2007 06:58:02 -0500 From: "Brian Rosen" To: "'Thomson, Martin'" , "'Winterbottom, James'" , "'Dawson, Martin'" , "'Hannes Tschofenig'" , Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement Date: Mon, 12 Mar 2007 07:57:59 -0400 Message-ID: <02eb01c7649d$b0146c40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcdjTsOILWsAysT6RM6RD5gOOmmjpwAO0woQACSEByAAA31kIAABjtrQABtHFOA= 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: 2ce306e4307a2c0b518ae453b13efdd0 Cc: geopriv@ietf.org, Barbara.Stark@BellSouth.com, lendl@nic.at, andy@hxr.us X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Sounds reasonable. I would think for routing you would want something = like 500 ms. The usual goal is 2 seconds dial to ring call setup. Using a quarter of that for location seems reasonable. =20 Brian > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Sunday, March 11, 2007 7:03 PM > To: Winterbottom, James; Brian Rosen; Dawson, Martin; Hannes = Tschofenig; > jerome.grenier@bell.ca > Cc: geopriv@ietf.org; Barbara.Stark@BellSouth.com; lendl@nic.at; > andy@hxr.us > Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement >=20 > The problem with the concept of classes of service is that they = require > conventions to define expectations. >=20 > 3GPP (and related) use two categories: "Low Delay" and "Delay = Tolerant". > These would match what Brian has asked for. In practice, these = classes > need to be defined, with reasonable time limits and so forth. No = point > asking for "Low Delay" if your definition is 1 second and the serving = node > thinks 3 seconds is OK. These can be controlled in a closed network - = the > values communicated between all respective nodes. Having a number is > simple and unambiguous. >=20 > Ta, > Martin >=20 > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Monday, 12 March 2007 9:17 AM > > To: Brian Rosen; Dawson, Martin; Hannes Tschofenig; > jerome.grenier@bell.ca > > Cc: geopriv@ietf.org; Barbara.Stark@BellSouth.com; lendl@nic.at; > > andy@hxr.us > > Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement > > > > I have to disagree with you on almost all counts below Brian, except > > possibly with more accurate results are coming more quickly. > > > > JSTD-036B has specifically move away from the immediate request = scenario > > for routing to a low-delay one, as immediate will give you cell only > > routing, and low-delay will give you a timing advance solution which > > substantially improves accuracy, and hence reduces misroutes. > > > > Your last comment I think gets to the crux of the matter. You are > thinking > > a wireline solution only for the L7 protocol, I am not. I think that > what > > we want, and what we are trying to come up with requirements for, is = an > > acquisition protocol covers all access networks. So precluding = wireless > is > > a very significant exclusion. > > > > Cheers > > James > > > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Monday, 12 March 2007 7:35 AM > > > To: Dawson, Martin; 'Hannes Tschofenig'; jerome.grenier@bell.ca > > > Cc: geopriv@ietf.org; Barbara.Stark@BellSouth.com; lendl@nic.at; > > > andy@hxr.us > > > Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement > > > > > > Is there really a use for more response time requests that = "immediate" > > and > > > "eventually"? I certainly don't see any use for more than those = two > in > > > the > > > emergency case (recognizing that current systems don't have any = such > > > options). I can see "immediate" as needed for call routing, while > > > "eventually" is the "get me an accurate fix" that you use to send > > > responders. I don't see why anyone would need more than that, and = I > > think > > > the direction of the technology is to moving towards faster = accurate > > > fixes, > > > so the need to have intermediate states is clearly going to go = down > over > > > time. > > > > > > I also think this is another case where the requirement doesn't = have > > > anything to do with L7, although it does seem to have to do with > mobile > > > devices. > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > Sent: Saturday, March 10, 2007 10:09 PM > > > > To: Hannes Tschofenig; jerome.grenier@bell.ca > > > > Cc: geopriv@ietf.org; Barbara.Stark@BellSouth.com; lendl@nic.at; > > > > andy@hxr.us > > > > Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement > > > > > > > > Using civic for routing may work in the US where the MSAG is = part of > > the > > > > legacy infrastructure. In other jurisdictions that I have spoken > with, > > > > they would hate to have to develop this just for routing calls. = As > > such > > > a > > > > nominal geo associated with fixed wireline access points is also = a > > > > requirement. Hence the need to be able to get both forms if > possible. > > > > > > > > There is plenty of demand for a response time parameter and it = is in > > the > > > > NENA requirements. It has a very valid application in doing = location > > > > technology arbitration in wireless location measurement - it is = used > > > > already in 2G and 3G location determination. There is nothing in = IP > > > > Location that removes this requirement - your opinion not > withstanding > > > > being valid as your opinion. > > > > > > > > Cheers, > > > > Martin > > > > > > > > -----Original Message----- > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > Sent: Sunday, 11 March 2007 7:00 AM > > > > To: jerome.grenier@bell.ca > > > > Cc: geopriv@ietf.org; Barbara.Stark@BellSouth.com; lendl@nic.at; > > > > andy@hxr.us > > > > Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement > > > > > > > > Hi Jerome, > > > > > > > > jerome.grenier@bell.ca wrote: > > > > > I agree with Barbara and would also add : > > > > > > > > > > - ability to request geo and/or civic location > > > > > > > > > > > > > Barbara previously said that geo-location does not make sense in = the > > DSL > > > > environment. > > > > I guess you are pointing to a different environment. The = question is > > > > only: Is the LIS-to-LIS communication needed there as well? > > > > > > > > > The "ability to specify how quickly a response is needed" = would > also > > > be > > > > really helpful to us. > > > > > > > > > I don't think that this is useful for this particular = application. > > > > > > > > > Having a BCP (one or more) that recommends a syntax to express > > various > > > > identifier types for common protocols like SIP/PRES and HTTP = would > be > > > > great! > > > > > > > > > > > > > > Ciao > > > > Hanes > > > > > > > > > J=E9r=F4me > > > > > > > > > > -----Message d'origine----- > > > > > De : Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > > > > > Envoy=E9 : 16 f=E9vrier 2007 10:05 > > > > > =C0 : Andrew Newton > > > > > Cc : geopriv@ietf.org; Otmar Lendl > > > > > Objet : RE: [Geopriv] Geopriv L7 LCP: New Requirement > > > > > > > > > > I hate to break ranks, but if we could get the user part = figured > out > > > > > (and I do think we would need some standardization, even if = it's > > just > > > a > > > > > BCP), I kind of like this proposed solution. It has a certain > > > simplicity > > > > > to it. > > > > > > > > > > Since we've been pushing for these LISs to support LbyR, = anyway, > and > > > > > this is really just LbyR, I don't see it as being a different > > > protocol, > > > > > yet again. This is a protocol we'd expect to be supported by a = LIS > > in > > > > > any case. The only change is that the URI may require careful > > parsing > > > by > > > > > the queried LIS, and the querier LIS needs to support LbyR = queries > > in > > > > > both directions. > > > > > > > > > > When I look at the functions in HELD (and RELO has a subset of > > these), > > > > > and think through which of those functions would I really need = for > > > > > LIS-LIS or OBO, I come up with: > > > > > - ability to request reference -- not needed, since, as = pointed > out, > > > > > I've already got a perfectly good non-expiring reference; OBO > > querier > > > or > > > > > LIS doesn't need to ask for references to hand off to others, = it > > > should > > > > > create its own references for that, as appropriate [aside: a > > > > > non-expiring reference and a "LCP" are rather equal in the = privacy > > > > > debate from the OBO/LIS-LIS perspective.] > > > > > - ability to assert location -- not needed for OBO or LIS-LIS; > only > > an > > > > > end device should be able to do this, if even that is allowed > > > > > - ability to provide rules/profile for privacy -- not needed = for > OBO > > > or > > > > > LIS-LIS; only the device should be able to do this > > > > > - ability to sign location -- if this is part of PIDF-LO, then > this > > is > > > > > independent of request mechanism > > > > > - ability to request that location be signed -- I think we can > > assume > > > > > that the location should be signed if it can be signed > > > > > - ability to specify how quickly a response is needed -- this > would > > be > > > > > useful, but it may be possible to design around the issue > > > > > - have I missed anything? > > > > > > > > > > Supporting URI formats other than SIP (e.g., HTTP) would still > need > > to > > > > > be worked. But that format would be common to all LbyR usages. > > > > > This in no way removes the requirement for a device-to-LIS = "LCP". > I > > > > > haven't read that into the suggestion at all. > > > > > > > > > > So, I think this idea warrants consideration. > > > > > Barbara > > > > > > > > > > -----Original Message----- > > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > > Sent: Thursday, February 15, 2007 3:51 PM > > > > > To: Stark, Barbara > > > > > Cc: geopriv@ietf.org; Otmar Lendl > > > > > Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement > > > > > > > > > > > > > > > On Feb 15, 2007, at 12:50 PM, Stark, Barbara wrote: > > > > > > > > > > > > > > >> What is difficult, is figuring out a standard format for a = URI > user > > > > >> part that would allow for all the variations in combinations = of > IDs > > > > >> that exist, so that a standard format could be defined that = would > > > > >> cover all interconnection models. Section 8 of the NENA = Location > > TID > > > > >> (http://www.nena.org/media/files/08-505_20061221.pdf) = provides 5 > > > > >> different examples of interconnection models, and the IDs = that > > would > > > > >> need to be used in each of these cases. In this document, > scenario > > 1 > > > > >> uses the IP address, scenario 2 uses NAS-ID and ATM PVC, = scenario > 3 > > > > >> uses > > > > >> 2 VLAN tags, scenario 4 uses IP address, and scenario 5 uses = L2TP > > > > >> tunnel ID (source and destination) and PPPoE session ID. = These > are > > > > >> just 5 possible examples, and should not be considered > exhaustive. > > > > >> Interconnection models are still evolving. > > > > >> > > > > > > > > > > Well, that's easily solved with a BCP for formulating URIs = based > on > > > the > > > > > ID. You don't need a new protocol or to conflate the LCP = protocol > > > with > > > > > this functionality. > > > > > > > > > > -andy > > > > > > > > > > ***** > > > > > > > > > > The information transmitted is intended only for the person or > > entity > > > to > > > > which it is addressed and may contain confidential, proprietary, > > and/or > > > > privileged material. Any review, retransmission, dissemination = or > > other > > > > use of, or taking of any action in reliance upon this = information by > > > > persons or entities other than the intended recipient is = prohibited. > > If > > > > you received this in error, please contact the sender and delete = the > > > > material from all computers. GA621 > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Geopriv mailing list > > > > > Geopriv@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > _______________________________________________ > > > > > Geopriv mailing list > > > > > Geopriv@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > = -------------------------------------------------------------------- > -- > > -- > > > -- > > > > ---------------------- > > > > This message is for the designated recipient only and may > > > > contain privileged, proprietary, or otherwise private = information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized use of > > > > this email is prohibited. > > > > = -------------------------------------------------------------------- > -- > > -- > > > -- > > > > ---------------------- > > > > [mf2] > > > > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > = ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > = ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > = -------------------------------------------------------------------------= - > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > = -------------------------------------------------------------------------= - > ---------------------- > [mf2] _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Mar 12 11:49: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 1HQmmR-0005h7-Qa; Mon, 12 Mar 2007 11:49:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQmmQ-0005go-Nv for geopriv@ietf.org; Mon, 12 Mar 2007 11:49:46 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQmmP-0001EW-E9 for geopriv@ietf.org; Mon, 12 Mar 2007 11:49:46 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 12 Mar 2007 11:49:45 -0400 X-IronPort-AV: i="4.14,275,1170651600"; d="scan'208"; a="54519062:sNHT41250464" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2CFnjYc000993; Mon, 12 Mar 2007 11:49:45 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2CFnjZn019425; Mon, 12 Mar 2007 15:49:45 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 11:49:44 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 11:49:43 -0400 From: "Marc Linsner" To: "'Dawson, Martin'" Subject: RE: [Geopriv] NENA Requirements Date: Mon, 12 Mar 2007 11:49:47 -0400 Message-ID: <01cc01c764be$1063d390$230d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcdjTeBAtyKST3eMTvyeug/JBnGIcwAOsaoAAE1BBKA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 12 Mar 2007 15:49:44.0040 (UTC) FILETIME=[0DBCF680:01C764BE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=301; t=1173714585; x=1174578585; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20NENA=20Requirements |Sender:=20 |To:=20=22'Dawson,=20Martin'=22=20; bh=wGgFlr3iFW9ff6xScVo48PxXfZqNNBLeraKDxS/kFPg=; b=GTH5ExZ3/RQvW3GfO/UP0LjqvTeWSwtSWbwYesoP3dNSZLuAlU3DKEw46nkgsRRtzWv5aphZ ukO2UHnANFPJA7OgQD1kYqywfJEMSitxGMc32i1WlKZx1YS/jRDg5dw0; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Martin, > > I think all of the NENA requirements have been raised and > discussed - the latest concept to cause indigestion is > location signing. You have requirements mixed up with solutions. Signing location objects is a solution. I believe Ted nailed the requirement. -Marc- _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Mar 12 17:28: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 1HQs4A-0000si-0r; Mon, 12 Mar 2007 17:28:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQs48-0000sK-Dy for geopriv@ietf.org; Mon, 12 Mar 2007 17:28:24 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQs44-0005R5-FU for geopriv@ietf.org; Mon, 12 Mar 2007 17:28:24 -0400 X-SEF-Processed: 5_0_0_910__2007_03_12_16_34_15 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, 12 Mar 2007 16:34:15 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 16:28:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement Date: Mon, 12 Mar 2007 16:28:15 -0500 Message-ID: In-Reply-To: <02eb01c7649d$b0146c40$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Geopriv L7 LCP: New Requirement Thread-Index: AcdjTsOILWsAysT6RM6RD5gOOmmjpwAO0woQACSEByAAA31kIAABjtrQABtHFOAAE9jJsA== From: "Thomson, Martin" To: "Brian Rosen" X-OriginalArrivalTime: 12 Mar 2007 21:28:18.0153 (UTC) FILETIME=[59E49D90:01C764ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2023601858==" Errors-To: geopriv-bounces@ietf.org --===============2023601858== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCB3b3VsZCBiZSBhIHJlYXNvbmFibGUgc3RhcnRpbmcgcG9pbnQuICBPZiBjb3Vyc2UsIGlm IHlvdSBwdXQgaXQgaW4gdGhlIHByb3RvY29sLCB0aGVuIHRoZSBVQSB2ZW5kb3IgY2FuIG1ha2Ug dGhvc2UgZGVjaXNpb25zIGJhc2VkIG9uIHRlc3RpbmcgYW5kIG90aGVyIGNvbnN0cmFpbnRzIHRo YXQgdGhleSBoYXZlLiAgU29tZSBtYXkgb3B0IGZvciBsb3dlciBvciBoaWdoZXIgYmFzZWQgb24g dGhlaXIgZXhwZXJpZW5jZS4NCg0KQW5kLCBhcyB5b3Ugc2FpZCwgdGhpcyBjb3VsZCBhcHBseSB0 byBhbGwgY29uZmlndXJhdGlvbiBwcm90b2NvbHMsIGxvY2F0aW9uIG9yIG90aGVyd2lzZS4gIE9u IHRoZSBvdGhlciBoYW5kLCBzaW5jZSBtYW55IG9mIHRob3NlIGNhbiBiZSBydW4gYmVmb3JlIGNh bGwtc2V0dXAgdGltZSwgdGhlcmUgaXMgbGVzcyBvZiBhbiBpbXBlcmF0aXZlLg0KDQpDaGVlcnMs DQpNYXJ0aW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBS b3NlbiBbbWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0XQ0KPiBTZW50OiBNb25kYXksIDEyIE1hcmNo IDIwMDcgMTA6NTggUE0NCj4gVG86IFRob21zb24sIE1hcnRpbjsgV2ludGVyYm90dG9tLCBKYW1l czsgRGF3c29uLCBNYXJ0aW47ICdIYW5uZXMNCj4gVHNjaG9mZW5pZyc7IGplcm9tZS5ncmVuaWVy QGJlbGwuY2ENCj4gQ2M6IGdlb3ByaXZAaWV0Zi5vcmc7IEJhcmJhcmEuU3RhcmtAQmVsbFNvdXRo LmNvbTsgbGVuZGxAbmljLmF0Ow0KPiBhbmR5QGh4ci51cw0KPiBTdWJqZWN0OiBSRTogW0dlb3By aXZdIEdlb3ByaXYgTDcgTENQOiBOZXcgUmVxdWlyZW1lbnQNCj4gDQo+IFNvdW5kcyByZWFzb25h YmxlLiAgSSB3b3VsZCB0aGluayBmb3Igcm91dGluZyB5b3Ugd291bGQgd2FudCBzb21ldGhpbmcN Cj4gbGlrZQ0KPiA1MDAgbXMuICBUaGUgdXN1YWwgZ29hbCBpcyAyIHNlY29uZHMgZGlhbCB0byBy aW5nIGNhbGwgc2V0dXAuICBVc2luZyBhDQo+IHF1YXJ0ZXIgb2YgdGhhdCBmb3IgbG9jYXRpb24g c2VlbXMgcmVhc29uYWJsZS4NCj4gDQo+IEJyaWFuDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gRnJvbTogVGhvbXNvbiwgTWFydGluIFttYWlsdG86TWFydGluLlRob21z b25AYW5kcmV3LmNvbV0NCj4gPiBTZW50OiBTdW5kYXksIE1hcmNoIDExLCAyMDA3IDc6MDMgUE0N Cj4gPiBUbzogV2ludGVyYm90dG9tLCBKYW1lczsgQnJpYW4gUm9zZW47IERhd3NvbiwgTWFydGlu OyBIYW5uZXMgVHNjaG9mZW5pZzsNCj4gPiBqZXJvbWUuZ3JlbmllckBiZWxsLmNhDQo+ID4gQ2M6 IGdlb3ByaXZAaWV0Zi5vcmc7IEJhcmJhcmEuU3RhcmtAQmVsbFNvdXRoLmNvbTsgbGVuZGxAbmlj LmF0Ow0KPiA+IGFuZHlAaHhyLnVzDQo+ID4gU3ViamVjdDogUkU6IFtHZW9wcml2XSBHZW9wcml2 IEw3IExDUDogTmV3IFJlcXVpcmVtZW50DQo+ID4NCj4gPiBUaGUgcHJvYmxlbSB3aXRoIHRoZSBj b25jZXB0IG9mIGNsYXNzZXMgb2Ygc2VydmljZSBpcyB0aGF0IHRoZXkgcmVxdWlyZQ0KPiA+IGNv bnZlbnRpb25zIHRvIGRlZmluZSBleHBlY3RhdGlvbnMuDQo+ID4NCj4gPiAzR1BQIChhbmQgcmVs YXRlZCkgdXNlIHR3byBjYXRlZ29yaWVzOiAiTG93IERlbGF5IiBhbmQgIkRlbGF5IFRvbGVyYW50 Ii4NCj4gPiBUaGVzZSB3b3VsZCBtYXRjaCB3aGF0IEJyaWFuIGhhcyBhc2tlZCBmb3IuICBJbiBw cmFjdGljZSwgdGhlc2UgY2xhc3Nlcw0KPiA+IG5lZWQgdG8gYmUgZGVmaW5lZCwgd2l0aCByZWFz b25hYmxlIHRpbWUgbGltaXRzIGFuZCBzbyBmb3J0aC4gIE5vIHBvaW50DQo+ID4gYXNraW5nIGZv ciAiTG93IERlbGF5IiBpZiB5b3VyIGRlZmluaXRpb24gaXMgMSBzZWNvbmQgYW5kIHRoZSBzZXJ2 aW5nDQo+IG5vZGUNCj4gPiB0aGlua3MgMyBzZWNvbmRzIGlzIE9LLiAgVGhlc2UgY2FuIGJlIGNv bnRyb2xsZWQgaW4gYSBjbG9zZWQgbmV0d29yayAtDQo+IHRoZQ0KPiA+IHZhbHVlcyBjb21tdW5p Y2F0ZWQgYmV0d2VlbiBhbGwgcmVzcGVjdGl2ZSBub2Rlcy4gIEhhdmluZyBhIG51bWJlciBpcw0K PiA+IHNpbXBsZSBhbmQgdW5hbWJpZ3VvdXMuDQo+ID4NCj4gPiBUYSwNCj4gPiBNYXJ0aW4NCj4g Pg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IFdpbnRlcmJv dHRvbSwgSmFtZXMgW21haWx0bzpKYW1lcy5XaW50ZXJib3R0b21AYW5kcmV3LmNvbV0NCj4gPiA+ IFNlbnQ6IE1vbmRheSwgMTIgTWFyY2ggMjAwNyA5OjE3IEFNDQo+ID4gPiBUbzogQnJpYW4gUm9z ZW47IERhd3NvbiwgTWFydGluOyBIYW5uZXMgVHNjaG9mZW5pZzsNCj4gPiBqZXJvbWUuZ3Jlbmll ckBiZWxsLmNhDQo+ID4gPiBDYzogZ2VvcHJpdkBpZXRmLm9yZzsgQmFyYmFyYS5TdGFya0BCZWxs U291dGguY29tOyBsZW5kbEBuaWMuYXQ7DQo+ID4gPiBhbmR5QGh4ci51cw0KPiA+ID4gU3ViamVj dDogUkU6IFtHZW9wcml2XSBHZW9wcml2IEw3IExDUDogTmV3IFJlcXVpcmVtZW50DQo+ID4gPg0K PiA+ID4gSSBoYXZlIHRvIGRpc2FncmVlIHdpdGggeW91IG9uIGFsbW9zdCBhbGwgY291bnRzIGJl bG93IEJyaWFuLCBleGNlcHQNCj4gPiA+IHBvc3NpYmx5IHdpdGggbW9yZSBhY2N1cmF0ZSByZXN1 bHRzIGFyZSBjb21pbmcgbW9yZSBxdWlja2x5Lg0KPiA+ID4NCj4gPiA+IEpTVEQtMDM2QiBoYXMg c3BlY2lmaWNhbGx5IG1vdmUgYXdheSBmcm9tIHRoZSBpbW1lZGlhdGUgcmVxdWVzdA0KPiBzY2Vu YXJpbw0KPiA+ID4gZm9yIHJvdXRpbmcgdG8gYSBsb3ctZGVsYXkgb25lLCBhcyBpbW1lZGlhdGUg d2lsbCBnaXZlIHlvdSBjZWxsIG9ubHkNCj4gPiA+IHJvdXRpbmcsIGFuZCBsb3ctZGVsYXkgd2ls bCBnaXZlIHlvdSBhIHRpbWluZyBhZHZhbmNlIHNvbHV0aW9uIHdoaWNoDQo+ID4gPiBzdWJzdGFu dGlhbGx5IGltcHJvdmVzIGFjY3VyYWN5LCBhbmQgaGVuY2UgcmVkdWNlcyBtaXNyb3V0ZXMuDQo+ ID4gPg0KPiA+ID4gWW91ciBsYXN0IGNvbW1lbnQgSSB0aGluayBnZXRzIHRvIHRoZSBjcnV4IG9m IHRoZSBtYXR0ZXIuIFlvdSBhcmUNCj4gPiB0aGlua2luZw0KPiA+ID4gYSB3aXJlbGluZSBzb2x1 dGlvbiBvbmx5IGZvciB0aGUgTDcgcHJvdG9jb2wsIEkgYW0gbm90LiBJIHRoaW5rIHRoYXQNCj4g PiB3aGF0DQo+ID4gPiB3ZSB3YW50LCBhbmQgd2hhdCB3ZSBhcmUgdHJ5aW5nIHRvIGNvbWUgdXAg d2l0aCByZXF1aXJlbWVudHMgZm9yLCBpcw0KPiBhbg0KPiA+ID4gYWNxdWlzaXRpb24gcHJvdG9j b2wgY292ZXJzIGFsbCBhY2Nlc3MgbmV0d29ya3MuIFNvIHByZWNsdWRpbmcNCj4gd2lyZWxlc3MN Cj4gPiBpcw0KPiA+ID4gYSB2ZXJ5IHNpZ25pZmljYW50IGV4Y2x1c2lvbi4NCj4gPiA+DQo+ID4g PiBDaGVlcnMNCj4gPiA+IEphbWVzDQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiA+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+IEZyb206IEJyaWFuIFJvc2VuIFttYWlsdG86 YnJAYnJpYW5yb3Nlbi5uZXRdDQo+ID4gPiA+IFNlbnQ6IE1vbmRheSwgMTIgTWFyY2ggMjAwNyA3 OjM1IEFNDQo+ID4gPiA+IFRvOiBEYXdzb24sIE1hcnRpbjsgJ0hhbm5lcyBUc2Nob2ZlbmlnJzsg amVyb21lLmdyZW5pZXJAYmVsbC5jYQ0KPiA+ID4gPiBDYzogZ2VvcHJpdkBpZXRmLm9yZzsgQmFy YmFyYS5TdGFya0BCZWxsU291dGguY29tOyBsZW5kbEBuaWMuYXQ7DQo+ID4gPiA+IGFuZHlAaHhy LnVzDQo+ID4gPiA+IFN1YmplY3Q6IFJFOiBbR2VvcHJpdl0gR2VvcHJpdiBMNyBMQ1A6IE5ldyBS ZXF1aXJlbWVudA0KPiA+ID4gPg0KPiA+ID4gPiBJcyB0aGVyZSByZWFsbHkgYSB1c2UgZm9yIG1v cmUgcmVzcG9uc2UgdGltZSByZXF1ZXN0cyB0aGF0DQo+ICJpbW1lZGlhdGUiDQo+ID4gPiBhbmQN Cj4gPiA+ID4gImV2ZW50dWFsbHkiPyAgSSBjZXJ0YWlubHkgZG9uJ3Qgc2VlIGFueSB1c2UgZm9y IG1vcmUgdGhhbiB0aG9zZSB0d28NCj4gPiBpbg0KPiA+ID4gPiB0aGUNCj4gPiA+ID4gZW1lcmdl bmN5IGNhc2UgKHJlY29nbml6aW5nIHRoYXQgY3VycmVudCBzeXN0ZW1zIGRvbid0IGhhdmUgYW55 IHN1Y2gNCj4gPiA+ID4gb3B0aW9ucykuICBJIGNhbiBzZWUgImltbWVkaWF0ZSIgYXMgbmVlZGVk IGZvciBjYWxsIHJvdXRpbmcsIHdoaWxlDQo+ID4gPiA+ICJldmVudHVhbGx5IiBpcyB0aGUgImdl dCBtZSBhbiBhY2N1cmF0ZSBmaXgiIHRoYXQgeW91IHVzZSB0byBzZW5kDQo+ID4gPiA+IHJlc3Bv bmRlcnMuICBJIGRvbid0IHNlZSB3aHkgYW55b25lIHdvdWxkIG5lZWQgbW9yZSB0aGFuIHRoYXQs IGFuZCBJDQo+ID4gPiB0aGluaw0KPiA+ID4gPiB0aGUgZGlyZWN0aW9uIG9mIHRoZSB0ZWNobm9s b2d5IGlzIHRvIG1vdmluZyB0b3dhcmRzIGZhc3RlciBhY2N1cmF0ZQ0KPiA+ID4gPiBmaXhlcywN Cj4gPiA+ID4gc28gdGhlIG5lZWQgdG8gaGF2ZSBpbnRlcm1lZGlhdGUgc3RhdGVzIGlzIGNsZWFy bHkgZ29pbmcgdG8gZ28gZG93bg0KPiA+IG92ZXINCj4gPiA+ID4gdGltZS4NCj4gPiA+ID4NCj4g PiA+ID4gSSBhbHNvIHRoaW5rIHRoaXMgaXMgYW5vdGhlciBjYXNlIHdoZXJlIHRoZSByZXF1aXJl bWVudCBkb2Vzbid0IGhhdmUNCj4gPiA+ID4gYW55dGhpbmcgdG8gZG8gd2l0aCBMNywgYWx0aG91 Z2ggaXQgZG9lcyBzZWVtIHRvIGhhdmUgdG8gZG8gd2l0aA0KPiA+IG1vYmlsZQ0KPiA+ID4gPiBk ZXZpY2VzLg0KPiA+ID4gPg0KPiA+ID4gPiBCcmlhbg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4g Pg0KPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gRnJvbTog RGF3c29uLCBNYXJ0aW4gW21haWx0bzpNYXJ0aW4uRGF3c29uQGFuZHJldy5jb21dDQo+ID4gPiA+ ID4gU2VudDogU2F0dXJkYXksIE1hcmNoIDEwLCAyMDA3IDEwOjA5IFBNDQo+ID4gPiA+ID4gVG86 IEhhbm5lcyBUc2Nob2ZlbmlnOyBqZXJvbWUuZ3JlbmllckBiZWxsLmNhDQo+ID4gPiA+ID4gQ2M6 IGdlb3ByaXZAaWV0Zi5vcmc7IEJhcmJhcmEuU3RhcmtAQmVsbFNvdXRoLmNvbTsgbGVuZGxAbmlj LmF0Ow0KPiA+ID4gPiA+IGFuZHlAaHhyLnVzDQo+ID4gPiA+ID4gU3ViamVjdDogUkU6IFtHZW9w cml2XSBHZW9wcml2IEw3IExDUDogTmV3IFJlcXVpcmVtZW50DQo+ID4gPiA+ID4NCj4gPiA+ID4g PiBVc2luZyBjaXZpYyBmb3Igcm91dGluZyBtYXkgd29yayBpbiB0aGUgVVMgd2hlcmUgdGhlIE1T QUcgaXMgcGFydA0KPiBvZg0KPiA+ID4gdGhlDQo+ID4gPiA+ID4gbGVnYWN5IGluZnJhc3RydWN0 dXJlLiBJbiBvdGhlciBqdXJpc2RpY3Rpb25zIHRoYXQgSSBoYXZlIHNwb2tlbg0KPiA+IHdpdGgs DQo+ID4gPiA+ID4gdGhleSB3b3VsZCBoYXRlIHRvIGhhdmUgdG8gZGV2ZWxvcCB0aGlzIGp1c3Qg Zm9yIHJvdXRpbmcgY2FsbHMuIEFzDQo+ID4gPiBzdWNoDQo+ID4gPiA+IGENCj4gPiA+ID4gPiBu b21pbmFsIGdlbyBhc3NvY2lhdGVkIHdpdGggZml4ZWQgd2lyZWxpbmUgYWNjZXNzIHBvaW50cyBp cyBhbHNvIGENCj4gPiA+ID4gPiByZXF1aXJlbWVudC4gSGVuY2UgdGhlIG5lZWQgdG8gYmUgYWJs ZSB0byBnZXQgYm90aCBmb3JtcyBpZg0KPiA+IHBvc3NpYmxlLg0KPiA+ID4gPiA+DQo+ID4gPiA+ ID4gVGhlcmUgaXMgcGxlbnR5IG9mIGRlbWFuZCBmb3IgYSByZXNwb25zZSB0aW1lIHBhcmFtZXRl ciBhbmQgaXQgaXMNCj4gaW4NCj4gPiA+IHRoZQ0KPiA+ID4gPiA+IE5FTkEgcmVxdWlyZW1lbnRz LiBJdCBoYXMgYSB2ZXJ5IHZhbGlkIGFwcGxpY2F0aW9uIGluIGRvaW5nDQo+IGxvY2F0aW9uDQo+ ID4gPiA+ID4gdGVjaG5vbG9neSBhcmJpdHJhdGlvbiBpbiB3aXJlbGVzcyBsb2NhdGlvbiBtZWFz dXJlbWVudCAtIGl0IGlzDQo+IHVzZWQNCj4gPiA+ID4gPiBhbHJlYWR5IGluIDJHIGFuZCAzRyBs b2NhdGlvbiBkZXRlcm1pbmF0aW9uLiBUaGVyZSBpcyBub3RoaW5nIGluDQo+IElQDQo+ID4gPiA+ ID4gTG9jYXRpb24gdGhhdCByZW1vdmVzIHRoaXMgcmVxdWlyZW1lbnQgLSB5b3VyIG9waW5pb24g bm90DQo+ID4gd2l0aHN0YW5kaW5nDQo+ID4gPiA+ID4gYmVpbmcgdmFsaWQgYXMgeW91ciBvcGlu aW9uLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQ2hlZXJzLA0KPiA+ID4gPiA+IE1hcnRpbg0KPiA+ ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiBG cm9tOiBIYW5uZXMgVHNjaG9mZW5pZyBbbWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXRd DQo+ID4gPiA+ID4gU2VudDogU3VuZGF5LCAxMSBNYXJjaCAyMDA3IDc6MDAgQU0NCj4gPiA+ID4g PiBUbzogamVyb21lLmdyZW5pZXJAYmVsbC5jYQ0KPiA+ID4gPiA+IENjOiBnZW9wcml2QGlldGYu b3JnOyBCYXJiYXJhLlN0YXJrQEJlbGxTb3V0aC5jb207IGxlbmRsQG5pYy5hdDsNCj4gPiA+ID4g PiBhbmR5QGh4ci51cw0KPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbR2VvcHJpdl0gR2VvcHJpdiBM NyBMQ1A6IE5ldyBSZXF1aXJlbWVudA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSGkgSmVyb21lLA0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gamVyb21lLmdyZW5pZXJAYmVsbC5jYSB3cm90ZToNCj4gPiA+ ID4gPiA+IEkgYWdyZWUgd2l0aCBCYXJiYXJhIGFuZCB3b3VsZCBhbHNvIGFkZCA6DQo+ID4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4gLSBhYmlsaXR5IHRvIHJlcXVlc3QgZ2VvIGFuZC9vciBjaXZpYyBs b2NhdGlvbg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEJhcmJhcmEgcHJldmlv dXNseSBzYWlkIHRoYXQgZ2VvLWxvY2F0aW9uIGRvZXMgbm90IG1ha2Ugc2Vuc2UgaW4NCj4gdGhl DQo+ID4gPiBEU0wNCj4gPiA+ID4gPiBlbnZpcm9ubWVudC4NCj4gPiA+ID4gPiBJIGd1ZXNzIHlv dSBhcmUgcG9pbnRpbmcgdG8gYSBkaWZmZXJlbnQgZW52aXJvbm1lbnQuIFRoZSBxdWVzdGlvbg0K PiBpcw0KPiA+ID4gPiA+IG9ubHk6IElzIHRoZSBMSVMtdG8tTElTIGNvbW11bmljYXRpb24gbmVl ZGVkIHRoZXJlIGFzIHdlbGw/DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFRoZSAiYWJpbGl0eSB0 byBzcGVjaWZ5IGhvdyBxdWlja2x5IGEgcmVzcG9uc2UgaXMgbmVlZGVkIiB3b3VsZA0KPiA+IGFs c28NCj4gPiA+ID4gYmUNCj4gPiA+ID4gPiByZWFsbHkgaGVscGZ1bCB0byB1cy4NCj4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gSSBkb24ndCB0aGluayB0aGF0IHRoaXMgaXMgdXNlZnVsIGZvciB0aGlz IHBhcnRpY3VsYXIgYXBwbGljYXRpb24uDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEhhdmluZyBh IEJDUCAob25lIG9yIG1vcmUpIHRoYXQgcmVjb21tZW5kcyBhIHN5bnRheCB0byBleHByZXNzDQo+ ID4gPiB2YXJpb3VzDQo+ID4gPiA+ID4gaWRlbnRpZmllciB0eXBlcyBmb3IgY29tbW9uIHByb3Rv Y29scyBsaWtlIFNJUC9QUkVTIGFuZCBIVFRQIHdvdWxkDQo+ID4gYmUNCj4gPiA+ID4gPiBncmVh dCENCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+IENpYW8NCj4gPiA+ID4gPiBI YW5lcw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBKw6lyw7RtZQ0KPiA+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ID4gPiA+ID4gRGUgOiBTdGFy aywgQmFyYmFyYSBbbWFpbHRvOkJhcmJhcmEuU3RhcmtAQmVsbFNvdXRoLmNvbV0NCj4gPiA+ID4g PiA+IEVudm95w6kgOiAxNiBmw6l2cmllciAyMDA3IDEwOjA1DQo+ID4gPiA+ID4gPiDDgCA6IEFu ZHJldyBOZXd0b24NCj4gPiA+ID4gPiA+IENjIDogZ2VvcHJpdkBpZXRmLm9yZzsgT3RtYXIgTGVu ZGwNCj4gPiA+ID4gPiA+IE9iamV0IDogUkU6IFtHZW9wcml2XSBHZW9wcml2IEw3IExDUDogTmV3 IFJlcXVpcmVtZW50DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSSBoYXRlIHRvIGJyZWFrIHJh bmtzLCBidXQgaWYgd2UgY291bGQgZ2V0IHRoZSB1c2VyIHBhcnQgZmlndXJlZA0KPiA+IG91dA0K PiA+ID4gPiA+ID4gKGFuZCBJIGRvIHRoaW5rIHdlIHdvdWxkIG5lZWQgc29tZSBzdGFuZGFyZGl6 YXRpb24sIGV2ZW4gaWYgaXQncw0KPiA+ID4ganVzdA0KPiA+ID4gPiBhDQo+ID4gPiA+ID4gPiBC Q1ApLCBJIGtpbmQgb2YgbGlrZSB0aGlzIHByb3Bvc2VkIHNvbHV0aW9uLiBJdCBoYXMgYSBjZXJ0 YWluDQo+ID4gPiA+IHNpbXBsaWNpdHkNCj4gPiA+ID4gPiA+IHRvIGl0Lg0KPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+IFNpbmNlIHdlJ3ZlIGJlZW4gcHVzaGluZyBmb3IgdGhlc2UgTElTcyB0byBz dXBwb3J0IExieVIsIGFueXdheSwNCj4gPiBhbmQNCj4gPiA+ID4gPiA+IHRoaXMgaXMgcmVhbGx5 IGp1c3QgTGJ5UiwgSSBkb24ndCBzZWUgaXQgYXMgYmVpbmcgYSBkaWZmZXJlbnQNCj4gPiA+ID4g cHJvdG9jb2wsDQo+ID4gPiA+ID4gPiB5ZXQgYWdhaW4uIFRoaXMgaXMgYSBwcm90b2NvbCB3ZSdk IGV4cGVjdCB0byBiZSBzdXBwb3J0ZWQgYnkgYQ0KPiBMSVMNCj4gPiA+IGluDQo+ID4gPiA+ID4g PiBhbnkgY2FzZS4gVGhlIG9ubHkgY2hhbmdlIGlzIHRoYXQgdGhlIFVSSSBtYXkgcmVxdWlyZSBj YXJlZnVsDQo+ID4gPiBwYXJzaW5nDQo+ID4gPiA+IGJ5DQo+ID4gPiA+ID4gPiB0aGUgcXVlcmll ZCBMSVMsIGFuZCB0aGUgcXVlcmllciBMSVMgbmVlZHMgdG8gc3VwcG9ydCBMYnlSDQo+IHF1ZXJp ZXMNCj4gPiA+IGluDQo+ID4gPiA+ID4gPiBib3RoIGRpcmVjdGlvbnMuDQo+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gV2hlbiBJIGxvb2sgYXQgdGhlIGZ1bmN0aW9ucyBpbiBIRUxEIChhbmQgUkVM TyBoYXMgYSBzdWJzZXQgb2YNCj4gPiA+IHRoZXNlKSwNCj4gPiA+ID4gPiA+IGFuZCB0aGluayB0 aHJvdWdoIHdoaWNoIG9mIHRob3NlIGZ1bmN0aW9ucyB3b3VsZCBJIHJlYWxseSBuZWVkDQo+IGZv cg0KPiA+ID4gPiA+ID4gTElTLUxJUyBvciBPQk8sIEkgY29tZSB1cCB3aXRoOg0KPiA+ID4gPiA+ ID4gLSBhYmlsaXR5IHRvIHJlcXVlc3QgcmVmZXJlbmNlIC0tIG5vdCBuZWVkZWQsIHNpbmNlLCBh cyBwb2ludGVkDQo+ID4gb3V0LA0KPiA+ID4gPiA+ID4gSSd2ZSBhbHJlYWR5IGdvdCBhIHBlcmZl Y3RseSBnb29kIG5vbi1leHBpcmluZyByZWZlcmVuY2U7IE9CTw0KPiA+ID4gcXVlcmllcg0KPiA+ ID4gPiBvcg0KPiA+ID4gPiA+ID4gTElTIGRvZXNuJ3QgbmVlZCB0byBhc2sgZm9yIHJlZmVyZW5j ZXMgdG8gaGFuZCBvZmYgdG8gb3RoZXJzLCBpdA0KPiA+ID4gPiBzaG91bGQNCj4gPiA+ID4gPiA+ IGNyZWF0ZSBpdHMgb3duIHJlZmVyZW5jZXMgZm9yIHRoYXQsIGFzIGFwcHJvcHJpYXRlIFthc2lk ZTogYQ0KPiA+ID4gPiA+ID4gbm9uLWV4cGlyaW5nIHJlZmVyZW5jZSBhbmQgYSAiTENQIiBhcmUg cmF0aGVyIGVxdWFsIGluIHRoZQ0KPiBwcml2YWN5DQo+ID4gPiA+ID4gPiBkZWJhdGUgZnJvbSB0 aGUgT0JPL0xJUy1MSVMgcGVyc3BlY3RpdmUuXQ0KPiA+ID4gPiA+ID4gLSBhYmlsaXR5IHRvIGFz c2VydCBsb2NhdGlvbiAtLSBub3QgbmVlZGVkIGZvciBPQk8gb3IgTElTLUxJUzsNCj4gPiBvbmx5 DQo+ID4gPiBhbg0KPiA+ID4gPiA+ID4gZW5kIGRldmljZSBzaG91bGQgYmUgYWJsZSB0byBkbyB0 aGlzLCBpZiBldmVuIHRoYXQgaXMgYWxsb3dlZA0KPiA+ID4gPiA+ID4gLSBhYmlsaXR5IHRvIHBy b3ZpZGUgcnVsZXMvcHJvZmlsZSBmb3IgcHJpdmFjeSAtLSBub3QgbmVlZGVkIGZvcg0KPiA+IE9C Tw0KPiA+ID4gPiBvcg0KPiA+ID4gPiA+ID4gTElTLUxJUzsgb25seSB0aGUgZGV2aWNlIHNob3Vs ZCBiZSBhYmxlIHRvIGRvIHRoaXMNCj4gPiA+ID4gPiA+IC0gYWJpbGl0eSB0byBzaWduIGxvY2F0 aW9uIC0tIGlmIHRoaXMgaXMgcGFydCBvZiBQSURGLUxPLCB0aGVuDQo+ID4gdGhpcw0KPiA+ID4g aXMNCj4gPiA+ID4gPiA+IGluZGVwZW5kZW50IG9mIHJlcXVlc3QgbWVjaGFuaXNtDQo+ID4gPiA+ ID4gPiAtIGFiaWxpdHkgdG8gcmVxdWVzdCB0aGF0IGxvY2F0aW9uIGJlIHNpZ25lZCAtLSBJIHRo aW5rIHdlIGNhbg0KPiA+ID4gYXNzdW1lDQo+ID4gPiA+ID4gPiB0aGF0IHRoZSBsb2NhdGlvbiBz aG91bGQgYmUgc2lnbmVkIGlmIGl0IGNhbiBiZSBzaWduZWQNCj4gPiA+ID4gPiA+IC0gYWJpbGl0 eSB0byBzcGVjaWZ5IGhvdyBxdWlja2x5IGEgcmVzcG9uc2UgaXMgbmVlZGVkIC0tIHRoaXMNCj4g PiB3b3VsZA0KPiA+ID4gYmUNCj4gPiA+ID4gPiA+IHVzZWZ1bCwgYnV0IGl0IG1heSBiZSBwb3Nz aWJsZSB0byBkZXNpZ24gYXJvdW5kIHRoZSBpc3N1ZQ0KPiA+ID4gPiA+ID4gLSBoYXZlIEkgbWlz c2VkIGFueXRoaW5nPw0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFN1cHBvcnRpbmcgVVJJIGZv cm1hdHMgb3RoZXIgdGhhbiBTSVAgKGUuZy4sIEhUVFApIHdvdWxkIHN0aWxsDQo+ID4gbmVlZA0K PiA+ID4gdG8NCj4gPiA+ID4gPiA+IGJlIHdvcmtlZC4gQnV0IHRoYXQgZm9ybWF0IHdvdWxkIGJl IGNvbW1vbiB0byBhbGwgTGJ5UiB1c2FnZXMuDQo+ID4gPiA+ID4gPiBUaGlzIGluIG5vIHdheSBy ZW1vdmVzIHRoZSByZXF1aXJlbWVudCBmb3IgYSBkZXZpY2UtdG8tTElTDQo+ICJMQ1AiLg0KPiA+ IEkNCj4gPiA+ID4gPiA+IGhhdmVuJ3QgcmVhZCB0aGF0IGludG8gdGhlIHN1Z2dlc3Rpb24gYXQg YWxsLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFNvLCBJIHRoaW5rIHRoaXMgaWRlYSB3YXJy YW50cyBjb25zaWRlcmF0aW9uLg0KPiA+ID4gPiA+ID4gQmFyYmFyYQ0KPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gPiBGcm9tOiBB bmRyZXcgTmV3dG9uIFttYWlsdG86YW5keUBoeHIudXNdDQo+ID4gPiA+ID4gPiBTZW50OiBUaHVy c2RheSwgRmVicnVhcnkgMTUsIDIwMDcgMzo1MSBQTQ0KPiA+ID4gPiA+ID4gVG86IFN0YXJrLCBC YXJiYXJhDQo+ID4gPiA+ID4gPiBDYzogZ2VvcHJpdkBpZXRmLm9yZzsgT3RtYXIgTGVuZGwNCj4g PiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbR2VvcHJpdl0gR2VvcHJpdiBMNyBMQ1A6IE5ldyBSZXF1 aXJlbWVudA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBPbiBGZWIgMTUs IDIwMDcsIGF0IDEyOjUwIFBNLCBTdGFyaywgQmFyYmFyYSB3cm90ZToNCj4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4+IFdoYXQgaXMgZGlmZmljdWx0LCBpcyBmaWd1cmluZyBv dXQgYSBzdGFuZGFyZCBmb3JtYXQgZm9yIGEgVVJJDQo+ID4gdXNlcg0KPiA+ID4gPiA+ID4+IHBh cnQgdGhhdCB3b3VsZCBhbGxvdyBmb3IgYWxsIHRoZSB2YXJpYXRpb25zIGluIGNvbWJpbmF0aW9u cyBvZg0KPiA+IElEcw0KPiA+ID4gPiA+ID4+IHRoYXQgZXhpc3QsIHNvIHRoYXQgYSBzdGFuZGFy ZCBmb3JtYXQgY291bGQgYmUgZGVmaW5lZCB0aGF0DQo+IHdvdWxkDQo+ID4gPiA+ID4gPj4gY292 ZXIgYWxsIGludGVyY29ubmVjdGlvbiBtb2RlbHMuIFNlY3Rpb24gOCBvZiB0aGUgTkVOQQ0KPiBM b2NhdGlvbg0KPiA+ID4gVElEDQo+ID4gPiA+ID4gPj4gKGh0dHA6Ly93d3cubmVuYS5vcmcvbWVk aWEvZmlsZXMvMDgtNTA1XzIwMDYxMjIxLnBkZikgcHJvdmlkZXMNCj4gNQ0KPiA+ID4gPiA+ID4+ IGRpZmZlcmVudCBleGFtcGxlcyBvZiBpbnRlcmNvbm5lY3Rpb24gbW9kZWxzLCBhbmQgdGhlIElE cyB0aGF0DQo+ID4gPiB3b3VsZA0KPiA+ID4gPiA+ID4+IG5lZWQgdG8gYmUgdXNlZCBpbiBlYWNo IG9mIHRoZXNlIGNhc2VzLiBJbiB0aGlzIGRvY3VtZW50LA0KPiA+IHNjZW5hcmlvDQo+ID4gPiAx DQo+ID4gPiA+ID4gPj4gdXNlcyB0aGUgSVAgYWRkcmVzcywgc2NlbmFyaW8gMiB1c2VzIE5BUy1J RCBhbmQgQVRNIFBWQywNCj4gc2NlbmFyaW8NCj4gPiAzDQo+ID4gPiA+ID4gPj4gdXNlcw0KPiA+ ID4gPiA+ID4+IDIgVkxBTiB0YWdzLCBzY2VuYXJpbyA0IHVzZXMgSVAgYWRkcmVzcywgYW5kIHNj ZW5hcmlvIDUgdXNlcw0KPiBMMlRQDQo+ID4gPiA+ID4gPj4gdHVubmVsIElEIChzb3VyY2UgYW5k IGRlc3RpbmF0aW9uKSBhbmQgUFBQb0Ugc2Vzc2lvbiBJRC4gVGhlc2UNCj4gPiBhcmUNCj4gPiA+ ID4gPiA+PiBqdXN0IDUgcG9zc2libGUgZXhhbXBsZXMsIGFuZCBzaG91bGQgbm90IGJlIGNvbnNp ZGVyZWQNCj4gPiBleGhhdXN0aXZlLg0KPiA+ID4gPiA+ID4+IEludGVyY29ubmVjdGlvbiBtb2Rl bHMgYXJlIHN0aWxsIGV2b2x2aW5nLg0KPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gV2VsbCwgdGhhdCdzIGVhc2lseSBzb2x2ZWQgd2l0aCBhIEJDUCBmb3IgZm9ybXVsYXRp bmcgVVJJcyBiYXNlZA0KPiA+IG9uDQo+ID4gPiA+IHRoZQ0KPiA+ID4gPiA+ID4gSUQuICBZb3Ug ZG9uJ3QgbmVlZCBhIG5ldyBwcm90b2NvbCBvciB0byBjb25mbGF0ZSB0aGUgTENQDQo+IHByb3Rv Y29sDQo+ID4gPiA+IHdpdGgNCj4gPiA+ID4gPiA+IHRoaXMgZnVuY3Rpb25hbGl0eS4NCj4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiAtYW5keQ0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ICoqKioq DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gVGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGlz IGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3INCj4gPiA+IGVudGl0eQ0KPiA+ID4gPiB0 bw0KPiA+ID4gPiA+IHdoaWNoIGl0IGlzIGFkZHJlc3NlZCBhbmQgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsLCBwcm9wcmlldGFyeSwNCj4gPiA+IGFuZC9vcg0KPiA+ID4gPiA+IHByaXZpbGVnZWQg bWF0ZXJpYWwuIEFueSByZXZpZXcsIHJldHJhbnNtaXNzaW9uLCBkaXNzZW1pbmF0aW9uIG9yDQo+ ID4gPiBvdGhlcg0KPiA+ID4gPiA+IHVzZSBvZiwgb3IgdGFraW5nIG9mIGFueSBhY3Rpb24gaW4g cmVsaWFuY2UgdXBvbiB0aGlzIGluZm9ybWF0aW9uDQo+IGJ5DQo+ID4gPiA+ID4gcGVyc29ucyBv ciBlbnRpdGllcyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMNCj4gcHJvaGli aXRlZC4NCj4gPiA+IElmDQo+ID4gPiA+ID4geW91IHJlY2VpdmVkIHRoaXMgaW4gZXJyb3IsIHBs ZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZQ0KPiB0aGUNCj4gPiA+ID4gPiBtYXRl cmlhbCBmcm9tIGFsbCBjb21wdXRlcnMuIEdBNjIxDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+ID4gR2VvcHJpdiBtYWlsaW5nIGxpc3QNCj4gPiA+ ID4gPiA+IEdlb3ByaXZAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2dlb3ByaXYNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+ID4g R2VvcHJpdiBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiA+IEdlb3ByaXZAaWV0Zi5vcmcNCj4gPiA+ ID4gPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dlb3ByaXYNCj4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+ IEdlb3ByaXYgbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4gR2VvcHJpdkBpZXRmLm9yZw0KPiA+ID4g PiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dlb3ByaXYNCj4gPiA+ ID4gPg0KPiA+ID4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiA+IC0tDQo+ID4gPiAtLQ0KPiA+ID4g PiAtLQ0KPiA+ID4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ID4gPiBUaGlzIG1l c3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCj4gPiA+ ID4gPiBjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0 ZSBpbmZvcm1hdGlvbi4NCj4gPiA+ID4gPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+ID4gPiA+ID4gaW1tZWRpYXRlbHkgYW5kIGRl bGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KPiA+ID4gPiA+IHRo aXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCj4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gPiAt LQ0KPiA+ID4gLS0NCj4gPiA+ID4gLS0NCj4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+ID4gPiA+ID4gW21mMl0NCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiBHZW9w cml2IG1haWxpbmcgbGlzdA0KPiA+ID4gPiA+IEdlb3ByaXZAaWV0Zi5vcmcNCj4gPiA+ID4gPiBo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nZW9wcml2DQo+ID4gPiA+DQo+ ID4gPiA+DQo+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4gPiA+IEdlb3ByaXYgbWFpbGluZyBsaXN0DQo+ID4gPiA+IEdlb3ByaXZAaWV0 Zi5vcmcNCj4gPiA+ID4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2Vv cHJpdg0KPiA+ID4NCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gPiAtLQ0KPiA+ID4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWdu YXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQo+ID4gPiBjb250YWluIHByaXZpbGVnZWQsIHBy b3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4NCj4gPiA+IElmIHlv dSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCj4g PiA+IGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXpl ZCB1c2Ugb2YNCj4gPiA+IHRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCj4gPiA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gLS0NCj4gPiAtLQ0KPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4g W21mMl0NCj4gPiA+DQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiA+IEdlb3ByaXYgbWFpbGluZyBsaXN0DQo+ID4gPiBHZW9w cml2QGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9nZW9wcml2DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+ID4gVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNp cGllbnQgb25seSBhbmQgbWF5DQo+ID4gY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwg b3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uDQo+ID4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KPiA+IGltbWVkaWF0ZWx5 IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCj4gPiB0 aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+ID4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IFttZjJdDQo+IA0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0 ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFy eSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2Vp dmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFu ZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1h aWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KW21mMl0NCg== --===============2023601858== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============2023601858==-- From geopriv-bounces@ietf.org Mon Mar 12 19:44: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 1HQuBn-0001QG-6q; Mon, 12 Mar 2007 19:44:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQuBl-0001QB-TT for geopriv@ietf.org; Mon, 12 Mar 2007 19:44:25 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQuBk-0006PI-Jd for geopriv@ietf.org; Mon, 12 Mar 2007 19:44:25 -0400 X-SEF-Processed: 5_0_0_910__2007_03_12_18_50_21 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); Mon, 12 Mar 2007 18:50:21 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 18:44:24 -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: [Geopriv] NENA Requirements Date: Mon, 12 Mar 2007 18:44:22 -0500 Message-ID: In-Reply-To: <01cc01c764be$1063d390$230d0d0a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] NENA Requirements Thread-Index: AcdjTeBAtyKST3eMTvyeug/JBnGIcwAOsaoAAE1BBKAADdzAIA== From: "Winterbottom, James" To: "Marc Linsner" , "Dawson, Martin" X-OriginalArrivalTime: 12 Mar 2007 23:44:24.0283 (UTC) FILETIME=[5D492AB0:01C76500] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I have re-read Ted's email now several times, and it seems to=0D=0Aconcentr= ate on being able to detect and potentially thwart denial of=0D=0Aservice a= ttacks. While this is one of the potential problem it is not=0D=0Athe only = one, and I don't see the kind of thing Ted is talking about as=0D=0Aaddress= ing the same problems that signatures will address.=0D=0A=0D=0AFurther more= I did not seem to me to provide a concrete way of doing=0D=0Awhat Ted was = suggesting. Precisely how will this be done=3F Without these=0D=0Adetails = it seems like smoke and mirrors and may not end up being=0D=0Apossible at a= ll. But I don't discount it as helping.=0D=0A=0D=0AI don't see DoS as being= the only source of attack, and certainly don't=0D=0Asee signatures as the = solution to the DoS problem. I do see signatures=0D=0Aas providing a good w= ay to potentially screen crank-calls and avoiding=0D=0Aunnecessary use of p= ublic resources.=20=0D=0A=0D=0AThe 4 requirements I am tabling are below. =0D= =0A=0D=0A1) The only calls that SHALL be directed to a PSAP are those calls= that=0D=0Ahave been made by end-devices that are in the PSAP service juris= diction=0D=0Aat the time a call is made.=20=0D=0A=0D=0A2) Any location used= by routing services or subsequent dispatch services=0D=0AMUST unequivocall= y represent the physical position of the end-device at=0D=0Athe time the lo= cation is proffered.=0D=0A=0D=0A3) Any request for location made to a LIS M= UST result in either an=0D=0Aerror, or the current location of the target d= evice being returned.=0D=0A=0D=0A4) The source of the location information = MUST be identifiable and is=0D=0Aaccountable for the accuracy of the inform= ation provided.=0D=0A=0D=0AProviding you try to meet these 4 requirements I= am happy. Simply saying=0D=0Athey can't be done and so they are not requir= ements, as has been said in=0D=0Athe past, is not acceptable.=0D=0A=0D=0ACh= eers=0D=0AJames=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message-= ----=0D=0A> From: Marc Linsner [mailto:mlinsner@cisco.com]=0D=0A> Sent: Tue= sday, 13 March 2007 2:50 AM=0D=0A> To: Dawson, Martin=0D=0A> Cc: 'GEOPRIV'=0D= =0A> Subject: RE: [Geopriv] NENA Requirements=0D=0A>=20=0D=0A> Martin,=0D=0A= >=20=0D=0A> >=0D=0A> > I think all of the NENA requirements have been raise= d and=0D=0A> > discussed - the latest concept to cause indigestion is=0D=0A= > > location signing.=0D=0A>=20=0D=0A>=20=0D=0A> You have requirements mixe= d up with solutions. Signing location=0D=0Aobjects=0D=0A> is=0D=0A> a solu= tion. I believe Ted nailed the requirement.=0D=0A>=20=0D=0A> -Marc-=0D=0A>= =20=0D=0A>=20=0D=0A>=20=0D=0A> ____________________________________________= ___=0D=0A> Geopriv mailing list=0D=0A> Geopriv@ietf.org=0D=0A> https://www1= =2Eietf.org/mailman/listinfo/geopriv=0D=0A=0D=0A---------------------------= ---------------------------------------------------------------------=0D=0A= This message is for the designated recipient only and may=0D=0Acontain priv= ileged, 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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Mar 12 20:03:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQuUJ-0000GG-Ti; Mon, 12 Mar 2007 20:03:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQuUJ-0000G6-3e for geopriv@ietf.org; Mon, 12 Mar 2007 20:03:35 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQuU8-00021S-29 for geopriv@ietf.org; Mon, 12 Mar 2007 20:03:35 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l2D03Kw6014179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Mar 2007 17:03:21 -0700 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.72.21]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2D03ItA016545; Mon, 12 Mar 2007 17:03:19 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 12 Mar 2007 17:00:52 -0700 To: Ted Hardie , Andrew Newton , GEOPRIV WG From: Randall Gellens Subject: Re: [Geopriv] Where we are / are we with L7-LCP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org At 2:52 PM -0800 3/9/07, Ted Hardie wrote: > PSAPs want to limit the ability of attackers to use their resources. > One way they do that now is to limit who can talk to the PSAP to those > within their service area. > > PSAPs can no longer use network topology to identify who is in their service > area. They would like to use something else. The location asserted by > the end user/network is used to identify a PSAP which serves the area, but > the PSAPs are concerned that bad actors can assert false information to > discover/target PSAPs. They would like the information used in those > assertions to be vouched for by someone they trust or with whom they > can build trust, and the information to be carried through to the PSAP. > > Rather than have the clients doing the assertion being vouched for > (now *there's > a problem*), they want one piece of information in the assertion to be > vouched for--the location. If that is vouched for, the PSAP has > higher confidence > that the call is from someone within their service area; that means that > they are no more likely to be an attacker than they would be with the > existing system (which allows for attackers to call from within the service > area). I'm not sure that the a caller who posses a signed location is no more likely to be an attacker than is a caller with today's POTS, given that attackers can obtain a location from an area other than their own. > > The issue that I'm raising is that while the primary aim,"limit the > ability of attackers > to use their resources", is laudable, useful, and strongly > associated with apple > pie, good beer, and the comic-book hero of your choice, doing so > by "limiting > the geographic range from which attacks may come" is only a strategy for > achieving it. There are other potential strategies (including > things like associative > IDS systems that do not work on single calls but work on patterns) that might > be more effective at thwarting the efforts of attackers to consume > PSAP resources. > Recreating the old strategy in the new system might be possible > (with a large, > likely unfunded mandate), but it will take a lot of time and cruft > to get it going. > Balancing the effort that goes into this strategy has to be weighed > against whether > this strategy is effective in and of itself and whether it is the > best use of the > community's resources. > > Put another way, we need to focus on the real goal, rather than on > whether this > strategy is the right way to achieve it. Brian has been saying > this in some ways > all along, but I think we've been hearing him say "how else can I > limit callers > to a specific geographic area" rather than "how else can I preserve PSAPs > against attackers looking to consume their resources." > > > All that now said, I remind folks that it has all along been possible to sign > a PIDF-LO object using S/MIME; that's in the base standard. Anyone looking > to create method for carrying location with a signature has only to pick > PIDF-LO as their format and that mechanism comes along for the ride. > That won't tell you who ought to sign it, when that signature out > to be checked, > or what actions to take when it fails, but as I understand it folks want that > to be a matter of policy anyway. So the question for geopriv becomes: what else is it necessary for us to do now? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Finagle's Second Law: No matter what the anticipated result, there will always be someone eager to (a) misinterpret it, (b) fake it, or (c) believe it happened according to his own pet theory. _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Mar 12 20:07: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 1HQuYC-0004WW-F1; Mon, 12 Mar 2007 20:07:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQuYB-0004WJ-6A for geopriv@ietf.org; Mon, 12 Mar 2007 20:07:35 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQuY9-0003S6-2P for geopriv@ietf.org; Mon, 12 Mar 2007 20:07:34 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l2D07T7f014530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Mar 2007 17:07:30 -0700 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.72.21]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2D07SRM017541; Mon, 12 Mar 2007 17:07:28 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 12 Mar 2007 17:07:26 -0700 To: "Dawson, Martin" , "Ted Hardie" , "Andrew Newton" , "GEOPRIV WG" From: Randall Gellens Subject: RE: [Geopriv] Where we are / are we with L7-LCP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org At 6:37 PM -0600 3/9/07, Martin Dawson wrote: > 2. There are parts of the PIDF-LO that should still be able to be > changed by the location object recipient and, potentially, some proxies. > If the signature applies to the whole object then this won't be > possible. Just curious: what about providing two pidf-lo objects: one signed and unaltered, and one that was modified as needed. The PSAP (or other entity) could compare the two and determine which fields had been modified, and decide if the fields were "safe". -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Beware of false knowledge; it is more dangerous than ignorance. _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Mar 12 20:13: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 1HQudd-0008Mg-R6; Mon, 12 Mar 2007 20:13:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQudc-0008Kl-HX for geopriv@ietf.org; Mon, 12 Mar 2007 20:13:12 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQuda-000460-9J for geopriv@ietf.org; Mon, 12 Mar 2007 20:13:12 -0400 X-SEF-Processed: 5_0_0_910__2007_03_12_19_19_07 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, 12 Mar 2007 19:19:07 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 19:13:10 -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: [Geopriv] Where we are / are we with L7-LCP Date: Mon, 12 Mar 2007 19:12:24 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Where we are / are we with L7-LCP Thread-Index: AcdlA5glsuiGn+BYSIWrqhbi0WrzQgAAB4dA From: "Dawson, Martin" To: "Randall Gellens" , "Ted Hardie" , "Andrew Newton" , "GEOPRIV WG" X-OriginalArrivalTime: 13 Mar 2007 00:13:10.0199 (UTC) FILETIME=[62030C70:01C76504] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I think the issue with that is that it tries to second guess the=0D=0Aappli= cation for the PIDF-LO.=0D=0A=0D=0ASIP conveyance is just one scenario. A L= IS client may request a location=0D=0Aobject for any arbitrary application = using any arbitrary conveyance. The=0D=0Aapplication may not deal with mult= iple PIDF-LO objects.=0D=0A=0D=0ASo - the proposition is that, in generatin= g the signature on the=0D=0Alocation information, the LIS is only securing = those parts of the=0D=0Ainformation that it is taking responsibility for wi= thout impeding the=0D=0Aability of other actors in the application scenario= from making=0D=0Aappropriate contributions to the content of the object.=0D= =0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFro= m: Randall Gellens [mailto:randy@qualcomm.com]=20=0D=0ASent: Tuesday, 13 Ma= rch 2007 11:07 AM=0D=0ATo: Dawson, Martin; Ted Hardie; Andrew Newton; GEOPR= IV WG=0D=0ASubject: RE: [Geopriv] Where we are / are we with L7-LCP=0D=0A=0D= =0AAt 6:37 PM -0600 3/9/07, Martin Dawson wrote:=0D=0A=0D=0A> 2. There are= parts of the PIDF-LO that should still be able to be=0D=0A> changed by th= e location object recipient and, potentially, some=0D=0Aproxies.=0D=0A> If= the signature applies to the whole object then this won't be=0D=0A> possi= ble.=0D=0A=0D=0AJust curious: what about providing two pidf-lo objects: one= signed=20=0D=0Aand unaltered, and one that was modified as needed. The PS= AP (or=20=0D=0Aother entity) could compare the two and determine which fiel= ds had=20=0D=0Abeen modified, and decide if the fields were "safe".=0D=0A=0D= =0A--=20=0D=0ARandall Gellens=0D=0AOpinions are personal; facts are susp= ect; I speak for myself only=0D=0A-------------- Randomly-selected tag: = ---------------=0D=0ABeware of false knowledge; it is more dangerous than i= gnorance.=0D=0A=0D=0A------------------------------------------------------= ------------------------------------------=0D=0AThis message is for the des= ignated recipient only and may=0D=0Acontain privileged, proprietary, or oth= erwise private information. =20=0D=0AIf you have received it in error, plea= se notify the sender=0D=0Aimmediately and delete the original. Any unautho= rized use of=0D=0Athis email is prohibited.=0D=0A--------------------------= ----------------------------------------------------------------------=0D=0A= [mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Mar 12 20:14: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 1HQueb-0000LF-VD; Mon, 12 Mar 2007 20:14:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQueZ-0000Ky-UJ for geopriv@ietf.org; Mon, 12 Mar 2007 20:14:11 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQueY-0004BM-IH for geopriv@ietf.org; Mon, 12 Mar 2007 20:14:11 -0400 X-SEF-Processed: 5_0_0_910__2007_03_12_19_20_07 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); Mon, 12 Mar 2007 19:20:07 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 19:14:10 -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: [Geopriv] Where we are / are we with L7-LCP Date: Mon, 12 Mar 2007 19:14:02 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Where we are / are we with L7-LCP Thread-Index: AcdlAxnlHd7cWcFSQlKlnCpdd0+r0QAATKZw From: "Dawson, Martin" To: "Randall Gellens" , "Ted Hardie" , "Andrew Newton" , "GEOPRIV WG" X-OriginalArrivalTime: 13 Mar 2007 00:14:10.0193 (UTC) FILETIME=[85C56810:01C76504] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org It's not about the "likelihood" of being an attacker. The emergency=0D=0Ase= rvice is currently structured to receive calls from devices that are=0D=0Ap= hysically located within the catchment area of the service. *One* of=0D=0At= he contributions of providing signed location (and it is just one of=0D=0At= hem) is that a policy can be applied to imposes the same limitation.=0D=0A=0D= =0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Ran= dall Gellens [mailto:randy@qualcomm.com]=20=0D=0ASent: Tuesday, 13 March 20= 07 11:01 AM=0D=0ATo: Ted Hardie; Andrew Newton; GEOPRIV WG=0D=0ASubject: Re= : [Geopriv] Where we are / are we with L7-LCP=0D=0A=0D=0AAt 2:52 PM -0800 3= /9/07, Ted Hardie wrote:=0D=0A=0D=0A> PSAPs want to limit the ability of a= ttackers to use their resources.=0D=0A> One way they do that now is to lim= it who can talk to the PSAP to=0D=0Athose=0D=0A> within their service area= =2E=0D=0A>=0D=0A> PSAPs can no longer use network topology to identify who= is in their=0D=0Aservice=0D=0A> area. They would like to use something e= lse. The location asserted=0D=0Aby=0D=0A> the end user/network is used to= identify a PSAP which serves the=0D=0Aarea, but=0D=0A> the PSAPs are con= cerned that bad actors can assert false information=0D=0Ato=0D=0A> discove= r/target PSAPs. They would like the information used in those=0D=0A> asse= rtions to be vouched for by someone they trust or with whom they=0D=0A> ca= n build trust, and the information to be carried through to the=0D=0APSAP.=0D= =0A>=0D=0A> Rather than have the clients doing the assertion being vouched= for=20=0D=0A> (now *there's=0D=0A> a problem*), they want one piece of in= formation in the assertion to=0D=0Abe=0D=0A> vouched for--the location. I= f that is vouched for, the PSAP has=20=0D=0A> higher confidence=0D=0A> tha= t the call is from someone within their service area; that means=0D=0Athat=0D= =0A> they are no more likely to be an attacker than they would be with the=0D= =0A> existing system (which allows for attackers to call from within the=0D= =0Aservice=0D=0A> area).=0D=0A=0D=0AI'm not sure that the a caller who pos= ses a signed location is no=20=0D=0Amore likely to be an attacker than is a= caller with today's POTS,=20=0D=0Agiven that attackers can obtain a locati= on from an area other than=20=0D=0Atheir own.=0D=0A=0D=0A>=0D=0A> The issu= e that I'm raising is that while the primary aim,"limit the=20=0D=0A> abili= ty of attackers=0D=0A> to use their resources", is laudable, useful, and s= trongly=20=0D=0A> associated with apple=0D=0A> pie, good beer, and the com= ic-book hero of your choice, doing so=20=0D=0A> by "limiting=0D=0A> the = geographic range from which attacks may come" is only a strategy=0D=0Afor=0D= =0A> achieving it. There are other potential strategies (including=20=0D=0A= > things like associative=0D=0A> IDS systems that do not work on single ca= lls but work on patterns)=0D=0Athat might=0D=0A> be more effective at thwa= rting the efforts of attackers to consume=20=0D=0A> PSAP resources.=0D=0A> = Recreating the old strategy in the new system might be possible=20=0D=0A> = (with a large,=0D=0A> likely unfunded mandate), but it will take a lot of= time and cruft=20=0D=0A> to get it going.=0D=0A> Balancing the effort tha= t goes into this strategy has to be weighed=20=0D=0A> against whether=0D=0A= > this strategy is effective in and of itself and whether it is the=20=0D=0A= > best use of the=0D=0A> community's resources.=0D=0A>=0D=0A> Put another= way, we need to focus on the real goal, rather than on=20=0D=0A> whether t= his=0D=0A> strategy is the right way to achieve it. Brian has been saying= =20=0D=0A> this in some ways=0D=0A> all along, but I think we've been hear= ing him say "how else can I=20=0D=0A> limit callers=0D=0A> to a specific g= eographic area" rather than "how else can I preserve=0D=0APSAPs=0D=0A> aga= inst attackers looking to consume their resources."=0D=0A>=0D=0A>=0D=0A> A= ll that now said, I remind folks that it has all along been possible=0D=0At= o sign=0D=0A> a PIDF-LO object using S/MIME; that's in the base standard. = Anyone=0D=0Alooking=0D=0A> to create method for carrying location with a = signature has only to=0D=0Apick=0D=0A> PIDF-LO as their format and that me= chanism comes along for the ride.=0D=0A> That won't tell you who ought to = sign it, when that signature out=20=0D=0A> to be checked,=0D=0A> or what a= ctions to take when it fails, but as I understand it folks=0D=0Awant that=0D= =0A> to be a matter of policy anyway.=0D=0A=0D=0ASo the question for geopr= iv becomes: what else is it necessary for us=20=0D=0Ato do now=3F=0D=0A-- =0D= =0ARandall Gellens=0D=0AOpinions are personal; facts are suspect; I s= peak for myself only=0D=0A-------------- Randomly-selected tag: -----------= ----=0D=0AFinagle's Second Law:=0D=0A No matter what the anticipated res= ult, there will always be=0D=0A someone eager to (a) misinterpret it, (b= ) fake it, or (c)=0D=0A believe it happened according to his own pet the= ory.=0D=0A=0D=0A_______________________________________________=0D=0AGeopri= v mailing list=0D=0AGeopriv@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/lis= tinfo/geopriv=0D=0A=0D=0A--------------------------------------------------= ----------------------------------------------=0D=0AThis message is for the= designated recipient only and may=0D=0Acontain privileged, 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 una= uthorized use of=0D=0Athis email is prohibited.=0D=0A----------------------= --------------------------------------------------------------------------=0D= =0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Mar 12 20:40: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 1HQv3k-0002MU-Ex; Mon, 12 Mar 2007 20:40:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQv3j-0002MK-Dg for geopriv@ietf.org; Mon, 12 Mar 2007 20:40:11 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQv3i-0003YU-65 for geopriv@ietf.org; Mon, 12 Mar 2007 20:40:11 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 12 Mar 2007 20:40:10 -0400 X-IronPort-AV: i="4.14,276,1170651600"; d="scan'208"; a="115451200:sNHT42965884" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2D0e9MZ008416; Mon, 12 Mar 2007 20:40:09 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2D0e9ZR011705; Tue, 13 Mar 2007 00:40:09 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 20:40:09 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 20:40:09 -0400 From: "Marc Linsner" To: "'Winterbottom, James'" Subject: RE: [Geopriv] NENA Requirements Date: Mon, 12 Mar 2007 20:40:07 -0400 Message-ID: <02d501c76508$26789950$230d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcdjTeBAtyKST3eMTvyeug/JBnGIcwAOsaoAAE1BBKAADdzAIAAEp1yg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 13 Mar 2007 00:40:09.0194 (UTC) FILETIME=[270214A0:01C76508] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=834; t=1173746409; x=1174610409; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20NENA=20Requirements |Sender:=20 |To:=20=22'Winterbottom,=20James'=22=20; bh=dO51el0M9Ttfmgosc9DgxkkPUfST73fbDaJso/T/r5E=; b=kHgTuEbGaHf2dIb/Hz2V1FuUBaY6B4EE+gbTZAi3nPji1XYk0ygVKYL3l6zX9+wYhSD5/Gxh mhPZXiljumAoHYVeDscl+qox0e5BHbE3lhUbRujJboHMG9WPr25OPjH7; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org James, > The 4 requirements I am tabling are below. > > 1) The only calls that SHALL be directed to a PSAP are those > calls that have been made by end-devices that are in the PSAP > service jurisdiction at the time a call is made. > > 2) Any location used by routing services or subsequent > dispatch services MUST unequivocally represent the physical > position of the end-device at the time the location is proffered. > > 3) Any request for location made to a LIS MUST result in > either an error, or the current location of the target device > being returned. > > 4) The source of the location information MUST be > identifiable and is accountable for the accuracy of the > information provided. Could you please cite the NENA document(s) that state these 4 requirements. Thanks, -Marc- _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Mar 12 21:02: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 1HQvP7-0007jH-4T; Mon, 12 Mar 2007 21:02:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQvP5-0007j6-Ka for geopriv@ietf.org; Mon, 12 Mar 2007 21:02:15 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQvP3-0001ys-Ty for geopriv@ietf.org; Mon, 12 Mar 2007 21:02:15 -0400 X-SEF-Processed: 5_0_0_910__2007_03_12_20_08_10 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); Mon, 12 Mar 2007 20:08:10 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 20:02: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: [Geopriv] NENA Requirements Date: Mon, 12 Mar 2007 19:55:46 -0500 Message-ID: In-Reply-To: <01cc01c764be$1063d390$230d0d0a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] NENA Requirements Thread-Index: AcdjTeBAtyKST3eMTvyeug/JBnGIcwAOsaoAAE1BBKAAEykEoA== From: "Dawson, Martin" To: "Marc Linsner" X-OriginalArrivalTime: 13 Mar 2007 01:02:13.0511 (UTC) FILETIME=[3C5CD170:01C7650B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I'm not sure what the purpose of the post is. No, the NENA requirements=0D=0A= don't specify signing, but the related discussion has led to the=0D=0Adiscu= ssion of that concept...=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: M= arc Linsner [mailto:mlinsner@cisco.com]=20=0D=0ASent: Tuesday, 13 March 200= 7 2:50 AM=0D=0ATo: Dawson, Martin=0D=0ACc: 'GEOPRIV'=0D=0ASubject: RE: [Geo= priv] NENA Requirements=0D=0A=0D=0AMartin,=0D=0A=0D=0A>=20=0D=0A> I think a= ll of the NENA requirements have been raised and=20=0D=0A> discussed - the = latest concept to cause indigestion is=20=0D=0A> location signing.=0D=0A=0D= =0A=0D=0AYou have requirements mixed up with solutions. Signing location o= bjects=0D=0Ais=0D=0Aa solution. I believe Ted nailed the requirement.=0D=0A=0D= =0A-Marc-=20=0D=0A=0D=0A=0D=0A=0D=0A---------------------------------------= ---------------------------------------------------------=0D=0AThis message= is for the designated recipient only and may=0D=0Acontain privileged, prop= rietary, or otherwise private information. =20=0D=0AIf you have received it= in error, please notify the sender=0D=0Aimmediately and delete the origina= l. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-----------= ---------------------------------------------------------------------------= ----------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Mar 12 21:02: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 1HQvP8-0007jV-9p; Mon, 12 Mar 2007 21:02:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQvP6-0007jB-QB for geopriv@ietf.org; Mon, 12 Mar 2007 21:02: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 1HQvP4-0001yt-9n for geopriv@ietf.org; Mon, 12 Mar 2007 21:02:16 -0400 X-SEF-Processed: 5_0_0_910__2007_03_12_20_08_11 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); Mon, 12 Mar 2007 20:08:11 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 20:02: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: [Geopriv] NENA Requirements Date: Mon, 12 Mar 2007 19:57:02 -0500 Message-ID: In-Reply-To: <02d501c76508$26789950$230d0d0a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] NENA Requirements Thread-Index: AcdjTeBAtyKST3eMTvyeug/JBnGIcwAOsaoAAE1BBKAADdzAIAAEp1ygAACqddA= From: "Dawson, Martin" To: "Marc Linsner" , "Winterbottom, James" X-OriginalArrivalTime: 13 Mar 2007 01:02:13.0964 (UTC) FILETIME=[3CA1F0C0:01C7650B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I must have missed the part where he said these were specifically quoted=0D= =0Afrom NENA requirements. Have we flipped to this being the sole source=3F=0D= =0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFro= m: Marc Linsner [mailto:mlinsner@cisco.com]=20=0D=0ASent: Tuesday, 13 March= 2007 11:40 AM=0D=0ATo: Winterbottom, James=0D=0ACc: 'GEOPRIV'=0D=0ASubject= : RE: [Geopriv] NENA Requirements=0D=0A=0D=0AJames,=0D=0A=0D=0A> The 4 requ= irements I am tabling are below.=20=0D=0A>=20=0D=0A> 1) The only calls that= SHALL be directed to a PSAP are those=20=0D=0A> calls that have been made = by end-devices that are in the PSAP=20=0D=0A> service jurisdiction at the t= ime a call is made.=20=0D=0A>=20=0D=0A> 2) Any location used by routing ser= vices or subsequent=20=0D=0A> dispatch services MUST unequivocally represen= t the physical=20=0D=0A> position of the end-device at the time the locatio= n is proffered.=0D=0A>=20=0D=0A> 3) Any request for location made to a LIS = MUST result in=20=0D=0A> either an error, or the current location of the ta= rget device=20=0D=0A> being returned.=0D=0A>=20=0D=0A> 4) The source of the= location information MUST be=20=0D=0A> identifiable and is accountable for= the accuracy of the=20=0D=0A> information provided.=0D=0A=0D=0ACould you p= lease cite the NENA document(s) that state these 4=0D=0Arequirements.=0D=0A=0D= =0AThanks,=0D=0A=0D=0A-Marc-=0D=0A=0D=0A=0D=0A_____________________________= __________________=0D=0AGeopriv mailing list=0D=0AGeopriv@ietf.org=0D=0Ahtt= ps://www1.ietf.org/mailman/listinfo/geopriv=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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 00: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 1HQyj1-0004AO-LS; Tue, 13 Mar 2007 00:35:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQyiz-0004A5-HJ for geopriv@ietf.org; Tue, 13 Mar 2007 00:35:01 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQyif-0006rA-TI for geopriv@ietf.org; Tue, 13 Mar 2007 00:35:01 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l2D4YbJw006997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Mar 2007 21:34:37 -0700 Received: from [71.204.158.100] (vpn-10-50-0-140.qualcomm.com [10.50.0.140]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2D4YZmD017826; Mon, 12 Mar 2007 21:34:36 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 12 Mar 2007 21:34:34 -0700 To: "Winterbottom, James" , "Marc Linsner" , "Dawson, Martin" From: Ted Hardie Subject: RE: [Geopriv] NENA Requirements Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org At 6:44 PM -0500 3/12/07, Winterbottom, James wrote: >The 4 requirements I am tabling are below. > >1) The only calls that SHALL be directed to a PSAP are those calls that >have been made by end-devices that are in the PSAP service jurisdiction >at the time a call is made. > This goes contrary to everything we have discussed before, where the theory has been that the call taker would try to take a call in any circumstance, and these indicators would be used at most for ranking. To link this to the "warnings" thread on Ecrit right now, we're saying there that there will be cases where a server should return a default, a stale answer, or similar, because it cannot parse the request, cannot reach an upstream for the data, or cannot confirm its freshness. It returns *a valid PSAP*, even if the request had an unresolvable address, because doing so may save lives. Sure, that call should have health warnings and may affect the queuing by call takers, but saying you won't deliver the call because *you cannot confirm at call time that the end device is within the PSAP jurisdiction* will kill someone. I reject such a requirement utterly, and I hope the WG agrees with me. Route the call, and let the local policy at the PSAP decide if you have to, but failing to route the call via system design is not okay. >2) Any location used by routing services or subsequent dispatch services >MUST unequivocally represent the physical position of the end-device at >the time the location is proffered. > This is a strawman, or at least I hope it is. A device that got its location on boot, cannot update it because of network issues, and presents its position to this system is behaving according to the best-effort nature of the underlying network. While the phone system is waiting for me to present an "unequivocal" location, your strawman is burning up in the car fire I was calling to report. >3) Any request for location made to a LIS MUST result in either an >error, or the current location of the target device being returned. > And if the LIS has the location of the attachment point, but not the target device, who resolves the problem? The end node, by presenting the attachment point to the LIS for location (nice targeting system, good luck!)? Or the LIS, which should return the likely service area of the attachment point as a non-point response? If the latter, we may have something useful for identifying useful PSAPs, but it is not the target device's location for lots of systems in which the service area is large (think: WiMAX). >4) The source of the location information MUST be identifiable and is >accountable for the accuracy of the information provided. The second is not an engineering requirement, and the first would be satisfied by a self-report for cases like enterprise networks. That might well be useful for tracking ill-described locations and similar post-facto analyses. But you're sprinkling crypto dust on it in the hopes of recreating a system where the underlying mechanism is totally different. With enough thrust the pig may fly, but it spoils the bacon and irritates the pig. Ted >Providing you try to meet these 4 requirements I am happy. Simply saying >they can't be done and so they are not requirements, as has been said in >the past, is not acceptable. >Cheers >James > > > > > >> -----Original Message----- >> From: Marc Linsner [mailto:mlinsner@cisco.com] >> Sent: Tuesday, 13 March 2007 2:50 AM >> To: Dawson, Martin >> Cc: 'GEOPRIV' >> Subject: RE: [Geopriv] NENA Requirements >> >> Martin, >> >> > >> > I think all of the NENA requirements have been raised and >> > discussed - the latest concept to cause indigestion is >> > location signing. >> >> >> You have requirements mixed up with solutions. Signing location >objects >> is >> a solution. I believe Ted nailed the requirement. > > >> -Marc- >> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 01:59: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 1HR02q-0002sG-JX; Tue, 13 Mar 2007 01:59:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR02o-0002s8-OX for geopriv@ietf.org; Tue, 13 Mar 2007 01:59:34 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR02o-0000HD-Ax for geopriv@ietf.org; Tue, 13 Mar 2007 01:59:34 -0400 X-SEF-Processed: 5_0_0_910__2007_03_13_01_05_31 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); Tue, 13 Mar 2007 01:05:31 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 00:59:33 -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: [Geopriv] NENA Requirements Date: Tue, 13 Mar 2007 00:55:06 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] NENA Requirements Thread-Index: AcdlKOq67RqUnNWWQUG2R5obqIxWMAACCcJA From: "Dawson, Martin" To: "Ted Hardie" , "Winterbottom, James" , "Marc Linsner" X-OriginalArrivalTime: 13 Mar 2007 05:59:33.0900 (UTC) FILETIME=[C61024C0:01C76534] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org It's actually quite inappropriate for the IETF to be stating what the=0D=0A= policies for emergency services in global jurisdictions needs to be.=0D=0AJ= ames' rules below may, indeed, be a strawman but they represent one=0D=0Apo= ssible set of rules that one possible jurisdiction may wish to adopt.=0D=0A=0D= =0AIt is an act of hubris for the IETF to deprive jurisdictions of these=0D= =0Amechanisms because individuals who aren't actually the ones who are=0D=0A= going to be the stakeholders didn't think it could be handled properly.=0D=0A=0D= =0ANENA - who do represent a very broad cross-section of genuine=0D=0Astake= holders - do consider that they have the chops to institute=0D=0Asomething = like VESA and make it work for them. I have the utmost=0D=0Aconfidence that= they will be able to make it work and that it will=0D=0Acontribute to the = integrity, in a significant way, of the emergency=0D=0Aservice. There's a t= endency to be dismissive of their skills and=0D=0Aknowledge in these areas = which I think is similarly patronising and=0D=0Aquite incorrect. They have = more experience in making complex networks,=0D=0Aorganizations, and process= es work than most of the commentators on this=0D=0Alist. I say give them th= e tools they are asking for.=0D=0A=0D=0AThings evolve. In the long term it = may actually be considered=0D=0Aunacceptable for an access network to not p= rovide a robust mechanism for=0D=0Ainstantaneous location determination rat= her than "attachment time"=0D=0Alocation. I suggest that it will always be = possible to do this,=0D=0Aregardless of access technology, given the right = approach. Ideally the=0D=0Acapabilities of networks won't be frozen in time= and they will become=0D=0Amore sophisticated in this respect as time goes = by.=0D=0A=0D=0AOn point 4 - you may argue that the "accountability" aspect = is not an=0D=0Aengineering requirement. Perhaps not; it's a service require= ment and it=0D=0Acreates the opportunity to provide an engineering solution= =2E There is=0D=0Avery real value in being able to reliably associate the l= ocation with=0D=0Athe source so that errors in the system can be traced to = that source and=0D=0Acorrected. Closing the loop in this way for continuous= improvement is=0D=0Apart of the existing switched circuit telephony emerge= ncy service=0D=0Aprocesses and there's no less of an imperative for it for = IP telephony.=0D=0AYet another of the uses of signed location is in providi= ng this robust=0D=0Alink back to the source for this purpose; it's an engin= eering solution=0D=0Athat suggests itself.=0D=0A=0D=0ACheers,=0D=0AMartin=0D= =0A=0D=0A-----Original Message-----=0D=0AFrom: Ted Hardie [mailto:hardie@qu= alcomm.com]=20=0D=0ASent: Tuesday, 13 March 2007 3:35 PM=0D=0ATo: Winterbot= tom, James; Marc Linsner; Dawson, Martin=0D=0ACc: GEOPRIV=0D=0ASubject: RE:= [Geopriv] NENA Requirements=0D=0A=0D=0AAt 6:44 PM -0500 3/12/07, Winterbot= tom, James wrote:=0D=0A>The 4 requirements I am tabling are below.=0D=0A>=0D= =0A>1) The only calls that SHALL be directed to a PSAP are those calls that=0D= =0A>have been made by end-devices that are in the PSAP service jurisdiction=0D= =0A>at the time a call is made.=0D=0A>=0D=0A=0D=0AThis goes contrary to eve= rything we have discussed before, where the=0D=0Atheory has been that the c= all taker would try to take a call in any=0D=0Acircumstance, and these indi= cators would be used at most for ranking.=0D=0A=0D=0ATo link this to the "w= arnings" thread on Ecrit right now, we're saying=0D=0Athere that there will= be cases where a server should return a default,=0D=0Aa stale answer, or s= imilar, because it cannot parse the request, cannot=0D=0Areach an upstream = for the data, or cannot confirm its freshness. It=0D=0Areturns *a valid PS= AP*, even if the request had an unresolvable=0D=0Aaddress, because doing so= may save lives. Sure, that call should=0D=0Ahave health warnings and may = affect the queuing by call takers,=0D=0Abut saying you won't deliver the ca= ll because *you cannot confirm=0D=0Aat call time that the end device is wi= thin the PSAP jurisdiction* will=0D=0Akill someone. I reject such a requir= ement utterly, and I hope the WG=0D=0Aagrees with me. Route the call, and = let the local policy at the PSAP=0D=0Adecide=0D=0Aif you have to, but faili= ng to route the call via system design is not=0D=0Aokay.=0D=0A=0D=0A>2) Any= location used by routing services or subsequent dispatch=0D=0Aservices=0D=0A= >MUST unequivocally represent the physical position of the end-device at=0D= =0A>the time the location is proffered.=0D=0A>=0D=0A=0D=0AThis is a strawma= n, or at least I hope it is. A device that got its=0D=0Alocation on=0D=0Ab= oot, cannot update it because of network issues, and presents its=0D=0Aposi= tion=0D=0Ato this system is behaving according to the best-effort nature o= f=0D=0Athe underlying network. While the phone system is waiting for me to=0D= =0Apresent=0D=0Aan "unequivocal" location, your strawman is burning up in t= he car fire=0D=0AI was calling to report.=0D=0A=0D=0A>3) Any request for lo= cation made to a LIS MUST result in either an=0D=0A>error, or the current l= ocation of the target device being returned.=0D=0A>=0D=0A=0D=0AAnd if the L= IS has the location of the attachment point, but not the=0D=0Atarget device= , who resolves the problem=3F The end node, by presenting=0D=0Athe attachm= ent point to the LIS for location (nice targeting system,=0D=0Agood luck!)=3F= Or the LIS, which should return the likely service area of=0D=0Athe=0D=0A= attachment point as a non-point response=3F If the latter, we may have=0D=0A= something useful for identifying useful PSAPs, but it is not the target=0D=0A= device's=0D=0Alocation for lots of systems in which the service area is lar= ge (think:=0D=0AWiMAX).=0D=0A=0D=0A>4) The source of the location informati= on MUST be identifiable and is=0D=0A>accountable for the accuracy of the in= formation provided.=0D=0A=0D=0AThe second is not an engineering requirement= , and the first would be=0D=0Asatisfied by a self-report for cases like ent= erprise networks. That=0D=0Amight well be useful for tracking ill-describe= d locations and similar=0D=0Apost-facto analyses. But you're sprinkling cr= ypto dust on it in the=0D=0Ahopes of recreating a system where the underlyi= ng mechanism is=0D=0Atotally different. With enough thrust the pig may fly= , but it spoils=0D=0Athe bacon and irritates the pig.=0D=0A=0D=0A=09=09=09=09= Ted=0D=0A=0D=0A>Providing you try to meet these 4 requirements I am happy. = Simply=0D=0Asaying=0D=0A>they can't be done and so they are not requirement= s, as has been said=0D=0Ain=0D=0A>the past, is not acceptable.=0D=0A=0D=0A=0D= =0A=0D=0A=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: Marc Linsner [mailto:mlinsne= r@cisco.com]=0D=0A>> Sent: Tuesday, 13 March 2007 2:50 AM=0D=0A>> To: Dawso= n, Martin=0D=0A>> Cc: 'GEOPRIV'=0D=0A>> Subject: RE: [Geopriv] NENA Require= ments=0D=0A>>=0D=0A>> Martin,=0D=0A>>=0D=0A>> >=0D=0A>> > I think all of th= e NENA requirements have been raised and=0D=0A>> > discussed - the latest c= oncept to cause indigestion is=0D=0A>> > location signing.=0D=0A>>=0D=0A>>=0D= =0A>> You have requirements mixed up with solutions. Signing location=0D=0A= >objects=0D=0A>> is=0D=0A>> a solution. I believe Ted nailed the requireme= nt.=0D=0A> >=0D=0A>> -Marc-=0D=0A>>=0D=0A>>=0D=0A>>=0D=0A>> _______________= ________________________________=0D=0A>> Geopriv mailing list=0D=0A>> Geopr= iv@ietf.org=0D=0A>> https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A>=0D= =0A>-----------------------------------------------------------------------=0D= =0A-------------------------=0D=0A>This message is for the designated recip= ient only and may=0D=0A>contain privileged, proprietary, or otherwise priva= te information.=20=0D=0A>If you have received it in error, please notify th= e sender=0D=0A>immediately and delete the original. Any unauthorized use o= f=0D=0A>this email is prohibited.=0D=0A>-----------------------------------= ------------------------------------=0D=0A-------------------------=0D=0A>[= mf2]=0D=0A>=0D=0A>=0D=0A>_______________________________________________=0D= =0A>Geopriv mailing list=0D=0A>Geopriv@ietf.org=0D=0A>https://www1.ietf.org= /mailman/listinfo/geopriv=0D=0A=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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 07:18: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 1HR50p-0004Au-Kt; Tue, 13 Mar 2007 07:17:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR50p-0004Ap-03 for geopriv@ietf.org; Tue, 13 Mar 2007 07:17:51 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HR50m-00045V-MH for geopriv@ietf.org; Tue, 13 Mar 2007 07:17:50 -0400 Received: (qmail invoked by alias); 13 Mar 2007 11:17:47 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp045) with SMTP; 13 Mar 2007 12:17:47 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/kWl4ONmTkPutL0nTY/W5y47Or7d2f0nBzt9BlAI dN1xTrUCkaLU+q Message-ID: <45F6884F.9090807@gmx.net> Date: Tue, 13 Mar 2007 13:17:35 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: GEOPRIV 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: 7bac9cb154eb5790ae3b2913587a40de Subject: [Geopriv] Geopriv Webpage Nit X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I think that the webpage should point to http://www.rfc-editor.org/rfc/rfc4776.txt instead of http://www.ietf.org/rfc/rfc4676.txt when pointing to "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information" Ciao Hannes _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 10:03: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 1HR7ax-0003ld-MC; Tue, 13 Mar 2007 10:03:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR7av-0003gJ-Th for geopriv@ietf.org; Tue, 13 Mar 2007 10:03:17 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR7at-0003Va-MB for geopriv@ietf.org; Tue, 13 Mar 2007 10:03: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; Tue, 13 Mar 2007 10:00:28 -0400 id 0158838A.45F6AE7C.00003A2C In-Reply-To: <45F6884F.9090807@gmx.net> References: <45F6884F.9090807@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <49F6BA88-906D-4B3E-B58A-5D0E3CA07E13@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Geopriv] Geopriv Webpage Nit Date: Tue, 13 Mar 2007 10:03:12 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org On Mar 13, 2007, at 7:17 AM, Hannes Tschofenig wrote: > I think that the webpage should point to > http://www.rfc-editor.org/rfc/rfc4776.txt > instead of > http://www.ietf.org/rfc/rfc4676.txt > when pointing to "Dynamic Host Configuration Protocol (DHCPv4 and > DHCPv6) Option for Civic Addresses Configuration Information" So does James Winterbottom, who pointed this out to me sometime back. I agree with both of you and have asked the secretariat to fix the page. Perhaps I sacrificed the wrong type of chicken when making the request. -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 10: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 1HR7uS-0006u3-52; Tue, 13 Mar 2007 10:23:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR7uR-0006tu-Be for geopriv@ietf.org; Tue, 13 Mar 2007 10:23:27 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR7uP-0008Bd-TR for geopriv@ietf.org; Tue, 13 Mar 2007 10:23: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; Tue, 13 Mar 2007 10:20:38 -0400 id 01588423.45F6B336.00004005 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2C1C95FD-9969-4ABC-8A35-E0A312E9D241@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Geopriv] NENA Requirements Date: Tue, 13 Mar 2007 10:23:23 -0400 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: Ted Hardie , GEOPRIV , Marc Linsner X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Martin, It is actually quite appropriate for the IETF to determine the scope of its own work. The IETF is not at the beck and call of other organizations, just as they are not at the beck and call of the IETF. And we do have the right to question requirements, and it says a lot if those requirements cannot stand up to scrutiny. And the IETF does have a right to apply its broad collective of knowledge and experience on networking to a specific topic area, regardless of how you feel about any individual's investment in the problem space. With respect to NENA, it is rude of you to suggest that others on this list are not respectful towards it. I and several others on this list are agents of entities that have contributed non-trivial amounts of funds to NENA so that it may continue its mission. NENA has a very important role to fill, one which the IETF cannot and will not take on. -andy, co-chair of GEOPRIV On Mar 13, 2007, at 1:55 AM, Dawson, Martin wrote: > It's actually quite inappropriate for the IETF to be stating what the > policies for emergency services in global jurisdictions needs to be. > James' rules below may, indeed, be a strawman but they represent one > possible set of rules that one possible jurisdiction may wish to > adopt. > > It is an act of hubris for the IETF to deprive jurisdictions of these > mechanisms because individuals who aren't actually the ones who are > going to be the stakeholders didn't think it could be handled > properly. > > NENA - who do represent a very broad cross-section of genuine > stakeholders - do consider that they have the chops to institute > something like VESA and make it work for them. I have the utmost > confidence that they will be able to make it work and that it will > contribute to the integrity, in a significant way, of the emergency > service. There's a tendency to be dismissive of their skills and > knowledge in these areas which I think is similarly patronising and > quite incorrect. They have more experience in making complex networks, > organizations, and processes work than most of the commentators on > this > list. I say give them the tools they are asking for. > > Things evolve. In the long term it may actually be considered > unacceptable for an access network to not provide a robust > mechanism for > instantaneous location determination rather than "attachment time" > location. I suggest that it will always be possible to do this, > regardless of access technology, given the right approach. Ideally the > capabilities of networks won't be frozen in time and they will become > more sophisticated in this respect as time goes by. > > On point 4 - you may argue that the "accountability" aspect is not an > engineering requirement. Perhaps not; it's a service requirement > and it > creates the opportunity to provide an engineering solution. There is > very real value in being able to reliably associate the location with > the source so that errors in the system can be traced to that > source and > corrected. Closing the loop in this way for continuous improvement is > part of the existing switched circuit telephony emergency service > processes and there's no less of an imperative for it for IP > telephony. > Yet another of the uses of signed location is in providing this robust > link back to the source for this purpose; it's an engineering solution > that suggests itself. > > Cheers, > Martin > > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Tuesday, 13 March 2007 3:35 PM > To: Winterbottom, James; Marc Linsner; Dawson, Martin > Cc: GEOPRIV > Subject: RE: [Geopriv] NENA Requirements > > At 6:44 PM -0500 3/12/07, Winterbottom, James wrote: >> The 4 requirements I am tabling are below. >> >> 1) The only calls that SHALL be directed to a PSAP are those calls >> that >> have been made by end-devices that are in the PSAP service >> jurisdiction >> at the time a call is made. >> > > This goes contrary to everything we have discussed before, where the > theory has been that the call taker would try to take a call in any > circumstance, and these indicators would be used at most for ranking. > > To link this to the "warnings" thread on Ecrit right now, we're saying > there that there will be cases where a server should return a default, > a stale answer, or similar, because it cannot parse the request, > cannot > reach an upstream for the data, or cannot confirm its freshness. It > returns *a valid PSAP*, even if the request had an unresolvable > address, because doing so may save lives. Sure, that call should > have health warnings and may affect the queuing by call takers, > but saying you won't deliver the call because *you cannot confirm > at call time that the end device is within the PSAP jurisdiction* > will > kill someone. I reject such a requirement utterly, and I hope the WG > agrees with me. Route the call, and let the local policy at the PSAP > decide > if you have to, but failing to route the call via system design is not > okay. > >> 2) Any location used by routing services or subsequent dispatch > services >> MUST unequivocally represent the physical position of the end- >> device at >> the time the location is proffered. >> > > This is a strawman, or at least I hope it is. A device that got its > location on > boot, cannot update it because of network issues, and presents its > position > to this system is behaving according to the best-effort nature of > the underlying network. While the phone system is waiting for me to > present > an "unequivocal" location, your strawman is burning up in the car fire > I was calling to report. > >> 3) Any request for location made to a LIS MUST result in either an >> error, or the current location of the target device being returned. >> > > And if the LIS has the location of the attachment point, but not the > target device, who resolves the problem? The end node, by presenting > the attachment point to the LIS for location (nice targeting system, > good luck!)? Or the LIS, which should return the likely service > area of > the > attachment point as a non-point response? If the latter, we may have > something useful for identifying useful PSAPs, but it is not the > target > device's > location for lots of systems in which the service area is large > (think: > WiMAX). > >> 4) The source of the location information MUST be identifiable and is >> accountable for the accuracy of the information provided. > > The second is not an engineering requirement, and the first would be > satisfied by a self-report for cases like enterprise networks. That > might well be useful for tracking ill-described locations and similar > post-facto analyses. But you're sprinkling crypto dust on it in the > hopes of recreating a system where the underlying mechanism is > totally different. With enough thrust the pig may fly, but it spoils > the bacon and irritates the pig. > > Ted > >> Providing you try to meet these 4 requirements I am happy. Simply > saying >> they can't be done and so they are not requirements, as has been said > in >> the past, is not acceptable. > > > > > >> Cheers >> James >> >> >> >> >> >>> -----Original Message----- >>> From: Marc Linsner [mailto:mlinsner@cisco.com] >>> Sent: Tuesday, 13 March 2007 2:50 AM >>> To: Dawson, Martin >>> Cc: 'GEOPRIV' >>> Subject: RE: [Geopriv] NENA Requirements >>> >>> Martin, >>> >>>> >>>> I think all of the NENA requirements have been raised and >>>> discussed - the latest concept to cause indigestion is >>>> location signing. >>> >>> >>> You have requirements mixed up with solutions. Signing location >> objects >>> is >>> a solution. I believe Ted nailed the requirement. >>> >>> -Marc- >>> >>> >>> >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www1.ietf.org/mailman/listinfo/geopriv >> >> --------------------------------------------------------------------- >> -- > ------------------------- >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> --------------------------------------------------------------------- >> -- > ------------------------- >> [mf2] >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2] > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 10:40: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 1HR8AL-0003QD-7j; Tue, 13 Mar 2007 10:39:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8AK-0003PD-Cf for geopriv@ietf.org; Tue, 13 Mar 2007 10:39:52 -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 1HR8AJ-00029n-1P for geopriv@ietf.org; Tue, 13 Mar 2007 10:39:52 -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, 13 Mar 2007 10:37:00 -0400 id 0158838A.45F6B70C.000044B7 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8EB273A4-5A33-47FC-A189-A44665DE1E23@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Geopriv] Brian Rosen on location signing Date: Tue, 13 Mar 2007 10:39:45 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org James, There are two issues here. One is about the requirement for location signing and the other is about technical details to accomplish location signing. The first is the issue I brought up based on Brian's comment, and the second is the issue you just brought up. 1) The justification for location signing has been about the non- spoofability of the location information. What I was noting was that if you believe so heavily in this requirement, then how can you justify location signing only for access networks that use L7-LCP and not those access networks that use DHCP, LLDP-MED, or other methods. If the justification is so important, shouldn't the problem be solved for those other access networks? 2) XML D-Sig has historically been no panacea. Many other SDOs have had to create or find other XML canonicalization methods. Perhaps the W3C has fixed this problem with a canonicalization specification that is more universal. As an example, the UDDI consortium struggled with which canonicalization specification to use. I've heard about this many other times. We were advised of these issues when we created RFC 4119 by the security area advisor. What I believe Brian has suggested is a canonicalization method that works across XML and the binary formats. Yes, this would be something we had to specify, but it doesn't sound unachievable since we know how location information can be represented in both forms. Taking the data, putting in canonical form to run a crypto signature over it, and passing that signature on is not an effort much greater than what you are suggesting. -andy On Mar 9, 2007, at 6:00 PM, Winterbottom, James wrote: > I am not in complete agreement with this position though I am a > proponent of location signing. > The standard container for location information in this forum is the > PIDF-LO, and this is something that we can easily address the signing > of. > > Attempting to come up with a signing mechanism that can support any > number of binary encoding schemes seems to me to be counter productive > and will likely have problems from a future-proofing perspective. > > Signing a PIDF-LO can provide the following characteristics: > 1) ties location to end-device > 2) ties signature to access provider > 3) ties end-device to location at specific point in time > 4) ties location to end-device for recipient if used with a conveyance > identity mechanism. > > It is unclear to me how you can achieve these things if all you get > is a > location element and a signature. There is a proposal on the table now > for how this can be done with a PIDF-LO, there has been talk over > signing LCI for nearly 2 years but not proposal has yet been made, and > it has is unclear precisely what would be signed, and how it would > address the 4 points above. > > Cheers > James > > > > > > > >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Saturday, 10 March 2007 7:58 AM >> To: Andrew Newton >> Cc: GEOPRIV WG >> Subject: Re: [Geopriv] Brian Rosen on location signing >> >> I would second Brian on those points. If we can agree that signed >> location objects are useful, then we should have a signed location >> object structure that's common across protocols, just like PIDF-LO is >> used for location across protocols. >> --RB >> >> Andrew Newton wrote: >>> Since I just spent the last half hour reviewing the mailing list > traffic >>> on location signing in my role as co-chair, I found that Brian Rosen >>> made a couple of points that were very interesting but also lightly >>> supported. And I tend to wonder why, since he supports location >> signing. >>> >>> Point 1. Location signing is much more than an L7-LCP issue. It > also >>> changes location conveyance and de-referenced locations. Is there >>> anybody that disagrees with this? Do participants realize this? >>> >>> Point 2. Brian has asserted that location signing should be applied > to >>> all location configuration protocols, not just L7-LCP. His > assertion is >>> that location signing for the emergency use case is applicable no > matter >>> how a UA acquires their location information. This brings up the >>> question, if the other proponents of location signing feel it is >>> important to deter spoofing, DoS, etc, why isn't location signing > always >>> important no matter how it is required? >>> >>> -andy >>> >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www1.ietf.org/mailman/listinfo/geopriv >>> >>> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2] > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 10:41: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 1HR8BR-0004hN-PW; Tue, 13 Mar 2007 10:41:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8BQ-0004hA-KQ for geopriv@ietf.org; Tue, 13 Mar 2007 10:41:00 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR8BO-0002M0-28 for geopriv@ietf.org; Tue, 13 Mar 2007 10:41:00 -0400 X-SEF-Processed: 5_0_0_910__2007_03_13_09_46_55 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, 13 Mar 2007 09:46:55 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 09:40:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] NENA Requirements Date: Tue, 13 Mar 2007 09:40:34 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] NENA Requirements Thread-Index: AcdleyrI9L3RML6+TmiRy1auOY/aTgAAZTyW References: <2C1C95FD-9969-4ABC-8A35-E0A312E9D241@hxr.us> From: "Dawson, Martin" To: "Andrew Newton" X-OriginalArrivalTime: 13 Mar 2007 14:40:57.0513 (UTC) FILETIME=[9C8CA990:01C7657D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: Ted Hardie , GEOPRIV , Marc Linsner X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org And is it more appropriate that NENA establish the policies governing how a= nd when emergency calls are treated, where they are directed, when they are= answered and what criteria should be used to exercise those policies - or = is it more appropriate for the IETF to do that. I don't intend to be rude b= ut I do feel the need to point out that the arguments being made against th= e proposal appear to be based on the assumption that NENA are not capable o= f understanding the implications of the technologies involved - and I think= that is incorrect.=0D=0A=20=0D=0AI don't think that any of the NENA requir= ements have failed to stand up to scrutiny - there are just some people who= don't want to accept them. I think their views are mistaken but, in any ca= se, why should we not define protocols with the capabilities that the domai= n experts have requested=3F=0D=0A=20=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A__= ______________________________=0D=0A=0D=0AFrom: Andrew Newton [mailto:andy@= hxr.us]=0D=0ASent: Wed 3/14/2007 1:23 AM=0D=0ATo: Dawson, Martin=0D=0ACc: T= ed Hardie; Winterbottom, James; Marc Linsner; GEOPRIV=0D=0ASubject: Re: [Ge= opriv] NENA Requirements=0D=0A=0D=0A=0D=0A=0D=0AMartin,=0D=0A=0D=0AIt is ac= tually quite appropriate for the IETF to determine the scope=20=0D=0Aof its= own work. The IETF is not at the beck and call of other=20=0D=0Aorganizat= ions, just as they are not at the beck and call of the=20=0D=0AIETF. And w= e do have the right to question requirements, and it says=20=0D=0Aa lot if = those requirements cannot stand up to scrutiny. And the=20=0D=0AIETF does = have a right to apply its broad collective of knowledge and=20=0D=0Aexperie= nce on networking to a specific topic area, regardless of how=20=0D=0Ayou f= eel about any individual's investment in the problem space.=0D=0A=0D=0AWith= respect to NENA, it is rude of you to suggest that others on=20=0D=0Athis = list are not respectful towards it. I and several others on this=20=0D=0Ali= st are agents of entities that have contributed non-trivial amounts=20=0D=0A= of funds to NENA so that it may continue its mission. NENA has a=20=0D=0Av= ery important role to fill, one which the IETF cannot and will not=20=0D=0A= take on.=0D=0A=0D=0A-andy, co-chair of GEOPRIV=0D=0A=0D=0AOn Mar 13, 2007, = at 1:55 AM, Dawson, Martin wrote:=0D=0A=0D=0A> It's actually quite inapprop= riate for the IETF to be stating what the=0D=0A> policies for emergency ser= vices in global jurisdictions needs to be.=0D=0A> James' rules below may, i= ndeed, be a strawman but they represent one=0D=0A> possible set of rules th= at one possible jurisdiction may wish to=20=0D=0A> adopt.=0D=0A>=0D=0A> It = is an act of hubris for the IETF to deprive jurisdictions of these=0D=0A> m= echanisms because individuals who aren't actually the ones who are=0D=0A> g= oing to be the stakeholders didn't think it could be handled=20=0D=0A> prop= erly.=0D=0A>=0D=0A> NENA - who do represent a very broad cross-section of g= enuine=0D=0A> stakeholders - do consider that they have the chops to instit= ute=0D=0A> something like VESA and make it work for them. I have the utmost=0D= =0A> confidence that they will be able to make it work and that it will=0D=0A= > contribute to the integrity, in a significant way, of the emergency=0D=0A= > service. There's a tendency to be dismissive of their skills and=0D=0A> k= nowledge in these areas which I think is similarly patronising and=0D=0A> q= uite incorrect. They have more experience in making complex networks,=0D=0A= > organizations, and processes work than most of the commentators on=20=0D=0A= > this=0D=0A> list. I say give them the tools they are asking for.=0D=0A>=0D= =0A> Things evolve. In the long term it may actually be considered=0D=0A> u= nacceptable for an access network to not provide a robust=20=0D=0A> mechani= sm for=0D=0A> instantaneous location determination rather than "attachment = time"=0D=0A> location. I suggest that it will always be possible to do this= ,=0D=0A> regardless of access technology, given the right approach. Ideally= the=0D=0A> capabilities of networks won't be frozen in time and they will = become=0D=0A> more sophisticated in this respect as time goes by.=0D=0A>=0D= =0A> On point 4 - you may argue that the "accountability" aspect is not an=0D= =0A> engineering requirement. Perhaps not; it's a service requirement=20=0D= =0A> and it=0D=0A> creates the opportunity to provide an engineering soluti= on. There is=0D=0A> very real value in being able to reliably associate the= location with=0D=0A> the source so that errors in the system can be traced= to that=20=0D=0A> source and=0D=0A> corrected. Closing the loop in this wa= y for continuous improvement is=0D=0A> part of the existing switched circui= t telephony emergency service=0D=0A> processes and there's no less of an im= perative for it for IP=20=0D=0A> telephony.=0D=0A> Yet another of the uses = of signed location is in providing this robust=0D=0A> link back to the sour= ce for this purpose; it's an engineering solution=0D=0A> that suggests itse= lf.=0D=0A>=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=0D=0A> -----Original Message= -----=0D=0A> From: Ted Hardie [mailto:hardie@qualcomm.com]=0D=0A> Sent: Tue= sday, 13 March 2007 3:35 PM=0D=0A> To: Winterbottom, James; Marc Linsner; D= awson, Martin=0D=0A> Cc: GEOPRIV=0D=0A> Subject: RE: [Geopriv] NENA Require= ments=0D=0A>=0D=0A> At 6:44 PM -0500 3/12/07, Winterbottom, James wrote:=0D= =0A>> The 4 requirements I am tabling are below.=0D=0A>>=0D=0A>> 1) The onl= y calls that SHALL be directed to a PSAP are those calls=20=0D=0A>> that=0D= =0A>> have been made by end-devices that are in the PSAP service=20=0D=0A>>= jurisdiction=0D=0A>> at the time a call is made.=0D=0A>>=0D=0A>=0D=0A> Thi= s goes contrary to everything we have discussed before, where the=0D=0A> th= eory has been that the call taker would try to take a call in any=0D=0A> ci= rcumstance, and these indicators would be used at most for ranking.=0D=0A>=0D= =0A> To link this to the "warnings" thread on Ecrit right now, we're saying=0D= =0A> there that there will be cases where a server should return a default,=0D= =0A> a stale answer, or similar, because it cannot parse the request,=20=0D= =0A> cannot=0D=0A> reach an upstream for the data, or cannot confirm its fr= eshness. It=0D=0A> returns *a valid PSAP*, even if the request had an unre= solvable=0D=0A> address, because doing so may save lives. Sure, that call = should=0D=0A> have health warnings and may affect the queuing by call taker= s,=0D=0A> but saying you won't deliver the call because *you cannot confirm=0D= =0A> at call time that the end device is within the PSAP jurisdiction*=20=0D= =0A> will=0D=0A> kill someone. I reject such a requirement utterly, and I = hope the WG=0D=0A> agrees with me. Route the call, and let the local polic= y at the PSAP=0D=0A> decide=0D=0A> if you have to, but failing to route the= call via system design is not=0D=0A> okay.=0D=0A>=0D=0A>> 2) Any location = used by routing services or subsequent dispatch=0D=0A> services=0D=0A>> MUS= T unequivocally represent the physical position of the end-=0D=0A>> device = at=0D=0A>> the time the location is proffered.=0D=0A>>=0D=0A>=0D=0A> This i= s a strawman, or at least I hope it is. A device that got its=0D=0A> locat= ion on=0D=0A> boot, cannot update it because of network issues, and present= s its=0D=0A> position=0D=0A> to this system is behaving according to the b= est-effort nature of=0D=0A> the underlying network. While the phone system= is waiting for me to=0D=0A> present=0D=0A> an "unequivocal" location, your= strawman is burning up in the car fire=0D=0A> I was calling to report.=0D=0A= >=0D=0A>> 3) Any request for location made to a LIS MUST result in either a= n=0D=0A>> error, or the current location of the target device being returne= d.=0D=0A>>=0D=0A>=0D=0A> And if the LIS has the location of the attachment = point, but not the=0D=0A> target device, who resolves the problem=3F The e= nd node, by presenting=0D=0A> the attachment point to the LIS for location = (nice targeting system,=0D=0A> good luck!)=3F Or the LIS, which should ret= urn the likely service=20=0D=0A> area of=0D=0A> the=0D=0A> attachment point= as a non-point response=3F If the latter, we may have=0D=0A> something us= eful for identifying useful PSAPs, but it is not the=20=0D=0A> target=0D=0A= > device's=0D=0A> location for lots of systems in which the service area is= large=20=0D=0A> (think:=0D=0A> WiMAX).=0D=0A>=0D=0A>> 4) The source of the= location information MUST be identifiable and is=0D=0A>> accountable for t= he accuracy of the information provided.=0D=0A>=0D=0A> The second is not an= engineering requirement, and the first would be=0D=0A> satisfied by a self= -report for cases like enterprise networks. That=0D=0A> might well be usef= ul for tracking ill-described locations and similar=0D=0A> post-facto analy= ses. But you're sprinkling crypto dust on it in the=0D=0A> hopes of recrea= ting a system where the underlying mechanism is=0D=0A> totally different. = With enough thrust the pig may fly, but it spoils=0D=0A> the bacon and irri= tates the pig.=0D=0A>=0D=0A> Ted=0D=0A>=0D=0A= >> Providing you try to meet these 4 requirements I am happy. Simply=0D=0A>= saying=0D=0A>> they can't be done and so they are not requirements, as has= been said=0D=0A> in=0D=0A>> the past, is not acceptable.=0D=0A>=0D=0A>=0D=0A= >=0D=0A>=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: Marc Linsner [= mailto:mlinsner@cisco.com]=0D=0A>>> Sent: Tuesday, 13 March 2007 2:50 AM=0D= =0A>>> To: Dawson, Martin=0D=0A>>> Cc: 'GEOPRIV'=0D=0A>>> Subject: RE: [Geo= priv] NENA Requirements=0D=0A>>>=0D=0A>>> Martin,=0D=0A>>>=0D=0A>>>>=0D=0A>= >>> I think all of the NENA requirements have been raised and=0D=0A>>>> dis= cussed - the latest concept to cause indigestion is=0D=0A>>>> location sign= ing.=0D=0A>>>=0D=0A>>>=0D=0A>>> You have requirements mixed up with solutio= ns. Signing location=0D=0A>> objects=0D=0A>>> is=0D=0A>>> a solution. I b= elieve Ted nailed the requirement.=0D=0A>>>=0D=0A>>> -Marc-=0D=0A>>>=0D=0A>= >>=0D=0A>>>=0D=0A>>> _______________________________________________=0D=0A>= >> Geopriv mailing list=0D=0A>>> Geopriv@ietf.org=0D=0A>>> https://www1.iet= f.org/mailman/listinfo/geopriv=0D=0A>>=0D=0A>> ----------------------------= -----------------------------------------=0D=0A>> --=0D=0A> ---------------= ----------=0D=0A>> This message is for the designated recipient only and ma= y=0D=0A>> contain privileged, proprietary, or otherwise private information= =2E=0D=0A>> If you have received it in error, please notify the sender=0D=0A= >> immediately and delete the original. Any unauthorized use of=0D=0A>> th= is email is prohibited.=0D=0A>> -------------------------------------------= --------------------------=0D=0A>> --=0D=0A> -------------------------=0D=0A= >> [mf2]=0D=0A>>=0D=0A>>=0D=0A>> __________________________________________= _____=0D=0A>> Geopriv mailing list=0D=0A>> Geopriv@ietf.org=0D=0A>> https:/= /www1.ietf.org/mailman/listinfo/geopriv=0D=0A>=0D=0A>=0D=0A> --------------= --------------------------------------------------------=0D=0A> -----------= ---------------=0D=0A> This message is for the designated recipient only an= d may=0D=0A> contain privileged, proprietary, or otherwise private informat= ion.=0D=0A> If you have received it in error, please notify the sender=0D=0A= > immediately and delete the original. Any unauthorized use of=0D=0A> this= email is prohibited.=0D=0A> ----------------------------------------------= ------------------------=0D=0A> --------------------------=0D=0A> [mf2]=0D=0A= >=0D=0A>=0D=0A> _______________________________________________=0D=0A> Geop= riv mailing list=0D=0A> Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailm= an/listinfo/geopriv=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A--------------------------= ----------------------------------------------------------------------=0D=0A= This message is for the designated recipient only and may=0D=0Acontain priv= ileged, 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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 10:42: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 1HR8D8-0005wS-M2; Tue, 13 Mar 2007 10:42:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8D7-0005uv-6g for geopriv@ietf.org; Tue, 13 Mar 2007 10:42:45 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR8D6-0002at-Hz for geopriv@ietf.org; Tue, 13 Mar 2007 10:42:45 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HR8Cx-0005hf-Bc; Tue, 13 Mar 2007 09:42:35 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Dawson, Martin'" Subject: RE: [Geopriv] NENA Requirements Date: Tue, 13 Mar 2007 10:42:40 -0400 Message-ID: <027301c7657d$dbabdf60$2f3c1f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <2C1C95FD-9969-4ABC-8A35-E0A312E9D241@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdleygCmJm50oJ+RB2PaCWq+C6B3AAAJhPQ 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: 025f8c5000216988bfe31585db759250 Cc: 'Ted Hardie' , 'GEOPRIV' , 'Marc Linsner' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Martin As a very frequent contributor to NENA, and specifically, someone who participated, albeit somewhat intermittently in the development of the requirements which you are referring to, I feel that we should point out that these specific requirements come primarily from me (in the case of several of the security related requirements) and James Winterbottom, although there are several other people who were involved. Although I have been working with NENA for several years now, I personally feel like I'm still the nethead in an otherwise bellhead environment there. We're telling them how IP networks behave and how they need to deal with them. They certainly tell us a lot about how the current system works, and how they use it. I don't think however, in this case, that you can really assert it is NENA that brought forth these requirements. We did it, and we pushed them through NENA. There isn't anything necessarily wrong with that; I just think you need to lay off some of the "NENA is the expert here" rhetoric. I don't even (personally) agree with some of them as written. It is, however, undeniably an approved NENA work product. I also feel somewhat uncomfortable with James' attempt to rewrite the NENA requirements. I wouldn't agree with how he characterizes them. I'm actually more on Andy's side with regard to what these mechanisms we are talking about are used for. I would say, however, that there is policy that guides how the mechanisms are used. It may well be in normal circumstances that calls with missing or invalid security checks are processed as a normal call, but with some alert to the call taker to be more careful. However, if the PSAP was under direct DoS attack, then it may be policy that calls with missing or invalid security checks are put on a queue that is answered less promptly than calls that have all the security mechanisms in place and working, or those calls may be chosen to be diverted to another PSAP. That might depend on the attack signature (and the policy). Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Tuesday, March 13, 2007 10:23 AM > To: Dawson, Martin > Cc: Ted Hardie; GEOPRIV; Marc Linsner > Subject: Re: [Geopriv] NENA Requirements > > Martin, > > It is actually quite appropriate for the IETF to determine the scope > of its own work. The IETF is not at the beck and call of other > organizations, just as they are not at the beck and call of the > IETF. And we do have the right to question requirements, and it says > a lot if those requirements cannot stand up to scrutiny. And the > IETF does have a right to apply its broad collective of knowledge and > experience on networking to a specific topic area, regardless of how > you feel about any individual's investment in the problem space. > > With respect to NENA, it is rude of you to suggest that others on > this list are not respectful towards it. I and several others on this > list are agents of entities that have contributed non-trivial amounts > of funds to NENA so that it may continue its mission. NENA has a > very important role to fill, one which the IETF cannot and will not > take on. > > -andy, co-chair of GEOPRIV > > On Mar 13, 2007, at 1:55 AM, Dawson, Martin wrote: > > > It's actually quite inappropriate for the IETF to be stating what the > > policies for emergency services in global jurisdictions needs to be. > > James' rules below may, indeed, be a strawman but they represent one > > possible set of rules that one possible jurisdiction may wish to > > adopt. > > > > It is an act of hubris for the IETF to deprive jurisdictions of these > > mechanisms because individuals who aren't actually the ones who are > > going to be the stakeholders didn't think it could be handled > > properly. > > > > NENA - who do represent a very broad cross-section of genuine > > stakeholders - do consider that they have the chops to institute > > something like VESA and make it work for them. I have the utmost > > confidence that they will be able to make it work and that it will > > contribute to the integrity, in a significant way, of the emergency > > service. There's a tendency to be dismissive of their skills and > > knowledge in these areas which I think is similarly patronising and > > quite incorrect. They have more experience in making complex networks, > > organizations, and processes work than most of the commentators on > > this > > list. I say give them the tools they are asking for. > > > > Things evolve. In the long term it may actually be considered > > unacceptable for an access network to not provide a robust > > mechanism for > > instantaneous location determination rather than "attachment time" > > location. I suggest that it will always be possible to do this, > > regardless of access technology, given the right approach. Ideally the > > capabilities of networks won't be frozen in time and they will become > > more sophisticated in this respect as time goes by. > > > > On point 4 - you may argue that the "accountability" aspect is not an > > engineering requirement. Perhaps not; it's a service requirement > > and it > > creates the opportunity to provide an engineering solution. There is > > very real value in being able to reliably associate the location with > > the source so that errors in the system can be traced to that > > source and > > corrected. Closing the loop in this way for continuous improvement is > > part of the existing switched circuit telephony emergency service > > processes and there's no less of an imperative for it for IP > > telephony. > > Yet another of the uses of signed location is in providing this robust > > link back to the source for this purpose; it's an engineering solution > > that suggests itself. > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Ted Hardie [mailto:hardie@qualcomm.com] > > Sent: Tuesday, 13 March 2007 3:35 PM > > To: Winterbottom, James; Marc Linsner; Dawson, Martin > > Cc: GEOPRIV > > Subject: RE: [Geopriv] NENA Requirements > > > > At 6:44 PM -0500 3/12/07, Winterbottom, James wrote: > >> The 4 requirements I am tabling are below. > >> > >> 1) The only calls that SHALL be directed to a PSAP are those calls > >> that > >> have been made by end-devices that are in the PSAP service > >> jurisdiction > >> at the time a call is made. > >> > > > > This goes contrary to everything we have discussed before, where the > > theory has been that the call taker would try to take a call in any > > circumstance, and these indicators would be used at most for ranking. > > > > To link this to the "warnings" thread on Ecrit right now, we're saying > > there that there will be cases where a server should return a default, > > a stale answer, or similar, because it cannot parse the request, > > cannot > > reach an upstream for the data, or cannot confirm its freshness. It > > returns *a valid PSAP*, even if the request had an unresolvable > > address, because doing so may save lives. Sure, that call should > > have health warnings and may affect the queuing by call takers, > > but saying you won't deliver the call because *you cannot confirm > > at call time that the end device is within the PSAP jurisdiction* > > will > > kill someone. I reject such a requirement utterly, and I hope the WG > > agrees with me. Route the call, and let the local policy at the PSAP > > decide > > if you have to, but failing to route the call via system design is not > > okay. > > > >> 2) Any location used by routing services or subsequent dispatch > > services > >> MUST unequivocally represent the physical position of the end- > >> device at > >> the time the location is proffered. > >> > > > > This is a strawman, or at least I hope it is. A device that got its > > location on > > boot, cannot update it because of network issues, and presents its > > position > > to this system is behaving according to the best-effort nature of > > the underlying network. While the phone system is waiting for me to > > present > > an "unequivocal" location, your strawman is burning up in the car fire > > I was calling to report. > > > >> 3) Any request for location made to a LIS MUST result in either an > >> error, or the current location of the target device being returned. > >> > > > > And if the LIS has the location of the attachment point, but not the > > target device, who resolves the problem? The end node, by presenting > > the attachment point to the LIS for location (nice targeting system, > > good luck!)? Or the LIS, which should return the likely service > > area of > > the > > attachment point as a non-point response? If the latter, we may have > > something useful for identifying useful PSAPs, but it is not the > > target > > device's > > location for lots of systems in which the service area is large > > (think: > > WiMAX). > > > >> 4) The source of the location information MUST be identifiable and is > >> accountable for the accuracy of the information provided. > > > > The second is not an engineering requirement, and the first would be > > satisfied by a self-report for cases like enterprise networks. That > > might well be useful for tracking ill-described locations and similar > > post-facto analyses. But you're sprinkling crypto dust on it in the > > hopes of recreating a system where the underlying mechanism is > > totally different. With enough thrust the pig may fly, but it spoils > > the bacon and irritates the pig. > > > > Ted > > > >> Providing you try to meet these 4 requirements I am happy. Simply > > saying > >> they can't be done and so they are not requirements, as has been said > > in > >> the past, is not acceptable. > > > > > > > > > > > >> Cheers > >> James > >> > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: Marc Linsner [mailto:mlinsner@cisco.com] > >>> Sent: Tuesday, 13 March 2007 2:50 AM > >>> To: Dawson, Martin > >>> Cc: 'GEOPRIV' > >>> Subject: RE: [Geopriv] NENA Requirements > >>> > >>> Martin, > >>> > >>>> > >>>> I think all of the NENA requirements have been raised and > >>>> discussed - the latest concept to cause indigestion is > >>>> location signing. > >>> > >>> > >>> You have requirements mixed up with solutions. Signing location > >> objects > >>> is > >>> a solution. I believe Ted nailed the requirement. > >>> > >>> -Marc- > >>> > >>> > >>> > >>> _______________________________________________ > >>> Geopriv mailing list > >>> Geopriv@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/geopriv > >> > >> --------------------------------------------------------------------- > >> -- > > ------------------------- > >> This message is for the designated recipient only and may > >> contain privileged, proprietary, or otherwise private information. > >> If you have received it in error, please notify the sender > >> immediately and delete the original. Any unauthorized use of > >> this email is prohibited. > >> --------------------------------------------------------------------- > >> -- > > ------------------------- > >> [mf2] > >> > >> > >> _______________________________________________ > >> Geopriv mailing list > >> Geopriv@ietf.org > >> https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > ---------------------------------------------------------------------- > > -------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > ---------------------------------------------------------------------- > > -------------------------- > > [mf2] > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 11:12: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 1HR8fc-0000xC-BF; Tue, 13 Mar 2007 11:12:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8fb-0000vh-NA for geopriv@ietf.org; Tue, 13 Mar 2007 11:12:11 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR8fa-00088p-Fd for geopriv@ietf.org; Tue, 13 Mar 2007 11:12:11 -0400 X-SEF-Processed: 5_0_0_910__2007_03_13_10_18_08 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, 13 Mar 2007 10:18:07 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 10:12:10 -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: [Geopriv] NENA Requirements Date: Tue, 13 Mar 2007 10:11:27 -0500 Message-ID: In-Reply-To: <027301c7657d$dbabdf60$2f3c1f0a@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] NENA Requirements Thread-Index: AcdleygCmJm50oJ+RB2PaCWq+C6B3AAAJhPQAADQdtA= From: "Dawson, Martin" To: "Brian Rosen" , "Andrew Newton" X-OriginalArrivalTime: 13 Mar 2007 15:12:10.0138 (UTC) FILETIME=[F8B88FA0:01C76581] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: Ted Hardie , GEOPRIV , Marc Linsner X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I agree with everything you said Brian - with the exception that I=0D=0Adid= n't think James was attempting to rewrite the NENA requirements; I=0D=0Acer= tainly didn't infer that he was quoting them; perhaps because I'm=0D=0Afami= liar enough with them that I can see the difference. At some point=0D=0Ain = time, in some jurisdiction, the policies he tabled may quite credibly=0D=0A= become that strict.=0D=0A=0D=0ANENA is NENA and there are plenty of people = who are only comfortable=0D=0Awith their own domain but there are also plen= ty of people who are=0D=0Acomfortable with IP - that is my assessment - aft= er all, it is an old=0D=0Aprotocol suite and it's been used for plenty of s= ystems in the emergency=0D=0Ainfrastructure before it ever became a voice t= runking protocol. I have=0D=0Anever liked the nethead/bellhead language bec= ause I think it gives wings=0D=0Ato prejudice and clouds judgement. What I = am saying is that I believe=0D=0Athere is sufficient body of knowledge and = expertise in NENA to assess=0D=0Afor themselves the validity, value, and pr= acticality of having signed=0D=0Alocation. I think you do too. Particular i= ndividuals certainly did do a=0D=0Alion's share or the work in the migrator= y and location working groups in=0D=0ANENA but nothing was documented that = wasn't fully discussed, assessed,=0D=0Aand agreed by the wider group.=0D=0A=0D= =0ANENA are "the experts here" when it comes to requirements. People in=0D=0A= this working group are trying to say what emergency services policy=0D=0Ash= ould be and I believe that belongs with NENA for the US and equivalent=0D=0A= entities for other jurisdictions.=0D=0A=0D=0AWhat you suggest with respect = to call treatment is also perfectly valid=0D=0Aand I have cited the same po= licy in previous posts as an example of=0D=0Asomething realistic that the e= mergency jurisdiction may want to apply.=0D=0AIt's all perfectly sensible a= nd reasonable.=0D=0A=0D=0AThis debate isn't just about building up or putti= ng down NENA - I am=0D=0Atrying to ensure that the requirements of real end= users don't get=0D=0Aquashed because somebody felt those end users weren't= qualified to=0D=0Aarticulate their real needs. It goes directly to what re= levant outputs=0D=0Athis working group is going to define.=0D=0A=0D=0ACheer= s,=0D=0AMartin=20=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Brian Ro= sen [mailto:br@brianrosen.net]=20=0D=0ASent: Wednesday, 14 March 2007 1:43 = AM=0D=0ATo: 'Andrew Newton'; Dawson, Martin=0D=0ACc: 'Ted Hardie'; 'GEOPRIV= '; 'Marc Linsner'=0D=0ASubject: RE: [Geopriv] NENA Requirements=0D=0A=0D=0A= Martin=0D=0A=0D=0AAs a very frequent contributor to NENA, and specifically,= someone who=0D=0Aparticipated, albeit somewhat intermittently in the devel= opment of the=0D=0Arequirements which you are referring to, I feel that we = should point out=0D=0Athat these specific requirements come primarily from = me (in the case of=0D=0Aseveral of the security related requirements) and J= ames Winterbottom,=0D=0Aalthough there are several other people who were in= volved. Although I=0D=0Ahave=0D=0Abeen working with NENA for several years= now, I personally feel like I'm=0D=0Astill the nethead in an otherwise bel= lhead environment there. We're=0D=0Atelling=0D=0Athem how IP networks beha= ve and how they need to deal with them. They=0D=0Acertainly tell us a lot = about how the current system works, and how they=0D=0Ause=0D=0Ait. I don't= think however, in this case, that you can really assert it=0D=0Ais=0D=0ANE= NA that brought forth these requirements. We did it, and we pushed=0D=0Ath= em=0D=0Athrough NENA. There isn't anything necessarily wrong with that; I = just=0D=0Athink you need to lay off some of the "NENA is the expert here"=0D= =0Arhetoric. I=0D=0Adon't even (personally) agree with some of them as wri= tten. It is,=0D=0Ahowever,=0D=0Aundeniably an approved NENA work product.=0D= =0A=0D=0AI also feel somewhat uncomfortable with James' attempt to rewrite = the=0D=0ANENA=0D=0Arequirements. I wouldn't agree with how he characterize= s them. I'm=0D=0Aactually more on Andy's side with regard to what these me= chanisms we are=0D=0Atalking about are used for. =20=0D=0A=0D=0AI would say= , however, that there is policy that guides how the=0D=0Amechanisms=0D=0Aar= e used. It may well be in normal circumstances that calls with=0D=0Amissin= g or=0D=0Ainvalid security checks are processed as a normal call, but with = some=0D=0Aalert=0D=0Ato the call taker to be more careful. However, if the= PSAP was under=0D=0Adirect=0D=0ADoS attack, then it may be policy that cal= ls with missing or invalid=0D=0Asecurity checks are put on a queue that is = answered less promptly than=0D=0Acalls=0D=0Athat have all the security mech= anisms in place and working, or those=0D=0Acalls=0D=0Amay be chosen to be d= iverted to another PSAP. That might depend on the=0D=0Aattack signature (a= nd the policy).=0D=0A=0D=0ABrian=0D=0A=0D=0A> -----Original Message-----=0D= =0A> From: Andrew Newton [mailto:andy@hxr.us]=0D=0A> Sent: Tuesday, March 1= 3, 2007 10:23 AM=0D=0A> To: Dawson, Martin=0D=0A> Cc: Ted Hardie; GEOPRIV; = Marc Linsner=0D=0A> Subject: Re: [Geopriv] NENA Requirements=0D=0A>=20=0D=0A= > Martin,=0D=0A>=20=0D=0A> It is actually quite appropriate for the IETF to= determine the scope=0D=0A> of its own work. The IETF is not at the beck a= nd call of other=0D=0A> organizations, just as they are not at the beck and= call of the=0D=0A> IETF. And we do have the right to question requirement= s, and it says=0D=0A> a lot if those requirements cannot stand up to scruti= ny. And the=0D=0A> IETF does have a right to apply its broad collective of= knowledge and=0D=0A> experience on networking to a specific topic area, re= gardless of how=0D=0A> you feel about any individual's investment in the pr= oblem space.=0D=0A>=20=0D=0A> With respect to NENA, it is rude of you to su= ggest that others on=0D=0A> this list are not respectful towards it. I and = several others on this=0D=0A> list are agents of entities that have contrib= uted non-trivial amounts=0D=0A> of funds to NENA so that it may continue it= s mission. NENA has a=0D=0A> very important role to fill, one which the IE= TF cannot and will not=0D=0A> take on.=0D=0A>=20=0D=0A> -andy, co-chair of = GEOPRIV=0D=0A>=20=0D=0A> On Mar 13, 2007, at 1:55 AM, Dawson, Martin wrote:=0D= =0A>=20=0D=0A> > It's actually quite inappropriate for the IETF to be stati= ng what=0D=0Athe=0D=0A> > policies for emergency services in global jurisdi= ctions needs to be.=0D=0A> > James' rules below may, indeed, be a strawman = but they represent one=0D=0A> > possible set of rules that one possible jur= isdiction may wish to=0D=0A> > adopt.=0D=0A> >=0D=0A> > It is an act of hub= ris for the IETF to deprive jurisdictions of=0D=0Athese=0D=0A> > mechanisms= because individuals who aren't actually the ones who are=0D=0A> > going to= be the stakeholders didn't think it could be handled=0D=0A> > properly.=0D= =0A> >=0D=0A> > NENA - who do represent a very broad cross-section of genui= ne=0D=0A> > stakeholders - do consider that they have the chops to institut= e=0D=0A> > something like VESA and make it work for them. I have the utmost=0D= =0A> > confidence that they will be able to make it work and that it will=0D= =0A> > contribute to the integrity, in a significant way, of the emergency=0D= =0A> > service. There's a tendency to be dismissive of their skills and=0D=0A= > > knowledge in these areas which I think is similarly patronising and=0D=0A= > > quite incorrect. They have more experience in making complex=0D=0Anetwo= rks,=0D=0A> > organizations, and processes work than most of the commentato= rs on=0D=0A> > this=0D=0A> > list. I say give them the tools they are askin= g for.=0D=0A> >=0D=0A> > Things evolve. In the long term it may actually be= considered=0D=0A> > unacceptable for an access network to not provide a ro= bust=0D=0A> > mechanism for=0D=0A> > instantaneous location determination r= ather than "attachment time"=0D=0A> > location. I suggest that it will alwa= ys be possible to do this,=0D=0A> > regardless of access technology, given = the right approach. Ideally=0D=0Athe=0D=0A> > capabilities of networks won'= t be frozen in time and they will=0D=0Abecome=0D=0A> > more sophisticated i= n this respect as time goes by.=0D=0A> >=0D=0A> > On point 4 - you may argu= e that the "accountability" aspect is not=0D=0Aan=0D=0A> > engineering requ= irement. Perhaps not; it's a service requirement=0D=0A> > and it=0D=0A> > c= reates the opportunity to provide an engineering solution. There is=0D=0A> = > very real value in being able to reliably associate the location=0D=0Awit= h=0D=0A> > the source so that errors in the system can be traced to that=0D= =0A> > source and=0D=0A> > corrected. Closing the loop in this way for cont= inuous improvement=0D=0Ais=0D=0A> > part of the existing switched circuit t= elephony emergency service=0D=0A> > processes and there's no less of an imp= erative for it for IP=0D=0A> > telephony.=0D=0A> > Yet another of the uses = of signed location is in providing this=0D=0Arobust=0D=0A> > link back to t= he source for this purpose; it's an engineering=0D=0Asolution=0D=0A> > that= suggests itself.=0D=0A> >=0D=0A> > Cheers,=0D=0A> > Martin=0D=0A> >=0D=0A>= > -----Original Message-----=0D=0A> > From: Ted Hardie [mailto:hardie@qual= comm.com]=0D=0A> > Sent: Tuesday, 13 March 2007 3:35 PM=0D=0A> > To: Winter= bottom, James; Marc Linsner; Dawson, Martin=0D=0A> > Cc: GEOPRIV=0D=0A> > S= ubject: RE: [Geopriv] NENA Requirements=0D=0A> >=0D=0A> > At 6:44 PM -0500 = 3/12/07, Winterbottom, James wrote:=0D=0A> >> The 4 requirements I am tabli= ng are below.=0D=0A> >>=0D=0A> >> 1) The only calls that SHALL be directed = to a PSAP are those calls=0D=0A> >> that=0D=0A> >> have been made by end-de= vices that are in the PSAP service=0D=0A> >> jurisdiction=0D=0A> >> at the = time a call is made.=0D=0A> >>=0D=0A> >=0D=0A> > This goes contrary to ever= ything we have discussed before, where the=0D=0A> > theory has been that th= e call taker would try to take a call in any=0D=0A> > circumstance, and the= se indicators would be used at most for=0D=0Aranking.=0D=0A> >=0D=0A> > To = link this to the "warnings" thread on Ecrit right now, we're=0D=0Asaying=0D= =0A> > there that there will be cases where a server should return a=0D=0Ad= efault,=0D=0A> > a stale answer, or similar, because it cannot parse the re= quest,=0D=0A> > cannot=0D=0A> > reach an upstream for the data, or cannot c= onfirm its freshness. It=0D=0A> > returns *a valid PSAP*, even if the requ= est had an unresolvable=0D=0A> > address, because doing so may save lives. = Sure, that call should=0D=0A> > have health warnings and may affect the qu= euing by call takers,=0D=0A> > but saying you won't deliver the call becaus= e *you cannot confirm=0D=0A> > at call time that the end device is within = the PSAP jurisdiction*=0D=0A> > will=0D=0A> > kill someone. I reject such = a requirement utterly, and I hope the=0D=0AWG=0D=0A> > agrees with me. Rou= te the call, and let the local policy at the=0D=0APSAP=0D=0A> > decide=0D=0A= > > if you have to, but failing to route the call via system design is=0D=0A= not=0D=0A> > okay.=0D=0A> >=0D=0A> >> 2) Any location used by routing servi= ces or subsequent dispatch=0D=0A> > services=0D=0A> >> MUST unequivocally r= epresent the physical position of the end-=0D=0A> >> device at=0D=0A> >> th= e time the location is proffered.=0D=0A> >>=0D=0A> >=0D=0A> > This is a str= awman, or at least I hope it is. A device that got its=0D=0A> > location o= n=0D=0A> > boot, cannot update it because of network issues, and presents i= ts=0D=0A> > position=0D=0A> > to this system is behaving according to the = best-effort nature of=0D=0A> > the underlying network. While the phone sys= tem is waiting for me to=0D=0A> > present=0D=0A> > an "unequivocal" locatio= n, your strawman is burning up in the car=0D=0Afire=0D=0A> > I was calling = to report.=0D=0A> >=0D=0A> >> 3) Any request for location made to a LIS MUS= T result in either an=0D=0A> >> error, or the current location of the targe= t device being returned.=0D=0A> >>=0D=0A> >=0D=0A> > And if the LIS has the= location of the attachment point, but not the=0D=0A> > target device, who = resolves the problem=3F The end node, by=0D=0Apresenting=0D=0A> > the atta= chment point to the LIS for location (nice targeting system,=0D=0A> > good = luck!)=3F Or the LIS, which should return the likely service=0D=0A> > area= of=0D=0A> > the=0D=0A> > attachment point as a non-point response=3F If t= he latter, we may=0D=0Ahave=0D=0A> > something useful for identifying usefu= l PSAPs, but it is not the=0D=0A> > target=0D=0A> > device's=0D=0A> > locat= ion for lots of systems in which the service area is large=0D=0A> > (think:=0D= =0A> > WiMAX).=0D=0A> >=0D=0A> >> 4) The source of the location information= MUST be identifiable and=0D=0Ais=0D=0A> >> accountable for the accuracy of= the information provided.=0D=0A> >=0D=0A> > The second is not an engineeri= ng requirement, and the first would be=0D=0A> > satisfied by a self-report = for cases like enterprise networks. That=0D=0A> > might well be useful for= tracking ill-described locations and=0D=0Asimilar=0D=0A> > post-facto anal= yses. But you're sprinkling crypto dust on it in the=0D=0A> > hopes of rec= reating a system where the underlying mechanism is=0D=0A> > totally differe= nt. With enough thrust the pig may fly, but it=0D=0Aspoils=0D=0A> > the ba= con and irritates the pig.=0D=0A> >=0D=0A> > =09=09=09=09Ted=0D=0A> >=0D=0A= > >> Providing you try to meet these 4 requirements I am happy. Simply=0D=0A= > > saying=0D=0A> >> they can't be done and so they are not requirements, a= s has been=0D=0Asaid=0D=0A> > in=0D=0A> >> the past, is not acceptable.=0D=0A= > >=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> >> Cheers=0D=0A> >> James=0D= =0A> >>=0D=0A> >>=0D=0A> >>=0D=0A> >>=0D=0A> >>=0D=0A> >>> -----Original Me= ssage-----=0D=0A> >>> From: Marc Linsner [mailto:mlinsner@cisco.com]=0D=0A>= >>> Sent: Tuesday, 13 March 2007 2:50 AM=0D=0A> >>> To: Dawson, Martin=0D=0A= > >>> Cc: 'GEOPRIV'=0D=0A> >>> Subject: RE: [Geopriv] NENA Requirements=0D=0A= > >>>=0D=0A> >>> Martin,=0D=0A> >>>=0D=0A> >>>>=0D=0A> >>>> I think all of = the NENA requirements have been raised and=0D=0A> >>>> discussed - the late= st concept to cause indigestion is=0D=0A> >>>> location signing.=0D=0A> >>>=0D= =0A> >>>=0D=0A> >>> You have requirements mixed up with solutions. Signing= location=0D=0A> >> objects=0D=0A> >>> is=0D=0A> >>> a solution. I believe= Ted nailed the requirement.=0D=0A> >>>=0D=0A> >>> -Marc-=0D=0A> >>>=0D=0A>= >>>=0D=0A> >>>=0D=0A> >>> _______________________________________________=0D= =0A> >>> Geopriv mailing list=0D=0A> >>> Geopriv@ietf.org=0D=0A> >>> https:= //www1.ietf.org/mailman/listinfo/geopriv=0D=0A> >>=0D=0A> >>=0D=0A---------= ------------------------------------------------------------=0D=0A> >> --=0D= =0A> > -------------------------=0D=0A> >> This message is for the designat= ed recipient only and may=0D=0A> >> contain privileged, proprietary, or oth= erwise private information.=0D=0A> >> If you have received it in error, ple= ase notify the sender=0D=0A> >> immediately and delete the original. Any u= nauthorized use of=0D=0A> >> this email is prohibited.=0D=0A> >>=0D=0A-----= ----------------------------------------------------------------=0D=0A> >> = --=0D=0A> > -------------------------=0D=0A> >> [mf2]=0D=0A> >>=0D=0A> >>=0D= =0A> >> _______________________________________________=0D=0A> >> Geopriv m= ailing list=0D=0A> >> Geopriv@ietf.org=0D=0A> >> https://www1.ietf.org/mail= man/listinfo/geopriv=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A----------------------= ------------------------------------------------=0D=0A> > -----------------= ---------=0D=0A> > This message is for the designated recipient only and ma= y=0D=0A> > contain privileged, proprietary, or otherwise private informatio= n.=0D=0A> > If you have received it in error, please notify the sender=0D=0A= > > immediately and delete the original. Any unauthorized use of=0D=0A> > = this email is prohibited.=0D=0A> >=0D=0A-----------------------------------= -----------------------------------=0D=0A> > --------------------------=0D=0A= > > [mf2]=0D=0A> >=0D=0A> >=0D=0A> > ______________________________________= _________=0D=0A> > Geopriv mailing list=0D=0A> > Geopriv@ietf.org=0D=0A> > = https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A>=20=0D=0A>=20=0D=0A> _= ______________________________________________=0D=0A> Geopriv mailing list=0D= =0A> Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D= =0A=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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 11:21: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 1HR8oS-0002Sa-9M; Tue, 13 Mar 2007 11:21:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8oQ-0002ST-FI for geopriv@ietf.org; Tue, 13 Mar 2007 11:21:18 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR8oN-0001jw-26 for geopriv@ietf.org; Tue, 13 Mar 2007 11:21:18 -0400 X-SEF-Processed: 5_0_0_910__2007_03_13_10_27_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); Tue, 13 Mar 2007 10:27:12 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 10:21:14 -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: [Geopriv] Brian Rosen on location signing Date: Tue, 13 Mar 2007 10:21:07 -0500 Message-ID: In-Reply-To: <8EB273A4-5A33-47FC-A189-A44665DE1E23@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Brian Rosen on location signing Thread-Index: AcdlfZOzn8cT8EmaSV6q9kEbP+2uHgABLpbw From: "Dawson, Martin" To: "Andrew Newton" , "Winterbottom, James" X-OriginalArrivalTime: 13 Mar 2007 15:21:14.0607 (UTC) FILETIME=[3D3FEFF0:01C76583] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Well I think that'd be great. I'd certainly prefer to discuss ways to=0D=0A= unify the ways to sign location than to spend time arguing about whether=0D= =0Awe are going to let the end users have location signing to begin with.=0D= =0A=0D=0ADHCP and LLDP-MED are essentially the same form of location=0D=0Ar= epresentation right and they don't use PIDF-LO as do at least some of=0D=0A= the candidate "L7" (I really hate the label) protocols do=3F=0D=0A=0D=0ANow= - SIP conveyance assumes a PIDF-LO form and, certainly, the NENA i2=0D=0Aa= rchitecture stated PIDF-LO as the standard representation.=0D=0A=0D=0AWhat = would the mechanics be, then, between the point of querying the=0D=0ADHCP s= erver or LLDP-MED-enabled switch port for location and the point=0D=0Aof di= spatching the PIDF-LO in the SIP signalling=3F That is where and how=0D=0Ac= ould the signature components be generated and transported=3F=0D=0A=0D=0ACh= eers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Andrew N= ewton [mailto:andy@hxr.us]=20=0D=0ASent: Wednesday, 14 March 2007 1:40 AM=0D= =0ATo: Winterbottom, James=0D=0ACc: GEOPRIV WG=0D=0ASubject: Re: [Geopriv] = Brian Rosen on location signing=0D=0A=0D=0AJames,=0D=0A=0D=0AThere are two = issues here. One is about the requirement for location =20=0D=0Asigning an= d the other is about technical details to accomplish =20=0D=0Alocation sign= ing. The first is the issue I brought up based on =20=0D=0ABrian's comment= , and the second is the issue you just brought up.=0D=0A=0D=0A1) The justif= ication for location signing has been about the non-=20=0D=0Aspoofability o= f the location information. What I was noting was that =20=0D=0Aif you bel= ieve so heavily in this requirement, then how can you =20=0D=0Ajustify loca= tion signing only for access networks that use L7-LCP and =20=0D=0Anot thos= e access networks that use DHCP, LLDP-MED, or other methods. =20=0D=0AIf t= he justification is so important, shouldn't the problem be solved =20=0D=0A= for those other access networks=3F=0D=0A=0D=0A2) XML D-Sig has historically= been no panacea. Many other SDOs have =20=0D=0Ahad to create or find othe= r XML canonicalization methods. Perhaps =20=0D=0Athe W3C has fixed this pr= oblem with a canonicalization specification =20=0D=0Athat is more universal= =2E As an example, the UDDI consortium struggled =20=0D=0Awith which canon= icalization specification to use. I've heard about =20=0D=0Athis many othe= r times. We were advised of these issues when we =20=0D=0Acreated RFC 4119= by the security area advisor.=0D=0A=0D=0AWhat I believe Brian has suggeste= d is a canonicalization method that =20=0D=0Aworks across XML and the binar= y formats. Yes, this would be =20=0D=0Asomething we had to specify, but it= doesn't sound unachievable since =20=0D=0Awe know how location information= can be represented in both forms. =20=0D=0ATaking the data, putting in ca= nonical form to run a crypto signature =20=0D=0Aover it, and passing that s= ignature on is not an effort much greater =20=0D=0Athan what you are sugges= ting.=0D=0A=0D=0A-andy=0D=0A=0D=0AOn Mar 9, 2007, at 6:00 PM, Winterbottom,= James wrote:=0D=0A=0D=0A> I am not in complete agreement with this positio= n though I am a=0D=0A> proponent of location signing.=0D=0A> The standard c= ontainer for location information in this forum is the=0D=0A> PIDF-LO, and = this is something that we can easily address the signing=0D=0A> of.=0D=0A>=0D= =0A> Attempting to come up with a signing mechanism that can support any=0D= =0A> number of binary encoding schemes seems to me to be counter productive=0D= =0A> and will likely have problems from a future-proofing perspective.=0D=0A= >=0D=0A> Signing a PIDF-LO can provide the following characteristics:=0D=0A= > 1) ties location to end-device=0D=0A> 2) ties signature to access provide= r=0D=0A> 3) ties end-device to location at specific point in time=0D=0A> 4)= ties location to end-device for recipient if used with a conveyance=0D=0A>= identity mechanism.=0D=0A>=0D=0A> It is unclear to me how you can achieve = these things if all you get =20=0D=0A> is a=0D=0A> location element and a s= ignature. There is a proposal on the table now=0D=0A> for how this can be d= one with a PIDF-LO, there has been talk over=0D=0A> signing LCI for nearly = 2 years but not proposal has yet been made, and=0D=0A> it has is unclear pr= ecisely what would be signed, and how it would=0D=0A> address the 4 points = above.=0D=0A>=0D=0A> Cheers=0D=0A> James=0D=0A>=0D=0A>=0D=0A>=0D=0A>=0D=0A>=0D= =0A>=0D=0A>=0D=0A>> -----Original Message-----=0D=0A>> From: Richard Barnes= [mailto:rbarnes@bbn.com]=0D=0A>> Sent: Saturday, 10 March 2007 7:58 AM=0D=0A= >> To: Andrew Newton=0D=0A>> Cc: GEOPRIV WG=0D=0A>> Subject: Re: [Geopriv] = Brian Rosen on location signing=0D=0A>>=0D=0A>> I would second Brian on tho= se points. If we can agree that signed=0D=0A>> location objects are useful= , then we should have a signed location=0D=0A>> object structure that's com= mon across protocols, just like PIDF-LO is=0D=0A>> used for location across= protocols.=0D=0A>> --RB=0D=0A>>=0D=0A>> Andrew Newton wrote:=0D=0A>>> Sinc= e I just spent the last half hour reviewing the mailing list=0D=0A> traffic=0D= =0A>>> on location signing in my role as co-chair, I found that Brian Rosen=0D= =0A>>> made a couple of points that were very interesting but also lightly=0D= =0A>>> supported. And I tend to wonder why, since he supports location=0D=0A= >> signing.=0D=0A>>>=0D=0A>>> Point 1. Location signing is much more than a= n L7-LCP issue. It=0D=0A> also=0D=0A>>> changes location conveyance and de= -referenced locations. Is there=0D=0A>>> anybody that disagrees with this=3F= Do participants realize this=3F=0D=0A>>>=0D=0A>>> Point 2. Brian has asse= rted that location signing should be applied=0D=0A> to=0D=0A>>> all locatio= n configuration protocols, not just L7-LCP. His=0D=0A> assertion is=0D=0A>= >> that location signing for the emergency use case is applicable no=0D=0A>= matter=0D=0A>>> how a UA acquires their location information. This brings= up the=0D=0A>>> question, if the other proponents of location signing feel= it is=0D=0A>>> important to deter spoofing, DoS, etc, why isn't location s= igning=0D=0A> always=0D=0A>>> important no matter how it is required=3F=0D=0A= >>>=0D=0A>>> -andy=0D=0A>>>=0D=0A>>> ______________________________________= _________=0D=0A>>> Geopriv mailing list=0D=0A>>> Geopriv@ietf.org=0D=0A>>> = https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A>>>=0D=0A>>>=0D=0A>>=0D= =0A>>=0D=0A>> _______________________________________________=0D=0A>> Geopr= iv mailing list=0D=0A>> Geopriv@ietf.org=0D=0A>> https://www1.ietf.org/mail= man/listinfo/geopriv=0D=0A>=0D=0A> ----------------------------------------= ------------------------------=0D=0A=0D=0A> --------------------------=0D=0A= > This message is for the designated recipient only and may=0D=0A> contain = privileged, proprietary, or otherwise private information.=0D=0A> If you ha= ve received it in error, please notify the sender=0D=0A> immediately and de= lete the original. Any unauthorized use of=0D=0A> this email is prohibited= =2E=0D=0A> ----------------------------------------------------------------= ------=0D=0A=0D=0A> --------------------------=0D=0A> [mf2]=0D=0A>=0D=0A=0D= =0A=0D=0A_______________________________________________=0D=0AGeopriv maili= ng list=0D=0AGeopriv@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/listinfo/g= eopriv=0D=0A=0D=0A---------------------------------------------------------= ---------------------------------------=0D=0AThis message is for the design= ated recipient only and may=0D=0Acontain privileged, proprietary, or otherw= ise private information. =20=0D=0AIf you have received it in error, please = notify the sender=0D=0Aimmediately and delete the original. Any unauthoriz= ed use of=0D=0Athis email is prohibited.=0D=0A-----------------------------= -------------------------------------------------------------------=0D=0A[m= f2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 11:32: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 1HR8z5-0004oW-SE; Tue, 13 Mar 2007 11:32:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8z5-0004nw-0D for geopriv@ietf.org; Tue, 13 Mar 2007 11:32:19 -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 1HR8z3-0004n7-O2 for geopriv@ietf.org; Tue, 13 Mar 2007 11:32:18 -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, 13 Mar 2007 11:29:29 -0400 id 01588115.45F6C359.000052F1 In-Reply-To: References: Mime-Version: 1.0 Message-Id: <2466A53A-0D94-4199-B249-8647BBD9D8C1@hxr.us> From: Andrew Newton Subject: Re: [Geopriv] NENA Requirements Date: Tue, 13 Mar 2007 11:32:14 -0400 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Ted Hardie , GEOPRIV , Marc Linsner X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1716066773==" Errors-To: geopriv-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1716066773== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-21237-1173799770-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-21237-1173799770-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Mar 13, 2007, at 11:11 AM, Dawson, Martin wrote: > NENA are "the experts here" when it comes to requirements. People in > this working group are trying to say what emergency services policy > should be and I believe that belongs with NENA for the US and > equivalent > entities for other jurisdictions. Martin, I'm not sure what it is you are attempting to do, but to suggest that the IETF has no experts in the field of network security or Internet topology and cannot therefore apply that knowledge is quite simply wrong. Location signing has been offered as a requirement. It has been pointed out that location signing is a solution and not a requirement. It has also been pointed out that the notion of network topology that is being applied to VoIP by this solution does not match the way the Internet works. Also, it has been fair to question the actual use of location signing with respect to invalidly signed or unsigned location information. To date, nobody has offered an authoritative policy... it is all supposition. It seems rather silly to claim to be the authoritative voice on this issue when you cannot give concrete policy examples. -andy --=_zeke.ecotroph.net-21237-1173799770-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.54.2
On Mar 13, 2007, at 11:= 11 AM, Dawson, Martin wrote:

<= FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">NENA = are "the experts here" when it comes to requirements. People in
this working group are trying = to say what emergency services policy

should be and I believe that belongs with NENA for the U= S and equivalent

= enti= ties for other jurisdictions.

Mart= in,

I'm not su= re what it is you are attempting to do, but to suggest that the IETF has = no experts in the field of network security or Internet topology and cann= ot therefore apply that knowledge is quite simply wrong.

Location signing has been offe= red as a requirement.=A0 It has been pointed out that location signing is = a solution and not a requirement.=A0 It has also been pointed out that th= e notion of network topology that is being applied to VoIP by this soluti= on does not match the way the Internet works.

Also, it has been fair to question the ac= tual use of location signing with respect to invalidly signed or unsigned = location information.=A0 To date, nobody has offered an authoritative pol= icy... it is all supposition.=A0 It seems rather silly to claim to be the = authoritative voice on this issue when you cannot give concrete policy ex= amples.

-andy<= /DIV> --=_zeke.ecotroph.net-21237-1173799770-0001-2-- --===============1716066773== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1716066773==-- From geopriv-bounces@ietf.org Tue Mar 13 11:51:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR9Hl-0006ee-3y; Tue, 13 Mar 2007 11:51:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR9Hj-0006eS-Im for geopriv@ietf.org; Tue, 13 Mar 2007 11:51:35 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR9Hf-0001CP-9i for geopriv@ietf.org; Tue, 13 Mar 2007 11:51:35 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2DFpOdQ023903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 13 Mar 2007 11:51:28 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: GEOPRIV From: Henning Schulzrinne Date: Tue, 13 Mar 2007 11:46:42 -0400 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: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Geopriv] On signing X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I'd like to take a step back, as we seem to be conflating requirements with solutions, and thus probably narrowing the solution space. Leaving out many of the details and caveats, the goal appears to be to deal with two threats: (1) individual human crank callers, with two sub-cases (1a) crank caller far away from claimed incident location (1b) crank caller in vicinity of claimed incident (2) large-scale non-human DOS attacks (bot nets) (1b) is the typical pay phone call. Location signing does very little for that, as the location is not spoofed. Addressing (2) partially relies on restricting the number of possible attackers, by making sure that each bot only gets to make one call and that out-of-area attacks are more difficult. However, what's been missing in this discussion is accountability. The major reason that crank calls are a nuisance, rather than a major issue today, is that there is a traceback to the phone subscriber, so that the caller has to figure that there's a non-zero chance of having his rear end hauled into court. (Anybody who's been in a dormitory or university knows that pulling fire alarms is a popular pastime; there is no uncertainty about their location; cameras are a far more effective means of stopping these pranks.) Thus, I think the missing ingredient is accountability. If the caller knows that the PSAP knows their name, they are rather unlikely to run the risk of a false report citation. In that case, whether location information is signed or not is somewhat secondary. In other words, focusing only on location signing misses that there may be other, easier to deploy, tools that may in some cases be more effective. As a practical example, if a customer of a well-known VSP calls and the VSP says "yes, I know this subscriber", even if the call delivered to the PSAP is anonymous, there is a low chance that this will be a crank call. Accountability addresses both (1a) and (1b). Also, there are other, non-signing mechanisms that accomplish (2), at least with high probability. (I'm not arguing that location signing is never useful, just that we need to look at what we want to accomplish, rather than just one particular mechanism.) Henning _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 11:52:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR9Iw-0008Hf-DG; Tue, 13 Mar 2007 11:52:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR9Iv-0008HX-68 for geopriv@ietf.org; Tue, 13 Mar 2007 11:52:49 -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 1HR9It-0001Xq-Vf for geopriv@ietf.org; Tue, 13 Mar 2007 11:52: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; Tue, 13 Mar 2007 11:49:59 -0400 id 0158805C.45F6C827.00005AFD In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6BCD7DED-475B-467E-8CAA-95ABD68F3997@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Geopriv] Brian Rosen on location signing Date: Tue, 13 Mar 2007 11:52:45 -0400 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org On Mar 13, 2007, at 11:21 AM, Dawson, Martin wrote: > Well I think that'd be great. I'd certainly prefer to discuss ways to > unify the ways to sign location than to spend time arguing about > whether > we are going to let the end users have location signing to begin with. Certainly, one answer is to say "let us go forward with the caveats given; if it is unworkable in the field we'll have no choice than to find another solution." > DHCP and LLDP-MED are essentially the same form of location > representation right and they don't use PIDF-LO as do at least some of > the candidate "L7" (I really hate the label) protocols do? I believe that is correct. > Now - SIP conveyance assumes a PIDF-LO form and, certainly, the > NENA i2 > architecture stated PIDF-LO as the standard representation. > > What would the mechanics be, then, between the point of querying the > DHCP server or LLDP-MED-enabled switch port for location and the point > of dispatching the PIDF-LO in the SIP signalling? That is where and > how > could the signature components be generated and transported? Well, there could be a new DHCP option for requesting the signature. This signature could then be put in an element in PIDF-LO such as ........ If an L7 protocol populates that element, it would mean it went through the same process for canonicalizing and signing the data. -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 11:56:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR9Mm-0002qN-8E; Tue, 13 Mar 2007 11:56:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR9Ml-0002qI-IA for geopriv@ietf.org; Tue, 13 Mar 2007 11:56:47 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR9Mk-0002BP-9o for geopriv@ietf.org; Tue, 13 Mar 2007 11:56:47 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HR9MT-0002OM-52; Tue, 13 Mar 2007 11:56:29 -0400 Received: from [127.0.0.1] (col-dhcp33-244-154.bbn.com [128.33.244.154]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l2DFuRw11026; Tue, 13 Mar 2007 10:56:27 -0500 (EST) Message-ID: <45F6C995.5060500@bbn.com> Date: Tue, 13 Mar 2007 11:56:05 -0400 From: Richard Barnes User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Geopriv] NENA Requirements References: <2466A53A-0D94-4199-B249-8647BBD9D8C1@hxr.us> In-Reply-To: <2466A53A-0D94-4199-B249-8647BBD9D8C1@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Ted Hardie , "Dawson, Martin" , Marc Linsner , GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org > Location signing has been offered as a requirement. It has been pointed > out that location signing is a solution and not a requirement. It has > also been pointed out that the notion of network topology that is being > applied to VoIP by this solution does not match the way the Internet works. However, the security of voice services (emergency calling in particular) depends centrally on the trust relationships that are currently encoded in the topology of the PSTN. These trust relationships are what need to persist through the transition to an IP-based infrastructure. Public-key cryptography is how trust relationships are codified and communicated in the modern Internet community. From the little I know about it, NENA's VESA effort seems like a good example of this translation. --Richard > Also, it has been fair to question the actual use of location signing > with respect to invalidly signed or unsigned location information. To > date, nobody has offered an authoritative policy... it is all > supposition. It seems rather silly to claim to be the authoritative > voice on this issue when you cannot give concrete policy examples. > > -andy > > > ------------------------------------------------------------------------ > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 12:08: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 1HR9Xy-0007TR-3S; Tue, 13 Mar 2007 12:08:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR9Xw-0007TM-RL for geopriv@ietf.org; Tue, 13 Mar 2007 12:08:20 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR9Xt-0004gj-UB for geopriv@ietf.org; Tue, 13 Mar 2007 12:08:20 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Mar 2007 12:08:17 -0400 X-IronPort-AV: i="4.14,280,1170651600"; d="scan'208"; a="115530936:sNHT79292240" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2DG8HAf012550; Tue, 13 Mar 2007 12:08:17 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2DG7mZp006268; Tue, 13 Mar 2007 16:08:15 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 12:08:11 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 12:08:10 -0400 From: "Marc Linsner" To: "'Dawson, Martin'" Subject: RE: [Geopriv] NENA Requirements Date: Tue, 13 Mar 2007 12:08:09 -0400 Message-ID: <00df01c76589$cba8a2e0$230d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdleygCmJm50oJ+RB2PaCWq+C6B3AAAJhPQAADQdtAAAVQHMA== X-OriginalArrivalTime: 13 Mar 2007 16:08:10.0757 (UTC) FILETIME=[CBCE5350:01C76589] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=18112; t=1173802097; x=1174666097; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20NENA=20Requirements |Sender:=20 |To:=20=22'Dawson,=20Martin'=22=20; bh=+Mpm9WqfuIJeEUei+ocP/BrW81Z95rh5ZbZReOsb/J4=; b=0u/qPNntpmLa4YOB57js205UmLUDfbk10QRxCqYfOlHR4uAgoUefr0/O7i3+TUmYO9SHpV3o TIw1j8MJUSiklVTimCr13VZbxmW82N0TuXiZ7NnPZVVeY43qhmAgJw79; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a9ddb14fac983e71b59f23b52a45b4e Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Martin, I think the disconnect lies between the understanding of IP and the understanding of the Internet. NENA's knowledge/experience is with 'closed' single purpose systems, the Internet is an 'open' general use system. Closed single purpose will always perform the designed-for task better than a general purpose system. So, while lots of people clamor to additional attributes that IP can/will deliver to a PSAP, most within NENA don't understand the Internet architecture (note: IP knowledge does not equal Internet knowledge). The IETF can/will fill that knowledge void wrt how the Internet works. IMO, as a long-time NENA member and limited participant/casual observer of happenings inside NENA, several of the published NENA requirements were reverse engineered from an understood solution. Asking the IETF to exonorate the NENA solution will not produce the desired outcome. NENA MUST convey their raw requirements (hopefully in an Internet context) in order to foster a desire to solve their problems. A great deal of frustration is derived attempting to wade through the reverse engineered requirements to try and understand the real underlying requirement. And it is fact that not every requirement has an Internet solution (or spam would cease to exist). One large point that NENA has failed to admit in the Internet context is they will not control what is launched at them on the Internet from afar. This is not something they are used to in their current environment. I have hope that we'll get there....but I sense more pain in the future. -Marc- > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Tuesday, March 13, 2007 11:11 AM > To: Brian Rosen; Andrew Newton > Cc: Ted Hardie; GEOPRIV; Marc Linsner > Subject: RE: [Geopriv] NENA Requirements > > I agree with everything you said Brian - with the exception > that I didn't think James was attempting to rewrite the NENA > requirements; I certainly didn't infer that he was quoting > them; perhaps because I'm familiar enough with them that I > can see the difference. At some point in time, in some > jurisdiction, the policies he tabled may quite credibly > become that strict. > > NENA is NENA and there are plenty of people who are only > comfortable with their own domain but there are also plenty > of people who are comfortable with IP - that is my assessment > - after all, it is an old protocol suite and it's been used > for plenty of systems in the emergency infrastructure before > it ever became a voice trunking protocol. I have never liked > the nethead/bellhead language because I think it gives wings > to prejudice and clouds judgement. What I am saying is that I > believe there is sufficient body of knowledge and expertise > in NENA to assess for themselves the validity, value, and > practicality of having signed location. I think you do too. > Particular individuals certainly did do a lion's share or the > work in the migratory and location working groups in NENA but > nothing was documented that wasn't fully discussed, assessed, > and agreed by the wider group. > > NENA are "the experts here" when it comes to requirements. > People in this working group are trying to say what emergency > services policy should be and I believe that belongs with > NENA for the US and equivalent entities for other jurisdictions. > > What you suggest with respect to call treatment is also > perfectly valid and I have cited the same policy in previous > posts as an example of something realistic that the emergency > jurisdiction may want to apply. > It's all perfectly sensible and reasonable. > > This debate isn't just about building up or putting down NENA > - I am trying to ensure that the requirements of real end > users don't get quashed because somebody felt those end users > weren't qualified to articulate their real needs. It goes > directly to what relevant outputs this working group is going > to define. > > Cheers, > Martin > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, 14 March 2007 1:43 AM > To: 'Andrew Newton'; Dawson, Martin > Cc: 'Ted Hardie'; 'GEOPRIV'; 'Marc Linsner' > Subject: RE: [Geopriv] NENA Requirements > > Martin > > As a very frequent contributor to NENA, and specifically, > someone who participated, albeit somewhat intermittently in > the development of the requirements which you are referring > to, I feel that we should point out that these specific > requirements come primarily from me (in the case of several > of the security related requirements) and James Winterbottom, > although there are several other people who were involved. > Although I have been working with NENA for several years now, > I personally feel like I'm still the nethead in an otherwise > bellhead environment there. We're telling them how IP > networks behave and how they need to deal with them. They > certainly tell us a lot about how the current system works, > and how they use it. I don't think however, in this case, > that you can really assert it is NENA that brought forth > these requirements. We did it, and we pushed them through > NENA. There isn't anything necessarily wrong with that; I > just think you need to lay off some of the "NENA is the expert here" > rhetoric. I > don't even (personally) agree with some of them as written. > It is, however, undeniably an approved NENA work product. > > I also feel somewhat uncomfortable with James' attempt to > rewrite the NENA requirements. I wouldn't agree with how he > characterizes them. I'm actually more on Andy's side with > regard to what these mechanisms we are talking about are used for. > > I would say, however, that there is policy that guides how > the mechanisms are used. It may well be in normal > circumstances that calls with missing or invalid security > checks are processed as a normal call, but with some alert to > the call taker to be more careful. However, if the PSAP was > under direct DoS attack, then it may be policy that calls > with missing or invalid security checks are put on a queue > that is answered less promptly than calls that have all the > security mechanisms in place and working, or those calls may > be chosen to be diverted to another PSAP. That might depend > on the attack signature (and the policy). > > Brian > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Tuesday, March 13, 2007 10:23 AM > > To: Dawson, Martin > > Cc: Ted Hardie; GEOPRIV; Marc Linsner > > Subject: Re: [Geopriv] NENA Requirements > > > > Martin, > > > > It is actually quite appropriate for the IETF to determine > the scope > > of its own work. The IETF is not at the beck and call of other > > organizations, just as they are not at the beck and call of > the IETF. > > And we do have the right to question requirements, and it > says a lot > > if those requirements cannot stand up to scrutiny. And the > IETF does > > have a right to apply its broad collective of knowledge and > experience > > on networking to a specific topic area, regardless of how you feel > > about any individual's investment in the problem space. > > > > With respect to NENA, it is rude of you to suggest that > others on this > > list are not respectful towards it. I and several others on > this list > > are agents of entities that have contributed non-trivial amounts of > > funds to NENA so that it may continue its mission. NENA has a very > > important role to fill, one which the IETF cannot and will not take > > on. > > > > -andy, co-chair of GEOPRIV > > > > On Mar 13, 2007, at 1:55 AM, Dawson, Martin wrote: > > > > > It's actually quite inappropriate for the IETF to be stating what > the > > > policies for emergency services in global jurisdictions > needs to be. > > > James' rules below may, indeed, be a strawman but they > represent one > > > possible set of rules that one possible jurisdiction may wish to > > > adopt. > > > > > > It is an act of hubris for the IETF to deprive jurisdictions of > these > > > mechanisms because individuals who aren't actually the > ones who are > > > going to be the stakeholders didn't think it could be handled > > > properly. > > > > > > NENA - who do represent a very broad cross-section of genuine > > > stakeholders - do consider that they have the chops to institute > > > something like VESA and make it work for them. I have the utmost > > > confidence that they will be able to make it work and > that it will > > > contribute to the integrity, in a significant way, of the > emergency > > > service. There's a tendency to be dismissive of their skills and > > > knowledge in these areas which I think is similarly > patronising and > > > quite incorrect. They have more experience in making complex > networks, > > > organizations, and processes work than most of the > commentators on > > > this list. I say give them the tools they are asking for. > > > > > > Things evolve. In the long term it may actually be considered > > > unacceptable for an access network to not provide a > robust mechanism > > > for instantaneous location determination rather than "attachment > > > time" > > > location. I suggest that it will always be possible to do this, > > > regardless of access technology, given the right approach. Ideally > the > > > capabilities of networks won't be frozen in time and they will > become > > > more sophisticated in this respect as time goes by. > > > > > > On point 4 - you may argue that the "accountability" aspect is not > an > > > engineering requirement. Perhaps not; it's a service > requirement and > > > it creates the opportunity to provide an engineering > solution. There > > > is very real value in being able to reliably associate > the location > with > > > the source so that errors in the system can be traced to > that source > > > and corrected. Closing the loop in this way for continuous > > > improvement > is > > > part of the existing switched circuit telephony emergency service > > > processes and there's no less of an imperative for it for IP > > > telephony. > > > Yet another of the uses of signed location is in providing this > robust > > > link back to the source for this purpose; it's an engineering > solution > > > that suggests itself. > > > > > > Cheers, > > > Martin > > > > > > -----Original Message----- > > > From: Ted Hardie [mailto:hardie@qualcomm.com] > > > Sent: Tuesday, 13 March 2007 3:35 PM > > > To: Winterbottom, James; Marc Linsner; Dawson, Martin > > > Cc: GEOPRIV > > > Subject: RE: [Geopriv] NENA Requirements > > > > > > At 6:44 PM -0500 3/12/07, Winterbottom, James wrote: > > >> The 4 requirements I am tabling are below. > > >> > > >> 1) The only calls that SHALL be directed to a PSAP are > those calls > > >> that have been made by end-devices that are in the PSAP service > > >> jurisdiction at the time a call is made. > > >> > > > > > > This goes contrary to everything we have discussed > before, where the > > > theory has been that the call taker would try to take a > call in any > > > circumstance, and these indicators would be used at most for > ranking. > > > > > > To link this to the "warnings" thread on Ecrit right now, we're > saying > > > there that there will be cases where a server should return a > default, > > > a stale answer, or similar, because it cannot parse the request, > > > cannot reach an upstream for the data, or cannot confirm its > > > freshness. It returns *a valid PSAP*, even if the request had an > > > unresolvable address, because doing so may save lives. > Sure, that > > > call should have health warnings and may affect the > queuing by call > > > takers, but saying you won't deliver the call because *you cannot > > > confirm at call time that the end device is within the PSAP > > > jurisdiction* will kill someone. I reject such a requirement > > > utterly, and I hope the > WG > > > agrees with me. Route the call, and let the local policy at the > PSAP > > > decide > > > if you have to, but failing to route the call via system design is > not > > > okay. > > > > > >> 2) Any location used by routing services or subsequent dispatch > > > services > > >> MUST unequivocally represent the physical position of the end- > > >> device at the time the location is proffered. > > >> > > > > > > This is a strawman, or at least I hope it is. A device > that got its > > > location on > > > boot, cannot update it because of network issues, and presents its > > > position > > > to this system is behaving according to the best-effort nature of > > > the underlying network. While the phone system is > waiting for me to > > > present > > > an "unequivocal" location, your strawman is burning up in the car > fire > > > I was calling to report. > > > > > >> 3) Any request for location made to a LIS MUST result in > either an > > >> error, or the current location of the target device > being returned. > > >> > > > > > > And if the LIS has the location of the attachment point, > but not the > > > target device, who resolves the problem? The end node, by > presenting > > > the attachment point to the LIS for location (nice > targeting system, > > > good luck!)? Or the LIS, which should return the likely service > > > area of > > > the > > > attachment point as a non-point response? If the latter, we may > have > > > something useful for identifying useful PSAPs, but it is not the > > > target > > > device's > > > location for lots of systems in which the service area is large > > > (think: > > > WiMAX). > > > > > >> 4) The source of the location information MUST be > identifiable and > is > > >> accountable for the accuracy of the information provided. > > > > > > The second is not an engineering requirement, and the > first would be > > > satisfied by a self-report for cases like enterprise > networks. That > > > might well be useful for tracking ill-described locations and > similar > > > post-facto analyses. But you're sprinkling crypto dust > on it in the > > > hopes of recreating a system where the underlying mechanism is > > > totally different. With enough thrust the pig may fly, but it > spoils > > > the bacon and irritates the pig. > > > > > > Ted > > > > > >> Providing you try to meet these 4 requirements I am happy. Simply > > > saying > > >> they can't be done and so they are not requirements, as has been > said > > > in > > >> the past, is not acceptable. > > > > > > > > > > > > > > > > > >> Cheers > > >> James > > >> > > >> > > >> > > >> > > >> > > >>> -----Original Message----- > > >>> From: Marc Linsner [mailto:mlinsner@cisco.com] > > >>> Sent: Tuesday, 13 March 2007 2:50 AM > > >>> To: Dawson, Martin > > >>> Cc: 'GEOPRIV' > > >>> Subject: RE: [Geopriv] NENA Requirements > > >>> > > >>> Martin, > > >>> > > >>>> > > >>>> I think all of the NENA requirements have been raised and > > >>>> discussed - the latest concept to cause indigestion is > > >>>> location signing. > > >>> > > >>> > > >>> You have requirements mixed up with solutions. Signing location > > >> objects > > >>> is > > >>> a solution. I believe Ted nailed the requirement. > > >>> > > >>> -Marc- > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> Geopriv mailing list > > >>> Geopriv@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/geopriv > > >> > > >> > --------------------------------------------------------------------- > > >> -- > > > ------------------------- > > >> This message is for the designated recipient only and may > > >> contain privileged, proprietary, or otherwise private > information. > > >> If you have received it in error, please notify the sender > > >> immediately and delete the original. Any unauthorized use of > > >> this email is prohibited. > > >> > --------------------------------------------------------------------- > > >> -- > > > ------------------------- > > >> [mf2] > > >> > > >> > > >> _______________________________________________ > > >> Geopriv mailing list > > >> Geopriv@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > ---------------------------------------------------------------------- > > > -------------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > ---------------------------------------------------------------------- > > > -------------------------- > > > [mf2] > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 15:44: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 1HRCvG-0008CQ-Or; Tue, 13 Mar 2007 15:44:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRCvE-00086s-Vn for geopriv@ietf.org; Tue, 13 Mar 2007 15:44:36 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRCvD-0003yb-H7 for geopriv@ietf.org; Tue, 13 Mar 2007 15:44:36 -0400 Received: (qmail invoked by alias); 13 Mar 2007 19:44:34 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp051) with SMTP; 13 Mar 2007 20:44:34 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+dpTwj6YKdFc0OJ+Ui78EI8IwcMmjngX2MGsKycf +tmdS6xJP5IFlb Message-ID: <45F6FF21.5060605@gmx.net> Date: Tue, 13 Mar 2007 20:44:33 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Richard Barnes Subject: Re: [Geopriv] draft-marshall-geopriv-lbyr-requirements-01 References: <2EE96B90-FBD5-4C77-B382-14E9DC60B71B@cisco.com> <45F4930A.1040606@bbn.com> In-Reply-To: <45F4930A.1040606@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 1.1 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Richard, this issue was actually subject for a long debate given that we have two protocols for dereferencing on the table, SIP and HTTP. We obviously came to no conclusion on the requirements. Ciao Hannes Richard Barnes wrote: > I don't know of any such requirement, but it wouldn't be inconsistent > with the existing requirements: I think concept of a "dereference > protocol" discussed in the requirements is large enough to cover both > synchronous and asynchronous delivery. And I don't think any of the > requirements contradict an asynchronous model. > > --RB > > > > Cullen Jennings wrote: >> >> Is there a requirement for the LR to be asynchronously notified about >> location changes for an LRI that has not expired and that the LR >> dereferences? >> >> Cullen >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> >> > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 15:44: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 1HRCvB-000819-5n; Tue, 13 Mar 2007 15:44:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRCvA-00080w-48 for geopriv@ietf.org; Tue, 13 Mar 2007 15:44:32 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRCv7-0003vl-Ll for geopriv@ietf.org; Tue, 13 Mar 2007 15:44:32 -0400 Received: (qmail invoked by alias); 13 Mar 2007 19:44:23 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp028) with SMTP; 13 Mar 2007 20:44:23 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX182sNhqImc2kJvXbzfcBDfyW11CUmhILvRov/IbC5 vO+8Jhk0cosSop Message-ID: <45F6FF15.7050807@gmx.net> Date: Tue, 13 Mar 2007 20:44:21 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Dawson, Martin" Subject: Re: [Geopriv] NENA Requirements References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Martin, Dawson, Martin wrote: > Well, I do take exception to the suggestion that the NENA requirements > were introduced long after the design team work was done. The NENA > requirements were available in draft long before geopriv even came to > grips with beginning to accept the idea of an "L7" protocol. > NENA is slower than the IETF. Interesting :-) In that case it could have even been easier to share the requirements a long time ago instead of letting an entire group discuss requirements for a long time. > I certainly tried to get people to consider the requirements from NENA - > but spent most of my time responding to arguments about why opinions > driven by the i2 architecture weren't relevant ("architecture is broken" > as one commentator put it). I am sure it would have been possible to share a copy-and-paste version of the requirements as written in the document. I also recall my statement regarding the broken architecture. That was targeting the way how authorization was supposed to work with location retrieval creating artificial relationships between every VoIP provider and every access network provider: What a deployment nightmare! > It's impossible to discuss requirements > productively if some group of people simply think the source is > unqualified to present any and spend all their time trying to discredit > proposals on that basis. I hope you understand that not everybody immediately shares your excitement with every proposal. This is quite common in standardization. > Thank you for not smoking anyone? As I recall, > the specific point was about why LbyR was needed and it was before > geopriv had begun to assimilate the value of that concept as well. > > I think all of the NENA requirements have been raised and discussed - > the latest concept to cause indigestion is location signing. > Obviously not all of the requirements have been brought forward since some of them have been raised during the WGLC of the problem statement and the requirements document. Location signing is indeed still difficult. > I will put together a list of what I think all the requirements are that > have been raised - including the NENA ones and others subsequently > mentioned and try to get it out in a succinct form this week. > We just need to make sure that all the requirements are in the requirements document before we forward the document to the IESG. Doesn't that sound reasonable to you as well? Ciao Hannes > Cheers, > Martin > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Sunday, 11 March 2007 6:47 AM > To: GEOPRIV > Subject: [Geopriv] NENA Requirements > > Some reviewers of note that the > requirements in > http://www.nena.org/media/files/08-505_20061221.pdf also have to be > considered. > > Interestingly, this document was published long after the design > team work took place were these requirements could have been > introduced. > > > Here are the requirements and I will copy them in a separate mail: > > > 4 Requirements > > These requirements are excerpted from the NENA TRD, NENA Requirements > for Location Information to Support Emergency Services, for the > convenience of the reader. If this document should inadvertently differ > from the TRD, the TRD is to be considered the normative reference. > As defined in the TRD, and as excerpted here, the terms "shall", "must > ", > and "required" are used in this section to indicate requirements and > to differentiate from those parameters that are recommendations. > > Recommendations are identified by the word "should." Optional, > desirable capabilities are identified by the words "desirable" or > "preferably". > > 4.1 Location Determination and Acquisition > > DA1 - The access network shall provide a mechanism for determination > and acquisition of location information, and support queries for > location. > > DA2 - The location estimate used shall be that associated with the > physically (wire, fiber, air) connected network. > > DA3 - Location may be requested at any time. Location information must > be associated with the device at the time the location is requested. > > DA4 - Location acquisition should be provided by a consistent method > across all network configurations. > > DA5 - Location determination and acquisition mechanisms must be > applicable to emergency calling, and may also be applicable to a wide > range of value-added location-based services. > > DA6 - Location determination and acquisition techniques shall support > both NENA i2 and i3 network architectures. > > DA7 (Location 1400-0100 from LTD WG i3 rqmts) - When measurement > based-location determination mechanisms fail, the most accurate > location information available should be provided. Examples include: > For mobile, the Wireless Service Provider might provide tower/Access > Point location, last known fix, etc. For wireline, a LIS might provide > a civic location that defines the serving area of an access point, > e.g., the State of Texas. > > DA8 - Location determination and acquisition must provide minimal > impact to call setup time in the event that location is not known ahead > of time. > > DA9 - Where a device is not location aware the IP Access network should > have the ability to provide a location estimate on behalf of the > device. > > DA10 - Location acquisition methods should not require modification of > hardware/firmware in home-routers/modems. > > DA11 - A location determination method must exist that does not require > network hardware replacement. > > DA12 -- The location acquisition protocol shall allow the requesting > device to specify a response time requirement to the LIS when > requesting location information. The response time is expressed as the > maximum time that the requesting node is prepared to wait for location > information. The LIS is required to provide the most accurate location > fix it can within the specified response time. > > 4.2 Location Representation > > Location Representation refers to the form and contents that are used > to represent the geographic location of an Endpoint. > > Rep1 - Location information may be provided as location-by-value or > location-by-reference and the form is subject to the nature of the > request. > > Rep2 - Location determination and acquisition mechanisms must support > all location information fields defined within a PIDF-LO. > > Rep3 - Location acquisition mechanisms must allow for easy backwards > compatibility as the representation of location information evolves. > > Rep4 - All representations of location shall include the ability to > carry altitude and/or floor designation. This requirement does not > imply altitude and/or floor designation is always used or supplied. > > 4.3 Location Security and Dependability > > LocSec1 - Location information shall only be provided to authenticated > and authorized network devices. The degree of authentication and > authorization required may vary depending on the network. > > LocSec2 - Location determination and acquisition methods should > preserve privacy of location information, subject to local laws and > regulations. > > LocSec3 - The location or location estimate of a caller should be > dependable. > > LocSec4 - The location acquisition protocol must support authentication > of the Location Information Server, integrity protection of the > Location Information, and protection against replay. > > LocSec5 - The location source shall be identified and should be > authenticated. This includes manually entered location1. > > LocSec6 - Where a location is acquired and cached prior to an emergency > call, it should be refreshed at regular intervals to ensure that it is > as current as possible, in the event location information cannot be > obtained in real time. > > LocSec7 - Where location by-reference is used the appropriate privacy > policies must be implemented and enforced by the LIS operator. > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 15:44:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRCvQ-0000FT-08; Tue, 13 Mar 2007 15:44:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRCvO-00009h-Kc for geopriv@ietf.org; Tue, 13 Mar 2007 15:44:46 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRCvM-000406-Rg for geopriv@ietf.org; Tue, 13 Mar 2007 15:44:46 -0400 Received: (qmail invoked by alias); 13 Mar 2007 19:44:43 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp049) with SMTP; 13 Mar 2007 20:44:43 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18JgrsiRiUJmqu626oFVGUsTJR8IfqgUN7XehVwVP DyNdIHAc62BA3/ Message-ID: <45F6FF2A.9010303@gmx.net> Date: Tue, 13 Mar 2007 20:44:42 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Dawson, Martin" Subject: Re: [Geopriv] NENA Requirements References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Martin, please find my response below: >> 4.2 Location Representation >> >> Location Representation refers to the form and contents that are used >> to represent the geographic location of an Endpoint. >> >> Rep1 - Location information may be provided as location-by-value or >> location-by-reference and the form is subject to the nature of the >> request. >> >> Rep2 - Location determination and acquisition mechanisms must support >> all location information fields defined within a PIDF-LO. >> >> Rep3 - Location acquisition mechanisms must allow for easy backwards >> compatibility as the representation of location information evolves. >> >> Rep4 - All representations of location shall include the ability to >> carry altitude and/or floor designation. This requirement does not >> imply altitude and/or floor designation is always used or supplied. >> >> 4.3 Location Security and Dependability >> >> LocSec1 - Location information shall only be provided to authenticated >> and authorized network devices. The degree of authentication and >> authorization required may vary depending on the network. >> >> > I guess that this refers to location-by-reference only. > > [[MCD]] No, it's really a generic requirement. A device asking for its > own location on the access network covered by the LIS may be implicitly > authorized, an OBO request for that same device may require a different > level of authorization and, as you say, it may also apply to the > dereferencing request applied for that target. The applicable degree of > authorization for each scenario may be domain-specific. > > That's quite misleading. What type of authorization is "implicit authorization"? I fear that if authorization is "domain specific" then emergency services might just not work. >> LocSec2 - Location determination and acquisition methods should >> preserve privacy of location information, subject to local laws and >> regulations. >> >> LocSec3 - The location or location estimate of a caller should be >> dependable. >> > What does "dependable" mean in this context? > > [[MCD]] I am sure that this has been described numerous times already. > It's what we have been talking about viz location signing. It covers the > characteristics that the location information: > > * Can be attributed to a recognized source > * Has not been tampered with since generated at that source > * Is applicable to a specific target identity > * Is applicable at a particular point in time > > Wouldn't it be better to list these requirements instead of "dependability"? >> LocSec4 - The location acquisition protocol must support >> > authentication > >> of the Location Information Server, integrity protection of the >> Location Information, and protection against replay. >> >> LocSec5 - The location source shall be identified and should be >> authenticated. This includes manually entered location1. >> > > I wonder how this would look like. > [[MCD]] How what would look like > As discussed, the proposal is to > include certificate mechanisms to make the source of the location > information explicit. For location entered into a device, the assertion > mechanism may be used to have the LIS do this. Does not make sense to me. > More prosaically, and > consistent with the current FCC requirement Which FCC requirement do you exactly refer to? > that VoIP providers allow > their subscribers to enter their current location via a service provider > web page or equivalent, the location proffered on the call may similarly > identify the source of the location information. Would a signature cover the location? Would the signature point to the user or to the VoIP provider? What happens if I enter my location at my VoIP client that I use in my home network? Who would certify what? > This is not actually a > LIS protocol requirement but I'm sure it was what was on a lot of > people's minds when the requirement was being discussed - you know what > committees are like. > I think that the requirements need more text in order to be understood. "The location source should be authenticated." could also mean that you have to authenticate the LIS as part of the LCP exchange. > >> LocSec6 - Where a location is acquired and cached prior to an >> > emergency > >> call, it should be refreshed at regular intervals to ensure that it is >> as current as possible, in the event location information cannot be >> obtained in real time. >> >> > This is not a security requirement. > [[MCD]] Yes, it's not very well categorized - can't argue with that. > Generally speaking, it's a function of LIS implementation as well and > tends to be independent of the acquisition protocol used - though not > completely. > > >> LocSec7 - Where location by-reference is used the appropriate privacy >> policies must be implemented and enforced by the LIS operator. >> > > What does this mean in context of requirement LocSec2 ? > [[MCD]] The device requesting the reference can provide its privacy > policies and LIS must honour them. This sounds a little bit like a requirement tailored to a solution. > LocSec2 acknowledges that certain > some jurisdictions may need to override these (e.g. location for > emergency services). > Ciao Hannes > Ciao > Hannes > > >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 15:44: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 1HRCvC-00083U-EN; Tue, 13 Mar 2007 15:44:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRCvA-000814-SH for geopriv@ietf.org; Tue, 13 Mar 2007 15:44:32 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRCv9-0003wU-37 for geopriv@ietf.org; Tue, 13 Mar 2007 15:44:32 -0400 Received: (qmail invoked by alias); 13 Mar 2007 19:44:29 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp019) with SMTP; 13 Mar 2007 20:44:29 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18o8zcVYNMokzmGhCjbbSYC2c8zXu3jnO506dwrua EDx63jMBNaOJ2M Message-ID: <45F6FF19.2010500@gmx.net> Date: Tue, 13 Mar 2007 20:44:25 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Dawson, Martin" Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: geopriv@ietf.org, Barbara.Stark@BellSouth.com, lendl@nic.at, andy@hxr.us X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Martin, I will double-check with some location folks to have more than one opinion. I want to make sure that I also see the "there is a plenty of demand" indication. Ciao Hannes Dawson, Martin wrote: > Using civic for routing may work in the US where the MSAG is part of the legacy infrastructure. In other jurisdictions that I have spoken with, they would hate to have to develop this just for routing calls. As such a nominal geo associated with fixed wireline access points is also a requirement. Hence the need to be able to get both forms if possible. > > There is plenty of demand for a response time parameter and it is in the NENA requirements. It has a very valid application in doing location technology arbitration in wireless location measurement - it is used already in 2G and 3G location determination. There is nothing in IP Location that removes this requirement - your opinion not withstanding being valid as your opinion. > > Cheers, > Martin > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Sunday, 11 March 2007 7:00 AM > To: jerome.grenier@bell.ca > Cc: geopriv@ietf.org; Barbara.Stark@BellSouth.com; lendl@nic.at; andy@hxr.us > Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement > > Hi Jerome, > > jerome.grenier@bell.ca wrote: > >> I agree with Barbara and would also add : >> >> - ability to request geo and/or civic location >> >> > > Barbara previously said that geo-location does not make sense in the DSL > environment. > I guess you are pointing to a different environment. The question is > only: Is the LIS-to-LIS communication needed there as well? > > >> The "ability to specify how quickly a response is needed" would also be really helpful to us. >> >> > I don't think that this is useful for this particular application. > > >> Having a BCP (one or more) that recommends a syntax to express various identifier types for common protocols like SIP/PRES and HTTP would be great! >> >> >> > Ciao > Hanes > > >> J�r�me >> >> -----Message d'origine----- >> De : Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] >> Envoy� : 16 f�vrier 2007 10:05 >> � : Andrew Newton >> Cc : geopriv@ietf.org; Otmar Lendl >> Objet : RE: [Geopriv] Geopriv L7 LCP: New Requirement >> >> I hate to break ranks, but if we could get the user part figured out >> (and I do think we would need some standardization, even if it's just a >> BCP), I kind of like this proposed solution. It has a certain simplicity >> to it. >> >> Since we've been pushing for these LISs to support LbyR, anyway, and >> this is really just LbyR, I don't see it as being a different protocol, >> yet again. This is a protocol we'd expect to be supported by a LIS in >> any case. The only change is that the URI may require careful parsing by >> the queried LIS, and the querier LIS needs to support LbyR queries in >> both directions. >> >> When I look at the functions in HELD (and RELO has a subset of these), >> and think through which of those functions would I really need for >> LIS-LIS or OBO, I come up with: >> - ability to request reference -- not needed, since, as pointed out, >> I've already got a perfectly good non-expiring reference; OBO querier or >> LIS doesn't need to ask for references to hand off to others, it should >> create its own references for that, as appropriate [aside: a >> non-expiring reference and a "LCP" are rather equal in the privacy >> debate from the OBO/LIS-LIS perspective.] >> - ability to assert location -- not needed for OBO or LIS-LIS; only an >> end device should be able to do this, if even that is allowed >> - ability to provide rules/profile for privacy -- not needed for OBO or >> LIS-LIS; only the device should be able to do this >> - ability to sign location -- if this is part of PIDF-LO, then this is >> independent of request mechanism >> - ability to request that location be signed -- I think we can assume >> that the location should be signed if it can be signed >> - ability to specify how quickly a response is needed -- this would be >> useful, but it may be possible to design around the issue >> - have I missed anything? >> >> Supporting URI formats other than SIP (e.g., HTTP) would still need to >> be worked. But that format would be common to all LbyR usages. >> This in no way removes the requirement for a device-to-LIS "LCP". I >> haven't read that into the suggestion at all. >> >> So, I think this idea warrants consideration. >> Barbara >> >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Thursday, February 15, 2007 3:51 PM >> To: Stark, Barbara >> Cc: geopriv@ietf.org; Otmar Lendl >> Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement >> >> >> On Feb 15, 2007, at 12:50 PM, Stark, Barbara wrote: >> >> >> >>> What is difficult, is figuring out a standard format for a URI user >>> part that would allow for all the variations in combinations of IDs >>> that exist, so that a standard format could be defined that would >>> cover all interconnection models. Section 8 of the NENA Location TID >>> (http://www.nena.org/media/files/08-505_20061221.pdf) provides 5 >>> different examples of interconnection models, and the IDs that would >>> need to be used in each of these cases. In this document, scenario 1 >>> uses the IP address, scenario 2 uses NAS-ID and ATM PVC, scenario 3 >>> uses >>> 2 VLAN tags, scenario 4 uses IP address, and scenario 5 uses L2TP >>> tunnel ID (source and destination) and PPPoE session ID. These are >>> just 5 possible examples, and should not be considered exhaustive. >>> Interconnection models are still evolving. >>> >>> >> Well, that's easily solved with a BCP for formulating URIs based on the >> ID. You don't need a new protocol or to conflate the LCP protocol with >> this functionality. >> >> -andy >> >> ***** >> >> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 >> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> >> >> > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 15:44: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 1HRCvD-00083p-JM; Tue, 13 Mar 2007 15:44:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRCvC-00083j-Sa for geopriv@ietf.org; Tue, 13 Mar 2007 15:44:34 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRCvB-0003yV-6E for geopriv@ietf.org; Tue, 13 Mar 2007 15:44:34 -0400 Received: (qmail invoked by alias); 13 Mar 2007 19:44:31 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp042) with SMTP; 13 Mar 2007 20:44:31 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18kBA1OykwklNOhiqcPnO5jCx1RhFowwCCVgHw1LQ P1QpY+70Gy2+9d Message-ID: <45F6FF1E.1040102@gmx.net> Date: Tue, 13 Mar 2007 20:44:30 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Dawson, Martin" Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: geopriv@ietf.org, Barbara.Stark@BellSouth.com, lendl@nic.at, andy@hxr.us X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Martin, I agree that the question of "response time parameter" is orthogonal to the question of LIS-to-LIS and also to the OBO aspect. Ciao Hannes Dawson, Martin wrote: > If we consider that the LIS-LIS scenario is typically an ISP LIS gatewaying the request to the infrastructure operator LIS, then the response time parameter still gets carried across that interface. I think the question of LIS-LIS versus target-LIS versus OBO, versus dereference are all orthogonal to the question of the utility of the response time parameter. > > Cheers, > Martin > > -----Original Message----- > From: jerome.grenier@bell.ca [mailto:jerome.grenier@bell.ca] > Sent: Sunday, 11 March 2007 7:44 AM > To: Hannes.Tschofenig@gmx.net > Cc: geopriv@ietf.org; Barbara.Stark@BellSouth.com; lendl@nic.at; andy@hxr.us > Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement > > Hi Hannes, > > Indeed, the scenario I had in mind did not involve LIS-to-LIS in a DSL environment. It is the mobile access to the Internet scenario (3G cell phones / PDAs, PC cards, etc). The deployment I know involves only one entity as both the Internet Service Provider and the (mobile) Access Service Provider, therefore only one LIS is needed. Of course, the LIS-to-LIS issues would apply to deployments where those two providers would be different organizations (I don't know if such deployments actually exist). > > In this mobile environment, the ability to specify how quickly a response is needed seems useful. Note that this makes more sense from an OBO perspective as well as if the mobile device itself tries to acquire its location just in time for an emergency call, for example. > > J�r�me > > -----Message d'origine----- > De : Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Envoy� : 10 mars 2007 15:00 > � : Grenier, Jerome (6002687) > Cc : Barbara.Stark@BellSouth.com; andy@hxr.us; geopriv@ietf.org; lendl@nic.at > Objet : Re: [Geopriv] Geopriv L7 LCP: New Requirement > > Hi Jerome, > > jerome.grenier@bell.ca wrote: > >> I agree with Barbara and would also add : >> >> - ability to request geo and/or civic location >> >> > > Barbara previously said that geo-location does not make sense in the DSL > environment. > I guess you are pointing to a different environment. The question is > only: Is the LIS-to-LIS communication needed there as well? > > >> The "ability to specify how quickly a response is needed" would also be really helpful to us. >> >> > I don't think that this is useful for this particular application. > > >> Having a BCP (one or more) that recommends a syntax to express various identifier types for common protocols like SIP/PRES and HTTP would be great! >> >> >> > Ciao > Hanes > > >> J�r�me >> >> -----Message d'origine----- >> De : Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] >> Envoy� : 16 f�vrier 2007 10:05 >> � : Andrew Newton >> Cc : geopriv@ietf.org; Otmar Lendl >> Objet : RE: [Geopriv] Geopriv L7 LCP: New Requirement >> >> I hate to break ranks, but if we could get the user part figured out >> (and I do think we would need some standardization, even if it's just a >> BCP), I kind of like this proposed solution. It has a certain simplicity >> to it. >> >> Since we've been pushing for these LISs to support LbyR, anyway, and >> this is really just LbyR, I don't see it as being a different protocol, >> yet again. This is a protocol we'd expect to be supported by a LIS in >> any case. The only change is that the URI may require careful parsing by >> the queried LIS, and the querier LIS needs to support LbyR queries in >> both directions. >> >> When I look at the functions in HELD (and RELO has a subset of these), >> and think through which of those functions would I really need for >> LIS-LIS or OBO, I come up with: >> - ability to request reference -- not needed, since, as pointed out, >> I've already got a perfectly good non-expiring reference; OBO querier or >> LIS doesn't need to ask for references to hand off to others, it should >> create its own references for that, as appropriate [aside: a >> non-expiring reference and a "LCP" are rather equal in the privacy >> debate from the OBO/LIS-LIS perspective.] >> - ability to assert location -- not needed for OBO or LIS-LIS; only an >> end device should be able to do this, if even that is allowed >> - ability to provide rules/profile for privacy -- not needed for OBO or >> LIS-LIS; only the device should be able to do this >> - ability to sign location -- if this is part of PIDF-LO, then this is >> independent of request mechanism >> - ability to request that location be signed -- I think we can assume >> that the location should be signed if it can be signed >> - ability to specify how quickly a response is needed -- this would be >> useful, but it may be possible to design around the issue >> - have I missed anything? >> >> Supporting URI formats other than SIP (e.g., HTTP) would still need to >> be worked. But that format would be common to all LbyR usages. >> This in no way removes the requirement for a device-to-LIS "LCP". I >> haven't read that into the suggestion at all. >> >> So, I think this idea warrants consideration. >> Barbara >> >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Thursday, February 15, 2007 3:51 PM >> To: Stark, Barbara >> Cc: geopriv@ietf.org; Otmar Lendl >> Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement >> >> >> On Feb 15, 2007, at 12:50 PM, Stark, Barbara wrote: >> >> >> >>> What is difficult, is figuring out a standard format for a URI user >>> part that would allow for all the variations in combinations of IDs >>> that exist, so that a standard format could be defined that would >>> cover all interconnection models. Section 8 of the NENA Location TID >>> (http://www.nena.org/media/files/08-505_20061221.pdf) provides 5 >>> different examples of interconnection models, and the IDs that would >>> need to be used in each of these cases. In this document, scenario 1 >>> uses the IP address, scenario 2 uses NAS-ID and ATM PVC, scenario 3 >>> uses >>> 2 VLAN tags, scenario 4 uses IP address, and scenario 5 uses L2TP >>> tunnel ID (source and destination) and PPPoE session ID. These are >>> just 5 possible examples, and should not be considered exhaustive. >>> Interconnection models are still evolving. >>> >>> >> Well, that's easily solved with a BCP for formulating URIs based on the >> ID. You don't need a new protocol or to conflate the LCP protocol with >> this functionality. >> >> -andy >> >> ***** >> >> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 >> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> >> >> > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 15:44: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 1HRCvC-00083U-EN; Tue, 13 Mar 2007 15:44:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRCvA-000814-SH for geopriv@ietf.org; Tue, 13 Mar 2007 15:44:32 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRCv9-0003wU-37 for geopriv@ietf.org; Tue, 13 Mar 2007 15:44:32 -0400 Received: (qmail invoked by alias); 13 Mar 2007 19:44:29 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp019) with SMTP; 13 Mar 2007 20:44:29 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18o8zcVYNMokzmGhCjbbSYC2c8zXu3jnO506dwrua EDx63jMBNaOJ2M Message-ID: <45F6FF19.2010500@gmx.net> Date: Tue, 13 Mar 2007 20:44:25 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Dawson, Martin" Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: geopriv@ietf.org, Barbara.Stark@BellSouth.com, lendl@nic.at, andy@hxr.us X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Martin, I will double-check with some location folks to have more than one opinion. I want to make sure that I also see the "there is a plenty of demand" indication. Ciao Hannes Dawson, Martin wrote: > Using civic for routing may work in the US where the MSAG is part of the legacy infrastructure. In other jurisdictions that I have spoken with, they would hate to have to develop this just for routing calls. As such a nominal geo associated with fixed wireline access points is also a requirement. Hence the need to be able to get both forms if possible. > > There is plenty of demand for a response time parameter and it is in the NENA requirements. It has a very valid application in doing location technology arbitration in wireless location measurement - it is used already in 2G and 3G location determination. There is nothing in IP Location that removes this requirement - your opinion not withstanding being valid as your opinion. > > Cheers, > Martin > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Sunday, 11 March 2007 7:00 AM > To: jerome.grenier@bell.ca > Cc: geopriv@ietf.org; Barbara.Stark@BellSouth.com; lendl@nic.at; andy@hxr.us > Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement > > Hi Jerome, > > jerome.grenier@bell.ca wrote: > >> I agree with Barbara and would also add : >> >> - ability to request geo and/or civic location >> >> > > Barbara previously said that geo-location does not make sense in the DSL > environment. > I guess you are pointing to a different environment. The question is > only: Is the LIS-to-LIS communication needed there as well? > > >> The "ability to specify how quickly a response is needed" would also be really helpful to us. >> >> > I don't think that this is useful for this particular application. > > >> Having a BCP (one or more) that recommends a syntax to express various identifier types for common protocols like SIP/PRES and HTTP would be great! >> >> >> > Ciao > Hanes > > >> J�r�me >> >> -----Message d'origine----- >> De : Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] >> Envoy� : 16 f�vrier 2007 10:05 >> � : Andrew Newton >> Cc : geopriv@ietf.org; Otmar Lendl >> Objet : RE: [Geopriv] Geopriv L7 LCP: New Requirement >> >> I hate to break ranks, but if we could get the user part figured out >> (and I do think we would need some standardization, even if it's just a >> BCP), I kind of like this proposed solution. It has a certain simplicity >> to it. >> >> Since we've been pushing for these LISs to support LbyR, anyway, and >> this is really just LbyR, I don't see it as being a different protocol, >> yet again. This is a protocol we'd expect to be supported by a LIS in >> any case. The only change is that the URI may require careful parsing by >> the queried LIS, and the querier LIS needs to support LbyR queries in >> both directions. >> >> When I look at the functions in HELD (and RELO has a subset of these), >> and think through which of those functions would I really need for >> LIS-LIS or OBO, I come up with: >> - ability to request reference -- not needed, since, as pointed out, >> I've already got a perfectly good non-expiring reference; OBO querier or >> LIS doesn't need to ask for references to hand off to others, it should >> create its own references for that, as appropriate [aside: a >> non-expiring reference and a "LCP" are rather equal in the privacy >> debate from the OBO/LIS-LIS perspective.] >> - ability to assert location -- not needed for OBO or LIS-LIS; only an >> end device should be able to do this, if even that is allowed >> - ability to provide rules/profile for privacy -- not needed for OBO or >> LIS-LIS; only the device should be able to do this >> - ability to sign location -- if this is part of PIDF-LO, then this is >> independent of request mechanism >> - ability to request that location be signed -- I think we can assume >> that the location should be signed if it can be signed >> - ability to specify how quickly a response is needed -- this would be >> useful, but it may be possible to design around the issue >> - have I missed anything? >> >> Supporting URI formats other than SIP (e.g., HTTP) would still need to >> be worked. But that format would be common to all LbyR usages. >> This in no way removes the requirement for a device-to-LIS "LCP". I >> haven't read that into the suggestion at all. >> >> So, I think this idea warrants consideration. >> Barbara >> >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Thursday, February 15, 2007 3:51 PM >> To: Stark, Barbara >> Cc: geopriv@ietf.org; Otmar Lendl >> Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement >> >> >> On Feb 15, 2007, at 12:50 PM, Stark, Barbara wrote: >> >> >> >>> What is difficult, is figuring out a standard format for a URI user >>> part that would allow for all the variations in combinations of IDs >>> that exist, so that a standard format could be defined that would >>> cover all interconnection models. Section 8 of the NENA Location TID >>> (http://www.nena.org/media/files/08-505_20061221.pdf) provides 5 >>> different examples of interconnection models, and the IDs that would >>> need to be used in each of these cases. In this document, scenario 1 >>> uses the IP address, scenario 2 uses NAS-ID and ATM PVC, scenario 3 >>> uses >>> 2 VLAN tags, scenario 4 uses IP address, and scenario 5 uses L2TP >>> tunnel ID (source and destination) and PPPoE session ID. These are >>> just 5 possible examples, and should not be considered exhaustive. >>> Interconnection models are still evolving. >>> >>> >> Well, that's easily solved with a BCP for formulating URIs based on the >> ID. You don't need a new protocol or to conflate the LCP protocol with >> this functionality. >> >> -andy >> >> ***** >> >> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 >> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> >> >> > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 15:44: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 1HRCvD-00083p-JM; Tue, 13 Mar 2007 15:44:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRCvC-00083j-Sa for geopriv@ietf.org; Tue, 13 Mar 2007 15:44:34 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRCvB-0003yV-6E for geopriv@ietf.org; Tue, 13 Mar 2007 15:44:34 -0400 Received: (qmail invoked by alias); 13 Mar 2007 19:44:31 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp042) with SMTP; 13 Mar 2007 20:44:31 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18kBA1OykwklNOhiqcPnO5jCx1RhFowwCCVgHw1LQ P1QpY+70Gy2+9d Message-ID: <45F6FF1E.1040102@gmx.net> Date: Tue, 13 Mar 2007 20:44:30 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Dawson, Martin" Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: geopriv@ietf.org, Barbara.Stark@BellSouth.com, lendl@nic.at, andy@hxr.us X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Martin, I agree that the question of "response time parameter" is orthogonal to the question of LIS-to-LIS and also to the OBO aspect. Ciao Hannes Dawson, Martin wrote: > If we consider that the LIS-LIS scenario is typically an ISP LIS gatewaying the request to the infrastructure operator LIS, then the response time parameter still gets carried across that interface. I think the question of LIS-LIS versus target-LIS versus OBO, versus dereference are all orthogonal to the question of the utility of the response time parameter. > > Cheers, > Martin > > -----Original Message----- > From: jerome.grenier@bell.ca [mailto:jerome.grenier@bell.ca] > Sent: Sunday, 11 March 2007 7:44 AM > To: Hannes.Tschofenig@gmx.net > Cc: geopriv@ietf.org; Barbara.Stark@BellSouth.com; lendl@nic.at; andy@hxr.us > Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement > > Hi Hannes, > > Indeed, the scenario I had in mind did not involve LIS-to-LIS in a DSL environment. It is the mobile access to the Internet scenario (3G cell phones / PDAs, PC cards, etc). The deployment I know involves only one entity as both the Internet Service Provider and the (mobile) Access Service Provider, therefore only one LIS is needed. Of course, the LIS-to-LIS issues would apply to deployments where those two providers would be different organizations (I don't know if such deployments actually exist). > > In this mobile environment, the ability to specify how quickly a response is needed seems useful. Note that this makes more sense from an OBO perspective as well as if the mobile device itself tries to acquire its location just in time for an emergency call, for example. > > J�r�me > > -----Message d'origine----- > De : Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Envoy� : 10 mars 2007 15:00 > � : Grenier, Jerome (6002687) > Cc : Barbara.Stark@BellSouth.com; andy@hxr.us; geopriv@ietf.org; lendl@nic.at > Objet : Re: [Geopriv] Geopriv L7 LCP: New Requirement > > Hi Jerome, > > jerome.grenier@bell.ca wrote: > >> I agree with Barbara and would also add : >> >> - ability to request geo and/or civic location >> >> > > Barbara previously said that geo-location does not make sense in the DSL > environment. > I guess you are pointing to a different environment. The question is > only: Is the LIS-to-LIS communication needed there as well? > > >> The "ability to specify how quickly a response is needed" would also be really helpful to us. >> >> > I don't think that this is useful for this particular application. > > >> Having a BCP (one or more) that recommends a syntax to express various identifier types for common protocols like SIP/PRES and HTTP would be great! >> >> >> > Ciao > Hanes > > >> J�r�me >> >> -----Message d'origine----- >> De : Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] >> Envoy� : 16 f�vrier 2007 10:05 >> � : Andrew Newton >> Cc : geopriv@ietf.org; Otmar Lendl >> Objet : RE: [Geopriv] Geopriv L7 LCP: New Requirement >> >> I hate to break ranks, but if we could get the user part figured out >> (and I do think we would need some standardization, even if it's just a >> BCP), I kind of like this proposed solution. It has a certain simplicity >> to it. >> >> Since we've been pushing for these LISs to support LbyR, anyway, and >> this is really just LbyR, I don't see it as being a different protocol, >> yet again. This is a protocol we'd expect to be supported by a LIS in >> any case. The only change is that the URI may require careful parsing by >> the queried LIS, and the querier LIS needs to support LbyR queries in >> both directions. >> >> When I look at the functions in HELD (and RELO has a subset of these), >> and think through which of those functions would I really need for >> LIS-LIS or OBO, I come up with: >> - ability to request reference -- not needed, since, as pointed out, >> I've already got a perfectly good non-expiring reference; OBO querier or >> LIS doesn't need to ask for references to hand off to others, it should >> create its own references for that, as appropriate [aside: a >> non-expiring reference and a "LCP" are rather equal in the privacy >> debate from the OBO/LIS-LIS perspective.] >> - ability to assert location -- not needed for OBO or LIS-LIS; only an >> end device should be able to do this, if even that is allowed >> - ability to provide rules/profile for privacy -- not needed for OBO or >> LIS-LIS; only the device should be able to do this >> - ability to sign location -- if this is part of PIDF-LO, then this is >> independent of request mechanism >> - ability to request that location be signed -- I think we can assume >> that the location should be signed if it can be signed >> - ability to specify how quickly a response is needed -- this would be >> useful, but it may be possible to design around the issue >> - have I missed anything? >> >> Supporting URI formats other than SIP (e.g., HTTP) would still need to >> be worked. But that format would be common to all LbyR usages. >> This in no way removes the requirement for a device-to-LIS "LCP". I >> haven't read that into the suggestion at all. >> >> So, I think this idea warrants consideration. >> Barbara >> >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Thursday, February 15, 2007 3:51 PM >> To: Stark, Barbara >> Cc: geopriv@ietf.org; Otmar Lendl >> Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement >> >> >> On Feb 15, 2007, at 12:50 PM, Stark, Barbara wrote: >> >> >> >>> What is difficult, is figuring out a standard format for a URI user >>> part that would allow for all the variations in combinations of IDs >>> that exist, so that a standard format could be defined that would >>> cover all interconnection models. Section 8 of the NENA Location TID >>> (http://www.nena.org/media/files/08-505_20061221.pdf) provides 5 >>> different examples of interconnection models, and the IDs that would >>> need to be used in each of these cases. In this document, scenario 1 >>> uses the IP address, scenario 2 uses NAS-ID and ATM PVC, scenario 3 >>> uses >>> 2 VLAN tags, scenario 4 uses IP address, and scenario 5 uses L2TP >>> tunnel ID (source and destination) and PPPoE session ID. These are >>> just 5 possible examples, and should not be considered exhaustive. >>> Interconnection models are still evolving. >>> >>> >> Well, that's easily solved with a BCP for formulating URIs based on the >> ID. You don't need a new protocol or to conflate the LCP protocol with >> this functionality. >> >> -andy >> >> ***** >> >> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 >> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> >> >> > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 15:46: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 1HRCws-0001qO-4V; Tue, 13 Mar 2007 15:46:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRCwr-0001nh-EH for geopriv@ietf.org; Tue, 13 Mar 2007 15:46:17 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRCwp-0004C6-Rs for geopriv@ietf.org; Tue, 13 Mar 2007 15:46:17 -0400 Received: (qmail invoked by alias); 13 Mar 2007 19:46:14 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp031) with SMTP; 13 Mar 2007 20:46:14 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+7tpo6nTm7RniMAMHJsdx/lmEnueMh/7nWB5DBXu zNhzogu326tdVG Message-ID: <45F6FF85.6090109@gmx.net> Date: Tue, 13 Mar 2007 20:46:13 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Winterbottom, James" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: GEOPRIV , "Dawson, Martin" , Marc Linsner Subject: [Geopriv] Strawman Proposal X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi all, since this discussion is ongoing for some time now I would like to better understand the relationship between location signaling and location-by-reference. Let me make another strawman proposal: * We don't do Location Signing at all. * Access networks distribute location information to the end host at a granularity that allows location based routing (unsigned). For most countries this is in fact trivial. * Access networks additionally provide a location-by-reference to the end host (if necessary and if they can do so) This reference is resolved by the PSAP for detailed location information retrieval. The PSAP can therefore also authenticate the LIS and has the information about the access network. As Henning pointed out there is some value in authenticating the emergency caller (directly or indirectly). Why did nobody investigate it since it also allows to get hold of the adversary? It might not look so nice from crypto point of view but it would provide a lot of help. Ciao Hannes PS: I also believe that the PSAP operator would accept calls that don't have any location attached to it. How many calls today have location information available? Do we have some statistics about it? Winterbottom, James wrote: > I have re-read Ted's email now several times, and it seems to > concentrate on being able to detect and potentially thwart denial of > service attacks. While this is one of the potential problem it is not > the only one, and I don't see the kind of thing Ted is talking about as > addressing the same problems that signatures will address. > > Further more I did not seem to me to provide a concrete way of doing > what Ted was suggesting. Precisely how will this be done? Without these > details it seems like smoke and mirrors and may not end up being > possible at all. But I don't discount it as helping. > > I don't see DoS as being the only source of attack, and certainly don't > see signatures as the solution to the DoS problem. I do see signatures > as providing a good way to potentially screen crank-calls and avoiding > unnecessary use of public resources. > > The 4 requirements I am tabling are below. > > 1) The only calls that SHALL be directed to a PSAP are those calls that > have been made by end-devices that are in the PSAP service jurisdiction > at the time a call is made. > > 2) Any location used by routing services or subsequent dispatch services > MUST unequivocally represent the physical position of the end-device at > the time the location is proffered. > > 3) Any request for location made to a LIS MUST result in either an > error, or the current location of the target device being returned. > > 4) The source of the location information MUST be identifiable and is > accountable for the accuracy of the information provided. > > Providing you try to meet these 4 requirements I am happy. Simply saying > they can't be done and so they are not requirements, as has been said in > the past, is not acceptable. > > Cheers > James > > > > > > >> -----Original Message----- >> From: Marc Linsner [mailto:mlinsner@cisco.com] >> Sent: Tuesday, 13 March 2007 2:50 AM >> To: Dawson, Martin >> Cc: 'GEOPRIV' >> Subject: RE: [Geopriv] NENA Requirements >> >> Martin, >> >> >>> I think all of the NENA requirements have been raised and >>> discussed - the latest concept to cause indigestion is >>> location signing. >>> >> You have requirements mixed up with solutions. Signing location >> > objects > >> is >> a solution. I believe Ted nailed the requirement. >> >> -Marc- >> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 16:06: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 1HRDGf-0004hU-Dv; Tue, 13 Mar 2007 16:06:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRDGf-0004hP-2J for geopriv@ietf.org; Tue, 13 Mar 2007 16:06:45 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRDGa-0007t8-Uj for geopriv@ietf.org; Tue, 13 Mar 2007 16:06:45 -0400 Received: from ([139.76.131.91]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.18117648; Tue, 13 Mar 2007 16:06:22 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 13 Mar 2007 16:06:07 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 13 Mar 2007 16:06:06 -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: [Geopriv] NENA Requirements Date: Tue, 13 Mar 2007 16:06:04 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA031B2739@crexc41p> Importance: normal Priority: normal In-Reply-To: <45F6FF15.7050807@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] NENA Requirements Thread-Index: AcdlqE3lQht7PdfvQCyXlQko9KRLdAAAWvPw References: <45F6FF15.7050807@gmx.net> From: "Stark, Barbara" To: "Hannes Tschofenig" , "Dawson, Martin" X-OriginalArrivalTime: 13 Mar 2007 20:06:06.0349 (UTC) FILETIME=[08B8CBD0:01C765AB] X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hannes, I sympathize with your frustration, but I think that part of the requirement sharing problem may lie with IETF processes. I know for a fact that the draft NENA TID was liaised to the DSL Forum in June 2006, and the final version was liaised in December 2006. I know there was discussion around liaising to the IETF, and I'm not knowledgeable enough to comprehend why the NENA liaison didn't make it to the geopriv WG. Clearly, it was NENA's intention to try to share the draft and get comments on it. June 2006 would also have given the LCP task force time to consider those requirements. I don't think there's anything to be done about the past, but for the future, would it be possible to define a liaison process so organizations such as NENA can properly share their drafts with IETF WGs?=20 Barbara=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Tuesday, March 13, 2007 3:44 PM NENA is slower than the IETF. Interesting :-) In that case it could have even been easier to share the requirements a long time ago instead of letting an entire group discuss requirements for a long time. ***** 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. GA624 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 16:51:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRDxx-0000cl-2g; Tue, 13 Mar 2007 16:51:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRDxv-0000cf-SG for geopriv@ietf.org; Tue, 13 Mar 2007 16:51:27 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRDxu-0000uC-FL for geopriv@ietf.org; Tue, 13 Mar 2007 16:51:27 -0400 X-SEF-Processed: 5_0_0_910__2007_03_13_15_57_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); Tue, 13 Mar 2007 15:57:23 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 15:51:25 -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 Date: Tue, 13 Mar 2007 15:51:23 -0500 Message-ID: In-Reply-To: <45F6FF85.6090109@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Strawman Proposal Thread-Index: AcdlqEVSFdZg4j1wTVmfZcy2HAPc9AABnHZQ From: "Winterbottom, James" To: "Hannes Tschofenig" X-OriginalArrivalTime: 13 Mar 2007 20:51:25.0792 (UTC) FILETIME=[5DA2DE00:01C765B1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: GEOPRIV , "Dawson, Martin" , Marc Linsner Subject: [Geopriv] RE: Strawman Proposal X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Hannes,=0D=0A=0D=0A=0D=0A> * We don't do Location Signing at all.=0D=0A>= * Access networks distribute location information to the end host at a=0D=0A= > granularity that allows location based routing (unsigned). For most=0D=0A= > countries this is in fact trivial.=0D=0A=0D=0A=0D=0A[AJW] My discussions = with carriers and infrastructure providers seems to=0D=0Asuggest that obtai= ning location information to provide to end hosts is=0D=0Agoing to be far f= rom trivial. When confronted with this hurdle I am not=0D=0Aso sure that ad= ding signing is that much more work.=0D=0A=0D=0A=0D=0A> * Access networks a= dditionally provide a location-by-reference to the=0D=0A> end host (if nece= ssary and if they can do so)=0D=0A> This reference is resolved by the PSAP = for detailed location=0D=0Ainformation=0D=0A> retrieval. The PSAP can there= fore also authenticate the LIS and has=0D=0Athe=0D=0A> information about th= e access network.=0D=0A=0D=0A[AJW] It is not clear to me how I can use this= approach to provide an=0D=0Aanswering or priority policy for the PSAP. Do = however agree that a=0D=0Are-query mechanism as you suggest is useful where= the PSAP wants=0D=0Aup-to-date or more accurate location information.=0D=0A=0D= =0A>=20=0D=0A> As Henning pointed out there is some value in authenticating= the=0D=0A> emergency caller (directly or indirectly). Why did nobody inves= tigate=0D=0Ait=0D=0A> since it also allows to get hold of the adversary=3F = It might not look=0D=0Aso=0D=0A> nice from crypto point of view but it woul= d provide a lot of help.=0D=0A>=20=0D=0A=0D=0A[AJW] It is not clear to me h= ow authenticating millions of users and=0D=0Atheir multitude of identity me= chanisms is any less daunting than=0D=0Aproviding accreditation to potentia= lly thousands of access network=0D=0Aproviders. But perhaps I am missing th= e point. That said, if you couple=0D=0Athis with signed location then you h= ave the whole gamut. See location=0D=0Adependability draft=0D=0Ahttp://tool= s.ietf.org/html/draft-thomson-geopriv-location-dependability-=0D=0A00=0D=0A= =20=0D=0A>=20=0D=0A> PS: I also believe that the PSAP operator would accept= calls that=0D=0Adon't=0D=0A> have any location attached to it. How many ca= lls today have location=0D=0A> information available=3F Do we have some sta= tistics about it=3F=0D=0A>=20=0D=0A=0D=0A[AJW] All emergency calls in the w= orld have some degree of location=0D=0Aprovided (inferred), though in some = cases this may not be fantastically=0D=0Aaccurate, country level. In the Un= ited States for wireline it is based=0D=0Aon the calling line ID, and eithe= r an ESRD (roughly representing a cell)=0D=0Aor an ESRK (representing a rou= gh calling area) for wireless.=0D=0A=0D=0APerhaps, like some other working = groups we need to make the distinction=0D=0Abetween support and implement. = I am asking that the requirements include=0D=0Asupport for it, I think that= implementation will be something that=0D=0Ajurisdictions have the option t= o do or not.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A> =0D= =0A> Winterbottom, James wrote:=0D=0A> > I have re-read Ted's email now sev= eral times, and it seems to=0D=0A> > concentrate on being able to detect an= d potentially thwart denial of=0D=0A> > service attacks. While this is one = of the potential problem it is=0D=0Anot=0D=0A> > the only one, and I don't = see the kind of thing Ted is talking about=0D=0Aas=0D=0A> > addressing the = same problems that signatures will address.=0D=0A> >=0D=0A> > Further more = I did not seem to me to provide a concrete way of doing=0D=0A> > what Ted w= as suggesting. Precisely how will this be done=3F Without=0D=0Athese=0D=0A= > > details it seems like smoke and mirrors and may not end up being=0D=0A>= > possible at all. But I don't discount it as helping.=0D=0A> >=0D=0A> > I= don't see DoS as being the only source of attack, and certainly=0D=0Adon't=0D= =0A> > see signatures as the solution to the DoS problem. I do see=0D=0Asig= natures=0D=0A> > as providing a good way to potentially screen crank-calls = and=0D=0Aavoiding=0D=0A> > unnecessary use of public resources.=0D=0A> >=0D= =0A> > The 4 requirements I am tabling are below.=0D=0A> >=0D=0A> > 1) The = only calls that SHALL be directed to a PSAP are those calls=0D=0Athat=0D=0A= > > have been made by end-devices that are in the PSAP service=0D=0Ajurisdi= ction=0D=0A> > at the time a call is made.=0D=0A> >=0D=0A> > 2) Any locatio= n used by routing services or subsequent dispatch=0D=0Aservices=0D=0A> > MU= ST unequivocally represent the physical position of the end-device=0D=0Aat=0D= =0A> > the time the location is proffered.=0D=0A> >=0D=0A> > 3) Any request= for location made to a LIS MUST result in either an=0D=0A> > error, or the= current location of the target device being returned.=0D=0A> >=0D=0A> > 4)= The source of the location information MUST be identifiable and=0D=0Ais=0D= =0A> > accountable for the accuracy of the information provided.=0D=0A> >=0D= =0A> > Providing you try to meet these 4 requirements I am happy. Simply=0D= =0Asaying=0D=0A> > they can't be done and so they are not requirements, as = has been=0D=0Asaid in=0D=0A> > the past, is not acceptable.=0D=0A> >=0D=0A>= > Cheers=0D=0A> > James=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A= > >=0D=0A> >> -----Original Message-----=0D=0A> >> From: Marc Linsner [mail= to:mlinsner@cisco.com]=0D=0A> >> Sent: Tuesday, 13 March 2007 2:50 AM=0D=0A= > >> To: Dawson, Martin=0D=0A> >> Cc: 'GEOPRIV'=0D=0A> >> Subject: RE: [Geo= priv] NENA Requirements=0D=0A> >>=0D=0A> >> Martin,=0D=0A> >>=0D=0A> >>=0D=0A= > >>> I think all of the NENA requirements have been raised and=0D=0A> >>> = discussed - the latest concept to cause indigestion is=0D=0A> >>> location = signing.=0D=0A> >>>=0D=0A> >> You have requirements mixed up with solutions= =2E Signing location=0D=0A> >>=0D=0A> > objects=0D=0A> >=0D=0A> >> is=0D=0A= > >> a solution. I believe Ted nailed the requirement.=0D=0A> >>=0D=0A> >>= -Marc-=0D=0A> >>=0D=0A> >>=0D=0A> >>=0D=0A> >> ___________________________= ____________________=0D=0A> >> Geopriv mailing list=0D=0A> >> Geopriv@ietf.= org=0D=0A> >> https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A> >>=0D=0A= > >=0D=0A> >=0D=0A---------------------------------------------------------= ---------------=0D=0A> ------------------------=0D=0A> > This message is fo= r the designated recipient only and may=0D=0A> > contain privileged, propri= etary, or otherwise private information.=0D=0A> > If you have received it i= n 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> > [mf2]=0D=0A> >=0D=0A> >=0D=0A> > ___= ____________________________________________=0D=0A> > Geopriv mailing list=0D= =0A> > Geopriv@ietf.org=0D=0A> > https://www1.ietf.org/mailman/listinfo/geo= priv=0D=0A> >=0D=0A>=20=0D=0A=0D=0A----------------------------------------= --------------------------------------------------------=0D=0AThis message = is for the designated recipient only and may=0D=0Acontain privileged, propr= ietary, or otherwise private information. =20=0D=0AIf you have received it = in error, please notify the sender=0D=0Aimmediately and delete the original= =2E Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A----------= ---------------------------------------------------------------------------= -----------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 16:51:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRDyI-0000hI-Dp; Tue, 13 Mar 2007 16:51:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRDyG-0000h7-NR for geopriv@ietf.org; Tue, 13 Mar 2007 16:51:48 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRDyF-0000wy-EN for geopriv@ietf.org; Tue, 13 Mar 2007 16:51:48 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2DKpbcU004453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 Mar 2007 16:51:38 -0400 (EDT) In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA031B2739@crexc41p> References: <45F6FF15.7050807@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA031B2739@crexc41p> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <015FCD41-D0AE-4955-AA32-B64534358516@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] NENA Requirements Date: Tue, 13 Mar 2007 16:52:19 -0400 To: "Stark, Barbara" 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: GEOPRIV , "Dawson, Martin" X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Why couldn't the NENA chair simply send an email with a publicly accessible URL to the GEOPRIV or ECRIT working groups? I don't think we need a full-time standardization diplomatic corps. On Mar 13, 2007, at 4:06 PM, Stark, Barbara wrote: > Hannes, > I sympathize with your frustration, but I think that part of the > requirement sharing problem may lie with IETF processes. I know for a > fact that the draft NENA TID was liaised to the DSL Forum in June > 2006, > and the final version was liaised in December 2006. I know there was > discussion around liaising to the IETF, and I'm not knowledgeable > enough > to comprehend why the NENA liaison didn't make it to the geopriv WG. > Clearly, it was NENA's intention to try to share the draft and get > comments on it. June 2006 would also have given the LCP task force > time > to consider those requirements. > > I don't think there's anything to be done about the past, but for the > future, would it be possible to define a liaison process so > organizations such as NENA can properly share their drafts with IETF > WGs? > Barbara _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 16:56:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRE2r-0002JF-5P; Tue, 13 Mar 2007 16:56:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRE2q-0002J0-1t for geopriv@ietf.org; Tue, 13 Mar 2007 16:56:32 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRE2o-00025R-R0 for geopriv@ietf.org; Tue, 13 Mar 2007 16:56:32 -0400 X-SEF-Processed: 5_0_0_910__2007_03_13_16_02_27 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); Tue, 13 Mar 2007 16:02:27 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 15:56:29 -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: [Geopriv] Brian Rosen on location signing Date: Tue, 13 Mar 2007 15:56:26 -0500 Message-ID: In-Reply-To: <6BCD7DED-475B-467E-8CAA-95ABD68F3997@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Brian Rosen on location signing Thread-Index: Acdlh6YmaIIPeygdRh60r4+/ZUEvWgAKgnxg From: "Winterbottom, James" To: "Andrew Newton" , "Dawson, Martin" X-OriginalArrivalTime: 13 Mar 2007 20:56:29.0268 (UTC) FILETIME=[1285A140:01C765B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org =0D=0A>=20=0D=0A> Well, there could be a new DHCP option for requesting the= signature.=0D=0A> This signature could then be put in an element in PIDF-L= O such as=0D=0A> ........ If an L7 = protocol=0D=0A> populates that element, it would mean it went through the s= ame=0D=0A> process for canonicalizing and signing the data.=0D=0A>=20=0D=0A=0D= =0AI think that there are a few details that would need to be worked out=0D= =0Ahere.=0D=0AFor example, if I request both geodetic and civic information= , what is=0D=0Athe signature applied to=3F Do I need two signature options = one for each=3F=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A------------------------------= ------------------------------------------------------------------=0D=0AThi= s message is for the designated recipient only and may=0D=0Acontain privile= ged, proprietary, or otherwise private information. =20=0D=0AIf you have re= ceived it in error, please notify the sender=0D=0Aimmediately and delete th= e original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A--= ---------------------------------------------------------------------------= -------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 16:58:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRE4k-0002fk-Fb; Tue, 13 Mar 2007 16:58:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRE4j-0002fb-Gt for geopriv@ietf.org; Tue, 13 Mar 2007 16:58:29 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRE4i-0002SY-6v for geopriv@ietf.org; Tue, 13 Mar 2007 16:58:29 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Mar 2007 16:58:28 -0400 X-IronPort-AV: i="4.14,280,1170651600"; d="scan'208"; a="54687102:sNHT52197810" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2DKwRdg008438; Tue, 13 Mar 2007 16:58:27 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2DKwRZX005936; Tue, 13 Mar 2007 20:58:28 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 16:58:15 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 16:58:15 -0400 From: "Marc Linsner" To: "'Stark, Barbara'" Subject: RE: [Geopriv] NENA Requirements Date: Tue, 13 Mar 2007 16:58:13 -0400 Message-ID: <004401c765b2$51bb4540$230d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdlqE3lQht7PdfvQCyXlQko9KRLdAAAWvPwAAHNW/A= In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA031B2739@crexc41p> X-OriginalArrivalTime: 13 Mar 2007 20:58:15.0510 (UTC) FILETIME=[51D8DF60:01C765B2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2884; t=1173819508; x=1174683508; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20NENA=20Requirements |Sender:=20 |To:=20=22'Stark,=20Barbara'=22=20; bh=30X1K6IggoNPo5zWpjZsHS1tCBAnDi+ud9iau/P5oOs=; b=EnK+FKEP2bu4gZPnn76ZD1Ex7dkDeP4JqYXJWXBPacbf9JNAxWbT4CgRiDyL1VR7US/MIK1z osQCHIhPbr2fEvXPf8uV6QQjDz+Vxrys64GyhjF6tewl5NuzcjBW6INY; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Barbara, Yes, the IETF liaison process is frustrating. But I attribute this partly to my own laziness/lack of desire to learn it. I did attempt to track the NENA document, at your earlier suggestion/request, starting at the NENA end since that seemed less intimidating than the IETF end. Unfortunately, I got a resounding 'no response' on my query on the NENA end which drove me to drop it as I see the IETF end as the bigger of the two dragons. I didn't get results from the little dragon, chances are the bigger one will be even less helpful. In defense of the IETF, NENA certainly knows how to submit/track a draft, which is the proven mechanism in the case of LoST and the NENA LTD wg. -Marc- > -----Original Message----- > From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > Sent: Tuesday, March 13, 2007 4:06 PM > To: Hannes Tschofenig; Dawson, Martin > Cc: GEOPRIV > Subject: RE: [Geopriv] NENA Requirements > > Hannes, > I sympathize with your frustration, but I think that part of > the requirement sharing problem may lie with IETF processes. > I know for a fact that the draft NENA TID was liaised to the > DSL Forum in June 2006, and the final version was liaised in > December 2006. I know there was discussion around liaising to > the IETF, and I'm not knowledgeable enough to comprehend why > the NENA liaison didn't make it to the geopriv WG. > Clearly, it was NENA's intention to try to share the draft > and get comments on it. June 2006 would also have given the > LCP task force time to consider those requirements. > > I don't think there's anything to be done about the past, but > for the future, would it be possible to define a liaison > process so organizations such as NENA can properly share > their drafts with IETF WGs? > Barbara > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, March 13, 2007 3:44 PM > > NENA is slower than the IETF. Interesting :-) In that case it > could have even been easier to share the requirements a long > time ago instead of letting an entire group discuss > requirements for a long time. > > > ***** > > 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. GA624 > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 17:16: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 1HREMP-0001dC-0g; Tue, 13 Mar 2007 17:16:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HREMN-0001d3-Tp for geopriv@ietf.org; Tue, 13 Mar 2007 17:16:43 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HREMM-0005dW-Js for geopriv@ietf.org; Tue, 13 Mar 2007 17:16:43 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2DLGZwU012281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 Mar 2007 17:16:36 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <03B0FD26-7F5F-4DDB-A177-E58930DFF0B0@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] RE: Strawman Proposal Date: Tue, 13 Mar 2007 17:17:18 -0400 To: "Winterbottom, James" 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: a2c12dacc0736f14d6b540e805505a86 Cc: GEOPRIV , "Dawson, Martin" , Marc Linsner X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org On Mar 13, 2007, at 4:51 PM, Winterbottom, James wrote: > Hi Hannes, > > >> * We don't do Location Signing at all. >> * Access networks distribute location information to the end host >> at a >> granularity that allows location based routing (unsigned). For most >> countries this is in fact trivial. > > > [AJW] My discussions with carriers and infrastructure providers > seems to > suggest that obtaining location information to provide to end hosts is > going to be far from trivial. When confronted with this hurdle I am > not > so sure that adding signing is that much more work. I agree with Hannes that location granularity matters. Having a single LO for the whole DSLAM (or DHCP server) that says "XYZ County" is a whole lot easier than tracking the wiring panel changes as lines get moved. Signing is not the big deal - getting valid CA-certified signatures is. We all know how many web servers have bogus, expired or self- signed certificates, and not just Joe's Barber Shop and Delicatessen. Take a large campus with thousands of offices. Unless you have a fairly elaborate delegation mechanism, somebody externally will have to sign for each and every room. This means that the organization has to operate a CA that is trusted by the proposed VESA entity, for example. We can't even get delegation to work within Internet2 and Columbia. > > [AJW] It is not clear to me how authenticating millions of users and > their multitude of identity mechanisms is any less daunting than > We have such a mechanism, e.g., within IMS, namely P-Asserted-ID, which is very widely deployed, from what I can tell. Or the SIP identity mechanism, although that seems to just start getting traction. The PSAP wouldn't care whether and how the VSP verified the customer identity; it just gets a single client cert from the VSP in a TLS connection. You probably missed the discussion on this years ago, but your concern and the perceived difficulties of a global PKI motivated the current mechanism, as it only requires what customers must have already, namely a shared secret with their VSP, and web-style cross- provider trust with a single cert for each provider. > providing accreditation to potentially thousands of access network > providers. But perhaps I am missing the point. That said, if you > couple > this with signed location then you have the whole gamut. See location > dependability draft > http://tools.ietf.org/html/draft-thomson-geopriv-location- > dependability- > 00 > >> >> PS: I also believe that the PSAP operator would accept calls that > don't >> have any location attached to it. How many calls today have location >> information available? Do we have some statistics about it? >> > > [AJW] All emergency calls in the world have some degree of location > provided (inferred), though in some cases this may not be > fantastically > accurate, country level. In the United States for wireline it is based > on the calling line ID, and either an ESRD (roughly representing a > cell) > or an ESRK (representing a rough calling area) for wireless. > > Perhaps, like some other working groups we need to make the > distinction > between support and implement. I am asking that the requirements > include > support for it, I think that implementation will be something that > jurisdictions have the option to do or not. This doesn't quite work, given that phones need to work universally. I don't want to buy a phone in Prague, say, that suddenly can't make an emergency call in New York city. Henning _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 17:22: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 1HRERm-00040S-Pz; Tue, 13 Mar 2007 17:22:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRERl-000409-8j for geopriv@ietf.org; Tue, 13 Mar 2007 17:22:17 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRERi-0007Dp-5q for geopriv@ietf.org; Tue, 13 Mar 2007 17:22:17 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 13 Mar 2007 14:22:13 -0700 X-IronPort-AV: i="4.14,280,1170662400"; d="scan'208"; a="121041730:sNHT52637913" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2DLMDnF023892; Tue, 13 Mar 2007 14:22:13 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2DLM6eH000853; Tue, 13 Mar 2007 21:22:13 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 14:21:53 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.152.157]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 14:21:52 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 Mar 2007 16:21:51 -0500 To: Hannes Tschofenig From: "James M. Polk" Subject: Re: [Geopriv] Strawman Proposal In-Reply-To: <45F6FF85.6090109@gmx.net> References: <45F6FF85.6090109@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 13 Mar 2007 21:21:52.0852 (UTC) FILETIME=[9EA61940:01C765B5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5749; t=1173820933; x=1174684933; 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=20[Geopriv]=20Strawman=20Proposal |Sender:=20; bh=K9nWe+wIx0osaGBphhju+QHeoDFd4UVyd7XqqbWIS6w=; b=b7q7xy26gK7fdxqmDV1VxWTkvY8DPxHwa8o7DUfalfNyyFfY8199kztOZPozWNC7QSe/sQDQ 9YX670zZtPiAFcoVPQWXvYzERNtgcaCOKjC3tU2x7O6fTUkl/iUMZME6VbMEGLHG/4kuTdZYu3 LppZhoASi4pSGsJwG4SvGCJA8=; 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: 87a3f533bb300b99e2a18357f3c1563d Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org It's hard for me to believe we can MUST strength any signing - because of the difference in being idealistic and pragmatic about service delivery. While reviewing the migratory nature of change from the existing systems to an IP based on. There are a lot of IP devices out there right now that can make IP calls to a PSAP, if that PSAP were IP enabled. MUSTing their upgrade in SW is gonna be a hard sell to some/most (everyone?). So do we want to be relevant or not implemented because we set our own bar too high? I don't think any of us want bad guys to clog up the systems, yet we need to support unregistered emergency callers. Presumably some (all?) of the unregistered emergency caller attempts wouldn't pass any authentication challenge. So what happens then, the unregistered caller gets denied when calling a PSAP? This is close to us making a legal decision (i.e. defining how jurisdictions interpret wrt whether or not to allow certain calls). That's out of scope from my pov. At 02:46 PM 3/13/2007, Hannes Tschofenig wrote: >Hi all, > >since this discussion is ongoing for some time now I would like to >better understand the relationship between location signaling and >location-by-reference. >Let me make another strawman proposal: > >* We don't do Location Signing at all. >* Access networks distribute location information to the end host at >a granularity that allows location based routing (unsigned). For >most countries this is in fact trivial. >* Access networks additionally provide a location-by-reference to >the end host (if necessary and if they can do so) >This reference is resolved by the PSAP for detailed location >information retrieval. The PSAP can therefore also authenticate the >LIS and has the information about the access network. > >As Henning pointed out there is some value in authenticating the >emergency caller (directly or indirectly). Why did nobody >investigate it since it also allows to get hold of the adversary? It >might not look so nice from crypto point of view but it would >provide a lot of help. > > >Ciao >Hannes > >PS: I also believe that the PSAP operator would accept calls that >don't have any location attached to it. How many calls today have >location information available? Do we have some statistics about it? > > >Winterbottom, James wrote: >>I have re-read Ted's email now several times, and it seems to >>concentrate on being able to detect and potentially thwart denial of >>service attacks. While this is one of the potential problem it is not >>the only one, and I don't see the kind of thing Ted is talking about as >>addressing the same problems that signatures will address. >> >>Further more I did not seem to me to provide a concrete way of doing >>what Ted was suggesting. Precisely how will this be done? Without these >>details it seems like smoke and mirrors and may not end up being >>possible at all. But I don't discount it as helping. >> >>I don't see DoS as being the only source of attack, and certainly don't >>see signatures as the solution to the DoS problem. I do see signatures >>as providing a good way to potentially screen crank-calls and avoiding >>unnecessary use of public resources. >>The 4 requirements I am tabling are below. >>1) The only calls that SHALL be directed to a PSAP are those calls that >>have been made by end-devices that are in the PSAP service jurisdiction >>at the time a call is made. >>2) Any location used by routing services or subsequent dispatch services >>MUST unequivocally represent the physical position of the end-device at >>the time the location is proffered. >> >>3) Any request for location made to a LIS MUST result in either an >>error, or the current location of the target device being returned. >> >>4) The source of the location information MUST be identifiable and is >>accountable for the accuracy of the information provided. >> >>Providing you try to meet these 4 requirements I am happy. Simply saying >>they can't be done and so they are not requirements, as has been said in >>the past, is not acceptable. >> >>Cheers >>James >> >> >> >> >> >> >>>-----Original Message----- >>>From: Marc Linsner [mailto:mlinsner@cisco.com] >>>Sent: Tuesday, 13 March 2007 2:50 AM >>>To: Dawson, Martin >>>Cc: 'GEOPRIV' >>>Subject: RE: [Geopriv] NENA Requirements >>> >>>Martin, >>> >>> >>>>I think all of the NENA requirements have been raised and >>>>discussed - the latest concept to cause indigestion is >>>>location signing. >>>> >>>You have requirements mixed up with solutions. Signing location >>> >>objects >> >>>is >>>a solution. I believe Ted nailed the requirement. >>> >>>-Marc- >>> >>> >>> >>>_______________________________________________ >>>Geopriv mailing list >>>Geopriv@ietf.org >>>https://www1.ietf.org/mailman/listinfo/geopriv >>> >> >>------------------------------------------------------------------------------------------------ >>This message is for the designated recipient only and may >>contain privileged, proprietary, or otherwise private information. >>If you have received it in error, please notify the sender >>immediately and delete the original. Any unauthorized use of >>this email is prohibited. >>------------------------------------------------------------------------------------------------ >>[mf2] >> >> >>_______________________________________________ >>Geopriv mailing list >>Geopriv@ietf.org >>https://www1.ietf.org/mailman/listinfo/geopriv >> > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 17:25: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 1HREUo-0004mm-2G; Tue, 13 Mar 2007 17:25:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HREUl-0004mb-Vm for geopriv@ietf.org; Tue, 13 Mar 2007 17:25:23 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HREUk-0007Zw-LI for geopriv@ietf.org; Tue, 13 Mar 2007 17:25:23 -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 1HREUh-0006nI-60; Tue, 13 Mar 2007 17:25:20 -0400 Message-ID: <45F716BE.6080407@bbn.com> Date: Tue, 13 Mar 2007 17:25:18 -0400 From: Richard Barnes User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Geopriv] RE: Strawman Proposal References: <03B0FD26-7F5F-4DDB-A177-E58930DFF0B0@cs.columbia.edu> In-Reply-To: <03B0FD26-7F5F-4DDB-A177-E58930DFF0B0@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: d8ae4fd88fcaf47c1a71c804d04f413d Cc: GEOPRIV , "Dawson, Martin" , Marc Linsner X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org > Take a large campus with thousands of offices. Unless you have a fairly > elaborate delegation mechanism, somebody externally will have to sign > for each and every room. This means that the organization has to operate > a CA that is trusted by the proposed VESA entity, for example. We can't > even get delegation to work within Internet2 and Columbia. Location granularity and certification granularity are two orthogonal issues. If there's one server that knows the geography of the whole Columbia campus, then there's only one certificate to manage. If you have one per building, then you have might a few more, or you might have each server reach back to a central signing server for a signature. --RB > > > > >> >> [AJW] It is not clear to me how authenticating millions of users and >> their multitude of identity mechanisms is any less daunting than >> > > We have such a mechanism, e.g., within IMS, namely P-Asserted-ID, which > is very widely deployed, from what I can tell. Or the SIP identity > mechanism, although that seems to just start getting traction. The PSAP > wouldn't care whether and how the VSP verified the customer identity; it > just gets a single client cert from the VSP in a TLS connection. > > You probably missed the discussion on this years ago, but your concern > and the perceived difficulties of a global PKI motivated the current > mechanism, as it only requires what customers must have already, namely > a shared secret with their VSP, and web-style cross-provider trust with > a single cert for each provider. > > >> providing accreditation to potentially thousands of access network >> providers. But perhaps I am missing the point. That said, if you couple >> this with signed location then you have the whole gamut. See location >> dependability draft >> http://tools.ietf.org/html/draft-thomson-geopriv-location-dependability- >> 00 >> >>> >>> PS: I also believe that the PSAP operator would accept calls that >> don't >>> have any location attached to it. How many calls today have location >>> information available? Do we have some statistics about it? >>> >> >> [AJW] All emergency calls in the world have some degree of location >> provided (inferred), though in some cases this may not be fantastically >> accurate, country level. In the United States for wireline it is based >> on the calling line ID, and either an ESRD (roughly representing a cell) >> or an ESRK (representing a rough calling area) for wireless. >> >> Perhaps, like some other working groups we need to make the distinction >> between support and implement. I am asking that the requirements include >> support for it, I think that implementation will be something that >> jurisdictions have the option to do or not. > > This doesn't quite work, given that phones need to work universally. I > don't want to buy a phone in Prague, say, that suddenly can't make an > emergency call in New York city. > > Henning > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 17:40: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 1HREjO-0003IS-8Y; Tue, 13 Mar 2007 17:40:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HREjN-0003IA-At for geopriv@ietf.org; Tue, 13 Mar 2007 17:40:29 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HREjL-0002t1-KE for geopriv@ietf.org; Tue, 13 Mar 2007 17:40:29 -0400 Received: (qmail invoked by alias); 13 Mar 2007 21:40:25 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp047) with SMTP; 13 Mar 2007 22:40:25 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+s3+AafFms64pnsk4IP5E1RMpYdTt0FnHGhaWaMj PV7zP+Bm2XByvx Message-ID: <45F71A47.7030604@gmx.net> Date: Tue, 13 Mar 2007 22:40:23 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Winterbottom, James" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: GEOPRIV , "Dawson, Martin" , Marc Linsner Subject: [Geopriv] Re: Strawman Proposal X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi James, Winterbottom, James wrote: > Hi Hannes, > > > >> * We don't do Location Signing at all. >> * Access networks distribute location information to the end host at a >> granularity that allows location based routing (unsigned). For most >> countries this is in fact trivial. >> > > > [AJW] My discussions with carriers and infrastructure providers seems to > suggest that obtaining location information to provide to end hosts is > going to be far from trivial. When confronted with this hurdle I am not > so sure that adding signing is that much more work. > > If operators don't want to make location information available to the end host then location signing is not helpful for them either. I also know that the same operators want to stick with the IMS approach where they neither need the LCP nor the location signing approach. > >> * Access networks additionally provide a location-by-reference to the >> end host (if necessary and if they can do so) >> This reference is resolved by the PSAP for detailed location >> > information > >> retrieval. The PSAP can therefore also authenticate the LIS and has >> > the > >> information about the access network. >> > > [AJW] It is not clear to me how I can use this approach to provide an > answering or priority policy for the PSAP. I don't know what the last part of the sentence means. > Do however agree that a > re-query mechanism as you suggest is useful where the PSAP wants > up-to-date or more accurate location information. > What is the re-query in this context? The PSAP fetches the location for the first time (given that only coarse grained location information is available for routing). Nothing else is needed. That's already far more than they have today. ; > >> As Henning pointed out there is some value in authenticating the >> emergency caller (directly or indirectly). Why did nobody investigate >> > it > >> since it also allows to get hold of the adversary? It might not look >> > so > >> nice from crypto point of view but it would provide a lot of help. >> >> > > [AJW] It is not clear to me how authenticating millions of users and > their multitude of identity mechanisms is any less daunting than > providing accreditation to potentially thousands of access network > providers. But perhaps I am missing the point. That said, if you couple > this with signed location then you have the whole gamut. See location > dependability draft > http://tools.ietf.org/html/draft-thomson-geopriv-location-dependability- > 00 > I agree it is useful to provided authenticated emergency calls in all cases. Mechanisms like P-Asserted-ID or SIP Identity will be useful in many other cases, not just for emergency service calls. Being able to trace a caller back to its real identity is really, really helpful. Location signing cannot provide you with this functionality. > > >> PS: I also believe that the PSAP operator would accept calls that >> > don't > >> have any location attached to it. How many calls today have location >> information available? Do we have some statistics about it? >> >> > > [AJW] All emergency calls in the world have some degree of location > provided (inferred), though in some cases this may not be fantastically > accurate, country level. I don't think that this is true. I have heard from cases where the location information is only retrieved when absolutely needed. > In the United States for wireline it is based > on the calling line ID, and either an ESRD (roughly representing a cell) > or an ESRK (representing a rough calling area) for wireless. > > Perhaps, like some other working groups we need to make the distinction > between support and implement. I am asking that the requirements include > support for it, I think that implementation will be something that > jurisdictions have the option to do or not. > Ciao Hannes > Cheers > James > > > > > >> Winterbottom, James wrote: >> >>> I have re-read Ted's email now several times, and it seems to >>> concentrate on being able to detect and potentially thwart denial of >>> service attacks. While this is one of the potential problem it is >>> > not > >>> the only one, and I don't see the kind of thing Ted is talking about >>> > as > >>> addressing the same problems that signatures will address. >>> >>> Further more I did not seem to me to provide a concrete way of doing >>> what Ted was suggesting. Precisely how will this be done? Without >>> > these > >>> details it seems like smoke and mirrors and may not end up being >>> possible at all. But I don't discount it as helping. >>> >>> I don't see DoS as being the only source of attack, and certainly >>> > don't > >>> see signatures as the solution to the DoS problem. I do see >>> > signatures > >>> as providing a good way to potentially screen crank-calls and >>> > avoiding > >>> unnecessary use of public resources. >>> >>> The 4 requirements I am tabling are below. >>> >>> 1) The only calls that SHALL be directed to a PSAP are those calls >>> > that > >>> have been made by end-devices that are in the PSAP service >>> > jurisdiction > >>> at the time a call is made. >>> >>> 2) Any location used by routing services or subsequent dispatch >>> > services > >>> MUST unequivocally represent the physical position of the end-device >>> > at > >>> the time the location is proffered. >>> >>> 3) Any request for location made to a LIS MUST result in either an >>> error, or the current location of the target device being returned. >>> >>> 4) The source of the location information MUST be identifiable and >>> > is > >>> accountable for the accuracy of the information provided. >>> >>> Providing you try to meet these 4 requirements I am happy. Simply >>> > saying > >>> they can't be done and so they are not requirements, as has been >>> > said in > >>> the past, is not acceptable. >>> >>> Cheers >>> James >>> >>> >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Marc Linsner [mailto:mlinsner@cisco.com] >>>> Sent: Tuesday, 13 March 2007 2:50 AM >>>> To: Dawson, Martin >>>> Cc: 'GEOPRIV' >>>> Subject: RE: [Geopriv] NENA Requirements >>>> >>>> Martin, >>>> >>>> >>>> >>>>> I think all of the NENA requirements have been raised and >>>>> discussed - the latest concept to cause indigestion is >>>>> location signing. >>>>> >>>>> >>>> You have requirements mixed up with solutions. Signing location >>>> >>>> >>> objects >>> >>> >>>> is >>>> a solution. I believe Ted nailed the requirement. >>>> >>>> -Marc- >>>> >>>> >>>> >>>> _______________________________________________ >>>> Geopriv mailing list >>>> Geopriv@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/geopriv >>>> >>>> >>> > ------------------------------------------------------------------------ > >> ------------------------ >> >>> This message is for the designated recipient only and may >>> contain privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender >>> immediately and delete the original. Any unauthorized use of >>> this email is prohibited. >>> >>> > ------------------------------------------------------------------------ > >> ------------------------ >> >>> [mf2] >>> >>> >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www1.ietf.org/mailman/listinfo/geopriv >>> >>> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 17:43:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HREly-00059Z-Ll; Tue, 13 Mar 2007 17:43:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRElw-0004ti-Vw for geopriv@ietf.org; Tue, 13 Mar 2007 17:43:09 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRElv-0003gK-Jm for geopriv@ietf.org; Tue, 13 Mar 2007 17:43:08 -0400 Received: (qmail invoked by alias); 13 Mar 2007 21:43:06 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp028) with SMTP; 13 Mar 2007 22:43:06 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/A6lF2UQfAuvzdweSxBdzNBkCbdGaDpJwdpyGw4Q YiwZ6yWaTaPAqn Message-ID: <45F71AE8.2040104@gmx.net> Date: Tue, 13 Mar 2007 22:43:04 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Geopriv] NENA Requirements References: <45F6FF15.7050807@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA031B2739@crexc41p> <015FCD41-D0AE-4955-AA32-B64534358516@cs.columbia.edu> In-Reply-To: <015FCD41-D0AE-4955-AA32-B64534358516@cs.columbia.edu> 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: 8abaac9e10c826e8252866cbe6766464 Cc: GEOPRIV , "Dawson, Martin" , "Stark, Barbara" X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I cannot agree more. We don't need complicated liaison processes if a number of people participate in both groups and are familiar with the work. Unless the requirements were extremely confidential it would have trivial to share them with GEOPRIV. Ciao Hannes Henning Schulzrinne wrote: > Why couldn't the NENA chair simply send an email with a publicly > accessible URL to the GEOPRIV or ECRIT working groups? I don't think > we need a full-time standardization diplomatic corps. > > On Mar 13, 2007, at 4:06 PM, Stark, Barbara wrote: > >> Hannes, >> I sympathize with your frustration, but I think that part of the >> requirement sharing problem may lie with IETF processes. I know for a >> fact that the draft NENA TID was liaised to the DSL Forum in June 2006, >> and the final version was liaised in December 2006. I know there was >> discussion around liaising to the IETF, and I'm not knowledgeable enough >> to comprehend why the NENA liaison didn't make it to the geopriv WG. >> Clearly, it was NENA's intention to try to share the draft and get >> comments on it. June 2006 would also have given the LCP task force time >> to consider those requirements. >> >> I don't think there's anything to be done about the past, but for the >> future, would it be possible to define a liaison process so >> organizations such as NENA can properly share their drafts with IETF >> WGs? >> Barbara _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 17:54:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HREwK-0007yj-FC; Tue, 13 Mar 2007 17:53:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HREwJ-0007ye-E3 for geopriv@ietf.org; Tue, 13 Mar 2007 17:53:51 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HREwH-0005dk-Sn for geopriv@ietf.org; Tue, 13 Mar 2007 17:53:51 -0400 Received: (qmail invoked by alias); 13 Mar 2007 21:53:48 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp044) with SMTP; 13 Mar 2007 22:53:48 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18TCmErO0UT9j/iZ/WGKa6ztWCEYOR1maUV1gkdmA 1DrZmvZJpzCw/1 Message-ID: <45F71D66.3030406@gmx.net> Date: Tue, 13 Mar 2007 22:53:42 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Richard Barnes Subject: Re: [Geopriv] RE: Strawman Proposal References: <03B0FD26-7F5F-4DDB-A177-E58930DFF0B0@cs.columbia.edu> <45F716BE.6080407@bbn.com> In-Reply-To: <45F716BE.6080407@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: 37af5f8fbf6f013c5b771388e24b09e7 Cc: GEOPRIV , "Dawson, Martin" , Marc Linsner , Henning Schulzrinne X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org We mentioned the idea of putting two PIDF-LOs into a SIP signaling message, namely one for routing and another one for consumption at the PSAP. The one for routing does not need to provide a perfect precision, as we know. For some countries it would be sufficient to use state granularity to hit the correct PSAP. I am also addressing those people who argue that "Operators will never provide location information to the end host because they want to make money with location-based applications. Hence, they can only use location-by-reference". I don't want to create relationships between every VoIP provider and every access network provider in the world because I believe that this will do a lot of harm to the Internet. I am OK with a relationship between access network provider and PSAPs even though I see a lot of problems there as well. If we have to use a location-by-reference mechanism for these operators then we don't need location signing. I doubt that signed location information can be demanded for all emergency service calls since we will even see calls with absolutely no location information at all. Furthermore, we would have to tell the IEEE to go home since none of their solution does any sort of signing. Ciao Hannes Richard Barnes wrote: >> Take a large campus with thousands of offices. Unless you have a >> fairly elaborate delegation mechanism, somebody externally will have >> to sign for each and every room. This means that the organization has >> to operate a CA that is trusted by the proposed VESA entity, for >> example. We can't even get delegation to work within Internet2 and >> Columbia. > > Location granularity and certification granularity are two orthogonal > issues. If there's one server that knows the geography of the whole > Columbia campus, then there's only one certificate to manage. If you > have one per building, then you have might a few more, or you might > have each server reach back to a central signing server for a signature. > > --RB > >> >> >> >> >>> >>> [AJW] It is not clear to me how authenticating millions of users and >>> their multitude of identity mechanisms is any less daunting than >>> >> >> We have such a mechanism, e.g., within IMS, namely P-Asserted-ID, >> which is very widely deployed, from what I can tell. Or the SIP >> identity mechanism, although that seems to just start getting >> traction. The PSAP wouldn't care whether and how the VSP verified the >> customer identity; it just gets a single client cert from the VSP in >> a TLS connection. >> >> You probably missed the discussion on this years ago, but your >> concern and the perceived difficulties of a global PKI motivated the >> current mechanism, as it only requires what customers must have >> already, namely a shared secret with their VSP, and web-style >> cross-provider trust with a single cert for each provider. >> >> >>> providing accreditation to potentially thousands of access network >>> providers. But perhaps I am missing the point. That said, if you couple >>> this with signed location then you have the whole gamut. See location >>> dependability draft >>> http://tools.ietf.org/html/draft-thomson-geopriv-location-dependability- >>> >>> 00 >>> >>>> >>>> PS: I also believe that the PSAP operator would accept calls that >>> don't >>>> have any location attached to it. How many calls today have location >>>> information available? Do we have some statistics about it? >>>> >>> >>> [AJW] All emergency calls in the world have some degree of location >>> provided (inferred), though in some cases this may not be fantastically >>> accurate, country level. In the United States for wireline it is based >>> on the calling line ID, and either an ESRD (roughly representing a >>> cell) >>> or an ESRK (representing a rough calling area) for wireless. >>> >>> Perhaps, like some other working groups we need to make the distinction >>> between support and implement. I am asking that the requirements >>> include >>> support for it, I think that implementation will be something that >>> jurisdictions have the option to do or not. >> >> This doesn't quite work, given that phones need to work universally. >> I don't want to buy a phone in Prague, say, that suddenly can't make >> an emergency call in New York city. >> >> Henning >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> >> > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 18:15: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 1HRFGp-00017B-AR; Tue, 13 Mar 2007 18:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRFGo-00016i-AX for geopriv@ietf.org; Tue, 13 Mar 2007 18:15:02 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRFGn-0000lb-0t for geopriv@ietf.org; Tue, 13 Mar 2007 18:15:02 -0400 X-SEF-Processed: 5_0_0_910__2007_03_13_17_20_56 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, 13 Mar 2007 17:20:56 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 17:14:58 -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: [Geopriv] NENA Requirements Date: Tue, 13 Mar 2007 17:14:56 -0500 Message-ID: In-Reply-To: <45F6C995.5060500@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] NENA Requirements Thread-Index: AcdliD6pKcBRDcFnRRGau6y2Ja8NswANMAEg From: "Winterbottom, James" To: "Richard Barnes" , "Andrew Newton" X-OriginalArrivalTime: 13 Mar 2007 22:14:58.0620 (UTC) FILETIME=[0983B7C0:01C765BD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Ted Hardie , "Dawson, Martin" , Marc Linsner , GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org This is very well stated and I completely agree with you Richard.=0D=0A=0D=0A= > -----Original Message-----=0D=0A> From: Richard Barnes [mailto:rbarnes@bb= n.com]=0D=0A> Sent: Wednesday, 14 March 2007 2:56 AM=0D=0A> To: Andrew Newt= on=0D=0A> Cc: Ted Hardie; Dawson, Martin; Marc Linsner; GEOPRIV=0D=0A> Subj= ect: Re: [Geopriv] NENA Requirements=0D=0A>=20=0D=0A> > Location signing ha= s been offered as a requirement. It has been=0D=0Apointed=0D=0A> > out tha= t location signing is a solution and not a requirement. It=0D=0Ahas=0D=0A>= > also been pointed out that the notion of network topology that is=0D=0Ab= eing=0D=0A> > applied to VoIP by this solution does not match the way the I= nternet=0D=0A> works.=0D=0A>=20=0D=0A> However, the security of voice servi= ces (emergency calling in=0D=0A> particular) depends centrally on the trust= relationships that are=0D=0A> currently encoded in the topology of the PST= N. These trust=0D=0A> relationships are what need to persist through the t= ransition to an=0D=0A> IP-based infrastructure. Public-key cryptography is= how trust=0D=0A> relationships are codified and communicated in the modern= Internet=0D=0A> community. From the little I know about it, NENA's VESA e= ffort seems=0D=0A> like a good example of this translation.=0D=0A>=20=0D=0A= > --Richard=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> > Also, it has been fair t= o question the actual use of location=0D=0Asigning=0D=0A> > with respect to= invalidly signed or unsigned location information.=0D=0ATo=0D=0A> > date, = nobody has offered an authoritative policy... it is all=0D=0A> > suppositio= n. It seems rather silly to claim to be the authoritative=0D=0A> > voice o= n this issue when you cannot give concrete policy examples.=0D=0A> >=0D=0A>= > -andy=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A----------------------------------= --------------------------------------=0D=0A> >=0D=0A> > __________________= _____________________________=0D=0A> > Geopriv mailing list=0D=0A> > Geopri= v@ietf.org=0D=0A> > https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A> =0D= =0A>=20=0D=0A> _______________________________________________=0D=0A> Geopr= iv mailing list=0D=0A> Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailma= n/listinfo/geopriv=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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 18:26:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRFRi-0001it-Ul; Tue, 13 Mar 2007 18:26:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRFRh-0001ij-Lt for geopriv@ietf.org; Tue, 13 Mar 2007 18:26:17 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRFRh-0002OW-9F for geopriv@ietf.org; Tue, 13 Mar 2007 18:26:17 -0400 X-SEF-Processed: 5_0_0_910__2007_03_13_17_32_15 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, 13 Mar 2007 17:32:15 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 17:26:16 -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: [Geopriv] RE: Strawman Proposal Date: Tue, 13 Mar 2007 17:26:14 -0500 Message-ID: In-Reply-To: <45F71D66.3030406@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: Strawman Proposal Thread-Index: Acdlun5dO0qH7qDqSNWoXGJSkn/jIwAAxkQg From: "Winterbottom, James" To: "Hannes Tschofenig" , "Richard Barnes" X-OriginalArrivalTime: 13 Mar 2007 22:26:16.0870 (UTC) FILETIME=[9DC87460:01C765BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: GEOPRIV , "Dawson, Martin" , Marc Linsner , Henning Schulzrinne X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Let me put a very real case out there, and see if it can be overcome=0D=0Aj= ust using location by reference and no signing.=0D=0A=0D=0AI have two entit= ies that are required to provide my access network. And=0D=0AISP and a regi= on access network provider (RANP). The ISP cannot=0D=0Adetermine location, = yet any location reference will point to him, in LIS=0D=0Aterms it is a gat= eway LIS. The ISP must get location from the RANP. When=0D=0Alocation is re= quested from the ISP by a reference, the ISP presents its=0D=0Aown certific= ate to the LR, yet it is not the ultimate source of the=0D=0Alocation infor= mation. How does a certificate from the ISP link back to=0D=0Alocation bein= g provided by the RANP in this case=3F=0D=0A=0D=0AI guess I don't see a cer= tificate used to establish a TLS session with a=0D=0ALIS as being the neces= sarily of the same stock as a certificate used to=0D=0Asign a location. But= maybe it is just me.=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D= =0A> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> Sent= : Wednesday, 14 March 2007 8:54 AM=0D=0A> To: Richard Barnes=0D=0A> Cc: GEO= PRIV; Dawson, Martin; Marc Linsner; Henning Schulzrinne=0D=0A> Subject: Re:= [Geopriv] RE: Strawman Proposal=0D=0A>=20=0D=0A> We mentioned the idea of = putting two PIDF-LOs into a SIP signaling=0D=0A> message, namely one for ro= uting and another one for consumption at the=0D=0A> PSAP.=0D=0A> The one fo= r routing does not need to provide a perfect precision, as=0D=0Awe=0D=0A> k= now. For some countries it would be sufficient to use state=0D=0Agranularit= y=0D=0A> to hit the correct PSAP.=0D=0A>=20=0D=0A> I am also addressing tho= se people who argue that "Operators will never=0D=0A> provide location info= rmation to the end host because they want to make=0D=0A> money with locatio= n-based applications. Hence, they can only use=0D=0A> location-by-reference= ".=0D=0A>=20=0D=0A> I don't want to create relationships between every VoIP= provider and=0D=0A> every access network provider in the world because I b= elieve that this=0D=0A> will do a lot of harm to the Internet. I am OK with= a relationship=0D=0A> between access network provider and PSAPs even thoug= h I see a lot of=0D=0A> problems there as well.=0D=0A>=20=0D=0A> If we have= to use a location-by-reference mechanism for these=0D=0Aoperators=0D=0A> t= hen we don't need location signing.=0D=0A>=20=0D=0A> I doubt that signed lo= cation information can be demanded for all=0D=0A> emergency service calls s= ince we will even see calls with absolutely=0D=0Ano=0D=0A> location informa= tion at all. Furthermore, we would have to tell the=0D=0AIEEE=0D=0A> to go = home since none of their solution does any sort of signing.=0D=0A>=20=0D=0A= > Ciao=0D=0A> Hannes=0D=0A>=20=0D=0A>=20=0D=0A> Richard Barnes wrote:=0D=0A= > >> Take a large campus with thousands of offices. Unless you have a=0D=0A= > >> fairly elaborate delegation mechanism, somebody externally will=0D=0Ah= ave=0D=0A> >> to sign for each and every room. This means that the organiza= tion=0D=0Ahas=0D=0A> >> to operate a CA that is trusted by the proposed VES= A entity, for=0D=0A> >> example. We can't even get delegation to work withi= n Internet2 and=0D=0A> >> Columbia.=0D=0A> >=0D=0A> > Location granularity = and certification granularity are two=0D=0Aorthogonal=0D=0A> > issues. If = there's one server that knows the geography of the whole=0D=0A> > Columbia = campus, then there's only one certificate to manage. If=0D=0Ayou=0D=0A> > = have one per building, then you have might a few more, or you might=0D=0A> = > have each server reach back to a central signing server for a=0D=0Asignat= ure.=0D=0A> >=0D=0A> > --RB=0D=0A> >=0D=0A> >>=0D=0A> >>=0D=0A> >>=0D=0A> >= >=0D=0A> >>>=0D=0A> >>> [AJW] It is not clear to me how authenticating mill= ions of users=0D=0Aand=0D=0A> >>> their multitude of identity mechanisms is= any less daunting than=0D=0A> >>>=0D=0A> >>=0D=0A> >> We have such a mecha= nism, e.g., within IMS, namely P-Asserted-ID,=0D=0A> >> which is very widel= y deployed, from what I can tell. Or the SIP=0D=0A> >> identity mechanism, = although that seems to just start getting=0D=0A> >> traction. The PSAP woul= dn't care whether and how the VSP verified=0D=0Athe=0D=0A> >> customer iden= tity; it just gets a single client cert from the VSP=0D=0Ain=0D=0A> >> a TL= S connection.=0D=0A> >>=0D=0A> >> You probably missed the discussion on thi= s years ago, but your=0D=0A> >> concern and the perceived difficulties of a= global PKI motivated=0D=0Athe=0D=0A> >> current mechanism, as it only requ= ires what customers must have=0D=0A> >> already, namely a shared secret wit= h their VSP, and web-style=0D=0A> >> cross-provider trust with a single cer= t for each provider.=0D=0A> >>=0D=0A> >>=0D=0A> >>> providing accreditatio= n to potentially thousands of access network=0D=0A> >>> providers. But perh= aps I am missing the point. That said, if you=0D=0A> couple=0D=0A> >>> this= with signed location then you have the whole gamut. See=0D=0Alocation=0D=0A= > >>> dependability draft=0D=0A> >>> http://tools.ietf.org/html/draft-thoms= on-geopriv-location-=0D=0A> dependability-=0D=0A> >>>=0D=0A> >>> 00=0D=0A> = >>>=0D=0A> >>>>=0D=0A> >>>> PS: I also believe that the PSAP operator would= accept calls that=0D=0A> >>> don't=0D=0A> >>>> have any location attached = to it. How many calls today have=0D=0Alocation=0D=0A> >>>> information avai= lable=3F Do we have some statistics about it=3F=0D=0A> >>>>=0D=0A> >>>=0D=0A= > >>> [AJW] All emergency calls in the world have some degree of=0D=0Alocat= ion=0D=0A> >>> provided (inferred), though in some cases this may not be=0D= =0A> fantastically=0D=0A> >>> accurate, country level. In the United States= for wireline it is=0D=0Abased=0D=0A> >>> on the calling line ID, and eithe= r an ESRD (roughly representing a=0D=0A> >>> cell)=0D=0A> >>> or an ESRK (r= epresenting a rough calling area) for wireless.=0D=0A> >>>=0D=0A> >>> Perha= ps, like some other working groups we need to make the=0D=0A> distinction=0D= =0A> >>> between support and implement. I am asking that the requirements=0D= =0A> >>> include=0D=0A> >>> support for it, I think that implementation wil= l be something that=0D=0A> >>> jurisdictions have the option to do or not.=0D= =0A> >>=0D=0A> >> This doesn't quite work, given that phones need to work=0D= =0Auniversally.=0D=0A> >> I don't want to buy a phone in Prague, say, that = suddenly can't=0D=0Amake=0D=0A> >> an emergency call in New York city.=0D=0A= > >>=0D=0A> >> Henning=0D=0A> >>=0D=0A> >> ________________________________= _______________=0D=0A> >> Geopriv mailing list=0D=0A> >> Geopriv@ietf.org=0D= =0A> >> https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A> >>=0D=0A> >>=0D= =0A> >=0D=0A> >=0D=0A> >=0D=0A> > _________________________________________= ______=0D=0A> > Geopriv mailing list=0D=0A> > Geopriv@ietf.org=0D=0A> > htt= ps://www1.ietf.org/mailman/listinfo/geopriv=0D=0A>=20=0D=0A>=20=0D=0A> ____= ___________________________________________=0D=0A> Geopriv mailing list=0D=0A= > Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 18:28: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 1HRFU8-0003Rq-Vf; Tue, 13 Mar 2007 18:28:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRFU8-0003Rl-J5 for geopriv@ietf.org; Tue, 13 Mar 2007 18:28:48 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRFU7-0002gd-Bt for geopriv@ietf.org; Tue, 13 Mar 2007 18:28:48 -0400 X-SEF-Processed: 5_0_0_910__2007_03_13_17_34_45 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, 13 Mar 2007 17:34:45 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 17:28:47 -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 Date: Tue, 13 Mar 2007 17:28:45 -0500 Message-ID: In-Reply-To: <45F71A47.7030604@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Strawman Proposal Thread-Index: AcdluDgfmUTnp+GSSGGHyop+BrNShQABnBCw From: "Winterbottom, James" To: "Hannes Tschofenig" X-OriginalArrivalTime: 13 Mar 2007 22:28:47.0167 (UTC) FILETIME=[F75DF4F0:01C765BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: GEOPRIV , "Dawson, Martin" , Marc Linsner Subject: [Geopriv] RE: Strawman Proposal X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org > > [AJW] All emergency calls in the world have some degree of location=0D=0A= > > provided (inferred), though in some cases this may not be=0D=0Afantasti= cally=0D=0A> > accurate, country level.=0D=0A>=20=0D=0A> I don't think that= this is true. I have heard from cases where the=0D=0A> location informatio= n is only retrieved when absolutely needed.=0D=0A>=20=0D=0A=0D=0A[AJW] If y= ou don't even have country level (inferred by something), then=0D=0Ayou can= 't route the call at all. So while location may not be displayed=0D=0Ato th= e operator, the operator can be pretty sure that you are in the=0D=0Asame c= ountry, and in some places the inferred granularity is much=0D=0Agreater.=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 13 18:56: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 1HRFue-0002lZ-Lx; Tue, 13 Mar 2007 18:56:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRFud-0002jH-21 for geopriv@ietf.org; Tue, 13 Mar 2007 18:56:11 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRFua-0007fe-Gl for geopriv@ietf.org; Tue, 13 Mar 2007 18:56:11 -0400 X-SEF-Processed: 5_0_0_910__2007_03_13_18_02_05 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); Tue, 13 Mar 2007 18:02:05 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 17:56:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] NENA Requirements Date: Tue, 13 Mar 2007 17:55:20 -0500 Message-ID: In-Reply-To: <2466A53A-0D94-4199-B249-8647BBD9D8C1@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] NENA Requirements Thread-Index: AcdlhMkHAsG37OvYQwqbUN6B5E2RmAAPUdhw From: "Dawson, Martin" To: "Andrew Newton" X-OriginalArrivalTime: 13 Mar 2007 22:56:07.0376 (UTC) FILETIME=[C901FD00:01C765C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: Ted Hardie , GEOPRIV , Marc Linsner X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2087996541==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============2087996541== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C765C2.AE16B2F1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C765C2.AE16B2F1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The discourse has been rife with concrete policy examples - and Brian=0D=0A= just added his version two posts ago.=0D=0A=0D=0A=20=0D=0A=0D=0AThe argumen= ts against location signing have been "Certificate management=0D=0Ais too c= omplicated - people won't succeed" and "PSAPs answer all the=0D=0Acalls any= way so there's no point".=0D=0A=0D=0A=20=0D=0A=0D=0AIn the case of the form= er, I accept NENA's word for it that they=0D=0Aunderstand the problem space= and can make a successful judgement with=0D=0Arespect to succeeding. The m= embership consists of everyone from the=0D=0Acarrier space through to the P= SAPs. The constant repetition of the=0D=0Asecond point only emphasises that= people don't understand how the=0D=0Acredentials can be used.=0D=0A=0D=0A =0D= =0A=0D=0AThe requirements have been spelt out - and location signing has be= en=0D=0Aproffered as the solution. The nay-sayers position is that the=0D=0A= requirement should be discounted - they should offer a superior solution=0D= =0Aif they have one.=0D=0A=0D=0A=20=0D=0A=0D=0AI have never said that the I= ETF has no experts in the identified fields=0D=0A- have I=3F=0D=0A=0D=0A =0D= =0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A______________= __________________=0D=0A=0D=0AFrom: Andrew Newton [mailto:andy@hxr.us]=20=0D= =0ASent: Wednesday, 14 March 2007 2:32 AM=0D=0ATo: Dawson, Martin=0D=0ACc: = Brian Rosen; Ted Hardie; GEOPRIV; Marc Linsner=0D=0ASubject: Re: [Geopriv] = NENA Requirements=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0AOn Mar 13, 2007,= at 11:11 AM, Dawson, Martin wrote:=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0ANENA= are "the experts here" when it comes to requirements. People in=0D=0A=0D=0A= this working group are trying to say what emergency services policy=0D=0A=0D= =0Ashould be and I believe that belongs with NENA for the US and equivalent=0D= =0A=0D=0Aentities for other jurisdictions.=0D=0A=0D=0A=20=0D=0A=0D=0AMartin= ,=0D=0A=0D=0A=20=0D=0A=0D=0AI'm not sure what it is you are attempting to d= o, but to suggest that=0D=0Athe IETF has no experts in the field of network= security or Internet=0D=0Atopology and cannot therefore apply that knowled= ge is quite simply=0D=0Awrong.=0D=0A=0D=0A=20=0D=0A=0D=0ALocation signing h= as been offered as a requirement. It has been pointed=0D=0Aout that locati= on signing is a solution and not a requirement. It has=0D=0Aalso been poin= ted out that the notion of network topology that is being=0D=0Aapplied to V= oIP by this solution does not match the way the Internet=0D=0Aworks.=0D=0A=0D= =0A=20=0D=0A=0D=0AAlso, it has been fair to question the actual use of loca= tion signing=0D=0Awith respect to invalidly signed or unsigned location inf= ormation. To=0D=0Adate, nobody has offered an authoritative policy... it i= s all=0D=0Asupposition. It seems rather silly to claim to be the authorita= tive=0D=0Avoice on this issue when you cannot give concrete policy examples= =2E=0D=0A=0D=0A=20=0D=0A=0D=0A-andy=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 ------_=_NextPart_001_01C765C2.AE16B2F1 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| UA |--------------------->| LIS | | | ID(UA;VSP) | | +------+ +-------+ | | +------+ SLO3| | | +-------->| LR | | | +------+ ID(A;B) = identifier of A in the context of B SLO* = signed location objects Generating a signed LO (SLO): 1. UA gets the ID of the LIS via an LCP 2. UA notifies the LIS that its VSP will be contacting it 3. UA tells its VSP the ID of its LIS, and the identifier that identifies it to that LIS 4. VSP requests users location using provided identity 5. LIS returns a signed object of the form SLO1 = LIS{ ID(UA;LIS), Location Information} 6. VSP returns a signed object of the form SLO2 = VSP{ ID(UA;VSP), SLO1 } 7. UA can optionally construct a third signed object of the form SLO3 = UA{ rules, SLO2 } * NB: VSP role could be played by a trusted module on the UA device. Semantics: -- LIS signature asserts ID(UA;LIS) at specified location -- VSP signature asserts ID(UA;VSP) and ID(UA;LIS) identify the same entity -- UA signature binds rules to rest of LO Assumptions: 1. UA authenticated to VSP using ID(UA;VSP) (e.g., using SIP digest auth) 2. UA authenticated to LIS using ID(UA;LIS) (e.g., via physical / MAC layer authentication) 3. For any other UA' under the same LIS 4. LIS and VSP are trusted to work properly 5. Location is determined by the LIS and ID(UA;LIS) Security properties: 1. It's hard for the UA to spoof either identity: -- If it lies to the LIS about ID(UA;VSP), then the one sent by the VSP in its request won't match up -- If it lies to the VSP about ID(UA;LIS), then the one in the VSP's request won't match the UA that notified the LIS. 2. Because, in particular, the LIS ID can't be spoofed, location can't be spoofed. Remaining attacks: 1. This would allow two attackers served by the same VSP and LIS to exchange locations by swapping the ID(*;VSP) values sent to the LIS and the ID(*;LIS) values sent to the VSP. This can be mitigated, e.g., by restricting the coverage area of any particular LIS. _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 14 09:45: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 1HRTmm-0001wP-77; Wed, 14 Mar 2007 09:45:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRTml-0001wF-BC for geopriv@ietf.org; Wed, 14 Mar 2007 09:44:59 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRTmd-0007O7-Oq for geopriv@ietf.org; Wed, 14 Mar 2007 09:44:59 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 14 Mar 2007 09:44:51 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2EDipRD009107; Wed, 14 Mar 2007 09:44:51 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2EDieGd002587; Wed, 14 Mar 2007 13:44:44 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 09:44:40 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 09:44:39 -0400 From: "Marc Linsner" To: "'Winterbottom, James'" , "'Dawson, Martin'" Subject: RE: [Geopriv] NENA Requirements Date: Wed, 14 Mar 2007 09:44:39 -0400 Message-ID: <008e01c7663e$ea186020$230d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcdleygCmJm50oJ+RB2PaCWq+C6B3AAAJhPQAADQdtAAAVQHMAAQTbXwAAFU1sAAANCY4AAFENEgAAHaVTAAFO2eAA== X-OriginalArrivalTime: 14 Mar 2007 13:44:39.0885 (UTC) FILETIME=[E9BD47D0:01C7663E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=29813; t=1173879891; x=1174743891; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20NENA=20Requirements |Sender:=20 |To:=20=22'Winterbottom, =20James'=22=20, =0 A=20=20=20=20=20=20=20=20=22'Dawson, =20Martin'=22=20; bh=0eEshJwUkSm8p7QbKAvENPmkEPeuW84AuW7YbIIFhyo=; b=NZYTKrOssalxH2Zcb55dYT1QHH1IimofrayLFc7x2+abMz9YP3bxMkVlbA9YBphXMxsjxJ+x WeRpIHn4jT+AsNZa9b2sRP5lWKUrwl8EFMqsPlYR76AFqeGREvDiU7Vd; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 419681661a5a61835a9a79996a04e3e9 Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org James, Martin Your total disregard of the information from those that have experience in the solution space you are suggesting is amazing. Andy has actual experience (made a living doing such) in digital signatures and certificate management, your experience in this area is not apparent. But yet your attitude of 'Don't confuse me with the facts my mine's made up!' seems very odd to many people. Like Andy stated, you think it's rough now, wait till your proposal gets to the IESG. I'm only glad that it won't be shepherded by an ECRIT chair. :^) -Marc- > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Tuesday, March 13, 2007 11:41 PM > To: Marc Linsner; Dawson, Martin > Cc: GEOPRIV > Subject: RE: [Geopriv] NENA Requirements > > Marc, > > Your statement below is not really correct. The IETF only > requires a rough consensus to carry a motion. The only people > that are really objecting to this concept are you are Andy. > Most the other vocal people largely seem to be in agreement > that it has merit. On that score I would say that we have a > rough consensus and that the sausage is sizzled! > > Cheers > James > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Wednesday, 14 March 2007 2:23 PM > > To: Dawson, Martin > > Cc: 'GEOPRIV' > > Subject: RE: [Geopriv] NENA Requirements > > > > Martin, > > > > You are correct, your efforts to meet NENA desires are > valiant. And > > during that process you disregarded all warnings that your solution > > would not > be > > successful on the Internet, afterall, it works in the lab. Now in > this > > venue, you are still disregarding such warnings. > > > > The speed at which this venue completes work is directly related to > > everyone agreeing that the solution, not only fulfills the > > requirements, but > has a > > half a chance of success on the Internet. > > > > I apologize for the forum shopping statement, I applied the 'score > sheet > > that lacks engineering' project in ATIS to you, I could be wrong. > > > > -Marc- > > > > > -----Original Message----- > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > Sent: Tuesday, March 13, 2007 8:35 PM > > > To: Marc Linsner > > > Cc: GEOPRIV > > > Subject: RE: [Geopriv] NENA Requirements > > > > > > Well thanks for putting your cards on the table. I prefer > to be able > > > to defend myself from direct comment than continually > having to deal > > > with insinuation. > > > > > > What you say is quite incorrect. We worked with NENA to > understand > > > their requirements and designed the best solution we > could to meet > > > those requirements; that's why HELD looks the way it > does. The only > > > forum we have tabled HELD in for specification so far is the IETF. > > > > > > What you are using is called "ad hominem rhetoric". Look it up. > > > People don't need to have an opinion of me to have an > opinion on the > > > protocols and to assess the arguments with respect to > requirements. > > > > > > There are folk who are responsible for deploying solutions *now*. > > > Look at the Canadian situation with respect to the CRTC ruling on > > > implementing i2. The requirements for the location acquisition > > > protocol are as described, but they need an actual > specification now > > > - not "some time"; that's why I'm anxious to move a specification > > > forward that will meet the immediate requirements. > > > > > > Cheers, > > > Martin > > > > > > -----Original Message----- > > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > > Sent: Wednesday, 14 March 2007 11:03 AM > > > To: Dawson, Martin > > > Cc: 'GEOPRIV' > > > Subject: RE: [Geopriv] NENA Requirements > > > > > > Martin, > > > > > > Since you obviously missed the inference, I'll explain. It isn't > > > the NENA general population that I witnessed reverse engineering > > > requirements from their solution, it was YOU reverse engineering > > > requirements from YOUR solution. This is something you > have become > > > proficient at as you forum shop. > > > > > > -Marc- > > > > > > > > > > -----Original Message----- > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > Sent: Tuesday, March 13, 2007 7:33 PM > > > > To: Marc Linsner > > > > Cc: GEOPRIV > > > > Subject: RE: [Geopriv] NENA Requirements > > > > > > > > Yes, I understand what you're saying - I just think it > is wrong. I > > > > think the requirements really are borne of genuine > operational and > > > > application domain specific requirements - not from a > > > mindless attempt > > > > to retro-fit convention from switched circuit to Internet. > > > > > > > > Cheers, > > > > Martin > > > > > > > > -----Original Message----- > > > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > > > Sent: Wednesday, 14 March 2007 3:08 AM > > > > To: Dawson, Martin > > > > Cc: 'GEOPRIV' > > > > Subject: RE: [Geopriv] NENA Requirements > > > > > > > > Martin, > > > > > > > > I think the disconnect lies between the understanding of IP and > the > > > > understanding of the Internet. > > > > > > > > NENA's knowledge/experience is with 'closed' single purpose > > > systems, > > > > the Internet is an 'open' general use system. > > > > Closed single purpose will always perform the designed-for > > > task better > > > > than a general purpose system. So, while lots of > people clamor to > > > > additional attributes that IP can/will deliver to a PSAP, > > > most within > > > > NENA don't understand the Internet architecture (note: IP > knowledge > > > > does not equal Internet knowledge). > > > > The > > > > IETF can/will fill that knowledge void wrt how the > Internet works. > > > > > > > > IMO, as a long-time NENA member and limited participant/casual > > > > observer of happenings inside NENA, several of the > published NENA > > > > requirements were reverse engineered from an understood > solution. > > > > Asking the IETF to exonorate the NENA solution will not produce > the > > > > desired outcome. NENA MUST convey their raw requirements > > > (hopefully > > > > in an Internet context) in order to foster a desire to > solve their > > > > problems. A great deal of frustration is derived > > > attempting to wade > > > > through the reverse engineered requirements to try and > > > understand the > > > > real underlying requirement. And it is fact that not every > > > > requirement has an Internet solution (or spam would cease to > exist). > > > > > > > > One large point that NENA has failed to admit in the > > > Internet context > > > > is they will not control what is launched at them on the > > > Internet from > > > > afar. > > > > This is not something they are used to in their current > environment. > > > > > > > > I have hope that we'll get there....but I sense more > pain in the > > > > future. > > > > > > > > -Marc- > > > > > > > > > -----Original Message----- > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > > Sent: Tuesday, March 13, 2007 11:11 AM > > > > > To: Brian Rosen; Andrew Newton > > > > > Cc: Ted Hardie; GEOPRIV; Marc Linsner > > > > > Subject: RE: [Geopriv] NENA Requirements > > > > > > > > > > I agree with everything you said Brian - with the > > > exception that I > > > > > didn't think James was attempting to rewrite the NENA > > > > requirements; I > > > > > certainly didn't infer that he was quoting them; perhaps > > > > because I'm > > > > > familiar enough with them that I can see the difference. At > > > > some point > > > > > in time, in some jurisdiction, the policies he tabled > may quite > > > > > credibly become that strict. > > > > > > > > > > NENA is NENA and there are plenty of people who are only > > > > comfortable > > > > > with their own domain but there are also plenty of people who > are > > > > > comfortable with IP - that is my assessment > > > > > - after all, it is an old protocol suite and it's been used > > > > for plenty > > > > > of systems in the emergency infrastructure before it ever > > > became a > > > > > voice trunking protocol. I have never liked the > nethead/bellhead > > > > > language because I think it gives wings to prejudice > and clouds > > > > > judgement. What I am saying is that I believe there is > > > > sufficient body > > > > > of knowledge and expertise in NENA to assess for > themselves the > > > > > validity, value, and practicality of having signed > > > > location. I think > > > > > you do too. > > > > > Particular individuals certainly did do a lion's share or > > > > the work in > > > > > the migratory and location working groups in NENA but nothing > was > > > > > documented that wasn't fully discussed, assessed, and > > > agreed by the > > > > > wider group. > > > > > > > > > > NENA are "the experts here" when it comes to requirements. > > > > > People in this working group are trying to say what > > > > emergency services > > > > > policy should be and I believe that belongs with NENA for > > > > the US and > > > > > equivalent entities for other jurisdictions. > > > > > > > > > > What you suggest with respect to call treatment is also > perfectly > > > > > valid and I have cited the same policy in previous posts as > > > > an example > > > > > of something realistic that the emergency jurisdiction > > > may want to > > > > > apply. > > > > > It's all perfectly sensible and reasonable. > > > > > > > > > > This debate isn't just about building up or putting down NENA > > > > > - I am trying to ensure that the requirements of real end > > > > users don't > > > > > get quashed because somebody felt those end users weren't > > > > qualified to > > > > > articulate their real needs. It goes directly to what > > > > relevant outputs > > > > > this working group is going to define. > > > > > > > > > > Cheers, > > > > > Martin > > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Wednesday, 14 March 2007 1:43 AM > > > > > To: 'Andrew Newton'; Dawson, Martin > > > > > Cc: 'Ted Hardie'; 'GEOPRIV'; 'Marc Linsner' > > > > > Subject: RE: [Geopriv] NENA Requirements > > > > > > > > > > Martin > > > > > > > > > > As a very frequent contributor to NENA, and specifically, > > > > someone who > > > > > participated, albeit somewhat intermittently in the > > > > development of the > > > > > requirements which you are referring to, I feel that we > > > > should point > > > > > out that these specific requirements come primarily from > > > me (in the > > > > > case of several of the security related requirements) > and James > > > > > Winterbottom, although there are several other people > who were > > > > > involved. > > > > > Although I have been working with NENA for several > years now, I > > > > > personally feel like I'm still the nethead in an > > > otherwise bellhead > > > > > environment there. We're telling them how IP networks > > > > behave and how > > > > > they need to deal with them. They certainly tell us a lot > > > > about how > > > > > the current system works, and how they use it. I don't > > > > think however, > > > > > in this case, that you can really assert it is NENA that > > > > brought forth > > > > > these requirements. We did it, and we pushed them > through NENA. > > > > > There isn't anything necessarily wrong with that; I just > > > think you > > > > > need to lay off some of the "NENA is the expert here" > > > > > rhetoric. I > > > > > don't even (personally) agree with some of them as written. > > > > > It is, however, undeniably an approved NENA work product. > > > > > > > > > > I also feel somewhat uncomfortable with James' attempt to > > > > rewrite the > > > > > NENA requirements. I wouldn't agree with how he > > > > characterizes them. > > > > > I'm actually more on Andy's side with regard to what these > > > > mechanisms > > > > > we are talking about are used for. > > > > > > > > > > I would say, however, that there is policy that > guides how the > > > > > mechanisms are used. It may well be in normal circumstances > that > > > > > calls with missing or invalid security checks are > processed as a > > > > > normal call, but with some alert to the call taker to be > > > > more careful. > > > > > However, if the PSAP was under direct DoS attack, > then it may be > > > > > policy that calls with missing or invalid security checks > > > > are put on a > > > > > queue that is answered less promptly than calls that have all > the > > > > > security mechanisms in place and working, or those calls > > > > may be chosen > > > > > to be diverted to another PSAP. That might depend on > the attack > > > > > signature (and the policy). > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > > > Sent: Tuesday, March 13, 2007 10:23 AM > > > > > > To: Dawson, Martin > > > > > > Cc: Ted Hardie; GEOPRIV; Marc Linsner > > > > > > Subject: Re: [Geopriv] NENA Requirements > > > > > > > > > > > > Martin, > > > > > > > > > > > > It is actually quite appropriate for the IETF to determine > > > > > the scope > > > > > > of its own work. The IETF is not at the beck and call of > other > > > > > > organizations, just as they are not at the beck and call of > > > > > the IETF. > > > > > > And we do have the right to question requirements, and it > > > > > says a lot > > > > > > if those requirements cannot stand up to scrutiny. And the > > > > > IETF does > > > > > > have a right to apply its broad collective of knowledge and > > > > > experience > > > > > > on networking to a specific topic area, regardless of how > > > > you feel > > > > > > about any individual's investment in the problem space. > > > > > > > > > > > > With respect to NENA, it is rude of you to suggest that > > > > > others on this > > > > > > list are not respectful towards it. I and several others on > > > > > this list > > > > > > are agents of entities that have contributed non-trivial > > > > amounts of > > > > > > funds to NENA so that it may continue its mission. NENA > > > > has a very > > > > > > important role to fill, one which the IETF cannot and > > > > will not take > > > > > > on. > > > > > > > > > > > > -andy, co-chair of GEOPRIV > > > > > > > > > > > > On Mar 13, 2007, at 1:55 AM, Dawson, Martin wrote: > > > > > > > > > > > > > It's actually quite inappropriate for the IETF to be > > > > stating what > > > > > the > > > > > > > policies for emergency services in global jurisdictions > > > > > needs to be. > > > > > > > James' rules below may, indeed, be a strawman but they > > > > > represent one > > > > > > > possible set of rules that one possible jurisdiction > > > > may wish to > > > > > > > adopt. > > > > > > > > > > > > > > It is an act of hubris for the IETF to deprive > > > jurisdictions of > > > > > these > > > > > > > mechanisms because individuals who aren't actually the > > > > > ones who are > > > > > > > going to be the stakeholders didn't think it could be > handled > > > > > > > properly. > > > > > > > > > > > > > > NENA - who do represent a very broad cross-section of > genuine > > > > > > > stakeholders - do consider that they have the chops to > > > > institute > > > > > > > something like VESA and make it work for them. I have > > > > the utmost > > > > > > > confidence that they will be able to make it work and > > > > > that it will > > > > > > > contribute to the integrity, in a significant way, of the > > > > > emergency > > > > > > > service. There's a tendency to be dismissive of their > > > > skills and > > > > > > > knowledge in these areas which I think is similarly > > > > > patronising and > > > > > > > quite incorrect. They have more experience in > making complex > > > > > networks, > > > > > > > organizations, and processes work than most of the > > > > > commentators on > > > > > > > this list. I say give them the tools they are asking for. > > > > > > > > > > > > > > Things evolve. In the long term it may actually be > considered > > > > > > > unacceptable for an access network to not provide a > > > > > robust mechanism > > > > > > > for instantaneous location determination rather than > > > > "attachment > > > > > > > time" > > > > > > > location. I suggest that it will always be possible > > > to do this, > > > > > > > regardless of access technology, given the right > > > > approach. Ideally > > > > > the > > > > > > > capabilities of networks won't be frozen in time and they > will > > > > > become > > > > > > > more sophisticated in this respect as time goes by. > > > > > > > > > > > > > > On point 4 - you may argue that the "accountability" > > > > aspect is not > > > > > an > > > > > > > engineering requirement. Perhaps not; it's a service > > > > > requirement and > > > > > > > it creates the opportunity to provide an engineering > > > > > solution. There > > > > > > > is very real value in being able to reliably associate > > > > > the location > > > > > with > > > > > > > the source so that errors in the system can be traced to > > > > > that source > > > > > > > and corrected. Closing the loop in this way for > continuous > > > > > > > improvement > > > > > is > > > > > > > part of the existing switched circuit telephony > > > > emergency service > > > > > > > processes and there's no less of an imperative > for it for IP > > > > > > > telephony. > > > > > > > Yet another of the uses of signed location is in > > > providing this > > > > > robust > > > > > > > link back to the source for this purpose; it's an > engineering > > > > > solution > > > > > > > that suggests itself. > > > > > > > > > > > > > > Cheers, > > > > > > > Martin > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Ted Hardie [mailto:hardie@qualcomm.com] > > > > > > > Sent: Tuesday, 13 March 2007 3:35 PM > > > > > > > To: Winterbottom, James; Marc Linsner; Dawson, Martin > > > > > > > Cc: GEOPRIV > > > > > > > Subject: RE: [Geopriv] NENA Requirements > > > > > > > > > > > > > > At 6:44 PM -0500 3/12/07, Winterbottom, James wrote: > > > > > > >> The 4 requirements I am tabling are below. > > > > > > >> > > > > > > >> 1) The only calls that SHALL be directed to a PSAP are > > > > > those calls > > > > > > >> that have been made by end-devices that are in the > > > > PSAP service > > > > > > >> jurisdiction at the time a call is made. > > > > > > >> > > > > > > > > > > > > > > This goes contrary to everything we have discussed > > > > > before, where the > > > > > > > theory has been that the call taker would try to take a > > > > > call in any > > > > > > > circumstance, and these indicators would be used > at most for > > > > > ranking. > > > > > > > > > > > > > > To link this to the "warnings" thread on Ecrit right > > > now, we're > > > > > saying > > > > > > > there that there will be cases where a server > should return > a > > > > > default, > > > > > > > a stale answer, or similar, because it cannot parse the > > > > request, > > > > > > > cannot reach an upstream for the data, or cannot > confirm its > > > > > > > freshness. It returns *a valid PSAP*, even if the > > > > request had an > > > > > > > unresolvable address, because doing so may save lives. > > > > > Sure, that > > > > > > > call should have health warnings and may affect the > > > > > queuing by call > > > > > > > takers, but saying you won't deliver the call because > > > > *you cannot > > > > > > > confirm at call time that the end device is > within the PSAP > > > > > > > jurisdiction* will kill someone. I reject such a > requirement > > > > > > > utterly, and I hope the > > > > > WG > > > > > > > agrees with me. Route the call, and let the local > > > policy at the > > > > > PSAP > > > > > > > decide > > > > > > > if you have to, but failing to route the call via > > > > system design is > > > > > not > > > > > > > okay. > > > > > > > > > > > > > >> 2) Any location used by routing services or > > > subsequent dispatch > > > > > > > services > > > > > > >> MUST unequivocally represent the physical position > > > of the end- > > > > > > >> device at the time the location is proffered. > > > > > > >> > > > > > > > > > > > > > > This is a strawman, or at least I hope it is. A device > > > > > that got its > > > > > > > location on > > > > > > > boot, cannot update it because of network issues, and > > > > presents its > > > > > > > position to this system is behaving according to the > > > > best-effort > > > > > > > nature of the underlying network. While the > phone system is > > > > > waiting for me to > > > > > > > present > > > > > > > an "unequivocal" location, your strawman is burning up > > > > in the car > > > > > fire > > > > > > > I was calling to report. > > > > > > > > > > > > > >> 3) Any request for location made to a LIS MUST result in > > > > > either an > > > > > > >> error, or the current location of the target device > > > > > being returned. > > > > > > >> > > > > > > > > > > > > > > And if the LIS has the location of the attachment point, > > > > > but not the > > > > > > > target device, who resolves the problem? The end node, by > > > > > presenting > > > > > > > the attachment point to the LIS for location (nice > > > > > targeting system, > > > > > > > good luck!)? Or the LIS, which should return the > > > > likely service > > > > > > > area of the attachment point as a non-point response? If > the > > > > > > > latter, we may > > > > > have > > > > > > > something useful for identifying useful PSAPs, but it > > > > is not the > > > > > > > target device's location for lots of systems in which > > > > the service > > > > > > > area is large > > > > > > > (think: > > > > > > > WiMAX). > > > > > > > > > > > > > >> 4) The source of the location information MUST be > > > > > identifiable and > > > > > is > > > > > > >> accountable for the accuracy of the information provided. > > > > > > > > > > > > > > The second is not an engineering requirement, and the > > > > > first would be > > > > > > > satisfied by a self-report for cases like enterprise > > > > > networks. That > > > > > > > might well be useful for tracking ill-described locations > and > > > > > similar > > > > > > > post-facto analyses. But you're sprinkling crypto dust > > > > > on it in the > > > > > > > hopes of recreating a system where the underlying > > > mechanism is > > > > > > > totally different. With enough thrust the pig > may fly, but > it > > > > > spoils > > > > > > > the bacon and irritates the pig. > > > > > > > > > > > > > > Ted > > > > > > > > > > > > > >> Providing you try to meet these 4 requirements I am > > > > happy. Simply > > > > > > > saying > > > > > > >> they can't be done and so they are not requirements, > > > > as has been > > > > > said > > > > > > > in > > > > > > >> the past, is not acceptable. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> Cheers > > > > > > >> James > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >>> -----Original Message----- > > > > > > >>> From: Marc Linsner [mailto:mlinsner@cisco.com] > > > > > > >>> Sent: Tuesday, 13 March 2007 2:50 AM > > > > > > >>> To: Dawson, Martin > > > > > > >>> Cc: 'GEOPRIV' > > > > > > >>> Subject: RE: [Geopriv] NENA Requirements > > > > > > >>> > > > > > > >>> Martin, > > > > > > >>> > > > > > > >>>> > > > > > > >>>> I think all of the NENA requirements have been > raised and > > > > > > >>>> discussed - the latest concept to cause indigestion > > > > is location > > > > > > >>>> signing. > > > > > > >>> > > > > > > >>> > > > > > > >>> You have requirements mixed up with solutions. > > > > Signing location > > > > > > >> objects > > > > > > >>> is > > > > > > >>> a solution. I believe Ted nailed the requirement. > > > > > > >>> > > > > > > >>> -Marc- > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> _______________________________________________ > > > > > > >>> Geopriv mailing list > > > > > > >>> Geopriv@ietf.org > > > > > > >>> https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > >> > > > > > > >> > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > >> -- > > > > > > > ------------------------- > > > > > > >> This message is for the designated recipient only and > > > > may contain > > > > > > >> privileged, proprietary, or otherwise private > > > > > information. > > > > > > >> If you have received it in error, please notify > the sender > > > > > > >> immediately and delete the original. Any > > > unauthorized use of > > > > > > >> this email is prohibited. > > > > > > >> > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > >> -- > > > > > > > ------------------------- > > > > > > >> [mf2] > > > > > > >> > > > > > > >> > > > > > > >> _______________________________________________ > > > > > > >> Geopriv mailing list > > > > > > >> Geopriv@ietf.org > > > > > > >> https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > -------------------------- > > > > > > > This message is for the designated recipient only and > > > > may contain > > > > > > > privileged, proprietary, or otherwise private information. > > > > > > > If you have received it in error, please notify > the sender > > > > > > > immediately and delete the original. Any unauthorized > > > > use of this > > > > > > > email is prohibited. > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > -------------------------- > > > > > > > [mf2] > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Geopriv mailing list > > > > > > > Geopriv@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Geopriv mailing list > > > > > > Geopriv@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------------------------------- > > > > > This message is for the designated recipient only and may > contain > > > > > privileged, proprietary, or otherwise private information. > > > > > If you have received it in error, please notify the sender > > > > immediately > > > > > and delete the original. Any unauthorized use of > this email is > > > > > prohibited. > > > > > -------------------------------------------------------------- > > > > > ---------------------------------- > > > > > [mf2] > > > > > > > > > > > > > -------------------------------------------------------------- > > > > ---------------------------------- > > > > This message is for the designated recipient only and > may contain > > > > privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > immediately > > > > and delete the original. Any unauthorized use of this email is > > > > prohibited. > > > > -------------------------------------------------------------- > > > > ---------------------------------- > > > > [mf2] > > > > > > > > > > -------------------------------------------------------------- > > > ---------------------------------- > > > This message is for the designated recipient only and may contain > > > privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized > use of this > > > email is prohibited. > > > -------------------------------------------------------------- > > > ---------------------------------- > > > [mf2] > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 14 10:16: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 1HRUHK-00040A-Q0; Wed, 14 Mar 2007 10:16:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRUHJ-0003zz-8p for geopriv@ietf.org; Wed, 14 Mar 2007 10:16:33 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRUHH-0008Qa-Tb for geopriv@ietf.org; Wed, 14 Mar 2007 10:16:33 -0400 X-SEF-Processed: 5_0_0_910__2007_03_14_09_22_30 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, 14 Mar 2007 09:22:30 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 09:16:31 -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: [Geopriv] Location signing daydream Date: Wed, 14 Mar 2007 09:16:19 -0500 Message-ID: In-Reply-To: <45F7F641.5000103@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Location signing daydream Thread-Index: AcdmO1s74gB5qbA+T32N76KqQkjT0AAByaCw From: "Dawson, Martin" To: "Richard Barnes" , "GEOPRIV" , "Matt Lepinski" X-OriginalArrivalTime: 14 Mar 2007 14:16:31.0405 (UTC) FILETIME=[5D1815D0:01C76643] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Very nice Richard - very clever.=0D=0A=0D=0AI assume LR is location recipie= nt=3F=0D=0A=0D=0AI think this adds two things:=0D=0A=0D=0A* It eliminates t= he one-off replay of a location object from a remote=0D=0Adevice (i.e. dron= e is present in the access, retrieves location,=0D=0Aprovides it to remote = third party who makes single call using that=0D=0Aobject)=0D=0A=0D=0A* It i= ncludes a signed voice service subscriber identity in the signed=0D=0Apacka= ge (I think it's more than a location object by now - since VSP=0D=0Asubscr= iber identity isn't a location attribute).=0D=0A=0D=0AFor a non-VSP scenari= o, the VSP collapses into the UA (they are their=0D=0Aown VSP) and this red= uces to obtaining the signed location object from=0D=0Athe LIS with a devic= e provided identity.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Origina= l Message-----=0D=0AFrom: Richard Barnes [mailto:rbarnes@bbn.com]=20=0D=0AS= ent: Thursday, 15 March 2007 12:19 AM=0D=0ATo: 'GEOPRIV'; Matt Lepinski=0D=0A= Subject: [Geopriv] Location signing daydream=0D=0A=0D=0ASo I got to daydrea= ming about location signing systems yesterday, and=20=0D=0Acame up with an = idea:=0D=0A=0D=0A
=0D=0A=0D=0A=0D=0A +-------+ ID(= UA;LIS), ID(UA;VSP)=20=0D=0A=0D=0A | |----------------= -----------+=0D=0A | VSP | |=0D=0A= | |<----------------------+ |=0D=0A = +-------+ SLO1 | |=0D=0A ^ | = | |=0D=0A | | = | |=0D=0A ID(LIS)| |SLO2 | |=0D=0A = ID(UA;LIS)| | | |=0D=0A | = V | V=0D=0A +------+ = +-------+=0D=0A ID(LIS) | | ID(VSP) | = |=0D=0ALCP----------->| UA |--------------------->| LIS |=0D=0A = | | ID(UA;VSP) | |=0D=0A +--= ----+ +-------+=0D=0A |=0D=0A = | +------+=0D=0A SLO3| | = |=0D=0A +-------->| LR |=0D=0A = | |=0D=0A +------+=0D=0A=0D= =0AID(A;B) =3D identifier of A in the context of B=0D=0ASLO* =3D signed loc= ation objects=0D=0A=0D=0A
=0D=0A=0D=0A=0D=0A=0D=0AGenerati= ng a signed LO (SLO):=0D=0A1. UA gets the ID of the LIS via an LCP=0D=0A2. = UA notifies the LIS that its VSP will be contacting it=0D=0A3. UA tells its= VSP the ID of its LIS, and the identifier that=20=0D=0Aidentifies it to th= at LIS=0D=0A4. VSP requests users location using provided identity=0D=0A5. = LIS returns a signed object of the form=0D=0A SLO1 =3D LIS{ ID(UA;LIS= ), Location Information}=0D=0A6. VSP returns a signed object of the form=0D= =0A SLO2 =3D VSP{ ID(UA;VSP), SLO1 }=0D=0A7. UA can optionally constr= uct a third signed object of the form=0D=0A SLO3 =3D UA{ rules, SLO2 = }=0D=0A* NB: VSP role could be played by a trusted module on the UA device.=0D= =0A=0D=0ASemantics:=0D=0A-- LIS signature asserts ID(UA;LIS) at specified l= ocation=0D=0A-- VSP signature asserts ID(UA;VSP) and ID(UA;LIS) identify th= e same=0D=0Aentity=0D=0A-- UA signature binds rules to rest of LO=0D=0A=0D=0A=0D= =0AAssumptions:=0D=0A1. UA authenticated to VSP using ID(UA;VSP)=0D=0A (= e.g., using SIP digest auth)=0D=0A2. UA authenticated to LIS using ID(UA;LI= S)=0D=0A (e.g., via physical / MAC layer authentication)=0D=0A3. For any= other UA' under the same LIS=0D=0A4. LIS and VSP are trusted to work prope= rly=0D=0A5. Location is determined by the LIS and ID(UA;LIS)=0D=0A=0D=0ASec= urity properties:=0D=0A1. It's hard for the UA to spoof either identity:=0D= =0A-- If it lies to the LIS about ID(UA;VSP), then the one sent by the VSP =0D= =0Ain its request won't match up=0D=0A-- If it lies to the VSP about ID(UA;= LIS), then the one in the VSP's=20=0D=0Arequest won't match the UA that not= ified the LIS.=0D=0A2. Because, in particular, the LIS ID can't be spoofed,= location can't=20=0D=0Abe spoofed.=0D=0A=0D=0ARemaining attacks:=0D=0A1. T= his would allow two attackers served by the same VSP and LIS to=20=0D=0Aexc= hange locations by swapping the ID(*;VSP) values sent to the LIS and=20=0D=0A= the ID(*;LIS) values sent to the VSP. This can be mitigated, e.g., by=20=0D= =0Arestricting the coverage area of any particular LIS.=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A_______________________________________________=0D= =0AGeopriv mailing list=0D=0AGeopriv@ietf.org=0D=0Ahttps://www1.ietf.org/ma= ilman/listinfo/geopriv=0D=0A=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0AThis message i= s for the designated recipient only and may=0D=0Acontain privileged, propri= etary, or otherwise private information. =20=0D=0AIf you have received it i= n 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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 14 11:21: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 1HRVI9-0004Ug-OY; Wed, 14 Mar 2007 11:21:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRVI8-0004Ub-UW for geopriv@ietf.org; Wed, 14 Mar 2007 11:21:28 -0400 Received: from mail.opengeospatial.org ([208.44.53.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRVI6-0003IK-TG for geopriv@ietf.org; Wed, 14 Mar 2007 11:21:28 -0400 Received: from SusieandCarl (c-67-174-113-243.hsd1.co.comcast.net [67.174.113.243]) (authenticated bits=0) by mail.opengeospatial.org (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l2EFLL4a022504 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 Mar 2007 11:21:22 -0400 Message-ID: <011601c7664c$6cbafd50$6401a8c0@SusieandCarl> From: "Carl Reed OGC Account" To: "Winterbottom, James" , "Andrew Newton" , "Dawson, Martin" References: Subject: Re: [Geopriv] IPR? Date: Wed, 14 Mar 2007 09:18:29 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Status: No, score=-96.0 required=5.0 tests=BAYES_50, RCVD_IN_NJABL_DUL, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, USER_IN_WHITELIST autolearn=disabled version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on mail.opengeospatial.org X-Virus-Scanned: ClamAV version 0.90.1, clamav-milter version 0.90.1 on mail.opengeospatial.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I am not a lawyer but I do spend some amount of time dealing with IPR issues in the OGC and have written general guidance on IPR for the OGC members as well as having done some considerable amount of prior-art research for the geospatial domain. The fairly typical definition of prior art is the previously known subject matter relating to the present invention. Included within the definition of 'prior art' can be a prior publication, a prior patent, an abandonment of an invention, a prior sale or offer for sale, a prior use, prior public and general knowledge or a prior invention. What is not so typically known is that the prior art must predate the patent application to which the art is applicable by at least one year to be allowed as evidence in any legal proceedings. In other words, if a patent application is dated 1/1/2007 then the prior art must be dated before 1/1/2006. Cheers Carl ----- Original Message ----- From: "Winterbottom, James" To: "Andrew Newton" ; "Dawson, Martin" Cc: "GEOPRIV" Sent: Wednesday, March 14, 2007 4:52 AM Subject: RE: [Geopriv] IPR? > Let me be clear. > > The concept of the VESA in NENA was introduced by me. > PIDF-LO had long since been defined. > The basic definition of PIDF-LO included S/MIME security, which > implicitly include location signing. > > Is that sufficient evidence of prior art? > > Cheers > James > > > >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Wednesday, 14 March 2007 9:46 PM >> To: Dawson, Martin >> Cc: GEOPRIV >> Subject: Re: [Geopriv] IPR? >> >> >> On Mar 14, 2007, at 6:40 AM, Dawson, Martin wrote: >> >> > I'm not aware of any IPR encumbrances on location signing. As I >> > said the other day, I am aware of publicly disclosed prior art >> > going back to 2004. >> >> Martin, >> >> It would help if you could point us to that prior art. >> >> -andy >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 14 11:38:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRVYA-000180-4q; Wed, 14 Mar 2007 11:38:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRVY8-00017u-8n for geopriv@ietf.org; Wed, 14 Mar 2007 11:38:00 -0400 Received: from bellwecs4.srvr.bell.ca ([207.236.237.116]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRVXz-00083B-HL for geopriv@ietf.org; Wed, 14 Mar 2007 11:38:00 -0400 Received: (qmail 4417 invoked from network); 14 Mar 2007 15:37:35 -0000 Received: from g.caron@bell.ca by bellwecs4.srvr.bell.ca with EntrustECS-Server-7.4; 14 Mar 2007 15:37:35 -0000 Received: from bellwfep7.bellnexxia.net (HELO bellwfep7-srv.bellnexxia.net) (207.236.237.99) by bellwecs4.srvr.bell.ca with SMTP; 14 Mar 2007 15:37:35 -0000 Received: from TOROONDC908.bell.corp.bce.ca ([142.182.89.88]) by bellwfep7-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20070314153735.UXKI2308.bellwfep7-srv.bellnexxia.net@TOROONDC908.bell.corp.bce.ca>; Wed, 14 Mar 2007 11:37:35 -0400 Received: from toroondc912.bell.corp.bce.ca ([142.182.89.15]) by TOROONDC908.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 11:37:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] Updated meeting agenda Date: Wed, 14 Mar 2007 11:37:31 -0400 Message-ID: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A2585CC@toroondc912> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Updated meeting agenda Thread-Index: AcdmJ+ZtZkXL51DVTBqJeL5InqYBXgAH5BvA References: From: To: , X-OriginalArrivalTime: 14 Mar 2007 15:37:32.0717 (UTC) FILETIME=[AEA96DD0:01C7664E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Andrew, Randall and Allison, At this point, I would like to know if geopriv will consider upgrading = one (or many) L7-LCP as working group items at IETF #68. For some high-speed access providers, this is the only viable option and = frankly, also the preferable approach. Thanks, Guy Caron -----Message d'origine----- De=A0: Andrew Newton [mailto:andy@hxr.us]=20 Envoy=E9=A0: 14 mars 2007 07:00 =C0=A0: GEOPRIV WG Objet=A0: [Geopriv] Updated meeting agenda All, After feedback from the draft agenda and a discussion among the co-=20 chairs, we have updated the GEOPRIV agenda for IETF 68. http://www3.ietf.org/proceedings/07mar/agenda/geopriv.txt The biggest change is in item 6, to address the issue now consuming =20 so many cycles on our mailing list. The intent is to explicitly =20 list, on the projector screen, the issues with location signing in a =20 high bandwidth environment so participants may ask for clarifications =20 of issues. Though we would all prefer to come to resolution on the =20 issue, this is not likely to happen. The hope is that we can clarify =20 issues to bring us closer to resolution. -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 14 13:15:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRX3p-0001lw-Oc; Wed, 14 Mar 2007 13:14:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRX3o-0001lr-JY for geopriv@ietf.org; Wed, 14 Mar 2007 13:14:48 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HRX3k-0003bJ-8N for geopriv@ietf.org; Wed, 14 Mar 2007 13:14:48 -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, 14 Mar 2007 13:11:36 -0400 id 015880D2.45F82CC8.00002104 In-Reply-To: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A2585CC@toroondc912> References: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A2585CC@toroondc912> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable Message-Id: From: Andrew Newton Subject: Re: [Geopriv] Updated meeting agenda Date: Wed, 14 Mar 2007 13:14:31 -0400 To: g.caron@bell.ca X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Guy, I realize this must seem confusing. We will have an L7-LCP proposal =20 advanced at some point. Today we have 3 proposals, and so we need to =20= figure out how to evaluate them and decide which we want to advance. =20= To do that, we initiated the L7-LCP problem statement and =20 requirements draft, a document that states the requirements we all =20 agree to. Once we agree to the requirements, we can move on to =20 picking a protocol proposal. Unfortunately, we seem to be unable to =20 agree on the requirements. There is a possibility that most of those issue could get cleared up =20 at IETF 68 with notable exception of location signing (which is a =20 very large issue). -andy On Mar 14, 2007, at 11:37 AM, g.caron@bell.ca wrote: > Andrew, Randall and Allison, > > At this point, I would like to know if geopriv will consider =20 > upgrading one (or many) L7-LCP as working group items at IETF #68. > > For some high-speed access providers, this is the only viable =20 > option and frankly, also the preferable approach. > > Thanks, > > Guy Caron > -----Message d'origine----- > De : Andrew Newton [mailto:andy@hxr.us] > Envoy=E9 : 14 mars 2007 07:00 > =C0 : GEOPRIV WG > Objet : [Geopriv] Updated meeting agenda > > All, > > After feedback from the draft agenda and a discussion among the co- > chairs, we have updated the GEOPRIV agenda for IETF 68. > > http://www3.ietf.org/proceedings/07mar/agenda/geopriv.txt > > The biggest change is in item 6, to address the issue now consuming > so many cycles on our mailing list. The intent is to explicitly > list, on the projector screen, the issues with location signing in a > high bandwidth environment so participants may ask for clarifications > of issues. Though we would all prefer to come to resolution on the > issue, this is not likely to happen. The hope is that we can clarify > issues to bring us closer to resolution. > > -andy > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 14 13:17: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 1HRX6I-0003rs-4F; Wed, 14 Mar 2007 13:17:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRX6H-0003rn-ET for geopriv@ietf.org; Wed, 14 Mar 2007 13:17:21 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HRX6F-0003js-59 for geopriv@ietf.org; Wed, 14 Mar 2007 13:17: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; Wed, 14 Mar 2007 13:14:20 -0400 id 015880D2.45F82D6C.000022A3 In-Reply-To: <011601c7664c$6cbafd50$6401a8c0@SusieandCarl> References: <011601c7664c$6cbafd50$6401a8c0@SusieandCarl> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Message-Id: From: Andrew Newton Subject: Re: [Geopriv] IPR? Date: Wed, 14 Mar 2007 13:17:15 -0400 To: Carl Reed OGC Account X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: GEOPRIV , "Dawson, Martin" X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0862088796==" Errors-To: geopriv-bounces@ietf.org --===============0862088796== Content-Type: multipart/alternative; boundary=Apple-Mail-23-164424067 --Apple-Mail-23-164424067 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Mar 14, 2007, at 11:18 AM, Carl Reed OGC Account wrote: > I am not a lawyer but I do spend some amount of time dealing with > IPR issues Unfortunately, this is becoming true for many of us. As distasteful as it is to have to deal with the issue, I know from experience what happens to working groups that do not address IPR issues early on. -andy --Apple-Mail-23-164424067 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=US-ASCII
On Mar 14, 2007, at 11:18 AM, Carl Reed OGC Account wrote:

I am not a lawyer but I do spend some amount of time dealing with IPR issues

Unfortunately, this is becoming true for many of us.

As distasteful as it is to have to deal with the issue, I know from experience what happens to working groups that do not address IPR issues early on.

-andy
--Apple-Mail-23-164424067-- --===============0862088796== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0862088796==-- From geopriv-bounces@ietf.org Wed Mar 14 13:45: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 1HRXXR-0003KA-8P; Wed, 14 Mar 2007 13:45:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRXXP-0003GA-G9 for geopriv@ietf.org; Wed, 14 Mar 2007 13:45:23 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRXXN-0007dM-Ps for geopriv@ietf.org; Wed, 14 Mar 2007 13:45:23 -0400 Received: from ([139.76.131.83]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.173094063; Wed, 14 Mar 2007 13:45:00 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 14 Mar 2007 13:45:00 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 14 Mar 2007 13:44:59 -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: [Geopriv] RE: Strawman Proposal Date: Wed, 14 Mar 2007 13:44:59 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA031B29FF@crexc41p> Importance: normal Priority: normal In-Reply-To: <45F7ACC3.4010000@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: Strawman Proposal Thread-Index: AcdmD7w1vtgSDxZ1SwSqlHeP53zm3gAQazsQ References: <45F7ACC3.4010000@gmx.net> From: "Stark, Barbara" To: "Hannes Tschofenig" , "Dawson, Martin" X-OriginalArrivalTime: 14 Mar 2007 17:44:59.0983 (UTC) FILETIME=[7CC99DF0:01C76660] X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: GEOPRIV , Marc Linsner , Henning Schulzrinne X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org > It seems that IMS actually makes that=20 > assumption - using the traditional "roaming partner" model that=20 > assumes the voice service *is* the access service. Just as an aside, please be careful as to whose view of IMS you're referring to. While this may be the view of 3GPP, where GSM is an integral part of IMS, it is not the view of telcos who are actually implementing IMS. The view of telcos is that GSM is just another access technology. In this telco view, connectivity to the IMS core will generally occur over the public Internet, and there is absolutely no correlation between access provider and IMS provider in that case. --------- Also, while requiring SIMS will take care of authentication in a cell phone world, it does nothing about people who launch point-to-point SIP calls. Given the architecture we're creating, it will be very simple for someone with a simple SIP client to create a PIDF-LO, do a LoST sos query, and make a call over the Internet to the result of that query, without ever touching a VSP. The access network will not be in a position to screen such calls, and (from what I've seen) there would probably be a public outcry if people were actually required to have a "real" VSP, before making a SIP call. If the PSAP wants to refuse to accept such calls, then that will be a national/jurisdictional decision. Then again, there are VSPs that offer free calling over the Internet, that don't really care about the identities of their users, and would have difficulty tracking these users if pressed to do so. There can be fly-by-night VSPs (it's not really that hard to create your own VSP for your own use, and set it up in a hotel room somewhere), and there can be VSPs in countries with lax laws. VSPs, as a generalization, are just as trustworthy as end users. Which means that the PSAP who wants to really restrict calls to those that are properly "authenticated", would have to only accept calls from VSPs that they know they can trust. Which is a very limiting proposition, and I don't think that's where we want to go. If PSAPs are permitted to do a LbyR lookup related to the IP address, then the attacker will at least have to be able to pretend to be at that IP address (through something physical at that IP address, or that can intercept all traffic to that IP address, and not simple spoofing). This is definitely a critical capability, though it's not perfect.=20 I don't think that signatures needs to be a part of an LCP (I agree that it's distinct from the protocol), but I think it would be useful to have a standard means defined for signing PIDF-LOs. I also think that the LCP needs to support location assertion for the purpose of getting a PIDF-LO signed, in the event that a jurisdiction or country wants to go that route. Assertion is also useful as a means of providing a presence server with a GPS-calculated location. Barbara ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA622 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 14 13:54: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 1HRXgJ-0000Lk-2f; Wed, 14 Mar 2007 13:54:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRXgH-0000ID-OV for geopriv@ietf.org; Wed, 14 Mar 2007 13:54:33 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRXcj-0008S6-8h for geopriv@ietf.org; Wed, 14 Mar 2007 13:50:56 -0400 Received: from ([139.76.131.83]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.173094789; Wed, 14 Mar 2007 13:50:20 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 14 Mar 2007 13:50:20 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 14 Mar 2007 13:50:20 -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: [Geopriv] Location signing daydream Date: Wed, 14 Mar 2007 13:50:19 -0400 Importance: normal Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA031B2A06@crexc41p> Priority: normal In-Reply-To: <45F7F641.5000103@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Location signing daydream Thread-Index: AcdmO2ddEanWVaepTbSE5Q0MzabcGQAJYZaA References: <45F7F641.5000103@bbn.com> From: "Stark, Barbara" To: "Richard Barnes" , "GEOPRIV" , "Matt Lepinski" X-OriginalArrivalTime: 14 Mar 2007 17:50:20.0420 (UTC) FILETIME=[3BC86C40:01C76661] X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org It's an interesting proposal, but I don't think VSPs can be trusted, necessarily. The big ones can probably be trusted (with regard to this), but I think it's dangerous to require people to use "well-known and trusted" VSPs. And without such a requirement, it will be very easy to create an "untrustworthy" VSP. It's also possible to use no VSP at all, unless there's some intention to prevent that? Barbara=20 -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com]=20 Sent: Wednesday, March 14, 2007 9:19 AM To: 'GEOPRIV'; Matt Lepinski Subject: [Geopriv] Location signing daydream So I got to daydreaming about location signing systems yesterday, and came up with an idea:
+-------+ ID(UA;LIS), ID(UA;VSP)=20 | |---------------------------+ | VSP | | | |<----------------------+ | +-------+ SLO1 | | ^ | | | | | | | ID(LIS)| |SLO2 | | ID(UA;LIS)| | | | | V | V +------+ +-------+ ID(LIS) | | ID(VSP) | | LCP----------->| UA |--------------------->| LIS | | | ID(UA;VSP) | | +------+ +-------+ | | +------+ SLO3| | | +-------->| LR | | | +------+ ID(A;B) =3D identifier of A in the context of B SLO* =3D signed location objects
Generating a signed LO (SLO): 1. UA gets the ID of the LIS via an LCP 2. UA notifies the LIS that its VSP will be contacting it 3. UA tells its VSP the ID of its LIS, and the identifier that identifies it to that LIS 4. VSP requests users location using provided identity 5. LIS returns a signed object of the form SLO1 =3D LIS{ ID(UA;LIS), Location Information} 6. VSP returns a signed object of the form SLO2 =3D VSP{ ID(UA;VSP), SLO1 } 7. UA can optionally construct a third signed object of the form SLO3 =3D UA{ rules, SLO2 } * NB: VSP role could be played by a trusted module on the UA device. Semantics: -- LIS signature asserts ID(UA;LIS) at specified location -- VSP signature asserts ID(UA;VSP) and ID(UA;LIS) identify the same entity -- UA signature binds rules to rest of LO Assumptions: 1. UA authenticated to VSP using ID(UA;VSP) (e.g., using SIP digest auth) 2. UA authenticated to LIS using ID(UA;LIS) (e.g., via physical / MAC layer authentication) 3. For any other UA' under the same LIS 4. LIS and VSP are trusted to work properly 5. Location is determined by the LIS and ID(UA;LIS) Security properties: 1. It's hard for the UA to spoof either identity: -- If it lies to the LIS about ID(UA;VSP), then the one sent by the VSP in its request won't match up -- If it lies to the VSP about ID(UA;LIS), then the one in the VSP's request won't match the UA that notified the LIS. 2. Because, in particular, the LIS ID can't be spoofed, location can't be spoofed. Remaining attacks: 1. This would allow two attackers served by the same VSP and LIS to exchange locations by swapping the ID(*;VSP) values sent to the LIS and the ID(*;LIS) values sent to the VSP. This can be mitigated, e.g., by restricting the coverage area of any particular LIS. _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA622 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 14 15:09: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 1HRYqN-0005MR-3q; Wed, 14 Mar 2007 15:09:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRYqL-0005ML-W5 for geopriv@ietf.org; Wed, 14 Mar 2007 15:09:01 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRYqI-0008L7-NM for geopriv@ietf.org; Wed, 14 Mar 2007 15:09:01 -0400 Received: (qmail invoked by alias); 14 Mar 2007 19:08:56 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp031) with SMTP; 14 Mar 2007 20:08:56 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/M984GxyLMv0gx/AAeVbWvrkshku6Wfof/pXH11X faCCVUM+6glJCl Message-ID: <45F84845.2000101@gmx.net> Date: Wed, 14 Mar 2007 20:08:53 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Stark, Barbara" Subject: Re: [Geopriv] RE: Strawman Proposal References: <45F7ACC3.4010000@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA031B29FF@crexc41p> In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA031B29FF@crexc41p> 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: 22bbb45ef41b733eb2d03ee71ece8243 Cc: GEOPRIV , "Dawson, Martin" , Marc Linsner , Henning Schulzrinne X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Barbara, thanks for your input. Please find a few responses below: Stark, Barbara wrote: >> It seems that IMS actually makes that >> assumption - using the traditional "roaming partner" model that >> assumes the voice service *is* the access service. >> > > Just as an aside, please be careful as to whose view of IMS you're > referring to. While this may be the view of 3GPP, where GSM is an > integral part of IMS, it is not the view of telcos who are actually > implementing IMS. The view of telcos is that GSM is just another access > technology. In this telco view, connectivity to the IMS core will > generally occur over the public Internet, and there is absolutely no > correlation between access provider and IMS provider in that case. > With this view of IMS their emergency service architecture does not work. > --------- > Also, while requiring SIMS will take care of authentication in a cell > phone world, it does nothing about people who launch point-to-point SIP > calls. Given the architecture we're creating, it will be very simple for > someone with a simple SIP client to create a PIDF-LO, do a LoST sos > query, and make a call over the Internet to the result of that query, > without ever touching a VSP. That's true. The problem is only that the 3GPP has not specified a protocol for the end host to retrieve location information. Hence, it would be difficult for the client to create a PIDF-LO (unless it is equipped with a GPS device). > The access network will not be in a > position to screen such calls, and (from what I've seen) there would > probably be a public outcry if people were actually required to have a > "real" VSP, before making a SIP call. > I don't understand this sentence. > If the PSAP wants to refuse to accept such calls, then that will be a > national/jurisdictional decision. > I agree. > Then again, there are VSPs that offer free calling over the Internet, > that don't really care about the identities of their users, and would > have difficulty tracking these users if pressed to do so. That's not true. Even with free calling over the Internet almost all VSP require some form of authentication. The same is true with email providers today. Some require a quite strong assurance that you are indeed the person you claim to be. Obviously it would be possible to create a legal framework around this for emergency services (as we assume it with everything else as well). > There can be > fly-by-night VSPs (it's not really that hard to create your own VSP for > your own use, and set it up in a hotel room somewhere), and there can be > VSPs in countries with lax laws. VSPs, as a generalization, are just as > trustworthy as end users. > That might be true. > Which means that the PSAP who wants to really restrict calls to those > that are properly "authenticated", would have to only accept calls from > VSPs that they know they can trust. Which is a very limiting > proposition, and I don't think that's where we want to go. > You have just described the SPIT problem, btw. Why do you think it would be better to * use signed location information (if you also claim that operators don't want to distribute location information to the end hosts), and * resolving a location-by-reference is only allowed by authorized entities > If PSAPs are permitted to do a LbyR lookup related to the IP address, > then the attacker will at least have to be able to pretend to be at that > IP address (through something physical at that IP address, or that can > intercept all traffic to that IP address, and not simple spoofing). This > is definitely a critical capability, though it's not perfect. > I don't understand what that means? How does a LbyR lookup based on the IP address work? I thought we said that the lookup would work by using the HTTPS or SIPS URI. The IP address that is seen by the PSAP will not be the IP address of the end host in most cases anyway since there are so many tunneling, NAT, VPN, mobility solutions out there that you just block something. > I don't think that signatures needs to be a part of an LCP (I agree that > it's distinct from the protocol), What does that mean? I thought that the idea was to use the LCP to request a signed LO. > but I think it would be useful to have > a standard means defined for signing PIDF-LOs. With SIP Location Conveyance you already have a way todo so, although it is not really useful since you have to resolve the reference via TLS and the signed PIDF-LO would just do the same thing essentially twice -- my HTTPS/S-HTTP description applies. > I also think that the LCP > needs to support location assertion for the purpose of getting a PIDF-LO > signed, This statement does not align nicely with the previous sentence. > in the event that a jurisdiction or country wants to go that > route. Assertion is also useful as a means of providing a presence > server with a GPS-calculated location. > But in this case you would really want to use an S/MIME signed PIDF-LO. Ciao Hannes > Barbara > > > ***** > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 14 15:22:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRZ3a-0002Z2-AN; Wed, 14 Mar 2007 15:22:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRZ3Z-0002XH-H7 for geopriv@ietf.org; Wed, 14 Mar 2007 15:22:41 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRZ3X-0001iT-5D for geopriv@ietf.org; Wed, 14 Mar 2007 15:22:41 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l2EJMZu17714; Wed, 14 Mar 2007 19:22:35 GMT Received: from [47.130.16.51] ([47.130.16.51] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 15:22:35 -0400 Message-ID: <45F84B54.8070206@nortel.com> Date: Wed, 14 Mar 2007 15:21:56 -0400 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Geopriv] NENA Requirements References: <004401c765b2$51bb4540$230d0d0a@amer.cisco.com> In-Reply-To: <004401c765b2$51bb4540$230d0d0a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2007 19:22:35.0432 (UTC) FILETIME=[1EE83A80:01C7666E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: GEOPRIV , "Stark, Barbara" X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org The liaison process to the IETF is simple enough. It passes through the WG Chair(s), preferably with additional notice to the list. See RFC 4053 for a complete description. Marc Linsner wrote: > Barbara, > > Yes, the IETF liaison process is frustrating. But I attribute this partly > to my own laziness/lack of desire to learn it. I did attempt to track the > NENA document, at your earlier suggestion/request, starting at the NENA end > since that seemed less intimidating than the IETF end. Unfortunately, I got > a resounding 'no response' on my query on the NENA end which drove me to > drop it as I see the IETF end as the bigger of the two dragons. I didn't > get results from the little dragon, chances are the bigger one will be even > less helpful. > > In defense of the IETF, NENA certainly knows how to submit/track a draft, > which is the proven mechanism in the case of LoST and the NENA LTD wg. > > -Marc- > > > > > >> -----Original Message----- >> From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] >> Sent: Tuesday, March 13, 2007 4:06 PM >> To: Hannes Tschofenig; Dawson, Martin >> Cc: GEOPRIV >> Subject: RE: [Geopriv] NENA Requirements >> >> Hannes, >> I sympathize with your frustration, but I think that part of >> the requirement sharing problem may lie with IETF processes. >> I know for a fact that the draft NENA TID was liaised to the >> DSL Forum in June 2006, and the final version was liaised in >> December 2006. I know there was discussion around liaising to >> the IETF, and I'm not knowledgeable enough to comprehend why >> the NENA liaison didn't make it to the geopriv WG. >> Clearly, it was NENA's intention to try to share the draft >> and get comments on it. June 2006 would also have given the >> LCP task force time to consider those requirements. >> >> I don't think there's anything to be done about the past, but >> for the future, would it be possible to define a liaison >> process so organizations such as NENA can properly share >> their drafts with IETF WGs? >> Barbara >> >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Tuesday, March 13, 2007 3:44 PM >> >> NENA is slower than the IETF. Interesting :-) In that case it >> could have even been easier to share the requirements a long >> time ago instead of letting an entire group discuss >> requirements for a long time. >> >> >> ***** >> >> 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. GA624 >> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 14 17:59: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 1HRbUZ-0007av-TA; Wed, 14 Mar 2007 17:58:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRbUY-0007aq-K4 for geopriv@ietf.org; Wed, 14 Mar 2007 17:58:42 -0400 Received: from mailipbo.vtcif.telstra.com.au ([202.12.144.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRbUU-00051w-9S for geopriv@ietf.org; Wed, 14 Mar 2007 17:58:42 -0400 Received: from webi.vtcif.telstra.com.au (HELO mailbi.vtcif.telstra.com.au) ([202.12.142.19]) by mailipbo.vtcif.telstra.com.au with ESMTP; 15 Mar 2007 08:58:33 +1100 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id 17A971DA84 for ; Thu, 15 Mar 2007 08:58:33 +1100 (EST) Received: from wsmsg2902.srv.dir.telstra.com (wsmsg2902.srv.dir.telstra.com [172.49.40.51]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id IAA01200 for ; Thu, 15 Mar 2007 08:58:32 +1100 (EST) Received: from WSMSG2153V.srv.dir.telstra.com ([192.74.195.21]) by wsmsg2902.srv.dir.telstra.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 08:58:32 +1100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Mar 2007 08:58:32 +1100 Message-ID: Thread-Topic: Making decisions at Prague.... Thread-Index: Acdmg+jEBqYn4RIoQKWl3xI9HoLRzA== From: "Moore, Lyn E" To: X-OriginalArrivalTime: 14 Mar 2007 21:58:32.0582 (UTC) FILETIME=[E8340260:01C76683] X-Spam-Score: 0.3 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Subject: [Geopriv] Making decisions at Prague.... X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0562012897==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============0562012897== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76683.E7DD1035" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76683.E7DD1035 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All =20 As a long-time "watcher" of GeoPriv, I'd like to make a few observations for you all to think about whilst you are in Prague... =20 1. The IETF is here to specify protocols. Not to conduct faction fighting. No standard protocol for location acquisition has been produced after 1 year of chit-chat and, sometimes, personal abuse between GeoPriv members. This is highly unprofessional behaviour. =20 2. I work for the largest telco in Australia (Employees: 50000, service area: Australia, Hong Kong and New Zealand). Telstra is a full-service provider - PSTN, ISP, VSP, access networks (ADSL, cable, WiFi, 2GSM, 3GSM), content provider, enterprise service provider and more. I require a solution now for IP Location - both emergency calling and general use. I want to deploy one solution not a NENAesque solution for emergency calling and another solution to provide location for the fixed access networks.=20 =20 3. Telco's build networks based on ESTI 3GPP/TISPAN, ADSL Forum, OMA standards etc. To have a useful location acquisition protocol, it needs to work on and with these standards. If not, any solution you come up with will be ignored as impractical. This is not a case of the old "net" vs "bell-head" jibe that reappeared this week, but this is reality. The IP networks out there are run by telcos. =20 4. Telstra, by Act of Parliament, also runs the Australian PSAP. As Australia only has the one PSAP, our requirements for routing emergency calls are simpler than elsewhere. However, the hype surrounding the emergency calling issue coming from North America and Europe is leading the regulators to believe commercial grade solutions are available. This puts pressure on. It is hard to explain that there are many draft protocols, but no standard. We will be required by the regulators to have a solution for emergency calling very soon. =20 5. I want someone to categorically tell me why HELD is "not suitable for the internet" as alleged earlier this week. Is this because it doesn't scale, isn't good technically, doesn't provide all the necessary functionality OR is it because Andrew Corp haven't done their politics correctly or aren't in the right clique ? =20 =20 6. I have asked a number of the usual telco equipment vendors, some of which you represent, and so far the Andrew Corp solution is the only one I can see that is possibly commercially viable. Is this the real issue ? Is this forum delaying standardisation of HELD for commercial reasons ? I hope not. =20 Sorry for being so blunt, but it needed to be said. =20 So please try and come to some form of consensus in Prague. I need commercial solutions, which means you guys need to specify protocols. =20 =20 Regards Lyn Moore =20 Senior Emerging Technology Specialist Telstra - Chief Technology Office 23 /242 Exhibition Street, Melbourne. AUSTRALIA =20 ------_=_NextPart_001_01C76683.E7DD1035 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi=20 All

As a = long-time=20 "watcher" of GeoPriv, I'd like to make a few observations for you = all to=20 think about whilst you are in Prague...

1. The IETF is=20 here to specify protocols. Not to conduct faction fighting. =20 No standard protocol for location acquisition has been produced = after 1=20 year of chit-chat and, sometimes, personal abuse between GeoPriv = members. =20 This is highly unprofessional behaviour.

2. =20 I work for the largest telco in Australia = (Employees:=20 50000, service area: Australia, Hong Kong and New Zealand). = Telstra is a=20 full-service provider - PSTN, ISP, VSP, access networks (ADSL, cable, = WiFi,=20 2GSM, 3GSM), content provider, enterprise service provider and=20 more.   I require a solution now for IP Location - both = emergency=20 calling and general use. I want to deploy one solution not a = NENAesque=20 solution for emergency calling and another solution to provide location = for the=20 fixed access networks.

3. Telco's build networks based on ESTI = 3GPP/TISPAN, ADSL Forum, OMA standards etc.  To have a useful = location=20 acquisition protocol, it needs to work on and with these = standards. =20 If not, any solution you come up with will be ignored as = impractical. This=20 is not a case of the old "net" vs "bell-head" jibe that reappeared this = week,=20 but this is reality. The IP networks out there are run by=20 telcos.

4.  Telstra, by Act of Parliament, = also runs=20 the Australian PSAP.   As Australia only has the one = PSAP, our=20 requirements for routing emergency calls are simpler than = elsewhere. =20 However, the hype surrounding the emergency calling issue coming from = North=20 America and Europe is leading the regulators to believe commercial = grade=20 solutions are available. This puts pressure on. It is hard = to=20 explain that there are many draft protocols, but no standard. We = will be=20 required by the regulators to have a solution for emergency calling very = soon.

5. I want someone to categorically tell = me why=20 HELD is "not suitable for the internet" as alleged earlier this = week. Is=20 this because it doesn't scale, isn't good technically, doesn't provide = all the=20 necessary functionality OR is it because Andrew Corp haven't = done=20 their politics correctly or aren't in the right=20 clique ?

6. I have asked a number of the usual = telco=20 equipment vendors, some of which you represent, and so far the Andrew = Corp=20 solution is the only one I can see that is possibly=20 commercially viable. Is this the real issue ? Is this = forum=20 delaying standardisation of HELD for commercial reasons ? I hope=20 not.

Sorry for being so blunt, but it needed to be = said.

So please try and come to some form of = consensus in=20 Prague. I need commercial solutions, which means you guys need to = specify=20 protocols.

Regards

Lyn=20 Moore

Senior Emerging = Technology=20 Specialist

Telstra - Chief = Technology=20 Office

23 /242 Exhibition = Street,=20 Melbourne.

AUSTRALIA

------_=_NextPart_001_01C76683.E7DD1035-- --===============0562012897== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0562012897==-- From geopriv-bounces@ietf.org Wed Mar 14 18:18: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 1HRbne-0002lq-KM; Wed, 14 Mar 2007 18:18:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRbne-0002lZ-BE for geopriv@ietf.org; Wed, 14 Mar 2007 18:18:26 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRbnc-0008Rk-Jk for geopriv@ietf.org; Wed, 14 Mar 2007 18:18:26 -0400 X-SEF-Processed: 5_0_0_910__2007_03_14_17_24_21 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, 14 Mar 2007 17:24:21 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 17:18:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] Location signing daydream Date: Wed, 14 Mar 2007 17:18:19 -0500 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA031B2A06@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Location signing daydream Thread-Index: AcdmO2ddEanWVaepTbSE5Q0MzabcGQAJYZaAAAhA+LA= From: "Thomson, Martin" To: "Stark, Barbara" , "Richard Barnes" , "GEOPRIV" , "Matt Lepinski" X-OriginalArrivalTime: 14 Mar 2007 22:18:22.0185 (UTC) FILETIME=[AD430590:01C76686] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1557708518==" Errors-To: geopriv-bounces@ietf.org --===============1557708518== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBsaWtlIHRoZSBjb25jZXB0LCBpdCdzIGxpbmthZ2Ugb2YgdGhlIGlkZW50aWZpZXJzIElEKFVB O1ZTUCkgYW5kIElEKFVBO0xJUykgaXMgbm92ZWwuICBOb3RlIHRoYXQgZGVtb25zdHJhdGVzIHVz ZSBvZiBsb2NhdGlvbiBieSByZWZlcmVuY2UgYnkgdGhlIFZTUC4NCg0KSSBkb24ndCB0aGluayB0 aGF0IHRoaXMgaGFzIHNpZ25pZmljYW50IGFkdmFudGFnZXMgb3ZlciB0aGUgbWV0aG9kcyBwcm9w b3NlZCBpbjoNCg0KPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRob21zb24tZ2Vv cHJpdi1sb2NhdGlvbi1kZXBlbmRhYmlsaXR5LTAwPg0KKHdoaWNoIGlzIGluIHR1cm4gYmFzZWQg b24gdGhlIGlkZWEgcHJlc2VudGVkIGluIHRoZSBsNy1sY3AtcHMgZHJhZnQpDQoNCllvdXIgcHJv cG9zYWwgcmVxdWlyZXMgdGhlIFZTUCB0byBwZXJmb3JtIGxpbmthZ2UgYmV0d2VlbiBJRChVQTtW U1ApIGFuZCBJRChVQTtMSVMpLiAgSW4gbWFueSBzZW5zZXMsIFZTUCBpcyBub3QgdGhlIHJpZ2h0 IHRlcm0gZm9yIHRoaXMgLS0gdGhlIFZTUCBpcyBhY3RpbmcgYXMgYW4gSWRlbnRpdHkgUHJvdmlk ZXIgaW4gdGhlIFNBTUwgc2Vuc2UuDQoNClRoZSBvdGhlciBwcm9wb3NhbCBkb2Vzbid0IHJlcXVp cmUgVlNQIGludGVyYWN0aW9uOg0KDQoxLiBVQSBkaXNjb3ZlcnMgTElTIChJIGRvbid0IHRoaW5r IHRoYXQgdGhlIExDUCBpcyB0aGUgcmlnaHQgdGVybSBmb3IgdGhpcyBzdGVwIEJUVykNCjIuIFRo ZSBVQSByZXF1ZXN0cyBhIHNpZ25lZCBMTy4NCglTTE8gPSBTaWcgeyBJRChVQTtMSVMpLCBmeyBJ RChVQTtWU1ApIH0sIExJLCAuLi4gfQ0KMy4gVGhlIFVBIHVzZXMgdGhhdCBzaWduZWQgTE8sIGF1 dGhlbnRpY2F0aW5nIHdpdGggSUQoVUE7VlNQKSB3aGVuIGl0IGlzIHVzZWQuDQoNCllvdXIgcHJv cG9zYWwgcmVxdWlyZXMgdGhhdCB0aGUgVUEgcHJvdmlkZSBpdHMgaWRlbnRpdHkgdG8gdGhlIExJ Uy4gIFNvbWUgbWF5IHBlcmNlaXZlIHRoYXQgYXMgYSBwcm9ibGVtOyBpdCB3YXMgY2l0ZWQgYXMg c3VjaC4gIFdoaWxlIHRoZSBhYm92ZSBjYW4gYmUgYmFzZWQgb24gcHJvdmlkaW5nIHRoZSBpZGVu dGl0eSAoaS5lLiBme30gaXMgdW5pdHkpLCBhIGhhc2ggZnVuY3Rpb24gcHJvdmlkZXMgYWRlcXVh dGUgbGlua2FnZSBiZXR3ZWVuIElEKFVBO1ZTUCkuDQoNCk5vdGUgdGhhdCB0aGUgVUEgd291bGQg aGF2ZSB0byBhdXRoZW50aWNhdGUgdXNpbmcgSUQoVUE7VlNQKSBpbiBlaXRoZXIgcHJvcG9zYWws IHRoYXQgYmVpbmcgdGhlIGlkZW50aXR5IHRoYXQgaXMga25vd24uDQoNCkNoZWVycywNCk1hcnRp bg0KDQpwLnMuIEkgbGlrZSB0aGUgbm90YXRpb24hICBWZXJ5IHVzZWZ1bC4NCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTdGFyaywgQmFyYmFyYSBbbWFpbHRvOkJhcmJh cmEuU3RhcmtAQmVsbFNvdXRoLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIDE1IE1hcmNoIDIwMDcg NDo1MCBBTQ0KPiBUbzogUmljaGFyZCBCYXJuZXM7IEdFT1BSSVY7IE1hdHQgTGVwaW5za2kNCj4g U3ViamVjdDogUkU6IFtHZW9wcml2XSBMb2NhdGlvbiBzaWduaW5nIGRheWRyZWFtDQo+IA0KPiBJ dCdzIGFuIGludGVyZXN0aW5nIHByb3Bvc2FsLCBidXQgSSBkb24ndCB0aGluayBWU1BzIGNhbiBi ZSB0cnVzdGVkLA0KPiBuZWNlc3NhcmlseS4gVGhlIGJpZyBvbmVzIGNhbiBwcm9iYWJseSBiZSB0 cnVzdGVkICh3aXRoIHJlZ2FyZCB0byB0aGlzKSwNCj4gYnV0IEkgdGhpbmsgaXQncyBkYW5nZXJv dXMgdG8gcmVxdWlyZSBwZW9wbGUgdG8gdXNlICJ3ZWxsLWtub3duIGFuZA0KPiB0cnVzdGVkIiBW U1BzLiBBbmQgd2l0aG91dCBzdWNoIGEgcmVxdWlyZW1lbnQsIGl0IHdpbGwgYmUgdmVyeSBlYXN5 IHRvDQo+IGNyZWF0ZSBhbiAidW50cnVzdHdvcnRoeSIgVlNQLiBJdCdzIGFsc28gcG9zc2libGUg dG8gdXNlIG5vIFZTUCBhdCBhbGwsDQo+IHVubGVzcyB0aGVyZSdzIHNvbWUgaW50ZW50aW9uIHRv IHByZXZlbnQgdGhhdD8NCj4gQmFyYmFyYQ0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogUmljaGFyZCBCYXJuZXMgW21haWx0bzpyYmFybmVzQGJibi5jb21dDQo+IFNl bnQ6IFdlZG5lc2RheSwgTWFyY2ggMTQsIDIwMDcgOToxOSBBTQ0KPiBUbzogJ0dFT1BSSVYnOyBN YXR0IExlcGluc2tpDQo+IFN1YmplY3Q6IFtHZW9wcml2XSBMb2NhdGlvbiBzaWduaW5nIGRheWRy ZWFtDQo+IA0KPiBTbyBJIGdvdCB0byBkYXlkcmVhbWluZyBhYm91dCBsb2NhdGlvbiBzaWduaW5n IHN5c3RlbXMgeWVzdGVyZGF5LCBhbmQNCj4gY2FtZSB1cCB3aXRoIGFuIGlkZWE6DQo+IA0KPiA8 ZmlndXJlPg0KPiANCj4gDQo+ICAgICAgICAgICAgICAgICArLS0tLS0tLSsgICAgSUQoVUE7TElT KSwgSUQoVUE7VlNQKQ0KPiANCj4gICAgICAgICAgICAgICAgIHwgICAgICAgfC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsNCj4gICAgICAgICAgICAgICAgIHwgIFZTUCAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCj4gICAgICAgICAgICAgICAgIHwgICAgICAgfDwtLS0tLS0tLS0t LS0tLS0tLS0tLS0tKyAgIHwNCj4gICAgICAgICAgICAgICAgICstLS0tLS0tKyAgICAgICAgU0xP MSAgICAgICAgICAgfCAgIHwNCj4gICAgICAgICAgICAgICAgICBeICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgIHwNCj4gICAgICAgICAgICAgICAgICB8ICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgIHwNCj4gICAgICAgICAgIElEKExJUyl8ICAgIHxTTE8yICAgICAgICAg ICAgICAgICAgICAgfCAgIHwNCj4gICAgICAgIElEKFVBO0xJUyl8ICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgIHwNCj4gICAgICAgICAgICAgICAgICB8ICAgIFYgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgIFYNCj4gICAgICAgICAgICAgICAgICstLS0tLS0rICAgICAgICAgICAg ICAgICAgICAgICstLS0tLS0tKw0KPiAgICAgICAgSUQoTElTKSAgfCAgICAgIHwgICAgICAgIElE KFZTUCkgICAgICAgfCAgICAgICB8DQo+IExDUC0tLS0tLS0tLS0tPnwgIFVBICB8LS0tLS0tLS0t LS0tLS0tLS0tLS0tPnwgIExJUyAgfA0KPiAgICAgICAgICAgICAgICAgfCAgICAgIHwgICAgICBJ RChVQTtWU1ApICAgICAgfCAgICAgICB8DQo+ICAgICAgICAgICAgICAgICArLS0tLS0tKyAgICAg ICAgICAgICAgICAgICAgICArLS0tLS0tLSsNCj4gICAgICAgICAgICAgICAgICAgICB8DQo+ICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICstLS0tLS0rDQo+ICAgICAgICAgICAgICAgICBT TE8zfCAgICAgICAgIHwgICAgICB8DQo+ICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tPnwg IExSICB8DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8DQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0rDQo+IDxsZWdlbmQ+DQo+IElEKEE7Qikg PSBpZGVudGlmaWVyIG9mIEEgaW4gdGhlIGNvbnRleHQgb2YgQg0KPiBTTE8qID0gc2lnbmVkIGxv Y2F0aW9uIG9iamVjdHMNCj4gPC9sZWdlbmQ+DQo+IDwvZmlndXJlPg0KPiANCj4gDQo+IA0KPiBH ZW5lcmF0aW5nIGEgc2lnbmVkIExPIChTTE8pOg0KPiAxLiBVQSBnZXRzIHRoZSBJRCBvZiB0aGUg TElTIHZpYSBhbiBMQ1ANCj4gMi4gVUEgbm90aWZpZXMgdGhlIExJUyB0aGF0IGl0cyBWU1Agd2ls bCBiZSBjb250YWN0aW5nIGl0IDMuIFVBIHRlbGxzDQo+IGl0cyBWU1AgdGhlIElEIG9mIGl0cyBM SVMsIGFuZCB0aGUgaWRlbnRpZmllciB0aGF0IGlkZW50aWZpZXMgaXQgdG8gdGhhdA0KPiBMSVMg NC4gVlNQIHJlcXVlc3RzIHVzZXJzIGxvY2F0aW9uIHVzaW5nIHByb3ZpZGVkIGlkZW50aXR5IDUu IExJUw0KPiByZXR1cm5zIGEgc2lnbmVkIG9iamVjdCBvZiB0aGUgZm9ybQ0KPiAgICAgICAgU0xP MSA9IExJU3sgSUQoVUE7TElTKSwgTG9jYXRpb24gSW5mb3JtYXRpb259IDYuIFZTUCByZXR1cm5z IGENCj4gc2lnbmVkIG9iamVjdCBvZiB0aGUgZm9ybQ0KPiAgICAgICAgU0xPMiA9IFZTUHsgSUQo VUE7VlNQKSwgU0xPMSB9DQo+IDcuIFVBIGNhbiBvcHRpb25hbGx5IGNvbnN0cnVjdCBhIHRoaXJk IHNpZ25lZCBvYmplY3Qgb2YgdGhlIGZvcm0NCj4gICAgICAgIFNMTzMgPSBVQXsgcnVsZXMsIFNM TzIgfQ0KPiAqIE5COiBWU1Agcm9sZSBjb3VsZCBiZSBwbGF5ZWQgYnkgYSB0cnVzdGVkIG1vZHVs ZSBvbiB0aGUgVUEgZGV2aWNlLg0KPiANCj4gU2VtYW50aWNzOg0KPiAtLSBMSVMgc2lnbmF0dXJl IGFzc2VydHMgSUQoVUE7TElTKSBhdCBzcGVjaWZpZWQgbG9jYXRpb24NCj4gLS0gVlNQIHNpZ25h dHVyZSBhc3NlcnRzIElEKFVBO1ZTUCkgYW5kIElEKFVBO0xJUykgaWRlbnRpZnkgdGhlIHNhbWUN Cj4gZW50aXR5DQo+IC0tIFVBIHNpZ25hdHVyZSBiaW5kcyBydWxlcyB0byByZXN0IG9mIExPDQo+ IA0KPiANCj4gQXNzdW1wdGlvbnM6DQo+IDEuIFVBIGF1dGhlbnRpY2F0ZWQgdG8gVlNQIHVzaW5n IElEKFVBO1ZTUCkNCj4gICAgIChlLmcuLCB1c2luZyBTSVAgZGlnZXN0IGF1dGgpDQo+IDIuIFVB IGF1dGhlbnRpY2F0ZWQgdG8gTElTIHVzaW5nIElEKFVBO0xJUykNCj4gICAgIChlLmcuLCB2aWEg cGh5c2ljYWwgLyBNQUMgbGF5ZXIgYXV0aGVudGljYXRpb24pIDMuIEZvciBhbnkgb3RoZXIgVUEn DQo+IHVuZGVyIHRoZSBzYW1lIExJUyA0LiBMSVMgYW5kIFZTUCBhcmUgdHJ1c3RlZCB0byB3b3Jr IHByb3Blcmx5IDUuDQo+IExvY2F0aW9uIGlzIGRldGVybWluZWQgYnkgdGhlIExJUyBhbmQgSUQo VUE7TElTKQ0KPiANCj4gU2VjdXJpdHkgcHJvcGVydGllczoNCj4gMS4gSXQncyBoYXJkIGZvciB0 aGUgVUEgdG8gc3Bvb2YgZWl0aGVyIGlkZW50aXR5Og0KPiAtLSBJZiBpdCBsaWVzIHRvIHRoZSBM SVMgYWJvdXQgSUQoVUE7VlNQKSwgdGhlbiB0aGUgb25lIHNlbnQgYnkgdGhlIFZTUA0KPiBpbiBp dHMgcmVxdWVzdCB3b24ndCBtYXRjaCB1cA0KPiAtLSBJZiBpdCBsaWVzIHRvIHRoZSBWU1AgYWJv dXQgSUQoVUE7TElTKSwgdGhlbiB0aGUgb25lIGluIHRoZSBWU1Ancw0KPiByZXF1ZXN0IHdvbid0 IG1hdGNoIHRoZSBVQSB0aGF0IG5vdGlmaWVkIHRoZSBMSVMuDQo+IDIuIEJlY2F1c2UsIGluIHBh cnRpY3VsYXIsIHRoZSBMSVMgSUQgY2FuJ3QgYmUgc3Bvb2ZlZCwgbG9jYXRpb24gY2FuJ3QNCj4g YmUgc3Bvb2ZlZC4NCj4gDQo+IFJlbWFpbmluZyBhdHRhY2tzOg0KPiAxLiBUaGlzIHdvdWxkIGFs bG93IHR3byBhdHRhY2tlcnMgc2VydmVkIGJ5IHRoZSBzYW1lIFZTUCBhbmQgTElTIHRvDQo+IGV4 Y2hhbmdlIGxvY2F0aW9ucyBieSBzd2FwcGluZyB0aGUgSUQoKjtWU1ApIHZhbHVlcyBzZW50IHRv IHRoZSBMSVMgYW5kDQo+IHRoZSBJRCgqO0xJUykgdmFsdWVzIHNlbnQgdG8gdGhlIFZTUC4gIFRo aXMgY2FuIGJlIG1pdGlnYXRlZCwgZS5nLiwgYnkNCj4gcmVzdHJpY3RpbmcgdGhlIGNvdmVyYWdl IGFyZWEgb2YgYW55IHBhcnRpY3VsYXIgTElTLg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gR2Vv cHJpdiBtYWlsaW5nIGxpc3QNCj4gR2VvcHJpdkBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nZW9wcml2DQo+IA0KPiAqKioqKg0KPiANCj4gVGhlIGlu Zm9ybWF0aW9uIHRyYW5zbWl0dGVkIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3Ig ZW50aXR5IHRvDQo+IHdoaWNoIGl0IGlzIGFkZHJlc3NlZCBhbmQgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsLCBwcm9wcmlldGFyeSwgYW5kL29yDQo+IHByaXZpbGVnZWQgbWF0ZXJpYWwuIEFueSBy ZXZpZXcsIHJldHJhbnNtaXNzaW9uLCBkaXNzZW1pbmF0aW9uIG9yIG90aGVyDQo+IHVzZSBvZiwg b3IgdGFraW5nIG9mIGFueSBhY3Rpb24gaW4gcmVsaWFuY2UgdXBvbiB0aGlzIGluZm9ybWF0aW9u IGJ5DQo+IHBlcnNvbnMgb3IgZW50aXRpZXMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50IGlzIHByb2hpYml0ZWQuIElmDQo+IHlvdSByZWNlaXZlZCB0aGlzIGluIGVycm9yLCBwbGVh c2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhlDQo+IG1hdGVyaWFsIGZyb20gYWxs IGNvbXB1dGVycy4gR0E2MjINCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gR2VvcHJpdiBtYWlsaW5nIGxpc3QNCj4gR2VvcHJp dkBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nZW9w cml2DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNz YWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWlu IHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlv bi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRo b3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ0K --===============1557708518== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1557708518==-- From geopriv-bounces@ietf.org Wed Mar 14 18:34:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRc3Q-0002Be-JI; Wed, 14 Mar 2007 18:34:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRc3Q-0002BZ-2l for geopriv@ietf.org; Wed, 14 Mar 2007 18:34:44 -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 1HRc3L-0002kr-SQ for geopriv@ietf.org; Wed, 14 Mar 2007 18:34:44 -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, 14 Mar 2007 18:31:38 -0400 id 01588179.45F877CA.0000377C In-Reply-To: References: 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: [Geopriv] Making decisions at Prague.... Date: Wed, 14 Mar 2007 18:34:35 -0400 To: "Moore, Lyn E" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org On Mar 14, 2007, at 5:58 PM, Moore, Lyn E wrote: > 6. I have asked a number of the usual telco equipment vendors, > some of which you represent, and so far the Andrew Corp solution is > the only one I can see that is possibly commercially viable. Since bluntness is the theme of the day, just how did you, they, or anybody reach such a conclusion? What were the qualifications and requirements for reaching that conclusion? And did you/they evaluate RELO, and how did it stack up? (I'll assume we're sticking to the L7 solution space and also disregard the proposal named LCP since I'm personally on record as considering it unimplementable as specified). And since HELD has gone through many iterations itself, how did you evaluate it as a moving target? > Is this the real issue ? Is this forum delaying standardisation > of HELD for commercial reasons ? I hope not. I sincerely hope not as well. My job would certainly be easier if this could be settled tomorrow. But I'll give you my perspective. HELD was first introduced as a protocol specification, and it did a lot of things. Let me stress that -- a lot of things! What was never introduced in clear terms to the working group were any requirements or goals or needs. We were basically asked to ratify a rather lengthy protocol specification that we did not understand. To top it off, there were subtle but important distinctions in terminology that made communication difficult (e.g. LIS vs. LS). Given that part of our task is the privacy of location information (i.e. the PRIV of GEOPRIV), understanding of the features is required. Since the introduction of HELD, we've had to dissect the various areas of function. So far we have L-by-R, LCP, OBO, and location signing. I hope we are at the end of that list, because each is a complicated subject. -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 14 19:48: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 1HRdCZ-0006fj-NT; Wed, 14 Mar 2007 19:48:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRdCX-0006fY-Uj for geopriv@ietf.org; Wed, 14 Mar 2007 19:48:13 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRdCX-0005L3-H9 for geopriv@ietf.org; Wed, 14 Mar 2007 19:48:13 -0400 X-SEF-Processed: 5_0_0_910__2007_03_14_18_54_03 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, 14 Mar 2007 18:54:03 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 18:48: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: [Geopriv] Making decisions at Prague.... Date: Wed, 14 Mar 2007 18:48:02 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Making decisions at Prague.... Thread-Index: AcdmiTA8rwbEHU3IT2qcIHm5ehWqQQAAy94w From: "Dawson, Martin" To: "Andrew Newton" , "Moore, Lyn E" X-OriginalArrivalTime: 14 Mar 2007 23:48:04.0229 (UTC) FILETIME=[3535C350:01C76693] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi everyone,=0D=0A=0D=0AI think the tension here is to be expected. The WG = wants to thoroughly=0D=0Adebate the issues that are associated with a proto= col like HELD - which=0D=0Acame to the table pretty much fully formed and w= ithout having been on=0D=0Athe radar previously. The industry players who w= ere involved in the=0D=0Aformulation of the requirements for some time prev= iously are now feeling=0D=0Athe pinch because a couple of years later there= still isn't a=0D=0Areferencable specification and both the market and the = regulatory=0D=0Aenvironment have continued to move forward. I'm still waiti= ng on the FCC=0D=0Ato "drop the other shoe" with respect to their mooted fu= ture rulings in=0D=0Atheir last docket. It's already happened in Canada.=0D= =0A=0D=0ATo be fair to HELD, the number of changes in the last two years ha= sn't=0D=0Abeen that great. The most significant one came early when its cou= pling=0D=0Awith HTTP was considered undersirable. The next draft decoupled = it from=0D=0Athe session/transport and separate drafts for BEEP versus HTTP= bindings=0D=0Awere provided.=0D=0A=0D=0AUnfortunately, I think there are a= number of additional features to be=0D=0Adiscussed. Here is the list of th= ings that HELD supports - and all of=0D=0Awhich have been raised to one deg= ree or another in the past months. It's=0D=0Aextensive but I think HELD is = no more or less than it needs to be -=0D=0Aacknowledging that other WG memb= ers haven't satisfied themselves of=0D=0Athis.=0D=0A=0D=0AObviously I'd rea= lly like it if HELD could be taken to WG item status=0D=0Aand the fine-tuni= ng of the features could still continue. That would=0D=0Agive the industry = a referencable draft without being the ultimate=0D=0Acommitment to the pack= age.=0D=0A=0D=0A=0D=0A=0D=0A1. Works over IP (also gets referred to as L= 7)=0D=0A=0D=0A2. Represents location using PIDF-LO=0D=0A=0D=0A3. Supp= orts Geodetic and/or Civic address location=0D=0A=0D=0A4. Permits acquis= ition of a jurisdictional-specific civic form for=0D=0Aemergency services a= ppropriate to access jurisdiction=0D=0A=0D=0A5. Client can specify prefe= rence for geo, postal civic, and/or=0D=0Ajurisdictional civic in request=0D= =0A=0D=0A6. Supports the acquisition of device identity independent loca= tion=0D=0Areferences=0D=0A a. Location reference request can specify li= fe-time of location=0D=0Areference=0D=0A b. Client can request extensio= n or termination of location=0D=0Areference life-time=0D=0A c. LIS is= able to apply client authentication/authorization on the=0D=0Adereference = interface=0D=0A d. The acquisition protocol is be able to be used as th= e=0D=0Adereference protocol=0D=0A=0D=0A7. Permits client to provide geop= riv privacy rules/preferences with=0D=0Athe expectation of them being appli= ed during dereferencing=0D=0A=0D=0A8. Location requests can include "res= ponse time" QoS against which=0D=0Aaccuracy may be traded off=0D=0A=0D=0A9.= PIDF-LO signature can be requested for acquired location=0D=0A a. S= ignature can be used to determine whether location information=0D=0Ahas bee= n changed since signature was generated=20=0D=0A b. Signature can be us= ed to verify the time-period of validity of=0D=0Athe location information =0D= =0A c. Signature can be used to discriminate between a PIDF-LO provided=0D= =0Afor one LIS client versus another=20=0D=0A d. Signature can be used = to determine an organizational/operator=0D=0Aidentity associated with the s= pecific LIS=20=0D=0A=0D=0A10. Location request can include a nominal locati= on which can be tested=0D=0Aby the LIS against the LIS-determined location = - This is location=0D=0Aassertion.=0D=0A a. The LIS communicates the re= sult of this assertion test to the=0D=0Aclient=20=0D=0A b. If requested= , the LIS is able to sign the client-provided=0D=0Alocation in the event of= a successful assertion test=20=0D=0A=0D=0A11. The protocol does not preclu= de an appropriately=0D=0Aauthenticated/authorized client from acquiring loc= ation or location=0D=0Areference on behalf of a target device. - OBO=0D=0A=0D= =0A12. The protocol supports the use of extensible parameters defining=0D=0A= target device identity to be included in a location request - used for=0D=0A= OBO and LIS-LIS communication.=0D=0A=0D=0A13.A LIS may use HELD to act as a= location acquisition client to another=0D=0ALIS=0D=0A a. A LIS acting = as a LIS client shall be able to use identity=0D=0Aextensions to facilitate= target device identification=20=0D=0A=0D=0A14. The protocol supports a mec= hanism by which the client and LIS can=0D=0Aestablish common location measu= rement and determination capabilities,=0D=0Aincluding additional location p= rotocol capabilities, and utilize those=0D=0Acapabilities in the determinat= ion of location. Allows a the device and=0D=0ALIS to negotiate common proto= col support - e.g. SUPL for assisted-GPS,=0D=0ARFID beacon scanning for ent= erprise/muni, LLDP for switch port ID...=0D=0A=0D=0A---------=0D=0A=0D=0ASo= - that's quite a list.=0D=0A=0D=0AThe only other feature that I can think = of as having been discussed is=0D=0Athe "location reporting" function. This= is mooted in RELO. The device=0D=0Acan ask for a location reference and th= e reference actually points to a=0D=0ASIP subscribable service that will pe= riodically push location=0D=0Ainformation to the dereferencer. I think this= makes sense as a service=0D=0Afor a LIS to provide (it hasn't come out of = the emergency services=0D=0Arequirement soup but it's certainly got precede= nts in OMA MLP and 3GPP=0D=0Alocation service models).=0D=0A=0D=0AWe'd cert= ainly be happy to add HELD support for requesting a reference=0D=0Ato such = a reporting service.=0D=0A=0D=0AI know this doesn't actually make the list = any shorter but I think we're=0D=0Aseeing that a network-embedded location = service may actually need to be=0D=0Aquite feature rich.=0D=0A=0D=0ACheers,=0D= =0AMartin=0D=0A=20=0D=0A=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: A= ndrew Newton [mailto:andy@hxr.us]=20=0D=0ASent: Thursday, 15 March 2007 9:3= 5 AM=0D=0ATo: Moore, Lyn E=0D=0ACc: geopriv@ietf.org=0D=0ASubject: Re: [Geo= priv] Making decisions at Prague....=0D=0A=0D=0A=0D=0AOn Mar 14, 2007, at 5= :58 PM, Moore, Lyn E wrote:=0D=0A> 6. I have asked a number of the usual t= elco equipment vendors, =20=0D=0A> some of which you represent, and so far = the Andrew Corp solution is =20=0D=0A> the only one I can see that is possi= bly commercially viable.=0D=0A=0D=0ASince bluntness is the theme of the day= , just how did you, they, or =20=0D=0Aanybody reach such a conclusion=3F W= hat were the qualifications and =20=0D=0Arequirements for reaching that con= clusion=3F And did you/they evaluate =20=0D=0ARELO, and how did it stack u= p=3F (I'll assume we're sticking to the L7 =20=0D=0Asolution space and also= disregard the proposal named LCP since I'm =20=0D=0Apersonally on record a= s considering it unimplementable as =20=0D=0Aspecified). And since HELD ha= s gone through many iterations itself, =20=0D=0Ahow did you evaluate it as = a moving target=3F=0D=0A=0D=0A> Is this the real issue =3F Is this forum= delaying standardisation =20=0D=0A> of HELD for commercial reasons =3F I = hope not.=0D=0A=0D=0AI sincerely hope not as well. My job would certainly = be easier if =20=0D=0Athis could be settled tomorrow.=0D=0A=0D=0ABut I'll g= ive you my perspective. HELD was first introduced as a =20=0D=0Aprotocol s= pecification, and it did a lot of things. Let me stress =20=0D=0Athat -- a= lot of things! What was never introduced in clear terms to =20=0D=0Athe wo= rking group were any requirements or goals or needs. We were =20=0D=0Abasi= cally asked to ratify a rather lengthy protocol specification =20=0D=0Athat= we did not understand. To top it off, there were subtle but =20=0D=0Aimpo= rtant distinctions in terminology that made communication =20=0D=0Adifficul= t (e.g. LIS vs. LS). Given that part of our task is the =20=0D=0Aprivacy o= f location information (i.e. the PRIV of GEOPRIV), =20=0D=0Aunderstanding o= f the features is required.=0D=0A=0D=0ASince the introduction of HELD, we'v= e had to dissect the various =20=0D=0Aareas of function. So far we have L-= by-R, LCP, OBO, and location =20=0D=0Asigning. I hope we are at the end of= that list, because each is a =20=0D=0Acomplicated subject.=0D=0A=0D=0A-and= y=0D=0A=0D=0A_______________________________________________=0D=0AGeopriv m= ailing list=0D=0AGeopriv@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/listin= fo/geopriv=0D=0A=0D=0A-----------------------------------------------------= -------------------------------------------=0D=0AThis message is for the de= signated recipient only and may=0D=0Acontain privileged, proprietary, or ot= herwise private information. =20=0D=0AIf you have received it in error, ple= ase notify the sender=0D=0Aimmediately and delete the original. Any unauth= orized use of=0D=0Athis email is prohibited.=0D=0A-------------------------= -----------------------------------------------------------------------=0D=0A= [mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 14 19:59: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 1HRdNs-0003JA-36; Wed, 14 Mar 2007 19:59:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRdNr-0003J5-GQ for geopriv@ietf.org; Wed, 14 Mar 2007 19:59:55 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRdNq-0007NH-5G for geopriv@ietf.org; Wed, 14 Mar 2007 19:59:55 -0400 X-SEF-Processed: 5_0_0_910__2007_03_14_19_05_52 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, 14 Mar 2007 19:05:52 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 18:59: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: [Geopriv] Making decisions at Prague.... Date: Wed, 14 Mar 2007 18:59:49 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Making decisions at Prague.... Thread-Index: AcdmiTA8rwbEHU3IT2qcIHm5ehWqQQAAy94wAAIZ5DA= From: "Winterbottom, James" To: "Dawson, Martin" , "Andrew Newton" , "Moore, Lyn E" X-OriginalArrivalTime: 14 Mar 2007 23:59:52.0786 (UTC) FILETIME=[DB8AFB20:01C76694] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org =0D=0A>=20=0D=0A> The only other feature that I can think of as having been= discussed is=0D=0A> the "location reporting" function. This is mooted in R= ELO. The device=0D=0A> can ask for a location reference and the reference a= ctually points to=0D=0Aa=0D=0A> SIP subscribable service that will periodic= ally push location=0D=0A> information to the dereferencer. I think this mak= es sense as a service=0D=0A> for a LIS to provide (it hasn't come out of th= e emergency services=0D=0A> requirement soup but it's certainly got precede= nts in OMA MLP and 3GPP=0D=0A> location service models).=0D=0A>=20=0D=0A> W= e'd certainly be happy to add HELD support for requesting a reference=0D=0A= > to such a reporting service.=0D=0A=0D=0A[AJW] Actually HELD does not prec= lude returning a SIP URI for just this=0D=0Apurpose.=0D=0AWhen you request = a context using HELD you get a list of URIs supported=0D=0Aby the LIS that = all point to the same context.=0D=0A=0D=0A[AJW] This is already supported f= or free.=0D=0A=0D=0A>=20=0D=0A> I know this doesn't actually make the list = any shorter but I think=0D=0Awe're=0D=0A> seeing that a network-embedded lo= cation service may actually need to=0D=0Abe=0D=0A> quite feature rich.=0D=0A= >=20=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> ----= -Original Message-----=0D=0A> From: Andrew Newton [mailto:andy@hxr.us]=0D=0A= > Sent: Thursday, 15 March 2007 9:35 AM=0D=0A> To: Moore, Lyn E=0D=0A> Cc: = geopriv@ietf.org=0D=0A> Subject: Re: [Geopriv] Making decisions at Prague..= =2E.=0D=0A>=20=0D=0A>=20=0D=0A> On Mar 14, 2007, at 5:58 PM, Moore, Lyn E w= rote:=0D=0A> > 6. I have asked a number of the usual telco equipment vendo= rs,=0D=0A> > some of which you represent, and so far the Andrew Corp soluti= on is=0D=0A> > the only one I can see that is possibly commercially viable.=0D= =0A>=20=0D=0A> Since bluntness is the theme of the day, just how did you, t= hey, or=0D=0A> anybody reach such a conclusion=3F What were the qualificat= ions and=0D=0A> requirements for reaching that conclusion=3F And did you/t= hey evaluate=0D=0A> RELO, and how did it stack up=3F (I'll assume we're sti= cking to the L7=0D=0A> solution space and also disregard the proposal named= LCP since I'm=0D=0A> personally on record as considering it unimplementabl= e as=0D=0A> specified). And since HELD has gone through many iterations it= self,=0D=0A> how did you evaluate it as a moving target=3F=0D=0A>=20=0D=0A>= > Is this the real issue =3F Is this forum delaying standardisation=0D=0A= > > of HELD for commercial reasons =3F I hope not.=0D=0A>=20=0D=0A> I sinc= erely hope not as well. My job would certainly be easier if=0D=0A> this co= uld be settled tomorrow.=0D=0A>=20=0D=0A> But I'll give you my perspective.= HELD was first introduced as a=0D=0A> protocol specification, and it did = a lot of things. Let me stress=0D=0A> that -- a lot of things! What was ne= ver introduced in clear terms to=0D=0A> the working group were any requirem= ents or goals or needs. We were=0D=0A> basically asked to ratify a rather = lengthy protocol specification=0D=0A> that we did not understand. To top i= t off, there were subtle but=0D=0A> important distinctions in terminology t= hat made communication=0D=0A> difficult (e.g. LIS vs. LS). Given that part= of our task is the=0D=0A> privacy of location information (i.e. the PRIV o= f GEOPRIV),=0D=0A> understanding of the features is required.=0D=0A>=20=0D=0A= > Since the introduction of HELD, we've had to dissect the various=0D=0A> a= reas of function. So far we have L-by-R, LCP, OBO, and location=0D=0A> sig= ning. I hope we are at the end of that list, because each is a=0D=0A> comp= licated subject.=0D=0A>=20=0D=0A> -andy=0D=0A>=20=0D=0A> __________________= _____________________________=0D=0A> Geopriv mailing list=0D=0A> Geopriv@ie= tf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A>=20=0D=0A= >=0D=0A--------------------------------------------------------------------= ----=0D=0A--=0D=0A> ----------------------=0D=0A> This message is for the d= esignated recipient only and may=0D=0A> contain privileged, proprietary, or= otherwise private information.=0D=0A> If you have received it in error, pl= ease notify the sender=0D=0A> immediately and delete the original. Any una= uthorized use of=0D=0A> this email is prohibited.=0D=0A>=0D=0A-------------= -----------------------------------------------------------=0D=0A--=0D=0A> = ----------------------=0D=0A> [mf2]=0D=0A>=20=0D=0A>=20=0D=0A> ____________= ___________________________________=0D=0A> Geopriv mailing list=0D=0A> Geop= riv@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 01:05:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRi9F-0005Ij-Tm; Thu, 15 Mar 2007 01:05:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRi9F-0005Ie-8x for geopriv@ietf.org; Thu, 15 Mar 2007 01:05:09 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRi9D-00064D-My for geopriv@ietf.org; Thu, 15 Mar 2007 01:05:09 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l2F555Nw028759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 14 Mar 2007 22:05:06 -0700 Received: from [71.204.158.100] (vpn-10-50-0-194.qualcomm.com [10.50.0.194]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2F554x6026930; Wed, 14 Mar 2007 22:05:05 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 14 Mar 2007 22:05:03 -0700 To: "Moore, Lyn E" , From: Ted Hardie Subject: Re: [Geopriv] Making decisions at Prague.... Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org > >1. The IETF is here to specify protocols. Not to conduct faction fighting. No standard protocol for location acquisition has been produced after 1 year of chit-chat and, sometimes, personal abuse between GeoPriv members. This is highly unprofessional behaviour. I don't think anyone would disagree that the situation has brought out more vitriol than is healthy, and I hope that those of us in Prague can find ways to move past that. You should realize, though, whatever your length of observation, that both sides in this feel pushed. The GeoPRIV working group was chartered a fair amount of time ago with a strong focus on the privacy aspects of location; the acronym doesn't appear in the working group's name by accident. It has produced a number of RFCs which specify the management and distribution of location objects and the presence-based architecture is actually very strongly coupled to SIP's idea of presence (and therefore to the IETF's idea of a VoIP infrastructure). Not just in relation to L7, but in relation to Radius, DHCP, and other protocols, the IETF has struggled with how to handle the tension between the provision of location objects (and their privacy characteristics) and the provision of the location information necessary to build those objects. Despite the fact that location information has many of the same privacy concerns, the working group has agreed in the past to allow the privacy concerns to take second fiddle where the deployment argued for a location provisioning mechanism that could not easily carry the full location object. But it did so with a serious amount of concern that the location information was protected to the extent possible, and with trepidation that this was sending the wrong message to the community about how best to protect the privacy of the user's location. Jon Peterson said some prescient (and dire) things to me on this topic when the DHCP draft was approved by the IESG; I happen to think that we would have had other problems without that draft, but he was clearly right that the message it sent has in some ways overwhelmed the original focus of GeoPRIV. HELD appears to have a very different view of the privacy characteristics of location, and it seems to come from a point of view that does not see the user control inherent in the presence infrastructure as critical to the overall system. Read again this introduction to held-identify-extensions: A basic premise in HELD is that the source IP address of the location request message can be used by the LIS to identify the requesting Target, and that this identity can be used with other contextual network information to provide a physical location for the Target. In many network deployments this premise holds true, but in some network deployments additional identifiers are required to identify the Target at different points throughout the network, or they may assist with speeding up location determination. The base HELD schema was designed with extensibility in mind and the assumption that IP address may not always be enought to identify a Target. The HELD identity extensions schema is made up of a number of discrete element blocks that can included into the HELD locationRequest, createContext and updateContext messages. These elements can then be used by the LIS to identify the Target closer to the edge of the network, for example a MAC address or DHCP client- identifier, or to identify an element that has a closer relationship with the target, for example LLDP switch and port information. The identity extension elements have been desgined to work across a range of existing and emerging technologies. It is envisaged that while this schema is not exhaustive, it will address many of the perceived deployment solution. It is further envisaged that extensions to this schema will be necessary as new identifiers are created or required. The kind of identity binding these discuss are very serious ties of user identity to location, and are exactly the kind of thing that GeoPRIV started out to protect. As you read any of the HELD documents, you get a strong sense that the aim is to use the location information model rather than the location object model throughout (though there are syntactic similarities with the location object model). That's a very basic difference of assumption--about the role of the network, the user, and the location. The use of emergency services as a driving use case for this has caused many conversations along the lines of "but we throw out the usual rules to get the best information we can to a PSAP". But it is very different to start from the assumption that the user is in control of the distribution of their location and relax specific rules when you need to get the job done versus starting from the assumption that the network is in control of the distribution of the user's location and whatever user identity it has. Many of the point arguments we have had in the past week, it seems to me, go back to that difference of assumptions. We argue about simless phones and specific regulatory mandates, when the real tension is far deeper. That is why your statement below, which implies putting forward a single system for emergency calling and general use, concerns me. I think if you started from the basic geopriv assumptions and moved from there, what you would end up there would be reasonably good (and you could do that today using signed location objects, presence, and SIP). If you start from where James and Martin seem to start from, I believe you will end up with a location information system that has little to no user control; that has to concern me. You ask if the Andrew folks haven't got their politics right. First, we do try to treat folks as individuals rather than by corporate affiliation here, but I assume you mean Martin and James. If you mean, are they not buying the right folks beer or horse-trading favors, then no, that's not the problem. The problem is their work appears to ignore the chartered goal of the working group. They argue (at times very convincingly) that the goals of the working group are incompatible with specific deployments, specific aims like emergency calling, or the fiscal realities of presuming that large networks will deploy expensive equipment to get this when that equipment's usual use is covered elsewhere. I am sure they are deeply frustrated by what can easily look like a willingness to ignore those realities. I can assure you that folks don't want to ignore them (though they may want demonstrations they are true). They want to understand if there are ways to meet the goals of the group *GeoPRIV* in those contexts. If not starting from the chartered goals of the working group isn't getting their politics right, then yes, that is a problem. That's just my opinion on the tension, obviously, and Martin, James and I already plan to sit down in Prague. Possibly they will there convince me that I have the wrong end of the stick. I hope, though, that the end goals remain the same: that we are working toward a system that continues to recognize that "while the formatting and transfer of such information (location) is in some sense a straightforward process, the implications of doing it, especially in regards to privacy and security, are anything but." and that continues to value the user's privacy and control--even if it must under some circumstances put other goals like emergency service higher. Just my two cents, regards, Ted Hardie _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 05:42:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRmTm-000543-MZ; Thu, 15 Mar 2007 05:42:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRmTm-00053l-3e for geopriv@ietf.org; Thu, 15 Mar 2007 05:42:38 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRmSK-00086H-7G for geopriv@ietf.org; Thu, 15 Mar 2007 05:41:10 -0400 Received: (qmail invoked by alias); 15 Mar 2007 09:41:07 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp031) with SMTP; 15 Mar 2007 10:41:07 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+6/uJMbj66ptup/aPVK5YH5YYdB9XJ+kAejECeHf E9HdNa15KHHCuG Message-ID: <45F914AE.2060405@gmx.net> Date: Thu, 15 Mar 2007 10:41:02 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) 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: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Geopriv] NENA X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi all, I would like to better understand the work done by NENA. Which SDOs are going to make use (or is already used) of the work done by NENA? Consider the following SDOs, as an example - 3GPP - 3GPP2 - Wimax - Wifi Alliance - DSL Forum - ETSI TISPAN - CableLabs Since there is often a mismatch between the standards being developed in these SDOs I would like to also understand how the NENA work going to be used on the Internet? Ciao Hannes _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 06:22:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRn6V-0000UE-Kd; Thu, 15 Mar 2007 06:22:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRn6V-0000U4-66 for geopriv@ietf.org; Thu, 15 Mar 2007 06:22:39 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRn6S-0002uS-MM for geopriv@ietf.org; Thu, 15 Mar 2007 06:22:39 -0400 Received: (qmail invoked by alias); 15 Mar 2007 10:22:35 -0000 X-Provags-ID: V01U2FsdGVkX1+8LIRBhj28bGSJkKHy9mkTARWD2vHBShTnI/NER2 l2AVafDYV1xblw Message-ID: <45F91E67.1030703@gmx.net> Date: Thu, 15 Mar 2007 11:22:31 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Moore, Lyn E" Subject: Re: [Geopriv] Making decisions at Prague.... References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Lyn, I agree with you that we need to make progress and I don't want to blame anyone for causing delays. Since you showed up on the mailing list, let me ask you a question based on my recent proposal. As you said there is only a single PSAP in Australia. My proposal would be ideal for such a country, namely: As an operator you would make location information at the country level granularity available to the end host. Then, you would also provide the end host with a location-by-reference. This reference points to the precise location of the end host and only needs to be resolved by the PSAP. Does this make sense to you? Ciao Hannes Moore, Lyn E wrote: > Hi All > > As a long-time "watcher" of GeoPriv, I'd like to make a few observations > for you all to think about whilst you are in Prague... > > 1. The IETF is here to specify protocols. Not to conduct faction > fighting. No standard protocol for location acquisition has been > produced after 1 year of chit-chat and, sometimes, personal abuse > between GeoPriv members. This is highly unprofessional behaviour. > > 2. I work for the largest telco in Australia (Employees: 50000, service > area: Australia, Hong Kong and New Zealand). Telstra is a full-service > provider - PSTN, ISP, VSP, access networks (ADSL, cable, WiFi, 2GSM, > 3GSM), content provider, enterprise service provider and more. I > require a solution now for IP Location - both emergency calling and > general use. I want to deploy one solution not a NENAesque solution for > emergency calling and another solution to provide location for the fixed > access networks. > > 3. Telco's build networks based on ESTI 3GPP/TISPAN, ADSL Forum, OMA > standards etc. To have a useful location acquisition protocol, it needs > to work on and with these standards. If not, any solution you come up > with will be ignored as impractical. This is not a case of the old > "net" vs "bell-head" jibe that reappeared this week, but this is > reality. The IP networks out there are run by telcos. > > 4. Telstra, by Act of Parliament, also runs the Australian PSAP. As > Australia only has the one PSAP, our requirements for routing emergency > calls are simpler than elsewhere. However, the hype surrounding the > emergency calling issue coming from North America and Europe is leading > the regulators to believe commercial grade solutions are available. > This puts pressure on. It is hard to explain that there are many draft > protocols, but no standard. We will be required by the regulators to > have a solution for emergency calling very soon. > > 5. I want someone to categorically tell me why HELD is "not suitable > for the internet" as alleged earlier this week. Is this because it > doesn't scale, isn't good technically, doesn't provide all the necessary > functionality OR is it because Andrew Corp haven't done their politics > correctly or aren't in the right clique ? > > 6. I have asked a number of the usual telco equipment vendors, some of > which you represent, and so far the Andrew Corp solution is the only one > I can see that is possibly commercially viable. Is this the real issue > ? Is this forum delaying standardisation of HELD for commercial reasons > ? I hope not. > > Sorry for being so blunt, but it needed to be said. > > So please try and come to some form of consensus in Prague. I need > commercial solutions, which means you guys need to specify protocols. > > > Regards > Lyn Moore > > Senior Emerging Technology Specialist > Telstra - Chief Technology Office > 23 /242 Exhibition Street, Melbourne. > AUSTRALIA > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 06:28: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 1HRnBs-000268-Lc; Thu, 15 Mar 2007 06:28:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRnBq-00025z-Mc; Thu, 15 Mar 2007 06:28:10 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRnBp-0003hs-9W; Thu, 15 Mar 2007 06:28:10 -0400 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-8.tower-120.messagelabs.com!1173954484!12364495!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 6363 invoked from network); 15 Mar 2007 10:28:05 -0000 Received: from unknown (HELO attrh9i.attrh.att.com) (134.24.146.4) by server-8.tower-120.messagelabs.com with SMTP; 15 Mar 2007 10:28:05 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh9i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2FAIs7G019862; Thu, 15 Mar 2007 06:18:54 -0400 (EDT) Received: from OCCLUST04EVS1.ugd.att.com (ocst08.ugd.att.com [135.38.164.13]) by attrh9i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2FAIqfp019856; Thu, 15 Mar 2007 06:18:52 -0400 (EDT) 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 Date: Thu, 15 Mar 2007 05:28:02 -0500 Message-ID: <28F05913385EAC43AF019413F674A017101B7790@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <45F914AE.2060405@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] NENA Thread-Index: Acdm5nZDo9e+vSXwTWyDOrrBG+jCegABhvEw References: <45F914AE.2060405@gmx.net> From: "DOLLY, MARTIN C, ATTLABS" To: "Hannes Tschofenig" , "GEOPRIV" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Geopriv] RE: [Ecrit] NENA X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org ATIS=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Thursday, March 15, 2007 5:41 AM To: GEOPRIV; ECRIT Subject: [Ecrit] NENA Hi all, I would like to better understand the work done by NENA. Which SDOs are going to make use (or is already used) of the work done=20 by NENA? Consider the following SDOs, as an example - 3GPP - 3GPP2 - Wimax - Wifi Alliance - DSL Forum - ETSI TISPAN - CableLabs Since there is often a mismatch between the standards being developed in these SDOs I would like to also understand how the NENA work going to be used on the Internet? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 06:36:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRnJs-0000YV-Vv; Thu, 15 Mar 2007 06:36:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRnIj-000858-GE; Thu, 15 Mar 2007 06:35:17 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRnEX-00045U-0V; Thu, 15 Mar 2007 06:30:58 -0400 Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l2FAUsSh023507; Thu, 15 Mar 2007 11:30:54 +0100 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id l2FAUqZ9028726; Thu, 15 Mar 2007 11:30:54 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 11:30:53 +0100 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: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 11:30:50 +0100 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E701903BB6@MCHP7R6A.ww002.siemens.net> In-Reply-To: <28F05913385EAC43AF019413F674A017101B7790@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: [Ecrit] NENA Thread-Index: Acdm5nZDo9e+vSXwTWyDOrrBG+jCegABhvEwAAAR9hA= From: "Tschofenig, Hannes" To: "DOLLY, MARTIN C, ATTLABS" , "Hannes Tschofenig" , "GEOPRIV" , "ECRIT" X-OriginalArrivalTime: 15 Mar 2007 10:30:53.0068 (UTC) FILETIME=[02078CC0:01C766ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Martin,=20 what do you mean by "ATIS"? You mean that ATIS is using the NENA architecture or I should have = included ATIS in the list of SDOs?=20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]=20 > Gesendet: Donnerstag, 15. M=E4rz 2007 11:28 > An: Hannes Tschofenig; GEOPRIV; ECRIT > Betreff: [Geopriv] RE: [Ecrit] NENA >=20 > ATIS=20 >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Thursday, March 15, 2007 5:41 AM > To: GEOPRIV; ECRIT > Subject: [Ecrit] NENA >=20 > Hi all, >=20 > I would like to better understand the work done by NENA. >=20 > Which SDOs are going to make use (or is already used) of the=20 > work done=20 > by NENA? >=20 > Consider the following SDOs, as an example > - 3GPP > - 3GPP2 > - Wimax > - Wifi Alliance > - DSL Forum > - ETSI TISPAN > - CableLabs >=20 > Since there is often a mismatch between the standards being=20 > developed in >=20 > these SDOs I would like to also understand how the NENA work=20 > going to be >=20 > used on the Internet? >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 07:47: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 1HRoQ2-0003Xb-9r; Thu, 15 Mar 2007 07:46:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRoQ1-0003XL-8H; Thu, 15 Mar 2007 07:46: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 1HRoPx-0004Xv-Rw; Thu, 15 Mar 2007 07:46:53 -0400 X-SEF-Processed: 5_0_0_910__2007_03_15_06_52_39 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, 15 Mar 2007 06:52:39 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 06:46:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 06:46:37 -0500 Message-ID: In-Reply-To: <8F6CBC7005099442AECDB784C9E9D7E701903BB6@MCHP7R6A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: [Ecrit] NENA Thread-Index: Acdm5nZDo9e+vSXwTWyDOrrBG+jCegABhvEwAAAR9hAAAhESUA== From: "Dawson, Martin" To: "Tschofenig, Hannes" , "DOLLY, MARTIN C, ATTLABS" , "Hannes Tschofenig" , "GEOPRIV" , "ECRIT" X-OriginalArrivalTime: 15 Mar 2007 11:46:39.0465 (UTC) FILETIME=[97E4AD90:01C766F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I think Martin (the other Martin, not me) meant that ATIS works with NENA s= pecifications. NENA is not an accredited SDO - in the same sense, for examp= le, that ATIS is accredited and able to publish American National Standards= =2E Of course, that doesn't prevent NENA from publishing referencable docum= ents. The E2 interface specification used for wireless E-9-1-1 is a NENA do= cument and, as ever, the i2 architecture specification is a NENA document.=0D= =0A=0D=0AI don't think there's anything prescriptive about how the work of = NENA interacts with other SDOs. I think it's best understood in terms of th= e general role of NENA - which is to provide a national consensus view on h= ow the elements of the emergency service fit together. This ends up coverin= g everything from devices through access and core networks, and into the em= ergency network elements - the routers, call centers, and ALI and ANI datab= ases.=0D=0A=0D=0AThis is particularly important in an environment such as t= he US which is extremely devolved with multiple independent parties operati= ng at every level and every function. Without a body like NENA it would all= deteriorate into chaos - despite how it seems to some, that's not what it = is now. :)=0D=0A=0D=0AIt's good to look at a case study.=0D=0A=0D=0ANENA ha= d a lot of influence on, for example, the TIA J-STD-036 specification for p= hase 2 wireless which subsequently formed the deployment model for how the = FCC mandate for wireless E-9-1-1 should be satisfied. This consequently had= an impact on 3GPP/2. There are even parameters in the 3GPP MAP specificati= on called NA-ESRK and NA-ESRD (the NA part stands for North American) - tho= ugh they do actually have generic utility.=0D=0A=0D=0AA typical chain of in= fluence would go along the lines that US carriers need to meet some regulat= ory requirement for which definitions originating or influenced by NENA for= m the model for deployment. The carriers need their vendors to support the = functionality associated with the model. Both the vendors and the carriers = participate in the SDOs governing the specifications for the network elemen= ts involved and subsequently influence what those specifications look like.= To a large extent, artefacts turn up in SDO specifications as an extended = phenotype of the significance and influence of the US market and the role o= f NENA in that market.=0D=0A=0D=0ADoes that make sense=3F I'm not aware tha= t there are any strict definitions for the relationship between NENA and ot= her SDOs.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message--= ---=0D=0AFrom: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] =0D= =0ASent: Thursday, 15 March 2007 9:31 PM=0D=0ATo: DOLLY, MARTIN C, ATTLABS;= Hannes Tschofenig; GEOPRIV; ECRIT=0D=0ASubject: AW: [Geopriv] RE: [Ecrit] = NENA=0D=0A=0D=0AHi Martin,=20=0D=0A=0D=0Awhat do you mean by "ATIS"=3F=0D=0A=0D= =0AYou mean that ATIS is using the NENA architecture or I should have inclu= ded ATIS in the list of SDOs=3F=20=0D=0A=0D=0ACiao=0D=0AHannes=0D=0A=0D=0A>= -----Urspr=FCngliche Nachricht-----=0D=0A> Von: DOLLY, MARTIN C, ATTLABS [= mailto:mdolly@att.com]=20=0D=0A> Gesendet: Donnerstag, 15. M=E4rz 2007 11:2= 8=0D=0A> An: Hannes Tschofenig; GEOPRIV; ECRIT=0D=0A> Betreff: [Geopriv] RE= : [Ecrit] NENA=0D=0A>=20=0D=0A> ATIS=20=0D=0A>=20=0D=0A> -----Original Mess= age-----=0D=0A> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] =0D= =0A> Sent: Thursday, March 15, 2007 5:41 AM=0D=0A> To: GEOPRIV; ECRIT=0D=0A= > Subject: [Ecrit] NENA=0D=0A>=20=0D=0A> Hi all,=0D=0A>=20=0D=0A> I would l= ike to better understand the work done by NENA.=0D=0A>=20=0D=0A> Which SDOs= are going to make use (or is already used) of the=20=0D=0A> work done=20=0D= =0A> by NENA=3F=0D=0A>=20=0D=0A> Consider the following SDOs, as an example=0D= =0A> - 3GPP=0D=0A> - 3GPP2=0D=0A> - Wimax=0D=0A> - Wifi Alliance=0D=0A> - D= SL Forum=0D=0A> - ETSI TISPAN=0D=0A> - CableLabs=0D=0A>=20=0D=0A> Since the= re is often a mismatch between the standards being=20=0D=0A> developed in=0D= =0A>=20=0D=0A> these SDOs I would like to also understand how the NENA work= =20=0D=0A> going to be=0D=0A>=20=0D=0A> used on the Internet=3F=0D=0A>=20=0D= =0A> Ciao=0D=0A> Hannes=0D=0A>=20=0D=0A>=20=0D=0A> ________________________= _______________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A= > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A> ___________= ____________________________________=0D=0A> Geopriv mailing list=0D=0A> Geo= priv@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A> =0D= =0A=0D=0A_______________________________________________=0D=0AGeopriv maili= ng list=0D=0AGeopriv@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/listinfo/g= eopriv=0D=0A=0D=0A---------------------------------------------------------= ---------------------------------------=0D=0AThis message is for the design= ated recipient only and may=0D=0Acontain privileged, proprietary, or otherw= ise private information. =20=0D=0AIf you have received it in error, please = notify the sender=0D=0Aimmediately and delete the original. Any unauthoriz= ed use of=0D=0Athis email is prohibited.=0D=0A-----------------------------= -------------------------------------------------------------------=0D=0A[m= f2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 07:53: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 1HRoVz-0000V2-Jl; Thu, 15 Mar 2007 07:53:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRoVy-0000SW-SQ; Thu, 15 Mar 2007 07:53:02 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRoVw-0005ru-JB; Thu, 15 Mar 2007 07:53:02 -0400 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-3.tower-121.messagelabs.com!1173959579!21901340!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 1941 invoked from network); 15 Mar 2007 11:52:59 -0000 Received: from unknown (HELO attrh9i.attrh.att.com) (134.24.146.4) by server-3.tower-121.messagelabs.com with SMTP; 15 Mar 2007 11:52:59 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh9i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2FBhneu013237; Thu, 15 Mar 2007 07:43:49 -0400 (EDT) Received: from OCCLUST04EVS1.ugd.att.com (ocst08.ugd.att.com [135.38.164.13]) by attrh9i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2FBhivJ013217; Thu, 15 Mar 2007 07:43:44 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 06:52:54 -0500 Message-ID: <28F05913385EAC43AF019413F674A017101B7791@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <8F6CBC7005099442AECDB784C9E9D7E701903BB6@MCHP7R6A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: [Ecrit] NENA Thread-Index: Acdm5nZDo9e+vSXwTWyDOrrBG+jCegABhvEwAAAR9hAAAuYscA== References: <28F05913385EAC43AF019413F674A017101B7790@OCCLUST04EVS1.ugd.att.com> <8F6CBC7005099442AECDB784C9E9D7E701903BB6@MCHP7R6A.ww002.siemens.net> From: "DOLLY, MARTIN C, ATTLABS" To: "Tschofenig, Hannes" , "Hannes Tschofenig" , "GEOPRIV" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Yes=20 -----Original Message----- From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 Sent: Thursday, March 15, 2007 6:31 AM To: DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig; GEOPRIV; ECRIT Subject: AW: [Geopriv] RE: [Ecrit] NENA Hi Martin,=20 what do you mean by "ATIS"? You mean that ATIS is using the NENA architecture or I should have = included ATIS in the list of SDOs?=20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]=20 > Gesendet: Donnerstag, 15. M=E4rz 2007 11:28 > An: Hannes Tschofenig; GEOPRIV; ECRIT > Betreff: [Geopriv] RE: [Ecrit] NENA >=20 > ATIS=20 >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Thursday, March 15, 2007 5:41 AM > To: GEOPRIV; ECRIT > Subject: [Ecrit] NENA >=20 > Hi all, >=20 > I would like to better understand the work done by NENA. >=20 > Which SDOs are going to make use (or is already used) of the=20 > work done=20 > by NENA? >=20 > Consider the following SDOs, as an example > - 3GPP > - 3GPP2 > - Wimax > - Wifi Alliance > - DSL Forum > - ETSI TISPAN > - CableLabs >=20 > Since there is often a mismatch between the standards being=20 > developed in >=20 > these SDOs I would like to also understand how the NENA work=20 > going to be >=20 > used on the Internet? >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 07:57: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 1HRoaW-0001kV-Vs; Thu, 15 Mar 2007 07:57:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRoaW-0001kK-79; Thu, 15 Mar 2007 07:57:44 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRoaU-0006W6-IQ; Thu, 15 Mar 2007 07:57:44 -0400 Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id l2FBvcQ3012618; Thu, 15 Mar 2007 12:57:38 +0100 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 l2FBvcAD010836; Thu, 15 Mar 2007 12:57:38 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 12:57:38 +0100 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: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 12:57:36 +0100 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E701903C2C@MCHP7R6A.ww002.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: [Ecrit] NENA Thread-Index: Acdm5nZDo9e+vSXwTWyDOrrBG+jCegABhvEwAAAR9hAAAhESUAAArn0Q From: "Tschofenig, Hannes" To: "Dawson, Martin" , "DOLLY, MARTIN C, ATTLABS" , "Hannes Tschofenig" , "GEOPRIV" , "ECRIT" X-OriginalArrivalTime: 15 Mar 2007 11:57:38.0068 (UTC) FILETIME=[20738540:01C766F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Martin,=20 Thanks for the quick response.=20 I am trying to figure out what the impact to the Internet is if many = SDOs develop their own specifications for emergency services without = considering the NENA work and I am particularly referring to the SDOs = that potentially impact real networks.=20 More comments below:=20 > -----Urspr=FCngliche Nachricht----- > Von: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 > Gesendet: Donnerstag, 15. M=E4rz 2007 12:47 > An: Tschofenig, Hannes; DOLLY, MARTIN C, ATTLABS; Hannes=20 > Tschofenig; GEOPRIV; ECRIT > Betreff: RE: [Geopriv] RE: [Ecrit] NENA >=20 > I think Martin (the other Martin, not me) meant that ATIS=20 > works with NENA specifications. NENA is not an accredited SDO=20 > - in the same sense, for example, that ATIS is accredited and=20 > able to publish American National Standards. Of course, that=20 > doesn't prevent NENA from publishing referencable documents.=20 > The E2 interface specification used for wireless E-9-1-1 is a=20 > NENA document and, as ever, the i2 architecture specification=20 > is a NENA document. >=20 > I don't think there's anything prescriptive about how the=20 > work of NENA interacts with other SDOs. I think it's best=20 > understood in terms of the general role of NENA - which is to=20 > provide a national consensus view on how the elements of the=20 > emergency service fit together. This ends up covering=20 > everything from devices through access and core networks, and=20 > into the emergency network elements - the routers, call=20 > centers, and ALI and ANI databases. >=20 > This is particularly important in an environment such as the=20 > US which is extremely devolved with multiple independent=20 > parties operating at every level and every function. Without=20 > a body like NENA it would all deteriorate into chaos -=20 > despite how it seems to some, that's not what it is now. :) >=20 > It's good to look at a case study. >=20 > NENA had a lot of influence on, for example, the TIA=20 > J-STD-036 specification for phase 2 wireless which=20 > subsequently formed the deployment model for how the FCC=20 > mandate for wireless E-9-1-1 should be satisfied. This=20 > consequently had an impact on 3GPP/2. >From the last SDO workshop I got the impression that the 3GPP2 actually = had nothing expect for a few high-level requirements. Since a lot of the = 3GPP2 work is taken from 3GPP it might well be possible that they also = recycle the emergency services work.=20 Maybe they have developed a solution already. Maybe you can point to the = relevant documents.=20 There are even=20 > parameters in the 3GPP MAP specification called NA-ESRK and=20 > NA-ESRD (the NA part stands for North American) - though they=20 > do actually have generic utility. But the NENA work is more than just these parameters.=20 >=20 > A typical chain of influence would go along the lines that US=20 > carriers need to meet some regulatory requirement for which=20 > definitions originating or influenced by NENA form the model=20 > for deployment. The carriers need their vendors to support=20 > the functionality associated with the model. Both the vendors=20 > and the carriers participate in the SDOs governing the=20 > specifications for the network elements involved and=20 > subsequently influence what those specifications look like.=20 > To a large extent, artefacts turn up in SDO specifications as=20 > an extended phenotype of the significance and influence of=20 > the US market and the role of NENA in that market. But it is not really good if the NENA work does not appear in the = standardization work of other SDOs.=20 >=20 > Does that make sense? I'm not aware that there are any strict=20 > definitions for the relationship between NENA and other SDOs. It makes sense but to me it looks like the recipe for a non-working = global emergency service solution since there are too many players = involved that want to develop their own story.=20 Ciao Hannes > Cheers, > Martin >=20 > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 > Sent: Thursday, 15 March 2007 9:31 PM > To: DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig; GEOPRIV; ECRIT > Subject: AW: [Geopriv] RE: [Ecrit] NENA >=20 > Hi Martin,=20 >=20 > what do you mean by "ATIS"? >=20 > You mean that ATIS is using the NENA architecture or I should=20 > have included ATIS in the list of SDOs?=20 >=20 > Ciao > Hannes >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]=20 > > Gesendet: Donnerstag, 15. M=E4rz 2007 11:28 > > An: Hannes Tschofenig; GEOPRIV; ECRIT > > Betreff: [Geopriv] RE: [Ecrit] NENA > >=20 > > ATIS=20 > >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > > Sent: Thursday, March 15, 2007 5:41 AM > > To: GEOPRIV; ECRIT > > Subject: [Ecrit] NENA > >=20 > > Hi all, > >=20 > > I would like to better understand the work done by NENA. > >=20 > > Which SDOs are going to make use (or is already used) of the=20 > > work done=20 > > by NENA? > >=20 > > Consider the following SDOs, as an example > > - 3GPP > > - 3GPP2 > > - Wimax > > - Wifi Alliance > > - DSL Forum > > - ETSI TISPAN > > - CableLabs > >=20 > > Since there is often a mismatch between the standards being=20 > > developed in > >=20 > > these SDOs I would like to also understand how the NENA work=20 > > going to be > >=20 > > used on the Internet? > >=20 > > Ciao > > Hannes > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 08:13: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 1HRoq5-0004lu-8o; Thu, 15 Mar 2007 08:13:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRoq3-0004lj-Lx; Thu, 15 Mar 2007 08:13:47 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRopx-0001vL-VS; Thu, 15 Mar 2007 08:13:47 -0400 Received: from ([139.76.131.79]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.173138017; Thu, 15 Mar 2007 08:13:13 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 15 Mar 2007 08:13:13 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 15 Mar 2007 08:13: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 08:13:11 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA031B2B60@crexc41p> In-Reply-To: <8F6CBC7005099442AECDB784C9E9D7E701903C2C@MCHP7R6A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Importance: normal Priority: normal Thread-Topic: [Geopriv] RE: [Ecrit] NENA Thread-Index: Acdm5nZDo9e+vSXwTWyDOrrBG+jCegABhvEwAAAR9hAAAhESUAAArn0QAADinsA= References: <8F6CBC7005099442AECDB784C9E9D7E701903C2C@MCHP7R6A.ww002.siemens.net> From: "Stark, Barbara" To: "Tschofenig, Hannes" , "Dawson, Martin" , "Dolly, Martin C $Attlabs$" , "Hannes Tschofenig" , "GEOPRIV" , "ECRIT" X-OriginalArrivalTime: 15 Mar 2007 12:13:13.0211 (UTC) FILETIME=[4DD704B0:01C766FB] X-Spam-Score: 0.1 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org DSL Forum is also using the NENA documents to determine requirements for = network elements and CPE. Barbara=20 -----Original Message----- From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 Sent: Thursday, March 15, 2007 7:58 AM To: Dawson, Martin; Dolly, Martin C (Attlabs); Hannes Tschofenig; = GEOPRIV; ECRIT Subject: AW: [Geopriv] RE: [Ecrit] NENA Hi Martin,=20 Thanks for the quick response.=20 I am trying to figure out what the impact to the Internet is if many = SDOs develop their own specifications for emergency services without = considering the NENA work and I am particularly referring to the SDOs = that potentially impact real networks.=20 More comments below:=20 > -----Urspr=FCngliche Nachricht----- > Von: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Gesendet: Donnerstag, 15. M=E4rz 2007 12:47 > An: Tschofenig, Hannes; DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig;=20 > GEOPRIV; ECRIT > Betreff: RE: [Geopriv] RE: [Ecrit] NENA >=20 > I think Martin (the other Martin, not me) meant that ATIS works with=20 > NENA specifications. NENA is not an accredited SDO > - in the same sense, for example, that ATIS is accredited and able to=20 > publish American National Standards. Of course, that doesn't prevent=20 > NENA from publishing referencable documents. > The E2 interface specification used for wireless E-9-1-1 is a NENA=20 > document and, as ever, the i2 architecture specification is a NENA=20 > document. >=20 > I don't think there's anything prescriptive about how the work of NENA = > interacts with other SDOs. I think it's best understood in terms of=20 > the general role of NENA - which is to provide a national consensus=20 > view on how the elements of the emergency service fit together. This=20 > ends up covering everything from devices through access and core=20 > networks, and into the emergency network elements - the routers, call=20 > centers, and ALI and ANI databases. >=20 > This is particularly important in an environment such as the US which=20 > is extremely devolved with multiple independent parties operating at=20 > every level and every function. Without a body like NENA it would all=20 > deteriorate into chaos - despite how it seems to some, that's not what = > it is now. :) >=20 > It's good to look at a case study. >=20 > NENA had a lot of influence on, for example, the TIA > J-STD-036 specification for phase 2 wireless which subsequently formed = > the deployment model for how the FCC mandate for wireless E-9-1-1=20 > should be satisfied. This consequently had an impact on 3GPP/2. >From the last SDO workshop I got the impression that the 3GPP2 actually = had nothing expect for a few high-level requirements. Since a lot of the = 3GPP2 work is taken from 3GPP it might well be possible that they also = recycle the emergency services work.=20 Maybe they have developed a solution already. Maybe you can point to the = relevant documents.=20 There are even=20 > parameters in the 3GPP MAP specification called NA-ESRK and NA-ESRD=20 > (the NA part stands for North American) - though they do actually have = > generic utility. But the NENA work is more than just these parameters.=20 >=20 > A typical chain of influence would go along the lines that US carriers = > need to meet some regulatory requirement for which definitions=20 > originating or influenced by NENA form the model for deployment. The=20 > carriers need their vendors to support the functionality associated=20 > with the model. Both the vendors and the carriers participate in the=20 > SDOs governing the specifications for the network elements involved=20 > and subsequently influence what those specifications look like. > To a large extent, artefacts turn up in SDO specifications as an=20 > extended phenotype of the significance and influence of the US market=20 > and the role of NENA in that market. But it is not really good if the NENA work does not appear in the = standardization work of other SDOs.=20 >=20 > Does that make sense? I'm not aware that there are any strict=20 > definitions for the relationship between NENA and other SDOs. It makes sense but to me it looks like the recipe for a non-working = global emergency service solution since there are too many players = involved that want to develop their own story.=20 Ciao Hannes > Cheers, > Martin >=20 > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Thursday, 15 March 2007 9:31 PM > To: DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig; GEOPRIV; ECRIT > Subject: AW: [Geopriv] RE: [Ecrit] NENA >=20 > Hi Martin, >=20 > what do you mean by "ATIS"? >=20 > You mean that ATIS is using the NENA architecture or I should have=20 > included ATIS in the list of SDOs? >=20 > Ciao > Hannes >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] > > Gesendet: Donnerstag, 15. M=E4rz 2007 11:28 > > An: Hannes Tschofenig; GEOPRIV; ECRIT > > Betreff: [Geopriv] RE: [Ecrit] NENA > >=20 > > ATIS > >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Thursday, March 15, 2007 5:41 AM > > To: GEOPRIV; ECRIT > > Subject: [Ecrit] NENA > >=20 > > Hi all, > >=20 > > I would like to better understand the work done by NENA. > >=20 > > Which SDOs are going to make use (or is already used) of the work=20 > > done by NENA? > >=20 > > Consider the following SDOs, as an example > > - 3GPP > > - 3GPP2 > > - Wimax > > - Wifi Alliance > > - DSL Forum > > - ETSI TISPAN > > - CableLabs > >=20 > > Since there is often a mismatch between the standards being=20 > > developed in > >=20 > > these SDOs I would like to also understand how the NENA work going=20 > > to be > >=20 > > used on the Internet? > >=20 > > Ciao > > Hannes > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may contain=20 > 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=20 > prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA621 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 09:43: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 1HRqEx-00030p-Ss; Thu, 15 Mar 2007 09:43:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqEw-00030T-29; Thu, 15 Mar 2007 09:43:34 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRqEs-0001nH-EI; Thu, 15 Mar 2007 09:43:34 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 15 Mar 2007 09:43:31 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2FDhURt008768; Thu, 15 Mar 2007 09:43:30 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2FDhOlG002393; Thu, 15 Mar 2007 13:43:24 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 09:43:11 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 09:43:11 -0400 From: "Marc Linsner" To: "'Dawson, Martin'" Subject: RE: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 09:43:10 -0400 Message-ID: <007001c76707$df4ac600$230d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acdm5nZDo9e+vSXwTWyDOrrBG+jCegABhvEwAAAR9hAAAhESUAACSAmg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 15 Mar 2007 13:43:11.0231 (UTC) FILETIME=[DF4F80F0:01C76707] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8090; t=1173966210; x=1174830210; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20RE=3A=20[Ecrit]=20NENA |Sender:=20 |To:=20=22'Dawson,=20Martin'=22=20; bh=2otwv8B+3mnT7vO6L7kIaiiy2myPFaGFpLU/dpg+EqY=; b=j0BefUX9Jwn0Elju1mdpz7rrgeNDfk9b95P7RDFsdBIlaKpas3d6nYqWNnqQwJh3NAWGft3y ECdyRHeza1iJh9MzSch6cfQ2AGD9ocNtK4XQJBO+m5yvSHZ8MFi58JHn; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: 'GEOPRIV' , 'ECRIT' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Martin D., As I have expressed in many NENA venues and will reiterate here, NENA = goes way past their boundary of expertise. I've pleaded many times, for many years (starting at the 2000 TDC), at many a microphone in NENA venues to please provide the requirements they need to perform their function. = IMO, no other organization can do that as well as NENA for North America. If/when NENA does such, the IP/VoIP/Internet industry/SDO community would/will provide the best solution possible to meet those = requirements. My statement didn't change over time: 'Please draw a line in the sand, = on one side is the world and the other side is NENA constituents, state the requirements when crossing the line.' Instead, many people have promoted to NENA members that they can not = only take NENA requirements to the SDO community, but that NENA can somehow dictate the solution. NENA's current review of location acquisition mechanisms is an example = of NENA crossing the line. Those documents which have now filtered to ATIS then liaised to a wide variety of SDOs 'on behalf of NENA' are fraught = with technical errors and misguided assumptions. But, when the responses to = the liaise attempt to point out those issues, it's passed off as a derelict response. Further discussion of the ATIS process wrt this isn't = warranted in this venue. But my point is that it seems to be common thread with = what we're experiencing in the IETF. But, there is good in the world! In my obviously biased opinion, I believe an example of what has worked = is the relationship between NENA and ECRIT. I believe that LoST/related = drafts have met almost all, if not all of the goals/requirements of the NENA = LTD wg. I did get a little testy when I (possibly mistakenly) sensed a late change in requirements, but I sense that has resolved itself. I've also witnessed a willingness by the LoST team to make adjustments to the = solution as we/NENA gain implementation experience. If that isn't an example of = how things should work, then all hope has vanished. So, I ask that you compare the difference between the NENA-ECRIT relationship and the NENA-GeoPriv relationship, what is your opinion of = what worked/didn't work/isn't working/and why? Yes, NENA does count! Threats of regulation do not count! -Marc- > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 > Sent: Thursday, March 15, 2007 7:47 AM > To: Tschofenig, Hannes; DOLLY, MARTIN C, ATTLABS; Hannes=20 > Tschofenig; GEOPRIV; ECRIT > Subject: RE: [Geopriv] RE: [Ecrit] NENA >=20 > I think Martin (the other Martin, not me) meant that ATIS=20 > works with NENA specifications. NENA is not an accredited SDO=20 > - in the same sense, for example, that ATIS is accredited and=20 > able to publish American National Standards. Of course, that=20 > doesn't prevent NENA from publishing referencable documents.=20 > The E2 interface specification used for wireless E-9-1-1 is a=20 > NENA document and, as ever, the i2 architecture specification=20 > is a NENA document. >=20 > I don't think there's anything prescriptive about how the=20 > work of NENA interacts with other SDOs. I think it's best=20 > understood in terms of the general role of NENA - which is to=20 > provide a national consensus view on how the elements of the=20 > emergency service fit together. This ends up covering=20 > everything from devices through access and core networks, and=20 > into the emergency network elements - the routers, call=20 > centers, and ALI and ANI databases. >=20 > This is particularly important in an environment such as the=20 > US which is extremely devolved with multiple independent=20 > parties operating at every level and every function. Without=20 > a body like NENA it would all deteriorate into chaos -=20 > despite how it seems to some, that's not what it is now. :) >=20 > It's good to look at a case study. >=20 > NENA had a lot of influence on, for example, the TIA=20 > J-STD-036 specification for phase 2 wireless which=20 > subsequently formed the deployment model for how the FCC=20 > mandate for wireless E-9-1-1 should be satisfied. This=20 > consequently had an impact on 3GPP/2. There are even=20 > parameters in the 3GPP MAP specification called NA-ESRK and=20 > NA-ESRD (the NA part stands for North American) - though they=20 > do actually have generic utility. >=20 > A typical chain of influence would go along the lines that US=20 > carriers need to meet some regulatory requirement for which=20 > definitions originating or influenced by NENA form the model=20 > for deployment. The carriers need their vendors to support=20 > the functionality associated with the model. Both the vendors=20 > and the carriers participate in the SDOs governing the=20 > specifications for the network elements involved and=20 > subsequently influence what those specifications look like.=20 > To a large extent, artefacts turn up in SDO specifications as=20 > an extended phenotype of the significance and influence of=20 > the US market and the role of NENA in that market. >=20 > Does that make sense? I'm not aware that there are any strict=20 > definitions for the relationship between NENA and other SDOs. >=20 > Cheers, > Martin >=20 > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Thursday, 15 March 2007 9:31 PM > To: DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig; GEOPRIV; ECRIT > Subject: AW: [Geopriv] RE: [Ecrit] NENA >=20 > Hi Martin,=20 >=20 > what do you mean by "ATIS"? >=20 > You mean that ATIS is using the NENA architecture or I should=20 > have included ATIS in the list of SDOs?=20 >=20 > Ciao > Hannes >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] > > Gesendet: Donnerstag, 15. M=E4rz 2007 11:28 > > An: Hannes Tschofenig; GEOPRIV; ECRIT > > Betreff: [Geopriv] RE: [Ecrit] NENA > >=20 > > ATIS > >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Thursday, March 15, 2007 5:41 AM > > To: GEOPRIV; ECRIT > > Subject: [Ecrit] NENA > >=20 > > Hi all, > >=20 > > I would like to better understand the work done by NENA. > >=20 > > Which SDOs are going to make use (or is already used) of=20 > the work done=20 > > by NENA? > >=20 > > Consider the following SDOs, as an example > > - 3GPP > > - 3GPP2 > > - Wimax > > - Wifi Alliance > > - DSL Forum > > - ETSI TISPAN > > - CableLabs > >=20 > > Since there is often a mismatch between the standards being=20 > developed=20 > > in > >=20 > > these SDOs I would like to also understand how the NENA=20 > work going to=20 > > be > >=20 > > used on the Internet? > >=20 > > Ciao > > Hannes > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may=20 > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender=20 > immediately and delete the original. Any unauthorized use of=20 > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 10:20:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqoG-0001M6-0P; Thu, 15 Mar 2007 10:20:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqoE-0001Lx-3X; Thu, 15 Mar 2007 10:20:02 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRqoD-0006q0-Fo; Thu, 15 Mar 2007 10:20:02 -0400 X-SEF-Processed: 5_0_0_910__2007_03_15_09_26_01 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); Thu, 15 Mar 2007 09:26:00 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 09:20:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 09:19:59 -0500 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA031B2B60@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: [Ecrit] NENA Thread-Index: Acdm5nZDo9e+vSXwTWyDOrrBG+jCegABhvEwAAAR9hAAAhESUAAArn0QAADinsAAAo4DgA== From: "Dawson, Martin" To: "Stark, Barbara" , "Tschofenig, Hannes" , "Dolly, Martin C $Attlabs$" , "Hannes Tschofenig" , "GEOPRIV" , "ECRIT" X-OriginalArrivalTime: 15 Mar 2007 14:20:00.0883 (UTC) FILETIME=[045DA430:01C7670D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org This ends up being a bit of an essay - but it was the only way I felt I cou= ld respond to the question. The executive summary just says "I think the si= gnificance of these forums to the Internet depends on the nature of the for= um." I know there's a mutual dependence between the Internet and these foru= ms - in a very real way, neither would survive without the other.=0D=0A=0D=0A= 1) A number of the forums are specialists in access technology. They care t= o the extent that convention and regulation impact the functionality they n= eed to provide.=0D=0A=0D=0AThe IEEE, for example, reported at the SDO works= hop in Columbia that they were considering dropping work on explicit locati= on support because the "L7" approach was gaining focus - and because the NE= NA requirements were based on that model. They are now thinking that it's b= etter to provide the mechanisms to deliver network measurement parameters b= y which a LIS could determine location - and subsequently package, deliver,= and protect according to a general model, rather than provide a WiMAX spec= ific mechanism to get location information to an end device. For them, it's= kind of a relief that they don't have to push up into the application issu= es associated with location.=0D=0A=0D=0A2) I'm not sure what the implicatio= ns are for the "Internet". My suspicion is that there aren't particularly s= trong implications for it. Access technologies will continue to diversify a= nd evolve as they have done for the last few decades. WiMAX, WiFi, Ethernet= =2E.. none of them are technically just for IP access but the only market w= hich permits them to become commodities is IP and the most common applicati= on for that is Internet access. I think the IEEE and other access forums wi= ll continue to try and keep their products relevant to that use.=0D=0A=0D=0A= 3) In the case of 3GPP/2 however, we have a definite collision of worlds. T= hey represent a complete end to end network architecture covering everythin= g from devices through functional network elements, protocols, and even the= services. While the architecture defines Packet Service (on top of the inc= reasingly defunct Circuit Service) it is definitely not the same as being t= he Internet. Strictly speaking, IMS only has meaning within that constraint= (even though the term is being used for a general Internet based VoIP serv= ice). The most significant convergence issue is between the likes of 3G and= the general Internet model. The probability envelope still hasn't collapse= d on whether 3G is primarily just another Internet access technology or whe= ther it's a complete network itself - with Internet access bolted on the si= de as a peripheral function. I think market forces will not permit it to co= ntinue as a relatively complete but closed network - but that's just my vie= w.=0D=0A=0D=0A4) NENA, ETSI TISPAN, and similar organizations represent spe= cial interest groups that live on the Internet - I think we'll see increasi= ng numbers of such organizations - NENA didn't used to worry about it, but = now it does. The Internet is paying the price of its success; people wanted= everyone to use it, now they do and they have things to say about how they= 'd like it to be. To some extent they will just want to refine their own ap= plications and conventions but, also, they will seek to influence the funct= ionality that is available in the Internet to make it optimal for their int= erests.=0D=0A=0D=0A5) The role of the IETF in all this... I am not sure. I = understand that in principal it may be the anointed party that ensures ther= e is consistency and integrity to support global interoperability and some = principles in support of users. When I look around, though, I see many many= working groups focusing on very eclectic topics - and I'm not sure what so= rt of constitutional governance is used to really decide what's pertinet fo= r the IETF and what might be better off having its own forum.=0D=0A=0D=0AAn= alternative view would have been to say that "internet" means that it stop= s at the internetworking layer (layer 3 really) and that the Internet is th= e specific most significant global set of interconnected networks. From tha= t perspective, the IETF would have made sure there was a consistent layer 3= , including control functions (like DNS, DHCP, BGCP, etc.) but wouldn't spo= nsor applications - nor necessarily session, transport, and presentation la= yer technologies. In it's purest form the Internet is an openly connected s= et of layer 3 networks; a global platform for any number of applications. V= oice is just a service, instant messaging is just a service, U-Tube is just= a service... they all involve protocols and have interworking issues in th= eir own domain but that's their problem and they shouldn't be able to impac= t a properly robust Internet. I think that's the virtue of the Internet ove= r 3GPP/2 by the way - it's not as heavily prescriptive about what it is use= d for.=0D=0A=0D=0AOf course - the IETF is not as I just suggested it could = be - I said earlier what it looks like to me... confusing. In practice some= of the application protocols are defined in the IETF and others are not. W= 3C was formed by Berners-Lee so he could pursue WWW principles independentl= y of the IETF. It didn't really make any difference to the Internet that he= did that - just added a terrific new application area with its own forum. = It's certainly good that there's a place for people to go if they think the= y have a useful idea for something to do on the Internet but it certainly b= ecomes a "grab bag". Perhaps it was because the IETF inherited other "stuff= " like SMTP, FTP, and SNMP from the original ARPANet suite that opened the = door to make it forum that's an application free for all... I don't know.=0D= =0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFro= m: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com]=20=0D=0ASent: Thursd= ay, 15 March 2007 11:13 PM=0D=0ATo: Tschofenig, Hannes; Dawson, Martin; Dol= ly, Martin C (Attlabs); Hannes Tschofenig; GEOPRIV; ECRIT=0D=0ASubject: RE:= [Geopriv] RE: [Ecrit] NENA=0D=0A=0D=0ADSL Forum is also using the NENA doc= uments to determine requirements for network elements and CPE.=0D=0ABarbara= =20=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Tschofenig, Hannes [ma= ilto:hannes.tschofenig@siemens.com]=20=0D=0ASent: Thursday, March 15, 2007 = 7:58 AM=0D=0ATo: Dawson, Martin; Dolly, Martin C (Attlabs); Hannes Tschofen= ig; GEOPRIV; ECRIT=0D=0ASubject: AW: [Geopriv] RE: [Ecrit] NENA=0D=0A=0D=0A= Hi Martin,=20=0D=0A=0D=0AThanks for the quick response.=20=0D=0A=0D=0AI am = trying to figure out what the impact to the Internet is if many SDOs develo= p their own specifications for emergency services without considering the N= ENA work and I am particularly referring to the SDOs that potentially impac= t real networks.=20=0D=0A=0D=0AMore comments below:=20=0D=0A=0D=0A> -----Ur= spr=FCngliche Nachricht-----=0D=0A> Von: Dawson, Martin [mailto:Martin.Daws= on@andrew.com]=0D=0A> Gesendet: Donnerstag, 15. M=E4rz 2007 12:47=0D=0A> An= : Tschofenig, Hannes; DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig;=20=0D=0A= > GEOPRIV; ECRIT=0D=0A> Betreff: RE: [Geopriv] RE: [Ecrit] NENA=0D=0A>=20=0D= =0A> I think Martin (the other Martin, not me) meant that ATIS works with =0D= =0A> NENA specifications. NENA is not an accredited SDO=0D=0A> - in the sam= e sense, for example, that ATIS is accredited and able to=20=0D=0A> publish= American National Standards. Of course, that doesn't prevent=20=0D=0A> NEN= A from publishing referencable documents.=0D=0A> The E2 interface specifica= tion used for wireless E-9-1-1 is a NENA=20=0D=0A> document and, as ever, t= he i2 architecture specification is a NENA=20=0D=0A> document.=0D=0A>=20=0D= =0A> I don't think there's anything prescriptive about how the work of NENA= =20=0D=0A> interacts with other SDOs. I think it's best understood in terms= of=20=0D=0A> the general role of NENA - which is to provide a national con= sensus=20=0D=0A> view on how the elements of the emergency service fit toge= ther. This=20=0D=0A> ends up covering everything from devices through acces= s and core=20=0D=0A> networks, and into the emergency network elements - th= e routers, call=20=0D=0A> centers, and ALI and ANI databases.=0D=0A>=20=0D=0A= > This is particularly important in an environment such as the US which=20=0D= =0A> is extremely devolved with multiple independent parties operating at =0D= =0A> every level and every function. Without a body like NENA it would all =0D= =0A> deteriorate into chaos - despite how it seems to some, that's not what= =20=0D=0A> it is now. :)=0D=0A>=20=0D=0A> It's good to look at a case study= =2E=0D=0A>=20=0D=0A> NENA had a lot of influence on, for example, the TIA=0D= =0A> J-STD-036 specification for phase 2 wireless which subsequently formed= =20=0D=0A> the deployment model for how the FCC mandate for wireless E-9-1-= 1=20=0D=0A> should be satisfied. This consequently had an impact on 3GPP/2.=0D= =0A=0D=0A>From the last SDO workshop I got the impression that the 3GPP2 ac= tually had nothing expect for a few high-level requirements. Since a lot of= the 3GPP2 work is taken from 3GPP it might well be possible that they also= recycle the emergency services work.=20=0D=0A=0D=0AMaybe they have develop= ed a solution already. Maybe you can point to the relevant documents.=20=0D= =0A=0D=0A There are even=20=0D=0A> parameters in the 3GPP MAP specification= called NA-ESRK and NA-ESRD=20=0D=0A> (the NA part stands for North America= n) - though they do actually have=20=0D=0A> generic utility.=0D=0A=0D=0ABut= the NENA work is more than just these parameters.=20=0D=0A=0D=0A>=20=0D=0A= > A typical chain of influence would go along the lines that US carriers =0D= =0A> need to meet some regulatory requirement for which definitions=20=0D=0A= > originating or influenced by NENA form the model for deployment. The=20=0D= =0A> carriers need their vendors to support the functionality associated =0D= =0A> with the model. Both the vendors and the carriers participate in the =0D= =0A> SDOs governing the specifications for the network elements involved =0D= =0A> and subsequently influence what those specifications look like.=0D=0A>= To a large extent, artefacts turn up in SDO specifications as an=20=0D=0A>= extended phenotype of the significance and influence of the US market=20=0D= =0A> and the role of NENA in that market.=0D=0A=0D=0ABut it is not really g= ood if the NENA work does not appear in the standardization work of other S= DOs.=20=0D=0A=0D=0A>=20=0D=0A> Does that make sense=3F I'm not aware that t= here are any strict=20=0D=0A> definitions for the relationship between NENA= and other SDOs.=0D=0AIt makes sense but to me it looks like the recipe for= a non-working global emergency service solution since there are too many p= layers involved that want to develop their own story.=20=0D=0A=0D=0A=0D=0AC= iao=0D=0AHannes=0D=0A=0D=0A=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=20=0D=0A> -= ----Original Message-----=0D=0A> From: Tschofenig, Hannes [mailto:hannes.ts= chofenig@siemens.com]=0D=0A> Sent: Thursday, 15 March 2007 9:31 PM=0D=0A> T= o: DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig; GEOPRIV; ECRIT=0D=0A> Subje= ct: AW: [Geopriv] RE: [Ecrit] NENA=0D=0A>=20=0D=0A> Hi Martin,=0D=0A>=20=0D= =0A> what do you mean by "ATIS"=3F=0D=0A>=20=0D=0A> You mean that ATIS is u= sing the NENA architecture or I should have=20=0D=0A> included ATIS in the = list of SDOs=3F=0D=0A>=20=0D=0A> Ciao=0D=0A> Hannes=0D=0A>=20=0D=0A> > ----= -Urspr=FCngliche Nachricht-----=0D=0A> > Von: DOLLY, MARTIN C, ATTLABS [mai= lto:mdolly@att.com]=0D=0A> > Gesendet: Donnerstag, 15. M=E4rz 2007 11:28=0D= =0A> > An: Hannes Tschofenig; GEOPRIV; ECRIT=0D=0A> > Betreff: [Geopriv] RE= : [Ecrit] NENA=0D=0A> >=20=0D=0A> > ATIS=0D=0A> >=20=0D=0A> > -----Original= Message-----=0D=0A> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gm= x.net]=0D=0A> > Sent: Thursday, March 15, 2007 5:41 AM=0D=0A> > To: GEOPRIV= ; ECRIT=0D=0A> > Subject: [Ecrit] NENA=0D=0A> >=20=0D=0A> > Hi all,=0D=0A> = >=20=0D=0A> > I would like to better understand the work done by NENA.=0D=0A= > >=20=0D=0A> > Which SDOs are going to make use (or is already used) of th= e work=20=0D=0A> > done by NENA=3F=0D=0A> >=20=0D=0A> > Consider the follow= ing SDOs, as an example=0D=0A> > - 3GPP=0D=0A> > - 3GPP2=0D=0A> > - Wimax=0D= =0A> > - Wifi Alliance=0D=0A> > - DSL Forum=0D=0A> > - ETSI TISPAN=0D=0A> >= - CableLabs=0D=0A> >=20=0D=0A> > Since there is often a mismatch between t= he standards being=20=0D=0A> > developed in=0D=0A> >=20=0D=0A> > these SDOs= I would like to also understand how the NENA work going=20=0D=0A> > to be=0D= =0A> >=20=0D=0A> > used on the Internet=3F=0D=0A> >=20=0D=0A> > Ciao=0D=0A>= > Hannes=0D=0A> >=20=0D=0A> >=20=0D=0A> > ________________________________= _______________=0D=0A> > Ecrit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A> = > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> >=20=0D=0A> > _______= ________________________________________=0D=0A> > Geopriv mailing list=0D=0A= > > Geopriv@ietf.org=0D=0A> > https://www1.ietf.org/mailman/listinfo/geopri= v=0D=0A> >=20=0D=0A>=20=0D=0A> ____________________________________________= ___=0D=0A> Geopriv mailing list=0D=0A> Geopriv@ietf.org=0D=0A> https://www1= =2Eietf.org/mailman/listinfo/geopriv=0D=0A>=20=0D=0A> ---------------------= -----------------------------------------=0D=0A> --------------------------= --------=0D=0A> This message is for the designated recipient only and may c= ontain=20=0D=0A> privileged, proprietary, or otherwise private information.=0D= =0A> If you have received it in error, please notify the sender immediately= =20=0D=0A> and delete the original. Any unauthorized use of this email is =0D= =0A> prohibited.=0D=0A> ---------------------------------------------------= -----------=0D=0A> ----------------------------------=0D=0A> [mf2]=0D=0A> =0D= =0A>=20=0D=0A=0D=0A_______________________________________________=0D=0AEcr= it mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/list= info/ecrit=0D=0A=0D=0A*****=0D=0A=0D=0AThe information transmitted is inten= ded only for the person or entity to which it is addressed and may contain = confidential, proprietary, and/or privileged material. Any review, retransm= ission, dissemination or other use of, or taking of any action in reliance = upon this information by persons or entities other than the intended recipi= ent is prohibited. If you received this in error, please contact the sender= and delete the material from all computers. GA621=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 informa= tion. =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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 10:27: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 1HRqvr-0006im-Ru; Thu, 15 Mar 2007 10:27:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqvo-0006Tw-A5; Thu, 15 Mar 2007 10:27:52 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRqvl-00085I-PD; Thu, 15 Mar 2007 10:27:52 -0400 X-SEF-Processed: 5_0_0_910__2007_03_15_09_33_49 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); Thu, 15 Mar 2007 09:33:49 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 09:27:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 09:27:47 -0500 Message-ID: In-Reply-To: <007001c76707$df4ac600$230d0d0a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: [Ecrit] NENA Thread-Index: Acdm5nZDo9e+vSXwTWyDOrrBG+jCegABhvEwAAAR9hAAAhESUAACSAmgAAPGYmA= From: "Dawson, Martin" To: "Marc Linsner" X-OriginalArrivalTime: 15 Mar 2007 14:27:49.0339 (UTC) FILETIME=[1B965AB0:01C7670E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: GEOPRIV , ECRIT X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Marc,=0D=0A=0D=0AI don't know what you mean. NENA wrote requirements. Th= e IETF is defining protocols. I think that's what you just said should happ= en.=0D=0A=0D=0AThe acquisition protocol comparison isn't a NENA document, i= t's an ESIF document. Perhaps you don't distinguish between them. Either wa= y, it's in response to some industry demand for clarity on what they should= be implementing. I think it's been worthwhile in bringing the requirements= to the fore across a number of forums.=0D=0A=0D=0AI haven't been involved = in the NENA/ECRIT work, so I couldn't comment on how effective it's been.=0D= =0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFro= m: Marc Linsner [mailto:mlinsner@cisco.com]=20=0D=0ASent: Friday, 16 March = 2007 12:43 AM=0D=0ATo: Dawson, Martin=0D=0ACc: 'GEOPRIV'; 'ECRIT'=0D=0ASubj= ect: RE: [Geopriv] RE: [Ecrit] NENA=0D=0A=0D=0AMartin D.,=0D=0A=0D=0AAs I h= ave expressed in many NENA venues and will reiterate here, NENA goes=0D=0Aw= ay past their boundary of expertise. I've pleaded many times, for many=0D=0A= years (starting at the 2000 TDC), at many a microphone in NENA venues to=0D= =0Aplease provide the requirements they need to perform their function. IM= O,=0D=0Ano other organization can do that as well as NENA for North America= =2E=0D=0AIf/when NENA does such, the IP/VoIP/Internet industry/SDO communit= y=0D=0Awould/will provide the best solution possible to meet those requirem= ents.=0D=0A=0D=0AMy statement didn't change over time: 'Please draw a line = in the sand, on=0D=0Aone side is the world and the other side is NENA const= ituents, state the=0D=0Arequirements when crossing the line.'=0D=0A=0D=0AIn= stead, many people have promoted to NENA members that they can not only=0D=0A= take NENA requirements to the SDO community, but that NENA can somehow=0D=0A= dictate the solution.=0D=0A=0D=0ANENA's current review of location acquisit= ion mechanisms is an example of=0D=0ANENA crossing the line. Those documen= ts which have now filtered to ATIS=0D=0Athen liaised to a wide variety of S= DOs 'on behalf of NENA' are fraught with=0D=0Atechnical errors and misguide= d assumptions. But, when the responses to the=0D=0Aliaise attempt to point= out those issues, it's passed off as a derelict=0D=0Aresponse. Further di= scussion of the ATIS process wrt this isn't warranted=0D=0Ain this venue. = But my point is that it seems to be common thread with what=0D=0Awe're expe= riencing in the IETF.=0D=0A=0D=0ABut, there is good in the world!=0D=0A=0D=0A= In my obviously biased opinion, I believe an example of what has worked is=0D= =0Athe relationship between NENA and ECRIT. I believe that LoST/related dr= afts=0D=0Ahave met almost all, if not all of the goals/requirements of the = NENA LTD=0D=0Awg. I did get a little testy when I (possibly mistakenly) se= nsed a late=0D=0Achange in requirements, but I sense that has resolved itse= lf. I've also=0D=0Awitnessed a willingness by the LoST team to make adjust= ments to the solution=0D=0Aas we/NENA gain implementation experience. If t= hat isn't an example of how=0D=0Athings should work, then all hope has vani= shed.=0D=0A=0D=0ASo, I ask that you compare the difference between the NENA= -ECRIT=0D=0Arelationship and the NENA-GeoPriv relationship, what is your op= inion of what=0D=0Aworked/didn't work/isn't working/and why=3F=0D=0A=0D=0AY= es, NENA does count! Threats of regulation do not count!=0D=0A=0D=0A-Marc-=0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Dawson= , Martin [mailto:Martin.Dawson@andrew.com]=20=0D=0A> Sent: Thursday, March = 15, 2007 7:47 AM=0D=0A> To: Tschofenig, Hannes; DOLLY, MARTIN C, ATTLABS; H= annes=20=0D=0A> Tschofenig; GEOPRIV; ECRIT=0D=0A> Subject: RE: [Geopriv] RE= : [Ecrit] NENA=0D=0A>=20=0D=0A> I think Martin (the other Martin, not me) m= eant that ATIS=20=0D=0A> works with NENA specifications. NENA is not an acc= redited SDO=20=0D=0A> - in the same sense, for example, that ATIS is accred= ited and=20=0D=0A> able to publish American National Standards. Of course, = that=20=0D=0A> doesn't prevent NENA from publishing referencable documents.= =20=0D=0A> The E2 interface specification used for wireless E-9-1-1 is a =0D= =0A> NENA document and, as ever, the i2 architecture specification=20=0D=0A= > is a NENA document.=0D=0A>=20=0D=0A> I don't think there's anything presc= riptive about how the=20=0D=0A> work of NENA interacts with other SDOs. I t= hink it's best=20=0D=0A> understood in terms of the general role of NENA - = which is to=20=0D=0A> provide a national consensus view on how the elements= of the=20=0D=0A> emergency service fit together. This ends up covering=20=0D= =0A> everything from devices through access and core networks, and=20=0D=0A= > into the emergency network elements - the routers, call=20=0D=0A> centers= , and ALI and ANI databases.=0D=0A>=20=0D=0A> This is particularly importan= t in an environment such as the=20=0D=0A> US which is extremely devolved wi= th multiple independent=20=0D=0A> parties operating at every level and ever= y function. Without=20=0D=0A> a body like NENA it would all deteriorate int= o chaos -=20=0D=0A> despite how it seems to some, that's not what it is now= =2E :)=0D=0A>=20=0D=0A> It's good to look at a case study.=0D=0A>=20=0D=0A>= NENA had a lot of influence on, for example, the TIA=20=0D=0A> J-STD-036 s= pecification for phase 2 wireless which=20=0D=0A> subsequently formed the d= eployment model for how the FCC=20=0D=0A> mandate for wireless E-9-1-1 shou= ld be satisfied. This=20=0D=0A> consequently had an impact on 3GPP/2. There= are even=20=0D=0A> parameters in the 3GPP MAP specification called NA-ESRK= and=20=0D=0A> NA-ESRD (the NA part stands for North American) - though the= y=20=0D=0A> do actually have generic utility.=0D=0A>=20=0D=0A> A typical ch= ain of influence would go along the lines that US=20=0D=0A> carriers need t= o meet some regulatory requirement for which=20=0D=0A> definitions originat= ing or influenced by NENA form the model=20=0D=0A> for deployment. The carr= iers need their vendors to support=20=0D=0A> the functionality associated w= ith the model. Both the vendors=20=0D=0A> and the carriers participate in t= he SDOs governing the=20=0D=0A> specifications for the network elements inv= olved and=20=0D=0A> subsequently influence what those specifications look l= ike.=20=0D=0A> To a large extent, artefacts turn up in SDO specifications a= s=20=0D=0A> an extended phenotype of the significance and influence of=20=0D= =0A> the US market and the role of NENA in that market.=0D=0A>=20=0D=0A> Do= es that make sense=3F I'm not aware that there are any strict=20=0D=0A> def= initions for the relationship between NENA and other SDOs.=0D=0A>=20=0D=0A>= Cheers,=0D=0A> Martin=0D=0A>=20=0D=0A> -----Original Message-----=0D=0A> F= rom: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=0D=0A> Sent:= Thursday, 15 March 2007 9:31 PM=0D=0A> To: DOLLY, MARTIN C, ATTLABS; Hanne= s Tschofenig; GEOPRIV; ECRIT=0D=0A> Subject: AW: [Geopriv] RE: [Ecrit] NENA=0D= =0A>=20=0D=0A> Hi Martin,=20=0D=0A>=20=0D=0A> what do you mean by "ATIS"=3F=0D= =0A>=20=0D=0A> You mean that ATIS is using the NENA architecture or I shoul= d=20=0D=0A> have included ATIS in the list of SDOs=3F=20=0D=0A>=20=0D=0A> C= iao=0D=0A> Hannes=0D=0A>=20=0D=0A> > -----Urspr=FCngliche Nachricht-----=0D= =0A> > Von: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]=0D=0A> > Gesen= det: Donnerstag, 15. M=E4rz 2007 11:28=0D=0A> > An: Hannes Tschofenig; GEOP= RIV; ECRIT=0D=0A> > Betreff: [Geopriv] RE: [Ecrit] NENA=0D=0A> >=20=0D=0A> = > ATIS=0D=0A> >=20=0D=0A> > -----Original Message-----=0D=0A> > From: Hanne= s Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> > Sent: Thursday, Ma= rch 15, 2007 5:41 AM=0D=0A> > To: GEOPRIV; ECRIT=0D=0A> > Subject: [Ecrit] = NENA=0D=0A> >=20=0D=0A> > Hi all,=0D=0A> >=20=0D=0A> > I would like to bett= er understand the work done by NENA.=0D=0A> >=20=0D=0A> > Which SDOs are go= ing to make use (or is already used) of=20=0D=0A> the work done=20=0D=0A> >= by NENA=3F=0D=0A> >=20=0D=0A> > Consider the following SDOs, as an example=0D= =0A> > - 3GPP=0D=0A> > - 3GPP2=0D=0A> > - Wimax=0D=0A> > - Wifi Alliance=0D= =0A> > - DSL Forum=0D=0A> > - ETSI TISPAN=0D=0A> > - CableLabs=0D=0A> >=20=0D= =0A> > Since there is often a mismatch between the standards being=20=0D=0A= > developed=20=0D=0A> > in=0D=0A> >=20=0D=0A> > these SDOs I would like to = also understand how the NENA=20=0D=0A> work going to=20=0D=0A> > be=0D=0A> = >=20=0D=0A> > used on the Internet=3F=0D=0A> >=20=0D=0A> > Ciao=0D=0A> > Ha= nnes=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> >=20=0D=0A> > ____________= ___________________________________=0D=0A> > Geopriv mailing list=0D=0A> > = Geopriv@ietf.org=0D=0A> > https://www1.ietf.org/mailman/listinfo/geopriv=0D= =0A> >=20=0D=0A>=20=0D=0A> _______________________________________________=0D= =0A> Geopriv mailing list=0D=0A> Geopriv@ietf.org=0D=0A> https://www1.ietf.= org/mailman/listinfo/geopriv=0D=0A>=20=0D=0A> -----------------------------= ---------------------------------=0D=0A> ----------------------------------=0D= =0A> This message is for the designated recipient only and may=20=0D=0A> co= ntain privileged, proprietary, or otherwise private information. =20=0D=0A>= If you have received it in error, please notify the sender=20=0D=0A> immed= iately and delete the original. Any unauthorized use of=20=0D=0A> this ema= il is prohibited.=0D=0A> --------------------------------------------------= ------------=0D=0A> ----------------------------------=0D=0A> [mf2]=0D=0A> =0D= =0A>=20=0D=0A> _______________________________________________=0D=0A> Geopr= iv mailing list=0D=0A> Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailma= n/listinfo/geopriv=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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 10:49:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRrGe-0006Ae-S0; Thu, 15 Mar 2007 10:49:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRrGd-0006AN-3P; Thu, 15 Mar 2007 10:49:23 -0400 Received: from dnsmx2pya.telcordia.com ([128.96.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRrGb-0003Ld-Fq; Thu, 15 Mar 2007 10:49:23 -0400 Received: from rrc-dte-ieg01.cc.telcordia.com (rrc-dte-ieg01.cc.telcordia.com [128.96.20.22]) by dnsmx2pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id l2FEn8O24854; Thu, 15 Mar 2007 10:49:08 -0400 (EDT) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2007031510493608821 ; Thu, 15 Mar 2007 10:49:36 -0400 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 10:49:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 10:49:30 -0400 Message-ID: In-Reply-To: <007001c76707$df4ac600$230d0d0a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: [Ecrit] NENA Thread-Index: Acdm5nZDo9e+vSXwTWyDOrrBG+jCegABhvEwAAAR9hAAAhESUAACSAmgAAKWrQA= From: "Abbott, Nadine B" To: "Marc Linsner" X-OriginalArrivalTime: 15 Mar 2007 14:49:35.0888 (UTC) FILETIME=[2659E900:01C76711] X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: GEOPRIV , ECRIT X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Marc, I think that you misrepresent the NENA WG work on location acquisition. The NENA WG worked to provide requirements and to feed these = requirements into the IETF Geopriv process, and it seems to me that many = IETF Geopriv members have exerted considerable effort to consider how to = include those requirements. Many of those requirements were in fact, quite aligned with the related = Long-Term Definition requirements provided to ECRIT.=20 Further, the NENA WG then has tried to stay aware of what is going on in = many industry forums in the expectation of identifying and recommending = standard solutions that would meet those requirements, and in the hope = of promoting widespread implementation of location-related capabilities. = This is an ongoing work effort. In the liaisons that were sent out to many SDOs last summer, the NENA WG = encouraged these SDOs to work in cooperation with IETF toward common = solutions. NENA has a keen interest in seeing common location solutions = become widely available. In addition to this encouragement, the liaisons = that were sent out included a summary of the above-mentioned = requirements, as well as examples of proposed solution(s) that the NENA = WG found to meet many of these requirements, to stimulate dialog. =20 To my knowledge, the NENA WG has never "passed off as a derelict = response" the responses that have been received from several SDOs to = these liaisons. =20 As you point out, IETF has the deepest understanding of the Internet, = but it has always seemed to me that in the area of location = capabilities, the community of mobile and IP service and solution = providers have valuable insights to offer. Members of the NENA WG have = tried to advocate within IETF (and industry SDOs) for solutions that = would meet practical needs of the emergency services community, and also = have a better chance of being implemented in existing infrastructures = beyond enterprise environments. I am encouraged by Ted Hardie's comments and the hope that the Geopriv = WG will be able to make some progress in the Prague meeting. =20 Regards, Nadine Abbott =20 -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com]=20 Sent: Thursday, March 15, 2007 9:43 AM To: 'Dawson, Martin' Cc: 'GEOPRIV'; 'ECRIT' Subject: RE: [Geopriv] RE: [Ecrit] NENA Martin D., As I have expressed in many NENA venues and will reiterate here, NENA = goes way past their boundary of expertise. I've pleaded many times, for = many years (starting at the 2000 TDC), at many a microphone in NENA = venues to please provide the requirements they need to perform their = function. IMO, no other organization can do that as well as NENA for = North America. If/when NENA does such, the IP/VoIP/Internet industry/SDO community = would/will provide the best solution possible to meet those = requirements. My statement didn't change over time: 'Please draw a line in the sand, = on one side is the world and the other side is NENA constituents, state = the requirements when crossing the line.' Instead, many people have promoted to NENA members that they can not = only take NENA requirements to the SDO community, but that NENA can = somehow dictate the solution. NENA's current review of location acquisition mechanisms is an example = of NENA crossing the line. Those documents which have now filtered to = ATIS then liaised to a wide variety of SDOs 'on behalf of NENA' are = fraught with technical errors and misguided assumptions. But, when the = responses to the liaise attempt to point out those issues, it's passed = off as a derelict response. Further discussion of the ATIS process wrt = this isn't warranted in this venue. But my point is that it seems to be = common thread with what we're experiencing in the IETF. But, there is good in the world! In my obviously biased opinion, I believe an example of what has worked = is the relationship between NENA and ECRIT. I believe that LoST/related = drafts have met almost all, if not all of the goals/requirements of the = NENA LTD wg. I did get a little testy when I (possibly mistakenly) = sensed a late change in requirements, but I sense that has resolved = itself. I've also witnessed a willingness by the LoST team to make = adjustments to the solution as we/NENA gain implementation experience. = If that isn't an example of how things should work, then all hope has = vanished. So, I ask that you compare the difference between the NENA-ECRIT = relationship and the NENA-GeoPriv relationship, what is your opinion of = what worked/didn't work/isn't working/and why? Yes, NENA does count! Threats of regulation do not count! -Marc- > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Thursday, March 15, 2007 7:47 AM > To: Tschofenig, Hannes; DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig;=20 > GEOPRIV; ECRIT > Subject: RE: [Geopriv] RE: [Ecrit] NENA >=20 > I think Martin (the other Martin, not me) meant that ATIS works with=20 > NENA specifications. NENA is not an accredited SDO > - in the same sense, for example, that ATIS is accredited and able to=20 > publish American National Standards. Of course, that doesn't prevent=20 > NENA from publishing referencable documents. > The E2 interface specification used for wireless E-9-1-1 is a NENA=20 > document and, as ever, the i2 architecture specification is a NENA=20 > document. >=20 > I don't think there's anything prescriptive about how the work of NENA = > interacts with other SDOs. I think it's best understood in terms of=20 > the general role of NENA - which is to provide a national consensus=20 > view on how the elements of the emergency service fit together. This=20 > ends up covering everything from devices through access and core=20 > networks, and into the emergency network elements - the routers, call=20 > centers, and ALI and ANI databases. >=20 > This is particularly important in an environment such as the US which=20 > is extremely devolved with multiple independent parties operating at=20 > every level and every function. Without a body like NENA it would all=20 > deteriorate into chaos - despite how it seems to some, that's not what = > it is now. :) >=20 > It's good to look at a case study. >=20 > NENA had a lot of influence on, for example, the TIA > J-STD-036 specification for phase 2 wireless which subsequently formed = > the deployment model for how the FCC mandate for wireless E-9-1-1=20 > should be satisfied. This consequently had an impact on 3GPP/2. There=20 > are even parameters in the 3GPP MAP specification called NA-ESRK and=20 > NA-ESRD (the NA part stands for North American) - though they do=20 > actually have generic utility. >=20 > A typical chain of influence would go along the lines that US carriers = > need to meet some regulatory requirement for which definitions=20 > originating or influenced by NENA form the model for deployment. The=20 > carriers need their vendors to support the functionality associated=20 > with the model. Both the vendors and the carriers participate in the=20 > SDOs governing the specifications for the network elements involved=20 > and subsequently influence what those specifications look like. > To a large extent, artefacts turn up in SDO specifications as an=20 > extended phenotype of the significance and influence of the US market=20 > and the role of NENA in that market. >=20 > Does that make sense? I'm not aware that there are any strict=20 > definitions for the relationship between NENA and other SDOs. >=20 > Cheers, > Martin >=20 > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Thursday, 15 March 2007 9:31 PM > To: DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig; GEOPRIV; ECRIT > Subject: AW: [Geopriv] RE: [Ecrit] NENA >=20 > Hi Martin, >=20 > what do you mean by "ATIS"? >=20 > You mean that ATIS is using the NENA architecture or I should have=20 > included ATIS in the list of SDOs? >=20 > Ciao > Hannes >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] > > Gesendet: Donnerstag, 15. M=E4rz 2007 11:28 > > An: Hannes Tschofenig; GEOPRIV; ECRIT > > Betreff: [Geopriv] RE: [Ecrit] NENA > >=20 > > ATIS > >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Thursday, March 15, 2007 5:41 AM > > To: GEOPRIV; ECRIT > > Subject: [Ecrit] NENA > >=20 > > Hi all, > >=20 > > I would like to better understand the work done by NENA. > >=20 > > Which SDOs are going to make use (or is already used) of > the work done > > by NENA? > >=20 > > Consider the following SDOs, as an example > > - 3GPP > > - 3GPP2 > > - Wimax > > - Wifi Alliance > > - DSL Forum > > - ETSI TISPAN > > - CableLabs > >=20 > > Since there is often a mismatch between the standards being > developed > > in > >=20 > > these SDOs I would like to also understand how the NENA > work going to > > be > >=20 > > used on the Internet? > >=20 > > Ciao > > Hannes > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may contain=20 > 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=20 > prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 11:21: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 1HRrm1-00021A-RB; Thu, 15 Mar 2007 11:21:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRrm0-0001xc-CC; Thu, 15 Mar 2007 11:21:48 -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 1HRrlw-0008FH-Ky; Thu, 15 Mar 2007 11:21:48 -0400 Received: from [172.28.172.102] ([::ffff:12.172.52.10]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 15 Mar 2007 11:18:34 -0400 id 01588433.45F963CB.00005B83 In-Reply-To: References: Mime-Version: 1.0 Message-Id: From: Andrew Newton Subject: Re: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 11:21:22 -0400 To: "Abbott, Nadine B" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: GEOPRIV WG , Marc Linsner , iab@ietf.org, ECRIT X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1171605965==" Errors-To: geopriv-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1171605965== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-23436-1173971917-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-23436-1173971917-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Mar 15, 2007, at 10:49 AM, Abbott, Nadine B wrote: > The NENA WG worked to provide requirements and to feed these > requirements into the IETF Geopriv process, and it seems to me that > many IETF Geopriv members have exerted considerable effort to > consider how to include those requirements. > Many of those requirements were in fact, quite aligned with the > related Long-Term Definition requirements provided to ECRIT. > > Further, the NENA WG then has tried to stay aware of what is going > on in many industry forums in the expectation of identifying and > recommending standard solutions that would meet those requirements, > and in the hope of promoting widespread implementation of location- > related capabilities. This is an ongoing work effort. I'm currently sitting in a NENA NG Partner Program meeting in Arlington, VA. One of the presentations was a list of the SDOs that NENA has reached out to, with the IETF left off the list. When questioned about that, the response was (summarizing) "Working with the IETF is a given. We work with them every day." I think some of the frustration around the requirements has been that, from the perspective of many IETF'ers, the requirements from NENA have been thrown over the wall, they are done as far as NENA is concerned, and that the IETF has no right to question them. I do not believe that was the intent, because I know many NENA active participants have been active in GEOPRIV and ECRIT. From the other perspective, I'm sure NENA participants see the IETF reacting badly. In the future, both organizations should strive to work together during the requirements development. I personally I have casually pursued getting the IETF to have an official liaison to NENA, but the IAB has not exactly been receptive of the idea. I think it is time that the ECRIT and GEOPRIV co-chairs push harder on the IAB to establish an official relationship if NENA is willing to allow it. -andy --=_zeke.ecotroph.net-23436-1173971917-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.54.2
On Mar 15, 2007, at 10:= 49 AM, Abbott, Nadine B wrote:

The = NENA WG worked to provide requirements and to feed these requirements int= o the IETF Geopriv process, and it seems to me that many IETF Geopriv mem= bers have exerted considerable effort to consider how to include those re= quirements.

Many of th= ose requirements were in fact, quite aligned with the related Long-Term D= efinition requirements provided to ECRIT.=A0

Further, the NENA WG then has tried to stay aware of = what is going on in many industry forums in the expectation of=A0 identifying and recommending standa= rd solutions that would meet those requirements, and in the hope of promo= ting widespread implementation of location-related capabilities.=A0 This is an ongoing work effort.

I'm currently sitting in a NENA NG = Partner Program meeting in Arlington, VA.=A0 One of the presentations was = a list of the SDOs that NENA has reached out to, with the IETF left off t= he list.=A0 When questioned about that, the response was (summarizing) "W= orking with the IETF is a given.=A0 We work with them every day."

I think some of the f= rustration around the requirements has been that, from the perspective of = many IETF'ers, the requirements from NENA have been thrown over the wall, = they are done as far as NENA is concerned, and that the IETF has no right = to question them.=A0 I do not believe that was the intent, because I know = many NENA active participants have been active in GEOPRIV and ECRIT.=A0 F= rom the other perspective, I'm sure NENA participants see the IETF reacti= ng badly.

In t= he future, both organizations should strive to work together during the r= equirements development.=A0 I personally I have casually pursued getting = the IETF to have an official liaison to NENA, but the IAB has not exactly = been receptive of the idea.=A0 I think it is time that the ECRIT and GEOP= RIV co-chairs push harder on the IAB to establish an official relationshi= p if NENA is willing to allow it.

-andy
--=_zeke.ecotroph.net-23436-1173971917-0001-2-- --===============1171605965== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1171605965==-- From geopriv-bounces@ietf.org Thu Mar 15 11:46: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 1HRs9T-00004w-Hx; Thu, 15 Mar 2007 11:46:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRs9S-0008WM-PS; Thu, 15 Mar 2007 11:46:02 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRs9Q-0002z1-E0; Thu, 15 Mar 2007 11:46:02 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2007 08:46:00 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l2FFjx5n022152; Thu, 15 Mar 2007 08:45:59 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2FFjcAY022040; Thu, 15 Mar 2007 15:45:59 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 11:45:56 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 11:45:55 -0400 From: "Marc Linsner" To: "'Abbott, Nadine B'" Subject: RE: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 11:45:55 -0400 Message-ID: <00a801c76719$04ecf570$230d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acdm5nZDo9e+vSXwTWyDOrrBG+jCegABhvEwAAAR9hAAAhESUAACSAmgAAKWrQAAAzfwgA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 15 Mar 2007 15:45:55.0979 (UTC) FILETIME=[050ADDB0:01C76719] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3210; t=1173973559; x=1174837559; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20RE=3A=20[Ecrit]=20NENA |Sender:=20; bh=L0YSdN7W7shDUggk+AtJwg3AiSS4b6NWNn1A9+q8KC4=; b=RoKkyfCMvqTvFfck4ERMw3slO7oyQDknh2/oupmTqSSyfiKouCzbp4tjzDmgqVXD+PvWOGRZ 2QXV81RPaOWnRmfz0LaJrCCXhcGMFZ3w1sRKWfD3nlLwUGnsj0JkE+8Q; Authentication-Results: sj-dkim-5; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: 'GEOPRIV' , 'ECRIT' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Nadine, > Further, the NENA WG then has tried to stay aware of what is > going on in many industry forums in the expectation of > identifying and recommending standard solutions that would > meet those requirements, and in the hope of promoting > widespread implementation of location-related capabilities. > This is an ongoing work effort. It is the act of NENA 'recommending standard solutions' that I am referring to. IMO, that is outside of NENA's expertise. > > In the liaisons that were sent out to many SDOs last summer, > the NENA WG encouraged these SDOs to work in cooperation with > IETF toward common solutions. NENA has a keen interest in > seeing common location solutions become widely available. In > addition to this encouragement, the liaisons that were sent > out included a summary of the above-mentioned requirements, > as well as examples of proposed solution(s) that the NENA WG > found to meet many of these requirements, to stimulate dialog. I wasn't specifically referring to the liaisons from NENA last summer, sorry that wasn't clear, but I was focused on NENA's new found agent, ESIF/NGES. It's very interesting on how Martin is characterizing these latest liaisons from NGES as an ESIF effort, but yet in that very venue when I questioned why normal ANSI engineering practices were not being exercised, I was told to go back to NENA if I questioned the requirements. So either that effort is an ESIF project requiring due ANSI proscribed engineering, or ESIF/NGES is an agent for NENA as was explained to me in that venue. Martin is changing the characterization of this project to fit his needs in the current conversation. > > To my knowledge, the NENA WG has never "passed off as a > derelict response" the responses that have been received from > several SDOs to these liaisons. Again, this is my opinion of how NGES is handling responses to their liaison, sorry for the confusion. > > As you point out, IETF has the deepest understanding of the > Internet, but it has always seemed to me that in the area of > location capabilities, the community of mobile and IP service > and solution providers have valuable insights to offer. > Members of the NENA WG have tried to advocate within IETF > (and industry SDOs) for solutions that would meet practical > needs of the emergency services community, and also have a > better chance of being implemented in existing > infrastructures beyond enterprise environments. So, come one and all with requirements. When consensus on requirements is achieved, come one and all with solution proposals. I've tried to demonstrate with the ECRIT example how that process works and at the same I believe we've witnessed how it doesn't work by bringing the requirements along with a proposed solution in what appears to be a mixed up sequence. > > I am encouraged by Ted Hardie's comments and the hope that > the Geopriv WG will be able to make some progress in the > Prague meeting. I have great hope for this effort. I hope Ted can provide the spark to get things moving forward. I know I'm tired of trying. -Marc- _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 11:56: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 1HRsJG-00030H-8q; Thu, 15 Mar 2007 11:56:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRsJD-000301-FD; Thu, 15 Mar 2007 11:56:07 -0400 Received: from mail.opengeospatial.org ([208.44.53.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRsJA-0003wX-Sh; Thu, 15 Mar 2007 11:56:07 -0400 Received: from SusieandCarl (c-67-174-113-243.hsd1.co.comcast.net [67.174.113.243]) (authenticated bits=0) by mail.opengeospatial.org (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l2FFtkjg010496 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 15 Mar 2007 11:55:48 -0400 Message-ID: <012101c7671a$6684fa70$6401a8c0@SusieandCarl> From: "Carl Reed OGC Account" To: "Tschofenig, Hannes" , "Dawson, Martin" , "DOLLY, MARTIN C, ATTLABS" , "Hannes Tschofenig" , "GEOPRIV" , "ECRIT" References: <8F6CBC7005099442AECDB784C9E9D7E701903C2C@MCHP7R6A.ww002.siemens.net> Subject: Re: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 09:53:02 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Status: No, score=-96.0 required=5.0 tests=BAYES_50, RCVD_IN_NJABL_DUL, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, USER_IN_WHITELIST autolearn=disabled version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on mail.opengeospatial.org X-Virus-Scanned: ClamAV 0.90.1/2841/Thu Mar 15 07:11:45 2007 on mail.opengeospatial.org X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.opengeospatial.org id l2FFtkjg010496 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hannes - A really interesting question - especially from the perspective of locati= on=20 payloads and location provision. We in the OGC struggle with this issue o= n a=20 regular basis. This is perhaps why the OGC has formal agreements with abo= ut=20 a dozen SDOs and other organizations that develop specifications in the=20 location/geospatial space. And even with lots of coordination and=20 collaboration, sometimes folks go their own way - which plays havoc with=20 consistent architecture and infrastructure. And we find new efforts cropp= ing=20 up on a regular basis. That said, from a standards "professional" perspective, I am very pleased= =20 with how the IETF GeoPRIV collaboration and standard work is progressing.= I=20 know that there is a bit of concern about discord in some of the recent=20 discussions . . . but compared to some standards discussions I have=20 witnessed over the years, the ones in the GeoPRIV WG are consistently=20 professional and well mannered! Regards Carl ----- Original Message -----=20 From: "Tschofenig, Hannes" To: "Dawson, Martin" ; "DOLLY, MARTIN C, ATTLAB= S"=20 ; "Hannes Tschofenig" ; "GEOPR= IV"=20 ; "ECRIT" Sent: Thursday, March 15, 2007 5:57 AM Subject: AW: [Geopriv] RE: [Ecrit] NENA > Hi Martin, > > Thanks for the quick response. > > I am trying to figure out what the impact to the Internet is if many SD= Os=20 > develop their own specifications for emergency services without=20 > considering the NENA work and I am particularly referring to the SDOs t= hat=20 > potentially impact real networks. > > More comments below: > >> -----Urspr=FCngliche Nachricht----- >> Von: Dawson, Martin [mailto:Martin.Dawson@andrew.com] >> Gesendet: Donnerstag, 15. M=E4rz 2007 12:47 >> An: Tschofenig, Hannes; DOLLY, MARTIN C, ATTLABS; Hannes >> Tschofenig; GEOPRIV; ECRIT >> Betreff: RE: [Geopriv] RE: [Ecrit] NENA >> >> I think Martin (the other Martin, not me) meant that ATIS >> works with NENA specifications. NENA is not an accredited SDO >> - in the same sense, for example, that ATIS is accredited and >> able to publish American National Standards. Of course, that >> doesn't prevent NENA from publishing referencable documents. >> The E2 interface specification used for wireless E-9-1-1 is a >> NENA document and, as ever, the i2 architecture specification >> is a NENA document. >> >> I don't think there's anything prescriptive about how the >> work of NENA interacts with other SDOs. I think it's best >> understood in terms of the general role of NENA - which is to >> provide a national consensus view on how the elements of the >> emergency service fit together. This ends up covering >> everything from devices through access and core networks, and >> into the emergency network elements - the routers, call >> centers, and ALI and ANI databases. >> >> This is particularly important in an environment such as the >> US which is extremely devolved with multiple independent >> parties operating at every level and every function. Without >> a body like NENA it would all deteriorate into chaos - >> despite how it seems to some, that's not what it is now. :) >> >> It's good to look at a case study. >> >> NENA had a lot of influence on, for example, the TIA >> J-STD-036 specification for phase 2 wireless which >> subsequently formed the deployment model for how the FCC >> mandate for wireless E-9-1-1 should be satisfied. This >> consequently had an impact on 3GPP/2. > >>From the last SDO workshop I got the impression that the 3GPP2 actually= =20 >>had nothing expect for a few high-level requirements. Since a lot of th= e=20 >>3GPP2 work is taken from 3GPP it might well be possible that they also=20 >>recycle the emergency services work. > > Maybe they have developed a solution already. Maybe you can point to th= e=20 > relevant documents. > > There are even >> parameters in the 3GPP MAP specification called NA-ESRK and >> NA-ESRD (the NA part stands for North American) - though they >> do actually have generic utility. > > But the NENA work is more than just these parameters. > >> >> A typical chain of influence would go along the lines that US >> carriers need to meet some regulatory requirement for which >> definitions originating or influenced by NENA form the model >> for deployment. The carriers need their vendors to support >> the functionality associated with the model. Both the vendors >> and the carriers participate in the SDOs governing the >> specifications for the network elements involved and >> subsequently influence what those specifications look like. >> To a large extent, artefacts turn up in SDO specifications as >> an extended phenotype of the significance and influence of >> the US market and the role of NENA in that market. > > But it is not really good if the NENA work does not appear in the=20 > standardization work of other SDOs. > >> >> Does that make sense? I'm not aware that there are any strict >> definitions for the relationship between NENA and other SDOs. > It makes sense but to me it looks like the recipe for a non-working glo= bal=20 > emergency service solution since there are too many players involved th= at=20 > want to develop their own story. > > > Ciao > Hannes > > >> Cheers, >> Martin >> >> -----Original Message----- >> From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] >> Sent: Thursday, 15 March 2007 9:31 PM >> To: DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig; GEOPRIV; ECRIT >> Subject: AW: [Geopriv] RE: [Ecrit] NENA >> >> Hi Martin, >> >> what do you mean by "ATIS"? >> >> You mean that ATIS is using the NENA architecture or I should >> have included ATIS in the list of SDOs? >> >> Ciao >> Hannes >> >> > -----Urspr=FCngliche Nachricht----- >> > Von: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] >> > Gesendet: Donnerstag, 15. M=E4rz 2007 11:28 >> > An: Hannes Tschofenig; GEOPRIV; ECRIT >> > Betreff: [Geopriv] RE: [Ecrit] NENA >> > >> > ATIS >> > >> > -----Original Message----- >> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> > Sent: Thursday, March 15, 2007 5:41 AM >> > To: GEOPRIV; ECRIT >> > Subject: [Ecrit] NENA >> > >> > Hi all, >> > >> > I would like to better understand the work done by NENA. >> > >> > Which SDOs are going to make use (or is already used) of the >> > work done >> > by NENA? >> > >> > Consider the following SDOs, as an example >> > - 3GPP >> > - 3GPP2 >> > - Wimax >> > - Wifi Alliance >> > - DSL Forum >> > - ETSI TISPAN >> > - CableLabs >> > >> > Since there is often a mismatch between the standards being >> > developed in >> > >> > these SDOs I would like to also understand how the NENA work >> > going to be >> > >> > used on the Internet? >> > >> > Ciao >> > Hannes >> > >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www1.ietf.org/mailman/listinfo/ecrit >> > >> > _______________________________________________ >> > Geopriv mailing list >> > Geopriv@ietf.org >> > https://www1.ietf.org/mailman/listinfo/geopriv >> > >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> >> -------------------------------------------------------------- >> ---------------------------------- >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> -------------------------------------------------------------- >> ---------------------------------- >> [mf2] >> >> > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 12:01:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRsO7-0002V5-Cs; Thu, 15 Mar 2007 12:01:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRsO7-0002V0-4o for geopriv@ietf.org; Thu, 15 Mar 2007 12:01:11 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRsO5-0004Zy-O8 for geopriv@ietf.org; Thu, 15 Mar 2007 12:01:11 -0400 Received: from ([139.76.131.91]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.173168949; Thu, 15 Mar 2007 12:00:46 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 15 Mar 2007 12:00:46 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 15 Mar 2007 12:00:46 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] Updated meeting agenda Date: Thu, 15 Mar 2007 12:00:44 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA031B2D51@crexc41p> In-Reply-To: X-MS-Has-Attach: Importance: normal X-MS-TNEF-Correlator: Priority: normal Thread-Topic: [Geopriv] Updated meeting agenda Thread-Index: AcdmXHwwevuE7qdfQwa60u5MMK6iqAAB4Crg References: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A2585CC@toroondc912> From: "Stark, Barbara" To: "Andrew Newton" , X-OriginalArrivalTime: 15 Mar 2007 16:00:46.0246 (UTC) FILETIME=[17AED460:01C7671B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Thanks, Andy. That would be really great if y'all could try to clear = those issues up, and select a protocol to go forward with. We really, = really need for this work to progress. There's rapidly growing anxiety = among service providers that we don't have a solution yet. It's starting = to border on desperation, due to pressure from regulatory bodies around = the world. So anything the chairs and the rest of the WG can do to get = this moving in Prague would be greatly appreciated. Service Providers = recognize the considerable expertise that the IETF has, and we all = believe that it would be best for the industry (and for individuals who = make emergency calls) if the IETF could provide us with a solution that = we can be comfortable implementing. With that said, I also need to stress that the NENA requirements are = very important to many service providers that I've talked to. I'm sorry = that the process for getting these requirements to geopriv in a timely = manner broke down, but I hope that they can be considered when making a = decision. Personally, I would be comfortable with signing still being an open = issue, so long as the solution didn't preclude it. I think the main = thing a solution would need to provide would be an assertion capability, = so (where appropriate, or where required by local/national law) a device = could request whatever is needed for a self-generated location's source = to be considered identified and authenticated. Barbara =20 -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Wednesday, March 14, 2007 1:15 PM To: g.caron@bell.ca Cc: geopriv@ietf.org Subject: Re: [Geopriv] Updated meeting agenda Guy, I realize this must seem confusing. We will have an L7-LCP proposal = advanced at some point. Today we have 3 proposals, and so we need to =20 figure out how to evaluate them and decide which we want to advance. =20 To do that, we initiated the L7-LCP problem statement and requirements = draft, a document that states the requirements we all agree to. Once we = agree to the requirements, we can move on to picking a protocol = proposal. Unfortunately, we seem to be unable to agree on the = requirements. There is a possibility that most of those issue could get cleared up at = IETF 68 with notable exception of location signing (which is a very = large issue). -andy On Mar 14, 2007, at 11:37 AM, g.caron@bell.ca wrote: > Andrew, Randall and Allison, > > At this point, I would like to know if geopriv will consider upgrading = > one (or many) L7-LCP as working group items at IETF #68. > > For some high-speed access providers, this is the only viable option=20 > and frankly, also the preferable approach. > > Thanks, > > Guy Caron > -----Message d'origine----- > De : Andrew Newton [mailto:andy@hxr.us] Envoy=E9 : 14 mars 2007 07:00 = =C0=20 > : GEOPRIV WG Objet : [Geopriv] Updated meeting agenda > > All, > > After feedback from the draft agenda and a discussion among the co-=20 > chairs, we have updated the GEOPRIV agenda for IETF 68. > > http://www3.ietf.org/proceedings/07mar/agenda/geopriv.txt > > The biggest change is in item 6, to address the issue now consuming so = > many cycles on our mailing list. The intent is to explicitly list, on = > the projector screen, the issues with location signing in a high=20 > bandwidth environment so participants may ask for clarifications of=20 > issues. Though we would all prefer to come to resolution on the=20 > issue, this is not likely to happen. The hope is that we can clarify=20 > issues to bring us closer to resolution. > > -andy > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv ***** 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. GA624 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 12:07: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 1HRsTl-0008CX-Ma; Thu, 15 Mar 2007 12:07:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRsTk-0008C7-C8 for geopriv@ietf.org; Thu, 15 Mar 2007 12:07:00 -0400 Received: from bellwecs5.bellnexxia.net ([207.236.237.117] helo=bellwecs5.srvr.bell.ca) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRsTf-0005NL-Rr for geopriv@ietf.org; Thu, 15 Mar 2007 12:07:00 -0400 Received: (qmail 2097 invoked from network); 15 Mar 2007 16:06:54 -0000 Received: from g.caron@bell.ca by bellwecs5.srvr.bell.ca with EntrustECS-Server-7.4; 15 Mar 2007 16:06:54 -0000 Received: from bellwfep4.bellnexxia.net (HELO bellwfep4-srv.bellnexxia.net) (207.236.237.110) by bellwecs5.srvr.bell.ca with SMTP; 15 Mar 2007 16:06:54 -0000 Received: from TOROONDC918.bell.corp.bce.ca ([142.182.89.79]) by bellwfep4-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20070315160654.RLUB1719.bellwfep4-srv.bellnexxia.net@TOROONDC918.bell.corp.bce.ca>; Thu, 15 Mar 2007 12:06:54 -0400 Received: from toroondc912.bell.corp.bce.ca ([142.182.89.15]) by TOROONDC918.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 12:06:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] Updated meeting agenda Date: Thu, 15 Mar 2007 12:06:52 -0400 Message-ID: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A2586C0@toroondc912> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Updated meeting agenda Thread-Index: AcdmXEJm+otROS5TSbG+VNfFUkNcawAGFtTg References: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A2585CC@toroondc912> From: To: X-OriginalArrivalTime: 15 Mar 2007 16:06:52.0640 (UTC) FILETIME=[F2121E00:01C7671B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Andrew, I do recognize the value of the L7-LCP Problem Statement & Requirements = Draft and find it reasonable to strive for an agreement (which I hope = does not mean consensus :) within the group. Putting the LO signing issue aside for the moment, I would like to = better understand what else needs further discussions to reach such an = agreement. If I may contribute to help expedite things a bit here (without stepping = too much on the Authors' toes), I would try to summarize what I've seen = so far on the Requirement aspect of the document in the last few weeks = and my perception of their statuses. Existing requirements: I haven't found oppositions in the archive on the existing requirements = found in section 9. This seems to be a solid agreement-base to start = with. For section 10.3, I've found only 1 request from J.Grenier to re-address = the "No conclusion" requirements but this was related to the SLO = discussion. I think it was suggested to move the LbyR requirements out = of the document since there is now a standalone I-D on this (couldn't = find the post on it though, so I might be wrong). Finally, it was = suggested by O.Lendl to consolidate all requirements in the same = section. Overall and besides SLO, nothing contentious there either. New requirement proposals:=20 - Consider requirements from NENA 08-752 Requested by: B.Stark Supported by: E.Arolik, M.Dawson, O.Lendl, J.Winterbottom, G.Caron Challenged by: H.Tschofenig STATUS: Under discussion however only 1 real assessment attempt thus = far REF: = http://www1.ietf.org/mail-archive/web/geopriv/current/msg02963.html - Setting a Response Time in the Location Request (NENA req. DA12) Requested by: B.Stark, J.Grenier Supported by: J.Winterbottom, M.Thompson, G.Caron Challenged by: B.Rosen STATUS: Open. Contention on the fact that it may be orthogonal to all = LCPs REF: = http://www1.ietf.org/mail-archive/web/geopriv/current/msg02989.html - Add LIS-LIS communications Requested by: O.Lendl, B.Stark, E.Arlolik Supported by: M.Dawson, J.Winterbottom, G.Caron, J.Grenier Challenged by: None (IMO, only clarifications were sought) STATUS: Resolved but may benefit from specific wording in L7-LCP PS&R REF: = http://www1.ietf.org/mail-archive/web/geopriv/current/msg02956.html - Requesting LO On-Behalf-Of an endpoint Requested by: B.Stark Supported by: E.Arolik, J.Winterbottom, M.Dawson, J.Grenier, G.Caron Challenged by: B.Rosen, H. Schulzrinne, A.Newton STATUS: Closed from an L7-LCP perspective REF: = http://www1.ietf.org/mail-archive/web/geopriv/current/msg02936.html - Add endpoint Location Assertion function as a requirement Requested by: J.Winterbottom Supported by: M.Dawson, G.Caron Challenged by: A.Newton STATUS: Open (dormant on the list) REF: = http://www1.ietf.org/mail-archive/web/geopriv/current/msg02903.html - Setting preferred loc type (civic/geo) in Location Request Requested by: J.Grenier Supported by: G.Caron Challenged by: None STATUS: Open (dormant on the list) REF: = http://www1.ietf.org/mail-archive/web/geopriv/current/msg02818.html - Add O&M requirements Requested by: D.Romascanu Supported by: None so far Challenged by: None so far STATUS: Open (dormant on the list) REF: = http://www1.ietf.org/mail-archive/web/geopriv/current/msg02829.html Did I miss/misinterpret anything? While I believe most of the above are not so contentious, I'm not sure = the allocated 10 minutes will be sufficient to move those along at the = meeting in Prague. Can we aim at closing the bulk of them on the list = prior to the meeting (if agreeable, please adjust the subject according = to the discussion!)? Would it be possible to add more time to the agenda = for the remaining ones? I must admit that there is *now* a pressing need to have a standard = track L7-LCP as some countries are at the point of implementation = planning. And for the record, I personally support most of the above (hence, added = my name in with this post). Thank you for your understanding. =20 Guy Caron -----Message d'origine----- De=A0: Andrew Newton [mailto:andy@hxr.us]=20 Envoy=E9=A0: 14 mars 2007 13:15 =C0=A0: Caron, Guy (A162859) Cc=A0: geopriv@ietf.org Objet=A0: Re: [Geopriv] Updated meeting agenda Guy, I realize this must seem confusing. We will have an L7-LCP proposal =20 advanced at some point. Today we have 3 proposals, and so we need to =20 figure out how to evaluate them and decide which we want to advance. =20 To do that, we initiated the L7-LCP problem statement and =20 requirements draft, a document that states the requirements we all =20 agree to. Once we agree to the requirements, we can move on to =20 picking a protocol proposal. Unfortunately, we seem to be unable to =20 agree on the requirements. There is a possibility that most of those issue could get cleared up =20 at IETF 68 with notable exception of location signing (which is a =20 very large issue). -andy On Mar 14, 2007, at 11:37 AM, g.caron@bell.ca wrote: > Andrew, Randall and Allison, > > At this point, I would like to know if geopriv will consider =20 > upgrading one (or many) L7-LCP as working group items at IETF #68. > > For some high-speed access providers, this is the only viable =20 > option and frankly, also the preferable approach. > > Thanks, > > Guy Caron > -----Message d'origine----- > De : Andrew Newton [mailto:andy@hxr.us] > Envoy=E9 : 14 mars 2007 07:00 > =C0 : GEOPRIV WG > Objet : [Geopriv] Updated meeting agenda > > All, > > After feedback from the draft agenda and a discussion among the co- > chairs, we have updated the GEOPRIV agenda for IETF 68. > > http://www3.ietf.org/proceedings/07mar/agenda/geopriv.txt > > The biggest change is in item 6, to address the issue now consuming > so many cycles on our mailing list. The intent is to explicitly > list, on the projector screen, the issues with location signing in a > high bandwidth environment so participants may ask for clarifications > of issues. Though we would all prefer to come to resolution on the > issue, this is not likely to happen. The hope is that we can clarify > issues to bring us closer to resolution. > > -andy > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 12:46: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 1HRt6I-0004Y2-VT; Thu, 15 Mar 2007 12:46:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRt6H-0004Xi-RE; Thu, 15 Mar 2007 12:46:49 -0400 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRt6G-0001bO-IM; Thu, 15 Mar 2007 12:46:49 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 51D1C4CFE4; Thu, 15 Mar 2007 17:46:35 +0100 (CET) Date: Thu, 15 Mar 2007 17:46:35 +0100 From: Otmar Lendl To: "Raymond Forbes (CV/ETL)" Subject: Re: [Ecrit] Re: [Geopriv] RE: Strawman Proposal Message-ID: <20070315164634.GB19647@nic.at> Mail-Followup-To: Otmar Lendl , "Raymond Forbes (CV/ETL)" , "Dawson, Martin" , GEOPRIV WG , ecrit@ietf.org References: <0776CCB1-730D-438D-A89D-E92B8B31A917@mah.priv.at> <0074F19FF6F8534E8F74C56BB84397BBB0C61D@esealmw118.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0074F19FF6F8534E8F74C56BB84397BBB0C61D@esealmw118.eemea.ericsson.se> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: GEOPRIV WG , "Dawson, Martin" , ecrit@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org [Unrelated to ecrit/geopriv, but I'm curious.] On 2007/03/14 09:03, "Raymond Forbes (CV/ETL)" wrote: > > In the UK, Eire, Switzerland, and increasingly in other EU countries; > SIM-Less Emergency Calls are forbidden as the Mobile traceability is > mandated by law. In a number of countries like France and Portugal that > did allow SIM-less Emergency calls though not by mandate the laws and > systems now (or soon will) forbid them. The reason for this change is > that the Emergency services were flooded with Anonymous calls from > second hand traders of Mobile handsets. If these anonymous test calls are reason for disabling a possible life-saving feature (emergency calls from SIM-less phones), why didn't the regulator instead force carriers to implement a simple test-number which could be used by those second hand traders without bothering PSAPs? It's not like these traders _want_ to harrass the PSAPs. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 13:34:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRtpp-0003D5-Tb; Thu, 15 Mar 2007 13:33:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRtpo-0003Cn-RS; Thu, 15 Mar 2007 13:33:52 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HRtpX-0002Fk-PP; Thu, 15 Mar 2007 13:33:52 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HRtpM-0007kP-MJ; Thu, 15 Mar 2007 12:33:25 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'GEOPRIV'" , "'ECRIT'" Date: Thu, 15 Mar 2007 13:33:29 -0400 Message-ID: <002201c76728$0ebb09c0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <45F914AE.2060405@gmx.net> Thread-Index: Acdm5knMQsrGGshPT0Oq3ygUQ/zZrgAPXrCQ 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: 287c806b254c6353fcb09ee0e53bbc5e Cc: Subject: [Geopriv] RE: [Ecrit] NENA X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I am the chair of the Long Term Definition Working Group in NENA. We are developing a specification currently entitled "Functional and Interface Requirements for Next Generation 9-1-1 (i3)". The central concept to i3 is the Emergency Services IP Network, which is a managed IP network to which all public safety agencies will be connected. The ESInet, which WILL be connected to the Internet, is the entry point for emergency calls, but it is also used among public safety agencies to exchange calls and data. The above referenced document has a defined scope. That scope is the interface for calls and asynchronous events from access networks (including the Internet), and the 9-1-1 system, coming into the ESInet and things within the ESInet itself. After a transition period, ALL calls and events will enter the ESInet through an i3 defined interface. A succinct definition of that interface is "SIP, with location and call back, routed by LoST". We may support other interfaces (e.g. XMPP). There will be an asynchronous event interface. The scope does not include what happens inside a PSAP, but does include the external interfaces it exposes and uses. The working group is intimately familiar with, and attempts to work with ecrit to make sure that the interface it defines aligns with the work of ecrit. The interface for multimedia calls will be SIP, and should conform to the -framework and -phonebcp documents. The scope of i3 is slightly bigger than the edge of the ESInet, because it includes the "Emergency Call Routing Function" (ECRF) which is the database callers use to route calls to an Emergency Services Routing Proxy (ESRP) which sits at the edge of the ESInet. The ECRF will have a LoST interface. Any carrier who delivers calls via IP to a PSAP in North America, will be required to use the NENA interface, since that is the only interface that will be supported. During transition, other interfaces may be supported, and of course, existing interfaces will be supported for some time during transition. PSAPs presently define their interfaces, and carriers are required to conform to them. That will not change. Carriers don't get to make up their own interface and demand the PSAP conform to that. On the other hand, PSAPs, and NENA, don't get to tell carriers how to build their networks. We only define the interface, and, in this case, supply databases for routing and validation. A draft of the document was liaisoned to a number of SDOs for comments. We are reluctant to put the document on a public website, since it is just a draft, and NENA policies to not permit drafts of its standards to be publicly available. I would have to get the group and NENA's concurrence, but if there are members of ecrit who cannot get the document by another path, I can probably arrange to email it to you. LTD has, on a number of occasions, sent requirements to ecrit. This has been done in the usual informal way, as an email or an Internet Draft submitted by an individual. We discuss ecrit drafts in our meeting, achieve consensus on what we would like to see happen, and delegate individuals to pursue the changes we want. Theresa Reese has recently been fulfilling that role with respect to the LoST drafts. In the NENA division of labor, location for NG9-1-1 is the province of a different working group (the "VoIP Location Working Group"), which has different leadership, but similar style. They mainly deal with geopriv. While a formal liaison relationship with NENA is possible, I don't feel we need one. NENA, like IETF, can do formal liaisons, but the organization is not an SDO, and doesn't really have a great process for liaisons. It would be nice to have a better way to get document drafts to IETF folks. I hope this is a sufficient explanation of NENAs work on IP based interfaces to emergency calls, the scope of its current work in that area, the way it thinks it interacts with IETF, and how it expects its work product to be used. If you have any questions, I would be please to answer them. Brian Rosen Chair Long Term Definition Working Group VoIP/Packet Technical Committee NENA Note: This email is my personal opinion and does not represent any discussions in NENA > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Thursday, March 15, 2007 5:41 AM > To: GEOPRIV; ECRIT > Subject: [Ecrit] NENA > > Hi all, > > I would like to better understand the work done by NENA. > > Which SDOs are going to make use (or is already used) of the work done > by NENA? > > Consider the following SDOs, as an example > - 3GPP > - 3GPP2 > - Wimax > - Wifi Alliance > - DSL Forum > - ETSI TISPAN > - CableLabs > > Since there is often a mismatch between the standards being developed in > these SDOs I would like to also understand how the NENA work going to be > used on the Internet? > > Ciao > Hannes > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 14:17: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 1HRuVt-00073W-L3; Thu, 15 Mar 2007 14:17:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRuVs-00072a-0J for geopriv@ietf.org; Thu, 15 Mar 2007 14:17:20 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRuVH-0001Cl-QG for geopriv@ietf.org; Thu, 15 Mar 2007 14:16:45 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HRuV6-0008Ev-Gn; Thu, 15 Mar 2007 13:16:33 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Ted Hardie'" , "'Andrew Newton'" Subject: RE: [Geopriv] NENA Requirements Date: Thu, 15 Mar 2007 14:16:39 -0400 Message-ID: <003201c7672e$157da1e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Acdl7aTBE2ngC4OKTMigwF2Ee033pQADlOhgAEu3djA= 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: 410b68b37343617c6913e76d02180b14 Cc: 'GEOPRIV' , 'Marc Linsner' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I have pointed out the flaw in the transitive trust model, where the access network carrier vouches for the location of one of its customers. The problem is liability. The access carrier gets to take on the liability of the information being wrong, and gets no value in return. It seems so unlikely to me that we could compel them to do it in a way that makes their liability go away. Imagine the following: an enterprise has a main campus and a satellite campus. It has a T3 or Metro Ethernet service into its main campus, and it has a dark fiber between the main campus and the satellite. Are you going to demand that the T3 carrier serving 123 Main St sign a location for 456 Locust? AT BEST, all the access carrier could do is sign something that says "I have a customer I know as Ajax Manufacturing, and I serve him at 123 Main Street". You can't assert that he is actually Ajax, and you sure won't sign something that says 456 Locust. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Wednesday, March 14, 2007 2:20 AM > To: Ted Hardie; Andrew Newton > Cc: Brian Rosen; GEOPRIV; Marc Linsner > Subject: RE: [Geopriv] NENA Requirements > > Most certainly Ted - thanks for the mutual respect. > > On the enterprise issue and the possibility of using transitive trust - > Yes, I posted a description the other day of how the assertion mechanism > could be used in conjunction with the existing trust relationship > between an Internet carrier and enterprises to minimize the population > of certificate owners. That was the one that does come under the Nortel > IPR that was raised. > > I know I do a lot of posts - the subject was "RE: > [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) > " and it was posted on the 9th of March (though my posts were held up > for about 24 hours for some reason around that day). Rather than paste > it all into this thread, I can send you a copy if you like. > > This situation has a precedent that predates Internet telephony as well. > Large (physically/geographically) enterprises have always had an issue > with the location associated with their outgoing trunk being a coarse > one relative to their actual geographic footprint. In many jurisdictions > - most states of the US even I think - this is just accepted. In some > jurisdictions sufficiently large "establishments" are required to > provide more precise location information - to a given area or number of > floors. This has been a challenge in those jurisdictions and the > solutions used involves a thing called PS-ALI, which is where the > enterprise actually purchases an external database system and can > configure the location associated with things called ELANs which end up > being associated with the outgoing CLI as it is set by the PABX. This is > clearly quite complex and costly - and I would suggest it is more so > than using assertion via a transitive trust relationship on an existing > LIS interface. > > I think jurisdictions could choose between the following with respect to > enterprises: > > * Just use the carrier level location, signed by the provider. As above, > this is if the additional precision doesn't represent a statutory > requirement. > > * Provide a CA program that does cover large enterprises. There's a > strict requirement on enterprises keeping their key information secure. > It becomes part of their identity so it should be subject to much the > same level of regulatory oversight as Sarbanes-Oxley applies to > financial information. That's just IMHO of course. > > * Use a transitive trust mechanism via something like assertion as > described above. It's very much the analog of PS-ALI (which may even be > argued to be prior art - just a thought) but it's a lot more light > weight from an implementation perspective. > > * Something else - and I'm genuinely open to suggestions. > > Between all these options, I think there is something workable for any > given global jurisdiction. I'd prefer an option that supported the > signing of the precise information that an enterprise can determine for > itself. Credentialed location has value beyond emergency services > whatever the jurisdiction requires for that particular application. > > I didn't understand the comment about "...location being so coarse as to > eliminate the perceived value of signing..." Can you elaborate on what > you mean? I didn't understand how a coarse location used for routing > eliminated the tracability. The signature still identifies the source of > the location whatever the precision of the information is. > > You had made the statement > > "... there may be other forms of protection that would achieve the same > goals without the need for entering into the CA business." > > There may be - but I haven't seen a proposal. Hannes suggested that > location by reference might do this, but I countered that a location > obtained that way won't have the same characteristics as a signed > location after all. > > The characteristics desired - that provide the hearty chunks for > discussion are, as I've posted previously, that the location > information: > > * Can be attributed to a recognized source > * Has not been tampered with since generated at that source > * Is applicable to a specific target identity > * Is applicable at a particular point in time > > Can you propose something alternative to KPI to provide this? > > Cheers, > Martin > > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Wednesday, 14 March 2007 3:03 PM > To: Dawson, Martin; Andrew Newton > Cc: Brian Rosen; GEOPRIV; Marc Linsner > Subject: RE: [Geopriv] NENA Requirements > > At 5:55 PM -0500 3/13/07, Dawson, Martin wrote: > >In the case of the former, I accept NENA's word for it that they > understand the problem space and can make a successful judgement with > respect to succeeding. The membership consists of everyone from the > carrier space through to the PSAPs. The constant repetition of the > second point only emphasises that people don't understand how the > credentials can be used. > > At least some of the examples that have been cited as challenges come > from the > enterprise space. Enterprises can and do select to use VoIP, and they > can provide > location to end-users (one original point of the DHCP option work was to > allow > wiremap database information to be transmitted easily to enterprise > customers). > There are many more enterprises than carriers (and there are, at least > if I understand > what you mean by carrier, many more network access providers in > general). > You have restated some complex discussion of the trade-offs as: > > "Certificate management is too complicated - people won't succeed" > > If you aren't planning to extend certificates to everyone who would need > one in > your model, you either won't succeed or you will cause a regulator to > eliminate > a market to achieve your goal. Neither would be, in my estimation, a > good course of > action. If you are going to extend certificates only to transit > upstreams, then you > have to include in your model how the transitive trust works from that > transit > upstream to the entity which provides location (e.g. the enterprise from > its > wiremap) and/or to the customer. Henning has suggested one possibility; > I haven't > considered it carefully yet, but the suggestion points in the right > direction: re-use > existing relationships to get where you need to go, don't try to create > new ones. > I am afraid that this challenges Richard's view, which states that trust > relationships > must persist through this transition, without recognizing that the > parties to the > relationships are increasing exponentially as we move to an > Internet-based > infrastructure. It says instead: build the infrastructure out of the > trust relationships > that are present in the Internet model, rather than trying to cut the > old ones > into the new cloth. > > You've also taken statements about the security trade-offs and filtered > them down to: > "PSAPs answer all the calls anyway so there's no point". Among the > things you > have removed from the soup of discussion were some pretty hearty chunks: > that there may be other forms of protection that would achieve the same > goals > without the need for entering into the CA business; the idea that where > the location > signing proposal is adopted, it would be to inform the calltaker or > manage the > queue, rather than drop the call; and the clear statements that the > kinds of location > which are sufficient for call routing may be the only ones available in > many > circumstances and that these may be so coarse as to eliminate the > perceived value > of the signature even in the case where the signature guarantees that > the call > should go to that psap as it does not provide the traceability aspect > that Henning > notes also came with the previous system. I'm not sure that what's left > is > going to nourish discussion very well. > > We've all been at this for a long time, and some frustration at the pace > of progress > is natural. But if we stop listening to each other entirely, we're not > going to get > faster. I will commit to listening as carefully as I can to the issues > you raise; I > hope you do the same. > > Ted > > > > > >The requirements have been spelt out - and location signing has been > proffered as the solution. The nay-sayers position is that the > requirement should be discounted - they should offer a superior solution > if they have one. > > > >I have never said that the IETF has no experts in the identified fields > - have I? > > > >Cheers, > >Martin > > > > > >From: Andrew Newton [mailto:andy@hxr.us] > >Sent: Wednesday, 14 March 2007 2:32 AM > >To: Dawson, Martin > >Cc: Brian Rosen; Ted Hardie; GEOPRIV; Marc Linsner > >Subject: Re: [Geopriv] NENA Requirements > > > > > >On Mar 13, 2007, at 11:11 AM, Dawson, Martin wrote: > > > > > >NENA are "the experts here" when it comes to requirements. People in > >this working group are trying to say what emergency services policy > >should be and I believe that belongs with NENA for the US and > equivalent > >entities for other jurisdictions. > > > >Martin, > > > >I'm not sure what it is you are attempting to do, but to suggest that > the IETF has no experts in the field of network security or Internet > topology and cannot therefore apply that knowledge is quite simply > wrong. > > > >Location signing has been offered as a requirement. It has been > pointed out that location signing is a solution and not a requirement. > It has also been pointed out that the notion of network topology that is > being applied to VoIP by this solution does not match the way the > Internet works. > > > >Also, it has been fair to question the actual use of location signing > with respect to invalidly signed or unsigned location information. To > date, nobody has offered an authoritative policy... it is all > supposition. It seems rather silly to claim to be the authoritative > voice on this issue when you cannot give concrete policy examples. > > > >-andy > > > > > > > >----------------------------------------------------------------------- > ------------------------- > >This message is for the designated recipient only and may > >contain privileged, proprietary, or otherwise private information. > >If you have received it in error, please notify the sender > >immediately and delete the original. Any unauthorized use of > >this email is prohibited. > >----------------------------------------------------------------------- > ------------------------- > >[mf2] > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 14:18: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 1HRuWv-0007FA-OZ; Thu, 15 Mar 2007 14:18:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRuWu-0007Ep-Ll for geopriv@ietf.org; Thu, 15 Mar 2007 14:18:24 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRuO7-0008Q8-L8 for geopriv@ietf.org; Thu, 15 Mar 2007 14:09:22 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HRuNu-0006Ik-9N; Thu, 15 Mar 2007 13:09:06 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Dawson, Martin'" , "'Andrew Newton'" Subject: RE: [Geopriv] NENA Requirements Date: Thu, 15 Mar 2007 14:09:13 -0400 Message-ID: <002c01c7672d$0b6312e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Acdl7aj644uZfpgXTzSbRMNhe2P3cABOr+3Q 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: 97c820c82c68af374c4e382a80dc5017 Cc: 'GEOPRIV' , 'Marc Linsner' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I've been trying to figure out where to insert my thoughts on this issue, this is as good a place as any. I think that the problem we are trying to solve is diversion of resources, and I think Henning's classification (lone hacker remote, lone hacker local, and organized DDoS) is about right. It is true that we tend to focus on the solutions more than the problems, and it is true that we look at the loss of a reasonably secured location source as the problem, rather than a symptom. That being said, I do think that the advantage of focusing on the location is a more tractable solution because they are always local, whereas the call network is often not. We can reasonably expect to be able to develop trust relationships between entities that are local to one another more than we can reasonably expect entities that are quite diffuse, and have no other reasons to interact in ways which would allow trust relationships to be formed. I also think there is a pretty substantive difference between a lie of the form "I am Joe Blow" and one of the form "I am at 123 Main St". In the end, we really don't care who you are, and we really do care where you are. I do recognize that enterprise is the largest problem for developing trust relationships, because there are so many of them. This is indeed the challenge. It's also true that at least for the foreseeable future, there will be many more enterprises with their own location infrastructure than enterprises with their own path to introduce calls to the emergency calling system, rather than using a carrier. I have pointed out before that with a little work, we can exploit an existing "validation" mechanism and extend it to validation of credentials for enterprise. Every enterprise receives, approximately yearly in most jurisdictions, a physical visit from someone in the public safety community. It's a "fire marshal" in the U.S. They make a physical inspection of the facility. If, among the fire marshal's duties on such visits, there was a call to a test number from any phone, we could validate credentials. This level of validation exceeds nearly every form of PKI that has been fielded. You have an actual visit by a person to the facility and s/he verifies that the credential's identification information is valid ("Yep, I am in Ajax Manufacturing, and it does report its address as 123 Main St"). Brian > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Wednesday, March 14, 2007 12:03 AM > To: Dawson, Martin; Andrew Newton > Cc: Brian Rosen; GEOPRIV; Marc Linsner > Subject: RE: [Geopriv] NENA Requirements > > At 5:55 PM -0500 3/13/07, Dawson, Martin wrote: > >In the case of the former, I accept NENA's word for it that they > understand the problem space and can make a successful judgement with > respect to succeeding. The membership consists of everyone from the > carrier space through to the PSAPs. The constant repetition of the second > point only emphasises that people don't understand how the credentials can > be used. > > At least some of the examples that have been cited as challenges come from > the > enterprise space. Enterprises can and do select to use VoIP, and they can > provide > location to end-users (one original point of the DHCP option work was to > allow > wiremap database information to be transmitted easily to enterprise > customers). > There are many more enterprises than carriers (and there are, at least if > I understand > what you mean by carrier, many more network access providers in general). > You have restated some complex discussion of the trade-offs as: > > "Certificate management is too complicated - people won't succeed" > > If you aren't planning to extend certificates to everyone who would need > one in > your model, you either won't succeed or you will cause a regulator to > eliminate > a market to achieve your goal. Neither would be, in my estimation, a good > course of > action. If you are going to extend certificates only to transit > upstreams, then you > have to include in your model how the transitive trust works from that > transit > upstream to the entity which provides location (e.g. the enterprise from > its > wiremap) and/or to the customer. Henning has suggested one possibility; I > haven't > considered it carefully yet, but the suggestion points in the right > direction: re-use > existing relationships to get where you need to go, don't try to create > new ones. > I am afraid that this challenges Richard's view, which states that trust > relationships > must persist through this transition, without recognizing that the parties > to the > relationships are increasing exponentially as we move to an Internet-based > infrastructure. It says instead: build the infrastructure out of the > trust relationships > that are present in the Internet model, rather than trying to cut the old > ones > into the new cloth. > > You've also taken statements about the security trade-offs and filtered > them down to: > "PSAPs answer all the calls anyway so there's no point". Among the things > you > have removed from the soup of discussion were some pretty hearty chunks: > that there may be other forms of protection that would achieve the same > goals > without the need for entering into the CA business; the idea that where > the location > signing proposal is adopted, it would be to inform the calltaker or manage > the > queue, rather than drop the call; and the clear statements that the kinds > of location > which are sufficient for call routing may be the only ones available in > many > circumstances and that these may be so coarse as to eliminate the > perceived value > of the signature even in the case where the signature guarantees that the > call > should go to that psap as it does not provide the traceability aspect that > Henning > notes also came with the previous system. I'm not sure that what's left > is > going to nourish discussion very well. > > We've all been at this for a long time, and some frustration at the pace > of progress > is natural. But if we stop listening to each other entirely, we're not > going to get > faster. I will commit to listening as carefully as I can to the issues > you raise; I > hope you do the same. > > Ted > > > > > >The requirements have been spelt out - and location signing has been > proffered as the solution. The nay-sayers position is that the requirement > should be discounted - they should offer a superior solution if they have > one. > > > >I have never said that the IETF has no experts in the identified fields - > have I? > > > >Cheers, > >Martin > > > > > >From: Andrew Newton [mailto:andy@hxr.us] > >Sent: Wednesday, 14 March 2007 2:32 AM > >To: Dawson, Martin > >Cc: Brian Rosen; Ted Hardie; GEOPRIV; Marc Linsner > >Subject: Re: [Geopriv] NENA Requirements > > > > > >On Mar 13, 2007, at 11:11 AM, Dawson, Martin wrote: > > > > > >NENA are "the experts here" when it comes to requirements. People in > >this working group are trying to say what emergency services policy > >should be and I believe that belongs with NENA for the US and equivalent > >entities for other jurisdictions. > > > >Martin, > > > >I'm not sure what it is you are attempting to do, but to suggest that the > IETF has no experts in the field of network security or Internet topology > and cannot therefore apply that knowledge is quite simply wrong. > > > >Location signing has been offered as a requirement. It has been pointed > out that location signing is a solution and not a requirement. It has > also been pointed out that the notion of network topology that is being > applied to VoIP by this solution does not match the way the Internet > works. > > > >Also, it has been fair to question the actual use of location signing > with respect to invalidly signed or unsigned location information. To > date, nobody has offered an authoritative policy... it is all supposition. > It seems rather silly to claim to be the authoritative voice on this issue > when you cannot give concrete policy examples. > > > >-andy > > > > > > > >------------------------------------------------------------------------- > ----------------------- > >This message is for the designated recipient only and may > >contain privileged, proprietary, or otherwise private information. > >If you have received it in error, please notify the sender > >immediately and delete the original. Any unauthorized use of > >this email is prohibited. > >------------------------------------------------------------------------- > ----------------------- > >[mf2] _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 14:35:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRumz-00023W-Tx; Thu, 15 Mar 2007 14:35:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRumy-00021p-Jh for geopriv@ietf.org; Thu, 15 Mar 2007 14:35:00 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRumu-0005Dt-E0 for geopriv@ietf.org; Thu, 15 Mar 2007 14:35:00 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 15 Mar 2007 11:34:56 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l2FIYt8Q003111; Thu, 15 Mar 2007 11:34:55 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2FIYqAO005066; Thu, 15 Mar 2007 18:34:55 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 14:34:48 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 14:34:47 -0400 From: "Marc Linsner" To: "'Brian Rosen'" Subject: RE: [Geopriv] NENA Requirements Date: Thu, 15 Mar 2007 14:34:46 -0400 Message-ID: <00dc01c76730$9be2ed60$230d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acdl7aj644uZfpgXTzSbRMNhe2P3cABOr+3QAAFkKXA= In-Reply-To: <002c01c7672d$0b6312e0$640fa8c0@cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 15 Mar 2007 18:34:47.0498 (UTC) FILETIME=[9BE5FAA0:01C76730] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3303; t=1173983695; x=1174847695; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20NENA=20Requirements |Sender:=20; bh=DBpHTcWfNfJoDJXo1gT6nmIdg/v4nOR+YwgIlNub8/Q=; b=tks1oaLu1kXNSQsopICaxgAx4MbU3BYhCAF6oG4QJjst6ONkwplNlfIbNsg3NKL675Xp+fDW YKcSNeLoyk0+xexah7nuyHML+ejbMTpxnn2QOl3RTlK9GyIw7rZGjoKM; Authentication-Results: sj-dkim-8; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Brian, At this point in the process, we need consensus on the requirement. I'm not the chair, but I haven't seen it. > > I've been trying to figure out where to insert my thoughts on > this issue, this is as good a place as any. > > I think that the problem we are trying to solve is diversion > of resources, We need to stop here and see if everyone agrees this is the requirement? and I think Henning's classification (lone > hacker remote, lone hacker local, and organized DDoS) is > about right. These are architectures by which the above requirement can be rendered broken. Is there consensus that this is inclusive? I think additional mitigating factors deserve consideration (and agreement) like (non-inclusive): No assumption there will be regulation forcing compliance. No assumption that regulation can enforce compliance. It is true that we tend to focus on the > solutions more than the problems, and it is true that we look > at the loss of a reasonably secured location source as the > problem, rather than a symptom. Nice words for a segway to your next step. Now, your following words are in the solution space. Premature to talk about until consensus on the above. > > That being said, I do think that the advantage of focusing on > the location is a more tractable solution because they are > always local, whereas the call network is often not. We can > reasonably expect to be able to develop trust relationships > between entities that are local to one another more than we > can reasonably expect entities that are quite diffuse, and > have no other reasons to interact in ways which would allow > trust relationships to be formed. > > I also think there is a pretty substantive difference between > a lie of the form "I am Joe Blow" and one of the form "I am > at 123 Main St". In the end, we really don't care who you > are, and we really do care where you are. > > I do recognize that enterprise is the largest problem for > developing trust relationships, because there are so many of > them. This is indeed the challenge. It's also true that at > least for the foreseeable future, there will be many more > enterprises with their own location infrastructure than > enterprises with their own path to introduce calls to the > emergency calling system, rather than using a carrier. > > I have pointed out before that with a little work, we can > exploit an existing "validation" mechanism and extend it to > validation of credentials for enterprise. Every enterprise > receives, approximately yearly in most jurisdictions, a > physical visit from someone in the public safety community. > It's a "fire marshal" in the U.S. They make a physical > inspection of the facility. If, among the fire marshal's > duties on such visits, there was a call to a test number from > any phone, we could validate credentials. This level of > validation exceeds nearly every form of PKI that has been fielded. > You have an actual visit by a person to the facility and s/he > verifies that the credential's identification information is > valid ("Yep, I am in Ajax Manufacturing, and it does report > its address as 123 Main St"). > > Brian -Marc- _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 14:50:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRv26-0002zV-4R; Thu, 15 Mar 2007 14:50:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRv24-0002xx-C3 for geopriv@ietf.org; Thu, 15 Mar 2007 14:50:36 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRv23-0007Cq-1w for geopriv@ietf.org; Thu, 15 Mar 2007 14:50:36 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2FIoTj2021224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 15 Mar 2007 14:50:34 -0400 (EDT) In-Reply-To: <002c01c7672d$0b6312e0$640fa8c0@cis.neustar.com> References: <002c01c7672d$0b6312e0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B5D7423-9288-4738-83FA-4E037277F01E@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] NENA Requirements Date: Thu, 15 Mar 2007 14:50:30 -0400 To: "Brian Rosen" 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: a2c12dacc0736f14d6b540e805505a86 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Brian, I probably didn't make this clear enough before, but I believe that the two assertions (identity and location) are complementary, in that, very roughly, in any particular circumstance, one tends to be easy and the other harder. I also believe that, together with coarse- grain location assertion that does not require cryptography, that this offers a mechanism that offers "as good as today" protection, which seems to be the rough yard stick of success. For residential (DSL/cable/FTTH) users, location signing is probably workable, as long as the big residential network providers play along. I'm not convinced that street-address-level signing is going to happen immediately, simply because of the difficulties of connecting pieces of equipments, such as DHCP servers and DSLAMs, to OA&M systems that know about wire locations. Even if the DSL Forum specifies how to do this, equipment won't get replaced overnight and OA&M systems seem to be particularly resistant to change, judging from the integration difficulties experienced during carrier mergers. (Rumor has it that MCI collapsed partially because of these problems, once the accounting tricks could no longer mask these failures.) For the same residential users, they will likely use commercial VSPs, usually within the same country, such as SunRocket and Vonage, as well as ISP-provided offerings such as FiOS. Again, identity assertion is relatively easy and mostly reliable. The number of providers that serve 90%+ of the customers is also modest. For larger enterprises, the problem is the opposite: identity assertion is easy and the enterprise is local to the PSAP, but location signing requires all kinds of acrobatics, as other mechanisms (such as LLDP-MED) are far more natural than multiple identifier mappings and hierarchical trust delegation. Yes, there are VPNs, but the number of people placing emergency calls through their corporate VPN while using some Sierra Leonian VSP is likely to be so small that it can easily be part of the unavoidable "needs special care" category. Enterprises also already have TLS certificates or can easily get them. No new national PKI needed here. Also, as I pointed out, location assertion, however good, does not prevent or mitigate many of the lone hacker cases that actually predominate today. One thing missing, I think, is an overall "performance" goal. Perfection isn't in the cards, and, as with everything, the last 0.1% cost the most. I think the goal should be that some large fraction (pick 95% or 99% or any other reasonable number) of legitimate calls should be recognizable, by either traceable identity or location or preferably both. After all, this is what we do today, given that a large fraction of cell phones don't have assured fine-grained location reaching the PSAP. As a side note, I would find it extremely useful if NENA could provide information on the rough relative frequency of the different types of crank calls. Most of this is driven by human behavior (and alcohol...), not technology, after all. Henning On Mar 15, 2007, at 2:09 PM, Brian Rosen wrote: > > I think that the problem we are trying to solve is diversion of > resources, > and I think Henning's classification (lone hacker remote, lone > hacker local, > and organized DDoS) is about right. It is true that we tend to > focus on the > solutions more than the problems, and it is true that we look at > the loss of > a reasonably secured location source as the problem, rather than a > symptom. > > That being said, I do think that the advantage of focusing on the > location > is a more tractable solution because they are always local, whereas > the call > network is often not. We can reasonably expect to be able to > develop trust > relationships between entities that are local to one another more > than we > can reasonably expect entities that are quite diffuse, and have no > other > reasons to interact in ways which would allow trust relationships > to be > formed. > > I also think there is a pretty substantive difference between a lie > of the > form "I am Joe Blow" and one of the form "I am at 123 Main St". In > the end, > we really don't care who you are, and we really do care where you are. > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 15:33: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 1HRvhA-0007Xw-DV; Thu, 15 Mar 2007 15:33:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRvh8-0007Xj-LD; Thu, 15 Mar 2007 15:33:02 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRvgh-0006Xt-3p; Thu, 15 Mar 2007 15:33:02 -0400 Received: from [172.28.172.102] ([::ffff:12.172.52.10]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 15 Mar 2007 15:29:10 -0400 id 01588370.45F99E87.00001B39 In-Reply-To: <002201c76728$0ebb09c0$640fa8c0@cis.neustar.com> References: <002201c76728$0ebb09c0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Message-Id: <0B003BCE-0BA4-485D-8F9A-D397698BC516@hxr.us> From: Andrew Newton Subject: Re: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 15:30:59 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: 'GEOPRIV' , 'ECRIT' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0907225544==" Errors-To: geopriv-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0907225544== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-6975-1173986965-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-6975-1173986965-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Mar 15, 2007, at 1:33 PM, Brian Rosen wrote: > While a formal liaison relationship with NENA is possible, I don't > feel we > need one. NENA, like IETF, can do formal liaisons, but the > organization is > not an SDO, and doesn't really have a great process for liaisons. > It would > be nice to have a better way to get document drafts to IETF folks. Brian, The IETF has liaison relationships with organizations that are not typically classified as SDOs. ICANN is a big example. I would also disagree about NENA not being an SDO, as they appear to be publishing standards in the context of these conversations. The standards may not be typical technical wire protocol specifications, but requirements can also be standards. I just had a conversation with Roger Hixson about the possibility of a formal liaison, and he believes it to be appropriate. -andy --=_zeke.ecotroph.net-6975-1173986965-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.54.2
On Mar 15, 2007, at 1:3= 3 PM, Brian Rosen wrote:

While a fo= rmal liaison relationship with NENA is possible, I don't feel we
need one.=A0 NENA, like IETF, can do formal liaisons, but = the organization is

n= ot an SDO, and doesn't really have a great process for liaisons.=A0 It would

be nice to have a better way to get document = drafts to IETF folks.

Brian,
=

The IETF has liaiso= n relationships with organizations that are not typically classified as S= DOs.=A0 ICANN is a big example.=A0 I would also disagree about NENA not b= eing an SDO, as they appear to be publishing standards in the context of = these conversations.=A0 The standards may not be typical technical wire p= rotocol specifications, but requirements can also be standards.=A0 I just = had a conversation with Roger Hixson about the possibility of a formal li= aison, and he believes it to be appropriate.

-andy
--=_zeke.ecotroph.net-6975-1173986965-0001-2-- --===============0907225544== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0907225544==-- From geopriv-bounces@ietf.org Thu Mar 15 15:42:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRvpk-0004xG-Pc; Thu, 15 Mar 2007 15:41:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRvpj-0004wD-0i; Thu, 15 Mar 2007 15:41:55 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRvpg-00007Q-FY; Thu, 15 Mar 2007 15:41:54 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HRvpU-0001DA-0f; Thu, 15 Mar 2007 14:41:40 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 15:41:47 -0400 Message-ID: <006301c76739$fa4c7520$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <0B003BCE-0BA4-485D-8F9A-D397698BC516@hxr.us> Thread-Index: AcdnOKD77ncrsVtUSbeMTYI5uEuZtQAAMYqQ 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: 07e9b4af03a165a413ec6e4d37ae537b Cc: 'GEOPRIV' , 'ECRIT' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0369450428==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============0369450428== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01C76718.733AD520" This is a multi-part message in MIME format. ------=_NextPart_000_0064_01C76718.733AD520 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Okay, just so you know what you are asking for. For my group to send an email to the ecrit or geopriv list, we discuss it in a conference call, we MAY (but often don't) pass around a draft, and we designate some one to send it. To get a liaison out, we fill out a form, hold a semi-official vote, send it to the "tech lead team", which includes Roger. They approve it, and then Roger sends it. So far, the average time to get through that process is between one and three months, although everyone agrees that is ridiculous, and we should be able to get it down to a couple of weeks. So sure, we can have a formal liaison if you want one. Brian _____ From: Andrew Newton [mailto:andy@hxr.us] Sent: Thursday, March 15, 2007 3:31 PM To: Brian Rosen Cc: 'Hannes Tschofenig'; 'GEOPRIV'; 'ECRIT' Subject: Re: [Geopriv] RE: [Ecrit] NENA On Mar 15, 2007, at 1:33 PM, Brian Rosen wrote: While a formal liaison relationship with NENA is possible, I don't feel we need one. NENA, like IETF, can do formal liaisons, but the organization is not an SDO, and doesn't really have a great process for liaisons. It would be nice to have a better way to get document drafts to IETF folks. Brian, The IETF has liaison relationships with organizations that are not typically classified as SDOs. ICANN is a big example. I would also disagree about NENA not being an SDO, as they appear to be publishing standards in the context of these conversations. The standards may not be typical technical wire protocol specifications, but requirements can also be standards. I just had a conversation with Roger Hixson about the possibility of a formal liaison, and he believes it to be appropriate. -andy ------=_NextPart_000_0064_01C76718.733AD520 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Okay, just so you know what you are = asking for.

For my group to send an email to = the ecrit or geopriv list, we discuss it in a conference call, we MAY (but often = don’t) pass around a draft, and we designate some one to send = it.

To get a liaison out, we fill out a = form, hold a semi-official vote, send it to the “tech lead team”, = which includes Roger. They approve it, and then Roger sends it. So = far, the average time to get through that process is between one and three = months, although everyone agrees that is ridiculous, and we should be able to = get it down to a couple of weeks.

So sure, we can have a formal = liaison if you want one.

Brian

From: = Andrew Newton [mailto:andy@hxr.us]
Sent: Thursday, March 15, = 2007 3:31 PM
To: Brian Rosen
Cc: 'Hannes Tschofenig'; 'GEOPRIV'; 'ECRIT'
Subject: Re: [Geopriv] = RE: [Ecrit] NENA

On Mar 15, 2007, at 1:33 PM, Brian Rosen = wrote:

While a formal liaison relationship with NENA is possible, I don't feel = we

need one. NENA, like IETF, can do formal = liaisons, but the organization is

not an SDO, and doesn't = really have a great process for liaisons. = It would

be nice to have a better = way to get document drafts to IETF folks.

Brian,

The IETF has liaison relationships with organizations that are = not typically classified as SDOs. ICANN is a big example. I would also = disagree about NENA not being an SDO, as they appear to be publishing standards = in the context of these conversations. The standards may not be typical = technical wire protocol specifications, but requirements can also be standards. I just = had a conversation with Roger Hixson about the possibility of a formal = liaison, and he believes it to be appropriate.

-andy

------=_NextPart_000_0064_01C76718.733AD520-- --===============0369450428== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0369450428==-- From geopriv-bounces@ietf.org Thu Mar 15 15:56: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 1HRw3H-0007V2-UC; Thu, 15 Mar 2007 15:55:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRw3H-0007Ut-16 for geopriv@ietf.org; Thu, 15 Mar 2007 15:55:55 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRw3E-0002rD-Ad for geopriv@ietf.org; Thu, 15 Mar 2007 15:55:55 -0400 Received: from ([139.76.131.31]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.18290915; Thu, 15 Mar 2007 15:55:21 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 15 Mar 2007 15:55:22 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 15 Mar 2007 15:55:21 -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: [Geopriv] RE: Strawman Proposal Date: Thu, 15 Mar 2007 15:55:19 -0400 Importance: normal Priority: normal Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA031B2E41@crexc41p> In-Reply-To: <45F84845.2000101@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: Strawman Proposal Thread-Index: AcdmbGB2kHyCopx/Q1efW9V+QBomkgAswHtA References: <45F7ACC3.4010000@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA031B29FF@crexc41p> <45F84845.2000101@gmx.net> From: "Stark, Barbara" To: "Hannes Tschofenig" X-OriginalArrivalTime: 15 Mar 2007 19:55:21.0737 (UTC) FILETIME=[DD544F90:01C7673B] X-Spam-Score: 0.1 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: GEOPRIV , "Dawson, Martin" , Marc Linsner , Henning Schulzrinne X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Comments inline. Barbara=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Wednesday, March 14, 2007 3:09 PM To: Stark, Barbara Cc: GEOPRIV; Dawson, Martin; Marc Linsner; Henning Schulzrinne Subject: Re: [Geopriv] RE: Strawman Proposal Hi Barbara, thanks for your input. Please find a few responses below: Stark, Barbara wrote: >> It seems that IMS actually makes that assumption - using the=20 >> traditional "roaming partner" model that assumes the voice service=20 >> *is* the access service. >> =20 > > Just as an aside, please be careful as to whose view of IMS you're=20 > referring to. While this may be the view of 3GPP, where GSM is an=20 > integral part of IMS, it is not the view of telcos who are actually=20 > implementing IMS. The view of telcos is that GSM is just another=20 > access technology. In this telco view, connectivity to the IMS core=20 > will generally occur over the public Internet, and there is absolutely > no correlation between access provider and IMS provider in that case. > =20 With this view of IMS their emergency service architecture does not work. [BHS] Agreed. I don't think telco implementations expect to use the 3GPP-defined emergency service architecture. I think they will use ATIS to fully define the emergency service architecture, and I think it would use the work done by NENA and IETF (ecrit and geopriv). That's why it's important not associate all IMS with 3GPP and GSM. They are NOT synonymous. > --------- > Also, while requiring SIMS will take care of authentication in a cell=20 > phone world, it does nothing about people who launch point-to-point=20 > SIP calls. Given the architecture we're creating, it will be very=20 > simple for someone with a simple SIP client to create a PIDF-LO, do a=20 > LoST sos query, and make a call over the Internet to the result of=20 > that query, without ever touching a VSP. That's true. The problem is only that the 3GPP has not specified a protocol for the end host to retrieve location information. Hence, it would be difficult for the client to create a PIDF-LO (unless it is equipped with a GPS device). [BHS] Sorry I wasn't clear -- I wasn't referring to SIP over cellular networks. I was referring to SIP phones on generic broadband connections. > The access network will not be in a > position to screen such calls, and (from what I've seen) there would=20 > probably be a public outcry if people were actually required to have a > "real" VSP, before making a SIP call. > =20 I don't understand this sentence. [BHS] Again, I'm referring to generic broadband access networks. My reading of the state of VoIP today is that there exists a number of people who want to use SIP as it was originally designed -- a point-to-point protocol, without all these intermediary softswitches, feature servers, etc. They can be very vocal when threatened. When it just takes a uri to get to the PSAP, it will be simple, when connected to a generic Internet connection, to send a SIP invite directly to the PSAP, without being registered with any VSP. For an access or backbone provider to try to prevent this (unless there's a regulatory mandate to do so) would go completely against all "net neutrality" attempts. > If the PSAP wants to refuse to accept such calls, then that will be a=20 > national/jurisdictional decision. > =20 I agree. > Then again, there are VSPs that offer free calling over the Internet,=20 > that don't really care about the identities of their users, and would=20 > have difficulty tracking these users if pressed to do so. That's not true. Even with free calling over the Internet almost all VSP require some form of authentication. The same is true with email providers today. Some require a quite strong assurance that you are indeed the person you claim to be. Obviously it would be possible to create a legal framework around this for emergency services (as we assume it with everything else as well). [BHS] Unfortunately, it's fairly impossible for the US to create a legal framework for VSPs in the Bahamas or Nigeria or elsewhere. If we start requiring trust of VSPs and their processes, then countries will only be able to trust VSPs that they can regulate, either directly or by treaty. Which breaks the utopian model that we're aiming for, of anyone from any country being able to take his phone anywhere in the world and trusting that it can make an emergency call. I think your email example is perfect -- considering the volume of spam I get, I'd say it's pretty easy to set up your own email domain and server and send whatever email you like. > There can be > fly-by-night VSPs (it's not really that hard to create your own VSP=20 > for your own use, and set it up in a hotel room somewhere), and there=20 > can be VSPs in countries with lax laws. VSPs, as a generalization, are > just as trustworthy as end users. > =20 That might be true. > Which means that the PSAP who wants to really restrict calls to those=20 > that are properly "authenticated", would have to only accept calls=20 > from VSPs that they know they can trust. Which is a very limiting=20 > proposition, and I don't think that's where we want to go. > =20 You have just described the SPIT problem, btw. Why do you think it would be better to * use signed location information (if you also claim that operators don't want to distribute location information to the end hosts), and * resolving a location-by-reference is only allowed by authorized entities [BHS] I really don't know what the right answer is, or that there's a single right answer. I think we're going to see a variety of solutions attempted, in different jurisdictions and different countries. So long as they don't try to put country specific requirements on the SIP endpoint, I think that will be ok. We need to make sure the protocols give the countries the ability to try a variety of solutions, to see what works best (i.e., don't design the protocol to preclude a potential solution). > If PSAPs are permitted to do a LbyR lookup related to the IP address, > then the attacker will at least have to be able to pretend to be at that > IP address (through something physical at that IP address, or that can > intercept all traffic to that IP address, and not simple spoofing). This > is definitely a critical capability, though it's not perfect.=20 > =20 I don't understand what that means? How does a LbyR lookup based on the=20 IP address work? I thought we said that the lookup would work by using=20 the HTTPS or SIPS URI. The IP address that is seen by the PSAP will not be the IP address of=20 the end host in most cases anyway since there are so many tunneling,=20 NAT, VPN, mobility solutions out there that you just block something. [BHS] Yes, there exist cases where lookup by IP address won't help. It's just another part of the overall toolkit. The question on the uri, is how is it formed, in the case of OBO or LIS-LIS (assuming LbyR is used for these)? The uri is not provided by the end device in these cases -- the uri must use a well-known format that includes the "identity" of the device whose location is requested.=20 > I don't think that signatures needs to be a part of an LCP (I agree that > it's distinct from the protocol), What does that mean? I thought that the idea was to use the LCP to=20 request a signed LO. [BHS] The LCP must be able to carry a signed PIDF-LO. But the LCP doesn't have to know that the PIDF-LO it is carrying is signed, or not, or what the mechanism is for signing. The LCP has to support assertion. Personally, I'm not sure of the value of having endpoints request signing. The LIS will know whether local PSAPs require signed location -- the endpoint will be clueless. A LIS in a PSAP jurisdiction where signing is required should always sign, according to local rules. A LIS that doesn't need to sign, probably won't even support the ability. But I can understand that there may be usefulness in having the request supported in the LCP, and it's not difficult to do. So I support providing the ability to request signing. > but I think it would be useful to have > a standard means defined for signing PIDF-LOs. With SIP Location Conveyance you already have a way todo so, although it is not really useful since you have to resolve the reference via TLS and the signed PIDF-LO would just do the same thing essentially twice -- my=20 HTTPS/S-HTTP description applies. > I also think that the LCP > needs to support location assertion for the purpose of getting a PIDF-LO > signed, This statement does not align nicely with the previous sentence. > in the event that a jurisdiction or country wants to go that > route. Assertion is also useful as a means of providing a presence > server with a GPS-calculated location. > =20 But in this case you would really want to use an S/MIME signed PIDF-LO. Ciao Hannes > Barbara > > > ***** > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 > > =20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv ***** 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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 16:13:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRwKM-0004CJ-UW; Thu, 15 Mar 2007 16:13:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRwKM-0004C4-3Z for geopriv@ietf.org; Thu, 15 Mar 2007 16:13:34 -0400 Received: from bellwecs4.bellnexxia.net ([207.236.237.116] helo=bellwecs4.srvr.bell.ca) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRwKF-00069Z-Dk for geopriv@ietf.org; Thu, 15 Mar 2007 16:13:34 -0400 Received: (qmail 20989 invoked from network); 15 Mar 2007 20:13:17 -0000 Received: from jerome.grenier@bell.ca by bellwecs4.srvr.bell.ca with EntrustECS-Server-7.4; 15 Mar 2007 20:13:17 -0000 Received: from bellwfep2.bellnexxia.net (HELO bellwfep2-srv.bellnexxia.net) (207.236.237.108) by bellwecs4.srvr.bell.ca with SMTP; 15 Mar 2007 20:13:17 -0000 Received: from TOROONDC908.bell.corp.bce.ca ([142.182.89.88]) by bellwfep2-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20070315201317.XOGE1671.bellwfep2-srv.bellnexxia.net@TOROONDC908.bell.corp.bce.ca>; Thu, 15 Mar 2007 16:13:17 -0400 Received: from toroondc912.bell.corp.bce.ca ([142.182.89.15]) by TOROONDC908.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 16:13:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] Making decisions at Prague.... Date: Thu, 15 Mar 2007 16:13:14 -0400 Message-ID: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A258706@toroondc912> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Making decisions at Prague.... Thread-Index: Acdmv4PR7bED2773S1WL8UoOPNW5xgAZfYRA References: From: To: , , X-OriginalArrivalTime: 15 Mar 2007 20:13:16.0053 (UTC) FILETIME=[5DABEC50:01C7673E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Ted, About user-control, network-control and the emergency context, I think a = few points are worth considering: - RFC-3693 allows for a jurisdiction (local, national or otherwise) to = share the role of the Rule Maker and therefore, to contribute explicit = Privacy Rules for some involved Location Servers (those under his = jurisdiction, for example) to be applied when providing a Location = Object to a Location Recipient (which obviously could include the = jurisdiction itself). - In the context of emergency calls or other life-threatening = situations, some jurisdictions allow for the emergency services provider = to use whatever (relevant) private/sensitive information they have at = their disposal, such as the caller's identity and location, to assist = the person in danger and this, without explicit consent of the caller. = This is the case for Canada. - Some emergency providers, as Guy and others mentioned, are about to = implement support for emergency calls on VoIP within their = jurisdictions. The reality is that not all emergency VoIP callers will = have access to a "location-capable" VoIP device in the short term. = Therefore, it is envisioned that in a transition phase, emergency = providers could acquire the VoIP caller's location on their behalf = (which is certainly not without its challenges). This is in line with = the jurisdictions I just described above, but might not be suitable for = other jurisdictions. - Some emergency providers (and their associated PSAPs) might want to be = able to distinguish a true location from a prank one and therefore might = want to restrict location forgery. In my opinion, these observations are not necessarily in opposition with = preserving user control, as the user totally controls that his location = information and maybe his identity are being used in a life- (probably = his own) threatening situation. HELD happens to address this emergency = context very well. This situation is very real and some have to deal = with it now. However, as I understand it, HELD is not restricted to this particular = use case as it also applies to the "location-capable" endpoint model. = That is, where the user has explicit and direct control over the = distribution of his location. I hope this helped expose some subtleties of the user-control versus = network-control perspective. J=E9r=F4me -----Message d'origine----- De=A0: Ted Hardie [mailto:hardie@qualcomm.com]=20 Envoy=E9=A0: 15 mars 2007 01:05 =C0=A0: Moore, Lyn E; geopriv@ietf.org Objet=A0: Re: [Geopriv] Making decisions at Prague.... > >1. The IETF is here to specify protocols. Not to conduct faction = fighting. No standard protocol for location acquisition has been = produced after 1 year of chit-chat and, sometimes, personal abuse = between GeoPriv members. This is highly unprofessional behaviour. I don't think anyone would disagree that the situation has brought out = more vitriol than is healthy, and I hope that those of us in Prague can find ways to = move past that.=20 You should realize, though, whatever your length of observation, that both sides in this feel pushed. The GeoPRIV working group was = chartered a fair amount of time ago with a strong focus on the privacy aspects of location; the acronym doesn't appear in the working group's name by accident. It has produced a number of RFCs which specify the management and distribution of location objects and the presence-based architecture is actually very strongly coupled to SIP's idea of presence (and = therefore to the IETF's idea of a VoIP infrastructure). Not just in relation to L7, but in relation to Radius, DHCP, and other = protocols, the IETF has struggled with how to handle the tension between the = provision of location objects (and their privacy characteristics) and the = provision of the location information necessary to build those objects. Despite = the fact that location information has many of the same privacy concerns, = the working group has agreed in the past to allow the privacy concerns to = take second fiddle where the deployment argued for a location provisioning mechanism that could not easily carry the full location object. But it = did so with a serious amount of concern that the location information was protected to the extent possible, and with trepidation that this was = sending the wrong message to the community about how best to protect the privacy of the user's location. Jon Peterson said some prescient (and = dire) things to me on this topic when the DHCP draft was approved by the IESG; I happen to think that we would have had other problems without that draft, but he was clearly right that the message it sent has in some = ways overwhelmed the original focus of GeoPRIV. HELD appears to have a very different view of the privacy = characteristics of location, and it seems to come from a point of view that does not see the user control inherent in the presence infrastructure as critical to the overall system. Read again this introduction to = held-identify-extensions: A basic premise in HELD is that the source IP address of the location request message can be used by the LIS to identify the requesting Target, and that this identity can be used with other contextual network information to provide a physical location for the Target. In many network deployments this premise holds true, but in some network deployments additional identifiers are required to identify the Target at different points throughout the network, or they may assist with speeding up location determination. The base HELD schema was designed with extensibility in mind and the assumption that IP address may not always be enought to identify a Target. The HELD identity extensions schema is made up of a number of discrete element blocks that can included into the HELD locationRequest, createContext and updateContext messages. These elements can then be used by the LIS to identify the Target closer to the edge of the network, for example a MAC address or DHCP client- identifier, or to identify an element that has a closer relationship with the target, for example LLDP switch and port information. The identity extension elements have been desgined to work across a range of existing and emerging technologies. It is envisaged that while this schema is not exhaustive, it will address many of the perceived deployment solution. It is further envisaged that extensions to this schema will be necessary as new identifiers are created or required. The kind of identity binding these discuss are very serious ties of user identity to location, and are exactly the kind of thing that GeoPRIV started out to protect. As you read any of the HELD documents, you get a strong sense that the aim is to use the location information model rather than the location object model throughout (though there are = syntactic similarities with the location object model). That's a very basic difference of assumption--about the role of the network, the user, and the location.=20 The use of emergency services as a driving use case for this has caused many conversations along the lines of "but we throw out the usual rules to get the best information we can to a PSAP". But it is very = different to start from the assumption that the user is in control of the = distribution of their location and relax specific rules when you need to get the job done versus starting from the assumption that the network is in control = of the distribution of the user's location and whatever user identity it has. Many of the point arguments we have had in the past week, it seems to me, go back to that difference of assumptions. We argue about simless phones and specific regulatory mandates, when the real tension is far deeper. That is why your statement below, which implies putting forward a single system for emergency calling and general use, concerns me. I think if you started from the basic geopriv assumptions and moved from there, what you would end up there would be reasonably good (and you could do that today using signed location objects, presence, and SIP). If you start from where James and Martin seem to start from, I believe you will end up with a location information system that has little to no user control; that has to concern me. You ask if the Andrew folks haven't got their politics right. First, we do try to treat folks as individuals rather than by corporate affiliation here, but I assume you mean Martin and James. If you mean, are they not buying the right folks beer or horse-trading favors, then = no, that's not the problem. The problem is their work appears to ignore the chartered goal of the working group. They argue (at times very convincingly) that the goals of the working group are incompatible with specific deployments, specific aims like emergency calling, or the fiscal realities of presuming that large networks will deploy expensive equipment to get this when that equipment's usual use is covered elsewhere. I am sure they are deeply frustrated by what can easily look like a willingness to ignore those realities. I can assure you that folks don't want to ignore them (though they may want demonstrations they are true). They want to understand if there are ways to meet the goals of the group *GeoPRIV* in those contexts. If not starting from the chartered goals of the working group isn't getting their politics right, then yes, that is a problem. That's just my opinion on the tension, obviously, and Martin, James and I already plan to sit down in Prague. Possibly they will there convince me that I have the wrong end of the stick. I hope, though, that the end goals remain the same: that we are working toward a system that continues to recognize that "while the formatting and transfer of = such information (location) is in some sense a straightforward process, the implications = of doing it, especially in regards to privacy and security, are anything but." and = that continues to value the user's privacy and control--even if it must under some circumstances put other goals like emergency service higher. Just my two cents, regards, Ted Hardie _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 16:23: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 1HRwTs-0004jS-KZ; Thu, 15 Mar 2007 16:23:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRwTs-0004jN-17 for geopriv@ietf.org; Thu, 15 Mar 2007 16:23:24 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRwTp-0007qx-Co for geopriv@ietf.org; Thu, 15 Mar 2007 16:23:24 -0400 X-SEF-Processed: 5_0_0_910__2007_03_15_15_29_20 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, 15 Mar 2007 15:29:20 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 15:23:19 -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: [Geopriv] NENA Requirements Date: Thu, 15 Mar 2007 15:23:18 -0500 Message-ID: In-Reply-To: <003201c7672e$157da1e0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] NENA Requirements Thread-Index: Acdl7aTBE2ngC4OKTMigwF2Ee033pQADlOhgAEu3djAABNpWcA== From: "Dawson, Martin" To: "Brian Rosen" , "Ted Hardie" , "Andrew Newton" X-OriginalArrivalTime: 15 Mar 2007 20:23:19.0976 (UTC) FILETIME=[C5A34280:01C7673F] X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: GEOPRIV , Marc Linsner X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org The question of liability goes to the regulatory environment of the=0D=0Aju= risdiction. PS-ALI is actually the same - the enterprise is not the=0D=0APS= -ALI operator and, yet, the PS-ALI operator is who provides the=0D=0Alocati= on information used for the call but they are not subject to=0D=0Aliability= =2E=0D=0A=0D=0AIn practice, the carrier will have a query record associated= with the=0D=0Arequest - and that will include the specific random client i= dentifier=0D=0Aassociated with the request and the time corresponding to th= e call.=0D=0AThey'll be able to point directly at the source of the locatio= n=0D=0Aassertion request and show what their assertion test rules were. It'= s a=0D=0Apretty strong non-repudiation arrangement.=0D=0A=0D=0AI think ther= e are plenty of environments in which transitive trust can=0D=0Abe used wit= hout liability being the impediment. Perhaps in others it=0D=0Acan't be. It= 's just another candidate for dealing with the enterprise=0D=0Acertificatio= n issue. I also like your description of how existing=0D=0A"audit" requirem= ents associated with local emergency authority can=0D=0Aunderpin a process = that permits enterprises to have their own=0D=0Acertificates.=0D=0A=0D=0AWe= 've both said in the past that the good thing about location is that=0D=0At= he source of location information, by definition, should be in the=0D=0Ageo= graphical area of concern of the emergency authority that deals with=0D=0At= hem. The emergency call center is able to understand what certification=0D=0A= process is applicable in their area. It's even possible, in the US, for=0D=0A= some call centers to understand certificates that are issued and=0D=0Arecog= nisable at a county level while other PSAPs expect location=0D=0Aproviders = to carry a nationally recognized certificate.=0D=0A=0D=0ACheers,=0D=0AMarti= n=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Brian Rosen [mailto:br@b= rianrosen.net]=20=0D=0ASent: Friday, 16 March 2007 5:17 AM=0D=0ATo: Dawson,= Martin; 'Ted Hardie'; 'Andrew Newton'=0D=0ACc: 'GEOPRIV'; 'Marc Linsner'=0D= =0ASubject: RE: [Geopriv] NENA Requirements=0D=0A=0D=0AI have pointed out t= he flaw in the transitive trust model, where the=0D=0Aaccess=0D=0Anetwork c= arrier vouches for the location of one of its customers. The=0D=0Aproblem = is liability. The access carrier gets to take on the liability=0D=0Aof=0D=0A= the information being wrong, and gets no value in return. It seems so=0D=0A= unlikely to me that we could compel them to do it in a way that makes=0D=0A= their=0D=0Aliability go away. =20=0D=0A=0D=0AImagine the following: an ente= rprise has a main campus and a satellite=0D=0Acampus. It has a T3 or Metro= Ethernet service into its main campus, and=0D=0Ait=0D=0Ahas a dark fiber b= etween the main campus and the satellite. Are you=0D=0Agoing=0D=0Ato deman= d that the T3 carrier serving 123 Main St sign a location for=0D=0A456=0D=0A= Locust=3F AT BEST, all the access carrier could do is sign something that=0D= =0Asays "I have a customer I know as Ajax Manufacturing, and I serve him at=0D= =0A123=0D=0AMain Street". You can't assert that he is actually Ajax, and y= ou sure=0D=0Awon't=0D=0Asign something that says 456 Locust.=0D=0A=0D=0ABri= an=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Dawson, Martin [mai= lto:Martin.Dawson@andrew.com]=0D=0A> Sent: Wednesday, March 14, 2007 2:20 A= M=0D=0A> To: Ted Hardie; Andrew Newton=0D=0A> Cc: Brian Rosen; GEOPRIV; Mar= c Linsner=0D=0A> Subject: RE: [Geopriv] NENA Requirements=0D=0A>=20=0D=0A> = Most certainly Ted - thanks for the mutual respect.=0D=0A>=20=0D=0A> On the= enterprise issue and the possibility of using transitive trust=0D=0A-=0D=0A= > Yes, I posted a description the other day of how the assertion=0D=0Amecha= nism=0D=0A> could be used in conjunction with the existing trust relationsh= ip=0D=0A> between an Internet carrier and enterprises to minimize the popul= ation=0D=0A> of certificate owners. That was the one that does come under t= he=0D=0ANortel=0D=0A> IPR that was raised.=0D=0A>=20=0D=0A> I know I do a l= ot of posts - the subject was "RE:=0D=0A>=0D=0A[Geopriv]WGLCondraft-ietf-ge= opriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)=0D=0A> " and it was posted on = the 9th of March (though my posts were held up=0D=0A> for about 24 hours fo= r some reason around that day). Rather than paste=0D=0A> it all into this t= hread, I can send you a copy if you like.=0D=0A>=20=0D=0A> This situation h= as a precedent that predates Internet telephony as=0D=0Awell.=0D=0A> Large = (physically/geographically) enterprises have always had an issue=0D=0A> wit= h the location associated with their outgoing trunk being a coarse=0D=0A> o= ne relative to their actual geographic footprint. In many=0D=0Ajurisdiction= s=0D=0A> - most states of the US even I think - this is just accepted. In s= ome=0D=0A> jurisdictions sufficiently large "establishments" are required t= o=0D=0A> provide more precise location information - to a given area or num= ber=0D=0Aof=0D=0A> floors. This has been a challenge in those jurisdictions= and the=0D=0A> solutions used involves a thing called PS-ALI, which is whe= re the=0D=0A> enterprise actually purchases an external database system and= can=0D=0A> configure the location associated with things called ELANs whic= h end=0D=0Aup=0D=0A> being associated with the outgoing CLI as it is set by= the PABX. This=0D=0Ais=0D=0A> clearly quite complex and costly - and I wou= ld suggest it is more so=0D=0A> than using assertion via a transitive trust= relationship on an=0D=0Aexisting=0D=0A> LIS interface.=0D=0A>=20=0D=0A> I = think jurisdictions could choose between the following with respect=0D=0Ato=0D= =0A> enterprises:=0D=0A>=20=0D=0A> * Just use the carrier level location, s= igned by the provider. As=0D=0Aabove,=0D=0A> this is if the additional prec= ision doesn't represent a statutory=0D=0A> requirement.=0D=0A>=20=0D=0A> * = Provide a CA program that does cover large enterprises. There's a=0D=0A> st= rict requirement on enterprises keeping their key information=0D=0Asecure.=0D= =0A> It becomes part of their identity so it should be subject to much the=0D= =0A> same level of regulatory oversight as Sarbanes-Oxley applies to=0D=0A>= financial information. That's just IMHO of course.=0D=0A>=20=0D=0A> * Use = a transitive trust mechanism via something like assertion as=0D=0A> describ= ed above. It's very much the analog of PS-ALI (which may even=0D=0Abe=0D=0A= > argued to be prior art - just a thought) but it's a lot more light=0D=0A>= weight from an implementation perspective.=0D=0A>=20=0D=0A> * Something el= se - and I'm genuinely open to suggestions.=0D=0A>=20=0D=0A> Between all th= ese options, I think there is something workable for any=0D=0A> given globa= l jurisdiction. I'd prefer an option that supported the=0D=0A> signing of t= he precise information that an enterprise can determine=0D=0Afor=0D=0A> its= elf. Credentialed location has value beyond emergency services=0D=0A> whate= ver the jurisdiction requires for that particular application.=0D=0A>=20=0D= =0A> I didn't understand the comment about "...location being so coarse as=0D= =0Ato=0D=0A> eliminate the perceived value of signing..." Can you elaborate= on what=0D=0A> you mean=3F I didn't understand how a coarse location used = for routing=0D=0A> eliminated the tracability. The signature still identifi= es the source=0D=0Aof=0D=0A> the location whatever the precision of the inf= ormation is.=0D=0A>=20=0D=0A> You had made the statement=0D=0A>=20=0D=0A> "= =2E.. there may be other forms of protection that would achieve the=0D=0Asa= me=0D=0A> goals without the need for entering into the CA business."=0D=0A>= =20=0D=0A> There may be - but I haven't seen a proposal. Hannes suggested t= hat=0D=0A> location by reference might do this, but I countered that a loca= tion=0D=0A> obtained that way won't have the same characteristics as a sign= ed=0D=0A> location after all.=0D=0A>=20=0D=0A> The characteristics desired = - that provide the hearty chunks for=0D=0A> discussion are, as I've posted = previously, that the location=0D=0A> information:=0D=0A>=20=0D=0A> * Can be= attributed to a recognized source=0D=0A> * Has not been tampered with sinc= e generated at that source=0D=0A> * Is applicable to a specific target iden= tity=0D=0A> * Is applicable at a particular point in time=0D=0A>=20=0D=0A> = Can you propose something alternative to KPI to provide this=3F=0D=0A>=20=0D= =0A> Cheers,=0D=0A> Martin=0D=0A>=20=0D=0A> -----Original Message-----=0D=0A= > From: Ted Hardie [mailto:hardie@qualcomm.com]=0D=0A> Sent: Wednesday, 14 = March 2007 3:03 PM=0D=0A> To: Dawson, Martin; Andrew Newton=0D=0A> Cc: Bria= n Rosen; GEOPRIV; Marc Linsner=0D=0A> Subject: RE: [Geopriv] NENA Requireme= nts=0D=0A>=20=0D=0A> At 5:55 PM -0500 3/13/07, Dawson, Martin wrote:=0D=0A>= >In the case of the former, I accept NENA's word for it that they=0D=0A> u= nderstand the problem space and can make a successful judgement with=0D=0A>= respect to succeeding. The membership consists of everyone from the=0D=0A>= carrier space through to the PSAPs. The constant repetition of the=0D=0A> = second point only emphasises that people don't understand how the=0D=0A> cr= edentials can be used.=0D=0A>=20=0D=0A> At least some of the examples that = have been cited as challenges come=0D=0A> from the=0D=0A> enterprise space.= Enterprises can and do select to use VoIP, and they=0D=0A> can provide=0D= =0A> location to end-users (one original point of the DHCP option work was=0D= =0Ato=0D=0A> allow=0D=0A> wiremap database information to be transmitted ea= sily to enterprise=0D=0A> customers).=0D=0A> There are many more enterprise= s than carriers (and there are, at least=0D=0A> if I understand=0D=0A> what= you mean by carrier, many more network access providers in=0D=0A> general)= =2E=0D=0A> You have restated some complex discussion of the trade-offs as:=0D= =0A>=20=0D=0A> "Certificate management is too complicated - people won't su= cceed"=0D=0A>=20=0D=0A> If you aren't planning to extend certificates to ev= eryone who would=0D=0Aneed=0D=0A> one in=0D=0A> your model, you either won'= t succeed or you will cause a regulator to=0D=0A> eliminate=0D=0A> a market= to achieve your goal. Neither would be, in my estimation, a=0D=0A> good c= ourse of=0D=0A> action. If you are going to extend certificates only to tr= ansit=0D=0A> upstreams, then you=0D=0A> have to include in your model how t= he transitive trust works from that=0D=0A> transit=0D=0A> upstream to the e= ntity which provides location (e.g. the enterprise=0D=0Afrom=0D=0A> its=0D=0A= > wiremap) and/or to the customer. Henning has suggested one=0D=0Apossibil= ity;=0D=0A> I haven't=0D=0A> considered it carefully yet, but the suggestio= n points in the right=0D=0A> direction: re-use=0D=0A> existing relationshi= ps to get where you need to go, don't try to=0D=0Acreate=0D=0A> new ones.=0D= =0A> I am afraid that this challenges Richard's view, which states that=0D=0A= trust=0D=0A> relationships=0D=0A> must persist through this transition, wit= hout recognizing that the=0D=0A> parties to the=0D=0A> relationships are in= creasing exponentially as we move to an=0D=0A> Internet-based=0D=0A> infras= tructure. It says instead: build the infrastructure out of the=0D=0A> trus= t relationships=0D=0A> that are present in the Internet model, rather than = trying to cut the=0D=0A> old ones=0D=0A> into the new cloth.=0D=0A>=20=0D=0A= > You've also taken statements about the security trade-offs and=0D=0Afilte= red=0D=0A> them down to:=0D=0A> "PSAPs answer all the calls anyway so there= 's no point". Among the=0D=0A> things you=0D=0A> have removed from the sou= p of discussion were some pretty hearty=0D=0Achunks:=0D=0A> that there may = be other forms of protection that would achieve the=0D=0Asame=0D=0A> goals=0D= =0A> without the need for entering into the CA business; the idea that=0D=0A= where=0D=0A> the location=0D=0A> signing proposal is adopted, it would be t= o inform the calltaker or=0D=0A> manage the=0D=0A> queue, rather than drop = the call; and the clear statements that the=0D=0A> kinds of location=0D=0A>= which are sufficient for call routing may be the only ones available=0D=0A= in=0D=0A> many=0D=0A> circumstances and that these may be so coarse as to e= liminate the=0D=0A> perceived value=0D=0A> of the signature even in the cas= e where the signature guarantees that=0D=0A> the call=0D=0A> should go to t= hat psap as it does not provide the traceability aspect=0D=0A> that Henning=0D= =0A> notes also came with the previous system. I'm not sure that what's=0D= =0Aleft=0D=0A> is=0D=0A> going to nourish discussion very well.=0D=0A>=20=0D= =0A> We've all been at this for a long time, and some frustration at the=0D= =0Apace=0D=0A> of progress=0D=0A> is natural. But if we stop listening to = each other entirely, we're=0D=0Anot=0D=0A> going to get=0D=0A> faster. I w= ill commit to listening as carefully as I can to the=0D=0Aissues=0D=0A> you= raise; I=0D=0A> hope you do the same.=0D=0A>=20=0D=0A> =09=09=09=09Ted=0D=0A= >=20=0D=0A>=20=0D=0A> >=0D=0A> >The requirements have been spelt out - and = location signing has been=0D=0A> proffered as the solution. The nay-sayers = position is that the=0D=0A> requirement should be discounted - they should = offer a superior=0D=0Asolution=0D=0A> if they have one.=0D=0A> >=0D=0A> >I = have never said that the IETF has no experts in the identified=0D=0Afields=0D= =0A> - have I=3F=0D=0A> >=0D=0A> >Cheers,=0D=0A> >Martin=0D=0A> >=0D=0A> >=0D= =0A> >From: Andrew Newton [mailto:andy@hxr.us]=0D=0A> >Sent: Wednesday, 14 = March 2007 2:32 AM=0D=0A> >To: Dawson, Martin=0D=0A> >Cc: Brian Rosen; Ted = Hardie; GEOPRIV; Marc Linsner=0D=0A> >Subject: Re: [Geopriv] NENA Requireme= nts=0D=0A> >=0D=0A> >=0D=0A> >On Mar 13, 2007, at 11:11 AM, Dawson, Martin = wrote:=0D=0A> >=0D=0A> >=0D=0A> >NENA are "the experts here" when it comes = to requirements. People in=0D=0A> >this working group are trying to say wha= t emergency services policy=0D=0A> >should be and I believe that belongs wi= th NENA for the US and=0D=0A> equivalent=0D=0A> >entities for other jurisdi= ctions.=0D=0A> >=0D=0A> >Martin,=0D=0A> >=0D=0A> >I'm not sure what it is y= ou are attempting to do, but to suggest that=0D=0A> the IETF has no experts= in the field of network security or Internet=0D=0A> topology and cannot th= erefore apply that knowledge is quite simply=0D=0A> wrong.=0D=0A> >=0D=0A> = >Location signing has been offered as a requirement. It has been=0D=0A> po= inted out that location signing is a solution and not a requirement.=0D=0A>= It has also been pointed out that the notion of network topology that=0D=0A= is=0D=0A> being applied to VoIP by this solution does not match the way the=0D= =0A> Internet works.=0D=0A> >=0D=0A> >Also, it has been fair to question th= e actual use of location signing=0D=0A> with respect to invalidly signed or= unsigned location information. To=0D=0A> date, nobody has offered an auth= oritative policy... it is all=0D=0A> supposition. It seems rather silly to= claim to be the authoritative=0D=0A> voice on this issue when you cannot g= ive concrete policy examples.=0D=0A> >=0D=0A> >-andy=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, proprieta= ry, or otherwise private information.=0D=0A> >If you have received it in er= ror, please notify the sender=0D=0A> >immediately and delete the original. = Any unauthorized use of=0D=0A> >this email is prohibited.=0D=0A>=0D=0A>---= --------------------------------------------------------------------=0D=0A>= -------------------------=0D=0A> >[mf2]=0D=0A>=20=0D=0A>=20=0D=0A>=0D=0A--= ----------------------------------------------------------------------=0D=0A= --=0D=0A> ----------------------=0D=0A> This message is for the designated = recipient only and may=0D=0A> contain privileged, proprietary, or otherwise= private information.=0D=0A> If you have received it in error, please notif= y the sender=0D=0A> immediately and delete the original. Any unauthorized = use of=0D=0A> this email is prohibited.=0D=0A>=0D=0A-----------------------= -------------------------------------------------=0D=0A--=0D=0A> ----------= ------------=0D=0A> [mf2]=0D=0A=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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 18:17:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRyFj-0001Yw-A8; Thu, 15 Mar 2007 18:16:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRyEk-0001F3-Er for geopriv@ietf.org; Thu, 15 Mar 2007 18:15:54 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRy8T-0001nq-65 for geopriv@ietf.org; Thu, 15 Mar 2007 18:09:26 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 15 Mar 2007 15:09:24 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l2FM9OfR007949; Thu, 15 Mar 2007 15:09:24 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2FM9OZT008168; Thu, 15 Mar 2007 22:09:24 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 18:09:24 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 18:09:23 -0400 From: "Marc Linsner" To: "'Stark, Barbara'" Subject: RE: [Geopriv] RE: Strawman Proposal Date: Thu, 15 Mar 2007 18:09:22 -0400 Message-ID: <012101c7674e$969cffd0$230d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcdmD7w1vtgSDxZ1SwSqlHeP53zm3gAQazsQAD5FEeA= In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA031B29FF@crexc41p> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 15 Mar 2007 22:09:23.0453 (UTC) FILETIME=[9690CAD0:01C7674E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1708; t=1173996564; x=1174860564; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20RE=3A=20Strawman=20Proposal |Sender:=20; bh=to4ysamfeWcDC8g8ULdz0PD6+hTq7igsCioMPScZ0EE=; b=Hk5LLs8FAXU75mBNAHETmosMJJY2OOfKOYnsImrUBjPEpVEmhgTURkGyYpVmz816cn3JZHyF CBsmFsJnxDpv4lHZCP3ZfeO6FvYMoakFgS7S18HU2JXVIFCFVgCBIT9F; Authentication-Results: sj-dkim-4; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: 'GEOPRIV' , 'Henning Schulzrinne' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Barbara, > > If PSAPs are permitted to do a LbyR lookup related to the IP > address, then the attacker will at least have to be able to > pretend to be at that IP address (through something physical > at that IP address, or that can intercept all traffic to that > IP address, and not simple spoofing). This is definitely a > critical capability, though it's not perfect. The only issue that bothers me with this is tying it to IP address. It appears you share some of my concerns with using IP address as an identifier, nats, vpns, IN-ADDR.ARPA issues, etc. I had recently proposed to Brian that the provided-by in the pidf-lo become a LbyR uri. Something along the line of pres:123456abefc987@accessprovider.net. Admittedly, a pidf-lo that contained such a provided-by uri could be 'stolen' by a bot or something similar. But a bot could also launch a sip call setup from an unsuspecting/infected endpoint. So regardless if the PSAP use the source IP address as the identifier or the provided-by LbyR uri, the PSAP *could* be spoofed. I don't think attackers have a preferred method, so one provides no more deterrence than the other. What if during dereferencing of my proposed LbyR-in-the-provided-by element the IP address that the LIS knew the end-point residing at was in a NET-LOC pidf-lo element. Hence the NET-LOC element would become 192.168.0.1. This would allow the PSAP to trigger one additional flag, matching source IP with NET-LOC, although nats/vpns could trigger a false positive. I think the LbyR-in-the-provided-by element mechanism provides like functionality with less machinery. More analysis required. -Marc- _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 15 22:43: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 1HS2Pa-0007vO-AP; Thu, 15 Mar 2007 22:43:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS2PY-0007vC-UG for geopriv@ietf.org; Thu, 15 Mar 2007 22:43:20 -0400 Received: from mailipao.vtcif.telstra.com.au ([202.12.144.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HS2PU-0002hz-Mn for geopriv@ietf.org; Thu, 15 Mar 2007 22:43:20 -0400 Received: from webi.vtcif.telstra.com.au (HELO mailbi.vtcif.telstra.com.au) ([202.12.142.19]) by mailipao.vtcif.telstra.com.au with ESMTP; 16 Mar 2007 13:43:10 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id 7C0191DA84; Fri, 16 Mar 2007 13:43:09 +1100 (EST) Received: from wsmsg2952.srv.dir.telstra.com (wsmsg2952.srv.dir.telstra.com [192.74.195.51]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 035E241DF6; Fri, 16 Mar 2007 13:43:08 +1100 (EST) Received: from WSMSG2153V.srv.dir.telstra.com ([192.74.195.21]) by wsmsg2952.srv.dir.telstra.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Mar 2007 13:43:08 +1100 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: [Geopriv] Making decisions at Prague.... Date: Fri, 16 Mar 2007 13:43:07 +1100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Making decisions at Prague.... Thread-Index: Acdmv4RuWHLMiZo9Q7eeOcollGZc8QAsmnzQ References: From: "Moore, Lyn E" To: "Ted Hardie" , X-OriginalArrivalTime: 16 Mar 2007 02:43:08.0862 (UTC) FILETIME=[D4DF4DE0:01C76774] X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Thanks for your reply Ted (and others) At least I now have some idea to the underlying source of your differences in opinion. Detailed technical discussion can easily submerge the reasoning behind issues. I am pleased to see that those who replied to my intentional bombastic email(sorry for that - I was trying to make you all see how your discussions could be interpreted) provided sound reasoning for me to consider further. =20 Good Luck in Prague Cheers Lyn -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com]=20 Sent: Thursday, 15 March 2007 4:05 PM To: Moore, Lyn E; geopriv@ietf.org Subject: Re: [Geopriv] Making decisions at Prague.... > >1. The IETF is here to specify protocols. Not to conduct faction fighting. No standard protocol for location acquisition has been produced after 1 year of chit-chat and, sometimes, personal abuse between GeoPriv members. This is highly unprofessional behaviour. I don't think anyone would disagree that the situation has brought out more vitriol than is healthy, and I hope that those of us in Prague can find ways to move past that.=20 You should realize, though, whatever your length of observation, that both sides in this feel pushed. The GeoPRIV working group was chartered a fair amount of time ago with a strong focus on the privacy aspects of location; the acronym doesn't appear in the working group's name by accident. It has produced a number of RFCs which specify the management and distribution of location objects and the presence-based architecture is actually very strongly coupled to SIP's idea of presence (and therefore to the IETF's idea of a VoIP infrastructure). Not just in relation to L7, but in relation to Radius, DHCP, and other protocols, the IETF has struggled with how to handle the tension between the provision of location objects (and their privacy characteristics) and the provision of the location information necessary to build those objects. Despite the fact that location information has many of the same privacy concerns, the working group has agreed in the past to allow the privacy concerns to take second fiddle where the deployment argued for a location provisioning mechanism that could not easily carry the full location object. But it did so with a serious amount of concern that the location information was protected to the extent possible, and with trepidation that this was sending the wrong message to the community about how best to protect the privacy of the user's location. Jon Peterson said some prescient (and dire) things to me on this topic when the DHCP draft was approved by the IESG; I happen to think that we would have had other problems without that draft, but he was clearly right that the message it sent has in some ways overwhelmed the original focus of GeoPRIV. HELD appears to have a very different view of the privacy characteristics of location, and it seems to come from a point of view that does not see the user control inherent in the presence infrastructure as critical to the overall system. Read again this introduction to held-identify-extensions: A basic premise in HELD is that the source IP address of the location request message can be used by the LIS to identify the requesting Target, and that this identity can be used with other contextual network information to provide a physical location for the Target. In many network deployments this premise holds true, but in some network deployments additional identifiers are required to identify the Target at different points throughout the network, or they may assist with speeding up location determination. The base HELD schema was designed with extensibility in mind and the assumption that IP address may not always be enought to identify a Target. The HELD identity extensions schema is made up of a number of discrete element blocks that can included into the HELD locationRequest, createContext and updateContext messages. These elements can then be used by the LIS to identify the Target closer to the edge of the network, for example a MAC address or DHCP client- identifier, or to identify an element that has a closer relationship with the target, for example LLDP switch and port information. The identity extension elements have been desgined to work across a range of existing and emerging technologies. It is envisaged that while this schema is not exhaustive, it will address many of the perceived deployment solution. It is further envisaged that extensions to this schema will be necessary as new identifiers are created or required. The kind of identity binding these discuss are very serious ties of user identity to location, and are exactly the kind of thing that GeoPRIV started out to protect. As you read any of the HELD documents, you get a strong sense that the aim is to use the location information model rather than the location object model throughout (though there are syntactic similarities with the location object model). That's a very basic difference of assumption--about the role of the network, the user, and the location.=20 The use of emergency services as a driving use case for this has caused many conversations along the lines of "but we throw out the usual rules to get the best information we can to a PSAP". But it is very different to start from the assumption that the user is in control of the distribution of their location and relax specific rules when you need to get the job done versus starting from the assumption that the network is in control of the distribution of the user's location and whatever user identity it has. Many of the point arguments we have had in the past week, it seems to me, go back to that difference of assumptions. We argue about simless phones and specific regulatory mandates, when the real tension is far deeper. That is why your statement below, which implies putting forward a single system for emergency calling and general use, concerns me. I think if you started from the basic geopriv assumptions and moved from there, what you would end up there would be reasonably good (and you could do that today using signed location objects, presence, and SIP). If you start from where James and Martin seem to start from, I believe you will end up with a location information system that has little to no user control; that has to concern me. You ask if the Andrew folks haven't got their politics right. First, we do try to treat folks as individuals rather than by corporate affiliation here, but I assume you mean Martin and James. If you mean, are they not buying the right folks beer or horse-trading favors, then no, that's not the problem. The problem is their work appears to ignore the chartered goal of the working group. They argue (at times very convincingly) that the goals of the working group are incompatible with specific deployments, specific aims like emergency calling, or the fiscal realities of presuming that large networks will deploy expensive equipment to get this when that equipment's usual use is covered elsewhere. I am sure they are deeply frustrated by what can easily look like a willingness to ignore those realities. I can assure you that folks don't want to ignore them (though they may want demonstrations they are true). They want to understand if there are ways to meet the goals of the group *GeoPRIV* in those contexts. If not starting from the chartered goals of the working group isn't getting their politics right, then yes, that is a problem. That's just my opinion on the tension, obviously, and Martin, James and I already plan to sit down in Prague. Possibly they will there convince me that I have the wrong end of the stick. I hope, though, that the end goals remain the same: that we are working toward a system that continues to recognize that "while the formatting and transfer of such information (location) is in some sense a straightforward process, the implications of doing it, especially in regards to privacy and security, are anything but." and that continues to value the user's privacy and control--even if it must under some circumstances put other goals like emergency service higher. Just my two cents, regards, Ted Hardie _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 16 07:24: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 1HSAXM-0005xI-TX; Fri, 16 Mar 2007 07:23:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSAXL-0005x4-4A for geopriv@ietf.org; Fri, 16 Mar 2007 07:23:55 -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 1HSAXJ-0002tW-S4 for geopriv@ietf.org; Fri, 16 Mar 2007 07:23:55 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 16 Mar 2007 07:20:16 -0400 id 0158C55F.45FA7D72.00002C46 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: GEOPRIV WG From: Andrew Newton Date: Fri, 16 Mar 2007 07:23:27 -0400 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Geopriv] review comments on draft-thomson-geopriv-lis-discovery-00.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org http://www.ietf.org/internet-drafts/draft-thomson-geopriv-lis- discovery-00.txt Overall, I like this draft very much, and favor its adoption by this working group. I appreciate James and Martin taking the time to separate out the LIS discovery mechanisms from their candidate proposal, HELD. One of the issues I think this working group has is that many people feel that to accept HELD or RELO or etc, they have to take the bad with the good. This draft separates the issue of LIS discovery so that this good idea of HELD may be applied to other protocols. Such ideas enable compromise and progression of good ideas. My comments: 1) The term LIS needs to be defined in the terminology section, especially since there is a reference to RFC 3693 where the terms LS and Target are defined. This might also help clarify the scope of the work and reduce some of the heartburn the security folks my have. 2) The introduction may want to expand upon #1 a little more by specifying the scope of the work to the application of L7-LCP enabled LIS environments. In other words, if you are already getting your LI from DHCP or LLDP-MED, this is not applicable. 3) Remove the registration for HELD to make this totally protocol neutral. Instead, note that whatever protocols do use this must create an IANA registration for U-NAPTR. 4) Specify the order of the discovery methods. Predictability is a good thing. I suggest this order: 1)DHCP, 2) U-NAPTR via configured domain (either static or dynamic), and 3) U-NAPTR via reverse IP. That's just a strawman proposal, but I think the methods do need to be ordered. 5) Create an appendix with examples. Examples always help. 6) There needs to be some text around how a client would query its location over DHCP vs. querying the LIS location over DHCP. In other words, explain how a client uses both. See #2. 7) Pat yourselves on the back for a job well done. -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 16 10:49:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSDjz-00070r-NJ; Fri, 16 Mar 2007 10:49:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSDjy-00070i-Ba for geopriv@ietf.org; Fri, 16 Mar 2007 10:49:10 -0400 Received: from mail.opengeospatial.org ([208.44.53.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSDjg-0000Mi-E8 for geopriv@ietf.org; Fri, 16 Mar 2007 10:49:10 -0400 Received: from SusieandCarl (c-67-174-113-243.hsd1.co.comcast.net [67.174.113.243]) (authenticated bits=0) by mail.opengeospatial.org (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l2GEmg0H030099 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 16 Mar 2007 10:48:43 -0400 Message-ID: <00f501c767da$324d59d0$6401a8c0@SusieandCarl> From: "Carl Reed OGC Account" To: "GEOPRIV WG" , "Andrew Newton" References: Subject: Re: [Geopriv] review comments ondraft-thomson-geopriv-lis-discovery-00.txt Date: Fri, 16 Mar 2007 08:48:06 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Status: No, score=-96.0 required=5.0 tests=BAYES_50, RCVD_IN_NJABL_DUL, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, USER_IN_WHITELIST autolearn=disabled version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on mail.opengeospatial.org X-Virus-Scanned: ClamAV 0.90.1/2850/Fri Mar 16 07:05:03 2007 on mail.opengeospatial.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I agree with Andy's suggestion that LIS needs to be properly defined. LIS is an acronym that has been used in the cadastral and GIS communities for decades. Stands for Land Information System. Cheers Carl ----- Original Message ----- From: "Andrew Newton" To: "GEOPRIV WG" Sent: Friday, March 16, 2007 5:23 AM Subject: [Geopriv] review comments ondraft-thomson-geopriv-lis-discovery-00.txt > http://www.ietf.org/internet-drafts/draft-thomson-geopriv-lis- > discovery-00.txt > > Overall, I like this draft very much, and favor its adoption by this > working group. I appreciate James and Martin taking the time to separate > out the LIS discovery mechanisms from their candidate proposal, HELD. > One of the issues I think this working group has is that many people feel > that to accept HELD or RELO or etc, they have to take the bad with the > good. This draft separates the issue of LIS discovery so that this good > idea of HELD may be applied to other protocols. Such ideas enable > compromise and progression of good ideas. > > My comments: > > 1) The term LIS needs to be defined in the terminology section, > especially since there is a reference to RFC 3693 where the terms LS and > Target are defined. This might also help clarify the scope of the work > and reduce some of the heartburn the security folks my have. > > 2) The introduction may want to expand upon #1 a little more by > specifying the scope of the work to the application of L7-LCP enabled LIS > environments. In other words, if you are already getting your LI from > DHCP or LLDP-MED, this is not applicable. > > 3) Remove the registration for HELD to make this totally protocol > neutral. Instead, note that whatever protocols do use this must create > an IANA registration for U-NAPTR. > > 4) Specify the order of the discovery methods. Predictability is a good > thing. I suggest this order: 1)DHCP, 2) U-NAPTR via configured domain > (either static or dynamic), and 3) U-NAPTR via reverse IP. That's just a > strawman proposal, but I think the methods do need to be ordered. > > 5) Create an appendix with examples. Examples always help. > > 6) There needs to be some text around how a client would query its > location over DHCP vs. querying the LIS location over DHCP. In other > words, explain how a client uses both. See #2. > > 7) Pat yourselves on the back for a job well done. > > -andy > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Mar 16 10:56: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 1HSDrQ-0002mI-Uh; Fri, 16 Mar 2007 10:56:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSDrP-0002m8-2M; Fri, 16 Mar 2007 10:56:51 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSDrJ-0001lC-SS; Fri, 16 Mar 2007 10:56:51 -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, 16 Mar 2007 10:53:24 -0400 id 015886A6.45FAAF64.00003908 In-Reply-To: <006301c76739$fa4c7520$640fa8c0@cis.neustar.com> References: <006301c76739$fa4c7520$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable Message-Id: <8FC935A8-F14F-42CE-BD94-DE8BF52CD003@hxr.us> From: Andrew Newton Subject: Re: [Geopriv] RE: [Ecrit] NENA Date: Fri, 16 Mar 2007 10:56:40 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: 'GEOPRIV' , 'ECRIT' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org On Mar 15, 2007, at 3:41 PM, Brian Rosen wrote: > To get a liaison out, we fill out a form, hold a semi-official =20 > vote, send it to the =93tech lead team=94, which includes Roger. They = =20 > approve it, and then Roger sends it. So far, the average time to =20 > get through that process is between one and three months, although =20 > everyone agrees that is ridiculous, and we should be able to get it =20= > down to a couple of weeks. All I ever wanted to do was write software. How did I get myself =20 into this mess? -andy= _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 17 02:42:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSSbT-0003t7-NH; Sat, 17 Mar 2007 02:41:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSSbT-0003t1-1j for geopriv@ietf.org; Sat, 17 Mar 2007 02:41: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 1HSSbR-0004ul-NE for geopriv@ietf.org; Sat, 17 Mar 2007 02:41:23 -0400 X-SEF-Processed: 5_0_0_910__2007_03_17_01_47_23 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); Sat, 17 Mar 2007 01:47:22 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Mar 2007 01:41:21 -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: [Geopriv] review comments ondraft-thomson-geopriv-lis-discovery-00.txt Date: Sat, 17 Mar 2007 01:41:19 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] review comments ondraft-thomson-geopriv-lis-discovery-00.txt Thread-Index: Acdnvezk4A7mMrotQquXtq7SRvsPvwAoMSvQ From: "Winterbottom, James" To: "Andrew Newton" , "GEOPRIV WG" X-OriginalArrivalTime: 17 Mar 2007 06:41:21.0219 (UTC) FILETIME=[4631A930:01C7685F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Andy,=0D=0A=0D=0AThanks for the comments. Just on point 4 below.=0D=0AIf= do a U-NAPTR lookup on the provisioned or static domain, then you may=0D=0A= well have to go to the point of actually requesting a location from the=0D=0A= LIS before you are able to determine that you have used the wrong=0D=0Adoma= in. And this detection mechanism is based on the LIS saying "oi, I=0D=0Acan= 't find you".=0D=0A=0D=0AAs long as that is acceptable, then I think the or= der you suggest can be=0D=0Aapplied.=0D=0A=0D=0AIf the reverse DNS is done = prior to the U-NAPTR, then you at least know=0D=0Aor can have a greater deg= ree of comfort that you are going to asking for=0D=0Athe local LIS.=0D=0A=0D= =0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D= =0A> From: Andrew Newton [mailto:andy@hxr.us]=0D=0A> Sent: Friday, 16 March= 2007 10:23 PM=0D=0A> To: GEOPRIV WG=0D=0A> Subject: [Geopriv] review comme= nts=0D=0Aondraft-thomson-geopriv-lis-discovery-=0D=0A> 00.txt=0D=0A>=20=0D=0A= > http://www.ietf.org/internet-drafts/draft-thomson-geopriv-lis-=0D=0A> dis= covery-00.txt=0D=0A>=20=0D=0A> Overall, I like this draft very much, and fa= vor its adoption by this=0D=0A> working group. I appreciate James and Mart= in taking the time to=0D=0A> separate out the LIS discovery mechanisms from= their candidate=0D=0A> proposal, HELD. One of the issues I think this wor= king group has is=0D=0A> that many people feel that to accept HELD or RELO = or etc, they have=0D=0A> to take the bad with the good. This draft separat= es the issue of LIS=0D=0A> discovery so that this good idea of HELD may be = applied to other=0D=0A> protocols. Such ideas enable compromise and progre= ssion of good=0D=0Aideas.=0D=0A>=20=0D=0A> My comments:=0D=0A>=20=0D=0A> 1)= The term LIS needs to be defined in the terminology section,=0D=0A> especi= ally since there is a reference to RFC 3693 where the terms LS=0D=0A> and T= arget are defined. This might also help clarify the scope of=0D=0A> the wo= rk and reduce some of the heartburn the security folks my have.=0D=0A>=20=0D= =0A> 2) The introduction may want to expand upon #1 a little more by=0D=0A>= specifying the scope of the work to the application of L7-LCP enabled=0D=0A= > LIS environments. In other words, if you are already getting your LI=0D=0A= > from DHCP or LLDP-MED, this is not applicable.=0D=0A>=20=0D=0A> 3) Remove= the registration for HELD to make this totally protocol=0D=0A> neutral. I= nstead, note that whatever protocols do use this must=0D=0A> create an IANA= registration for U-NAPTR.=0D=0A>=20=0D=0A> 4) Specify the order of the dis= covery methods. Predictability is a=0D=0A> good thing. I suggest this ord= er: 1)DHCP, 2) U-NAPTR via configured=0D=0A> domain (either static or dynam= ic), and 3) U-NAPTR via reverse IP.=0D=0A> That's just a strawman proposal,= but I think the methods do need to=0D=0A> be ordered.=0D=0A>=20=0D=0A> 5) = Create an appendix with examples. Examples always help.=0D=0A>=20=0D=0A> 6= ) There needs to be some text around how a client would query its=0D=0A> lo= cation over DHCP vs. querying the LIS location over DHCP. In other=0D=0A> = words, explain how a client uses both. See #2.=0D=0A>=20=0D=0A> 7) Pat you= rselves on the back for a job well done.=0D=0A>=20=0D=0A> -andy=0D=0A>=20=0D= =0A> _______________________________________________=0D=0A> Geopriv mailing= list=0D=0A> Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo= /geopriv=0D=0A=0D=0A-------------------------------------------------------= -----------------------------------------=0D=0AThis message is for the desi= gnated recipient only and may=0D=0Acontain privileged, proprietary, or othe= rwise private information. =20=0D=0AIf you have received it in error, pleas= e notify the sender=0D=0Aimmediately and delete the original. Any unauthor= ized use of=0D=0Athis email is prohibited.=0D=0A---------------------------= ---------------------------------------------------------------------=0D=0A= [mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 17 14:35:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSdjq-0000As-N1; Sat, 17 Mar 2007 14:34:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSdjp-0000An-Sh for geopriv@ietf.org; Sat, 17 Mar 2007 14:34:45 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSdjm-0004HZ-C3 for geopriv@ietf.org; Sat, 17 Mar 2007 14:34:45 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Mar 2007 18:34:39 +0000 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Mar 2007 18:34:39 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 17 Mar 2007 18:34:37 -0000 Message-ID: <83413EA4F18F4445B1E94356DBA0B5DA0287A606@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Contribution on Location for Emergency Calls Thread-Index: AcdowurqchvHByImQI+n6RMP+fd7Ng== From: To: X-OriginalArrivalTime: 17 Mar 2007 18:34:39.0141 (UTC) FILETIME=[EBBE4D50:01C768C2] X-Spam-Score: 0.3 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [Geopriv] Contribution on Location for Emergency Calls X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0008596599==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============0008596599== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C768C2.EB93D36C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C768C2.EB93D36C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As BT's UK 112/999 Policy Manager, I'd like to urge the IETF to make a decision next week on a suitable Location Acquisition Protocol. I'm responsible for how emergency calls are handled in BT's PSAPs (28 million emergency calls from fixed and mobile devices each year). We are experiencing a rapid growth in VoIP emergency calls and urgently need a referencable standard against which to plan developments in the UK, that we can be sure also allows international calling scenarios to be managed. I'm aware the HELD protocol is at an advanced stage of development, is being adopted in Canada, and it would seem appropriate to give this serious consideration as a suitable way forward. Thanks and regards John Medland Tel:+44 (0)1977 593408 | Email: john.medland@bt.com=20 ------_=_NextPart_001_01C768C2.EB93D36C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Contribution on Location for Emergency Calls

As BT's UK 112/999 Policy = Manager, I'd like to urge the IETF to make a decision next week on a = suitable Location Acquisition Protocol.

I'm responsible for how emergency = calls are handled in BT's PSAPs (28 million emergency calls from fixed = and mobile devices each year). We are experiencing a rapid growth = in VoIP emergency calls and urgently need a referencable standard = against which to plan developments in the UK, that we can be sure also = allows international calling scenarios to be managed.

I'm aware the HELD protocol is at = an advanced stage of development, is being adopted in Canada, and it = would seem appropriate to give this serious consideration as a suitable = way forward.   Thanks and regards

John Medland

Tel:+44 (0)1977 593408 | Email: = john.medland@bt.com
------_=_NextPart_001_01C768C2.EB93D36C-- --===============0008596599== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0008596599==-- From geopriv-bounces@ietf.org Sat Mar 17 21:45: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 1HSkRg-0001Bh-0n; Sat, 17 Mar 2007 21:44:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSkRd-00018a-8D for geopriv@ietf.org; Sat, 17 Mar 2007 21:44:26 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSkRa-0003KB-Gv for geopriv@ietf.org; Sat, 17 Mar 2007 21:44:24 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sat, 17 Mar 2007 21:40:50 -0400 id 0158C3D1.45FC98A2.000021E8 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: GEOPRIV WG From: Andrew Newton Date: Sat, 17 Mar 2007 21:44:19 -0400 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Geopriv] review comments on draft-thomson-geopriv-held-beep-00.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org http://www.ietf.org/internet-drafts/draft-thomson-geopriv-held- beep-00.txt Overall impression: As of today, too little is likely known about these systems to warrant a hammer solution such as a BEEP binding. Take it from a guy who has an RFC about another application that has a BEEP binding. This is definitely something that could be done at a later date when such an optimization is known to be needed, because getting BEEP right is not easy. 1) Since the H in HELD stands for HTTP, I guess the HELD name will need changing. :) 2) The introduction does not completely frame the usage scenario, as it uses the word "requester" as the actor making multiple requests. It should say "client LIS" or "client LS", as LIS-to-LIS communications is where a BEEP binding would be used. This binding makes no sense in Target-as-LR to LIS communications. 3) The justification for using BEEP is that multiple HTTP connections are bad. Why? Many, many multi-tier servers work this way, with the app server maintaining a pool of persistent TCP connections to its back-end database. I remain unconvinced that this BEEP binding is anymore efficient for the purpose outlined than multiple HTTP connections. 4) The BEEP profile stated does not use the standard BEEP convention, and instead overloads the XML NS URN. That's two sins in one registration. 5) There is no discussion of how the serverName attribute gets populated, or what happens when the attribute is absent. 6) At least we can agree on Section 6. :) -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 17 22:08: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 1HSkp9-0007vU-KJ; Sat, 17 Mar 2007 22:08:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSkp8-0007tp-Du for geopriv@ietf.org; Sat, 17 Mar 2007 22:08:42 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSkp6-0006P7-6V for geopriv@ietf.org; Sat, 17 Mar 2007 22:08:42 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sat, 17 Mar 2007 22:05:07 -0400 id 0158C3D1.45FC9E53.000025EE Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <7080E267-DB1E-41B0-B3B6-1CA0810006B8@hxr.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: GEOPRIV WG From: Andrew Newton Date: Sat, 17 Mar 2007 22:08:33 -0400 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Geopriv] review comments on draft-winterbottom-geopriv-held-identity-extensions-01.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org http://www.ietf.org/internet-drafts/draft-winterbottom-geopriv-held- identity-extensions-01.txt Overall, this draft seems to address its goal, which appears to be to make HELD compliant with the identifier list in draft-ietf-geopriv-l7- lcp-ps-00.txt. Section 4 sports a very impressive list of identifiers, and section 6 sports a very impressive list of regular expressions to match. This identifier list seems to be a superset of that mentioned in draft-ietf-geopriv-l7-lcp-ps-00.txt. Given the complex nature of the systems and protocols involved, how likely is it that all of these identifier types will be used? Is it possible that some may be dropped? And if they cannot be dropped, can we tie their need to a stated requirement? -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Mar 17 22:34: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 1HSlE4-0007U9-3K; Sat, 17 Mar 2007 22:34:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSlE2-0007TF-Ut for geopriv@ietf.org; Sat, 17 Mar 2007 22:34:26 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSlE0-0000hc-N6 for geopriv@ietf.org; Sat, 17 Mar 2007 22:34:26 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sat, 17 Mar 2007 22:30:47 -0400 id 0158C3D1.45FCA457.00002944 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <74094F32-F7D8-4044-9C41-9068531250ED@hxr.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: GEOPRIV WG From: Andrew Newton Date: Sat, 17 Mar 2007 22:34:17 -0400 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Geopriv] review comments on draft-schulzrinne-geopriv-relo-03.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org http://www.ietf.org/internet-drafts/draft-schulzrinne-geopriv- relo-03.txt Overall impression: This was easy to understand, though I was left scratching my head in a couple of places. 1) The last paragraph in Section 1 is appreciated and makes a good point. However, the reader has to get to Section 3.2 to understand why, which is that the source IP address of the query is the key for the location. 2) The url parameter could use a little explaining, as in it is about updating the time on a specific URL previously retrieved. Or that's what I gather it is for. 3) Also, the secret parameter needs more explaining. I'm having trouble understanding the use case, specifically how it might be used by a third party (not the client and not the LIS) and where. 4) This list of identifiers does not seem to include all that are in draft-ietf-geopriv-l7-lcp-ps-00.txt. 5) The assert attribute contains an entire PIDF-LO!? Perhaps you need to consider having this interaction work with a POST instead of a GET. 6) The parenthetical comment "Since the query does not change the state of the resource, GET is the appropriate method." seems to be violated quite a bit by a few parameters. 7) The Subscribe header enables subscriptions to location via SIP. If a client wants to use SIP, why don't we just define these parameters using SIP? That way there is no need to do this, and the client can just talk one protocol. -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sun Mar 18 02:47: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 1HSp9b-0004ec-9R; Sun, 18 Mar 2007 02:46:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSp9a-0004eT-Hf for geopriv@ietf.org; Sun, 18 Mar 2007 02:46:06 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSp9Z-0001OF-7X for geopriv@ietf.org; Sun, 18 Mar 2007 02:46:06 -0400 X-SEF-Processed: 5_0_0_910__2007_03_18_01_52_05 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, 18 Mar 2007 01:52:05 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Mar 2007 01:46:02 -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: [Geopriv] review comments ondraft-winterbottom-geopriv-held-identity-extensions-01.txt Date: Sun, 18 Mar 2007 01:46:01 -0500 Message-ID: In-Reply-To: <7080E267-DB1E-41B0-B3B6-1CA0810006B8@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] review comments ondraft-winterbottom-geopriv-held-identity-extensions-01.txt Thread-Index: AcdpApaP4C5ohW5WQyqtwSMKiQ7fGgAJQfWA From: "Winterbottom, James" To: "Andrew Newton" , "GEOPRIV WG" X-OriginalArrivalTime: 18 Mar 2007 06:46:02.0585 (UTC) FILETIME=[18507490:01C76929] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Andy,=0D=0A=0D=0ATo be clear the schema for this draft has been in basic= existence since=0D=0Athe end of 2005, and many of the identifiers have com= e from looking at=0D=0Aspecific network deployment problems. The identifier= list is long=0D=0Aindeed, and certainly some are in there for just-in-case= =2E If there are=0D=0Aspecific identifiers that you would like me to clarif= y or provide a=0D=0Ascenario for I would be happy to do so. I have provided= quite a few=0D=0Aexamples in a number non-IETF texts over which I have bee= n able to=0D=0Aprovide a use-case for almost all of these identifiers.=0D=0A=0D= =0AI agree that the regular expressions are long, however they enforce that=0D= =0Aspecific address types are indeed valid, something that I think is=0D=0A= important. If we as a group or the IETF as a whole wanted to produce a=0D=0A= separate schema that enforced some of these constraints then we would be=0D= =0Ahappy to import it. For example I see quite a bit of use in a generic=0D= =0Aschema that defines IPv4 and IPv6 address and enforces through=0D=0Avali= dation that the values provided are indeed valid addresses.=0D=0A=0D=0AChee= rs=0D=0AJames=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A= > From: Andrew Newton [mailto:andy@hxr.us]=0D=0A> Sent: Sunday, 18 March 20= 07 1:09 PM=0D=0A> To: GEOPRIV WG=0D=0A> Subject: [Geopriv] review comments = ondraft-winterbottom-geopriv-held-=0D=0A> identity-extensions-01.txt=0D=0A>= =20=0D=0A> http://www.ietf.org/internet-drafts/draft-winterbottom-geopriv-h= eld-=0D=0A> identity-extensions-01.txt=0D=0A>=20=0D=0A> Overall, this draft= seems to address its goal, which appears to be to=0D=0A> make HELD complia= nt with the identifier list in draft-ietf-geopriv-l7-=0D=0A> lcp-ps-00.txt.= Section 4 sports a very impressive list of=0D=0A> identifiers, and sectio= n 6 sports a very impressive list of regular=0D=0A> expressions to match. = This identifier list seems to be a superset of=0D=0A> that mentioned in dra= ft-ietf-geopriv-l7-lcp-ps-00.txt. Given the=0D=0A> complex nature of the s= ystems and protocols involved, how likely is=0D=0A> it that all of these id= entifier types will be used=3F Is it possible=0D=0A> that some may be drop= ped=3F And if they cannot be dropped, can we tie=0D=0A> their need to a st= ated requirement=3F=0D=0A>=20=0D=0A> -andy=0D=0A>=20=0D=0A> _______________= ________________________________=0D=0A> Geopriv mailing list=0D=0A> Geopriv= @ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sun Mar 18 05:05: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 1HSrK3-0002Nx-3Q; Sun, 18 Mar 2007 05:05:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSrK0-0002Mc-Vr; Sun, 18 Mar 2007 05:05:00 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSrJz-0006XZ-OE; Sun, 18 Mar 2007 05:05:00 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 18 Mar 2007 02:05:00 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l2I94wKr023285; Sun, 18 Mar 2007 02:04:58 -0700 Received: from [130.129.20.115] (sjc-vpn6-128.cisco.com [10.21.120.128]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2I94vA8004127; Sun, 18 Mar 2007 09:04:58 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <263711A7-1B77-47E4-840B-40A429F7D028@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: speermint@ietf.org, geopriv@ietf.org From: Cullen Jennings Date: Sun, 18 Mar 2007 10:04:50 +0100 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=411; t=1174208699; x=1175072699; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20IMPORTANT=20SCHEDULE=20CHANGE |Sender:=20; bh=vSpFuIGLllbqotLuQ6sJ3meBwZUi3JsrPgXTYT4c358=; b=J1RFIeExu+4lO3H2VbTGDWeebkpyKLfbibq1DiV2gBL08X6AVy9s3SiFhO/XOrtNquUvRER1 QWeVQyKlfQp72/ZqzuMzjiyGmBZBSr8VcqNz4Yv7gxNiieJbfALADblA; Authentication-Results: sj-dkim-6; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.4 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Geopriv] IMPORTANT SCHEDULE CHANGE X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org We are probably going to swap the time of the geopriv and spearmint meeting. This will result in spearmint being 9:00 Tuesday and geopriv being 9:00 Thursday. This is not confirmed yet but I wanted to give folks a early heads up that this was likely to happen. My apologies for the late notice on this but we have some issues around when we can get the chairs to be here. Thanks, Cullen _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sun Mar 18 05:49: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 1HSs0d-0005FG-UC; Sun, 18 Mar 2007 05:49:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSs0d-0005FB-3O for geopriv@ietf.org; Sun, 18 Mar 2007 05:49:03 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSs0a-0003xK-Ro for geopriv@ietf.org; Sun, 18 Mar 2007 05:49:03 -0400 X-SEF-Processed: 5_0_0_910__2007_03_18_04_54_59 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, 18 Mar 2007 04:54:59 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Mar 2007 04:48:56 -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: [Geopriv] review comments on draft-thomson-geopriv-held-beep-00.txt Date: Sun, 18 Mar 2007 04:48:55 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] review comments on draft-thomson-geopriv-held-beep-00.txt Thread-Index: Acdo/7AGjMJ33Y7lTU2rgD6Ei6/4mgAQWoTA From: "Winterbottom, James" To: "Andrew Newton" , "GEOPRIV WG" X-OriginalArrivalTime: 18 Mar 2007 09:48:56.0733 (UTC) FILETIME=[A56A8CD0:01C76942] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Andy one quick response now.=0D=0A=0D=0A=0D=0A>=20=0D=0A> 3) The justifi= cation for using BEEP is that multiple HTTP connections=0D=0A> are bad. Wh= y=3F Many, many multi-tier servers work this way, with the=0D=0A> app serv= er maintaining a pool of persistent TCP connections to its=0D=0A> back-end = database. I remain unconvinced that this BEEP binding is=0D=0A> anymore ef= ficient for the purpose outlined than multiple HTTP=0D=0A> connections.=0D=0A= >=20=0D=0A=0D=0AOur experience with using HTTP in the manner you describe i= n systems=0D=0Awhere requests can each have a different response time is th= at for a=0D=0Asimilar sized system using HTTP you get about have the peak r= ate of=0D=0Asomething BEEP-like. That is not to say that you cannot perhaps= tweak an=0D=0AHTTP system to improve performance, but I remain unconvinced= that you=0D=0Acan tweak to get a 100% increase in performance.=0D=0A=0D=0A= The problem is of course dimensioning enough threads and ensuring that=0D=0A= you don't get queuing of low-delay requests immediately after=0D=0Adelay-to= lerant requests thereby failing to meet QoS. You also need to=0D=0Aavoid qu= euing multiple delay-tolerant requests to avoid starving.=0D=0A=0D=0ACheers=0D= =0AJames=0D=0A=0D=0A=0D=0A=0D=0A-------------------------------------------= -----------------------------------------------------=0D=0AThis message is = for the designated recipient only and may=0D=0Acontain privileged, propriet= ary, 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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sun Mar 18 09:00: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 1HSuyp-0008Lg-4Y; Sun, 18 Mar 2007 08:59:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSuyn-0008Lb-Kq for geopriv@ietf.org; Sun, 18 Mar 2007 08:59:21 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSuym-0006cX-E3 for geopriv@ietf.org; Sun, 18 Mar 2007 08:59:21 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sun, 18 Mar 2007 08:55:25 -0400 id 0158C3D4.45FD36C4.00002AD6 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4497BCFB-4767-4E57-8DC1-1D1FC081CDD4@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Geopriv] review comments on draft-thomson-geopriv-held-beep-00.txt Date: Sun, 18 Mar 2007 08:58:59 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org On Mar 18, 2007, at 5:48 AM, Winterbottom, James wrote: > Hi Andy one quick response now. > > >> >> 3) The justification for using BEEP is that multiple HTTP connections >> are bad. Why? Many, many multi-tier servers work this way, with the >> app server maintaining a pool of persistent TCP connections to its >> back-end database. I remain unconvinced that this BEEP binding is >> anymore efficient for the purpose outlined than multiple HTTP >> connections. >> > > Our experience with using HTTP in the manner you describe in systems > where requests can each have a different response time is that for a > similar sized system using HTTP you get about have the peak rate of > something BEEP-like. That is not to say that you cannot perhaps > tweak an > HTTP system to improve performance, but I remain unconvinced that you > can tweak to get a 100% increase in performance. > > The problem is of course dimensioning enough threads and ensuring that > you don't get queuing of low-delay requests immediately after > delay-tolerant requests thereby failing to meet QoS. You also need to > avoid queuing multiple delay-tolerant requests to avoid starving. If you are suggesting that TCP congestion control doesn't work with a high number of TCP connections, I'll let you argue that with the Transport folks... I'm not saying that is either wrong or right. However, BEEP's channel multiplexing over a single TCP connection doesn't seem to solve the problem you are talking about. It simply lifts the problem one layer up. Perhaps your HTTP implementation needed some tweaking. If you are saying that your implementation partitions the channels into sets of pools based on the characteristic of the query, that can also been done with HTTP/TCP pools as well. And I'd note, the HELD/ BEEP draft does not mention that. -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sun Mar 18 09:02: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 1HSv2G-0002tp-LD; Sun, 18 Mar 2007 09:02:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSv2E-0002tk-F9 for geopriv@ietf.org; Sun, 18 Mar 2007 09:02:54 -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 1HSv2C-0007Sv-8L for geopriv@ietf.org; Sun, 18 Mar 2007 09:02:54 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sun, 18 Mar 2007 08:59:03 -0400 id 0158C3E2.45FD3797.00002D40 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <45124F92-E83F-4C71-9B90-4567BAB5CB36@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Geopriv] review comments ondraft-winterbottom-geopriv-held-identity-extensions-01.txt Date: Sun, 18 Mar 2007 09:02:38 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org On Mar 18, 2007, at 2:46 AM, Winterbottom, James wrote: > To be clear the schema for this draft has been in basic existence > since > the end of 2005, and many of the identifiers have come from looking at > specific network deployment problems. The identifier list is long > indeed, and certainly some are in there for just-in-case. If there are > specific identifiers that you would like me to clarify or provide a > scenario for I would be happy to do so. I have provided quite a few > examples in a number non-IETF texts over which I have been able to > provide a use-case for almost all of these identifiers. I have no problem with any of those identifiers. But if you feel they are necessary, shouldn't they be in the requirements document? Otherwise, you are putting items into a protocol that are not necessary. > I agree that the regular expressions are long, however they enforce > that > specific address types are indeed valid, something that I think is > important. If we as a group or the IETF as a whole wanted to produce a > separate schema that enforced some of these constraints then we > would be > happy to import it. For example I see quite a bit of use in a generic > schema that defines IPv4 and IPv6 address and enforces through > validation that the values provided are indeed valid addresses. I wasn't being facetious when I said it was impressive. That work is good. -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sun Mar 18 10:42:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSwaD-0005Y3-Jy; Sun, 18 Mar 2007 10:42:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSwaA-0005Xs-TQ for geopriv@ietf.org; Sun, 18 Mar 2007 10:42:03 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HSwa9-0002ad-51 for geopriv@ietf.org; Sun, 18 Mar 2007 10:42:02 -0400 Received: (qmail invoked by alias); 18 Mar 2007 14:41:59 -0000 X-Provags-ID: V01U2FsdGVkX18CDuoaQugClo4s6DVZW+2lC/3BcArh9WORrAD/XE HOY7q1PBRLafWz Message-ID: <45FD4FB6.1010405@gmx.net> Date: Sun, 18 Mar 2007 15:41:58 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: GEOPRIV 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [Geopriv] IETF ECRIT / IEEE Meeting @ IETF#68: Monday, 19th March 2007, 11:30 - 13:00, Room Tyrolka X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi all, I guess I haven't forwarded this mail to the GEOPRIV mailing list but it is definitely relevant for GEOPRIV WG members. The first slide set was also made available already. Please find them here: *http://www.tschofenig.priv.at/twiki/pub/EmergencyServices/IetfEcritRoadMap/11-07-0505-01-0000-emergency-services-shortened-tutorial.ppt * Lunch: We will organize lunch boxes from the hotel catering service. We will have to collect money from each participant. Ciao Hannes -------- Original Message -------- Subject: [Ecrit] IETF ECRIT / IEEE Meeting @ IETF#68: Room Tyrolka Date: Thu, 15 Mar 2007 21:22:14 +0100 From: Hannes Tschofenig To: ECRIT , peter_blatherwick@mitel.com, Dorothy Stanley , Bernard Aboba , "Cullen Jennings (fluffy)" , OPS ADs , "Richard L. Barnes" , Brian Rosen , Marc Linsner , Henning Schulzrinne , "Winterbottom, James" , "James M. Polk" , lixia@CS.UCLA.EDU References: <45F56A82.5060108@gmx.net> Hi all, we got a room, namely Tyrolka, for your meeting on Monday. It will hold around 40 person (the room setting is u-shaped). Ciao Hannes Hannes Tschofenig wrote: > Hi all, > > I wanted to inform you that we picked > > *19th March 2007 (Monday) > 11:30 - 13:00 > > *for our meeting (based on the preference indicated on the Wiki page). > I am still waiting for the room reservation. * > > *Ciao > Hannes > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sun Mar 18 11:25:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSxGK-0004hI-40; Sun, 18 Mar 2007 11:25:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSxGI-0004eL-Cj; Sun, 18 Mar 2007 11:25:34 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSxGB-0000lS-OZ; Sun, 18 Mar 2007 11:25:33 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2007 16:25:28 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2IFPRoV008468; Sun, 18 Mar 2007 16:25:27 +0100 Received: from [10.0.0.223] (ams3-vpn-dhcp4506.cisco.com [10.61.81.153]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2IFPQlZ008995; Sun, 18 Mar 2007 15:25:26 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <2A45522D-9D71-472B-8B82-8717FF14E65A@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: GEOPRIV , speermint@ietf.org From: Cullen Jennings Date: Sun, 18 Mar 2007 16:25:19 +0100 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=362; t=1174231527; x=1175095527; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Times=20of=20GEOPRIV=20and=20SPEERMINT=20meeting=20changed |Sender:=20; bh=seKqnifSIvIS2QKxBi9IIAjspjrzizU7m+CMV3rwSpQ=; b=Zs2h+t1VeVafNcrEW3w1ut4wUcoXrW8K2txQr65/SUwjlOPBf15kEHsAR4iQEoqV3ipiFdtl fMnJpDZ9WJjxmFYRFiYQs0P5qDEqm2RCDrnGBWbuK0Bk87F2FYrmw99/; Authentication-Results: ams-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Geopriv] Times of GEOPRIV and SPEERMINT meeting changed X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org The times of the GEOPRIV and SPEERMINT meetings have been changed. Geopriv is now thursday at 9:00 while SPEERMINT is now tuesday at 9:00. You can find them on agenda at https://datatracker.ietf.org/public/meeting_agenda_html.cgi? meeting_num=68 I know this causes some problems but it was the best plan could come up with. Thanks, Cullen _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Mar 19 04:25:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTDAJ-00078t-Kd; Mon, 19 Mar 2007 04:24:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTDAH-00076W-P3; Mon, 19 Mar 2007 04:24:25 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTDAG-00081F-FX; Mon, 19 Mar 2007 04:24:25 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 19 Mar 2007 01:24:24 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2J8ONgP000758; Mon, 19 Mar 2007 01:24:23 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2J8ONZT021712; Mon, 19 Mar 2007 08:24:23 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 01:24:23 -0700 Received: from mlinsnerwxp ([10.21.101.39]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 01:24:19 -0700 From: "Marc Linsner" To: , "'GEOPRIV'" Date: Mon, 19 Mar 2007 04:24:16 -0400 Message-ID: <000001c769ff$fd1fdfd0$2765150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acdp//mtqtddye4vQAWT3LRxv9eQxA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 19 Mar 2007 08:24:19.0931 (UTC) FILETIME=[FDD1CAB0:01C769FF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=280; t=1174292663; x=1175156663; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20IETF=20ECRIT=20/=20IEEE=20Meeting=20@=20IETF#68=3A=20Monday, = 2019th=20March=202007,=2011=3A30=20-=2013=3A00,=20Room=20Tyrolka |Sender:=20; bh=Fo+zuf66WWBAquJ/Xj+l5KdTBtpwGNNYlFcquj15ZGQ=; b=mPcFwOk45UGX0pX/771xReRxbxbAr1BBGz1K0u/zd20jREDtXKQqxi+jZymcS11Kf7D+PucK PYlqUGdonrkDPJ/rY5TTPwO2InK1eD8OY5EoD4dF+6RH5df9PciEsHX0; Authentication-Results: sj-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Geopriv] IETF ECRIT / IEEE Meeting @ IETF#68: Monday, 19th March 2007, 11:30 - 13:00, Room Tyrolka X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Update...... For those worried about eating....there will be pick-up food available in the lobby level of the hotel. Please visit there and bring the food to room Tyrolka on the Mezzanine level. Agenda: 802.11 - Dorothy 802.16 - DJ 802.1 / LLDP MED - Peter, Dan _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Mar 19 14:46: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 1HTMrX-00027Z-AH; Mon, 19 Mar 2007 14:45:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMrV-00027G-6h for geopriv@ietf.org; Mon, 19 Mar 2007 14:45:41 -0400 Received: from 199-117-205-100.dia.static.qwest.net ([199.117.205.100] helo=ns2.sccx.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTMqw-00069W-PG for geopriv@ietf.org; Mon, 19 Mar 2007 14:45:41 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 19 Mar 2007 13:44:57 -0500 Message-ID: <422D410BD61FC04185076AD99AA7207A02289654@inilmx01.lgmt.trdo> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GRUU in HELD Identities thread-index: AcdqVrEiIv68QoQmT36pUkqkKmgg6Q== From: "Sherry, Robert" To: X-OriginalArrivalTime: 19 Mar 2007 18:44:59.0500 (UTC) FILETIME=[B25512C0:01C76A56] X-Spam-Score: 0.5 (/) X-Scan-Signature: 8f9ac37b081a3249085c4867ee1404d4 Subject: [Geopriv] GRUU in HELD Identities X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0489375075==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============0489375075== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76A56.B1CEEBC9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76A56.B1CEEBC9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a recommendation to add GRUUs to the list of heldDevice enumerations in draft-winterbottom-geopriv-held-identity-extensions-01.txt. =20 The GRUUs define a specific instance of a UA and are described in http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-12.txt =20 The schema might look as follows. gruu based upon draft-ietf-sip-gruu-12 =20 However, I would be satisfied it just uuid were included. =20 Bob Sherry, ENP=20 Intrado Inc. 3030 Warrenville Rd, 4th Floor Lisle, IL 60532 direct: 630-300-2838 mobile: 630-880-3704 fax: 720-494-6600 email: Robert.Sherry@intrado.com =20 Intrado www.intrado.com=20 =20 =20 ------_=_NextPart_001_01C76A56.B1CEEBC9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a recommendation to add GRUUs to the list of heldDevice enumerations in = draft-winterbottom-geopriv-held-identity-extensions-01.txt.

The GRUUs define a specific instance of a UA and are described in h= ttp://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-12.txt

The schema might look as = follows.

<xs:element name=3D"gruu">

           =              = <xs:annotation>

           =             &= nbsp;            = <xs:documentation>gruu based = upon draft-ietf-sip-gruu-12 </xs:documentation>

           =              = </xs:annotation>

           =              = <xs:complexType>

           =             &= nbsp;            = <xs:sequence>

           =             &= nbsp;           &n= bsp;            = <xs:element = name=3D"pub_gruu" = type=3D"xs:anyURI" = minOccurs=3D"0"/>

           =             &= nbsp;           &n= bsp;            = <xs:element = name=3D"temp_gruu" = type=3D"xs:anyURI" = minOccurs=3D"0"/>

           =             &= nbsp;           &n= bsp;            = <xs:element = name=3D"uuid" = type=3D"xs:token" = minOccurs=3D"0"/>

           =             &= nbsp;            = </xs:sequence>

           =              = </xs:complexType>

   = ;         </xs:element>

=
However, I would be satisfied it just uuid were = included.

Bob = Sherry, = ENP

Intrado = Inc.

3030 Warrenville = Rd, 4^th = Floor

Lisle, IL 60532

direct: 630-300-2838   mobile: = 630-880-3704

fax: 720-494-6600 email: = Robert.Sherry@intrado.com

Intrado

www.intrado.com

------_=_NextPart_001_01C76A56.B1CEEBC9-- --===============0489375075== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0489375075==-- From geopriv-bounces@ietf.org Mon Mar 19 17:27: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 1HTPNN-00005I-CP; Mon, 19 Mar 2007 17:26:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTPNL-000054-R7 for geopriv@ietf.org; Mon, 19 Mar 2007 17:26:43 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTPMz-0003GU-6X for geopriv@ietf.org; Mon, 19 Mar 2007 17:26:43 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HTPMN-0001pp-Mq; Mon, 19 Mar 2007 16:25:44 -0500 From: "Brian Rosen" To: "'Sherry, Robert'" , Subject: RE: [Geopriv] GRUU in HELD Identities Date: Mon, 19 Mar 2007 17:26:14 -0400 Message-ID: <017c01c76a6d$3b241b30$37158182@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <422D410BD61FC04185076AD99AA7207A02289654@inilmx01.lgmt.trdo> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdqVrEiIv68QoQmT36pUkqkKmgg6QAFQs2g 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 - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: 9d5866e4c615ceea0db8f42c46495d22 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0533264079==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============0533264079== Content-Type: multipart/alternative; boundary="----=_NextPart_000_017D_01C76A4B.B4127B30" This is a multi-part message in MIME format. ------=_NextPart_000_017D_01C76A4B.B4127B30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm not sure how good of an idea this is 1. You probably need some other identifier that lets the registrar associate a location with the endpoint. I'm not sure what that would be. Normally, the registrar doesn't have that kind of information. Any device that has the user's credentials is normally indistinguishable from any other device with those credentials. The GRUU can keep the devices straight, so that if there are more than one device which are simultaneously registered with the same AoR, the GRUU will be unique for that device. But it doesn't usually know where the device is. It doesn't usually have any other information that a LIS could use to identify the device for location purposes either. 2. A GRUU is pretty ephemeral. It's typically good as long as the user maintains a registration at the SIP registrar. That is pretty useful for the emergency case, and probably most other uses of location, but it may not be useful in some circumstances. 3. You need a correlation between the LIS and the registrar, so it probably only works in a situation where the access network and the calling network are operated by the same entity. Brian _____ From: Sherry, Robert [mailto:Robert.Sherry@intrado.com] Sent: Monday, March 19, 2007 2:45 PM To: geopriv@ietf.org Subject: [Geopriv] GRUU in HELD Identities This is a recommendation to add GRUUs to the list of heldDevice enumerations in draft-winterbottom-geopriv-held-identity-extensions-01.txt. The GRUUs define a specific instance of a UA and are described in http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-12.txt The schema might look as follows. gruu based upon draft-ietf-sip-gruu-12 However, I would be satisfied it just uuid were included. Bob Sherry, ENP Intrado Inc. 3030 Warrenville Rd, 4th Floor Lisle, IL 60532 direct: 630-300-2838 mobile: 630-880-3704 fax: 720-494-6600 email: Robert.Sherry@intrado.com Intrado www.intrado.com ------=_NextPart_000_017D_01C76A4B.B4127B30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not sure how good of an = idea this is

You probably need some other identifier that lets the registrar = associate a location with the endpoint. I’m not sure what that = would be. Normally, the registrar doesn’t have that kind of = information. Any device that has the user’s credentials is normally indistinguishable from any other device with those credentials. = The GRUU can keep the devices straight, so that if there are more than = one device which are simultaneously registered with the same AoR, the = GRUU will be unique for that device. But it doesn’t usually = know where the device is. It doesn’t usually have any other information that a LIS could use to identify the device for = location purposes either.

A GRUU is pretty ephemeral. It’s typically good as long = as the user maintains a registration at the SIP registrar. That is = pretty useful for the emergency case, and probably most other uses of = location, but it may not be useful in some circumstances. =

You need a correlation between the LIS and the registrar, so it = probably only works in a situation where the access network and the calling = network are operated by the same entity.

Brian =

      =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;        =

From: = Sherry, Robert [mailto:Robert.Sherry@intrado.com]
Sent: Monday, March 19, = 2007 2:45 PM
To: geopriv@ietf.org
Subject: [Geopriv] GRUU = in HELD Identities

This is a recommendation to add GRUUs to the list of heldDevice enumerations in draft-winterbottom-geopriv-held-identity-extensions-01.txt.

The GRUUs define a specific instance of a UA and are described in h= ttp://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-12.txt

The schema might look as = follows.

<xs:element name=3D"gruu">

           =              <xs:annotation>

           =             &= nbsp;            <xs:documentation>gruu based = upon draft-ietf-sip-gruu-12 </xs:documentation>

           =              </xs:annotation>

           =              <xs:complexType>

           =             &= nbsp;            <xs:sequence>

           =             &= nbsp;           &n= bsp;            <xs:element = name=3D"pub_gruu" = type=3D"xs:anyURI" = minOccurs=3D"0"/>

           =             &= nbsp;           &n= bsp;            <xs:element = name=3D"temp_gruu" = type=3D"xs:anyURI" = minOccurs=3D"0"/>

           =             &= nbsp;           &n= bsp;            <xs:element = name=3D"uuid" = type=3D"xs:token" = minOccurs=3D"0"/>

           =             &= nbsp;            </xs:sequence>

           =              </xs:complexType>

   = ;         </xs:element>

=
However, I would be satisfied it just uuid were = included.

Bob = Sherry, = ENP

Intrado = Inc.

3030 Warrenville = Rd, 4^th Floor

Lisle, IL 60532

direct: 630-300-2838   mobile: = 630-880-3704

fax: 720-494-6600 email: = Robert.Sherry@intrado.com

Intrado

www.intrado.com

------=_NextPart_000_017D_01C76A4B.B4127B30-- --===============0533264079== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0533264079==-- From geopriv-bounces@ietf.org Mon Mar 19 17:33: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 1HTPTq-0003tr-H5; Mon, 19 Mar 2007 17:33:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTPTp-0003tm-E5 for geopriv@ietf.org; Mon, 19 Mar 2007 17:33:25 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTPTM-0004S2-Vg for geopriv@ietf.org; Mon, 19 Mar 2007 17:33:25 -0400 X-SEF-Processed: 5_0_0_910__2007_03_19_16_39_01 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); Mon, 19 Mar 2007 16:39:00 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 16:32:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] GRUU in HELD Identities Date: Mon, 19 Mar 2007 16:32:52 -0500 Message-ID: In-Reply-To: <422D410BD61FC04185076AD99AA7207A02289654@inilmx01.lgmt.trdo> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] GRUU in HELD Identities Thread-Index: AcdqVrEiIv68QoQmT36pUkqkKmgg6QAFyClQ From: "Thomson, Martin" To: "Sherry, Robert" , X-OriginalArrivalTime: 19 Mar 2007 21:32:55.0854 (UTC) FILETIME=[284EACE0:01C76A6E] X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d38eb86565b1a4d8c3dba35af39014d Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1452833885==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============1452833885== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76A6E.27AB39C6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76A6E.27AB39C6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQm9iLA0KDQogDQoNCkEgR1JVVSBpcyBqdXN0IGEgU0lQIFVSSSB3aXRoIHNwZWNpYWwgcHJv cGVydGllcy4gIElmIHRoaXMgaXMgYSBuZWNlc3NhcnkgaWRlbnRpZmllciAoZW1waGFzaXMgb24g 4oCcaWbigJ0sIGMuZi4gQnJpYW7igJlzIHJlcGx5KSB0aGUgPGxpbms+IGVsZW1lbnQgY2FuIGJl IHVzZWQuICBJIGRvbuKAmXQgc2VlIGFueSBuZWVkIHRvIGluY2x1ZGUgYWRkaXRpb25hbCBwYXJh bWV0ZXJzLg0KDQogDQoNCkNoZWVycywNCg0KTWFydGluDQoNCiANCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KRnJvbTogU2hlcnJ5LCBSb2JlcnQgW21haWx0bzpSb2JlcnQu U2hlcnJ5QGludHJhZG8uY29tXSANClNlbnQ6IFR1ZXNkYXksIDIwIE1hcmNoIDIwMDcgNTo0NSBB TQ0KVG86IGdlb3ByaXZAaWV0Zi5vcmcNClN1YmplY3Q6IFtHZW9wcml2XSBHUlVVIGluIEhFTEQg SWRlbnRpdGllcw0KDQogDQoNClRoaXMgaXMgYSByZWNvbW1lbmRhdGlvbiB0byBhZGQgR1JVVXMg dG8gdGhlIGxpc3Qgb2YgaGVsZERldmljZSBlbnVtZXJhdGlvbnMgaW4gZHJhZnQtd2ludGVyYm90 dG9tLWdlb3ByaXYtaGVsZC1pZGVudGl0eS1leHRlbnNpb25zLTAxLnR4dC4NCg0KIA0KDQpUaGUg R1JVVXMgZGVmaW5lIGEgc3BlY2lmaWMgaW5zdGFuY2Ugb2YgYSBVQSBhbmQgYXJlIGRlc2NyaWJl ZCBpbiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXNpcC1n cnV1LTEyLnR4dA0KDQogDQoNClRoZSBzY2hlbWEgbWlnaHQgbG9vayBhcyBmb2xsb3dzLg0KDQo8 eHM6ZWxlbWVudCBuYW1lPSJncnV1Ij4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgPHhzOmFu bm90YXRpb24+DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4czpkb2N1 bWVudGF0aW9uPmdydXUgYmFzZWQgdXBvbiBkcmFmdC1pZXRmLXNpcC1ncnV1LTEyIDwveHM6ZG9j dW1lbnRhdGlvbj4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgPC94czphbm5vdGF0aW9uPg0K DQogICAgICAgICAgICAgICAgICAgICAgICA8eHM6Y29tcGxleFR5cGU+DQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDx4czpzZXF1ZW5jZT4NCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHhzOmVsZW1lbnQgbmFtZT0icHViX2dy dXUiIHR5cGU9InhzOmFueVVSSSIgbWluT2NjdXJzPSIwIi8+DQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4czplbGVtZW50IG5hbWU9InRlbXBfZ3J1 dSIgdHlwZT0ieHM6YW55VVJJIiBtaW5PY2N1cnM9IjAiLz4NCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHhzOmVsZW1lbnQgbmFtZT0idXVpZCIgdHlw ZT0ieHM6dG9rZW4iIG1pbk9jY3Vycz0iMCIvPg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8L3hzOnNlcXVlbmNlPg0KDQogICAgICAgICAgICAgICAgICAgICAgICA8L3hz OmNvbXBsZXhUeXBlPg0KDQogICAgICAgICAgICA8L3hzOmVsZW1lbnQ+DQoNCiANCg0KSG93ZXZl ciwgSSB3b3VsZCBiZSBzYXRpc2ZpZWQgaXQganVzdCB1dWlkIHdlcmUgaW5jbHVkZWQuDQoNCiAN Cg0KQm9iIFNoZXJyeSwgRU5QIA0KDQpJbnRyYWRvIEluYy4NCg0KMzAzMCBXYXJyZW52aWxsZSBS ZCwgNHRoIEZsb29yDQoNCkxpc2xlLCBJTCA2MDUzMg0KDQpkaXJlY3Q6IDYzMC0zMDAtMjgzOCAg IG1vYmlsZTogNjMwLTg4MC0zNzA0DQoNCmZheDogNzIwLTQ5NC02NjAwICBlbWFpbDogUm9iZXJ0 LlNoZXJyeUBpbnRyYWRvLmNvbQ0KDQogDQoNCkludHJhZG8NCg0Kd3d3LmludHJhZG8uY29tIA0K DQogDQoNCiANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlz IG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNv bnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9y bWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1 bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJdDQo= ------_=_NextPart_001_01C76A6E.27AB39C6 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQoNCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDExIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYg IW1zb10+DQo8c3R5bGU+DQp2XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoq IHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1 bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+ DQo8IVtlbmRpZl0tLT48bzpTbWFydFRhZ1R5cGUNCiBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFz LW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyIgbmFtZT0iUG9zdGFsQ29kZSIvPg0KPG86 U21hcnRUYWdUeXBlIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6c21hcnR0YWdzIg0KIG5hbWU9IlN0YXRlIi8+DQo8bzpTbWFydFRhZ1R5cGUgbmFtZXNwYWNl dXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiDQogbmFtZT0i cGxhY2UiLz4NCjxvOlNtYXJ0VGFnVHlwZSBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jv c29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyINCiBuYW1lPSJDaXR5Ii8+DQo8bzpTbWFydFRhZ1R5 cGUgbmFtZXNwYWNldXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRh Z3MiDQogbmFtZT0iU3RyZWV0Ii8+DQo8bzpTbWFydFRhZ1R5cGUgbmFtZXNwYWNldXJpPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiDQogbmFtZT0iYWRkcmVzcyIv Pg0KPCEtLVtpZiAhbXNvXT4NCjxzdHlsZT4NCnN0MVw6KntiZWhhdmlvcjp1cmwoI2RlZmF1bHQj aWVvb3VpKSB9DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+DQo8c3R5bGU+DQo8IS0tDQogLyogRm9u dCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkFyaWFsIE5hcnJvdyI7DQoJcGFub3NlLTE6MiAxMSA1IDYgMiAyIDIgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiU2NyaXB0IE1UIEJvbGQiO30NCiAvKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBj bTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CnAucmVmZXJlbmNlLCBsaS5yZWZlcmVuY2UsIGRpdi5yZWZlcmVuY2UNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1pbmRlbnQ6MGNtOw0KCW1zby1saXN0Omww IGxldmVsMSBsZm8yOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiI7DQoJZm9udC1zdHlsZTppdGFsaWM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6d2luZG93 dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseTpBcmlhbDsNCgljb2xvcjptYXJvb247DQoJZm9udC13ZWlnaHQ6bm9y bWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0K QHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5 MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQog LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KIEBsaXN0IGwwDQoJe21zby1saXN0LWlkOjM1NDUwNjY1 NDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTE5MjQx NTA0OCAtMTEzNDkzNTkxNCA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLXN0eWxlLWxpbms6cmVmZXJlbmNlOw0KCW1zby1sZXZlbC10ZXh0OiJcWyUxXF0iOw0K CW1zby1sZXZlbC10YWItc3RvcDo0NS4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCW1hcmdpbi1sZWZ0OjQ1LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNv LWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC10 YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpvbA0KCXttYXJnaW4t Ym90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT4NCjwvc3R5bGU+DQoN CjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPg0KDQo8 ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNv bG9yPW1hcm9vbiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9u dC1mYW1pbHk6QXJpYWw7Y29sb3I6bWFyb29uJz5IaSBCb2IsPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1tYXJvb24g ZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFy aWFsO2NvbG9yOm1hcm9vbic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1tYXJvb24gZmFjZT1BcmlhbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm1h cm9vbic+QSBHUlVVIGlzIGp1c3QgYSBTSVAgVVJJIHdpdGggc3BlY2lhbA0KcHJvcGVydGllcy7C oCBJZiB0aGlzIGlzIGEgbmVjZXNzYXJ5IGlkZW50aWZpZXIgKGVtcGhhc2lzIG9uIOKAnGlm4oCd LCBjLmYuDQpCcmlhbuKAmXMgcmVwbHkpIHRoZSAmbHQ7bGluayZndDsgZWxlbWVudCBjYW4gYmUg dXNlZC7CoCBJIGRvbuKAmXQgc2VlDQphbnkgbmVlZCB0byBpbmNsdWRlIGFkZGl0aW9uYWwgcGFy YW1ldGVycy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW1hcm9vbiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bWFyb29uJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6 ZT0yIGNvbG9yPW1hcm9vbiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4w cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bWFyb29uJz5DaGVlcnMsPG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1t YXJvb24gZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFt aWx5OkFyaWFsO2NvbG9yOm1hcm9vbic+TWFydGluPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1tYXJvb24gZmFjZT1B cmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2Nv bG9yOm1hcm9vbic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPGRpdiBz dHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Jz4NCg0KPGRpdj4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249 Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PGZvbnQgc2l6ZT0zDQpmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz4NCg0KPGhyIHNpemU9 MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyIHRhYmluZGV4PS0xPg0KDQo8L3NwYW4+PC9mb250 PjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PGZvbnQgc2l6ZT0yIGZhY2U9VGFob21h PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6VGFob21hO2ZvbnQt d2VpZ2h0OmJvbGQnPkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0yDQpmYWNlPVRh aG9tYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWEnPiBT aGVycnksIFJvYmVydA0KW21haWx0bzpSb2JlcnQuU2hlcnJ5QGludHJhZG8uY29tXSA8YnI+DQo8 Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U2VudDo8L3NwYW4+PC9iPiBUdWVzZGF5 LCAyMCBNYXJjaCAyMDA3IDU6NDUNCkFNPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0 OmJvbGQnPlRvOjwvc3Bhbj48L2I+IGdlb3ByaXZAaWV0Zi5vcmc8YnI+DQo8Yj48c3BhbiBzdHls ZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U3ViamVjdDo8L3NwYW4+PC9iPiBbR2VvcHJpdl0gR1JVVSBp biBIRUxEDQpJZGVudGl0aWVzPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJp YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+VGhp cyBpcyBhIHJlY29tbWVuZGF0aW9uIHRvIGFkZCBHUlVVcyB0byB0aGUgbGlzdCBvZg0KaGVsZERl dmljZSBlbnVtZXJhdGlvbnMgaW4NCmRyYWZ0LXdpbnRlcmJvdHRvbS1nZW9wcml2LWhlbGQtaWRl bnRpdHktZXh0ZW5zaW9ucy0wMS50eHQuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1B cmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5U aGUgR1JVVXMgZGVmaW5lIGEgc3BlY2lmaWMgaW5zdGFuY2Ugb2YgYSBVQSBhbmQgYXJlDQpkZXNj cmliZWQgaW4gPGENCmhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtc2lwLWdydXUtMTIudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1pZXRmLXNpcC1ncnV1LTEyLnR4dDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNp emU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1p bHk6QXJpYWwnPlRoZSBzY2hlbWEgbWlnaHQgbG9vayBhcyBmb2xsb3dzLjxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hdXRvc3Bh Y2U6bm9uZSc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUNCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymx1ZTtiYWNrZ3JvdW5kOg0Kd2hp dGUnPiZsdDs8L3NwYW4+PC9mb250Pjxmb250IGNvbG9yPW1hcm9vbj48c3BhbiBzdHlsZT0nY29s b3I6bWFyb29uOw0KYmFja2dyb3VuZDp3aGl0ZSc+eHM6ZWxlbWVudDwvc3Bhbj48L2ZvbnQ+PGZv bnQgY29sb3I9cmVkPjxzcGFuDQpzdHlsZT0nY29sb3I6cmVkO2JhY2tncm91bmQ6d2hpdGUnPiBu YW1lPC9zcGFuPjwvZm9udD48Zm9udCBjb2xvcj1ibHVlPjxzcGFuDQpzdHlsZT0nY29sb3I6Ymx1 ZTtiYWNrZ3JvdW5kOndoaXRlJz49JnF1b3Q7PC9zcGFuPjwvZm9udD48Zm9udCBjb2xvcj1ibGFj az48c3Bhbg0Kc3R5bGU9J2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUnPmdydXU8L3NwYW4+ PC9mb250Pjxmb250IGNvbG9yPWJsdWU+PHNwYW4NCnN0eWxlPSdjb2xvcjpibHVlO2JhY2tncm91 bmQ6d2hpdGUnPiZxdW90OyZndDs8L3NwYW4+PC9mb250Pjxmb250IGNvbG9yPWJsYWNrPjxzcGFu DQpzdHlsZT0nY29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSc+PG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9zcGFjZTpu b25lJz48Zm9udCBzaXplPTMgY29sb3I9YmxhY2sNCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDoNCndoaXRl Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgY29sb3I9Ymx1 ZT48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZTtiYWNrZ3JvdW5kOndoaXRlJz4mbHQ7PC9zcGFuPjwv Zm9udD48Zm9udA0KY29sb3I9bWFyb29uPjxzcGFuIHN0eWxlPSdjb2xvcjptYXJvb247YmFja2dy b3VuZDp3aGl0ZSc+eHM6YW5ub3RhdGlvbjwvc3Bhbj48L2ZvbnQ+PGZvbnQNCmNvbG9yPWJsdWU+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWU7YmFja2dyb3VuZDp3aGl0ZSc+Jmd0Ozwvc3Bhbj48L2Zv bnQ+PGZvbnQNCmNvbG9yPWJsYWNrPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjaztiYWNrZ3JvdW5k OndoaXRlJz48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J3RleHQtYXV0b3NwYWNlOm5vbmUnPjxmb250IHNpemU9MyBjb2xvcj1ibGFjaw0K ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjaztiYWNrZ3JvdW5kOg0Kd2hpdGUnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48Zm9udCBjb2xvcj1ibHVlPjxzcGFuIHN0eWxlPSdj b2xvcjpibHVlO2JhY2tncm91bmQ6d2hpdGUnPiZsdDs8L3NwYW4+PC9mb250Pjxmb250DQpjb2xv cj1tYXJvb24+PHNwYW4gc3R5bGU9J2NvbG9yOm1hcm9vbjtiYWNrZ3JvdW5kOndoaXRlJz54czpk b2N1bWVudGF0aW9uPC9zcGFuPjwvZm9udD48Zm9udA0KY29sb3I9Ymx1ZT48c3BhbiBzdHlsZT0n Y29sb3I6Ymx1ZTtiYWNrZ3JvdW5kOndoaXRlJz4mZ3Q7PC9zcGFuPjwvZm9udD48Zm9udA0KY29s b3I9YmxhY2s+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUnPmdydXUg YmFzZWQgdXBvbg0KZHJhZnQtaWV0Zi1zaXAtZ3J1dS0xMiA8L3NwYW4+PC9mb250Pjxmb250IGNv bG9yPWJsdWU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWU7DQpiYWNrZ3JvdW5kOndoaXRlJz4mbHQ7 Lzwvc3Bhbj48L2ZvbnQ+PGZvbnQgY29sb3I9bWFyb29uPjxzcGFuIHN0eWxlPSdjb2xvcjoNCm1h cm9vbjtiYWNrZ3JvdW5kOndoaXRlJz54czpkb2N1bWVudGF0aW9uPC9zcGFuPjwvZm9udD48Zm9u dCBjb2xvcj1ibHVlPjxzcGFuDQpzdHlsZT0nY29sb3I6Ymx1ZTtiYWNrZ3JvdW5kOndoaXRlJz4m Z3Q7PC9zcGFuPjwvZm9udD48Zm9udCBjb2xvcj1ibGFjaz48c3Bhbg0Kc3R5bGU9J2NvbG9yOmJs YWNrO2JhY2tncm91bmQ6d2hpdGUnPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PGZvbnQgc2l6ZT0z IGNvbG9yPWJsYWNrDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6DQp3aGl0ZSc+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjxmb250IGNvbG9yPWJsdWU+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsdWU7YmFja2dyb3VuZDp3aGl0ZSc+Jmx0Oy88L3NwYW4+PC9mb250Pjxmb250DQpjb2xv cj1tYXJvb24+PHNwYW4gc3R5bGU9J2NvbG9yOm1hcm9vbjtiYWNrZ3JvdW5kOndoaXRlJz54czph bm5vdGF0aW9uPC9zcGFuPjwvZm9udD48Zm9udA0KY29sb3I9Ymx1ZT48c3BhbiBzdHlsZT0nY29s b3I6Ymx1ZTtiYWNrZ3JvdW5kOndoaXRlJz4mZ3Q7PC9zcGFuPjwvZm9udD48Zm9udA0KY29sb3I9 YmxhY2s+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUnPjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1h dXRvc3BhY2U6bm9uZSc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsYWNrDQpmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrO2JhY2tncm91 bmQ6DQp3aGl0ZSc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjxmb250 IGNvbG9yPWJsdWU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWU7YmFja2dyb3VuZDp3aGl0ZSc+Jmx0 Ozwvc3Bhbj48L2ZvbnQ+PGZvbnQNCmNvbG9yPW1hcm9vbj48c3BhbiBzdHlsZT0nY29sb3I6bWFy b29uO2JhY2tncm91bmQ6d2hpdGUnPnhzOmNvbXBsZXhUeXBlPC9zcGFuPjwvZm9udD48Zm9udA0K Y29sb3I9Ymx1ZT48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZTtiYWNrZ3JvdW5kOndoaXRlJz4mZ3Q7 PC9zcGFuPjwvZm9udD48Zm9udA0KY29sb3I9YmxhY2s+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr O2JhY2tncm91bmQ6d2hpdGUnPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PGZvbnQgc2l6ZT0zIGNv bG9yPWJsYWNrDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6DQp3aGl0ZSc+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjxmb250IGNvbG9yPWJsdWU+PHNw YW4gc3R5bGU9J2NvbG9yOmJsdWU7YmFja2dyb3VuZDp3aGl0ZSc+Jmx0Ozwvc3Bhbj48L2ZvbnQ+ PGZvbnQNCmNvbG9yPW1hcm9vbj48c3BhbiBzdHlsZT0nY29sb3I6bWFyb29uO2JhY2tncm91bmQ6 d2hpdGUnPnhzOnNlcXVlbmNlPC9zcGFuPjwvZm9udD48Zm9udA0KY29sb3I9Ymx1ZT48c3BhbiBz dHlsZT0nY29sb3I6Ymx1ZTtiYWNrZ3JvdW5kOndoaXRlJz4mZ3Q7PC9zcGFuPjwvZm9udD48Zm9u dA0KY29sb3I9YmxhY2s+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUn PjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsYWNrDQpmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr O2JhY2tncm91bmQ6DQp3aGl0ZSc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjxmb250IGNvbG9yPWJsdWU+PHNwYW4g c3R5bGU9J2NvbG9yOmJsdWU7YmFja2dyb3VuZDp3aGl0ZSc+Jmx0Ozwvc3Bhbj48L2ZvbnQ+PGZv bnQNCmNvbG9yPW1hcm9vbj48c3BhbiBzdHlsZT0nY29sb3I6bWFyb29uO2JhY2tncm91bmQ6d2hp dGUnPnhzOmVsZW1lbnQ8L3NwYW4+PC9mb250Pjxmb250DQpjb2xvcj1yZWQ+PHNwYW4gc3R5bGU9 J2NvbG9yOnJlZDtiYWNrZ3JvdW5kOndoaXRlJz4gbmFtZTwvc3Bhbj48L2ZvbnQ+PGZvbnQNCmNv bG9yPWJsdWU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWU7YmFja2dyb3VuZDp3aGl0ZSc+PSZxdW90 Ozwvc3Bhbj48L2ZvbnQ+PGZvbnQNCmNvbG9yPWJsYWNrPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj aztiYWNrZ3JvdW5kOndoaXRlJz5wdWJfZ3J1dTwvc3Bhbj48L2ZvbnQ+PGZvbnQNCmNvbG9yPWJs dWU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWU7YmFja2dyb3VuZDp3aGl0ZSc+JnF1b3Q7PC9zcGFu PjwvZm9udD48Zm9udA0KY29sb3I9cmVkPjxzcGFuIHN0eWxlPSdjb2xvcjpyZWQ7YmFja2dyb3Vu ZDp3aGl0ZSc+IHR5cGU8L3NwYW4+PC9mb250Pjxmb250DQpjb2xvcj1ibHVlPjxzcGFuIHN0eWxl PSdjb2xvcjpibHVlO2JhY2tncm91bmQ6d2hpdGUnPj0mcXVvdDs8L3NwYW4+PC9mb250Pjxmb250 DQpjb2xvcj1ibGFjaz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSc+ eHM6YW55VVJJPC9zcGFuPjwvZm9udD48Zm9udA0KY29sb3I9Ymx1ZT48c3BhbiBzdHlsZT0nY29s b3I6Ymx1ZTtiYWNrZ3JvdW5kOndoaXRlJz4mcXVvdDs8L3NwYW4+PC9mb250Pjxmb250DQpjb2xv cj1yZWQ+PHNwYW4gc3R5bGU9J2NvbG9yOnJlZDtiYWNrZ3JvdW5kOndoaXRlJz4gbWluT2NjdXJz PC9zcGFuPjwvZm9udD48Zm9udA0KY29sb3I9Ymx1ZT48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZTti YWNrZ3JvdW5kOndoaXRlJz49JnF1b3Q7PC9zcGFuPjwvZm9udD48Zm9udA0KY29sb3I9YmxhY2s+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUnPjA8L3NwYW4+PC9mb250 Pjxmb250DQpjb2xvcj1ibHVlPjxzcGFuIHN0eWxlPSdjb2xvcjpibHVlO2JhY2tncm91bmQ6d2hp dGUnPiZxdW90Oy8mZ3Q7PC9zcGFuPjwvZm9udD48Zm9udA0KY29sb3I9YmxhY2s+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUnPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+ PGZvbnQgc2l6ZT0zIGNvbG9yPWJsYWNrDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6DQp3aGl0ZSc+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9mb250Pjxmb250IGNvbG9yPWJsdWU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWU7YmFja2dy b3VuZDp3aGl0ZSc+Jmx0Ozwvc3Bhbj48L2ZvbnQ+PGZvbnQNCmNvbG9yPW1hcm9vbj48c3BhbiBz dHlsZT0nY29sb3I6bWFyb29uO2JhY2tncm91bmQ6d2hpdGUnPnhzOmVsZW1lbnQ8L3NwYW4+PC9m b250Pjxmb250DQpjb2xvcj1yZWQ+PHNwYW4gc3R5bGU9J2NvbG9yOnJlZDtiYWNrZ3JvdW5kOndo aXRlJz4gbmFtZTwvc3Bhbj48L2ZvbnQ+PGZvbnQNCmNvbG9yPWJsdWU+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsdWU7YmFja2dyb3VuZDp3aGl0ZSc+PSZxdW90Ozwvc3Bhbj48L2ZvbnQ+PGZvbnQNCmNv bG9yPWJsYWNrPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlJz50ZW1w X2dydXU8L3NwYW4+PC9mb250Pjxmb250DQpjb2xvcj1ibHVlPjxzcGFuIHN0eWxlPSdjb2xvcjpi bHVlO2JhY2tncm91bmQ6d2hpdGUnPiZxdW90Ozwvc3Bhbj48L2ZvbnQ+PGZvbnQNCmNvbG9yPXJl ZD48c3BhbiBzdHlsZT0nY29sb3I6cmVkO2JhY2tncm91bmQ6d2hpdGUnPiB0eXBlPC9zcGFuPjwv Zm9udD48Zm9udA0KY29sb3I9Ymx1ZT48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZTtiYWNrZ3JvdW5k OndoaXRlJz49JnF1b3Q7PC9zcGFuPjwvZm9udD48Zm9udA0KY29sb3I9YmxhY2s+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUnPnhzOmFueVVSSTwvc3Bhbj48L2ZvbnQ+ PGZvbnQNCmNvbG9yPWJsdWU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWU7YmFja2dyb3VuZDp3aGl0 ZSc+JnF1b3Q7PC9zcGFuPjwvZm9udD48Zm9udA0KY29sb3I9cmVkPjxzcGFuIHN0eWxlPSdjb2xv cjpyZWQ7YmFja2dyb3VuZDp3aGl0ZSc+IG1pbk9jY3Vyczwvc3Bhbj48L2ZvbnQ+PGZvbnQNCmNv bG9yPWJsdWU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWU7YmFja2dyb3VuZDp3aGl0ZSc+PSZxdW90 Ozwvc3Bhbj48L2ZvbnQ+PGZvbnQNCmNvbG9yPWJsYWNrPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj aztiYWNrZ3JvdW5kOndoaXRlJz4wPC9zcGFuPjwvZm9udD48Zm9udA0KY29sb3I9Ymx1ZT48c3Bh biBzdHlsZT0nY29sb3I6Ymx1ZTtiYWNrZ3JvdW5kOndoaXRlJz4mcXVvdDsvJmd0Ozwvc3Bhbj48 L2ZvbnQ+PGZvbnQNCmNvbG9yPWJsYWNrPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjaztiYWNrZ3Jv dW5kOndoaXRlJz48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J3RleHQtYXV0b3NwYWNlOm5vbmUnPjxmb250IHNpemU9MyBjb2xvcj1ibGFj aw0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjaztiYWNrZ3JvdW5kOg0Kd2hpdGUnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48Zm9udCBjb2xvcj1i bHVlPjxzcGFuIHN0eWxlPSdjb2xvcjpibHVlO2JhY2tncm91bmQ6d2hpdGUnPiZsdDs8L3NwYW4+ PC9mb250Pjxmb250DQpjb2xvcj1tYXJvb24+PHNwYW4gc3R5bGU9J2NvbG9yOm1hcm9vbjtiYWNr Z3JvdW5kOndoaXRlJz54czplbGVtZW50PC9zcGFuPjwvZm9udD48Zm9udA0KY29sb3I9cmVkPjxz cGFuIHN0eWxlPSdjb2xvcjpyZWQ7YmFja2dyb3VuZDp3aGl0ZSc+IG5hbWU8L3NwYW4+PC9mb250 Pjxmb250DQpjb2xvcj1ibHVlPjxzcGFuIHN0eWxlPSdjb2xvcjpibHVlO2JhY2tncm91bmQ6d2hp dGUnPj0mcXVvdDs8L3NwYW4+PC9mb250Pjxmb250DQpjb2xvcj1ibGFjaz48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSc+dXVpZDwvc3Bhbj48L2ZvbnQ+PGZvbnQNCmNv bG9yPWJsdWU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWU7YmFja2dyb3VuZDp3aGl0ZSc+JnF1b3Q7 PC9zcGFuPjwvZm9udD48Zm9udA0KY29sb3I9cmVkPjxzcGFuIHN0eWxlPSdjb2xvcjpyZWQ7YmFj a2dyb3VuZDp3aGl0ZSc+IHR5cGU8L3NwYW4+PC9mb250Pjxmb250DQpjb2xvcj1ibHVlPjxzcGFu IHN0eWxlPSdjb2xvcjpibHVlO2JhY2tncm91bmQ6d2hpdGUnPj0mcXVvdDs8L3NwYW4+PC9mb250 Pjxmb250DQpjb2xvcj1ibGFjaz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2s7YmFja2dyb3VuZDp3 aGl0ZSc+eHM6dG9rZW48L3NwYW4+PC9mb250Pjxmb250DQpjb2xvcj1ibHVlPjxzcGFuIHN0eWxl PSdjb2xvcjpibHVlO2JhY2tncm91bmQ6d2hpdGUnPiZxdW90Ozwvc3Bhbj48L2ZvbnQ+PGZvbnQN CmNvbG9yPXJlZD48c3BhbiBzdHlsZT0nY29sb3I6cmVkO2JhY2tncm91bmQ6d2hpdGUnPiBtaW5P Y2N1cnM8L3NwYW4+PC9mb250Pjxmb250DQpjb2xvcj1ibHVlPjxzcGFuIHN0eWxlPSdjb2xvcjpi bHVlO2JhY2tncm91bmQ6d2hpdGUnPj0mcXVvdDs8L3NwYW4+PC9mb250Pjxmb250DQpjb2xvcj1i bGFjaz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSc+MDwvc3Bhbj48 L2ZvbnQ+PGZvbnQNCmNvbG9yPWJsdWU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWU7YmFja2dyb3Vu ZDp3aGl0ZSc+JnF1b3Q7LyZndDs8L3NwYW4+PC9mb250Pjxmb250DQpjb2xvcj1ibGFjaz48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSc+PG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWF1dG9zcGFjZTpu b25lJz48Zm9udCBzaXplPTMgY29sb3I9YmxhY2sNCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDoNCndoaXRl Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+ PGZvbnQgY29sb3I9Ymx1ZT48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZTtiYWNrZ3JvdW5kOndoaXRl Jz4mbHQ7Lzwvc3Bhbj48L2ZvbnQ+PGZvbnQNCmNvbG9yPW1hcm9vbj48c3BhbiBzdHlsZT0nY29s b3I6bWFyb29uO2JhY2tncm91bmQ6d2hpdGUnPnhzOnNlcXVlbmNlPC9zcGFuPjwvZm9udD48Zm9u dA0KY29sb3I9Ymx1ZT48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZTtiYWNrZ3JvdW5kOndoaXRlJz4m Z3Q7PC9zcGFuPjwvZm9udD48Zm9udA0KY29sb3I9YmxhY2s+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrO2JhY2tncm91bmQ6d2hpdGUnPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hdXRvc3BhY2U6bm9uZSc+PGZvbnQgc2l6ZT0z IGNvbG9yPWJsYWNrDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6DQp3aGl0ZSc+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjxmb250IGNvbG9yPWJsdWU+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsdWU7YmFja2dyb3VuZDp3aGl0ZSc+Jmx0Oy88L3NwYW4+PC9mb250Pjxmb250DQpjb2xv cj1tYXJvb24+PHNwYW4gc3R5bGU9J2NvbG9yOm1hcm9vbjtiYWNrZ3JvdW5kOndoaXRlJz54czpj b21wbGV4VHlwZTwvc3Bhbj48L2ZvbnQ+PGZvbnQNCmNvbG9yPWJsdWU+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsdWU7YmFja2dyb3VuZDp3aGl0ZSc+Jmd0Ozwvc3Bhbj48L2ZvbnQ+PGZvbnQNCmNvbG9y PWJsYWNrPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlJz48bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0z IGNvbG9yPWJsYWNrIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4NCnN0eWxlPSdmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUnPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu PjwvZm9udD48Zm9udCBjb2xvcj1ibHVlPjxzcGFuIHN0eWxlPSdjb2xvcjpibHVlO2JhY2tncm91 bmQ6d2hpdGUnPiZsdDsvPC9zcGFuPjwvZm9udD48Zm9udA0KY29sb3I9bWFyb29uPjxzcGFuIHN0 eWxlPSdjb2xvcjptYXJvb247YmFja2dyb3VuZDp3aGl0ZSc+eHM6ZWxlbWVudDwvc3Bhbj48L2Zv bnQ+PGZvbnQNCmNvbG9yPWJsdWU+PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWU7YmFja2dyb3VuZDp3 aGl0ZSc+Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu DQpzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibHVlJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+SG93ZXZl ciwgSSB3b3VsZCBiZSBzYXRpc2ZpZWQgaXQganVzdCB1dWlkIHdlcmUgaW5jbHVkZWQuPC9zcGFu PjwvZm9udD48Zm9udA0Kc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwnPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cD48Zm9udCBzaXplPTQgY29sb3I9cmVkIGZhY2U9IlNjcmlw dCBNVCBCb2xkIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDsNCmZvbnQtZmFtaWx5OiJT Y3JpcHQgTVQgQm9sZCI7Y29sb3I6cmVkJz5Cb2IgU2hlcnJ5LDwvc3Bhbj48L2ZvbnQ+PHN0cm9u Zz48Yj48Zm9udA0KZmFjZT0iU2NyaXB0IE1UIEJvbGQiPjxzcGFuIHN0eWxlPSdmb250LWZhbWls eToiU2NyaXB0IE1UIEJvbGQiJz4gPC9zcGFuPjwvZm9udD48L2I+PC9zdHJvbmc+PHN0cm9uZz48 Yj48Zm9udA0KY29sb3I9cmVkIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OkFy aWFsO2NvbG9yOnJlZCc+RU5QPC9zcGFuPjwvZm9udD48L2I+PC9zdHJvbmc+DQo8bzpwPjwvbzpw PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzdHJvbmc+PGI+PGZvbnQgc2l6ZT0zIGNvbG9y PXJlZCBmYWNlPSJBcmlhbCBOYXJyb3ciPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseToiQXJpYWwgTmFycm93Ijtjb2xvcjpyZWQnPkludHJhZG8gSW5jLjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L2I+PC9zdHJvbmc+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PHN0MTpTdHJlZXQgdzpzdD0ib24iPjxzdDE6YWRkcmVzcyB3OnN0PSJvbiI+PGZvbnQgc2l6ZT0x DQogIGNvbG9yPWdyYXkgZmFjZT0iQXJpYWwgTmFycm93Ij48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCBOYXJyb3ciOw0KICBjb2xvcjpncmF5Jz4zMDMwIFdh cnJlbnZpbGxlIFJkPC9zcGFuPjwvZm9udD48L3N0MTphZGRyZXNzPjwvc3QxOlN0cmVldD48Zm9u dA0Kc2l6ZT0xIGNvbG9yPWdyYXkgZmFjZT0iQXJpYWwgTmFycm93Ij48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5Og0KIkFyaWFsIE5hcnJvdyI7Y29sb3I6Z3JheSc+LCA0 PHN1cD50aDwvc3VwPiBGbG9vcjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0xDQpjb2xvcj1ncmF5 PjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC4wcHQ7Y29sb3I6Z3JheSc+PG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzdDE6cGxhY2UgdzpzdD0ib24i PjxzdDE6Q2l0eSB3OnN0PSJvbiI+PGZvbnQgc2l6ZT0xDQogIGNvbG9yPWdyYXkgZmFjZT0iQXJp YWwgTmFycm93Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiJBcmlh bCBOYXJyb3ciOw0KICBjb2xvcjpncmF5Jz5MaXNsZTwvc3Bhbj48L2ZvbnQ+PC9zdDE6Q2l0eT48 Zm9udCBzaXplPTEgY29sb3I9Z3JheQ0KIGZhY2U9IkFyaWFsIE5hcnJvdyI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseToiQXJpYWwgTmFycm93IjsNCiBjb2xvcjpncmF5 Jz4sIDxzdDE6U3RhdGUgdzpzdD0ib24iPklMPC9zdDE6U3RhdGU+IDxzdDE6UG9zdGFsQ29kZSB3 OnN0PSJvbiI+NjA1MzI8L3N0MTpQb3N0YWxDb2RlPjwvc3Bhbj48L2ZvbnQ+PC9zdDE6cGxhY2U+ PGZvbnQNCnNpemU9MSBjb2xvcj1ncmF5IGZhY2U9IkFyaWFsIE5hcnJvdyI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseToNCiJBcmlhbCBOYXJyb3ciO2NvbG9yOmdyYXkn PjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48aT48 Zm9udCBzaXplPTEgY29sb3I9Z3JheSBmYWNlPSJBcmlhbCBOYXJyb3ciPjxzcGFuDQpzdHlsZT0n Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCBOYXJyb3ciO2NvbG9yOmdyYXk7Zm9u dC1zdHlsZTppdGFsaWMnPmRpcmVjdDoNCjYzMC0zMDAtMjgzOCZuYnNwOyZuYnNwOyBtb2JpbGU6 IDYzMC04ODAtMzcwNDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L2k+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGk+PGZvbnQgc2l6ZT0xIGNvbG9yPWdyYXkgZmFjZT0iQXJpYWwgTmFycm93 Ij48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseToiQXJpYWwgTmFycm93 Ijtjb2xvcjpncmF5O2ZvbnQtc3R5bGU6aXRhbGljJz5mYXg6DQo3MjAtNDk0LTY2MDAmbmJzcDsg ZW1haWw6IFJvYmVydC5TaGVycnlAaW50cmFkby5jb208bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9pPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MSBjb2xvcj1ncmF5IGZh Y2U9IkFyaWFsIE5hcnJvdyI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p bHk6IkFyaWFsIE5hcnJvdyI7Y29sb3I6Z3JheSc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzdHJvbmc+PGI+PGZvbnQgc2l6ZT0zIGNv bG9yPXJlZCBmYWNlPSJBcmlhbCBOYXJyb3ciPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseToiQXJpYWwgTmFycm93Ijtjb2xvcjpyZWQnPkludHJhZG88L3NwYW4+PC9m b250Pjxmb250DQpjb2xvcj1yZWQ+PHNwYW4gc3R5bGU9J2NvbG9yOnJlZCc+PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvYj48L3N0cm9uZz48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3Ry b25nPjxiPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCBOYXJyb3ciPjxzcGFuDQpzdHlsZT0nZm9u dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCBOYXJyb3ciJz53d3cuaW50cmFkby5jb208 c3Bhbg0Kc3R5bGU9J2xheW91dC1ncmlkLW1vZGU6bGluZSc+IDx1Pjxmb250IGNvbG9yPWJsdWU+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWUnPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3U+PC9z cGFuPjwvc3Bhbj48L2ZvbnQ+PC9iPjwvc3Ryb25nPjwvcD4NCg0KPHA+PGZvbnQgc2l6ZT0zIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0K MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0K PC9kaXY+DQoNCjxicj48YnI+PHRhYmxlIGJnY29sb3I9d2hpdGUgc3R5bGU9ImNvbG9yOmJsYWNr Ij48dHI+PHRkPjxicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+ DQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2lzJm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7ZGVzaWdu YXRlZCZuYnNwO3JlY2lwaWVudCZuYnNwO29ubHkmbmJzcDthbmQmbmJzcDttYXk8YnI+DQpjb250 YWluJm5ic3A7cHJpdmlsZWdlZCwmbmJzcDtwcm9wcmlldGFyeSwmbmJzcDtvciZuYnNwO290aGVy d2lzZSZuYnNwO3ByaXZhdGUmbmJzcDtpbmZvcm1hdGlvbi4mbmJzcDsmbmJzcDs8YnI+DQpJZiZu YnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO2l0Jm5ic3A7aW4mbmJzcDtlcnJv ciwmbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtzZW5kZXI8YnI+DQppbW1l ZGlhdGVseSZuYnNwO2FuZCZuYnNwO2RlbGV0ZSZuYnNwO3RoZSZuYnNwO29yaWdpbmFsLiZuYnNw OyZuYnNwO0FueSZuYnNwO3VuYXV0aG9yaXplZCZuYnNwO3VzZSZuYnNwO29mPGJyPg0KdGhpcyZu YnNwO2VtYWlsJm5ic3A7aXMmbmJzcDtwcm9oaWJpdGVkLjxicj4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClttZjJdPC90ZD48L3RyPjwvdGFibGU+PC9ib2R5 Pg0KDQo8L2h0bWw+DQo= ------_=_NextPart_001_01C76A6E.27AB39C6-- --===============1452833885== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1452833885==-- From geopriv-bounces@ietf.org Mon Mar 19 20:54:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTSbg-0002hv-35; Mon, 19 Mar 2007 20:53:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTSbb-0002he-V8 for geopriv@ietf.org; Mon, 19 Mar 2007 20:53:39 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTSbG-0004j5-Nn for geopriv@ietf.org; Mon, 19 Mar 2007 20:53:39 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 19 Mar 2007 20:44:06 -0400 id 0158C3E4.45FF2E56.00003DCC In-Reply-To: <017c01c76a6d$3b241b30$37158182@cis.neustar.com> References: <017c01c76a6d$3b241b30$37158182@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <76D30645-90BC-4503-8F78-73D5C0817403@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Geopriv] GRUU in HELD Identities Date: Mon, 19 Mar 2007 20:47:53 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org On Mar 19, 2007, at 5:26 PM, Brian Rosen wrote: > I'm not sure how good of an idea this is > > 1. You probably need some other identifier that lets the registrar > associate a location with the endpoint. I'm not sure what that > would be. > Normally, the registrar doesn't have that kind of information. Any > device > that has the user's credentials is normally indistinguishable from > any other > device with those credentials. The GRUU can keep the devices > straight, so > that if there are more than one device which are simultaneously > registered > with the same AoR, the GRUU will be unique for that device. But it > doesn't > usually know where the device is. It doesn't usually have any other > information that a LIS could use to identify the device for location > purposes either. I guess that depends on the level of sophistication of your registrar. A good many registrars do create a binding between the endpoint, as much as it can be known through tricks like STUN, etc.., and AoR (and probably GRUU once it is more widely supported). > 2. A GRUU is pretty ephemeral. It's typically good as long as the > user > maintains a registration at the SIP registrar. That is pretty > useful for > the emergency case, and probably most other uses of location, but > it may not > be useful in some circumstances. > 3. You need a correlation between the LIS and the registrar, so it > probably only works in a situation where the access network and the > calling > network are operated by the same entity. I think this is the better point, but I see no reason not to have this identity for those environments where it could be used. We're not talking about disallowing other identifiers. -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 20 00:55:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTWMl-0003iS-EU; Tue, 20 Mar 2007 00:54:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTWMk-0003i8-3q for geopriv@ietf.org; Tue, 20 Mar 2007 00:54:34 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTWMi-0001I0-QE for geopriv@ietf.org; Tue, 20 Mar 2007 00:54:34 -0400 X-SEF-Processed: 5_0_0_910__2007_03_20_00_00_37 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); Tue, 20 Mar 2007 00:00:37 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 23:54:32 -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: [Geopriv] GRUU in HELD Identities Date: Mon, 19 Mar 2007 23:54:31 -0500 Message-ID: In-Reply-To: <76D30645-90BC-4503-8F78-73D5C0817403@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] GRUU in HELD Identities Thread-Index: AcdqioXYMPTEm4xeTdKrtf4dPzF//AAIUNhw From: "Winterbottom, James" To: "Andrew Newton" , "Brian Rosen" X-OriginalArrivalTime: 20 Mar 2007 04:54:32.0243 (UTC) FILETIME=[D962C830:01C76AAB] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Okay I will add a GRUU type in the next release of this draft.=0D=0A=0D=0A=0D= =0A> -----Original Message-----=0D=0A> From: Andrew Newton [mailto:andy@hxr= =2Eus]=0D=0A> Sent: Tuesday, 20 March 2007 11:48 AM=0D=0A> To: Brian Rosen=0D= =0A> Cc: geopriv@ietf.org=0D=0A> Subject: Re: [Geopriv] GRUU in HELD Identi= ties=0D=0A>=20=0D=0A>=20=0D=0A> On Mar 19, 2007, at 5:26 PM, Brian Rosen wr= ote:=0D=0A>=20=0D=0A> > I'm not sure how good of an idea this is=0D=0A> >=0D= =0A> > 1.=09You probably need some other identifier that lets the registrar=0D= =0A> > associate a location with the endpoint. I'm not sure what that=0D=0A= > > would be.=0D=0A> > Normally, the registrar doesn't have that kind of in= formation. Any=0D=0A> > device=0D=0A> > that has the user's credentials is= normally indistinguishable from=0D=0A> > any other=0D=0A> > device with th= ose credentials. The GRUU can keep the devices=0D=0A> > straight, so=0D=0A= > > that if there are more than one device which are simultaneously=0D=0A> = > registered=0D=0A> > with the same AoR, the GRUU will be unique for that d= evice. But it=0D=0A> > doesn't=0D=0A> > usually know where the device is. = It doesn't usually have any other=0D=0A> > information that a LIS could us= e to identify the device for location=0D=0A> > purposes either.=0D=0A>=20=0D= =0A> I guess that depends on the level of sophistication of your=0D=0A> reg= istrar. A good many registrars do create a binding between the=0D=0A> endp= oint, as much as it can be known through tricks like STUN, etc..,=0D=0A> an= d AoR (and probably GRUU once it is more widely supported).=0D=0A>=20=0D=0A= > > 2.=09A GRUU is pretty ephemeral. It's typically good as long as the=0D= =0A> > user=0D=0A> > maintains a registration at the SIP registrar. That i= s pretty=0D=0A> > useful for=0D=0A> > the emergency case, and probably most= other uses of location, but=0D=0A> > it may not=0D=0A> > be useful in some= circumstances.=0D=0A> > 3.=09You need a correlation between the LIS and th= e registrar, so it=0D=0A> > probably only works in a situation where the ac= cess network and the=0D=0A> > calling=0D=0A> > network are operated by the = same entity.=0D=0A>=20=0D=0A> I think this is the better point, but I see n= o reason not to have=0D=0A> this identity for those environments where it c= ould be used. We're=0D=0A> not talking about disallowing other identifiers= =2E=0D=0A>=20=0D=0A> -andy=0D=0A>=20=0D=0A> _______________________________= ________________=0D=0A> Geopriv mailing list=0D=0A> Geopriv@ietf.org=0D=0A>= https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A=0D=0A----------------= ---------------------------------------------------------------------------= -----=0D=0AThis message is for the designated recipient only and may=0D=0Ac= ontain privileged, proprietary, or otherwise private information. =20=0D=0A= If you have received it in error, please notify the sender=0D=0Aimmediately= and delete the original. Any unauthorized use of=0D=0Athis email is prohi= bited.=0D=0A---------------------------------------------------------------= ---------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 20 04:18: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 1HTZY2-00029F-5h; Tue, 20 Mar 2007 04:18:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTZY0-000299-Sd for geopriv@ietf.org; Tue, 20 Mar 2007 04:18:24 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTZXz-00037m-Cr for geopriv@ietf.org; Tue, 20 Mar 2007 04:18:24 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HTZXH-0006iG-Pk; Tue, 20 Mar 2007 03:17:40 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Geopriv] GRUU in HELD Identities Date: Tue, 20 Mar 2007 04:18:18 -0400 Message-ID: <025301c76ac8$5311d6f0$37158182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <76D30645-90BC-4503-8F78-73D5C0817403@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdqiVc8vc32Ixj4RAWZJSst3XtxPAAPbbFQ 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 - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I'm not following your thought in 1). Suppose I have 3 endpoints that register the same AoR. They have the credentials to do that, and the registrar permits that (say, it forks incoming calls to all of them). Are you aware of a registrar that could know which device was which? Most registrars I know that can handle more than one registration don't have any mechanism that would know the difference between the snom phone in my house, the cisco TA in my office and the Nokia handheld that walks around with me. They all have my credentials. They would each have a unique GRUU if they were all registered with my AoR, but which one was which would not be known to the registrar. Presence could very well know the difference, but not the registrar. Does your mileage vary? Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Monday, March 19, 2007 8:48 PM > To: Brian Rosen > Cc: 'Sherry, Robert'; geopriv@ietf.org > Subject: Re: [Geopriv] GRUU in HELD Identities > > > On Mar 19, 2007, at 5:26 PM, Brian Rosen wrote: > > > I'm not sure how good of an idea this is > > > > 1. You probably need some other identifier that lets the registrar > > associate a location with the endpoint. I'm not sure what that > > would be. > > Normally, the registrar doesn't have that kind of information. Any > > device > > that has the user's credentials is normally indistinguishable from > > any other > > device with those credentials. The GRUU can keep the devices > > straight, so > > that if there are more than one device which are simultaneously > > registered > > with the same AoR, the GRUU will be unique for that device. But it > > doesn't > > usually know where the device is. It doesn't usually have any other > > information that a LIS could use to identify the device for location > > purposes either. > > I guess that depends on the level of sophistication of your > registrar. A good many registrars do create a binding between the > endpoint, as much as it can be known through tricks like STUN, etc.., > and AoR (and probably GRUU once it is more widely supported). > > > 2. A GRUU is pretty ephemeral. It's typically good as long as the > > user > > maintains a registration at the SIP registrar. That is pretty > > useful for > > the emergency case, and probably most other uses of location, but > > it may not > > be useful in some circumstances. > > 3. You need a correlation between the LIS and the registrar, so it > > probably only works in a situation where the access network and the > > calling > > network are operated by the same entity. > > I think this is the better point, but I see no reason not to have > this identity for those environments where it could be used. We're > not talking about disallowing other identifiers. > > -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 20 06:04: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 1HTbCp-0001Li-5I; Tue, 20 Mar 2007 06:04:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbCo-0001IQ-EB for geopriv@ietf.org; Tue, 20 Mar 2007 06:04:38 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTbCm-0003nT-6a for geopriv@ietf.org; Tue, 20 Mar 2007 06:04:38 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 20 Mar 2007 06:00:23 -0400 id 015880EB.45FFB0B7.000055F6 In-Reply-To: <025301c76ac8$5311d6f0$37158182@cis.neustar.com> References: <025301c76ac8$5311d6f0$37158182@cis.neustar.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: [Geopriv] GRUU in HELD Identities Date: Tue, 20 Mar 2007 06:04:16 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org On Mar 20, 2007, at 4:18 AM, Brian Rosen wrote: > I'm not following your thought in 1). Suppose I have 3 endpoints that > register the same AoR. They have the credentials to do that, and the > registrar permits that (say, it forks incoming calls to all of > them). Are > you aware of a registrar that could know which device was which? Most > registrars I know that can handle more than one registration don't > have any > mechanism that would know the difference between the snom phone in > my house, > the cisco TA in my office and the Nokia handheld that walks around > with me. > They all have my credentials. They would each have a unique GRUU > if they > were all registered with my AoR, but which one was which would not > be known > to the registrar. Presence could very well know the difference, > but not the > registrar. I don't think it matters. The client asks the registrar for its location using the GRUU. The registrar looks at the GRUU-to-endpoint mapping that it has (which might be 10.0.0.5:48001), then consults its location table for the endpoint (most likely, a network map that says "network 10.0.0/24 is at 923 Main St., Topeka, KS"). Thinking about this entire space does make me ask one question: with the list of HELD identities topping 22 now, how is a client to know which identity to use? Does it send everything it has in hopes that the LIS supports just one of them? Certainly, every LIS will not support every type of identity. -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 20 11:45: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 1HTgWP-0001tf-1Q; Tue, 20 Mar 2007 11:45:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTgWN-0001r6-T1 for geopriv@ietf.org; Tue, 20 Mar 2007 11:45:12 -0400 Received: from [209.108.197.61] (helo=ns1.sccx.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTgWL-0002cm-Lg for geopriv@ietf.org; Tue, 20 Mar 2007 11:45:11 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] GRUU in HELD Identities X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 20 Mar 2007 10:45:01 -0500 Message-ID: <422D410BD61FC04185076AD99AA7207A022897C5@inilmx01.lgmt.trdo> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] GRUU in HELD Identities thread-index: AcdqVrEiIv68QoQmT36pUkqkKmgg6QAFyClQACYW7GA= References: <422D410BD61FC04185076AD99AA7207A02289654@inilmx01.lgmt.trdo> From: "Sherry, Robert" To: "Thomson, Martin" , X-OriginalArrivalTime: 20 Mar 2007 15:45:03.0393 (UTC) FILETIME=[B9C3A110:01C76B06] X-Spam-Score: 0.4 (/) X-Scan-Signature: 667ab3155b58f6148f26cdbf27b4043b Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0955205130==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============0955205130== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76B06.B87CE0E2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76B06.B87CE0E2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So according to the gruu draft a gruu can have three attributes: the Public gruu and Private gruu which are URIs and uuid However, the uuid is a fixed format and is what the UA would register with. This allows different UAs with the same TN. =20 To Brian's point uuids are globally unique so can be used in which ever network a UA can register. =20 Bob Sherry, ENP=20 Intrado Inc. 3030 Warrenville Rd, 4th Floor Lisle, IL 60532 direct: 630-300-2838 mobile: 630-880-3704 fax: 720-494-6600 email: Robert.Sherry@intrado.com =20 Intrado www.intrado.com=20 =20 ________________________________ From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=20 Sent: Monday, March 19, 2007 4:33 PM To: Sherry, Robert; geopriv@ietf.org Subject: RE: [Geopriv] GRUU in HELD Identities =20 Hi Bob, =20 A GRUU is just a SIP URI with special properties. If this is a necessary identifier (emphasis on "if", c.f. Brian's reply) the element can be used. I don't see any need to include additional parameters. =20 Cheers, Martin =20 ________________________________ From: Sherry, Robert [mailto:Robert.Sherry@intrado.com]=20 Sent: Tuesday, 20 March 2007 5:45 AM To: geopriv@ietf.org Subject: [Geopriv] GRUU in HELD Identities =20 This is a recommendation to add GRUUs to the list of heldDevice enumerations in draft-winterbottom-geopriv-held-identity-extensions-01.txt. =20 The GRUUs define a specific instance of a UA and are described in http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-12.txt =20 The schema might look as follows. gruu based upon draft-ietf-sip-gruu-12 =20 However, I would be satisfied it just uuid were included. =20 Bob Sherry, ENP=20 Intrado Inc. 3030 Warrenville Rd, 4th Floor Lisle, IL 60532 direct: 630-300-2838 mobile: 630-880-3704 fax: 720-494-6600 email: Robert.Sherry@intrado.com =20 Intrado www.intrado.com=20 =20 =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] =20 ------_=_NextPart_001_01C76B06.B87CE0E2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So according to the gruu draft a = gruu can have three attributes: the Public gruu and Private gruu which are URIs = and uuid

However, the uuid is a fixed format = and is what the UA would register with.

This allows different UAs with the = same TN.

To Brian’s point uuids are = globally unique so can be used in which ever network a UA can = register.

Bob = Sherry, ENP

Intrado = Inc.

3030 Warrenville = Rd, 4^th = Floor

Lisle, IL 60532

direct: 630-300-2838   mobile: = 630-880-3704

fax: 720-494-6600 email: = Robert.Sherry@intrado.com

Intrado

www.intrado.com =

From: = Thomson, Martin [mailto:Martin.Thomson@andrew.com]
Sent: Monday, March 19, = 2007 4:33 PM
To: Sherry, Robert; geopriv@ietf.org
Subject: RE: [Geopriv] = GRUU in HELD Identities

Hi = Bob,

A GRUU is just a SIP URI with = special properties. If this is a necessary identifier (emphasis on = “if”, c.f. Brian’s reply) the <link> element can be used. I = don’t see any need to include additional parameters.

Cheers,
Martin

From: = Sherry, Robert [mailto:Robert.Sherry@intrado.com]
Sent: Tuesday, 20 March = 2007 5:45 AM
To: geopriv@ietf.org
Subject: [Geopriv] GRUU = in HELD Identities

This is a recommendation to add GRUUs to the list of heldDevice enumerations in = draft-winterbottom-geopriv-held-identity-extensions-01.txt.

The GRUUs define a specific instance of a UA and are described in h= ttp://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-12.txt

The schema might look as = follows.

<xs:element name=3D"gruu">

           =              <xs:annotation>

           =             &= nbsp;            <xs:documentation>gruu based = upon draft-ietf-sip-gruu-12 </xs:documentation>

           =              </xs:annotation>

           =              <xs:complexType>

           =             &= nbsp;            <xs:sequence>

           =             &= nbsp;           &n= bsp;            <xs:element = name=3D"pub_gruu" = type=3D"xs:anyURI" = minOccurs=3D"0"/>

           =             &= nbsp;           &n= bsp;            <xs:element = name=3D"temp_gruu" = type=3D"xs:anyURI" = minOccurs=3D"0"/>

           =             &= nbsp;           &n= bsp;            <xs:element = name=3D"uuid" = type=3D"xs:token" = minOccurs=3D"0"/>

           =             &= nbsp;            </xs:sequence>

           =              </xs:complexType>

   = ;         </xs:element>

=
However, I would be satisfied it just uuid were = included.

Bob = Sherry, = ENP

Intrado = Inc.

3030 = Warrenville Rd, 4^th Floor

Lisle, = IL 60532

direct: 630-300-2838   mobile: = 630-880-3704

fax: 720-494-6600 email: = Robert.Sherry@intrado.com

Intrado

www.intrado.com

= -------------------------------------------------------------------------= -----------------------
= This message is for the designated recipien= t only and may
= contain privileged, proprietary, or otherwise pr= ivate information.
= If you have received it in error, plea= se notify the sender
= immediately and delete the original.  Any&n= bsp;unauthorized use of
this email is prohibited.
= -------------------------------------------------------------------------= -----------------------
[mf2]

------_=_NextPart_001_01C76B06.B87CE0E2-- --===============0955205130== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0955205130==-- From geopriv-bounces@ietf.org Tue Mar 20 11:50:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTgbZ-0000pn-CA; Tue, 20 Mar 2007 11:50:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTgbY-0000jC-3k for geopriv@ietf.org; Tue, 20 Mar 2007 11:50:32 -0400 Received: from 199-117-205-100.dia.static.qwest.net ([199.117.205.100] helo=ns2.sccx.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTgbW-0004rL-L5 for geopriv@ietf.org; Tue, 20 Mar 2007 11:50:32 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] GRUU in HELD Identities X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 20 Mar 2007 10:50:22 -0500 Message-ID: <422D410BD61FC04185076AD99AA7207A022897CE@inilmx01.lgmt.trdo> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] GRUU in HELD Identities thread-index: Acdq1yFbMzZ3jnDdQVO2Qp99tLkTCQAL947w References: <025301c76ac8$5311d6f0$37158182@cis.neustar.com> From: "Sherry, Robert" To: "Andrew Newton" , "Brian Rosen" X-OriginalArrivalTime: 20 Mar 2007 15:50:25.0296 (UTC) FILETIME=[79A22100:01C76B07] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I think there has to be a correlation between the identity that is registered and the identity that the LIS knows. I would expect a type of UA to use only one identity. (Although I could see TN and MAC. With MAC being the unique identifier and TN used for tracking or logging.) The LIS would have to support many types of identities depending upon what types of access networks it supports. Bob Sherry, ENP=20 Intrado Inc. 3030 Warrenville Rd, 4th Floor Lisle, IL 60532 direct: 630-300-2838 mobile: 630-880-3704 fax: 720-494-6600 email: Robert.Sherry@intrado.com =20 Intrado www.intrado.com=20 =20 -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Tuesday, March 20, 2007 5:04 AM To: Brian Rosen Cc: Sherry, Robert; geopriv@ietf.org Subject: Re: [Geopriv] GRUU in HELD Identities On Mar 20, 2007, at 4:18 AM, Brian Rosen wrote: > I'm not following your thought in 1). Suppose I have 3 endpoints that > register the same AoR. They have the credentials to do that, and the > registrar permits that (say, it forks incoming calls to all of =20 > them). Are > you aware of a registrar that could know which device was which? Most > registrars I know that can handle more than one registration don't =20 > have any > mechanism that would know the difference between the snom phone in =20 > my house, > the cisco TA in my office and the Nokia handheld that walks around =20 > with me. > They all have my credentials. They would each have a unique GRUU =20 > if they > were all registered with my AoR, but which one was which would not =20 > be known > to the registrar. Presence could very well know the difference, =20 > but not the > registrar. I don't think it matters. The client asks the registrar for its =20 location using the GRUU. The registrar looks at the GRUU-to-endpoint =20 mapping that it has (which might be 10.0.0.5:48001), then consults =20 its location table for the endpoint (most likely, a network map that =20 says "network 10.0.0/24 is at 923 Main St., Topeka, KS"). Thinking about this entire space does make me ask one question: with =20 the list of HELD identities topping 22 now, how is a client to know =20 which identity to use? Does it send everything it has in hopes that =20 the LIS supports just one of them? Certainly, every LIS will not =20 support every type of identity. -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 20 13:07:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HThnk-0003S5-3q; Tue, 20 Mar 2007 13:07:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HThne-0003Od-2o for geopriv@ietf.org; Tue, 20 Mar 2007 13:07:06 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HThjb-0004nw-8C for geopriv@ietf.org; Tue, 20 Mar 2007 13:02:56 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 20 Mar 2007 12:58:52 -0400 id 0158805F.460012CC.00004DCA In-Reply-To: <422D410BD61FC04185076AD99AA7207A022897CE@inilmx01.lgmt.trdo> References: <025301c76ac8$5311d6f0$37158182@cis.neustar.com> <422D410BD61FC04185076AD99AA7207A022897CE@inilmx01.lgmt.trdo> Mime-Version: 1.0 Message-Id: From: Andrew Newton Subject: Re: [Geopriv] GRUU in HELD Identities Date: Tue, 20 Mar 2007 13:02:47 -0400 To: "Sherry, Robert" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1374577855==" Errors-To: geopriv-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1374577855== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-19917-1174409937-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-19917-1174409937-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Mar 20, 2007, at 11:50 AM, Sherry, Robert wrote: > I think there has to be a correlation between the identity that is > registered and the identity that the LIS knows. > I would expect a type of UA to use only one identity. > (Although I could see TN and MAC. With MAC being the unique identifier > and TN used for tracking or logging.) > The LIS would have to support many types of identities depending upon > what types of access networks it supports. Naturally, the LIS can only usefully support the identities relevant to the networks in which it is deployed. However, a client can be deployed in many types of networks and can jump from one type to another. How does it know which identity to send to the LIS? -andy --=_zeke.ecotroph.net-19917-1174409937-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.54.2
On Mar 20, 2007, at 11:= 50 AM, Sherry, Robert wrote:

<= FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">I thi= nk there has to be a correlation between the identity that is
=
registered and the identity that = the LIS knows.

I woul= d expect a type of UA to use only one identity.

(Although I could see TN and MAC. With MAC being = the unique identifier

and TN used for tracking or logging.)

The LIS would have to support many types of identities = depending upon

what t= ypes of access networks it supports.

Naturally, the LIS can only usefully support the identities relevant t= o the networks in which it is deployed.=A0 However, a client can be deplo= yed in many types of networks and can jump from one type to another.=A0 H= ow does it know which identity to send to the LIS?

-andy
--=_zeke.ecotroph.net-19917-1174409937-0001-2-- --===============1374577855== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1374577855==-- From geopriv-bounces@ietf.org Tue Mar 20 13:21:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTi1Q-00057X-Q0; Tue, 20 Mar 2007 13:21:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTi1P-00057M-5p for geopriv@ietf.org; Tue, 20 Mar 2007 13:21:19 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTi1L-0007jD-7j for geopriv@ietf.org; Tue, 20 Mar 2007 13:21:19 -0400 Received: (qmail invoked by alias); 20 Mar 2007 17:21:14 -0000 Received: from dhcp-1453.ietf68.org (EHLO [130.129.20.83]) [130.129.20.83] by mail.gmx.net (mp023) with SMTP; 20 Mar 2007 18:21:14 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+ev5px8X6e8wAdwawmikncdq4FjIU78XCXXthSBa fqJQXmodaaRyZE Message-ID: <46001808.90001@gmx.net> Date: Tue, 20 Mar 2007 18:21:12 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Geopriv] GRUU in HELD Identities References: <025301c76ac8$5311d6f0$37158182@cis.neustar.com> <422D410BD61FC04185076AD99AA7207A022897CE@inilmx01.lgmt.trdo> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org The end host sends all identities it has to the LIS --> great for privacy. Ciao Hannes Andrew Newton wrote: > > On Mar 20, 2007, at 11:50 AM, Sherry, Robert wrote: > >> I think there has to be a correlation between the identity that is >> registered and the identity that the LIS knows. >> I would expect a type of UA to use only one identity. >> (Although I could see TN and MAC. With MAC being the unique identifier >> and TN used for tracking or logging.) >> The LIS would have to support many types of identities depending upon >> what types of access networks it supports. > > Naturally, the LIS can only usefully support the identities relevant > to the networks in which it is deployed. However, a client can be > deployed in many types of networks and can jump from one type to > another. How does it know which identity to send to the LIS? > > -andy > ------------------------------------------------------------------------ > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 20 13:42: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 1HTiLO-00068d-De; Tue, 20 Mar 2007 13:41:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTiLN-00067O-BJ for geopriv@ietf.org; Tue, 20 Mar 2007 13:41:57 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTiLI-0003C0-9Q for geopriv@ietf.org; Tue, 20 Mar 2007 13:41:57 -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 1HTiLF-0006lj-48; Tue, 20 Mar 2007 13:41:49 -0400 Message-ID: <46001CD6.7040600@bbn.com> Date: Tue, 20 Mar 2007 18:41:42 +0100 From: Richard Barnes User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Geopriv] GRUU in HELD Identities References: <025301c76ac8$5311d6f0$37158182@cis.neustar.com> <422D410BD61FC04185076AD99AA7207A022897CE@inilmx01.lgmt.trdo> 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: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org If we had some taxonomy (say, an IANA registry?) on classes of these identifiers, couldn't this be part of the LIS discovery? Result of discovery is: "Here's the LIS to contact, and the identifiers to send." --Richard Andrew Newton wrote: > > On Mar 20, 2007, at 11:50 AM, Sherry, Robert wrote: > >> I think there has to be a correlation between the identity that is >> >> registered and the identity that the LIS knows. >> >> I would expect a type of UA to use only one identity. >> >> (Although I could see TN and MAC. With MAC being the unique identifier >> >> and TN used for tracking or logging.) >> >> The LIS would have to support many types of identities depending upon >> >> what types of access networks it supports. >> > > Naturally, the LIS can only usefully support the identities relevant to > the networks in which it is deployed. However, a client can be deployed > in many types of networks and can jump from one type to another. How > does it know which identity to send to the LIS? > > -andy > > > ------------------------------------------------------------------------ > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 20 13:59:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTic7-0004IY-Al; Tue, 20 Mar 2007 13:59:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTic6-0004IS-UL for geopriv@ietf.org; Tue, 20 Mar 2007 13:59:14 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTibz-0005sF-PE for geopriv@ietf.org; Tue, 20 Mar 2007 13:59:14 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 20 Mar 2007 13:54:44 -0400 id 015887FF.46001FE4.000068E9 In-Reply-To: <46001CD6.7040600@bbn.com> References: <025301c76ac8$5311d6f0$37158182@cis.neustar.com> <422D410BD61FC04185076AD99AA7207A022897CE@inilmx01.lgmt.trdo> <46001CD6.7040600@bbn.com> Mime-Version: 1.0 Message-Id: <50D2662E-C637-4B01-B605-9C74004A5A96@hxr.us> From: Andrew Newton Subject: Re: [Geopriv] GRUU in HELD Identities Date: Tue, 20 Mar 2007 13:58:40 -0400 To: Richard Barnes X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1576466845==" Errors-To: geopriv-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1576466845== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-26921-1174413309-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-26921-1174413309-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Mar 20, 2007, at 1:41 PM, Richard Barnes wrote: > If we had some taxonomy (say, an IANA registry?) on classes of > these identifiers, couldn't this be part of the LIS discovery? > Result of discovery is: "Here's the LIS to contact, and the > identifiers to send." As Hannes noted, we have fairly serious privacy and security issue here. Even if you only send an identifier that is part of discovery, only identifiers truly associated with the network avoids problems. Accidently attaching to a wireless network run by Evil, Inc. and automatically sending your telephone number or private GRUU is probably not a good idea. -andy --=_zeke.ecotroph.net-26921-1174413309-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.54.2
On Mar 20, 2007, at 1:4= 1 PM, Richard Barnes wrote:

=
If we = had some taxonomy (say, an IANA registry?) on classes of these identifier= s, couldn't this be part of the LIS discovery?=A0 Result of discovery is: "Here's the LIS to contact, = and the identifiers to send."

As H= annes noted, we have fairly serious privacy and security issue here.=A0 E= ven if you only send an identifier that is part of discovery, only identi= fiers truly associated with the network avoids problems.

Accidently attaching to a wire= less network run by Evil, Inc. and automatically sending your telephone n= umber or private GRUU is probably not a good idea.

-andy
--=_zeke.ecotroph.net-26921-1174413309-0001-2-- --===============1576466845== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1576466845==-- From geopriv-bounces@ietf.org Tue Mar 20 14:32: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 1HTj82-00013z-6s; Tue, 20 Mar 2007 14:32:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTj80-00013p-Sp for geopriv@ietf.org; Tue, 20 Mar 2007 14:32:12 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTj7t-00033j-5b for geopriv@ietf.org; Tue, 20 Mar 2007 14:32:12 -0400 Received: from ([139.76.131.83]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.18554012; Tue, 20 Mar 2007 14:31:40 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 20 Mar 2007 14:31:40 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 20 Mar 2007 14:31:40 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] GRUU in HELD Identities Date: Tue, 20 Mar 2007 14:31:39 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA03393FF0@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Importance: normal Priority: normal Thread-Topic: [Geopriv] GRUU in HELD Identities Thread-Index: AcdrEmI4/EEJoRN+SqG2HtF5jVeMFwABxOIw References: <025301c76ac8$5311d6f0$37158182@cis.neustar.com><422D410BD61FC04185076AD99AA7207A022897CE@inilmx01.lgmt.trdo> From: "Stark, Barbara" To: "Andrew Newton" , "Sherry, Robert" X-OriginalArrivalTime: 20 Mar 2007 18:31:40.0227 (UTC) FILETIME=[00577130:01C76B1E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1553019712==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============1553019712== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76B1E.0058CF8A" Content-Transfer-Encoding: 7bit This is a multi-part message in MIME format. ------_=_NextPart_001_01C76B1E.0058CF8A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable For a consumer-grade end device that's not knowingly connecting to a mobile network, it doesn't look too bad, to me. I see ipV4 and ipV6. And a device should know whether the IP address that it wants to use is v4 or v6. mac and lldp look like they could be optionally used when a location assertion is being done, but I wouldn't use them for a LIS query (to acquire location). I'm not sure how useful ssid is, but I can't think of a really good application for it. Especially not for consumer devices. =20 For LIS-LIS, the querying LIS is going to have to know what identifiers it needs to use for a particular access network LIS. That will be programmatically defined in the querrying LIS, and shouldn't be difficult. This includes atm, vlan, l2tp, nas-ip-address, and nas-identifier. I'm not sure how dhcp or access-node-id would be used, but they aren't things that would be known by an end device. =20 For mobile devices, I'm clueless as to what they would be doing. It looks like it might depend on the type of network they're connecting to? I think the following apply to mobile devices: msisdn, imsi, directorynumber, imei, mdn, min. =20 extension looks like it would only work on devices intended to operate in a PBX environment. If that's the case, I would expect it to be a non-consumer, custom, closed environment. =20 Which leaves link and depend, where link is anything you want it to be (and therefore only useful in custom, closed environments), and depend is associated with the signatures that we haven't resolved. =20 So, I don't really see what the problem is with this long list. There's flexibility for custom, closed environments, and for LIS-LIS, but regular consumer devices aren't burdened with lots of IDs. Unless there are too many mobile identifiers, since I don't know about those things.=20 Barbara ________________________________ From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Tuesday, March 20, 2007 1:03 PM To: Sherry, Robert Cc: geopriv@ietf.org Subject: Re: [Geopriv] GRUU in HELD Identities On Mar 20, 2007, at 11:50 AM, Sherry, Robert wrote: I think there has to be a correlation between the identity that is registered and the identity that the LIS knows. I would expect a type of UA to use only one identity. (Although I could see TN and MAC. With MAC being the unique identifier and TN used for tracking or logging.) The LIS would have to support many types of identities depending upon what types of access networks it supports. Naturally, the LIS can only usefully support the identities relevant to the networks in which it is deployed. However, a client can be deployed in many types of networks and can jump from one type to another. How does it know which identity to send to the LIS? -andy ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA622 ------_=_NextPart_001_01C76B1E.0058CF8A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
For a consumer-grade end device that's not = knowingly=20 connecting to a mobile network, it doesn't look too bad, to me. I see = ipV4 and=20 ipV6. And a device should know whether the IP address that it wants to = use is v4=20 or v6. mac and lldp look like they could be optionally used when a = location=20 assertion is being done, but I wouldn't use them for a LIS query (to = acquire=20 location). I'm not sure how useful ssid is, but I can't think of a = really good=20 application for it. Especially not for consumer = devices.

For LIS-LIS, the querying LIS is going to have = to know what=20 identifiers it needs to use for a particular access network LIS. That = will be=20 programmatically defined in the querrying LIS, and shouldn't be = difficult. This=20 includes atm, vlan, l2tp, nas-ip-address, and nas-identifier. I'm not = sure how=20 dhcp or access-node-id would be used, but they aren't things that = would be=20 known by an end device.

For mobile devices, I'm clueless as to what = they would be=20 doing. It looks like it might depend on the type of network they're = connecting=20 to? I think the following apply to mobile devices: msisdn, imsi,=20 directorynumber, imei, mdn, min.

extension looks like it would only work on = devices intended=20 to operate in a PBX environment. If that's the case, I would expect it = to be a=20 non-consumer, custom, closed environment.

Which leaves link and depend, where link is = anything you=20 want it to be (and therefore only useful in custom, closed = environments), and=20 depend is associated with the signatures that we haven't=20 resolved.

So, I don't really see what the problem is with = this long=20 list. There's flexibility for custom, closed environments, and for = LIS-LIS, but=20 regular consumer devices aren't burdened with lots of IDs. Unless there = are too=20 many mobile identifiers, since I don't know about those things.=20

Barbara

From: Andrew Newton = [mailto:andy@hxr.us]=20
Sent: Tuesday, March 20, 2007 1:03 PM
To: Sherry,=20 Robert
Cc: geopriv@ietf.org
Subject: Re: [Geopriv] = GRUU in=20 HELD Identities

On Mar 20, 2007, at 11:50 AM, Sherry, Robert wrote:

I think there has to be a correlation between the identity = that=20 is

registered and the identity that the LIS knows.

I would expect a type of UA to use only one = identity.

(Although I could see TN and MAC. With MAC being the unique=20 identifier

and TN used for tracking or logging.)

The LIS would have to support many types of identities = depending=20 upon

what types of access networks it=20 supports.

Naturally, the LIS can only usefully support the identities = relevant to the=20 networks in which it is deployed. However, a client can be = deployed in=20 many types of networks and can jump from one type to another. How = does it=20 know which identity to send to the LIS?

-andy

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. GA622
------_=_NextPart_001_01C76B1E.0058CF8A-- --===============1553019712== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1553019712==-- From geopriv-bounces@ietf.org Tue Mar 20 15:12: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 1HTjkS-0004OA-3w; Tue, 20 Mar 2007 15:11:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTjkR-0004Nz-AQ for geopriv@ietf.org; Tue, 20 Mar 2007 15:11:55 -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 1HTjk1-0003FH-Lh for geopriv@ietf.org; Tue, 20 Mar 2007 15:11:55 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 20 Mar 2007 15:07:09 -0400 id 015884C7.460030DD.0000235C In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA03393FF0@crexc41p> References: <025301c76ac8$5311d6f0$37158182@cis.neustar.com><422D410BD61FC04185076AD99AA7207A022897CE@inilmx01.lgmt.trdo> <7582BC68E4994F4ABF0BD4723975C3FA03393FF0@crexc41p> 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: [Geopriv] GRUU in HELD Identities Date: Tue, 20 Mar 2007 15:11:05 -0400 To: "Stark, Barbara" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Barbara, Thanks for pointing out that some of the identifiers are not relevant to LCP and only relevant to LIS-to-LIS. However, msisdn, directoryNumber, mdn, and extension all seem to be phone numbers (or part of one) that can be used externally of the specific network and which can be tracked back to the user. That's a privacy issue. Additionally, imsi, imei, and min appear to be tied to specific devices, which can also be related back to a user. Again, that's a privacy issue. And while link sounds useful, if the client doesn't know when to send it, then it could also potentially leak user sensitive information. Finally, GRUUs that contain an AoR might also leak user sensitive information. -andy On Mar 20, 2007, at 2:31 PM, Stark, Barbara wrote: > For a consumer-grade end device that's not knowingly connecting to > a mobile network, it doesn't look too bad, to me. I see ipV4 and > ipV6. And a device should know whether the IP address that it wants > to use is v4 or v6. mac and lldp look like they could be optionally > used when a location assertion is being done, but I wouldn't use > them for a LIS query (to acquire location). I'm not sure how useful > ssid is, but I can't think of a really good application for it. > Especially not for consumer devices. > > For LIS-LIS, the querying LIS is going to have to know what > identifiers it needs to use for a particular access network LIS. > That will be programmatically defined in the querrying LIS, and > shouldn't be difficult. This includes atm, vlan, l2tp, nas-ip- > address, and nas-identifier. I'm not sure how dhcp or access-node- > id would be used, but they aren't things that would be known by an > end device. > > For mobile devices, I'm clueless as to what they would be doing. It > looks like it might depend on the type of network they're > connecting to? I think the following apply to mobile devices: > msisdn, imsi, directorynumber, imei, mdn, min. > > extension looks like it would only work on devices intended to > operate in a PBX environment. If that's the case, I would expect it > to be a non-consumer, custom, closed environment. > > Which leaves link and depend, where link is anything you want it to > be (and therefore only useful in custom, closed environments), and > depend is associated with the signatures that we haven't resolved. > > So, I don't really see what the problem is with this long list. > There's flexibility for custom, closed environments, and for LIS- > LIS, but regular consumer devices aren't burdened with lots of IDs. > Unless there are too many mobile identifiers, since I don't know > about those things. > Barbara > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Tuesday, March 20, 2007 1:03 PM > To: Sherry, Robert > Cc: geopriv@ietf.org > Subject: Re: [Geopriv] GRUU in HELD Identities > > > On Mar 20, 2007, at 11:50 AM, Sherry, Robert wrote: > >> I think there has to be a correlation between the identity that is >> registered and the identity that the LIS knows. >> I would expect a type of UA to use only one identity. >> (Although I could see TN and MAC. With MAC being the unique >> identifier >> and TN used for tracking or logging.) >> The LIS would have to support many types of identities depending upon >> what types of access networks it supports. > > Naturally, the LIS can only usefully support the identities > relevant to the networks in which it is deployed. However, a > client can be deployed in many types of networks and can jump from > one type to another. How does it know which identity to send to > the LIS? > > -andy > ***** > > The information transmitted is intended only for the person or > entity to which it is addressed and may contain confidential, > proprietary, and/or privileged material. Any review, > retransmission, dissemination or other use of, or taking of any > action in reliance upon this information by persons or entities > other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material > from all computers. GA622 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 20 18:07:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTmTe-0004SF-Co; Tue, 20 Mar 2007 18:06:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTmSO-00044a-Mx for geopriv@ietf.org; Tue, 20 Mar 2007 18:05:28 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTmKk-0005bW-20 for geopriv@ietf.org; Tue, 20 Mar 2007 17:57:35 -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 1HTmKh-0006k2-4e; Tue, 20 Mar 2007 17:57:31 -0400 Message-ID: <460058C1.80204@bbn.com> Date: Tue, 20 Mar 2007 22:57:21 +0100 From: Richard Barnes User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Geopriv] GRUU in HELD Identities References: <025301c76ac8$5311d6f0$37158182@cis.neustar.com><422D410BD61FC04185076AD99AA7207A022897CE@inilmx01.lgmt.trdo> <7582BC68E4994F4ABF0BD4723975C3FA03393FF0@crexc41p> 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: 944ecb6e61f753561f559a497458fb4f Cc: geopriv@ietf.org, "Stark, Barbara" X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org > Additionally, imsi, imei, and min appear to be tied to specific devices, > which can also be related back to a user. Again, that's a privacy issue. OK, I'm a confused here. In order to locate something, you need to identify a unique physical thing to locate. But you're saying that transmitting something that identifies a unique physical thing is a privacy violation? I'm not an expert here, but aren't those identifiers transmitted to the access network anyway, as part of the attachment process? (And analogously for other physical/MAC-layer identifiers in other scenarios.) If that's the case, then how is using them to query a LIS controlled by the access network any more a privacy violation? --RB > > And while link sounds useful, if the client doesn't know when to send > it, then it could also potentially leak user sensitive information. > > Finally, GRUUs that contain an AoR might also leak user sensitive > information. > > -andy > > On Mar 20, 2007, at 2:31 PM, Stark, Barbara wrote: > >> For a consumer-grade end device that's not knowingly connecting to a >> mobile network, it doesn't look too bad, to me. I see ipV4 and ipV6. >> And a device should know whether the IP address that it wants to use >> is v4 or v6. mac and lldp look like they could be optionally used when >> a location assertion is being done, but I wouldn't use them for a LIS >> query (to acquire location). I'm not sure how useful ssid is, but I >> can't think of a really good application for it. Especially not for >> consumer devices. >> >> For LIS-LIS, the querying LIS is going to have to know what >> identifiers it needs to use for a particular access network LIS. That >> will be programmatically defined in the querrying LIS, and shouldn't >> be difficult. This includes atm, vlan, l2tp, nas-ip-address, and >> nas-identifier. I'm not sure how dhcp or access-node-id would be used, >> but they aren't things that would be known by an end device. >> >> For mobile devices, I'm clueless as to what they would be doing. It >> looks like it might depend on the type of network they're connecting >> to? I think the following apply to mobile devices: msisdn, imsi, >> directorynumber, imei, mdn, min. >> >> extension looks like it would only work on devices intended to operate >> in a PBX environment. If that's the case, I would expect it to be a >> non-consumer, custom, closed environment. >> >> Which leaves link and depend, where link is anything you want it to be >> (and therefore only useful in custom, closed environments), and depend >> is associated with the signatures that we haven't resolved. >> >> So, I don't really see what the problem is with this long list. >> There's flexibility for custom, closed environments, and for LIS-LIS, >> but regular consumer devices aren't burdened with lots of IDs. Unless >> there are too many mobile identifiers, since I don't know about those >> things. >> Barbara >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Tuesday, March 20, 2007 1:03 PM >> To: Sherry, Robert >> Cc: geopriv@ietf.org >> Subject: Re: [Geopriv] GRUU in HELD Identities >> >> >> On Mar 20, 2007, at 11:50 AM, Sherry, Robert wrote: >> >>> I think there has to be a correlation between the identity that is >>> registered and the identity that the LIS knows. >>> I would expect a type of UA to use only one identity. >>> (Although I could see TN and MAC. With MAC being the unique identifier >>> and TN used for tracking or logging.) >>> The LIS would have to support many types of identities depending upon >>> what types of access networks it supports. >> >> Naturally, the LIS can only usefully support the identities relevant >> to the networks in which it is deployed. However, a client can be >> deployed in many types of networks and can jump from one type to >> another. How does it know which identity to send to the LIS? >> >> -andy >> ***** >> >> The information transmitted is intended only for the person or entity >> to which it is addressed and may contain confidential, proprietary, >> and/or privileged material. Any review, retransmission, dissemination >> or other use of, or taking of any action in reliance upon this >> information by persons or entities other than the intended recipient >> is prohibited. If you received this in error, please contact the >> sender and delete the material from all computers. GA622 > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 20 18:49:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTn8N-000801-8B; Tue, 20 Mar 2007 18:48:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTn8L-0007zY-Ip for geopriv@ietf.org; Tue, 20 Mar 2007 18:48:49 -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 1HTn8J-00046l-Am for geopriv@ietf.org; Tue, 20 Mar 2007 18:48:49 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 20 Mar 2007 18:44:46 -0400 id 0158810A.460063DE.000006F2 In-Reply-To: <460058C1.80204@bbn.com> References: <025301c76ac8$5311d6f0$37158182@cis.neustar.com><422D410BD61FC04185076AD99AA7207A022897CE@inilmx01.lgmt.trdo> <7582BC68E4994F4ABF0BD4723975C3FA03393FF0@crexc41p> <460058C1.80204@bbn.com> Mime-Version: 1.0 Message-Id: <93961821-3011-4BD9-9361-60F10906D7EB@hxr.us> From: Andrew Newton Subject: Re: [Geopriv] GRUU in HELD Identities Date: Tue, 20 Mar 2007 18:48:44 -0400 To: Richard Barnes X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: geopriv@ietf.org, "Stark, Barbara" X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0021390167==" Errors-To: geopriv-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0021390167== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-1781-1174430686-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-1781-1174430686-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Mar 20, 2007, at 5:57 PM, Richard Barnes wrote: > I'm not an expert here, but aren't those identifiers transmitted to > the access network anyway, as part of the attachment process? (And > analogously for other physical/MAC-layer identifiers in other > scenarios.) If that's the case, then how is using them to query a > LIS controlled by the access network any more a privacy violation? Admittedly, you have a point. Though a MAC is only required to be unique on a network, and therefore could be changed by the user. Still, I don't know many people who do that, or even know how. I don't know how imsi, imei, and min are administered. -andy --=_zeke.ecotroph.net-1781-1174430686-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.54.2
On Mar 20, 2007, at 5:5= 7 PM, Richard Barnes wrote:

=
I'm no= t an expert here, but aren't those identifiers transmitted to the access = network anyway, as part of the attachment process?=A0 (And analogously for other physical/MAC-layer i= dentifiers in other scenarios.)=A0 = If that's the case, then how is using them to query a LIS controll= ed by the access network any more a privacy violation?

Admittedly, you have a point.

Though a MAC is only required to be = unique on a network, and therefore could be changed by the user.=A0 Still= , I don't know many people who do that, or even know how.=A0 I don't know = how=A0imsi, imei, and min are administered.

-andy
--=_zeke.ecotroph.net-1781-1174430686-0001-2-- --===============0021390167== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0021390167==-- From geopriv-bounces@ietf.org Tue Mar 20 19:01: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 1HTnKG-00053j-CK; Tue, 20 Mar 2007 19:01:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTnKF-00051i-UT for geopriv@ietf.org; Tue, 20 Mar 2007 19:01:07 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTnK9-0005iH-U0 for geopriv@ietf.org; Tue, 20 Mar 2007 19:01:07 -0400 X-SEF-Processed: 5_0_0_910__2007_03_20_18_07_07 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); Tue, 20 Mar 2007 18:07:07 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 18:01:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] GRUU in HELD Identities Date: Tue, 20 Mar 2007 18:00:59 -0500 Message-ID: In-Reply-To: <93961821-3011-4BD9-9361-60F10906D7EB@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] GRUU in HELD Identities Thread-Index: AcdrQkaaXYIjAW2BRUS4CVr5D1dBUQAAJ1Kw From: "Thomson, Martin" To: "Andrew Newton" , "Richard Barnes" X-OriginalArrivalTime: 20 Mar 2007 23:01:01.0265 (UTC) FILETIME=[A1122410:01C76B43] X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: geopriv@ietf.org, "Stark, Barbara" X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1035181454==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============1035181454== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76B43.A0FAB99B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76B43.A0FAB99B Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SU1TSSBpcyBhc3NpZ25lZCB0byBhIG1vYmlsZSBTSU0uICBJTUVJIGlzIGFzc2lnbmVkIHRvIHRo ZSBhY3R1YWwgaGFyZHdhcmUuIE1JTiBpcyBsaWtld2lzZSBhc3NpZ25lZCB0byBoYXJkd2FyZSAo bm8gVUlDQyBpbiBJUy05NS9DRE1BMjAwMCkuICBOb25lIG9mIHRoZXNlIGNhbiBiZSBjaGFuZ2Vk LCBhbmQgYXJlIGdsb2JhbGx5IHVuaXF1ZS4gDQoNCiANCg0KTUFDIGNhbiBiZSBjaGFuZ2VkIGZv ciBzb21lIGRldmljZXMsIGJ1dCB0aGlzIGlzIGEgcmVjZW50IGRldmVsb3BtZW50LiAgU29tZW9u ZSBhdCB0aGUgb2ZmaWNlIGhlcmUgYm91Z2h0IGEgbW90aGVyYm9hcmQgdGhhdCBoYXMgYSBCSU9T IHNldHRpbmcgZm9yIE1BQyBhZGRyZXNzLiAgVGhlIGRlZmF1bHQgaXMgMDA6MDA6MDA6MDA6MDA6 MDAuDQoNCiANCg0KTQ0KDQogDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN CkZyb206IEFuZHJldyBOZXd0b24gW21haWx0bzphbmR5QGh4ci51c10gDQpTZW50OiBXZWRuZXNk YXksIDIxIE1hcmNoIDIwMDcgOTo0OSBBTQ0KVG86IFJpY2hhcmQgQmFybmVzDQpDYzogZ2VvcHJp dkBpZXRmLm9yZzsgU3RhcmssIEJhcmJhcmENClN1YmplY3Q6IFJlOiBbR2VvcHJpdl0gR1JVVSBp biBIRUxEIElkZW50aXRpZXMNCg0KIA0KDQogDQoNCk9uIE1hciAyMCwgMjAwNywgYXQgNTo1NyBQ TSwgUmljaGFyZCBCYXJuZXMgd3JvdGU6DQoNCg0KDQoNCg0KSSdtIG5vdCBhbiBleHBlcnQgaGVy ZSwgYnV0IGFyZW4ndCB0aG9zZSBpZGVudGlmaWVycyB0cmFuc21pdHRlZCB0byB0aGUgYWNjZXNz IG5ldHdvcmsgYW55d2F5LCBhcyBwYXJ0IG9mIHRoZSBhdHRhY2htZW50IHByb2Nlc3M/ICAoQW5k IGFuYWxvZ291c2x5IGZvciBvdGhlciBwaHlzaWNhbC9NQUMtbGF5ZXIgaWRlbnRpZmllcnMgaW4g b3RoZXIgc2NlbmFyaW9zLikgIElmIHRoYXQncyB0aGUgY2FzZSwgdGhlbiBob3cgaXMgdXNpbmcg dGhlbSB0byBxdWVyeSBhIExJUyBjb250cm9sbGVkIGJ5IHRoZSBhY2Nlc3MgbmV0d29yayBhbnkg bW9yZSBhIHByaXZhY3kgdmlvbGF0aW9uPw0KDQogDQoNCkFkbWl0dGVkbHksIHlvdSBoYXZlIGEg cG9pbnQuDQoNCiANCg0KVGhvdWdoIGEgTUFDIGlzIG9ubHkgcmVxdWlyZWQgdG8gYmUgdW5pcXVl IG9uIGEgbmV0d29yaywgYW5kIHRoZXJlZm9yZSBjb3VsZCBiZSBjaGFuZ2VkIGJ5IHRoZSB1c2Vy LiAgU3RpbGwsIEkgZG9uJ3Qga25vdyBtYW55IHBlb3BsZSB3aG8gZG8gdGhhdCwgb3IgZXZlbiBr bm93IGhvdy4gIEkgZG9uJ3Qga25vdyBob3cgaW1zaSwgaW1laSwgYW5kIG1pbiBhcmUgYWRtaW5p c3RlcmVkLg0KDQogDQoNCi1hbmR5DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25s eSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2Ug cHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3Jp Z2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVk Lg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ0K ------_=_NextPart_001_01C76B43.A0FAB99B Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM9Imh0dHA6Ly93 d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCg0KPG1ldGEgbmFtZT1HZW5lcmF0 b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTEgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT4NCjxzdHlsZT4NCnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9c Oioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVm YXVsdCNWTUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHls ZT4NCjwhW2VuZGlmXS0tPg0KPHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMTowIDExIDUg MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnANCgl7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpzcGFuLkVtYWls U3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpB cmlhbDsNCgljb2xvcjptYXJvb247DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6 bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw dDt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQoNCjwv aGVhZD4NCg0KPGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlIHN0eWxlPSd3 b3JkLXdyYXA6IGJyZWFrLXdvcmQ7DQota2h0bWwtbmJzcC1tb2RlOiBzcGFjZTsta2h0bWwtbGlu ZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2UnPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW1hcm9vbiBmYWNlPUFyaWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bWFy b29uJz5JTVNJIGlzIGFzc2lnbmVkIHRvIGEgbW9iaWxlIFNJTS7CoCBJTUVJDQppcyBhc3NpZ25l ZCB0byB0aGUgYWN0dWFsIGhhcmR3YXJlLiBNSU4gaXMgbGlrZXdpc2UgYXNzaWduZWQgdG8gaGFy ZHdhcmUgKG5vDQpVSUNDIGluIElTLTk1L0NETUEyMDAwKS7CoCBOb25lIG9mIHRoZXNlIGNhbiBi ZSBjaGFuZ2VkLCBhbmQgYXJlIGdsb2JhbGx5IHVuaXF1ZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bWFyb29u IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpB cmlhbDtjb2xvcjptYXJvb24nPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bWFyb29uIGZhY2U9QXJpYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpt YXJvb24nPk1BQyBjYW4gYmUgY2hhbmdlZCBmb3Igc29tZSBkZXZpY2VzLCBidXQNCnRoaXMgaXMg YSByZWNlbnQgZGV2ZWxvcG1lbnQuIMKgU29tZW9uZSBhdCB0aGUgb2ZmaWNlIGhlcmUgYm91Z2h0 IGEgbW90aGVyYm9hcmQNCnRoYXQgaGFzIGEgQklPUyBzZXR0aW5nIGZvciBNQUMgYWRkcmVzcy7C oCBUaGUgZGVmYXVsdCBpcyAwMDowMDowMDowMDowMDowMC48bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW1hcm9vbiBm YWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJp YWw7Y29sb3I6bWFyb29uJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW1hcm9vbiBmYWNlPUFyaWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bWFy b29uJz5NPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MiBjb2xvcj1tYXJvb24gZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm1hcm9vbic+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz4NCg0KPGRp dj4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWdu OmNlbnRlcic+PGZvbnQgc2l6ZT0zDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTIuMHB0Jz4NCg0KPGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2Vu dGVyIHRhYmluZGV4PS0xPg0KDQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PGI+PGZvbnQgc2l6ZT0yIGZhY2U9VGFob21hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Ow0KZm9udC1mYW1pbHk6VGFob21hO2ZvbnQtd2VpZ2h0OmJvbGQnPkZyb206PC9zcGFu PjwvZm9udD48L2I+PGZvbnQgc2l6ZT0yDQpmYWNlPVRhaG9tYT48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWEnPiBBbmRyZXcgTmV3dG9uDQpbbWFpbHRvOmFu ZHlAaHhyLnVzXSA8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U2VudDo8 L3NwYW4+PC9iPiBXZWRuZXNkYXksIDIxIE1hcmNoIDIwMDcNCjk6NDkgQU08YnI+DQo8Yj48c3Bh biBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+VG86PC9zcGFuPjwvYj4gUmljaGFyZCBCYXJuZXM8 YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+Q2M6PC9zcGFuPjwvYj4gZ2Vv cHJpdkBpZXRmLm9yZzsgU3RhcmssDQpCYXJiYXJhPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQt d2VpZ2h0OmJvbGQnPlN1YmplY3Q6PC9zcGFuPjwvYj4gUmU6IFtHZW9wcml2XSBHUlVVIGluDQpI RUxEIElkZW50aXRpZXM8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToNCjEyLjBwdCc+T24gTWFyIDIwLCAyMDA3LCBhdCA1OjU3IFBNLCBSaWNoYXJkIEJh cm5lcyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQoNCjxwIHN0eWxlPSdtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFw dCc+PGZvbnQgc2l6ZT0xIGZhY2U9SGVsdmV0aWNhPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSc+SSdtIG5vdCBhbiBleHBlcnQgaGVyZSwgYnV0DQph cmVuJ3QgdGhvc2UgaWRlbnRpZmllcnMgdHJhbnNtaXR0ZWQgdG8gdGhlIGFjY2VzcyBuZXR3b3Jr IGFueXdheSwgYXMgcGFydCBvZg0KdGhlIGF0dGFjaG1lbnQgcHJvY2Vzcz88c3BhbiBjbGFzcz1h cHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7IDwvc3Bhbj4oQW5kDQphbmFsb2dvdXNseSBmb3Ig b3RoZXIgcGh5c2ljYWwvTUFDLWxheWVyIGlkZW50aWZpZXJzIGluIG90aGVyIHNjZW5hcmlvcy4p PHNwYW4NCmNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDsgPC9zcGFuPklmIHRoYXQn cyB0aGUgY2FzZSwgdGhlbiBob3cgaXMgdXNpbmcNCnRoZW0gdG8gcXVlcnkgYSBMSVMgY29udHJv bGxlZCBieSB0aGUgYWNjZXNzIG5ldHdvcmsgYW55IG1vcmUgYSBwcml2YWN5DQp2aW9sYXRpb24/ PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOg0KMTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8 ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+QWRtaXR0ZWRseSwgeW91IGhh dmUgYSBwb2ludC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToNCjEyLjBwdCc+VGhvdWdoIGEgTUFDIGlzIG9ubHkgcmVxdWlyZWQgdG8gYmUgdW5pcXVlIG9u IGEgbmV0d29yaywgYW5kIHRoZXJlZm9yZQ0KY291bGQgYmUgY2hhbmdlZCBieSB0aGUgdXNlci4m bmJzcDsgU3RpbGwsIEkgZG9uJ3Qga25vdyBtYW55IHBlb3BsZSB3aG8gZG8NCnRoYXQsIG9yIGV2 ZW4ga25vdyBob3cuJm5ic3A7IEkgZG9uJ3Qga25vdyBob3cmbmJzcDtpbXNpLCBpbWVpLCBhbmQg bWluIGFyZQ0KYWRtaW5pc3RlcmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwv ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4tYW5keTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxicj48YnI+PHRhYmxlIGJnY29sb3I9 d2hpdGUgc3R5bGU9ImNvbG9yOmJsYWNrIj48dHI+PHRkPjxicj4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2lzJm5ic3A7 Zm9yJm5ic3A7dGhlJm5ic3A7ZGVzaWduYXRlZCZuYnNwO3JlY2lwaWVudCZuYnNwO29ubHkmbmJz cDthbmQmbmJzcDttYXk8YnI+DQpjb250YWluJm5ic3A7cHJpdmlsZWdlZCwmbmJzcDtwcm9wcmll dGFyeSwmbmJzcDtvciZuYnNwO290aGVyd2lzZSZuYnNwO3ByaXZhdGUmbmJzcDtpbmZvcm1hdGlv bi4mbmJzcDsmbmJzcDs8YnI+DQpJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZu YnNwO2l0Jm5ic3A7aW4mbmJzcDtlcnJvciwmbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0 aGUmbmJzcDtzZW5kZXI8YnI+DQppbW1lZGlhdGVseSZuYnNwO2FuZCZuYnNwO2RlbGV0ZSZuYnNw O3RoZSZuYnNwO29yaWdpbmFsLiZuYnNwOyZuYnNwO0FueSZuYnNwO3VuYXV0aG9yaXplZCZuYnNw O3VzZSZuYnNwO29mPGJyPg0KdGhpcyZuYnNwO2VtYWlsJm5ic3A7aXMmbmJzcDtwcm9oaWJpdGVk Ljxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClttZjJd PC90ZD48L3RyPjwvdGFibGU+PC9ib2R5Pg0KDQo8L2h0bWw+DQo= ------_=_NextPart_001_01C76B43.A0FAB99B-- --===============1035181454== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1035181454==-- From geopriv-bounces@ietf.org Tue Mar 20 19:08: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 1HTnQq-0007wS-Dm; Tue, 20 Mar 2007 19:07:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTnQp-0007fO-Ov for geopriv@ietf.org; Tue, 20 Mar 2007 19:07:55 -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 1HTnOt-0006WB-Q0 for geopriv@ietf.org; Tue, 20 Mar 2007 19:05:57 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 20 Mar 2007 19:01:54 -0400 id 0158805F.460067E2.00000B05 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7829923B-A4D0-4E19-AD25-0C000B7A5A1D@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Geopriv] GRUU in HELD Identities Date: Tue, 20 Mar 2007 19:05:48 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: geopriv@ietf.org, "Stark, Barbara" X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org On Mar 20, 2007, at 7:00 PM, Thomson, Martin wrote: > MAC can be changed for some devices, but this is a recent > development. Someone at the office here bought a motherboard that > has a BIOS setting for MAC address. The default is 00:00:00:00:00:00. I'll give you the point, but the ability to change MAC addresses is nothing new. Network admins use to do it on a regular basis, encoding office locations into the addresses. That was considered state-of-the-art in network management back in 1990. -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 20 19:44:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTo02-00060A-2k; Tue, 20 Mar 2007 19:44:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTo00-0005zj-Am for geopriv@ietf.org; Tue, 20 Mar 2007 19:44: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 1HTnzo-000509-GA for geopriv@ietf.org; Tue, 20 Mar 2007 19:44:16 -0400 X-SEF-Processed: 5_0_0_910__2007_03_20_18_50_02 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, 20 Mar 2007 18:50:02 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 18:43:56 -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: [Geopriv] GRUU in HELD Identities Date: Tue, 20 Mar 2007 18:43:51 -0500 Message-ID: In-Reply-To: <460058C1.80204@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] GRUU in HELD Identities Thread-Index: AcdrPEX9QLYEbKp3ThGEFrpKUpdBiAACoQ0g From: "Dawson, Martin" To: "Richard Barnes" , "Andrew Newton" X-OriginalArrivalTime: 20 Mar 2007 23:43:56.0130 (UTC) FILETIME=[9FCF5C20:01C76B49] X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: geopriv@ietf.org, "Stark, Barbara" X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi everyone,=0D=0A=0D=0AWith this discussion, I think it has to be borne in= mind what the=0D=0Apurpose of providing a device identity extension to a L= IS is.=0D=0A=0D=0AIt is to provide the LIS with some additional identifier = that can be=0D=0Acorrelated with network measurements where the IP address = is not known=0D=0Aor not sufficient. It needs to be some value that the LIS= is already=0D=0Aaware of and is already capable of correlating with a loca= tion.=0D=0A=0D=0ASo, for example, in a DSL network the L2TP tunnel identifi= er may be=0D=0Apassed from an ISP LIS to an RBP LIS because the IP address = doesn't mean=0D=0Aanything in the DSL infrastructure provider's domain.=0D=0A=0D= =0ACellular is a bit of a special case - it already has a location=0D=0Ainf= rastructure that, at the gateway level, uses the MSISDN as the device=0D=0A= identifier. In this case a cellular device in a target-LIS query could=0D=0A= also pass its MSISDN when it's in a cellular network. It's obviously not=0D= =0Aideal for a device to have to know it's in the cellular-access network=0D= =0Ascenario in order to add this extension - though it's possible for a=0D=0A= specific client implementation to do that. Actually, there are a number=0D=0A= of published methodologies that describe how the LIS can work out the=0D=0A= MSISDN from the IP address in a cellular access domain anyway - then use=0D= =0Athe MSISDN to invoke the existing location infrastructure. So even this=0D= =0Ascenario should not really be necessary.=0D=0A=0D=0ABeyond that, it is g= oing to be very specific implementation scenarios=0D=0Awhere anything other= than IP address is really needed. For example, a=0D=0Aspecific enterprise = implementation that uses LLDP to determine the=0D=0Aswitch/port ID (rather = than using DHCP relay or SNMP bridge MIB queries=0D=0Afor example) and pass= es that switch port value in the target-LIS=0D=0Arequest. Or it may be wher= e an application server is performing an OBO=0D=0Ato the LIS using the iden= tifier it knows and which the LIS can still=0D=0Aactually use to correlate = to location. And, as mentioned already,=0D=0Aspecific network LIS-LIS scena= rios may use these extensions. I tend to=0D=0Athink these kind of additiona= l identity parameters will actually be=0D=0Alower layer parameters rather t= han application layer identities because=0D=0Athey are most likely able to = be associated with the physical=0D=0Aconnectivity from which location is de= termined.=0D=0A=0D=0AIn no cases should an identity be passed to a LIS that= isn't already=0D=0Aknown by the LIS and which isn't useful to perform corr= elation with some=0D=0Aother network parameters which permit location to be= determined.=0D=0A=0D=0AI have my doubts that quite high level application = identities (which I=0D=0Aget the sense that GRUU is - I don't pretend to ha= ve a clue in that=0D=0Aquarter) will actually provide any kind of meaningfu= l correlator for a=0D=0ALIS to determine location from. On the other hand, = I certainly don't=0D=0Aclaim to know if it couldn't be useful. At worst, it= 's presence in the=0D=0Aidentity form list should be benign and at best it = will be useful to=0D=0Asome domain specific LIS implementation. I don't thi= nk that the use of=0D=0Athese identity extensions should ever create a priv= acy issue.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-= ----=0D=0AFrom: Richard Barnes [mailto:rbarnes@bbn.com]=20=0D=0ASent: Wedne= sday, 21 March 2007 8:57 AM=0D=0ATo: Andrew Newton=0D=0ACc: geopriv@ietf.or= g; Stark, Barbara=0D=0ASubject: Re: [Geopriv] GRUU in HELD Identities=0D=0A=0D= =0A> Additionally, imsi, imei, and min appear to be tied to specific=0D=0Ad= evices,=20=0D=0A> which can also be related back to a user. Again, that's = a privacy=0D=0Aissue.=0D=0A=0D=0AOK, I'm a confused here. In order to loca= te something, you need to=20=0D=0Aidentify a unique physical thing to locat= e. But you're saying that=20=0D=0Atransmitting something that identifies a= unique physical thing is a=20=0D=0Aprivacy violation=3F=0D=0A=0D=0AI'm not= an expert here, but aren't those identifiers transmitted to the=20=0D=0Aac= cess network anyway, as part of the attachment process=3F (And=20=0D=0Aana= logously for other physical/MAC-layer identifiers in other=20=0D=0Ascenario= s.) If that's the case, then how is using them to query a LIS=20=0D=0Acont= rolled by the access network any more a privacy violation=3F=0D=0A=0D=0A--R= B=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A>=20=0D=0A> And while link sounds useful, if= the client doesn't know when to send=20=0D=0A> it, then it could also pote= ntially leak user sensitive information.=0D=0A>=20=0D=0A> Finally, GRUUs th= at contain an AoR might also leak user sensitive=20=0D=0A> information.=0D=0A= >=20=0D=0A> -andy=0D=0A>=20=0D=0A> On Mar 20, 2007, at 2:31 PM, Stark, Barb= ara wrote:=0D=0A>=20=0D=0A>> For a consumer-grade end device that's not kno= wingly connecting to a=20=0D=0A>> mobile network, it doesn't look too bad, = to me. I see ipV4 and ipV6.=20=0D=0A>> And a device should know whether the= IP address that it wants to use=20=0D=0A>> is v4 or v6. mac and lldp look = like they could be optionally used=0D=0Awhen=20=0D=0A>> a location assertio= n is being done, but I wouldn't use them for a LIS=0D=0A=0D=0A>> query (to = acquire location). I'm not sure how useful ssid is, but I=20=0D=0A>> can't = think of a really good application for it. Especially not for=20=0D=0A>> co= nsumer devices.=0D=0A>>=0D=0A>> For LIS-LIS, the querying LIS is going to h= ave to know what=20=0D=0A>> identifiers it needs to use for a particular ac= cess network LIS. That=0D=0A=0D=0A>> will be programmatically defined in th= e querrying LIS, and shouldn't=20=0D=0A>> be difficult. This includes atm, = vlan, l2tp, nas-ip-address, and=20=0D=0A>> nas-identifier. I'm not sure how= dhcp or access-node-id would be=0D=0Aused,=20=0D=0A>> but they aren't thin= gs that would be known by an end device.=0D=0A>>=0D=0A>> For mobile devices= , I'm clueless as to what they would be doing. It=20=0D=0A>> looks like it = might depend on the type of network they're connecting=20=0D=0A>> to=3F I t= hink the following apply to mobile devices: msisdn, imsi,=20=0D=0A>> direct= orynumber, imei, mdn, min.=0D=0A>>=0D=0A>> extension looks like it would on= ly work on devices intended to=0D=0Aoperate=20=0D=0A>> in a PBX environment= =2E If that's the case, I would expect it to be a=20=0D=0A>> non-consumer, = custom, closed environment.=0D=0A>>=0D=0A>> Which leaves link and depend, w= here link is anything you want it to=0D=0Abe=20=0D=0A>> (and therefore only= useful in custom, closed environments), and=0D=0Adepend=20=0D=0A>> is asso= ciated with the signatures that we haven't resolved.=0D=0A>>=0D=0A>> So, I = don't really see what the problem is with this long list.=20=0D=0A>> There'= s flexibility for custom, closed environments, and for LIS-LIS,=0D=0A=0D=0A= >> but regular consumer devices aren't burdened with lots of IDs. Unless=0D= =0A=0D=0A>> there are too many mobile identifiers, since I don't know about= those=0D=0A=0D=0A>> things.=0D=0A>> Barbara=0D=0A>> From: Andrew Newton [m= ailto:andy@hxr.us]=0D=0A>> Sent: Tuesday, March 20, 2007 1:03 PM=0D=0A>> To= : Sherry, Robert=0D=0A>> Cc: geopriv@ietf.org=0D=0A>> Subject: Re: [Geopriv= ] GRUU in HELD Identities=0D=0A>>=0D=0A>>=0D=0A>> On Mar 20, 2007, at 11:50= AM, Sherry, Robert wrote:=0D=0A>>=0D=0A>>> I think there has to be a corre= lation between the identity that is=0D=0A>>> registered and the identity th= at the LIS knows.=0D=0A>>> I would expect a type of UA to use only one iden= tity.=0D=0A>>> (Although I could see TN and MAC. With MAC being the unique=0D= =0Aidentifier=0D=0A>>> and TN used for tracking or logging.)=0D=0A>>> The L= IS would have to support many types of identities depending=0D=0Aupon=0D=0A= >>> what types of access networks it supports.=0D=0A>>=0D=0A>> Naturally, t= he LIS can only usefully support the identities relevant=20=0D=0A>> to the = networks in which it is deployed. However, a client can be=20=0D=0A>> depl= oyed in many types of networks and can jump from one type to=20=0D=0A>> ano= ther. How does it know which identity to send to the LIS=3F=0D=0A>>=0D=0A>= > -andy=0D=0A>> *****=0D=0A>>=0D=0A>> The information transmitted is intend= ed only for the person or entity=0D=0A=0D=0A>> to which it is addressed and= may contain confidential, proprietary,=20=0D=0A>> and/or privileged materi= al. Any review, retransmission, dissemination=0D=0A=0D=0A>> or other use of= , or taking of any action in reliance upon this=20=0D=0A>> information by p= ersons or entities other than the intended recipient=20=0D=0A>> is prohibit= ed. If you received this in error, please contact the=20=0D=0A>> sender and= delete the material from all computers. GA622=0D=0A>=20=0D=0A>=20=0D=0A> _= ______________________________________________=0D=0A> Geopriv mailing list=0D= =0A> Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D= =0A>=20=0D=0A>=20=0D=0A=0D=0A=0D=0A=0D=0A__________________________________= _____________=0D=0AGeopriv mailing list=0D=0AGeopriv@ietf.org=0D=0Ahttps://= www1.ietf.org/mailman/listinfo/geopriv=0D=0A=0D=0A-------------------------= -----------------------------------------------------------------------=0D=0A= This message is for the designated recipient only and may=0D=0Acontain priv= ileged, 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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Mar 20 22:04: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 1HTqAe-0001U7-R3; Tue, 20 Mar 2007 22:03:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTqAe-0001Tz-0T for geopriv@ietf.org; Tue, 20 Mar 2007 22:03:24 -0400 Received: from bellwecs2.bellnexxia.net ([207.236.237.114] helo=bellwecs2.srvr.bell.ca) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTqAI-0001ac-Ud for geopriv@ietf.org; Tue, 20 Mar 2007 22:03:23 -0400 Received: (qmail 24365 invoked from network); 21 Mar 2007 02:02:56 -0000 Received: from g.caron@bell.ca by bellwecs2.srvr.bell.ca with EntrustECS-Server-7.4; 21 Mar 2007 02:02:56 -0000 Received: from bellwfep3.bellnexxia.net (HELO bellwfep3-srv.bellnexxia.net) (207.236.237.109) by bellwecs2.srvr.bell.ca with SMTP; 21 Mar 2007 02:02:55 -0000 Received: from toroondc550.bell.corp.bce.ca ([142.182.84.162]) by bellwfep3-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20070321020255.LMKA1679.bellwfep3-srv.bellnexxia.net@toroondc550.bell.corp.bce.ca>; Tue, 20 Mar 2007 22:02:55 -0400 Received: from toroondc912.bell.corp.bce.ca ([142.182.89.15]) by toroondc550.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 22:02:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] Contribution on Location for Emergency Calls Date: Tue, 20 Mar 2007 22:02:54 -0400 Message-ID: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A4BF4DE@toroondc912> In-Reply-To: <83413EA4F18F4445B1E94356DBA0B5DA0287A606@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Contribution on Location for Emergency Calls Thread-Index: AcdowurqchvHByImQI+n6RMP+fd7NgBXUvyA References: <83413EA4F18F4445B1E94356DBA0B5DA0287A606@E03MVZ1-UKDY.domain1.systemhost.net> From: To: , X-OriginalArrivalTime: 21 Mar 2007 02:02:55.0513 (UTC) FILETIME=[0A783890:01C76B5D] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I fully support John's request to move things a bit here in order to get = an L7-LCP accepted as a WG item in Prague. Just one point of clarification: At this moment, HELD is being "strongly = considered" in Canada. Nevertheless, as a proponent of an L7-LCP and a = short term implementer, HELD is my preferred choice and would like to = see it promoted. Thanks, Guy Caron ________________________________________ De=A0: john.medland@bt.com [mailto:john.medland@bt.com]=20 Envoy=E9=A0: 17 mars 2007 14:35 =C0=A0: geopriv@ietf.org Objet=A0: [Geopriv] Contribution on Location for Emergency Calls As BT's UK 112/999 Policy Manager, I'd like to urge the IETF to make a = decision next week on a suitable Location Acquisition Protocol. I'm responsible for how emergency calls are handled in BT's PSAPs (28 = million emergency calls from fixed and mobile devices each year).=A0 We = are experiencing a rapid growth in VoIP emergency calls and urgently = need a referencable standard against which to plan developments in the = UK, that we can be sure also allows international calling scenarios to = be managed. I'm aware the HELD protocol is at an advanced stage of development, is = being adopted in Canada, and it would seem appropriate to give this = serious consideration as a suitable way forward.=A0=A0 Thanks and = regards John Medland=20 Tel:+44 (0)1977 593408 | Email: john.medland@bt.com=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 04:58: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 1HTwe2-0004MS-Ao; Wed, 21 Mar 2007 04:58:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTwe0-0004MH-VP for geopriv@ietf.org; Wed, 21 Mar 2007 04:58:08 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTwdy-0002mj-LU for geopriv@ietf.org; Wed, 21 Mar 2007 04:58:08 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Mar 2007 04:58:05 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2L8w4QP022428; Wed, 21 Mar 2007 04:58:04 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2L8w4lG002744; Wed, 21 Mar 2007 08:58:04 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 04:58:04 -0400 Received: from mlinsnerwxp ([10.82.216.37]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 04:58:03 -0400 From: "Marc Linsner" To: , Subject: RE: [Geopriv] Contribution on Location for Emergency Calls Date: Wed, 21 Mar 2007 04:58:02 -0400 Message-ID: <003f01c76b97$08dddd20$25d8520a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A4BF4DE@toroondc912> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdowurqchvHByImQI+n6RMP+fd7NgBXUvyAAF2RLIA= X-OriginalArrivalTime: 21 Mar 2007 08:58:03.0754 (UTC) FILETIME=[08F02CA0:01C76B97] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2085; t=1174467484; x=1175331484; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20Contribution=20on=20Location=20for=20Emer gency=20Calls |Sender:=20 |To:=20,=20; bh=8rPBMoOdjhXHL36muqROuLiJkDpv0zrZb53LDRD+CZo=; b=dHy8thYJ/hxM6k2lAez/FaX15s0ZndP0bXRG1VCtbCF01bySVLqhQ2g3NqSuQUQBGkQEpHoN fMIm0SjK7k5H/NfRKypBGPwFY+ZFtjZKDprFnZg6Ey1OpCMaUNo919+X; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Guy, You've made this request a few times now. I'm curious what the = implications of a GeoPriv decision are to your implementation? -Marc- =20 > -----Original Message----- > From: g.caron@bell.ca [mailto:g.caron@bell.ca]=20 > Sent: Tuesday, March 20, 2007 10:03 PM > To: john.medland@bt.com; geopriv@ietf.org > Subject: RE: [Geopriv] Contribution on Location for Emergency Calls >=20 > I fully support John's request to move things a bit here in=20 > order to get an L7-LCP accepted as a WG item in Prague. >=20 > Just one point of clarification: At this moment, HELD is=20 > being "strongly considered" in Canada. Nevertheless, as a=20 > proponent of an L7-LCP and a short term implementer, HELD is=20 > my preferred choice and would like to see it promoted. >=20 > Thanks, >=20 > Guy Caron > ________________________________________ > De=A0: john.medland@bt.com [mailto:john.medland@bt.com] Envoy=E9=A0 > : 17 mars 2007 14:35 =C0=A0: geopriv@ietf.org Objet=A0: [Geopriv]=20 > Contribution on Location for Emergency Calls >=20 >=20 > As BT's UK 112/999 Policy Manager, I'd like to urge the IETF=20 > to make a decision next week on a suitable Location=20 > Acquisition Protocol. > I'm responsible for how emergency calls are handled in BT's=20 > PSAPs (28 million emergency calls from fixed and mobile=20 > devices each year).=A0 We are experiencing a rapid growth in=20 > VoIP emergency calls and urgently need a referencable=20 > standard against which to plan developments in the UK, that=20 > we can be sure also allows international calling scenarios to=20 > be managed. > I'm aware the HELD protocol is at an advanced stage of=20 > development, is being adopted in Canada, and it would seem=20 > appropriate to give this serious consideration as a suitable=20 > way forward.=A0=A0 Thanks and regards > John Medland=20 > Tel:+44 (0)1977 593408 | Email: john.medland@bt.com=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 06:00: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 1HTxcc-0006ep-Dy; Wed, 21 Mar 2007 06:00:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxcb-0006eg-5z for geopriv@ietf.org; Wed, 21 Mar 2007 06:00:45 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTxcR-0004xW-M5 for geopriv@ietf.org; Wed, 21 Mar 2007 06:00:45 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 21 Mar 2007 06:00:36 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2LA0ZlW010101 for ; Wed, 21 Mar 2007 06:00:35 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2LA0ZGd008601 for ; Wed, 21 Mar 2007 10:00:35 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 06:00:35 -0400 Received: from mlinsnerwxp ([10.82.216.37]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 06:00:34 -0400 From: "Marc Linsner" To: Date: Wed, 21 Mar 2007 06:00:33 -0400 Message-ID: <004301c76b9f$c49a5810$25d8520a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdrn72HB/eKODQMScyBMH8b9gRhVA== X-OriginalArrivalTime: 21 Mar 2007 10:00:35.0051 (UTC) FILETIME=[C4E2ABB0:01C76B9F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1843; t=1174471235; x=1175335235; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20Location=20Integrity |Sender:=20 |To:=20; bh=V2/To9T3z70nD1CjjTR2A4GA3e62nHFuV5y4SJypETc=; b=LaG0PfH0qF1NhMCgqn/VmeTnIY1TmQYr6HBNcjwFmUh2+U1Tj052POeIa+iQJqiUHtR7/w1K KPI5lx1bdo7pbdF/spqVrqn0xqf/EB1COZRIXZy+H6UJ/jfRff2dMvII; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Geopriv] Location Integrity X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I've proposed this in a couple of obtuse emails to the list, but after asking a few, it appears it hasn't been understood. I know, a draft is needed, but for the discussion on tomorrow's agenda, I thought I would reiterate here. It appears there is large support for using certificates to establish a trust between the Location Recipient and the author of the location information. This is possible today using a couple of different methods. One that I'm not sure is clear is using the provided-by within the pidf-lo, populating with a random L-by-R uri, then requesting TLS is employed while dereferencing. The trust is gained/denied during the dereference operation/TLS connection establishment. If the location value returned by the dereference matches the L-by-V provided initially, you now have the same level of trust that is gained with the proposed location signing. A few of advantages of this method: 1) No IETF work required. Faster time to market. Everything is in-place to do this today. Provided-by = pres:12456abcdef@accessprovider.net 2) L-by-V is used in the SIP invite, intermediate routing proxies don't need to dereference anything for routing, they simply use the by-value data. 3) The dereference operation provides multiple attributes: establishes the trust via certificates, and sets up a presence subscribe/notify for tracking a mobile client (corresponding to the rebid process deployed in NA PSAPs today). I'm sure there are downsides that I'm missing, please point them out. The obvious one is the extra step required to get the certificate initially, but if the AOR of major providers is somewhat static and well known by PSAPs as claimed by some, only comparison of the location data is needed, a process that is probably prudent prior to dispatch anyway. -Marc- _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 06:13:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxo8-000468-Hs; Wed, 21 Mar 2007 06:12:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxo7-00044o-7M for geopriv@ietf.org; Wed, 21 Mar 2007 06:12:39 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTxo5-0008Gn-TD for geopriv@ietf.org; Wed, 21 Mar 2007 06:12:39 -0400 X-SEF-Processed: 5_0_0_910__2007_03_21_05_18_44 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, 21 Mar 2007 05:18:44 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 05:12:37 -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: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 05:12:34 -0500 Message-ID: In-Reply-To: <004301c76b9f$c49a5810$25d8520a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Location Integrity Thread-Index: Acdrn72HB/eKODQMScyBMH8b9gRhVAAAPXhg From: "Winterbottom, James" To: "Marc Linsner" , X-OriginalArrivalTime: 21 Mar 2007 10:12:37.0403 (UTC) FILETIME=[7370D6B0:01C76BA1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Marc,=0D=0A=0D=0AI will assert that the LIS providing the location by-refer= ence still=0D=0Arequires a VESA certificate or the like in order for this m= odel to=0D=0Aprovide the same degree of trust as the signatures that have b= een=0D=0Adescribed. Consequently the mechanism you describe has at least th= e same=0D=0Aadministrative overhead with regards to certificate management.= So that=0D=0Apart solves nothing.=0D=0A=0D=0ASecondly, this solution does = not solve the total collusion problem of=0D=0Atwo people swapping identity = information around the place, so it doesn't=0D=0Asolve anything more than w= hat has been described in the Thomson location=0D=0Adependability draft. It= does however, as you point out, now require a=0D=0Alocation reference mech= anism over and above the location by value=0D=0Aalready being sent in order= to provide a questionable degree a surety.=0D=0AIn case you hadn't guessed= I don't like this proposal as it provides=0D=0Anothing extra except for pr= ocessing cycles.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A> -----Origi= nal Message-----=0D=0A> From: Marc Linsner [mailto:mlinsner@cisco.com]=0D=0A= > Sent: Wednesday, 21 March 2007 9:01 PM=0D=0A> To: geopriv@ietf.org=0D=0A>= Subject: [Geopriv] Location Integrity=0D=0A>=20=0D=0A> I've proposed this = in a couple of obtuse emails to the list, but after=0D=0A> asking a few, it= appears it hasn't been understood. I know, a draft=0D=0Ais=0D=0A> needed,= but for the discussion on tomorrow's agenda, I thought I would=0D=0A> reit= erate here.=0D=0A>=20=0D=0A> It appears there is large support for using ce= rtificates to establish=0D=0Aa=0D=0A> trust between the Location Recipient = and the author of the location=0D=0A> information. This is possible today = using a couple of different=0D=0Amethods.=0D=0A> One that I'm not sure is c= lear is using the provided-by within the=0D=0Apidf-=0D=0A> lo,=0D=0A> popul= ating with a random L-by-R uri, then requesting TLS is employed=0D=0Awhile=0D= =0A> dereferencing. The trust is gained/denied during the dereference=0D=0A= > operation/TLS connection establishment. If the location value=0D=0Aretur= ned by=0D=0A> the dereference matches the L-by-V provided initially, you no= w have=0D=0Athe=0D=0A> same=0D=0A> level of trust that is gained with the p= roposed location signing.=0D=0A>=20=0D=0A> A few of advantages of this meth= od:=0D=0A>=20=0D=0A> 1) No IETF work required. Faster time to market. Eve= rything is=0D=0Ain-place=0D=0A> to=0D=0A> do this today. Provided-by =3D p= res:12456abcdef@accessprovider.net=0D=0A>=20=0D=0A> 2) L-by-V is used in th= e SIP invite, intermediate routing proxies=0D=0Adon't=0D=0A> need=0D=0A> to= dereference anything for routing, they simply use the by-value=0D=0Adata.=0D= =0A>=20=0D=0A> 3) The dereference operation provides multiple attributes: e= stablishes=0D=0Athe=0D=0A> trust via certificates, and sets up a presence s= ubscribe/notify for=0D=0A> tracking=0D=0A> a mobile client (corresponding t= o the rebid process deployed in NA=0D=0APSAPs=0D=0A> today).=0D=0A>=20=0D=0A= > I'm sure there are downsides that I'm missing, please point them out.=0D=0A= The=0D=0A> obvious one is the extra step required to get the certificate=0D= =0Ainitially,=0D=0A> but=0D=0A> if the AOR of major providers is somewhat s= tatic and well known by=0D=0APSAPs=0D=0A> as=0D=0A> claimed by some, only c= omparison of the location data is needed, a=0D=0Aprocess=0D=0A> that is pro= bably prudent prior to dispatch anyway.=0D=0A>=20=0D=0A> -Marc-=0D=0A>=20=0D= =0A> _______________________________________________=0D=0A> Geopriv mailing= list=0D=0A> Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo= /geopriv=0D=0A=0D=0A-------------------------------------------------------= -----------------------------------------=0D=0AThis message is for the desi= gnated recipient only and may=0D=0Acontain privileged, proprietary, or othe= rwise private information. =20=0D=0AIf you have received it in error, pleas= e notify the sender=0D=0Aimmediately and delete the original. Any unauthor= ized use of=0D=0Athis email is prohibited.=0D=0A---------------------------= ---------------------------------------------------------------------=0D=0A= [mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 06:57:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTyVr-0005iD-Nc; Wed, 21 Mar 2007 06:57:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTyVp-0005Zd-Sv for geopriv@ietf.org; Wed, 21 Mar 2007 06:57:49 -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 1HTyVm-0006jr-5z for geopriv@ietf.org; Wed, 21 Mar 2007 06:57:49 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 21 Mar 2007 06:53:40 -0400 id 01588110.46010EB4.0000366C In-Reply-To: References: Mime-Version: 1.0 Message-Id: <936B6027-9122-4443-8968-E0A63374052D@hxr.us> From: Andrew Newton Subject: Re: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 06:57:43 -0400 To: James Winterbottom , Marc Linsner X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1560690582==" Errors-To: geopriv-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1560690582== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-13934-1174474420-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-13934-1174474420-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Marc, Thanks for using the correct terminology. As outlined in RFC 3552, integrity is the desired property and requirement. Signing is one method of accomplishing this. On Mar 21, 2007, at 6:12 AM, Winterbottom, James wrote: > In case you hadn't guessed I don't like this proposal as it provides > nothing extra except for processing cycles. I don't think any proposal using XML D-Sig has any bragging rights about being efficient or less complex. Marc's proposal is simpler and requires little standardization effort. And the act of the dereference provides an opportunity to thwart replay attacks. I do have concerns though. It relies on L-by-V, which might be problematic with the state of multiple MIME bodies being what they are today. An L-by-R in an INVITE does seem to have the advantage of being retrofitted into networks and software more easily. Additionally, if the dereference act provides the trust, then why not just use L-by-R in the INVITE? I must be missing something. Finally, given the description of in RFC 4119... especially the text about SubjectAltName and certificates, it might be wisest to create a new element for this purpose. -andy --=_zeke.ecotroph.net-13934-1174474420-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.54.2
Marc,

Thanks for using the correct terminology= .=A0 As outlined in RFC 3552, integrity is the desired property and requi= rement.=A0 Signing is one method of accomplishing this.

On Mar 21, 2007, at 6:12 AM, Winterbottom, James wrote:

In case you hadn't guessed I don't like this proposa= l as it provides

= noth= ing extra except for processing cycles.

I don't think any proposal using XML D-Sig has any bragging rights = about being=A0efficient or less complex.

Marc's proposal is simpler and requires little = standardization effort.=A0 And the act of the dereference provides an opp= ortunity to thwart replay attacks.

I do have concerns though.=A0 It relies on L-by-V, w= hich might be problematic with the state of multiple MIME bodies being wh= at they are today.=A0 An L-by-R in an INVITE does seem to have the advant= age of being retrofitted into networks and software more easily.

Additionally, if the d= ereference act provides the trust, then why not just use L-by-R in the IN= VITE?=A0 I must be missing something.

Finally, given the description of <provided-by= > in RFC 4119... especially the text about SubjectAltName and certific= ates, it might be wisest to create a new element for this purpose.
<= DIV>
-andy
--=_zeke.ecotroph.net-13934-1174474420-0001-2-- --===============1560690582== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1560690582==-- From geopriv-bounces@ietf.org Wed Mar 21 07:49:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzJn-0001h5-KM; Wed, 21 Mar 2007 07:49:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzJm-0001h0-Js for geopriv@ietf.org; Wed, 21 Mar 2007 07:49:26 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTzJS-0005pO-6e for geopriv@ietf.org; Wed, 21 Mar 2007 07:49:26 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 21 Mar 2007 04:49:06 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l2LBn5dL032506; Wed, 21 Mar 2007 04:49:05 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2LBn4wn007363; Wed, 21 Mar 2007 11:49:05 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 07:49:04 -0400 Received: from mlinsnerwxp ([10.21.120.84]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 07:49:03 -0400 From: "Marc Linsner" To: "'Winterbottom, James'" , Subject: RE: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 07:49:01 -0400 Message-ID: <006f01c76bae$ed1757c0$25d8520a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdrn72HB/eKODQMScyBMH8b9gRhVAAAPXhgAAMEySA= X-OriginalArrivalTime: 21 Mar 2007 11:49:04.0051 (UTC) FILETIME=[EC8D4030:01C76BAE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1636; t=1174477745; x=1175341745; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20Location=20Integrity |Sender:=20; bh=Z3S7lb87Xxh/qZz5YQtZZN/kHOsW6r90RsR6h5zhbZI=; b=RZ+h1aCyNXPcXCd5ZoNSuOFvKvo1ud0LI4K1LICqcoh3iznA5EFo0AQwOCjDlBeeZwEwzRXi DgT6+JVwTRV4JR9/c+awClrtmkOsyEWcfWhlBoGPDEdoV59jqfmYwxJO; Authentication-Results: sj-dkim-5; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org James, > I will assert that the LIS providing the location > by-reference still requires a VESA certificate or the like in > order for this model to provide the same degree of trust as > the signatures that have been described. Consequently the > mechanism you describe has at least the same administrative > overhead with regards to certificate management. So that part > solves nothing. Ageed, CA management is required. This seems to be accepted by those proposing the certificate trust model. What I suggesting is a different/faster-to-market mechanism to perform that same level of integrity checking. I still have reservations about the ROI from using this model, you are asking to spend large amounts of public money to deploy/maintain this mechanism. I'm also amiss at the complete dismissal of other suggestions to satisfy the requirement that have higher ROI, hence I think consensus on the requirement is needed. > > Secondly, this solution does not solve the total collusion > problem of two people swapping identity information around > the place, so it doesn't solve anything more than what has > been described in the Thomson location dependability draft. Like I said, faster time to market with parallel benefit. > It does however, as you point out, now require a location > reference mechanism over and above the location by value > already being sent in order to provide a questionable degree a surety. Ack > In case you hadn't guessed I don't like this proposal as it > provides nothing extra except for processing cycles. I got that. -Marc- _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 07:49:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzJV-00019s-4E; Wed, 21 Mar 2007 07:49:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzJT-00015U-Ba for geopriv@ietf.org; Wed, 21 Mar 2007 07:49:07 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTzJQ-00018P-Kw for geopriv@ietf.org; Wed, 21 Mar 2007 07:49:07 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 21 Mar 2007 04:49:04 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l2LBn3je004494; Wed, 21 Mar 2007 04:49:03 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2LBn3wn007356; Wed, 21 Mar 2007 11:49:03 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 07:49:02 -0400 Received: from mlinsnerwxp ([10.21.120.84]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 07:49:02 -0400 From: "Marc Linsner" To: "'Andrew Newton'" Subject: RE: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 07:49:01 -0400 Message-ID: <006a01c76bae$ec181030$25d8520a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <936B6027-9122-4443-8968-E0A63374052D@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdrp8ttNq+FBPrCSmKNTIIGiZ3sAgAAVFoQ X-OriginalArrivalTime: 21 Mar 2007 11:49:02.0395 (UTC) FILETIME=[EB9090B0:01C76BAE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6815; t=1174477743; x=1175341743; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20Location=20Integrity |Sender:=20; bh=/WVAL1ixNqLwDFDynE29tiwPVXI/Z3xtPRYeup6+nN4=; b=MTBaGrhki7wZMU8A7QveNsJCrt1sDD1iG9Q3VmqcXTX1Ha6Qe9ULTRpa96b7Tz4HN/tR8ybi z3zu/Ywae9xduRiLJ1AbtZdADf1pOA/u/hll98Km1vVhx9Yu/SE+yJ36; Authentication-Results: sj-dkim-7; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: 'GEOPRIV WG' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1371099490==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============1371099490== Content-Type: multipart/alternative; boundary="----=_NextPart_000_006B_01C76B8D.65067030" This is a multi-part message in MIME format. ------=_NextPart_000_006B_01C76B8D.65067030 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andy, Marc's proposal is simpler and requires little standardization effort. And the act of the dereference provides an opportunity to thwart replay attacks. As I stated earlier, I do believe an update on location between sip session establishment and responder dispatch is going to become normal procedure. If I'm right, location integrity is best performed closest to the time it has high-value usage. I do have concerns though. It relies on L-by-V, which might be problematic with the state of multiple MIME bodies being what they are today. An L-by-R in an INVITE does seem to have the advantage of being retrofitted into networks and software more easily. OK, given my ignorance on this, I have no choice but to believe you. Is this insurmountable? Additionally, if the dereference act provides the trust, then why not just use L-by-R in the INVITE? I must be missing something. I see a large advantage to having L-by-V in the invite for routing purposes. I can't imagine the time will be available during a routing decision to either derefernce nor chase trust relationships. L-by-V is *required* for routing, IMO. Remember, we are already performing LoST queries during routing. Plus, the REAL requirement, which is still in dispute, is to not waste PSAP resources by dispatching to false emergencies. With that said, there is time between call session establishment and dispatch of responders to perform integrity checks on the location data. Finally, given the description of in RFC 4119... especially the text about SubjectAltName and certificates, it might be wisest to create a new element for this purpose. I've accepted the realization that pidf-lo will be in turmoil/change for some time, so I don't object to a new element. With that said, there is nothing stopping implementations that agree to using provided-by doing so TODAY. -Marc- ------=_NextPart_000_006B_01C76B8D.65067030 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Andy,

Marc's proposal is simpler and requires little standardization = effort.=20 And the act of the dereference provides an opportunity to thwart = replay=20 attacks.

As I stated earlier, I do believe an update on=20 location between sip session establishment and responder dispatch is going = to become=20 normal procedure.  If I'm right, location integrity is = best=20 performed closest to the time it has high-value = usage.

I do have concerns though. It relies on L-by-V, which might be=20 From geopriv-bounces@ietf.org Wed Mar 21 07:49:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzJn-0001h5-KM; Wed, 21 Mar 2007 07:49:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzJm-0001h0-Js for geopriv@ietf.org; Wed, 21 Mar 2007 07:49:26 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTzJS-0005pO-6e for geopriv@ietf.org; Wed, 21 Mar 2007 07:49:26 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 21 Mar 2007 04:49:06 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l2LBn5dL032506; Wed, 21 Mar 2007 04:49:05 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2LBn4wn007363; Wed, 21 Mar 2007 11:49:05 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 07:49:04 -0400 Received: from mlinsnerwxp ([10.21.120.84]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 07:49:03 -0400 From: "Marc Linsner" To: "'Winterbottom, James'" , Subject: RE: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 07:49:01 -0400 Message-ID: <006f01c76bae$ed1757c0$25d8520a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdrn72HB/eKODQMScyBMH8b9gRhVAAAPXhgAAMEySA= X-OriginalArrivalTime: 21 Mar 2007 11:49:04.0051 (UTC) FILETIME=[EC8D4030:01C76BAE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1636; t=1174477745; x=1175341745; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20Location=20Integrity |Sender:=20; bh=Z3S7lb87Xxh/qZz5YQtZZN/kHOsW6r90RsR6h5zhbZI=; b=RZ+h1aCyNXPcXCd5ZoNSuOFvKvo1ud0LI4K1LICqcoh3iznA5EFo0AQwOCjDlBeeZwEwzRXi DgT6+JVwTRV4JR9/c+awClrtmkOsyEWcfWhlBoGPDEdoV59jqfmYwxJO; Authentication-Results: sj-dkim-5; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org James, > I will assert that the LIS providing the location > by-reference still requires a VESA certificate or the like in > order for this model to provide the same degree of trust as > the signatures that have been described. Consequently the > mechanism you describe has at least the same administrative > overhead with regards to certificate management. So that part > solves nothing. Ageed, CA management is required. This seems to be accepted by those proposing the certificate trust model. What I suggesting is a different/faster-to-market mechanism to perform that same level of integrity checking. I still have reservations about the ROI from using this model, you are asking to spend large amounts of public money to deploy/maintain this mechanism. I'm also amiss at the comple problematic with the state of multiple MIME bodies being what they are = today.=20 An L-by-R in an INVITE does seem to have the advantage of being = retrofitted=20 into networks and software more easily.

OK, given my ignorance on this, I have no choice but to believe = you. Is this insurmountable?

Additionally, if the dereference act provides the trust, then why = not=20 just use L-by-R in the INVITE? I must be missing something.

I see a large advantage to having L-by-V in the invite for = routing=20 purposes. I can't imagine the time will be available during a = routing=20 decision to either derefernce nor chase trust relationships. = L-by-V is=20 *required* for routing, IMO. Remember, we are already performing = LoST=20 queries during routing. Plus, the REAL requirement, which is = still in=20 dispute, is to not waste PSAP resources by dispatching to false=20 emergencies. With that said, there is time between call = session=20 establishment and dispatch of responders to perform integrity = checks on the=20 location data.

Finally, given the description of <provided-by> in RFC = 4119...=20 especially the text about SubjectAltName and certificates, it might be = wisest=20 to create a new element for this purpose.

I've accepted the realization that pidf-lo will be in=20 turmoil/change for some time, so I don't object to a new=20 element. With that said, there is nothing stopping = implementations=20 that agree to using provided-by doing so = TODAY.

-Marc-
------=_NextPart_000_006B_01C76B8D.65067030-- --===============1371099490== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1371099490==-- te dismissal of other suggestions to satisfy the requirement that have higher ROI, hence I think consensus on the requirement is needed. > > Secondly, this solution does not solve the total collusion > problem of two people swapping identity information around > the place, so it doesn't solve anything more than what has > been described in the Thomson location dependability draft. Like I said, faster time to market with parallel benefit. > It does however, as you point out, now require a location > reference mechanism over and above the location by value > already being sent in order to provide a questionable degree a surety. Ack > In case you hadn't guessed I don't like this proposal as it > provides nothing extra except for processing cycles. I got that. -Marc- _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 07:49:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzJV-00019s-4E; Wed, 21 Mar 2007 07:49:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzJT-00015U-Ba for geopriv@ietf.org; Wed, 21 Mar 2007 07:49:07 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTzJQ-00018P-Kw for geopriv@ietf.org; Wed, 21 Mar 2007 07:49:07 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 21 Mar 2007 04:49:04 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l2LBn3je004494; Wed, 21 Mar 2007 04:49:03 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2LBn3wn007356; Wed, 21 Mar 2007 11:49:03 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 07:49:02 -0400 Received: from mlinsnerwxp ([10.21.120.84]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 07:49:02 -0400 From: "Marc Linsner" To: "'Andrew Newton'" Subject: RE: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 07:49:01 -0400 Message-ID: <006a01c76bae$ec181030$25d8520a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <936B6027-9122-4443-8968-E0A63374052D@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdrp8ttNq+FBPrCSmKNTIIGiZ3sAgAAVFoQ X-OriginalArrivalTime: 21 Mar 2007 11:49:02.0395 (UTC) FILETIME=[EB9090B0:01C76BAE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6815; t=1174477743; x=1175341743; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20Location=20Integrity |Sender:=20; bh=/WVAL1ixNqLwDFDynE29tiwPVXI/Z3xtPRYeup6+nN4=; b=MTBaGrhki7wZMU8A7QveNsJCrt1sDD1iG9Q3VmqcXTX1Ha6Qe9ULTRpa96b7Tz4HN/tR8ybi z3zu/Ywae9xduRiLJ1AbtZdADf1pOA/u/hll98Km1vVhx9Yu/SE+yJ36; Authentication-Results: sj-dkim-7; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: 'GEOPRIV WG' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1371099490==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============1371099490== Content-Type: multipart/alternative; boundary="----=_NextPart_000_006B_01C76B8D.65067030" This is a multi-part message in MIME format. ------=_NextPart_000_006B_01C76B8D.65067030 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andy, Marc's proposal is simpler and requires little standardization effort. And the act of the dereference provides an opportunity to thwart replay attacks. As I stated earlier, I do believe an update on location between sip session establishment and responder dispatch is going to become normal procedure. If I'm right, location integrity is best performed closest to the time it has high-value usage. I do have concerns though. It relies on L-by-V, which might be problematic with the state of multiple MIME bodies being what they are today. An L-by-R in an INVITE does seem to have the advantage of being retrofitted into networks and software more easily. OK, given my ignorance on this, I have no choice but to believe you. Is this insurmountable? Additionally, if the dereference act provides the trust, then why not just use L-by-R in the INVITE? I must be missing something. I see a large advantage to having L-by-V in the invite for routing purposes. I can't imagine the time will be available during a routing decision to either derefernce nor chase trust relationships. L-by-V is *required* for routing, IMO. Remember, we are already performing LoST queries during routing. Plus, the REAL requirement, which is still in dispute, is to not waste PSAP resources by dispatching to false emergencies. With that said, there is time between call session establishment and dispatch of responders to perform integrity checks on the location data. Finally, given the description of in RFC 4119... especially the text about SubjectAltName and certificates, it might be wisest to create a new element for this purpose. I've accepted the realization that pidf-lo will be in turmoil/change for some time, so I don't object to a new element. With that said, there is nothing stopping implementations that agree to using provided-by doing so TODAY. -Marc- ------=_NextPart_000_006B_01C76B8D.65067030 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Andy,

Marc's proposal is simpler and requires little standardization = effort.=20 And the act of the dereference provides an opportunity to thwart = replay=20 attacks.

As I stated earlier, I do believe an update on=20 location between sip session establishment and responder dispatch is going = to become=20 normal procedure.  If I'm right, location integrity is = best=20 performed closest to the time it has high-value = usage.

I do have concerns though. It relies on L-by-V, which might be=20 problematic with the state of multiple MIME bodies being what they are = today.=20 An L-by-R in an INVITE does seem to have the advantage of being = retrofitted=20 into networks and software more easily.

OK, given my ignorance on this, I have no choice but to believe = you. Is this insurmountable?

Additionally, if the dereference act provides the trust, then why = not=20 just use L-by-R in the INVITE? I must be missing something.

I see a large advantage to having L-by-V in the invite for = routing=20 purposes. I can't imagine the time will be available during a = routing=20 decision to either derefernce nor chase trust relationships. = L-by-V is=20 *required* for routing, IMO. Remember, we are already performing = LoST=20 queries during routing. Plus, the REAL requirement, which is = still in=20 dispute, is to not waste PSAP resources by dispatching to false=20 emergencies. With that said, there is time between call = session=20 establishment and dispatch of responders to perform integrity = checks on the=20 location data.

Finally, given the description of <provided-by> in RFC = 4119...=20 especially the text about SubjectAltName and certificates, it might be = wisest=20 to create a new element for this purpose.

I've accepted the realization that pidf-lo will be in=20 turmoil/change for some time, so I don't object to a new=20 element. With that said, there is nothing stopping = implementations=20 that agree to using provided-by doing so = TODAY.

-Marc-
------=_NextPart_000_006B_01C76B8D.65067030-- --===============1371099490== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1371099490==-- From geopriv-bounces@ietf.org Wed Mar 21 08:08: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 1HTzcV-0007kz-IM; Wed, 21 Mar 2007 08:08:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzcU-0007kc-Ao for geopriv@ietf.org; Wed, 21 Mar 2007 08:08:46 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTzcT-0001tM-15 for geopriv@ietf.org; Wed, 21 Mar 2007 08:08:46 -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 1HTzcM-0006Od-4l; Wed, 21 Mar 2007 08:08:38 -0400 Message-ID: <46012040.8010906@bbn.com> Date: Wed, 21 Mar 2007 13:08:32 +0100 From: Richard Barnes User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Geopriv] Location Integrity References: <006f01c76bae$ed1757c0$25d8520a@amer.cisco.com> In-Reply-To: <006f01c76bae$ed1757c0$25d8520a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org If you're going to have the certificate infrastructure anyway, why not just make a PIDF-LO per Marc's proposal, drop it in an S/MIME container, and sign it? There's no extra standardization, and you get integrity and origin authentication for both the by-value and by-reference locations. This requires no additional standardization action, other than maybe a BCP describing this stuff. --RB Marc Linsner wrote: > James, > > >> I will assert that the LIS providing the location >> by-reference still requires a VESA certificate or the like in >> order for this model to provide the same degree of trust as >> the signatures that have been described. Consequently the >> mechanism you describe has at least the same administrative >> overhead with regards to certificate management. So that part >> solves nothing. > > Ageed, CA management is required. This seems to be accepted by those > proposing the certificate trust model. What I suggesting is a > different/faster-to-market mechanism to perform that same level of integrity > checking. I still have reservations about the ROI from using this model, > you are asking to spend large amounts of public money to deploy/maintain > this mechanism. > > I'm also amiss at the complete dismissal of other suggestions to satisfy the > requirement that have higher ROI, hence I think consensus on the requirement > is needed. > >> Secondly, this solution does not solve the total collusion >> problem of two people swapping identity information around >> the place, so it doesn't solve anything more than what has >> been described in the Thomson location dependability draft. > > Like I said, faster time to market with parallel benefit. > >> It does however, as you point out, now require a location >> reference mechanism over and above the location by value >> already being sent in order to provide a questionable degree a surety. > > Ack > >> In case you hadn't guessed I don't like this proposal as it >> provides nothing extra except for processing cycles. > > I got that. > > -Marc- > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 08:15:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzjA-00020f-6F; Wed, 21 Mar 2007 08:15:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzj9-000208-3N for geopriv@ietf.org; Wed, 21 Mar 2007 08:15:39 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTzj7-0003wT-SU for geopriv@ietf.org; Wed, 21 Mar 2007 08:15:39 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Mar 2007 08:15:38 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2LCFbDn011056; Wed, 21 Mar 2007 08:15:37 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2LCFXlG006966; Wed, 21 Mar 2007 12:15:33 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 08:15:33 -0400 Received: from mlinsnerwxp ([10.21.115.188]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 08:15:31 -0400 From: "Marc Linsner" To: "'Richard Barnes'" Subject: RE: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 08:15:28 -0400 Message-ID: <007b01c76bb2$9f73ddf0$25d8520a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <46012040.8010906@bbn.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdrsbAHA7kd/1qzQhynBfugb+axXAAAELXw X-OriginalArrivalTime: 21 Mar 2007 12:15:32.0279 (UTC) FILETIME=[9F359C70:01C76BB2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=318; t=1174479337; x=1175343337; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20Location=20Integrity |Sender:=20 |To:=20=22'Richard=20Barnes'=22=20; bh=fknWMuLZG1lTSG6e/irgmyP46G8+B1kmSvP3XkzaSUk=; b=l5lj49Sb6Ske1CtUHsUxsK+915+1dFClA2sng4Fo66Rcp/adzB31n+OmhnKlz42MFqmjJd4P tZIb+V4eLHlmuC2HCuMuTuOGuRJuVJ4JqRYNHH0O430AhjDegHeG2QQv; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Richard, > If you're going to have the certificate infrastructure > anyway, why not just make a PIDF-LO per Marc's proposal, drop > it in an S/MIME container, and sign it? Who is signing it at this point? There is other information in the pidf-lo than what the access network LIS provides. -Marc- _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 08:16:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzkI-0003Rs-1A; Wed, 21 Mar 2007 08:16:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzkH-0003Rm-FE for geopriv@ietf.org; Wed, 21 Mar 2007 08:16:49 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTzkG-0004Kp-4q for geopriv@ietf.org; Wed, 21 Mar 2007 08:16:49 -0400 Received: from [130.129.22.195] (dhcp-16c3.ietf68.org [130.129.22.195]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2LCGhuk028223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 21 Mar 2007 08:16:47 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 08:16:40 -0400 To: GEOPRIV WG 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: dbb8771284c7a36189745aa720dc20ab X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Leaving the detailed mechanism aside, I think there is value to differentiate between the CA function and the "trust" function. Creating a new special-purpose CA requires far more overhead, cost and complexity than stating that "Acme Corp, as certified by FalsiSign Inc, can be trusted to provide true location (or identity) information". FalsiSign's cert would be the normal HTTP or SIP cert, as applicable, already commercially available from many competing providers. There are many ways to accomplish the protocol mechanics, including, but not limited to, transporting LOs in TLS when derefencing to including a verification reference in the LO. It would be helpful to explore these as opposed to simply reiterating the same "my sign way or the highway". Henning On Mar 21, 2007, at 6:12 AM, Winterbottom, James wrote: > Marc, > > I will assert that the LIS providing the location by-reference still > requires a VESA certificate or the like in order for this model to > provide the same degree of trust as the signatures that have been > described. Consequently the mechanism you describe has at least the > same > administrative overhead with regards to certificate management. So > that > part solves nothing. > > Secondly, this solution does not solve the total collusion problem of > two people swapping identity information around the place, so it > doesn't > solve anything more than what has been described in the Thomson > location > dependability draft. It does however, as you point out, now require a > location reference mechanism over and above the location by value > already being sent in order to provide a questionable degree a surety. > In case you hadn't guessed I don't like this proposal as it provides > nothing extra except for processing cycles. > > Cheers > James > > >> -----Original Message----- >> From: Marc Linsner [mailto:mlinsner@cisco.com] >> Sent: Wednesday, 21 March 2007 9:01 PM >> To: geopriv@ietf.org >> Subject: [Geopriv] Location Integrity >> >> I've proposed this in a couple of obtuse emails to the list, but >> after >> asking a few, it appears it hasn't been understood. I know, a draft > is >> needed, but for the discussion on tomorrow's agenda, I thought I >> would >> reiterate here. >> >> It appears there is large support for using certificates to establish > a >> trust between the Location Recipient and the author of the location >> information. This is possible today using a couple of different > methods. >> One that I'm not sure is clear is using the provided-by within the > pidf- >> lo, >> populating with a random L-by-R uri, then requesting TLS is employed > while >> dereferencing. The trust is gained/denied during the dereference >> operation/TLS connection establishment. If the location value > returned by >> the dereference matches the L-by-V provided initially, you now have > the >> same >> level of trust that is gained with the proposed location signing. >> >> A few of advantages of this method: >> >> 1) No IETF work required. Faster time to market. Everything is > in-place >> to >> do this today. Provided-by = pres:12456abcdef@accessprovider.net >> >> 2) L-by-V is used in the SIP invite, intermediate routing proxies > don't >> need >> to dereference anything for routing, they simply use the by-value > data. >> >> 3) The dereference operation provides multiple attributes: >> establishes > the >> trust via certificates, and sets up a presence subscribe/notify for >> tracking >> a mobile client (corresponding to the rebid process deployed in NA > PSAPs >> today). >> >> I'm sure there are downsides that I'm missing, please point them out. > The >> obvious one is the extra step required to get the certificate > initially, >> but >> if the AOR of major providers is somewhat static and well known by > PSAPs >> as >> claimed by some, only comparison of the location data is needed, a > process >> that is probably prudent prior to dispatch anyway. >> >> -Marc- >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2] > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 08:37:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU04P-0006u8-BY; Wed, 21 Mar 2007 08:37:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU04O-0006tt-AA for geopriv@ietf.org; Wed, 21 Mar 2007 08:37:36 -0400 Received: from bellwecs5.srvr.bell.ca ([207.236.237.117]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HU04G-0001Yj-B2 for geopriv@ietf.org; Wed, 21 Mar 2007 08:37:36 -0400 Received: (qmail 5782 invoked from network); 21 Mar 2007 12:37:27 -0000 Received: from g.caron@bell.ca by bellwecs5.srvr.bell.ca with EntrustECS-Server-7.4; 21 Mar 2007 12:37:27 -0000 Received: from bellwfep4.bellnexxia.net (HELO bellwfep4-srv.bellnexxia.net) (207.236.237.110) by bellwecs5.srvr.bell.ca with SMTP; 21 Mar 2007 12:37:27 -0000 Received: from TOROONDC908.bell.corp.bce.ca ([142.182.89.88]) by bellwfep4-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20070321123727.XRYE1719.bellwfep4-srv.bellnexxia.net@TOROONDC908.bell.corp.bce.ca>; Wed, 21 Mar 2007 08:37:27 -0400 Received: from toroondc912.bell.corp.bce.ca ([142.182.89.15]) by TOROONDC908.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 08:37:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] Contribution on Location for Emergency Calls Date: Wed, 21 Mar 2007 08:37:25 -0400 Message-ID: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A4BF4FA@toroondc912> In-Reply-To: <003f01c76b97$08dddd20$25d8520a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Contribution on Location for Emergency Calls Thread-Index: AcdowurqchvHByImQI+n6RMP+fd7NgBXUvyAAF2RLIAABu+nAA== References: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A4BF4DE@toroondc912> <003f01c76b97$08dddd20$25d8520a@amer.cisco.com> From: To: , X-OriginalArrivalTime: 21 Mar 2007 12:37:27.0413 (UTC) FILETIME=[AF172250:01C76BB5] X-Spam-Score: 0.2 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Marc, I like the idea of a protocol being vetted by the IETF, especially when = it can be used over the Internet. Furthermore, it is always nice to have = a referencable Standard when talking with vendors. Guy Caron -----Message d'origine----- De=A0: Marc Linsner [mailto:mlinsner@cisco.com]=20 Envoy=E9=A0: 21 mars 2007 04:58 =C0=A0: Caron, Guy (A162859); geopriv@ietf.org Objet=A0: RE: [Geopriv] Contribution on Location for Emergency Calls Guy, You've made this request a few times now. I'm curious what the = implications of a GeoPriv decision are to your implementation? -Marc- =20 > -----Original Message----- > From: g.caron@bell.ca [mailto:g.caron@bell.ca]=20 > Sent: Tuesday, March 20, 2007 10:03 PM > To: john.medland@bt.com; geopriv@ietf.org > Subject: RE: [Geopriv] Contribution on Location for Emergency Calls >=20 > I fully support John's request to move things a bit here in=20 > order to get an L7-LCP accepted as a WG item in Prague. >=20 > Just one point of clarification: At this moment, HELD is=20 > being "strongly considered" in Canada. Nevertheless, as a=20 > proponent of an L7-LCP and a short term implementer, HELD is=20 > my preferred choice and would like to see it promoted. >=20 > Thanks, >=20 > Guy Caron > ________________________________________ > De=A0: john.medland@bt.com [mailto:john.medland@bt.com] Envoy=E9=A0 > : 17 mars 2007 14:35 =C0=A0: geopriv@ietf.org Objet=A0: [Geopriv]=20 > Contribution on Location for Emergency Calls >=20 >=20 > As BT's UK 112/999 Policy Manager, I'd like to urge the IETF=20 > to make a decision next week on a suitable Location=20 > Acquisition Protocol. > I'm responsible for how emergency calls are handled in BT's=20 > PSAPs (28 million emergency calls from fixed and mobile=20 > devices each year).=A0 We are experiencing a rapid growth in=20 > VoIP emergency calls and urgently need a referencable=20 > standard against which to plan developments in the UK, that=20 > we can be sure also allows international calling scenarios to=20 > be managed. > I'm aware the HELD protocol is at an advanced stage of=20 > development, is being adopted in Canada, and it would seem=20 > appropriate to give this serious consideration as a suitable=20 > way forward.=A0=A0 Thanks and regards > John Medland=20 > Tel:+44 (0)1977 593408 | Email: john.medland@bt.com=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 08:40: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 1HU072-0007kP-84; Wed, 21 Mar 2007 08:40:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU071-0007kH-4s for geopriv@ietf.org; Wed, 21 Mar 2007 08:40:19 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU06w-0002ln-F4 for geopriv@ietf.org; Wed, 21 Mar 2007 08:40:19 -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 1HU06w-0003Jz-3N; Wed, 21 Mar 2007 08:40:14 -0400 Message-ID: <460127A7.3020109@bbn.com> Date: Wed, 21 Mar 2007 13:40:07 +0100 From: Richard Barnes User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Geopriv] Location Integrity References: <007b01c76bb2$9f73ddf0$25d8520a@amer.cisco.com> In-Reply-To: <007b01c76bb2$9f73ddf0$25d8520a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Use the same key to sign it that the TLS cert attests. That way, the same signer vouches for the PIDF-LO and the LO resulting from the dereference. --RB Marc Linsner wrote: > Richard, > > >> If you're going to have the certificate infrastructure >> anyway, why not just make a PIDF-LO per Marc's proposal, drop >> it in an S/MIME container, and sign it? > > Who is signing it at this point? There is other information in the pidf-lo > than what the access network LIS provides. > > -Marc- > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 08:56:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU0MU-0008LH-L8; Wed, 21 Mar 2007 08:56:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU0MT-0008Il-Rg for geopriv@ietf.org; Wed, 21 Mar 2007 08:56:17 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU0MS-0005cv-Iq for geopriv@ietf.org; Wed, 21 Mar 2007 08:56:17 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 21 Mar 2007 05:56:16 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2LCuFjN031419; Wed, 21 Mar 2007 05:56:16 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2LCtTMr008024; Wed, 21 Mar 2007 12:56:15 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 08:56:12 -0400 Received: from mlinsnerwxp ([10.21.115.188]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 08:56:11 -0400 From: "Marc Linsner" To: "'Richard Barnes'" Subject: RE: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 08:56:09 -0400 Message-ID: <008c01c76bb8$4cf752e0$25d8520a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <460127A7.3020109@bbn.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdrthtTjuL2PIhHQdmkKtwwad5cFgAAdLxw X-OriginalArrivalTime: 21 Mar 2007 12:56:12.0145 (UTC) FILETIME=[4D7B9E10:01C76BB8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=280; t=1174481776; x=1175345776; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20Location=20Integrity |Sender:=20; bh=YOTckwRngH64iKjZUtbCCy5gnq5Yyo8vuuieJJ7KHHU=; b=W0oOsyyTSgNzcbmonXUat4de9/mTy0zz+Pi06lKAomFqglzeU+sAwsBRJRb+r+g7ZlfksOCC iwd+b1KAkvTfuWhH/CNquzGi1WwNh2B3mSWyfQm4Xbogz2OJUyC6uXIQYzONFK3605rXM8brQ0 Q+EhSWwI/+MK7nwYm3oZJsobw=; Authentication-Results: sj-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Richard, > > Use the same key to sign it that the TLS cert attests. That > way, the same signer vouches for the PIDF-LO and the LO > resulting from the dereference. Huh? Please provide state-machine-like steps showing what gets signed when/where/who/why. -Marc- _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 09:13: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 1HU0cu-0001OW-1i; Wed, 21 Mar 2007 09:13:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU0cs-0001Mq-2G for geopriv@ietf.org; Wed, 21 Mar 2007 09:13:14 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HU0cq-0005Fh-J0 for geopriv@ietf.org; Wed, 21 Mar 2007 09:13:13 -0400 X-SEF-Processed: 5_0_0_910__2007_03_21_08_19_10 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, 21 Mar 2007 08:19:10 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 08:13:03 -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: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 08:12:57 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Location Integrity Thread-Index: Acdrss6dGdeKfROlTMC9KAFGBkvafQABwWLQ From: "Dawson, Martin" To: "Henning Schulzrinne" , "GEOPRIV WG" X-OriginalArrivalTime: 21 Mar 2007 13:13:03.0836 (UTC) FILETIME=[A87F69C0:01C76BBA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Henning=0D=0A=0D=0AI agree the two things you mention below are differen= t - but I don't=0D=0Aunderstand what contribution the latter makes to locat= ion integrity. How=0D=0Adoes a recipient know that Acme Corp is trusted=3F=0D= =0A=0D=0AI mean, if all you are saying is that the recipient may be comfort= able=0D=0Awith recognizing a well-known and trusted brand as certified by V= erisign=0D=0A- then sure. Really, that is putting Verisign in the role of V= ESA with=0D=0Athe additional requirement on location recipients to maintain= the list=0D=0Aof signers that they will trust for location integrity.=0D=0A=0D= =0AI don't think that's a sea change as far as proposals go... much the=0D=0A= same process and infrastructure is involved either way. Indeed, it would=0D= =0Abe a reasonable option for some jurisdictions.=0D=0A=0D=0ACheers,=0D=0AM= artin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Henning Schulzrinne = [mailto:hgs@cs.columbia.edu]=20=0D=0ASent: Wednesday, 21 March 2007 11:17 P= M=0D=0ATo: GEOPRIV WG=0D=0ASubject: Re: [Geopriv] Location Integrity=0D=0A=0D= =0ALeaving the detailed mechanism aside, I think there is value to =20=0D=0A= differentiate between the CA function and the "trust" function. =20=0D=0ACr= eating a new special-purpose CA requires far more overhead, cost =20=0D=0Aa= nd complexity than stating that "Acme Corp, as certified by =20=0D=0AFalsiS= ign Inc, can be trusted to provide true location (or identity) =20=0D=0Ainf= ormation". FalsiSign's cert would be the normal HTTP or SIP cert, =20=0D=0A= as applicable, already commercially available from many competing =20=0D=0A= providers.=0D=0A=0D=0AThere are many ways to accomplish the protocol mechan= ics, including, =20=0D=0Abut not limited to, transporting LOs in TLS when d= erefencing to =20=0D=0Aincluding a verification reference in the LO. It wou= ld be helpful to =20=0D=0Aexplore these as opposed to simply reiterating th= e same "my sign way =20=0D=0Aor the highway".=0D=0A=0D=0AHenning=0D=0A=0D=0A= On Mar 21, 2007, at 6:12 AM, Winterbottom, James wrote:=0D=0A=0D=0A> Marc,=0D= =0A>=0D=0A> I will assert that the LIS providing the location by-reference = still=0D=0A> requires a VESA certificate or the like in order for this mode= l to=0D=0A> provide the same degree of trust as the signatures that have be= en=0D=0A> described. Consequently the mechanism you describe has at least t= he =20=0D=0A> same=0D=0A> administrative overhead with regards to certifica= te management. So =20=0D=0A> that=0D=0A> part solves nothing.=0D=0A>=0D=0A>= Secondly, this solution does not solve the total collusion problem of=0D=0A= > two people swapping identity information around the place, so it =20=0D=0A= > doesn't=0D=0A> solve anything more than what has been described in the Th= omson =20=0D=0A> location=0D=0A> dependability draft. It does however, as y= ou point out, now require a=0D=0A> location reference mechanism over and ab= ove the location by value=0D=0A> already being sent in order to provide a q= uestionable degree a surety.=0D=0A> In case you hadn't guessed I don't like= this proposal as it provides=0D=0A> nothing extra except for processing cy= cles.=0D=0A>=0D=0A> Cheers=0D=0A> James=0D=0A>=0D=0A>=0D=0A>> -----Original= Message-----=0D=0A>> From: Marc Linsner [mailto:mlinsner@cisco.com]=0D=0A>= > Sent: Wednesday, 21 March 2007 9:01 PM=0D=0A>> To: geopriv@ietf.org=0D=0A= >> Subject: [Geopriv] Location Integrity=0D=0A>>=0D=0A>> I've proposed this= in a couple of obtuse emails to the list, but =20=0D=0A>> after=0D=0A>> as= king a few, it appears it hasn't been understood. I know, a draft=0D=0A> i= s=0D=0A>> needed, but for the discussion on tomorrow's agenda, I thought I = =20=0D=0A>> would=0D=0A>> reiterate here.=0D=0A>>=0D=0A>> It appears there = is large support for using certificates to establish=0D=0A> a=0D=0A>> trust= between the Location Recipient and the author of the location=0D=0A>> info= rmation. This is possible today using a couple of different=0D=0A> methods= =2E=0D=0A>> One that I'm not sure is clear is using the provided-by within = the=0D=0A> pidf-=0D=0A>> lo,=0D=0A>> populating with a random L-by-R uri, t= hen requesting TLS is employed=0D=0A> while=0D=0A>> dereferencing. The tru= st is gained/denied during the dereference=0D=0A>> operation/TLS connection= establishment. If the location value=0D=0A> returned by=0D=0A>> the deref= erence matches the L-by-V provided initially, you now have=0D=0A> the=0D=0A= >> same=0D=0A>> level of trust that is gained with the proposed location si= gning.=0D=0A>>=0D=0A>> A few of advantages of this method:=0D=0A>>=0D=0A>> = 1) No IETF work required. Faster time to market. Everything is=0D=0A> in-= place=0D=0A>> to=0D=0A>> do this today. Provided-by =3D pres:12456abcdef@a= ccessprovider.net=0D=0A>>=0D=0A>> 2) L-by-V is used in the SIP invite, inte= rmediate routing proxies=0D=0A> don't=0D=0A>> need=0D=0A>> to dereference a= nything for routing, they simply use the by-value=0D=0A> data.=0D=0A>>=0D=0A= >> 3) The dereference operation provides multiple attributes: =20=0D=0A>> e= stablishes=0D=0A> the=0D=0A>> trust via certificates, and sets up a presenc= e subscribe/notify for=0D=0A>> tracking=0D=0A>> a mobile client (correspond= ing to the rebid process deployed in NA=0D=0A> PSAPs=0D=0A>> today).=0D=0A>= >=0D=0A>> I'm sure there are downsides that I'm missing, please point them = out.=0D=0A> The=0D=0A>> obvious one is the extra step required to get the c= ertificate=0D=0A> initially,=0D=0A>> but=0D=0A>> if the AOR of major provid= ers is somewhat static and well known by=0D=0A> PSAPs=0D=0A>> as=0D=0A>> cl= aimed by some, only comparison of the location data is needed, a=0D=0A> pro= cess=0D=0A>> that is probably prudent prior to dispatch anyway.=0D=0A>>=0D=0A= >> -Marc-=0D=0A>>=0D=0A>> _______________________________________________=0D= =0A>> Geopriv mailing list=0D=0A>> Geopriv@ietf.org=0D=0A>> https://www1.ie= tf.org/mailman/listinfo/geopriv=0D=0A>=0D=0A> -----------------------------= -----------------------------------------=0D=0A=0D=0A> --------------------= ------=0D=0A> This message is for the designated recipient only and may=0D=0A= > contain privileged, proprietary, or otherwise private information.=0D=0A>= If you have received it in error, please notify the sender=0D=0A> immediat= ely and delete the original. Any unauthorized use of=0D=0A> this email is = prohibited.=0D=0A> --------------------------------------------------------= --------------=0D=0A=0D=0A> --------------------------=0D=0A> [mf2]=0D=0A>=0D= =0A>=0D=0A> _______________________________________________=0D=0A> Geopriv = mailing list=0D=0A> Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailman/l= istinfo/geopriv=0D=0A=0D=0A=0D=0A__________________________________________= _____=0D=0AGeopriv mailing list=0D=0AGeopriv@ietf.org=0D=0Ahttps://www1.iet= f.org/mailman/listinfo/geopriv=0D=0A=0D=0A---------------------------------= ---------------------------------------------------------------=0D=0AThis m= essage is for the designated recipient only and may=0D=0Acontain privileged= , proprietary, or otherwise private information. =20=0D=0AIf you have recei= ved it in error, please notify the sender=0D=0Aimmediately and delete the o= riginal. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-----= ---------------------------------------------------------------------------= ----------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 09:34:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU0x0-0003Aw-3H; Wed, 21 Mar 2007 09:34:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU0wz-0003An-GU for geopriv@ietf.org; Wed, 21 Mar 2007 09:34:01 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU0wd-0004Ir-97 for geopriv@ietf.org; Wed, 21 Mar 2007 09:34:01 -0400 X-SEF-Processed: 5_0_0_910__2007_03_21_08_39_45 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, 21 Mar 2007 08:39:45 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 08:33:38 -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: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 08:33:38 -0500 Message-ID: In-Reply-To: <007b01c76bb2$9f73ddf0$25d8520a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Location Integrity Thread-Index: AcdrsbAHA7kd/1qzQhynBfugb+axXAAAELXwAAI8CcA= From: "Dawson, Martin" To: "Marc Linsner" , "Richard Barnes" X-OriginalArrivalTime: 21 Mar 2007 13:33:38.0908 (UTC) FILETIME=[88A871C0:01C76BBD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi all,=0D=0A=0D=0AThere have been a number of proposals that standard S/MI= ME covering the=0D=0Awhole PIDF-LO is an acceptable signature mechanism. I = think Richard is=0D=0Aproposing that here.=0D=0A=0D=0AI've mentioned before= that I'm not comfortable that the LIS wants to=0D=0Atake responsibility - = or to impose control over - every element in that=0D=0Astructure. Ideally i= t would just set and sign the parts that it=0D=0Acontributes. On that score= , Marc, it sounds like we may be agreeing.=0D=0A=0D=0AI'm not sure what the= fuss is about with respect to Marc's general=0D=0Aproposal. I think that a= ppropriate signing and CA validation on=0D=0Adereferencing makes perfectly = good sense when the end-consumer of the=0D=0Alocation is also the dereferen= cer. A certificate exchange associated=0D=0Awith the dereferencing seems ob= viously quite satisfactory as far=0D=0Aoffering equivalent surety about the= integrity of the location=0D=0Ainformation (there's a second order issue w= ith respect to checking=0D=0Adevice uniqueness that I won't go into). And, = finally, there's no issue=0D=0Awith respect to other parts of the PIDF-LO b= eing able to be defined by=0D=0Aother entities - this is coming straight fr= om the LIS so no other=0D=0Aentities are involved.=0D=0A=0D=0AHaving said a= ll that, I don't think that all network topologies,=0D=0Aapplication polici= es, or use cases in general are going to be supported=0D=0Aif location inte= grity is only able to be communicated when the final=0D=0Aconsumer is also = a dereferencer. I think there are definitely scenarios=0D=0Athat will invol= ve transmission by value through an intermediary. To that=0D=0Aend, I think= there still needs to be a defined mechanism that involves=0D=0Asigning the= actual value. As above, I'm not a big fan of just chucking=0D=0Athe whole = PIDF-LO into an S/MIME bucket as being that defined mechanism.=0D=0A=0D=0AS= o, while I don't object to Marc's proposal - I wouldn't agree that it=0D=0A= represents either a mutually exclusive or a solely adequate alternative=0D=0A= mechanism compared to signed value for location integrity. Perhaps as=0D=0A= Marc suggests it will offer the best time to market if the IETF take a=0D=0A= long time to establish a documented value signing mechanism. I just=0D=0Ath= ink that mechanism is required eventually anyway.=0D=0A=0D=0ACheers,=0D=0AM= artin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Marc Linsner [mailto= :mlinsner@cisco.com]=20=0D=0ASent: Wednesday, 21 March 2007 11:15 PM=0D=0AT= o: 'Richard Barnes'=0D=0ACc: geopriv@ietf.org=0D=0ASubject: RE: [Geopriv] L= ocation Integrity=0D=0A=0D=0ARichard,=20=0D=0A=0D=0A=20=0D=0A> If you're go= ing to have the certificate infrastructure=20=0D=0A> anyway, why not just m= ake a PIDF-LO per Marc's proposal, drop=20=0D=0A> it in an S/MIME container= , and sign it=3F=20=0D=0A=0D=0AWho is signing it at this point=3F There is= other information in the=0D=0Apidf-lo=0D=0Athan what the access network LI= S provides.=0D=0A=0D=0A-Marc-=0D=0A=0D=0A__________________________________= _____________=0D=0AGeopriv mailing list=0D=0AGeopriv@ietf.org=0D=0Ahttps://= www1.ietf.org/mailman/listinfo/geopriv=0D=0A=0D=0A-------------------------= -----------------------------------------------------------------------=0D=0A= This message is for the designated recipient only and may=0D=0Acontain priv= ileged, 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 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 09:40: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 1HU12u-0004kP-4i; Wed, 21 Mar 2007 09:40:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU12t-0004iA-27 for geopriv@ietf.org; Wed, 21 Mar 2007 09:40:07 -0400 Received: from fnord.ir.bbn.com ([192.1.100.210]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU12f-0005WQ-Aw for geopriv@ietf.org; Wed, 21 Mar 2007 09:40:06 -0400 Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 29A48528E; Wed, 21 Mar 2007 09:39:51 -0400 (EDT) From: Greg Troxel To: "Marc Linsner" Subject: Re: [Geopriv] Location Integrity In-Reply-To: <004301c76b9f$c49a5810$25d8520a@amer.cisco.com> (Marc Linsner's message of "Wed\, 21 Mar 2007 06\:00\:33 -0400") References: <004301c76b9f$c49a5810$25d8520a@amer.cisco.com> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (berkeley-unix) X-Hashcash: 1:20:070321:mlinsner@cisco.com::BfeVaQf65kyswFEI:00000000000000000000000000000000000000000004DuF X-Hashcash: 1:20:070321:geopriv@ietf.org::rXHfhBfiQmL+wC3R:07qt/ Date: Wed, 21 Mar 2007 09:39:48 -0400 Message-ID: MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1849211016==" Errors-To: geopriv-bounces@ietf.org --===============1849211016== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable It appears there is large support for using certificates to establish a trust between the Location Recipient and the author of the location information. I've been lurking and not paying close attention, but I have a few brief comments. I realize you probably know a lot of what I'm saying, but I'm erring on the side of saying too much since that seems more likely to be helpful. I'm uncomfortable when people use the word 'trust'. That properly refers to a human interaction where one entity has confidence in another to behave reasonably. Here, I think we're talking about authenticity of data, or confidence that some particular piece of data is accurate. I have found that avoiding the word trust tends to result in greater clarity as then people have to describe which piece of data and what property they want it to have. So I suggest that the word trust be completely eliminated from discussions of protocols. A signature on an object is very different from authentication of transported data. Certificates merely bind identities to public keys (identity certificates) or record authorization (typically via names). While this is a tremendously useful building block, many details remain. One that I'm not sure is clear is using the provided-by within the pidf-lo, populating with a random L-by-R uri, then requesting TLS is employed while dereferencing. The trust is gained/denied during the dereference operation/TLS connection establishment. If the location value returned by the dereference matches the L-by-V provided initially, you now have the same level of trust that is gained with the proposed location signing. In this case, it's necessary to be clear on what entity does TLS at the webserver that fulfills the uri request. That could well be different than the entity that would have signed a location. And, one needs to authenticate that the uri is the right one, in order to construct a proof that the result is correct (given reasonable and documented assumptions). Sorry if I'm causing trouble by stepping into this without knowing enough details. =2D-=20 Greg Troxel --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (NetBSD) iD8DBQFGATWk+vesoDJhHiURAlCUAJ9/BbOdmwZr6GuE9+Qsrh0+asvuaACfRg+f qDipIx0GxU4kKdTO6+yISXM= =e38/ -----END PGP SIGNATURE----- --=-=-=-- --===============1849211016== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1849211016==-- From geopriv-bounces@ietf.org Wed Mar 21 09:45: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 1HU18R-0001T6-2s; Wed, 21 Mar 2007 09:45:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU18Q-0001Sz-38 for geopriv@ietf.org; Wed, 21 Mar 2007 09:45:50 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU18O-0006zv-OO for geopriv@ietf.org; Wed, 21 Mar 2007 09:45:50 -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 1HU18M-0003wN-4D; Wed, 21 Mar 2007 09:45:46 -0400 Message-ID: <46013704.4060105@bbn.com> Date: Wed, 21 Mar 2007 14:45:40 +0100 From: Richard Barnes User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Geopriv] Location Integrity References: <004301c76b9f$c49a5810$25d8520a@amer.cisco.com> In-Reply-To: <004301c76b9f$c49a5810$25d8520a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org If there's no correspondence required between the by-value and the by-reference locations, then this leads to an interesting situation: -- Botnet operator seeds bots with a valid location URI -- Bots make up bogus LOs within the target PSAP's service area -- Bots make emergency calls with their generated LOs -- All calls get routed to target PSAP -- PSAP dereferences the URI, gets a cert that matches the domain At this point, each call has two locations: 1. The unverified by-value location that's within its service area, and 2. The verified by-reference location that's somewhere else on earth The result: The LO has passed your validity check (provided-by domain = cert domain), but is actually an invalid location. So this is a validation model that doesn't actually reflect a notion of validity. On the other hand, if you have include a comparison of the two LOs in your validity check, then this attack doesn't work, and this could actually be considered a check on the validity of the provided LO. But then you'd have to standardize this comparison operation. --Richar Marc Linsner wrote: > I've proposed this in a couple of obtuse emails to the list, but after > asking a few, it appears it hasn't been understood. I know, a draft is > needed, but for the discussion on tomorrow's agenda, I thought I would > reiterate here. > > It appears there is large support for using certificates to establish a > trust between the Location Recipient and the author of the location > information. This is possible today using a couple of different methods. > One that I'm not sure is clear is using the provided-by within the pidf-lo, > populating with a random L-by-R uri, then requesting TLS is employed while > dereferencing. The trust is gained/denied during the dereference > operation/TLS connection establishment. If the location value returned by > the dereference matches the L-by-V provided initially, you now have the same > level of trust that is gained with the proposed location signing. > > A few of advantages of this method: > > 1) No IETF work required. Faster time to market. Everything is in-place to > do this today. Provided-by = pres:12456abcdef@accessprovider.net > > 2) L-by-V is used in the SIP invite, intermediate routing proxies don't need > to dereference anything for routing, they simply use the by-value data. > > 3) The dereference operation provides multiple attributes: establishes the > trust via certificates, and sets up a presence subscribe/notify for tracking > a mobile client (corresponding to the rebid process deployed in NA PSAPs > today). > > I'm sure there are downsides that I'm missing, please point them out. The > obvious one is the extra step required to get the certificate initially, but > if the AOR of major providers is somewhat static and well known by PSAPs as > claimed by some, only comparison of the location data is needed, a process > that is probably prudent prior to dispatch anyway. > > -Marc- > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 09:46: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 1HU18y-0001Ya-6B; Wed, 21 Mar 2007 09:46:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU18x-0001YV-0Y for geopriv@ietf.org; Wed, 21 Mar 2007 09:46:23 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU18n-00077v-B0 for geopriv@ietf.org; Wed, 21 Mar 2007 09:46:22 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 21 Mar 2007 09:46:14 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2LDkCrM002825; Wed, 21 Mar 2007 09:46:12 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2LDk8lM021749; Wed, 21 Mar 2007 13:46:08 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 09:46:00 -0400 Received: from mlinsnerwxp ([10.21.115.188]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 09:45:58 -0400 From: "Marc Linsner" To: "'Dawson, Martin'" Subject: RE: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 09:45:58 -0400 Message-ID: <009901c76bbf$42757cf0$25d8520a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdrsbAHA7kd/1qzQhynBfugb+axXAAAELXwAAI8CcAAANAtEA== X-OriginalArrivalTime: 21 Mar 2007 13:45:59.0119 (UTC) FILETIME=[41DBADF0:01C76BBF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=646; t=1174484772; x=1175348772; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20Location=20Integrity |Sender:=20 |To:=20=22'Dawson,=20Martin'=22=20; bh=3n4ZTkA6AdWSwJac2B2TH+TytxBcdLSrjFbDnolwjA4=; b=uDwlRj5kmjOSmca4B06ulG1AA3CnFCwDCqLP5zOJtw8IsbMm88uust40gZzjOS0ZymEr2fWv v6f7eJG/Tdw3zHLI8v3HifBDDNQFZqPPUSG1GmWVG2tLRZ/ZFeLknzaz; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Martin, > > Having said all that, I don't think that all network > topologies, application policies, or use cases in general are > going to be supported if location integrity is only able to > be communicated when the final consumer is also a > dereferencer. I think there are definitely scenarios that > will involve transmission by value through an intermediary. Now were back to arguing the requirement(s). We will never converge on a solution if the requirement/use case is constantly changing. Can you share substantiated use cases/requirements that you are referring to in the above statement? Thanks, -Marc- _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 09:53:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1Fc-0008VG-5V; Wed, 21 Mar 2007 09:53:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1FM-0008NC-Nd for geopriv@ietf.org; Wed, 21 Mar 2007 09:53:00 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU1DI-0008DO-Im for geopriv@ietf.org; Wed, 21 Mar 2007 09:50:53 -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 1HU1DG-0007SV-3s; Wed, 21 Mar 2007 09:50:50 -0400 Message-ID: <46013830.4090705@bbn.com> Date: Wed, 21 Mar 2007 14:50:40 +0100 From: Richard Barnes User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Geopriv] Location Integrity References: <008c01c76bb8$4cf752e0$25d8520a@amer.cisco.com> In-Reply-To: <008c01c76bb8$4cf752e0$25d8520a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org What I'm proposing is that the transmitted LO (regardless of how it's constructed) has the following form: S/MIME-Data { Content-Type: application/pidf+xml ... reliable-lis@access.net ... } signed by reliable-lis@access.net This way, you get two avenues for verification: -- By reference (Marc): Dereference the provided-by reference and verify that (1) cert provided is the cert for the indicated domain and (2) the tranmitted LO matches (see my other message). -- By value (Richard): Verify the signature on the LO. These provide equivalent levels of assurance, since both methods are based on encryptions with the same private key: By value, the encrypted thing is the hash of the LO, by reference, the TLS PreMasterSecret (or some such). One way that this might work: 1. UA does L7LCP discovery 2. UA sends L7LCP query to his presence server, with LIS URI in the requires URI (e.g.) 3. Presence server passes query to the LIS, get LO 4. Presence server creates above signed LO, returns to UA 5. UA includes signed location in emergency call 6. Location recipient does Marc's authenticating dereference Does that make sense? --Richard Marc Linsner wrote: > Richard, >> Use the same key to sign it that the TLS cert attests. That >> way, the same signer vouches for the PIDF-LO and the LO >> resulting from the dereference. > > Huh? Please provide state-machine-like steps showing what gets signed > when/where/who/why. > > -Marc- > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 09:56: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 1HU1IG-0001Z5-JD; Wed, 21 Mar 2007 09:56:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1FS-0008Sq-Lb for geopriv@ietf.org; Wed, 21 Mar 2007 09:53:06 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU1BN-0007wz-8b for geopriv@ietf.org; Wed, 21 Mar 2007 09:48:55 -0400 Received: from [130.129.22.195] (dhcp-16c3.ietf68.org [130.129.22.195]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2LDmdte008339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 21 Mar 2007 09:48:45 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8B07F607-6B23-46C5-B8D2-CDFB8167347B@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 09:48:36 -0400 To: "Dawson, Martin" 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: 501044f827b673024f6a4cb1d46e67d2 Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org In this case, VeriSign has no clue about emergency calls or location signing, so it is not "assuming that role". As you hint at, this simply requires maintaining a list at the PSAP of trusted identities and a list of CAs (the latter is already available via typical TLS libraries). The bigger protocol issues relate to the conveyance, i.e., things other than XML-DSIG, exploring No, this is not a major change, just a way to simplify deployments and avoid creating a new special-purpose PKI. On Mar 21, 2007, at 9:12 AM, Dawson, Martin wrote: > Hi Henning > > I agree the two things you mention below are different - but I don't > understand what contribution the latter makes to location > integrity. How > does a recipient know that Acme Corp is trusted? > > I mean, if all you are saying is that the recipient may be comfortable > with recognizing a well-known and trusted brand as certified by > Verisign > - then sure. Really, that is putting Verisign in the role of VESA with > the additional requirement on location recipients to maintain the list > of signers that they will trust for location integrity. > > I don't think that's a sea change as far as proposals go... much the > same process and infrastructure is involved either way. Indeed, it > would > be a reasonable option for some jurisdictions. > > Cheers, > Martin > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, 21 March 2007 11:17 PM > To: GEOPRIV WG > Subject: Re: [Geopriv] Location Integrity > > Leaving the detailed mechanism aside, I think there is value to > differentiate between the CA function and the "trust" function. > Creating a new special-purpose CA requires far more overhead, cost > and complexity than stating that "Acme Corp, as certified by > FalsiSign Inc, can be trusted to provide true location (or identity) > information". FalsiSign's cert would be the normal HTTP or SIP cert, > as applicable, already commercially available from many competing > providers. > > There are many ways to accomplish the protocol mechanics, including, > but not limited to, transporting LOs in TLS when derefencing to > including a verification reference in the LO. It would be helpful to > explore these as opposed to simply reiterating the same "my sign way > or the highway". > > Henning > > On Mar 21, 2007, at 6:12 AM, Winterbottom, James wrote: > >> Marc, >> >> I will assert that the LIS providing the location by-reference still >> requires a VESA certificate or the like in order for this model to >> provide the same degree of trust as the signatures that have been >> described. Consequently the mechanism you describe has at least the >> same >> administrative overhead with regards to certificate management. So >> that >> part solves nothing. >> >> Secondly, this solution does not solve the total collusion problem of >> two people swapping identity information around the place, so it >> doesn't >> solve anything more than what has been described in the Thomson >> location >> dependability draft. It does however, as you point out, now require a >> location reference mechanism over and above the location by value >> already being sent in order to provide a questionable degree a >> surety. >> In case you hadn't guessed I don't like this proposal as it provides >> nothing extra except for processing cycles. >> >> Cheers >> James >> >> >>> -----Original Message----- >>> From: Marc Linsner [mailto:mlinsner@cisco.com] >>> Sent: Wednesday, 21 March 2007 9:01 PM >>> To: geopriv@ietf.org >>> Subject: [Geopriv] Location Integrity >>> >>> I've proposed this in a couple of obtuse emails to the list, but >>> after >>> asking a few, it appears it hasn't been understood. I know, a draft >> is >>> needed, but for the discussion on tomorrow's agenda, I thought I >>> would >>> reiterate here. >>> >>> It appears there is large support for using certificates to >>> establish >> a >>> trust between the Location Recipient and the author of the location >>> information. This is possible today using a couple of different >> methods. >>> One that I'm not sure is clear is using the provided-by within the >> pidf- >>> lo, >>> populating with a random L-by-R uri, then requesting TLS is employed >> while >>> dereferencing. The trust is gained/denied during the dereference >>> operation/TLS connection establishment. If the location value >> returned by >>> the dereference matches the L-by-V provided initially, you now have >> the >>> same >>> level of trust that is gained with the proposed location signing. >>> >>> A few of advantages of this method: >>> >>> 1) No IETF work required. Faster time to market. Everything is >> in-place >>> to >>> do this today. Provided-by = pres:12456abcdef@accessprovider.net >>> >>> 2) L-by-V is used in the SIP invite, intermediate routing proxies >> don't >>> need >>> to dereference anything for routing, they simply use the by-value >> data. >>> >>> 3) The dereference operation provides multiple attributes: >>> establishes >> the >>> trust via certificates, and sets up a presence subscribe/notify for >>> tracking >>> a mobile client (corresponding to the rebid process deployed in NA >> PSAPs >>> today). >>> >>> I'm sure there are downsides that I'm missing, please point them >>> out. >> The >>> obvious one is the extra step required to get the certificate >> initially, >>> but >>> if the AOR of major providers is somewhat static and well known by >> PSAPs >>> as >>> claimed by some, only comparison of the location data is needed, a >> process >>> that is probably prudent prior to dispatch anyway. >>> >>> -Marc- >>> >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www1.ietf.org/mailman/listinfo/geopriv >> >> --------------------------------------------------------------------- >> - > >> -------------------------- >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> --------------------------------------------------------------------- >> - > >> -------------------------- >> [mf2] >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2] > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 10:01:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1Mm-00078y-14; Wed, 21 Mar 2007 10:00:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1Ml-00077C-CR for geopriv@ietf.org; Wed, 21 Mar 2007 10:00:39 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU1Mj-00020o-16 for geopriv@ietf.org; Wed, 21 Mar 2007 10:00:39 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HU1Li-0006Ni-Ts; Wed, 21 Mar 2007 08:59:35 -0500 From: "Brian Rosen" To: "'Greg Troxel'" , "'Marc Linsner'" Subject: RE: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 10:00:31 -0400 Message-ID: <00b801c76bc1$4d7a9d90$81238182@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: Thread-Index: AcdrvlUoxvdpv0DsSPitj/E79IPePgAAI8lA 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 - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I think you have a very hard battle ahead trying to remove the term "trust" from security discussions. We are in fact talking about trust some times: who does the PSAP trust to generate location objects for example. Sometimes we do talk about authenticity of data, which is one of the properties you might facilitate with a digital signature. For example, a signature can guaranty integrity of the data - it was not changed from the signer to the recipient. However, the usefulness of that authenticity depends on the trust you have in the signer. EvilCorp can legitimately sign something so that it authentically came from EvilCorp, but the PSAP may not trust EvilCorp to provide location. On the other hand, I assume you want us to use "authenticity" to mean the authentic location, regardless of who provided it or how we got it. Henning of course would want to point out that "authentic location" is not the requirement, it's "prevent diversion of PSAP and responder resources". Authentic location data is one path to meeting that requirement, which might require a trusted entity digitally signing a location object. Have I got terms straight? I do indeed believe it is a requirement that the entity that would sign a location be the one that would operate the server that did the provided-by dereference (or at least that there is a chain of trust between the two). Brian > -----Original Message----- > From: Greg Troxel [mailto:gdt@ir.bbn.com] > Sent: Wednesday, March 21, 2007 9:40 AM > To: Marc Linsner > Cc: geopriv@ietf.org > Subject: Re: [Geopriv] Location Integrity > > > It appears there is large support for using certificates to establish a > trust between the Location Recipient and the author of the location > information. > > I've been lurking and not paying close attention, but I have a few > brief comments. I realize you probably know a lot of what I'm saying, > but I'm erring on the side of saying too much since that seems more > likely to be helpful. > > I'm uncomfortable when people use the word 'trust'. That properly > refers to a human interaction where one entity has confidence in > another to behave reasonably. Here, I think we're talking about > authenticity of data, or confidence that some particular piece of data > is accurate. I have found that avoiding the word trust tends to > result in greater clarity as then people have to describe which piece > of data and what property they want it to have. So I suggest that the > word trust be completely eliminated from discussions of protocols. > > A signature on an object is very different from authentication of > transported data. > > Certificates merely bind identities to public keys (identity > certificates) or record authorization (typically via names). While > this is a tremendously useful building block, many details remain. > > One that I'm not sure is clear is using the provided-by within the > pidf-lo, populating with a random L-by-R uri, then requesting TLS is > employed while dereferencing. The trust is gained/denied during the > dereference operation/TLS connection establishment. If the location > value returned by the dereference matches the L-by-V provided > initially, you now have the same level of trust that is gained with > the proposed location signing. > > In this case, it's necessary to be clear on what entity does TLS at > the webserver that fulfills the uri request. That could well be > different than the entity that would have signed a location. And, one > needs to authenticate that the uri is the right one, in order to > construct a proof that the result is correct (given reasonable and > documented assumptions). > > Sorry if I'm causing trouble by stepping into this without knowing > enough details. > > -- > Greg Troxel _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 10:02:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1Ob-0001Ry-MK; Wed, 21 Mar 2007 10:02:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1OZ-0001LJ-VX for geopriv@ietf.org; Wed, 21 Mar 2007 10:02:31 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU1OY-0002VQ-Nq for geopriv@ietf.org; Wed, 21 Mar 2007 10:02:31 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Mar 2007 10:02:31 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2LE2Urp011745; Wed, 21 Mar 2007 10:02:30 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2LE2IGp020159; Wed, 21 Mar 2007 14:02:26 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 10:02:21 -0400 Received: from mlinsnerwxp ([10.21.115.188]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 10:02:20 -0400 From: "Marc Linsner" To: "'Richard Barnes'" Subject: RE: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 10:02:16 -0400 Message-ID: <00a801c76bc1$8929b2e0$25d8520a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <46013704.4060105@bbn.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdrv0HJtzNrZ8kWQKKflO1R8eB3bAAALoWw X-OriginalArrivalTime: 21 Mar 2007 14:02:20.0505 (UTC) FILETIME=[8ACF4C90:01C76BC1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=830; t=1174485750; x=1175349750; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20Location=20Integrity |Sender:=20 |To:=20=22'Richard=20Barnes'=22=20; bh=9V2jY9tJnyhlDH9ZMNDPMXmAE9uMq2mEETLEhABKTgY=; b=Ky50lW7IhSmKMimtj12Yi2U9R+/uCTdY8H6LmhZjMTqHca5X8oBCY1T77+LklD8EFhLDMs3U y7YBA9JSL0L/qjvqzhtePslWf4twdjxUKXjumuBm2xOCSX8/hgI66Ved; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Richard, > > On the other hand, if you have include a comparison of the > two LOs in your validity check, then this attack doesn't > work, and this could actually be considered a check on the > validity of the provided LO. But then you'd have to > standardize this comparison operation. This falls apart with mobile clients that are 'on the move'. The original by-value lo will never match the current dereferenced lo, but I agree they should be at least close (given normal rates of mobility, cars, planes, trains). But, the current location is only what I really care about, that is where I'm dispatching resources. If the by-value included in the call setup is in Los Angeles and the deferenced L-by-R from provided-by is New York, that *should* raise a flag to the Los Angeles call taker. -Marc- _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 10:36: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 1HU1v6-0002ZO-EU; Wed, 21 Mar 2007 10:36:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1v5-0002Ue-BE for geopriv@ietf.org; Wed, 21 Mar 2007 10:36:07 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU1v0-0002xH-Ne for geopriv@ietf.org; Wed, 21 Mar 2007 10:36:07 -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 1HU1ul-00086k-4r; Wed, 21 Mar 2007 10:35:47 -0400 Message-ID: <460142BB.5030203@bbn.com> Date: Wed, 21 Mar 2007 15:35:39 +0100 From: Richard Barnes User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Geopriv] Location Integrity References: <00a801c76bc1$8929b2e0$25d8520a@amer.cisco.com> In-Reply-To: <00a801c76bc1$8929b2e0$25d8520a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org (Re-creating a conversation just had with Marc) You're absolutely right. But what that means is that the verification you get from your procedure has nothing to do with the provided LO. You might as well provide them completely separately. That said, while the provided-by field provides a convenient field with no standardization needed, there are other standard mechanisms to convey both locations with the same property. Most notably, SIP location: To copy an example from draft-ietf-sip-location-conveyance: INVITE sips:bob@biloxi.example.com SIP/2.0 ... Geolocation: ;inserted-by=endpoint, ;inserted-by=endpoint Supported: geolocation --boundary1 Content-Type: application/sdp ...SDP here --boundary1 Content-Type: application/pidf+xml Content-ID: alice123@atlanta.example.com ... PIDF-LO here --boundary1-- You get the (possibly bogus) PIDF-LO object as a body part pointed to by the CID URI, and the verifiable reference in the PRES URI. --Richard Marc Linsner wrote: > Richard, > >> On the other hand, if you have include a comparison of the >> two LOs in your validity check, then this attack doesn't >> work, and this could actually be considered a check on the >> validity of the provided LO. But then you'd have to >> standardize this comparison operation. > > This falls apart with mobile clients that are 'on the move'. The original > by-value lo will never match the current dereferenced lo, but I agree they > should be at least close (given normal rates of mobility, cars, planes, > trains). But, the current location is only what I really care about, that > is where I'm dispatching resources. If the by-value included in the call > setup is in Los Angeles and the deferenced L-by-R from provided-by is New > York, that *should* raise a flag to the Los Angeles call taker. > > -Marc- > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 10:37: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 1HU1w0-00032r-Ab; Wed, 21 Mar 2007 10:37:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1vz-0002yw-2X for geopriv@ietf.org; Wed, 21 Mar 2007 10:37:03 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU1vr-000356-5X for geopriv@ietf.org; Wed, 21 Mar 2007 10:37:03 -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 1HU1vq-0004iM-4T for geopriv@ietf.org; Wed, 21 Mar 2007 10:36:54 -0400 Message-ID: <460142FF.8060302@bbn.com> Date: Wed, 21 Mar 2007 15:36:47 +0100 From: Richard Barnes User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: GEOPRIV WG Subject: Re: [Geopriv] Location Integrity 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: 0770535483960d190d4a0d020e7060bd X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Henning, To say it a different way, you're differentiating between two different types of trust: 1. FalsiSign is trusted to attest to the identity of Acme Corp 2. Acme Corp is trusted to attest to the reliablility of location information Both types of attestations are made, as you say, in various ways. But the standard way to make these attestations is to use public-key mechanisms, whether by creating signed objects (by value) or by communicating objects over an authenticated deference channel. I think we agree, --Richard Henning Schulzrinne wrote: > Leaving the detailed mechanism aside, I think there is value to > differentiate between the CA function and the "trust" function. Creating > a new special-purpose CA requires far more overhead, cost and complexity > than stating that "Acme Corp, as certified by FalsiSign Inc, can be > trusted to provide true location (or identity) information". FalsiSign's > cert would be the normal HTTP or SIP cert, as applicable, already > commercially available from many competing providers. > > There are many ways to accomplish the protocol mechanics, including, but > not limited to, transporting LOs in TLS when derefencing to including a > verification reference in the LO. It would be helpful to explore these > as opposed to simply reiterating the same "my sign way or the highway". > > Henning > > On Mar 21, 2007, at 6:12 AM, Winterbottom, James wrote: > >> Marc, >> >> I will assert that the LIS providing the location by-reference still >> requires a VESA certificate or the like in order for this model to >> provide the same degree of trust as the signatures that have been >> described. Consequently the mechanism you describe has at least the same >> administrative overhead with regards to certificate management. So that >> part solves nothing. >> >> Secondly, this solution does not solve the total collusion problem of >> two people swapping identity information around the place, so it doesn't >> solve anything more than what has been described in the Thomson location >> dependability draft. It does however, as you point out, now require a >> location reference mechanism over and above the location by value >> already being sent in order to provide a questionable degree a surety. >> In case you hadn't guessed I don't like this proposal as it provides >> nothing extra except for processing cycles. >> >> Cheers >> James >> >> >>> -----Original Message----- >>> From: Marc Linsner [mailto:mlinsner@cisco.com] >>> Sent: Wednesday, 21 March 2007 9:01 PM >>> To: geopriv@ietf.org >>> Subject: [Geopriv] Location Integrity >>> >>> I've proposed this in a couple of obtuse emails to the list, but after >>> asking a few, it appears it hasn't been understood. I know, a draft >> is >>> needed, but for the discussion on tomorrow's agenda, I thought I would >>> reiterate here. >>> >>> It appears there is large support for using certificates to establish >> a >>> trust between the Location Recipient and the author of the location >>> information. This is possible today using a couple of different >> methods. >>> One that I'm not sure is clear is using the provided-by within the >> pidf- >>> lo, >>> populating with a random L-by-R uri, then requesting TLS is employed >> while >>> dereferencing. The trust is gained/denied during the dereference >>> operation/TLS connection establishment. If the location value >> returned by >>> the dereference matches the L-by-V provided initially, you now have >> the >>> same >>> level of trust that is gained with the proposed location signing. >>> >>> A few of advantages of this method: >>> >>> 1) No IETF work required. Faster time to market. Everything is >> in-place >>> to >>> do this today. Provided-by = pres:12456abcdef@accessprovider.net >>> >>> 2) L-by-V is used in the SIP invite, intermediate routing proxies >> don't >>> need >>> to dereference anything for routing, they simply use the by-value >> data. >>> >>> 3) The dereference operation provides multiple attributes: establishes >> the >>> trust via certificates, and sets up a presence subscribe/notify for >>> tracking >>> a mobile client (corresponding to the rebid process deployed in NA >> PSAPs >>> today). >>> >>> I'm sure there are downsides that I'm missing, please point them out. >> The >>> obvious one is the extra step required to get the certificate >> initially, >>> but >>> if the AOR of major providers is somewhat static and well known by >> PSAPs >>> as >>> claimed by some, only comparison of the location data is needed, a >> process >>> that is probably prudent prior to dispatch anyway. >>> >>> -Marc- >>> >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www1.ietf.org/mailman/listinfo/geopriv >> >> ------------------------------------------------------------------------------------------------ >> >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> ------------------------------------------------------------------------------------------------ >> >> [mf2] >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 11:45:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU30I-0005RG-F9; Wed, 21 Mar 2007 11:45:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU30H-0005R5-QQ for geopriv@ietf.org; Wed, 21 Mar 2007 11:45:33 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU30E-0001TJ-Ry for geopriv@ietf.org; Wed, 21 Mar 2007 11:45:33 -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, 21 Mar 2007 11:40:58 -0400 id 0158C768.4601520A.0000457A In-Reply-To: <009901c76bbf$42757cf0$25d8520a@amer.cisco.com> References: <009901c76bbf$42757cf0$25d8520a@amer.cisco.com> Mime-Version: 1.0 Message-Id: From: Andrew Newton Subject: Re: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 11:45:03 -0400 To: Marc Linsner X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: geopriv@ietf.org, "'Dawson, Martin'" X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1985072726==" Errors-To: geopriv-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1985072726== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-17820-1174491683-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-17820-1174491683-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Mar 21, 2007, at 9:45 AM, Marc Linsner wrote: > Now were back to arguing the requirement(s). We will never > converge on a > solution if the requirement/use case is constantly changing. Bingo! Everybody in Prague should buy Marc a beer. -andy --=_zeke.ecotroph.net-17820-1174491683-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.54.2
On Mar 21, 2007, at 9:4= 5 AM, Marc Linsner wrote:

Now were = back to arguing the requirement(s).= =A0 We will never converge on a

solution if the requirement/use case is constantly chan= ging.

Bingo!=A0 Everybody in Pragu= e should buy Marc a beer.

-andy
--=_zeke.ecotroph.net-17820-1174491683-0001-2-- --===============1985072726== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1985072726==-- From geopriv-bounces@ietf.org Wed Mar 21 12:43: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 1HU3uG-0003QJ-31; Wed, 21 Mar 2007 12:43:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU3uE-0003PT-JR for geopriv@ietf.org; Wed, 21 Mar 2007 12:43:22 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU3u5-0001jL-VR for geopriv@ietf.org; Wed, 21 Mar 2007 12:43:22 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 21 Mar 2007 12:43:14 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2LGhDLI007838; Wed, 21 Mar 2007 12:43:13 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2LGh1lI014293; Wed, 21 Mar 2007 16:43:09 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 12:43:00 -0400 Received: from mlinsnerwxp ([10.21.118.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 12:42:59 -0400 From: "Marc Linsner" To: "'Andrew Newton'" Subject: RE: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 12:42:53 -0400 Message-ID: <00de01c76bd7$fb3c4440$25d8520a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdrz/XTxFgrYabkS/WrGanO7maWFgAB6AOg X-OriginalArrivalTime: 21 Mar 2007 16:43:00.0239 (UTC) FILETIME=[FC89F9F0:01C76BD7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2942; t=1174495393; x=1175359393; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20Location=20Integrity |Sender:=20 |To:=20=22'Andrew=20Newton'=22=20; bh=8SnCAaOfkEoG8WRheuJx/FVugYbuy2CmKcB2yWhQ6Ok=; b=LQnAMei37P5rcjBY/NBxGnh+sfDNqFTcXqYpL3SFdVqPiiB07lXubd9Xw5HeYxJuNyvb37zQ NVLJ/iipLR2PJXgspy6ZbM70Y3WwtAlkkpXzK/n/0rGfn/bcJ7inYpKm; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0467531924==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============0467531924== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DF_01C76BB6.742AA440" This is a multi-part message in MIME format. ------=_NextPart_000_00DF_01C76BB6.742AA440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'll second that (and third, and fourth, and ....) -Marc- _____ From: Andrew Newton [mailto:andy@hxr.us] Sent: Wednesday, March 21, 2007 11:45 AM To: Marc Linsner Cc: 'Dawson, Martin'; geopriv@ietf.org Subject: Re: [Geopriv] Location Integrity On Mar 21, 2007, at 9:45 AM, Marc Linsner wrote: Now were back to arguing the requirement(s). We will never converge on a solution if the requirement/use case is constantly changing. Bingo! Everybody in Prague should buy Marc a beer. -andy ------=_NextPart_000_00DF_01C76BB6.742AA440 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I'll second that (and third, and fourth, and=20 ....)

-Marc-

From: Andrew Newton = [mailto:andy@hxr.us]=20
Sent: Wednesday, March 21, 2007 11:45 AM
To: Marc = Linsner
Cc: 'Dawson, Martin'; = geopriv@ietf.org
Subject:=20 Re: [Geopriv] Location Integrity

On Mar 21, 2007, at 9:45 AM, Marc Linsner wrote:

Now were back to arguing the requirement(s). We will never converge on = a

solution if the requirement/use case is constantly=20 changing.

Bingo! Everybody in Prague should buy Marc a beer.

-andy
------=_NextPart_000_00DF_01C76BB6.742AA440-- --===============0467531924== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0467531924==-- From geopriv-bounces@ietf.org Wed Mar 21 12:52: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 1HU431-0000qK-C1; Wed, 21 Mar 2007 12:52:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU430-0000qF-E4 for geopriv@ietf.org; Wed, 21 Mar 2007 12:52:26 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU42p-0005Sr-1B for geopriv@ietf.org; Wed, 21 Mar 2007 12:52:26 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 21 Mar 2007 12:52:14 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2LGqEPC005915; Wed, 21 Mar 2007 12:52:14 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2LGqEGd011054; Wed, 21 Mar 2007 16:52:14 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 12:52:04 -0400 Received: from mlinsnerwxp ([10.21.118.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 12:52:03 -0400 From: "Marc Linsner" To: "'Richard Barnes'" , "'GEOPRIV WG'" Subject: RE: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 12:51:59 -0400 Message-ID: <00e901c76bd9$3f1c6810$25d8520a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <460142FF.8060302@bbn.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdrxoakdx0RgCMoQfW9cW28SbM3mgAEeuYg X-OriginalArrivalTime: 21 Mar 2007 16:52:03.0942 (UTC) FILETIME=[409C7860:01C76BD9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=886; t=1174495934; x=1175359934; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20Location=20Integrity |Sender:=20 |To:=20=22'Richard=20Barnes'=22=20, =20=22'GEOPRIV=20WG'= 22=20; bh=FZXr7lC4BpccPrrj6jMDhEATSh1KSzbm91pfZnglk6s=; b=Ytd3UIPyW2sOjyemdXUgKpK/8Udo1TLpSDyn7IumZZN0DZmj7F/Wg8g4UGCzI041HPdSgO2G hzA12uknn5SmXmm93BhZOBFBAfMRawK7K4SGeFSJa7T2LD7Unc1J4NuH; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Richard, > To say it a different way, you're differentiating between two > different types of trust: > > 1. FalsiSign is trusted to attest to the identity of Acme Corp > > 2. Acme Corp is trusted to attest to the reliablility of > location information > > Both types of attestations are made, as you say, in various > ways. But the standard way to make these attestations is to > use public-key mechanisms, whether by creating signed objects > (by value) or by communicating objects over an authenticated > deference channel. Unless we relinguish control of network operation to a some entity higher that a human being, it is very hard to assertain that the location information supplied is the actual location of the host in question, trusting the entity that supplied the information is probably the best possible with today's technology. -Marc- _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 16:14:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU7CM-00022w-T5; Wed, 21 Mar 2007 16:14:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU7CM-00022Z-0C for geopriv@ietf.org; Wed, 21 Mar 2007 16:14:18 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU7CI-0003R8-MW for geopriv@ietf.org; Wed, 21 Mar 2007 16:14:17 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Mar 2007 16:14:15 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2LKEEVb023363; Wed, 21 Mar 2007 16:14:14 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2LKE1H1016245; Wed, 21 Mar 2007 20:14:06 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 16:14:05 -0400 Received: from mlinsnerwxp ([10.21.153.119]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 16:14:04 -0400 From: "Marc Linsner" To: "'Greg Troxel'" Subject: RE: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 16:14:04 -0400 Message-ID: <012401c76bf5$7a581160$25d8520a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdrvmjTFsvQuN1ST0aQT47s70SbHwANWZvg X-OriginalArrivalTime: 21 Mar 2007 20:14:05.0128 (UTC) FILETIME=[7966AC80:01C76BF5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2394; t=1174508054; x=1175372054; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20Location=20Integrity |Sender:=20 |To:=20=22'Greg=20Troxel'=22=20; bh=mkw5NZIiy2QwHdrGlQ+kNRtrCF6N3AuhQ7r2F20ZXzY=; b=Op+9T8c1tmSpcDKeqgKvz50ytiZhTb4nrBOS8bVxwXH6oolFZ6xRUh6e9hGsHKLy97er3N3n E0ai3yzwB2sLgPJ1/ylA6+d/RvjOcvu5pkejibKf07OGsqzdr8lq0/xf; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Greg, I saw Brian's reply and I'm not trying to gang up on you. But.... > I've been lurking and not paying close attention, but I have > a few brief comments. I realize you probably know a lot of > what I'm saying, but I'm erring on the side of saying too > much since that seems more likely to be helpful. > > I'm uncomfortable when people use the word 'trust'. That > properly refers to a human interaction where one entity has > confidence in another to behave reasonably. Here, I think > we're talking about authenticity of data, or confidence that > some particular piece of data is accurate. I have found that > avoiding the word trust tends to result in greater clarity as > then people have to describe which piece of data and what > property they want it to have. So I suggest that the word > trust be completely eliminated from discussions of protocols. > > A signature on an object is very different from > authentication of transported data. > > Certificates merely bind identities to public keys (identity > certificates) or record authorization (typically via names). > While this is a tremendously useful building block, many > details remain. You, like Richard, seem to be implying that it is possible for IETF defined Internet protocols to provide absolute assurance that the location conveyed about an IP host is absolutely the location of such host. I'd like to hear how that is accomplished without complete upheaval of the current Internet (and I do have data that suggests such upheaval is not warranted). > In this case, it's necessary to be clear on what entity does > TLS at the webserver that fulfills the uri request. That > could well be different than the entity that would have > signed a location. And, one needs to authenticate that the > uri is the right one, in order to construct a proof that the > result is correct (given reasonable and documented assumptions). Yes, I am assuming that the entity providing the L-by-V to the IP host initially, knows how to represent itself in the L-by-R supplied at the same time such that the cert used for TLS during dereference represents the same entity. Given acceptance that a PSAP can only really 'trust' the provider of the location data, not the exact data itself, I don't see any problems. If you do, please advise. -Marc- _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 16:50:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU7lB-0004Ly-K3; Wed, 21 Mar 2007 16:50:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU7lA-0004Lt-Vt for geopriv@ietf.org; Wed, 21 Mar 2007 16:50:16 -0400 Received: from fnord.ir.bbn.com ([192.1.100.210]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU7ku-0002st-33 for geopriv@ietf.org; Wed, 21 Mar 2007 16:50:16 -0400 Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id D326D5289; Wed, 21 Mar 2007 16:49:57 -0400 (EDT) From: Greg Troxel To: "Brian Rosen" Subject: Re: [Geopriv] Location Integrity In-Reply-To: <00b801c76bc1$4d7a9d90$81238182@cis.neustar.com> (Brian Rosen's message of "Wed\, 21 Mar 2007 10\:00\:31 -0400") References: <00b801c76bc1$4d7a9d90$81238182@cis.neustar.com> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (berkeley-unix) X-Hashcash: 1:20:070321:geopriv@ietf.org::xAH66ag/GELOeJd3:01JpT X-Hashcash: 1:20:070321:mlinsner@cisco.com::Bml/ZPgqEjCxqnZw:000000000000000000000000000000000000000000054nr X-Hashcash: 1:20:070321:br@brianrosen.net::uVK7WWqDiav+1Hrj:000000000000000000000000000000000000000000009M7L Date: Wed, 21 Mar 2007 16:49:53 -0400 Message-ID: MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: geopriv@ietf.org, 'Marc Linsner' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1722331589==" Errors-To: geopriv-bounces@ietf.org --===============1722331589== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= "Brian Rosen" writes: > I think you have a very hard battle ahead trying to remove the term > "trust" from security discussions. We are in fact talking about > trust some times: who does the PSAP trust to generate location > objects for example. That's fair enough, but then we aren't talking about "certificates establishing trust", but rather certificates binding identity or recording human decisions about trust. I was really just asking for more clarity of language because have been finding this difficult to follow. The word trust is a trigger for me because I've seen the casual use of the word (not recognizing the above distinction on which we agree) strongly positively correlated with fuzzy thinking in other contexts. > Sometimes we do talk about authenticity of data, which is one of the > properties you might facilitate with a digital signature. For > example, a signature can guaranty integrity of the data - it was not > changed from the signer to the recipient. However, the usefulness > of that authenticity depends on the trust you have in the signer. > EvilCorp can legitimately sign something so that it authentically > came from EvilCorp, but the PSAP may not trust EvilCorp to provide > location. Agreed. > On the other hand, I assume you want us to use "authenticity" to > mean the authentic location, regardless of who provided it or how we > got it. Henning of course would want to point out that "authentic > location" is not the requirement, it's "prevent diversion of PSAP > and responder resources". Authentic location data is one path to > meeting that requirement, which might require a trusted entity > digitally signing a location object. Have I got terms straight? Yes, that's fine and I understand you. I'd use "accurate" to describe the location being correct, reserving "authentic" (or the combination of the "data origin authentication" service and the "integrity" service) to refer to a message which is known to have originated by some entity and not been modified. If I tell you I'm in Australia in this email, the message would still be authentic not not accurate. I realize that what you want is for very few significantly inaccurate locations to be delivered to PSAPs, for some values of very few and significant. > I do indeed believe it is a requirement that the entity that would sign a > location be the one that would operate the server that did the provided-by > dereference (or at least that there is a chain of trust between the two). That makes sense. I still wonder why L-by-R should use a different mechanism (TLS) rather than using a regular channel to return a signed object such as might be used with L-by-V. It seems that indirection for efficiency/convenience is being combined with security properties in a way which strikes me (as someone who admittedly has not been playing close attention) as hard to follow. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (NetBSD) iD8DBQFGAZpx+vesoDJhHiURAiqgAKCffKGiZEgyuUj9bAnL8HaSK3FoVQCfefG4 XiN8XFHq0+X9EnaqzzyMq48= =n4G3 -----END PGP SIGNATURE----- --=-=-=-- --===============1722331589== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1722331589==-- From geopriv-bounces@ietf.org Wed Mar 21 16:55:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU7qH-0005lm-3v; Wed, 21 Mar 2007 16:55:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU7qG-0005lh-Jv for geopriv@ietf.org; Wed, 21 Mar 2007 16:55:32 -0400 Received: from fnord.ir.bbn.com ([192.1.100.210]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HU7qF-0000dw-89 for geopriv@ietf.org; Wed, 21 Mar 2007 16:55:32 -0400 Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id E1C02528E; Wed, 21 Mar 2007 16:55:26 -0400 (EDT) From: Greg Troxel To: "Marc Linsner" Subject: Re: [Geopriv] Location Integrity References: <012401c76bf5$7a581160$25d8520a@amer.cisco.com> X-Hashcash: 1:20:070321:geopriv@ietf.org::FLkLT20m4GE/3XNB:02lTV X-Hashcash: 1:20:070321:mlinsner@cisco.com::VP4xNQ2qkeb63Rs8:00000000000000000000000000000000000000000005f0X Date: Wed, 21 Mar 2007 16:55:24 -0400 In-Reply-To: <012401c76bf5$7a581160$25d8520a@amer.cisco.com> (Marc Linsner's message of "Wed\, 21 Mar 2007 16\:14\:04 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (berkeley-unix) MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1120198799==" Errors-To: geopriv-bounces@ietf.org --===============1120198799== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable "Marc Linsner" writes: > You, like Richard, seem to be implying that it is possible for IETF defin= ed > Internet protocols to provide absolute assurance that the location convey= ed > about an IP host is absolutely the location of such host. I'd like to he= ar > how that is accomplished without complete upheaval of the current Internet > (and I do have data that suggests such upheaval is not warranted).=20=20= =20 I realize this isn't doable, and I didn't mean to argue that point. I'm really trying to say that as someone used to thinking about security and only semi paying attention, I'm having trouble following the discussion. >> In this case, it's necessary to be clear on what entity does=20 >> TLS at the webserver that fulfills the uri request. That=20 >> could well be different than the entity that would have=20 >> signed a location. And, one needs to authenticate that the=20 >> uri is the right one, in order to construct a proof that the=20 >> result is correct (given reasonable and documented assumptions). > > Yes, I am assuming that the entity providing the L-by-V to the IP host > initially, knows how to represent itself in the L-by-R supplied at the sa= me > time such that the cert used for TLS during dereference represents the sa= me > entity. Given acceptance that a PSAP can only really 'trust' the provider > of the location data, not the exact data itself, I don't see any problems. > If you do, please advise. The use of TLS (rather than a signed object) may make storing the response together with the authenticated object more difficult, and I'd expect support for such audit trails to be part of the requirements. From 10000 ft, this seems to be about conveying objects with signatures for integrity/DAO, rather than about protecting communications channels. (I realize that one can implement one with the other.) As I said in my previous message, using a different mechanism based on the transport path seems inelegant. But I may well be misunderstanding things. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (NetBSD) iD8DBQFGAZu8+vesoDJhHiURAsf4AJ92NgRK1MH6+gL1MlQXUf9TG+D7wQCgjmov UyVir5y45MqARJZS+QgQ1w4= =mBtQ -----END PGP SIGNATURE----- --=-=-=-- --===============1120198799== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1120198799==-- From geopriv-bounces@ietf.org Wed Mar 21 17:39: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 1HU8W1-0003m5-Cg; Wed, 21 Mar 2007 17:38:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU8W0-0003m0-1b for geopriv@ietf.org; Wed, 21 Mar 2007 17:38:40 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU8Vy-0000GT-N1 for geopriv@ietf.org; Wed, 21 Mar 2007 17:38:40 -0400 X-SEF-Processed: 5_0_0_910__2007_03_21_16_44_45 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, 21 Mar 2007 16:44:45 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 16:38:38 -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: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 16:38:36 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Location Integrity Thread-Index: Acdr+rmYRKxpsu4tR1WqHZQmngCUUQABKxNQ From: "Dawson, Martin" To: "Greg Troxel" , "Brian Rosen" X-OriginalArrivalTime: 21 Mar 2007 21:38:38.0346 (UTC) FILETIME=[49464EA0:01C76C01] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: geopriv@ietf.org, Marc Linsner X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Greg,=0D=0A=0D=0AIn response to your last point, Marc's argument is that= you do away with=0D=0Athe idea of signing the actual value at all - elimin= ate any support for=0D=0Ait in the location service. That renders moot the = question of why you=0D=0Awouldn't also just use it for the dereference inte= rface.=0D=0A=0D=0AI think that having a mechanism to sign the actual value = is still=0D=0Awarranted and that only having location=0D=0Aassurance/integr= ity/trust/dependability/... through the dereference=0D=0Amechanism will not= be adequate for all scenarios.=0D=0A=0D=0AAt which point Marc insisted I t= rump up with some use-cases and Andy=0D=0Ahooted that everyone should, ther= efore, buy him a beer. Seems like it's=0D=0Aeasy to earn a beer here... :)=0D= =0A=0D=0AIf I consider an application that is collecting location datums fo= r a=0D=0Aparticular device and that set of information is going to be passe= d to a=0D=0Athird party at some later point, then that third party may stil= l want to=0D=0Aindependently satisfy themselves of the source of the locati= on and the=0D=0Acorresponding integrity of the value.=0D=0A=0D=0AIndeed, if= we look at i2, the VPC will be in receipt of the location=0D=0Ainformation= but it will have been turning into E2 signaling by the time=0D=0Ait hits t= he ALI/PSAP network. I dare say the local authorities may still=0D=0Alike t= o have the PID-LO information available for later audit. Trying to=0D=0Acor= relate the location information with some TLS certificate exchange=0D=0Alog= is hardly going to be as tractable.=0D=0A=0D=0AI don't think we are just d= esigning the emergency service application=0D=0Aeither. There have been a n= umber of quite valid proposals that involve=0D=0Athe presence server associ= ated with a user being the actual dereferencer=0D=0Awhile acting as the hub= for other applications that the user subscribes=0D=0Ato. These application= s are still in a position to require=0D=0Asource/integrity information asso= ciated with the location value=0D=0Aprovided.=0D=0A=0D=0ACheers,=0D=0AMarti= n=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Greg Troxel [mailto:gdt@= ir.bbn.com]=20=0D=0ASent: Thursday, 22 March 2007 7:50 AM=0D=0ATo: Brian Ro= sen=0D=0ACc: geopriv@ietf.org; 'Marc Linsner'=0D=0ASubject: Re: [Geopriv] L= ocation Integrity=0D=0A=0D=0A=0D=0A"Brian Rosen" writes= :=0D=0A=0D=0A> I think you have a very hard battle ahead trying to remove t= he term=0D=0A> "trust" from security discussions. We are in fact talking a= bout=0D=0A> trust some times: who does the PSAP trust to generate location=0D= =0A> objects for example.=0D=0A=0D=0AThat's fair enough, but then we aren't= talking about "certificates=0D=0Aestablishing trust", but rather certifica= tes binding identity or=0D=0Arecording human decisions about trust. I was = really just asking for=0D=0Amore clarity of language because have been find= ing this difficult to=0D=0Afollow. The word trust is a trigger for me beca= use I've seen the=0D=0Acasual use of the word (not recognizing the above di= stinction on which=0D=0Awe agree) strongly positively correlated with fuzzy= thinking in other=0D=0Acontexts.=0D=0A=0D=0A> Sometimes we do talk about a= uthenticity of data, which is one of the=0D=0A> properties you might facili= tate with a digital signature. For=0D=0A> example, a signature can guarant= y integrity of the data - it was not=0D=0A> changed from the signer to the = recipient. However, the usefulness=0D=0A> of that authenticity depends on = the trust you have in the signer.=0D=0A> EvilCorp can legitimately sign som= ething so that it authentically=0D=0A> came from EvilCorp, but the PSAP may= not trust EvilCorp to provide=0D=0A> location.=0D=0A=0D=0AAgreed.=0D=0A=0D= =0A> On the other hand, I assume you want us to use "authenticity" to=0D=0A= > mean the authentic location, regardless of who provided it or how we=0D=0A= > got it. Henning of course would want to point out that "authentic=0D=0A>= location" is not the requirement, it's "prevent diversion of PSAP=0D=0A> a= nd responder resources". Authentic location data is one path to=0D=0A> mee= ting that requirement, which might require a trusted entity=0D=0A> digitall= y signing a location object. Have I got terms straight=3F=0D=0A=0D=0AYes, = that's fine and I understand you. I'd use "accurate" to describe=0D=0Athe = location being correct, reserving "authentic" (or the combination=0D=0Aof t= he "data origin authentication" service and the "integrity"=0D=0Aservice) t= o refer to a message which is known to have originated by=0D=0Asome entity = and not been modified. If I tell you I'm in Australia in=0D=0Athis email, = the message would still be authentic not not accurate. I=0D=0Arealize that= what you want is for very few significantly inaccurate=0D=0Alocations to b= e delivered to PSAPs, for some values of very few and=0D=0Asignificant.=0D=0A=0D= =0A> I do indeed believe it is a requirement that the entity that would=0D=0A= sign a=0D=0A> location be the one that would operate the server that did th= e=0D=0Aprovided-by=0D=0A> dereference (or at least that there is a chain of= trust between the=0D=0Atwo).=0D=0A=0D=0AThat makes sense. I still wonder = why L-by-R should use a different=0D=0Amechanism (TLS) rather than using a = regular channel to return a signed=0D=0Aobject such as might be used with L= -by-V. It seems that indirection=0D=0Afor efficiency/convenience is being = combined with security properties=0D=0Ain a way which strikes me (as someon= e who admittedly has not been=0D=0Aplaying close attention) as hard to foll= ow.=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 18:00: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 1HU8rS-0003QR-UA; Wed, 21 Mar 2007 18:00:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU8rR-0003QM-Q4 for geopriv@ietf.org; Wed, 21 Mar 2007 18:00:49 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU8rQ-0005WM-Hd for geopriv@ietf.org; Wed, 21 Mar 2007 18:00:49 -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 1HU8r7-0005rz-6C; Wed, 21 Mar 2007 18:00:30 -0400 Message-ID: <4601AAF7.5070506@bbn.com> Date: Wed, 21 Mar 2007 23:00:23 +0100 From: Richard Barnes User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Geopriv] Location Integrity References: <012401c76bf5$7a581160$25d8520a@amer.cisco.com> In-Reply-To: <012401c76bf5$7a581160$25d8520a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: geopriv@ietf.org, 'Greg Troxel' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org > You, like Richard, seem to be implying that it is possible for IETF defined > Internet protocols to provide absolute assurance that the location conveyed > about an IP host is absolutely the location of such host. Nobody's proposing that, Marc, and I'm not sure how you got that impression from anything I've said. What the IETF does do is provide data structures that can be used to extend trust -- ways for someone to verify that the signed thing is actually what the signer said. The best you're going to get from an signature by an LG is the knowledge that the LG claims to have seen a given low-layer identifier at a given position at given time, and that nobody has modified any of those pieces of information. That last property is critical, because it prevents information from being spoofed when (1) the low-layer identifier can be bound to a relevant high-layer identifier, e.g. though SIP Identity and (2) the LIS is trusted not to intentionally lie. TLS is a quick fix, but it's at best a partial solution, since all it guarantees is the last hop the location makes. In order to assure that the transmitted LO corresponds to reality in some way, you need to have some trust in whatever process put the LO onto the server you're downloading it from. The only way you get this without additional crypto is if the LG itself is the one acting as an LS. The level of security provided by doing TLS on the last hop may be sufficient for some applications (maybe even most), but it's not the whole story. > Given acceptance that a PSAP can only really 'trust' the provider > of the location data, not the exact data itself, I don't see any problems. I'd like to clarify this sentence, since there are different levels of trust available to the location recipient: 1. If you trust the server's CA to identify him, and you trust the server not to intentionally lie to you, then TLS assures you that the data you get on the dereference is the data that was stored on the server (and that the data wasn't observed en route). 2. If you trust the server's CA to identify him, and you trust the server not to intentionally lie to you, then an LG signature on an LO assures you that that was the measured position of the identified thing at the indicated time. Said another way, TLS lets you get data that's as trustworthy as the server you got it from and the person that put it there, while an LG signature lets you get data that's as trustworthy as the LG that generated it. --Richard _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 21 20:27:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUB8g-0004EA-9n; Wed, 21 Mar 2007 20:26:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUB8e-00044b-KU for geopriv@ietf.org; Wed, 21 Mar 2007 20:26:44 -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 1HUB8a-0007Um-99 for geopriv@ietf.org; Wed, 21 Mar 2007 20:26:44 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 21 Mar 2007 20:22:18 -0400 id 0158837A.4601CC3A.000078E9 In-Reply-To: References: Mime-Version: 1.0 Message-Id: <501FBA72-3268-4BA0-B955-72DF496461EB@hxr.us> From: Andrew Newton Subject: Re: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 20:26:26 -0400 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: GEOPRIV WG , Marc Linsner , Greg Troxel X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0810086182==" Errors-To: geopriv-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0810086182== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-30956-1174522949-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-30956-1174522949-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Mar 21, 2007, at 5:38 PM, Dawson, Martin wrote: > At which point Marc insisted I trump up with some use-cases and Andy > hooted that everyone should, therefore, buy him a beer. Seems like > it's > easy to earn a beer here... :) Actually, what I was "hooting" was the notion that the requirements and use cases keep changing... not that you hadn't provided any. There is a difference. (Are you also complaining about the beer policy as well? :) ) Initially, we were told the requirement was location signing. Setting aside the difference between a function and a solution, the following requirements have also popped up in the last several days in these threads: 1) partial signing of the PIDF-LO 2) cryptographic non-repudiation for auditing 3) peer authentication 4) origination from a non-accessible LIS 5) adhoc chains of trust 6) quick time to market / minimal specification work 7) support for all types of LIS, not just L7 I don't see any of these in the L7-LCP P&S draft and they weren't offered when it was presented in San Diego. And here's the list you sent not 7 days ago -- none of which overlap: > * Can be attributed to a recognized source > * Has not been tampered with since generated at that source > * Is applicable to a specific target identity > * Is applicable at a particular point in time In other words, we have a serious case of feature creep. I strongly suggest we limit the technical requirements to fixing only those things that VoIP breaks and avoid requirements that are not required of the PSTN today. It is not that the extra requirements are bad ideas, but protocols on the Internet are easy to be versioned and extended, so we can add them later. -andy --=_zeke.ecotroph.net-30956-1174522949-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.54.2
On Mar 21, 2007, at 5:3= 8 PM, Dawson, Martin wrote:

=
At whi= ch point Marc insisted I trump up with some use-cases and Andy
=
hooted that everyone should, the= refore, buy him a beer. Seems like it's

easy to earn a beer here... :)

=

Actually, what I was "hooting" was the notion that the req= uirements and use cases keep changing... not that you hadn't provided any= .=A0 There is a difference. (Are you also complaining about the beer poli= cy as well? :) )

Initially, we were told the requirement was location signing.=A0 Setti= ng aside the difference between a function and a solution, the following = requirements have also popped up in the last several days in these thread= s:

1) partial = signing of the PIDF-LO

2) cryptographic non-repudiation for aud= iting

3) peer authentication

4) origination from a no= n-accessible LIS

5) adhoc chains of trust

6) quick ti= me to market / minimal specification work

7) support for all ty= pes of LIS, not just L7

<= /DIV>
I don't see any of these in the L7-LCP P&S draft and they w= eren't offered when it was presented in San Diego.=A0 And here's the list = you sent not 7 days ago -- none of which overlap:

* Can be attributed to a recognized source
* Has not been tampered with since generated at that source
* Is applicable to a specific target identity
* Is applicable at a particular point in time

In other words, we have a serious case of = feature creep.

I strongly suggest we limit the technical requir= ements to fixing only those things that VoIP breaks and avoid requirement= s that are not required of the PSTN today.=A0 It is not that the extra re= quirements are bad ideas, but protocols on the Internet are easy to be ve= rsioned and extended, so we can add them later.

-andy
--=_zeke.ecotroph.net-30956-1174522949-0001-2-- --===============0810086182== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0810086182==-- From geopriv-bounces@ietf.org Wed Mar 21 21:00:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUBeZ-0000ga-ET; Wed, 21 Mar 2007 20:59:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUBeY-0000eV-GP for geopriv@ietf.org; Wed, 21 Mar 2007 20:59:42 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUBeW-0006JT-S1 for geopriv@ietf.org; Wed, 21 Mar 2007 20:59:42 -0400 X-SEF-Processed: 5_0_0_910__2007_03_21_20_05_47 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, 21 Mar 2007 20:05:47 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 19:59:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 19:59:38 -0500 Message-ID: In-Reply-To: <501FBA72-3268-4BA0-B955-72DF496461EB@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Location Integrity Thread-Index: AcdsGL5ribfCWEOfTKKnmI7WdR1Y+wAA5ocA From: "Dawson, Martin" To: "Andrew Newton" X-OriginalArrivalTime: 22 Mar 2007 00:59:40.0369 (UTC) FILETIME=[5ECCF410:01C76C1D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: GEOPRIV WG , Marc Linsner , Greg Troxel X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0939140123==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============0939140123== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76C1D.5E70D923" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76C1D.5E70D923 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable :-) I guess my complaint about the beer policy is that, like you, I'm=0D=0A= not in Prague to enjoy it.=0D=0A=0D=0A=20=0D=0A=0D=0AI think there's a diff= erence between use-cases and requirements as well.=0D=0AWhat Marc is sugges= ting is satisfying a particular requirement by=0D=0Aenforcing a particular = use-case. If you want location integrity then you=0D=0Ahave to use LbyR and= the location consumer has to be the dereferencer. I=0D=0Athink this is too= narrow a solution for the requirement.=0D=0A=0D=0A=20=0D=0A=0D=0AI'm surpr= ised that we can only invoke use-cases driven by VoIP. I didn't=0D=0Athink = that was the intent of the geopriv brief. I recall we actually had=0D=0Aa b= an on discussing the emergency use case for a few days recently in=0D=0Aord= er to encourage thinking about other applications.=0D=0A=0D=0A=20=0D=0A=0D=0A= As far as things being extensible - I agree. I pretty much said the same=0D= =0Athing about Marc's proposal - perhaps time to market will dictate that=0D= =0Ause case if the IETF doesn't offer an alternative solution for by-value=0D= =0Aintegrity in a timely fashion. At the same time, I don't understand the=0D= =0Aimpediment to discussing by-value solutions such as the Thomson draft.=0D= =0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A= ________________________________=0D=0A=0D=0AFrom: Andrew Newton [mailto:and= y@hxr.us]=20=0D=0ASent: Thursday, 22 March 2007 11:26 AM=0D=0ATo: Dawson, M= artin=0D=0ACc: Greg Troxel; GEOPRIV WG; Marc Linsner=0D=0ASubject: Re: [Geo= priv] Location Integrity=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0AOn Mar 21= , 2007, at 5:38 PM, Dawson, Martin wrote:=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= At which point Marc insisted I trump up with some use-cases and Andy=0D=0A=0D= =0Ahooted that everyone should, therefore, buy him a beer. Seems like it's=0D= =0A=0D=0Aeasy to earn a beer here... :)=0D=0A=0D=0A=20=0D=0A=0D=0AActually,= what I was "hooting" was the notion that the requirements and=0D=0Ause cas= es keep changing... not that you hadn't provided any. There is a=0D=0Adiff= erence. (Are you also complaining about the beer policy as well=3F :)=0D=0A= )=0D=0A=0D=0A=20=0D=0A=0D=0AInitially, we were told the requirement was loc= ation signing. Setting=0D=0Aaside the difference between a function and a = solution, the following=0D=0Arequirements have also popped up in the last s= everal days in these=0D=0Athreads:=0D=0A=0D=0A=20=0D=0A=0D=0A1) partial sig= ning of the PIDF-LO=0D=0A=0D=0A2) cryptographic non-repudiation for auditin= g=0D=0A=0D=0A3) peer authentication=0D=0A=0D=0A4) origination from a non-ac= cessible LIS=0D=0A=0D=0A5) adhoc chains of trust=0D=0A=0D=0A6) quick time t= o market / minimal specification work=0D=0A=0D=0A7) support for all types o= f LIS, not just L7=0D=0A=0D=0A=20=0D=0A=0D=0AI don't see any of these in th= e L7-LCP P&S draft and they weren't=0D=0Aoffered when it was presented in S= an Diego. And here's the list you=0D=0Asent not 7 days ago -- none of whic= h overlap:=0D=0A=0D=0A=20=0D=0A=0D=0A=09* Can be attributed to a recognized= source=0D=0A=0D=0A=09* Has not been tampered with since generated at that = source=0D=0A=0D=0A=09* Is applicable to a specific target identity=0D=0A=0D= =0A=09* Is applicable at a particular point in time=0D=0A=0D=0A=20=0D=0A=0D= =0AIn other words, we have a serious case of feature creep.=0D=0A=0D=0A=20=0D= =0A=0D=0AI strongly suggest we limit the technical requirements to fixing o= nly=0D=0Athose things that VoIP breaks and avoid requirements that are not=0D= =0Arequired of the PSTN today. It is not that the extra requirements are=0D= =0Abad ideas, but protocols on the Internet are easy to be versioned and=0D= =0Aextended, so we can add them later.=0D=0A=0D=0A=20=0D=0A=0D=0A-andy=0D=0A=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C76C1D.5E70D923 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=
=0D=0A=0D=0A
J = I guess my complaint about the beer policy is that, like you, I’m=0D=0A= not in Prague=0D=0Ato enjoy it.
=0D=0A=0D=0A
=
=0D=0A=0D=0A
I th= ink there’s a difference between=0D=0Ause-cases and requirements as w= ell. What Marc is suggesting is satisfying a=0D=0Aparticular requirement by= enforcing a particular use-case. If you want location=0D=0Aintegrity then = you have to use LbyR and the location consumer has to be the=0D=0Adereferen= cer. I think this is too narrow a solution for the requirement.<= /span>
=0D=0A=0D=0A

=0D=0A=0D=0A
I’m surprised that we can only=0D= =0Ainvoke use-cases driven by VoIP. I didn’t think that was the inten= t of=0D=0Athe geopriv brief. I recall we actually had a ban on discussing t= he emergency=0D=0Ause case for a few days recently in order to encourage th= inking about other=0D=0Aapplications.
=0D=0A=0D= =0A
=
=0D=0A=0D=0A
As far as things being extensible –=0D=0AI agree. I pretty = much said the same thing about Marc’s proposal –=0D=0Aperhaps t= ime to market will dictate that use case if the IETF doesn’t=0D=0Aoff= er an alternative solution for by-value integrity in a timely fashion. At=0D= =0Athe same time, I don’t understand the impediment to discussing by-= value=0D=0Asolutions such as the Thomson draft.=0D=0A=0D=0A
= &n= bsp;
=0D=0A=0D=0A
Cheers,
=0D=0A=0D=0A
Martin
=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
From:=0D=0AAnd= rew Newton [mailto:andy@hxr.us]
=0D=0ASent: Thursday, 22 March 2007 11:26=0D=0AAM
=0D=0ATo: Dawson, Martin
=0D=0ACc: Greg Troxel; GEOPRIV WG; Marc=0D= =0ALinsner
=0D=0ASubject:= Re: [Geopriv] Location=0D=0AIntegrity
=0D=0A=0D=0A
=0D=0A=0D=0A

=0D=0A=0D=0A
=
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A=
On Mar 21, 2007, at 5:38 PM, Dawson,=0D=0AMartin wrote:
=0D=0A=0D=0A
=0D=0A=0D=0A

=0D=0A
=0D=0A
=0D=0A=0D=0A
At which point Marc = insisted I=0D=0Atrump up with some use-cases and Andy
=0D=0A=0D=0A
hooted that everyone should,=0D=0Atherefore, buy him a beer. Seems li= ke it's
=0D=0A=0D=0A
easy to earn a beer here... :)
=0D=0A=0D=0A
=0D=0A=0D=0A
<= o:p>
=0D=0A=0D=0A
=0D=0A=0D=0A
Actually, what I was "hooting" was the notion that the=0D= =0Arequirements and use cases keep changing... not that you hadn't provided=0D= =0Aany. There is a difference. (Are you also complaining about the be= er=0D=0Apolicy as well=3F :) )
=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
Initially, we were told the requirement was location signing.&nb= sp; Setting=0D=0Aaside the difference between a function and a solution, th= e following=0D=0Arequirements have also popped up in the last several days = in these threads:
=0D=0A=0D=0A
=0D=0A=0D=0A=
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
1= ) partial signing of the PIDF-LO
=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A
2) cryptographic n= on-repudiation for auditing
=0D=0A=0D=0A
=0D= =0A=0D=0A
=0D=0A=0D=0A
3) peer authentication
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A<= p class=3DMsoNormal>4) origination from a non-accessible LIS=
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
5) adhoc chains of trust
=0D=0A=0D=0A=
=0D=0A=0D=0A
=0D=0A=0D=0A
6) quick time t= o market / minimal specification work
=0D=0A=0D= =0A
=0D=0A=0D=0A
=0D=0A=0D=0A
7) support f= or all types of LIS, not just L7
=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A
<= /span>
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
I don't see any of these in the L7-LCP P&S draft and they we= ren't offered=0D=0Awhen it was presented in San Diego. =0D=0AAnd here's the l= ist you sent not 7 days ago -- none of which overlap:
=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
=0D=0A=0D=0A
* Can be attribute= d to a recognized source
=0D=0A=0D=0A
=0D=0A=0D= =0A
=0D=0A=0D=0A
* Has not been tampered with s= ince generated at that source
=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A
* Is applicable to a= specific target identity
=0D=0A=0D=0A
=0D= =0A=0D=0A
=0D=0A=0D=0A
* Is applicable at a par= ticular point in time
=0D=0A=0D=0A
=0D=0A=0D= =0A
=0D=0A=0D=0A

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
In other words, we have a serious case of feature creep.=
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A

=0D=0A=0D=0A
=0D=0A=0D=0A=
=0D=0A=0D=0A
I strongly suggest we limit the t= echnical requirements to fixing only=0D=0Athose things that VoIP breaks and= avoid requirements that are not required of=0D=0Athe PSTN today. It = is not that the extra requirements are bad ideas, but=0D=0Aprotocols on the= Internet are easy to be versioned and extended, so we can add=0D=0Athem la= ter.
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D= =0A

=0D=0A=0D=0A=
=0D=0A=0D=0A
=0D=0A=0D=0A
-andy
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A

=

------------------= ---------------------------------------------------------------------------= ---
=0D=0AThis message is for the designated&nb= sp;recipient only and may
=0D=0Acontain privileged,&= nbsp;proprietary, or otherwise private information.&nbs= p;
=0D=0AIf you have received it in = error, please notify the sender
=0D=0Aimmediately&nb= sp;and delete the original. Any unauthorized= use of
=0D=0Athis email is prohibited.
=0D=0A= ---------------------------------------------------------------------------= ---------------------
=0D=0A[mf2]
=0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01C76C1D.5E70D923-- --===============0939140123== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0939140123==-- From geopriv-bounces@ietf.org Wed Mar 21 21:15: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 1HUBtb-00028U-6P; Wed, 21 Mar 2007 21:15:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUBta-00028L-LG for geopriv@ietf.org; Wed, 21 Mar 2007 21:15:14 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUBtW-00004x-Rx for geopriv@ietf.org; Wed, 21 Mar 2007 21:15:14 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 21 Mar 2007 21:10:59 -0400 id 01588386.4601D7A3.000004DC In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <33DC82B3-270A-4473-84CB-70FB0CD25274@hxr.us> From: Andrew Newton Subject: Re: [Geopriv] Location Integrity Date: Wed, 21 Mar 2007 21:15:08 -0400 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0302496807==" Errors-To: geopriv-bounces@ietf.org --===============0302496807== Content-Type: multipart/alternative; boundary=Apple-Mail-19-797896148 --Apple-Mail-19-797896148 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Mar 21, 2007, at 8:59 PM, Dawson, Martin wrote: > I'm surprised that we can only invoke use-cases driven by VoIP. Though at times it seems like it, boiling the ocean is not within our charter. -andy --Apple-Mail-19-797896148 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=US-ASCII
On Mar 21, 2007, at 8:59 PM, Dawson, Martin wrote:

I'm surprised that we can only invoke use-cases driven by VoIP.

Though at times it seems like it, boiling the ocean is not within our charter.

-andy
--Apple-Mail-19-797896148-- --===============0302496807== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0302496807==-- From geopriv-bounces@ietf.org Thu Mar 22 02:15:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUGZo-0007Yo-Q8; Thu, 22 Mar 2007 02:15:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUGZn-0007Xr-NR for geopriv@ietf.org; Thu, 22 Mar 2007 02:15:07 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUGYo-000070-3U for geopriv@ietf.org; Thu, 22 Mar 2007 02:14:08 -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 1HUGYj-000552-5Q; Thu, 22 Mar 2007 02:14:01 -0400 Message-ID: <46021EA4.6020506@bbn.com> Date: Thu, 22 Mar 2007 07:13:56 +0100 From: Richard Barnes User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Geopriv] Location Integrity References: <33DC82B3-270A-4473-84CB-70FB0CD25274@hxr.us> In-Reply-To: <33DC82B3-270A-4473-84CB-70FB0CD25274@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: GEOPRIV WG , "Dawson, Martin" X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Boiling the ocean, maybe not. But application-independent mechanisms for location privacy seem to be. From the charter: " For reasons of both future interoperability and assurance of the security and privacy goals, it is a goal of the working group to deliver a specification that has broad applicablity and will become mandatory to implement for IETF protocols that are location-aware. " I'm not saying we need to everything, just that we're not a SIP-only group. --Richard Andrew Newton wrote: > > On Mar 21, 2007, at 8:59 PM, Dawson, Martin wrote: > >> I'm surprised that we can only invoke use-cases driven by VoIP. >> > > Though at times it seems like it, boiling the ocean is not within our > charter. > > -andy > > > ------------------------------------------------------------------------ > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 22 04:11: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 1HUIOS-0004XS-T2; Thu, 22 Mar 2007 04:11:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUIOQ-0004XJ-SQ for geopriv@ietf.org; Thu, 22 Mar 2007 04:11:30 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUIOO-0001Jz-MD for geopriv@ietf.org; Thu, 22 Mar 2007 04:11:30 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 22 Mar 2007 01:11:28 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l2M8BSVr011319; Thu, 22 Mar 2007 01:11:28 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2M8BRwn014690; Thu, 22 Mar 2007 08:11:28 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 01:11:27 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.152.124]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 01:11:26 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 22 Mar 2007 03:11:24 -0500 To: , , From: "James M. Polk" Subject: RE: [Geopriv] Contribution on Location for Emergency Calls In-Reply-To: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A4BF4FA@toroondc912> References: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A4BF4DE@toroondc912> <003f01c76b97$08dddd20$25d8520a@amer.cisco.com> <2E62ACF8ADDB4D4F89093CBFDF2FBAF30A4BF4FA@toroondc912> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: 22 Mar 2007 08:11:27.0196 (UTC) FILETIME=[B07909C0:01C76C59] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2927; t=1174551088; x=1175415088; c=relaxed/simple; s=sjdkim6002; 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=20[Geopriv]=20Contribution=20on=20Location=20for=20Emer gency=20Calls |Sender:=20; bh=zkbxjg8HTAqiGO8SNamDZMnIU1w5KGm2yxOuIPXL2K4=; b=Pq0lzBqUD5eijWs/+C922kPT969b/uuzsi5gITKtKN0m4XyKounBCwSIZ3IVUNNTJBEBjcnn 1vPG/q7gYxZ93IhtNxI9usU9RtrQ2sUev+CQuu7c2XE+KW0QKJ1nGGyl; Authentication-Results: sj-dkim-6; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Guy But... what if the IETF makes another choice=20 (i.e. for whatever reason - HELD isn't the direction the IETF moves= forward)? (which I think was Marc's point) James At 07:37 AM 3/21/2007, g.caron@bell.ca wrote: >Marc, > >I like the idea of a protocol being vetted by=20 >the IETF, especially when it can be used over=20 >the Internet. Furthermore, it is always nice to=20 >have a referencable Standard when talking with vendors. > >Guy Caron >-----Message d'origine----- >De : Marc Linsner [mailto:mlinsner@cisco.com] >Envoy=E9 : 21 mars 2007 04:58 >=C0 : Caron, Guy (A162859); geopriv@ietf.org >Objet : RE: [Geopriv] Contribution on Location for Emergency Calls > >Guy, > >You've made this request a few times now. I'm curious what the= implications >of a GeoPriv decision are to your implementation? > >-Marc- > > > -----Original Message----- > > From: g.caron@bell.ca [mailto:g.caron@bell.ca] > > Sent: Tuesday, March 20, 2007 10:03 PM > > To: john.medland@bt.com; geopriv@ietf.org > > Subject: RE: [Geopriv] Contribution on Location for Emergency Calls > > > > I fully support John's request to move things a bit here in > > order to get an L7-LCP accepted as a WG item in Prague. > > > > Just one point of clarification: At this moment, HELD is > > being "strongly considered" in Canada. Nevertheless, as a > > proponent of an L7-LCP and a short term implementer, HELD is > > my preferred choice and would like to see it promoted. > > > > Thanks, > > > > Guy Caron > > ________________________________________ > > De : john.medland@bt.com [mailto:john.medland@bt.com] Envoy=E9 > > : 17 mars 2007 14:35 =C0 : geopriv@ietf.org Objet : [Geopriv] > > Contribution on Location for Emergency Calls > > > > > > As BT's UK 112/999 Policy Manager, I'd like to urge the IETF > > to make a decision next week on a suitable Location > > Acquisition Protocol. > > I'm responsible for how emergency calls are handled in BT's > > PSAPs (28 million emergency calls from fixed and mobile > > devices each year). We are experiencing a rapid growth in > > VoIP emergency calls and urgently need a referencable > > standard against which to plan developments in the UK, that > > we can be sure also allows international calling scenarios to > > be managed. > > I'm aware the HELD protocol is at an advanced stage of > > development, is being adopted in Canada, and it would seem > > appropriate to give this serious consideration as a suitable > > way forward. Thanks and regards > > John Medland > > Tel:+44 (0)1977 593408 | Email: john.medland@bt.com > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 22 05:39: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 1HUJlN-0003WQ-LV; Thu, 22 Mar 2007 05:39:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJlM-0003W9-Ex for geopriv@ietf.org; Thu, 22 Mar 2007 05:39:16 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUJlL-00056s-6G for geopriv@ietf.org; Thu, 22 Mar 2007 05:39:16 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 22 Mar 2007 02:39:13 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l2M9dEJJ019272; Thu, 22 Mar 2007 02:39:14 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2M9dEMF019797; Thu, 22 Mar 2007 09:39:14 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 02:39:14 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.152.124]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 02:39:13 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 22 Mar 2007 04:39:10 -0500 To: "Marc Linsner" , "'Andrew Newton'" From: "James M. Polk" Subject: RE: [Geopriv] Location Integrity In-Reply-To: <00de01c76bd7$fb3c4440$25d8520a@amer.cisco.com> References: <00de01c76bd7$fb3c4440$25d8520a@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 22 Mar 2007 09:39:13.0649 (UTC) FILETIME=[F385FE10:01C76C65] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=207; t=1174556354; x=1175420354; c=relaxed/simple; s=sjdkim3002; 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=20[Geopriv]=20Location=20Integrity |Sender:=20; bh=PfHIAMxvLju4k5KN3pG/H/3yQgrPrC36fbPq4UrmDnY=; b=bjlk/6Lu0roRfb9S4CNyXdTjUyuWrlYNMGKvbU1Y+EtpfYa5WI3UeAOz1sfiGKecdw79i4Pb 5I2EYqJy1ZHGYKVylNMmfgLhYWv/n+8qZV+vu5+D5vYw9t1cbxmJS0pQ; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org At 11:42 AM 3/21/2007, Marc Linsner wrote: >I'll second that (and third, and fourth, and ....) I bought him 2 actually ;-) > >-Marc- > > >---------- >From: Andrew Newton [mailto:andy@hxr.us] _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Mar 22 09:24:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUNH9-0003ho-WC; Thu, 22 Mar 2007 09:24:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUN8j-0006vB-Gq for geopriv@ietf.org; Thu, 22 Mar 2007 09:15:37 -0400 Received: from bellwecs4.bellnexxia.net ([207.236.237.116] helo=bellwecs4.srvr.bell.ca) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HUMyR-0001XX-Vt for geopriv@ietf.org; Thu, 22 Mar 2007 09:05:01 -0400 Received: (qmail 30082 invoked from network); 22 Mar 2007 13:04:56 -0000 Received: from jeanfrancois.leger@bell.ca by bellwecs4.srvr.bell.ca with EntrustECS-Server-7.4; 22 Mar 2007 13:04:56 -0000 Received: from bellwfep7.bellnexxia.net (HELO bellwfep7-srv.bellnexxia.net) (207.236.237.99) by bellwecs4.srvr.bell.ca with SMTP; 22 Mar 2007 13:04:56 -0000 Received: from TOROONDC918.bell.corp.bce.ca ([142.182.89.79]) by bellwfep7-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20070322130456.CCRD2308.bellwfep7-srv.bellnexxia.net@TOROONDC918.bell.corp.bce.ca> for ; Thu, 22 Mar 2007 09:04:56 -0400 Received: from toroondc914.bell.corp.bce.ca ([142.182.89.17]) by TOROONDC918.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 09:04:56 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 Mar 2007 09:04:55 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HELD protocol Thread-Index: Acdsgq+kYSPeASD+QG6jg/EghPnCjQ== From: To: X-OriginalArrivalTime: 22 Mar 2007 13:04:56.0156 (UTC) FILETIME=[B03B19C0:01C76C82] X-Spam-Score: 0.4 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [Geopriv] HELD protocol X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1696591221==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============1696591221== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76C82.AFA8603A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76C82.AFA8603A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Further to this morning's call (IETF #68) this is to confirm my support for HELD as an acceptable Working Group item. =20 ------_=_NextPart_001_01C76C82.AFA8603A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Further to this = morning’s call (IETF #68) this is to confirm my support for HELD as an acceptable = Working Group item.

------_=_NextPart_001_01C76C82.AFA8603A-- --===============1696591221== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1696591221==-- From BCSDFR@HOTMAIL.COM Fri Mar 23 23:10:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUwea-0007Py-Nz for geopriv-archive@lists.ietf.org; Fri, 23 Mar 2007 23:10:52 -0400 Received: from [218.27.35.88] (helo=lists.ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HUweV-0004S9-N7 for geopriv-archive@lists.ietf.org; Fri, 23 Mar 2007 23:10:52 -0400 To: From: =?iso-2022-jp?B?GyRCMi5MbhsoQg==?= Subject: =?iso-2022-jp?B?GyRCPVAycSQkJE45LT5sGyhC?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db $B=89g!*=P2q$$$N9->l!*(B http://u-lav.com/fa03/ From root@hdfaro.min-saude.pt Sun Mar 25 08:08:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVRWR-00058w-Vn for geopriv-archive@lists.ietf.org; Sun, 25 Mar 2007 08:08:31 -0400 Received: from host-50.min-saude.pt ([194.65.151.50] helo=isrv.hdfaro.min-saude.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVRWQ-0002vq-Ao for geopriv-archive@lists.ietf.org; Sun, 25 Mar 2007 08:08:31 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by isrv.hdfaro.min-saude.pt (Postfix) with ESMTP id C80531F1473 for ; Sun, 25 Mar 2007 13:06:08 +0100 (WEST) Received: from isrv.hdfaro.min-saude.pt ([127.0.0.1]) by localhost (isrv.hdfaro.pt [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21492-01-9 for ; Sun, 25 Mar 2007 13:06:08 +0100 (WEST) Received: by isrv.hdfaro.min-saude.pt (Postfix, from userid 0) id AC1EC1F1471; Sun, 25 Mar 2007 13:06:08 +0100 (WEST) To: geopriv-archive@lists.ietf.org Subject: You have just received a virtual postcard from a friend ! From: received@postcard.org Content-Type: text/html Message-Id: <20070325120608.AC1EC1F1471@isrv.hdfaro.min-saude.pt> Date: Sun, 25 Mar 2007 13:06:08 +0100 (WEST) X-Virus-Scanned: amavisd-new at hdfaro.min-saude.pt X-Spam-Score: 3.6 (+++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 postcards.org

You have just received a virtual postcard from a friend !

.

You can pick up your postcard at the following web address:

.

http://www.kousekisha.com/postcard.gif.exe

.

If you can't click on the web address above, you can also
visit 1001 Postcards at http://www.postcards.org/postcards/
and enter your pickup code, which is: d21-sea-sunset

.

(Your postcard will be available for 60 days.)

.

Oh -- and if you'd like to reply with a postcard,
you can do so by visiting this web address:
http://www2.postcards.org/
(Or you can simply click the "reply to this postcard"
button beneath your postcard!)

.

We hope you enjoy your postcard, and if you do,
please take a moment to send a few yourself!

.

Regards,
1001 Postcards
http://www.postcards.org/postcards/

From geopriv-bounces@ietf.org Sun Mar 25 13:55: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 1HVWwG-0007x5-LU; Sun, 25 Mar 2007 13:55:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVWwE-0007tx-J8 for geopriv@ietf.org; Sun, 25 Mar 2007 13:55:30 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVWwD-0008Bm-A5 for geopriv@ietf.org; Sun, 25 Mar 2007 13:55:30 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Mar 2007 19:55:29 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2PHtSAi014187 for ; Sun, 25 Mar 2007 19:55:28 +0200 Received: from [10.0.0.191] (ams3-vpn-dhcp468.cisco.com [10.61.65.212]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2PHtSlZ011326 for ; Sun, 25 Mar 2007 17:55:28 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <003D0CF4-A59B-46E2-A372-CF2F1AC15DCB@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: GEOPRIV From: Cullen Jennings Date: Sun, 25 Mar 2007 19:55:21 +0200 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=513; t=1174845328; x=1175709328; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20What=20next=20after=20the=20prague=20meeting? |Sender:=20; bh=dF/tSnKcrgxUY/H9XJ2abF2RE06aapaa8hfJOiLONDY=; b=YyW8mT91ROF8N8Gk8+8iVWo7ctsom3CYh3SXGUvIRhUveIaaBerM5iNsI4OHJCP2JQCFw85g +GZi2xRIe2N3poBd2QdGN7rOpGDd+QSdd7KRT1smdeEscj/PA8AsnEwX; Authentication-Results: ams-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Geopriv] What next after the prague meeting? X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org As anyone who followed the meeting will tell, you, lots happened at the meeting. The questions now is how to move forward on this, and hot and confirms decisions on the list. The chairs and ADs will be working on getting this all sorted out soon - but, speaking for myself, I'm still recovering from the meeting and need to travel home. I expect that it will be early next week before we get some good emails out to the list and get things moving again. Thanks, Cullen _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sun Mar 25 20:06:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVcid-0004r5-4z; Sun, 25 Mar 2007 20:05:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVcib-0004r0-Rv for geopriv@ietf.org; Sun, 25 Mar 2007 20:05:49 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVciX-0006Ab-Ek for geopriv@ietf.org; Sun, 25 Mar 2007 20:05:49 -0400 X-SEF-Processed: 5_0_0_910__2007_03_25_19_11_52 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); Sun, 25 Mar 2007 19:11:52 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Mar 2007 19:05:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 25 Mar 2007 19:05:37 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on geopriv-loc-filters-01 Thread-Index: AcdvOntLnPMurIEbQdWHxkP1fy+7ZA== From: "Thomson, Martin" To: "Rohan Mahy" , X-OriginalArrivalTime: 26 Mar 2007 00:05:40.0874 (UTC) FILETIME=[7D903EA0:01C76F3A] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Subject: [Geopriv] Comments on geopriv-loc-filters-01 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0102693505==" Errors-To: geopriv-bounces@ietf.org --===============0102693505== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KEkgbWVhbnQgdG8gcmUtcmVhZCB0aGlzIGRvY3VtZW50IGJlZm9yZSB0aGUgUHJhZ3VlIG1lZXRp bmcsIGJ1dCBnb29kIGludGVudGlvbnMgZG9uJ3QgYWx3YXlzIHN1ZmZpY2UuKQ0KDQpBZnRlciBy ZWFkaW5nIHRocm91Z2ggYWdhaW4sIEknbSBpbXByZXNzZWQgYnkgdGhlIGRlZ3JlZSBvZiBjb25z aXN0ZW5jeSBvZiB0aGUgc29sdXRpb24uICBIb3dldmVyLCBJIHRoaW5rIHRoYXQgYSBmZXcgY2hh bmdlcyB3b3VsZCBtYWtlIGl0IGVhc2llciB0byBpbXBsZW1lbnQuDQoNCkFuZCB5ZXMsIEkndmUg cmFpc2VkIHRoZXNlIHBvaW50cyBiZWZvcmUsIGJ1dCBJIGNhbid0IHJlbWVtYmVyIGFueSBzcGVj aWZpYyBjb25jbHVzaW9ucyBiZWluZyByZWFjaGVkLg0KDQo8bW92ZWRIb3Jpej4gLyA8bW92ZWRW ZXJ0Pg0KDQpUaGVzZSBlbGVtZW50cyBhcmUgd2VsbCBkZWZpbmVkLCBubyByZWFsIGNvbW1lbnRz IGhlcmUuDQoNCjxzcGVlZEV4Y2VlZHM+DQoNClRoaXMgZWxlbWVudCBpcyBsaWtld2lzZSB3ZWxs IGRlZmluZWQuICBIb3dldmVyLCB0aGUgI21wcyBpcyBsaWtlbHkgdG8gY2F1c2UgcHJvYmxlbXMg d2l0aCBHTUwgcHJvY2Vzc29ycywgd2hpY2ggd2lsbCBzZWFyY2ggZm9yIGEgZGVmaW5pdGlvbi4g IEknbSBub3QgYXdhcmUgb2YgYSBzdGFibGUgcmVmZXJlbmNlIGZvciB0aGlzLCBzbyBJIHN1Z2dl c3QgdGhhdCB5b3UgZGVmaW5lIGEgVVJJLCBtYXliZSBzb21ldGhpbmcgbGlrZToNCiAgdXJuOmll dGY6cGFyYW1zOnhtbDpuczpsb2NhdGlvbi1maWx0ZXIjbXBzDQpGb3IgcmVmZXJlbmNlLCBJJ3Zl IGluY2x1ZGVkIGEgR01MIGRlcml2ZWQgdW5pdCBkZWZpbml0aW9uIGF0IHRoZSBlbmQgb2YgdGhp cyBlbWFpbCBmb3IgbWV0cmVzIHBlciBzZWNvbmQuDQoNCjx2YWx1ZUNoYW5nZXM+DQoNCk5vIGNv bXBsYWludHMgZXhjZXB0IHRvIHBvaW50IG91dCB0aGF0IHRoZSBleGFtcGxlcyBhbGwgcmVseSBv biBhIGRlcHJlY2F0ZWQgbmFtZXNwYWNlLiAgUGxlYXNlIHVwZGF0ZSB0aGlzIHNlY3Rpb24gdG8g cmVmZXIgdG8gInVybjppZXRmOnBhcmFtczp4bWw6bnM6cGlkZjpnZW9wcml2MTA6Y2l2aWNBZGRy IiAgKGFuZCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWdlb3ByaXYtcmV2 aXNlZC1jaXZpYy1sby0wNSkNCg0KPGVudGVyT3JFeGl0Pg0KDQpUaGlzIGVsZW1lbnQgdXNlcyB0 aGUgZ21sOkZlYXR1cmVQcm9wZXJ0eVR5cGUsIHdoaWNoIGhhcyBhIHJpY2hlciBjb250ZW50IG1v ZGVsIHRoYW4gaXMgcmVxdWlyZWQgZm9yIHRoaXMgcHVycG9zZS4gIE15IHN1Z2dlc3Rpb24gaXMg dG8gc2ltcGxpZnkgdGhpcyB0byB1c2UgZ21sOkdlb21ldHJ5UHJvcGVydHlUeXBlIGluc3RlYWQu ICANCg0KVGhpcyB3b3VsZCBhbHNvIG9idmlhdGUgdGhlIG5lZWQgZm9yIHRoZSB1bmRlZmluZWQg PG15OlBhcmtpbmdCdWlsZGluZz4gZWxlbWVudHMsIHdoaWNoIG9ubHkgaW5jcmVhc2UgaW1wbGVt ZW50YXRpb24gY29tcGxleGl0eS4gIFdpdGggdGhlIGN1cnJlbnQgZGVmaW5pdGlvbnMgaW1wbGVt ZW50YXRpb25zIG5lZWQgdG8gcmVjb2duaXplIGFyYml0cmFyeSBlbGVtZW50IGNvbnRlbnQgYmFz ZWQgb24gaXRzIGRlcml2YXRpb24gZnJvbSBnbWw6RmVhdHVyZSwgd2hpY2ggcmVxdWlyZXMgYSBj b21wbGV0ZSBzY2hlbWEgcGFyc2UgKGFuZCBhY2Nlc3MgdG8gc2NoZW1hKTsgb3IgYXQgYSBtaW5p bXVtLCB0aGV5IG5lZWQgdG8gbWFrZSBzb21lIGFzc3VtcHRpb25zIGFib3V0IGNvbnRlbnQgbW9k ZWwuDQoNCkluIGVzc2VuY2UgdGhlIGNoYW5nZSBpcyB0cml2aWFsOiBjaGFuZ2UgdGhlIGJhc2Ug dHlwZSwgYW5kIHJlbW92ZSBhIGZldyBsYXllcnMgZnJvbSB0aGUgZXhhbXBsZS4NCg0KICAgPGxv Y2F0aW9uLWZpbHRlcj4NCiAgICAgPGVudGVyT3JFeGl0Pg0KeC0+ICAgIDxteTpCdWlsZGluZz4N CngtPiAgICAgIDxnbWw6bmFtZT5CdWlsZGluZyAxMDwvZ21sOm5hbWU+DQp4LT4gICAgICA8Z21s OmV4dGVudE9mPg0KICAgICAgICAgICA8Z21sOlBvbHlnb24gc3JzTmFtZT0idXJuOm9nYzpkZWY6 Y3JzOkVQU0c6OjQzMjYiDQoNCkluIG9yZGVyIHRvIHN1cHBvcnQgeW91ciB1c2Ugb2YgZXh0ZXJu YWwgb2JqZWN0cyAod2hpY2ggSSB0aGluayBpcyB2ZXJ5IHVzZWZ1bCBmb3IgdGhpcyBzb3J0IG9m IGFwcGxpY2F0aW9uKSwgdGhlIHhsaW5rOmhyZWYgYXR0cmlidXRlIGFjdHVhbGx5IGdvZXMgb24g dGhlIGVudGVyT3JFeGl0IGVsZW1lbnQgY29uc2lzdGVudCB3aXRoIEdNTCB1c2FnZSAocmVmZXIg dG8gc2VjdGlvbiA3LjUuMyBvZiBHTUwtMy4xLjEpOg0KICANCiAgIDxsb2NhdGlvbi1maWx0ZXI+ DQogICAgICA8ZW50ZXJPckV4aXQgeGxpbms6aHJlZj0iaHR0cDovL2V4YW1wbGUuY29tL2J1aWxk aW5ncy54bWwjMTAiLz4NCiAgIDwvbG9jYXRpb24tZmlsdGVyPg0KDQpUaGlzIGRvZXNuJ3QgcHJl dmVudCB0aGUgdXNlIG9mIHBhcnRzIG9mIGFuIGV4dGVybmFsIGZlYXR1cmUgY29sbGVjdGlvbi4g IEl0IG9ubHkgbWVhbnMgdGhhdCB0aGUgcmVmZXJlbmNlIG5lZWRzIHRvIHBvaW50IHRvIHRoZSBn ZW9tZXRyeSBvYmplY3Qgd2l0aGluIGEgZmVhdHVyZSwgcmF0aGVyIHRoYW4gdGhlIGZlYXR1cmUg b2JqZWN0Lg0KDQpUaGUgY29udGFpbm1lbnQgcGFydCBzZWVtcyB0byBvbmx5IHVzZSB0aGUgbmFt ZSBwYXJ0IG9mIHRoZSBmZWF0dXJlLiAgSXMgdGhpcyB0aGUgcmVhc29uIHRoYXQgeW91IGhhdmUg cGVyc2lzdGVkIHdpdGggRmVhdHVyZSByYXRoZXIgdGhhbiBHZW9tZXRyeT8gIFlvdSBzaG91bGQg a25vdyB0aGF0IEdlb21ldHJ5IGFsc28gcGVybWl0cyBuYW1pbmc6DQoNCiAgIDxnbWw6UG9seWdv biBzcnNOYW1lPSJ1cm46b2djOmRlZjpjcnM6RVBTRzo6NDMyNiI+DQogICAgIDxnbWw6bmFtZT5C dWlsZGluZzwvZ21sOm5hbWU+DQogICAgIDxnbWw6ZXh0ZXJpb3I+Li4uPC9nbWw6ZXh0ZXJpb3I+ DQogICA8L2dtbDpQb2x5Z29uPg0KDQpXaGF0IHB1cnBvc2UgZG8geW91IHNlZSB0aGUgbmFtZSBz ZXJ2aW5nIGluIHRoaXMgY29udGV4dD8gIEkgZG9uJ3QgdGhpbmsgdGhhdCB1c2luZyBpdCBhcyBh IGZvcm0gb2Yga2V5IGlzIGFwcHJvcHJpYXRlLiAgSWYgdGhlIGludGVudCBpcyB0byBhdm9pZCBl Y2hvaW5nIGVudGlyZSBnZW9tZXRyaWVzLCB0aGVuIHBlcmhhcHMgdGhhdCB3b3VsZCBiZSBiZXR0 ZXIgc2VydmVkIGJ5IHVzaW5nIElEIGF0dHJpYnV0ZXMgb3Igc29tZXRoaW5nIHNpbWlsYXIuDQoN CllvdSBjYW4gdXBkYXRlIHRoZSByZWZlcmVuY2UgdG8gdGhlIGdlby1zaGFwZSBkb2N1bWVudCBh ZnRlciBpdHMgYWRvcHRpb24gYnkgdGhlIE9HQyAoaW4geG1sMnJmYyByZWZlcmVuY2UgZm9ybSk6 DQoNCiAgPHJlZmVyZW5jZSBhbmNob3I9Ikdlb1NoYXBlIj4NCiAgICAgPGZyb250Pg0KICAgICAg ICA8dGl0bGUgYWJicmV2PSJHZW8tU2hhcGUiPkdNTCAzLjEuMSBQSURGLUxPIFNoYXBlIEFwcGxp Y2F0aW9uIA0KICAgICAgICAgIFNjaGVtYSBmb3IgdXNlIGJ5IHRoZSBJbnRlcm5ldCBFbmdpbmVl cmluZyBUYXNrIA0KICAgICAgICAgIEZvcmNlIChJRVRGKTwvdGl0bGU+DQogICAgICAgIDxhdXRo b3IgaW5pdGlhbHM9Ik0uIiBzdXJuYW1lPSJUaG9tc29uIiBmdWxsbmFtZT0iTWFydGluIFRob21z b24iPg0KICAgICAgICAgICA8b3JnYW5pemF0aW9uPkFuZHJldyBDb3Jwb3JhdGlvbjwvb3JnYW5p emF0aW9uPg0KICAgICAgICA8L2F1dGhvcj4NCiAgICAgICAgPGF1dGhvciBpbml0aWFscz0iQy4i IHN1cm5hbWU9IlJlZWQiIGZ1bGxuYW1lPSJDYXJsIFJlZWQsIFBoRC4iPg0KICAgICAgICAgICA8 b3JnYW5pemF0aW9uPk9wZW4gR2Vvc3BhdGlhbCBDb25zb3J0aXVtIEluYy48L29yZ2FuaXphdGlv bj4NCiAgICAgICAgPC9hdXRob3I+DQogICAgICAgIDxkYXRlIG1vbnRoPSJEZWNlbWJlciIgZGF5 PSIyNiIgeWVhcj0iMjAwNiIvPg0KICAgICA8L2Zyb250Pg0KICAgICA8c2VyaWVzSW5mbyBuYW1l PSJDYW5kaWRhdGUgT3BlbkdJUyBJbXBsZW1lbnRhdGlvbiBTcGVjaWZpY2F0aW9uIg0KICAgICAg IHZhbHVlPSIwNi0xNDIsIFZlcnNpb246IDAuMC45Ii8+DQogICA8L3JlZmVyZW5jZT4NCg0KQ2hl ZXJzLA0KTWFydGluIA0KDQoNCnAucy4gQSBHTUwgZGljdGlvbmFyeSB0aGF0IGRlZmluZXMgbWV0 cmVzIHBlciBzZWNvbmQgaXMgaW5jbHVkZWQgYmVsb3cuICBOb3RlOiBJIGRvbid0IGhhdmUgYSBz dGFibGUgcmVmZXJlbmNlIGZvciBzZWNvbmRzIGVpdGhlciwgc28gdGhvc2UgYXJlIGluY2x1ZGVk IGFzIGEgYmFzZSB1bml0Lg0KLS0NCjxnbWw6RGljdGlvbmFyeSB4bWxuczpnbWw9Imh0dHA6Ly93 d3cub3Blbmdpcy5uZXQvZ21sIiANCiAgICAgICAgICAgICAgICB4bWxuczp4bGluaz0iaHR0cDov L3d3dy53My5vcmcvMTk5OS94bGluayI+DQogIDxnbWw6ZGVzY3JpcHRpb24+VW5pdHMgb2YgbWVh c3VyZSBmb3IgdXNlIGluIGxvY2F0aW9uIGZpbHRlcnMuPC9nbWw6ZGVzY3JpcHRpb24+DQogIDxn bWw6bmFtZT5nZW9wcml2LWxvYy1maWx0ZXJzIHVuaXRzIG9mIG1lYXN1cmU8L2dtbDpuYW1lPg0K ICA8Z21sOmRpY3Rpb25hcnlFbnRyeT4NCiAgICA8Z21sOkJhc2VVbml0IGdtbDppZD0icyI+DQog ICAgICA8Z21sOmRlc2NyaXB0aW9uPkEgc2Vjb25kLCB0aGUgU0kgYmFzZSB1bml0LjwvZ21sOmRl c2NyaXB0aW9uPg0KICAgICAgPGdtbDpuYW1lPnNlY29uZDwvZ21sOm5hbWU+DQogICAgICA8Z21s OnF1YW50aXR5VHlwZT5UaW1lPC9nbWw6cXVhbnRpdHlUeXBlPg0KICAgICAgPGdtbDpjYXRhbG9n U3ltYm9sPnM8L2dtbDpjYXRhbG9nU3ltYm9sPg0KICAgIDwvZ21sOkJhc2VVbml0Pg0KICA8L2dt bDpkaWN0aW9uYXJ5RW50cnk+DQogIDxnbWw6ZGljdGlvbmFyeUVudHJ5Pg0KICAgIDxnbWw6RGVy aXZlZFVuaXQgZ21sOmlkPSJtcHMiPg0KICAgICAgPGdtbDpkZXNjcmlwdGlvbj5NZXRlcnMgcGVy IHNlY29uZCwgdXNlZCBhcyBhIG1lYXN1cmUgb2Ygc3BlZWQuPC9nbWw6ZGVzY3JpcHRpb24+DQog ICAgICA8Z21sOm5hbWU+bWV0ZXJzIHBlciBzZWNvbmQ8L2dtbDpuYW1lPg0KICAgICAgPGdtbDpx dWFudGl0eVR5cGU+U3BlZWQ8L2dtbDpxdWFudGl0eVR5cGU+DQogICAgICA8Z21sOmNhdGFsb2dT eW1ib2w+bXBzPC9nbWw6Y2F0YWxvZ1N5bWJvbD4NCiAgICAgIDxnbWw6ZGVyaXZhdGlvblVuaXRU ZXJtIHVvbT0idXJuOm9nYzpkZWY6dW9tOkVQU0c6OjkwMDEiIGV4cG9uZW50PSIxIi8+DQogICAg ICA8Z21sOmRlcml2YXRpb25Vbml0VGVybSB1b209IiNzIiBleHBvbmVudD0iLTEiLz4NCiAgICA8 L2dtbDpEZXJpdmVkVW5pdD4NCiAgPC9nbWw6ZGljdGlvbmFyeUVudHJ5Pg0KPC9nbWw6RGljdGlv bmFyeT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNz YWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWlu IHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlv bi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRo b3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ0K --===============0102693505== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0102693505==-- From geopriv-bounces@ietf.org Mon Mar 26 12:46: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 1HVsL8-0003GQ-DV; Mon, 26 Mar 2007 12:46:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVsL7-0003GJ-T5; Mon, 26 Mar 2007 12:46:37 -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 1HVsL3-00052D-N1; Mon, 26 Mar 2007 12:46:37 -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, 26 Mar 2007 12:41:04 -0400 id 01588015.4607F7A0.00004C29 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <353307C5-089B-4768-A5EB-0D3A76B7F4E1@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Mon, 26 Mar 2007 12:45:59 -0400 To: Cullen Jennings , iesg-secretary@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: GEOPRIV WG Subject: [Geopriv] Document Shepherd Write-up for draft-ietf-geopriv-revised-civic-lo-05.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Technical Summary This document defines an XML format for the representation of civic location. This format is designed for use with PIDF Location Object (PIDF-LO) documents. The format is based on the civic address definition in PIDF-LO, but adds several new elements based on the civic types defined for DHCP, and adds a hierarchy to address complex road identity schemes. The format also includes support for the xml:lang language tag and restricts the types of elements where appropriate. Working Group Summary This document was reviewed by the GEOPRIV working group, where it has reached consensus for publication as an IETF RFC. Document Quality The XML Schema contained within this document has been checked against Xerces-J 2.6.2. In addition to updating RFC 4119, this document is also a normative reference in draft-ietf-ecrit-lost-05.txt. There are three known implementations of this specification. Personnel The Document Shepherd is Andrew Newton . The Responsible Area Director is Cullen Jennings _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From BCSDFR@HOTMAIL.COM Mon Mar 26 19:41:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVyoy-0008WE-9T for geopriv-archive@lists.ietf.org; Mon, 26 Mar 2007 19:41:52 -0400 Received: from [218.27.110.21] (helo=lists.ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HVyow-00030j-Ey for geopriv-archive@lists.ietf.org; Mon, 26 Mar 2007 19:41:52 -0400 To: From: =?iso-2022-jp?B?GyRCMi5MbhsoQg==?= Subject: =?iso-2022-jp?B?GyRCPVUkQCQrJGkhJiEmISZLKCQoJEMhKhsoQg==?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 $B40A4L5NA%i%s%-%s%0!*$"!&$=!&$\!*(B http://u-lav.com/fa03/ From geopriv-bounces@ietf.org Tue Mar 27 10:51:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWD1F-00076e-PI; Tue, 27 Mar 2007 10:51:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWD1E-00075M-LR for geopriv@ietf.org; Tue, 27 Mar 2007 10:51:28 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWD1C-0006PT-9z for geopriv@ietf.org; Tue, 27 Mar 2007 10:51:28 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 27 Mar 2007 07:51:25 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l2REpPEq008868; Tue, 27 Mar 2007 07:51:25 -0700 Received: from [192.168.4.2] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l2REoQxG016409; Tue, 27 Mar 2007 14:51:23 GMT In-Reply-To: References: 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: Cullen Jennings Subject: Re: [Geopriv] draft-thomson-geopriv-lis-discovery-00 Date: Mon, 26 Mar 2007 12:18:31 -0700 To: "Thomson, Martin" X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2015; t=1175007085; x=1175871085; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Geopriv]=20draft-thomson-geopriv-lis-discovery-00 |Sender:=20; bh=03tN4X3G5zSsKU9fQs5lxtdLlkI/0ecq79HifuaXeZg=; b=nG302QDfDyMdjWaoeyIiV4eYc66bRcb2Mzo4w5mQkjd/i/uJxFbSbmm6WM1b7vzHzqS8BsBp B31uLkYrpcT0r4nqGg18lNSZJ+V9Z7B3GDdtB8YUUPcuRsGo1dFPjIzc; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I see what you are saying about the LIS being in in the second layer. Thanks for getting me less confused :-) On Mar 11, 2007, at 4:19 PM, Thomson, Martin wrote: > Hi Cullen, > > The intent is not to discover the outermost NAT, at least not > always. If you look at the cases where two layers of NAT are used, > a LIS is likely to exist within the second layer. > > I'm thinking primarily of cable networks where it is common to have > a NAT on the customer premises and another NAT for the entire ISP > network (or parts thereof). Say these are a 192.168.x.x (in my > house) and a 10.x.x.x (for my ISP). The ISP LIS needs to exist in > the larger network so that it can see the necessary identifiers > (primarly, the 10.x.x.x address that is given to your house/modem/ > router/NAT). In this case, resolving the IP of the outermost NAT > is counterproductive. > > Perhaps this discussion is worth including in the draft. > > Cheers, > Martin > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Sunday, 11 March 2007 9:00 AM >> To: geopriv@ietf.org >> Subject: [Geopriv] draft-thomson-geopriv-lis-discovery-00 >> >> >> UPnP will not discover the outer most NAT so I don think it should be >> used here. >> >> Cullen >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2] _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From Chrys-myung@ak.durdilova.cz Wed Mar 28 10:31:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWZBh-0002rc-Hk for geopriv-archive@lists.ietf.org; Wed, 28 Mar 2007 10:31:45 -0400 Received: from [195.138.130.98] (helo=host2.itochu.bg) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWZBS-0005L1-Qp for geopriv-archive@lists.ietf.org; Wed, 28 Mar 2007 10:31:45 -0400 Received: from 123-9ef0a964fc6 by ak.durdilova.cz with ASMTP id 648C82B3 for ; Wed, 28 Mar 2007 05:29:04 -0800 Received: from 123-9ef0a964fc6 ([153.153.90.33]) by ak.durdilova.cz with ESMTP id E608924D8EAB for ; Wed, 28 Mar 2007 05:29:04 -0800 Message-ID: <000f01c7713d$0756eef0$62828ac3@1239ef0a964fc6> From: "copies" To: geopriv-archive@lists.ietf.org Subject: investing sells cars Dearborn Date: Wed, 28 Mar 2007 05:28:53 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000B_01C770F9.F933AEF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.0 (+++) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 ------=_NextPart_000_000B_01C770F9.F933AEF0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000C_01C770F9.F933AEF0" ------=_NextPart_001_000C_01C770F9.F933AEF0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Their respective ie breaks outlook pintmaster ae cc? Unix techniacl amp about, small business offering such. Makeopen way happen case hole, dictated. Aka, outside, away benefit. Of, the in are designed to. Bands artists endorsing, our read more stand = choice american. Todays game lego smbtoday happy. Easy, instantly launch webex meetmenow instant messenger. Ctu fmu, itt anthem south devry! Mpr selphy cp ds mini id, ipr ipd lide. Whether packs highest pmits stories hug. Doing google phrase prints. = Radios, worse lg phones! Click here, access global. Protection sans nas raid identity tries dwho = favor. Affordable detects enforces policies every learn offers! Robot plx thx, joshua his mind. Cisco router kiwi cattools, expert = thinks. Cardio diabetes brian alveyaol, jason judith meskillaol ted leonsisaol. ------=_NextPart_001_000C_01C770F9.F933AEF0 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable

Their respective ie breaks outlook = pintmaster ae cc?

Unix techniacl amp about, small = business offering such.

Makeopen way happen case hole, = dictated.

Aka, outside, away = benefit.

Of, the in are designed to. Bands = artists=20 endorsing, our read more stand choice american.

Todays game lego smbtoday = happy.

Easy, instantly launch webex meetmenow = instant messenger.

Ctu fmu, itt anthem south devry! Mpr = selphy cp ds=20 mini id, ipr ipd lide.

Whether packs highest pmits stories = hug. Doing=20 google phrase prints. Radios, worse lg phones!

Click here, access global. Protection = sans nas raid=20 identity tries dwho favor. Affordable detects enforces policies every = learn offers!

Robot plx thx, joshua his mind. Cisco = router kiwi=20 cattools, expert thinks.

Cardio diabetes brian alveyaol, jason = judith=20 meskillaol ted leonsisaol.

------=_NextPart_001_000C_01C770F9.F933AEF0-- ------=_NextPart_000_000B_01C770F9.F933AEF0 Content-Type: image/gif; name="Thread.gif" Content-Transfer-Encoding: base64 Content-ID: <000a01c7713d$0756eef0$62828ac3@1239ef0a964fc6> R0lGODlhkAF4AYcAAAAGC4kAAAB0AISLBgABh3UAcQZ+fMm9xMbkxJzO60ceC2MTB3siBakiAcwu DesnAA49ABVNDUI5AGFDAHJEAKUzAM1LAeE6BgBqBBRYCz1uAFdYCYJUAKpfBs1tDdRpAAB1ABx/ Ckl5AGiMCneDAJyLALWBAOuKAAigABujBkCgAGicBXWlCKunCsGgCduRAArJDSO7AEa+AF6zBHe/ BZzNAL6+COixAADUABvqAEviAGfVAoLnAKzdAMvhB+PYAAAANSMAQ0EATmwMOowAN6UMPMIATdYH MgMmNCctQEkdM2AoPIgXQ6UaTrITQdUXNABNQihKTUo2SlQ2QH5CRa5KMrk5O9tDNgJfORZuNUps NWVuQIxoAKBWRb1RR+BrQwWHSRF6OjZ1N254SXt/RZ52Q7FyNtV0OgurNROSMzOaOV6WQ4OUNZWm Pb2RQdiSRgDHPRnNMz7LOGPCPYC1R6LMSMG6Pt3BRAXSOyLdRE3XSG3aPI3aRKDkNM3cM+jRPAAA gCYAfUQAiGMAcoAAda0AjLkIdNUAgAETfRYfdkQWc10XgoEUiqEneM4medISfQs6fhZIgzw3fmE0 h3tEeJMzgLVOjNFIcwBdfSRud0lkcWVaf4RZhJFRjLNpcuZRgguIehl0ejt+hlFyhoR7d5Z+fcmN g959dwyTeymqjUumhFuWc3SqgZuierSgeNyqdADKfROycTG3jFfLcYqzf5O0d8O3ctTEewDthx3g fUzuglXtgoHgdZ3qjMPejNPWiAIAzisAtzQAu1EAwXEEvKwAvsgAs9YAtwUXvSkpzE4bzFoUvXsr w5sjzb8qtN0svwlFxRROyDcyvGA0xnNIxa5DsbhAyeFOxQBixi1St0lquGdqzYhovZxSwsFdtO5m uQWMsxR9uDmKvFWMuYuGtaSIvbKLwNuBwwmivC6Vzjicx2CovI6kyKKluM6TwOSmsQC6uyy9tzi4 zVO7uXa8s66xtf//95KupYOMjPkCDgz/APH7AAAG+P8H8AD/8///9iH5BACs5+AALAAAAACQAXgB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixIsJ/GDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGN6tEizps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqxSmzqdOnMJdKnUq1qtWrWLNq3cq1q9evBaGK HUuWLNizaNOqXcu2rdulZePKnQv1rd27Yenq3cu3r9+/gAMLHky4sOHDiOfiXVw1sePHdRlLnky5 suXLPwEAwMy5s2euUEKHFij6s2mkKoGo3qgaCOTCPMHInk37tO2iqVdrbM26te5/vD8SGL5xOIGS xpMTf22co+/f/5orP/66unWxFDVvHqi9ILDv4IEN/wz//WDrgucdkg//lT3B6cYFwo9v8br9+y2D A4fOrz+/f/5lNB9HAWJU4EnNOXXgS9ppplGDGWknIHz4VWihXAcuKGFH4GEUHkcbbnhShw86+I+I JTWIokrkaZQgRi9utOKFNNaYUUX00SdQdwjxuKNmBXXnY0RD2sOjj0KquN2PKh7U4ENDPmlkkUze ZuVQK4VoIkYzRrjliSsqqVKYJor43JmucSkhimKSFKOSXYK5pERAXmmnQiytuWWcHn63EYleQpgS mQCoWShGaD4XqKEZrQdMil9GRyGIcB46Ep82Zmpfm4x+RCilkZq0YoIvJifpcS9qaSmmwi0HI6kx Gv8KJ0mhamrrpiqWaGlHn4IK6aqRqrqonMR2KiKnl37JZqhisnrrs4JZpCRBUdY55ZxSUmttQ0hu e22V4Ca5pLhzXuutQtVi6y25VN7prkQtCRroofIe26WzuhYqr6z1lumgvbnyWqtHy/obrMEDm/Tu nfHOWGm+AcuYsKezShyxsAATui/FF1cM7cc1Zpattk06ea5DJUNZp7jcnWyuywbBSTK+INds883J 7oqzXwv37Fa7Pgf91s5l0Uz00Uj/IzRFCjS9tD1JRy110k9XfdDUt1qt9dZc84S1zV2HLfbQLS2w QEwTBxAAZE23jZLackWM0sQZte12SA00UNLYNLn/5IADMTHAAEh0A/Z3RoeblHhZTWPU+EhwIw44 SYuHVPnXtwoe+OAfYYDBSIJrjhEEpJMOlekaoU6rzmJRQEFGridbYkmqh1Q45viVDsFGuos6owDA A5+R8P8Q/4/pqgdfvAAbKb+R55+LVPvou2MEvee895567Sh0371G3qMwkuq1B8+8Rthn9D1J08ud Pt9AsQQDDP/Mv/3x1Y8kvPHU9+8/6ulLH/78hxF96OMfBgSf+NYHEgFmRIC6y9/yMMK/BCbQetfL CA5w8I8Nyk5ND4yeA7knPpIwkFFbmh7uolUR4NnDhS2TCOnsMcOBzM+GMCCI7gbSPYH0UCAbBCIO /3B4kBvaw4joKteUiIjEH9rDiT904gxraA/PQaSGVKQhBASSRSQeMYcOgeFArFhFDAwkiPDbyrQI EjyVjYyKWQzfGM1YxoFgcYsC8SIP5cgQNBLEjwY0CBKRuMFC6hCPBTGgPhwSPhQUBI1+1OIfh+iQ SC7xkvawZBp3shLj8Y+C5xPJnixFPgmaz0sgxIgHO8hBDHbEeyVZpQZbiZETgnJ4oSwkR1SISpHs L5T/k6Dp5vgQMQoEhmI05iarYkxlPtGRDGmmAIiYRzDaEZHVnJ8R7xhDTHIzmtM8Zji7qS1yInOc MIMZG8NpzChC04fvfOZDyEjMOi5TKGPa1ZZO+f/BVFJPexmBTkpEA4XmOS9noYIDHDqi0IYuNCPa pF8vNRJRktgPIxeVlcQoKtGQ0EY2EJVoRkG6Qtjc0ypzEWhJiXZSyaz0pTCNqWNaehOZ2vSmSKOp Tnf6E5z6dC88DapXfkrUxzyqqEhN6l9YxzqyJIw6Y5GbUlci1IcMCkR60VdT57LVqXq1LxMplxJj FqSxQok7SjFrVdc6FGyRLEjU2lFZURbXurZsXJd0K13jei6YffWvLMkOWgdrJLuadTtqtatcCVvY xi4RsYpdiFghO9jEsvWye3WsY/WqWcJadrGMxStoKdvYz0ZWtJ3FLGazdCIZRehBr8Xq7VoL29j/ 0va2TOWSqFyr297aR7W32YxYQ+tZcnILrsUdrcmIhNzNNgSw0OUqVn1722L5tqu1pS5ubdvU2dr2 utz9bnTHW5a1cURt5jUJektit/NqxG0KwEh6NzLfkKA3cv9I73zv5jjy+pckPnNAZf67Qp8FALgI xuyBE8zgqirAKASOsIQnTOGXNPjCQa3wSTAMPw17+MMgthCHzxLir42Ykw0zmu+wKxJYpqR02ZMg /gCqyAY68B/Qg8yJj8KSCMK4KQdNiTZV8uOMFHnGAEVWCKO35BJTWMUpCTJKhpwSXc6SlnLSqqUa 6WIFlvAfXXYygak8lobKL6MoEU1G1GxkXi7v/3z81IiZ/zFnsO6YMen5SZ4nsuc9K6SN4hznbBIy 6IEUeiBtBPRCxGxiisyHIH1WjXyGYw/4vGc6B1GOQSINBIfkiNID8TOkJR1qP5+payW2SKLu+lZ7 OIo843FUQfxDa++Ux9Gg1pGOzEPqUnd61L5hC6MVcxP32CM9ea5Utp40svMEm9UVYRm4EGLqXvv6 1wIZdoVFRCJAmUo6rgLYsKz7D0ANSm6Y6tWf/PTTO3NrXdvCNLSl/a1p6xrUAhE1ROQtEP8QxN/5 tvazW90YbRsG1/hOzqUVPm8gdWtc1no4wevdEFr3Z2ZMWtK98T1xqBk8uvOB6rwshsItdRtQEP/a V8FM8qHiTApRieIQu6vjbtysZDoEG9VywA3Vh0HsYCwW5b02xq+BQfnjOQUKlY7k8IivsaxLV+dV kG7wo1P9LzU/itSzznUrAa3rYA/u1t199a95t+xoT7t1ws72pan97XCPu9x31naizP3uVCvK14fS trr7PSJ/C7yAUTb2n6BXJw9IfEHsxvi/Vy2fUn2MkjGSt8qTpL0aSbzmN493/8IYoI5hPOYzErrS Cz1UR76Q44NCZNSl3iOpd53sxeJjGWMkdLcX3UdADzvZz77zMqVI6biYxYRA75AR7EminXm9OdIR IcM/SO2xufqTeu+ZToyoNgeiSIJsf/szg7f/aa9//YJEn/jUR/4OJ0nJQlJSLcAfC0Wud/xrJj+b Z9Sk8+nvfT0ihP7NZ3/IZ3wA+HwUt3fVJzbuZ0kyE2iI5kwCqEXpBxEF+HyGlH/vFzNOp1aKBhfx NxgU0YFv5SOKdn5Q9zI10YDlB0/xdILTpoGmlYBbAzQm6Hx3JVzWUns3QX4/1IEiSBAruIIGIYQy mEbgt2nWBm3ot37HNnA2sXzh5FACIYU9Qi4NF4Oc8YE3MhE/KBCHBmwF8VHAhm3WhoAB12lo4mtn uE7j1ITPMYZOWITukhtpwhGxohIDElAq1RGJAh15CHN1+Cp3eCZa+FI8sWsWoWmqloYFwW9W/1KI ZnEbiCiHFyY1Vpd2lRg1+gGJnNiJnviJoGhTlDiKpFiKpniKqKhTWChZPbOKpGiJMBF0gCGLDLIR puGKdzEm4mUv06VdBIM2sTiLg0GL0EKMmiJYoFVaaLUuydhWSlgkD0daqSUUqIVX8OZGN6hcSrho c9Mr+tRa9KIrrzVKwGKM+IGMzkVWySiN6IIT1qiNypiOqJVEEDdZHkduqxJeqZSP1eUpvcWP/Ehb 4Xgw4ihK+hiO/6hVAhlbZaKPNxNt6aiO6ziNTtJxCYEkxBWRpCVapiVc8EhZ1chXhlVZjNUjJKlc IZlXJzmPJrlYKQmSLvmRGYkZrGUp9ZURZ/+DkxqBXyIRX/KlXj/ZX0KJEWaTk0GZX0Spkz95k7+Y EXrzD0/5D0bplJT3XjuJlEqJlVgZlVH5ET75Dz75lQ8mEAe2YPZglgvGkQbRAALBlgyBlgIxlvYg l2U5EAsgEHdpD3nZdwMBl80ol5axEvH1lUz5D/mgEYdplSQxlYXJEWKZEen1AIoJlkdpXo9ZN19p OxpRlIh5XjxJmVepEVGpX+AVEpcZkFoJmqB5mZMjmnmjNAyhlsmoNisZlwMxln5pD4NHEA/wNB7Z lgThlvaQDwNBnARhnA5hlgKBnAohl845EMJJlrRZnPlAnMZZndVJEMq5ELupl3YpELs5eCn/2ZcF YZZ56Z0Z1xCHt2B2QxDnGZeNE1+kqZXmNZ8gUZSMCTfptSuT05+QiV+tGaCS05oxlZhOaXmY+TiT CTm9+BH2CRUGKhJdaZjVuZM8iSKZyRKN+RQGaqAoonkjQaB4E4rspaAhgZ2GKRYbChkrWh20OJVe pYprYYZgEZ0K0Z2pKFQkChhdt6M++qMeJhQTuHpD+oRWdXVC0YJT0YZcoaRIgUhO0VHAJxRMOhVO mhVFqnc+kaU1oX8TUXzmZ35g6jPT1E5EqHTbEn0X+GcvdEwDKFfbomicBX1U1IURUX6IhEiAVqZV ihBrSnHut6U5gYPQVxBgZE2MsRI5xkqq/1SaIZF6B7UhnyNAAMkRWPYR9pOppRlAm/pA+qNBoNpj xzM6RqZdZRJNiDZGVQREZ+QT5SKE9bcQ1oSobtqG7dcz7MRFduSmvKoQUDAQvxqTXmgPYDCFcDCF eZSsoRamDPFrzqqr0DqryoqoeMSlwwqtNHQ1JSGldViHUhpKwOQR4PpdYJAR5YoRbIauoRFSUuoR irJdGFGu56qZ31U9EnSu82orE1Gs1zpO4USGzZpvqdqr2NamvCpq/HqtrBiPAHtsy0qsslEQZZpZ /koTBZuwCeuw8EhohjawAvuxDeuwv+aKBRuyfYoQbdiGtWFoEbswBDAQL1tpMCsQ4kGzzf8qcA+r sfIxszpbsDL7sQsRs0ILtM/6sTH7swHnECHrs8/lIrsRUMUBIwIiEt0KtVYLHIiStVfrISYhclAF VYEYEoFYtVqrW+ZYM0dVbmXbrZvorlYbkGmrtlzbJ2m7ibJ4VHg7bl87br74EYFobirxH/kiiI1S uKenEXGbZZ0ytazBERf5HjyLtLE5k47FD/1GGXSItQyiLP8yt44KGWeLMzXrauNxEJZ7XGCYswzB cDsLua2LtKObo5mxMALzjY0ycwYpYQyGiygGpL77u8BrI7JLYsFbvMZbIcMLL8dbFsnbvBXZFbx7 EXI3MTpjNKFrHddLK3mivbrYt+e2W1//JVguM1wU+RXRq3Ulibqz24zouI3N1WFX5Yv6Ulu0mL19 gS/5SJB8+7jrGHGYRKPW2JErg0lhhVz1+IJj073UhZD/yL2LazuFM7/9eCwFabaX0kuVasEPXC8H ycD1i8EXrCajNXYlI5uRpVpzOjI0urGTW74x5HAnqZHpy7/ymFzaOJ4bacMLu1khDK+oSTjZ9cP2 izkUoZxm+Zy3OZcPoZwxmJsJsWBQTJbkKcW2WcUuXJ5TfJZWjMR42cVbnMVFqZ1ZDJgKcWBDmaFN 6cPe2xGMCZnZlZpKhY5zYsRJrMQN8Z72YKMIgZzMiRBRrMV2HMh0mcVYuCR+ycWAyZdU/wzIjNyb AuHIXIyjTwydlMwQiCyd27kQZNx3iZzF8Ps26+XGoamaaNwRIqqaXlk3uYuQl6mVHSrKDIoRkinL CfqVuzKfD1rBAnqUpumQIJFeXIkRr6wRCeHICaHIgTy8h/duv5kQefnMt+k0YwmYmqd0TzydmJzJ aoHMmuy8btHHQaHNrLe8KhE250skhVcR5NwUXcMA3vzObrHOH0N28ixi8HzPWFLP+nwzX0YYrGN7 JmFLtFNhl3p3odSufhGu/WgSB8TQF6TQYPYaCI0YEy13EC2MzbMSAI2pGEVBFmIpl3pCFx0XTLZS IShGesWExnqsR/RF6jcQLF1Y18gQ1f+KrUOSZ4g0MsVkPg2RfoTascnqRUf4Qig9djl0qBZpD8Fq ELlqEFuURTVYTET90kITZcNjtXU4rvG61fuhtWR7W7pRhwzst17t0WaNtXWIr+Y6Em2br0DMESQ1 r/PakMVz1XX9tGX7ESC1144qL/MatmUb11z9D26t13Gt1pqb2CYtEUN7aZD2sEfb2D8bspHNsyGb EC9LaZX9uj4r2UdLw3PCtAjx2ZF7tNi22ZItuUW7EJ2muWny2ldbh3vrHPoI2yF8KGl7VLMNXTPi KtHBuLltIBkhuMHtW7P91R/xKH6Strstcgu5xoYrt1I7EoIbtdP929dNHXfYc7Nl22n/giLFndhf Pd50SxLFzY+7vdgRsdmk295IG7OjW7ObjVqnm47xfVzNfN/NGLP1Xd8Jod/s25LCGpENy5L8PRD+ 3ZIwOeDzuGsAXrMs+bzx2FiX3TOQ912HYiqLIsG4JSI9Z1saTq/Vqyy8pbj0Wl3OTTgezrjwelso x7myiJDl6JApDpucnbPgob45fIaiPYdiMcQKbBh3iDQcDBI1niWdO1V6dhSk/S77jB9H/hQEcHb2 jM9a8eRYnhKnmOW2AuRx4eUxajXn3BZj7oxGUeZOvtCaAuYyERRo7uZmPo1vnlbpLOHtGOB4MedM EYvkOOPjRjPi9sD+GMH6NFs/vOa6/9W+oJ0WR0LAOk0VFz6OpRmQEmyMHvzcar5Rmd7ALc4xZmu7 fBHoKbLAQCeRFznA2wLAju6/E67qpbXgV3wW41nDmkW+LRyRE37nrX7DeC6RdF1dl7jAGwxe5njp kz5yuQsmnL7pIKzGz02MGYzpbB4TBbyxHMmM77vo/RuDJrzjKyzDLAwRQXzsn/sr9HuQ4pXGGRzj DEnsHM7s4+7s8M4XE3Ge56mcwumW9u7J/H4Q+27FjCzOBIHEBF/HXGwQoqnKQ9mVMNq9h1KfCq+a LdoRg+maXTmfrQwSreyTNIPLPLk2+klfPfzwopzLH21bs4zs+fXxFjrx/wCis6wzgf83EpfZyvKC oj1snxkK5Bweykn583BMEolpoBiv8Bmfymdc7h0xn8G8lEF/yhQfn/R5oK95cBOxzJbhxMvJNHUc yMbc7xLxNwMRntkG87wc9LxiW/wFla+pN8NsObC8n7ezyys/X2Pt8w9pNdjZx1/vE5VnEylPeVVP GILH5TaC99bR8Ia/+BHPvFbevGT8+HLI+CEj+ZafE5Sf+bZ4+Zy/MCypaIFUEPF0pVZxsnbxfrR6 EAY4EakfNmPRz2PRUVJqr556Y3BmEmgmPSdRe/XzSsRmE/FkTYu0ENa6EBnosRgWvXxaSa2qrBKL /OyoEK0vqxSRgcW/FhW7wxQx/Vz/g+Tbkz9SBnuq8+tim9gbLUwawTwjvUtUqxtkBr5ZCx0S1LYd AUxw9klFRv/sP6r83/90BhD/BMIQWNBgQQEJBRgE0PDgQ4EKFxaEchAGQYgZNW7k2NHjR5D/7I0k WdKkSSAjU9oDQ7KlypMxX7KEWTOmSQH2co4EcHMmTZc/b44EU7RoSYVET64cOnQnz572ogLV2dTk zJdMtdpsKVSmUqo/p04dihUs1bIuSTKVytPqW7hx5c6lW3ftXXsERurFa5VvXptsm6Zk+tekYcOA 5SZeWRilXXtst7rt+5Yv38Yk/26OS5hwScNTBZM0SKCg6X9ABKruiPqfa9b/ABSc/x3S9m3cuTXa 5Ueyd14CickO5azYuNXev48XP24PGN3nvqVXTixXeeS+w6O//TwS2PeSk5sPfQ5++/Ht52+mhzqc uObpxqtDpl/f/n2SYym33d9UP38A3xquoYZKItA99/wyMD+T/rsNGIMgFEjCfyik7SOHBHINNQop dK2110IsKDYRU+uoNtk0PO3ECwVC8UXdYpRxxo0g+w689kCLi0D8eozrOuV+4zE+5+RCMUUXC+KH tgw9OlK2JlMDQjXWntyotic/pNDKh6ackqEoNbrRwg8PLMhCGtNUc02NuGTzTTWf9NJEOOt0s048 8bwzTz5jrG80HwMVdFBCoSsUrv8+adwzUUZDsmvIQyOVdFJBAaX0UvogxXRTyBr19FNQQ82NU1JL NfVUVFO9VFRWW3X1VVhjlXVWWmu19VZcc9V1V1579fVXYFtVdVhiKQ32WGTrLHZZZpt19lloo5V2 2reStfZabLNllVpuu/X2W3DDFXfc+7Q191x00+2IXHajVffdWduVd1566yUVXnw/sndffm/K91+A AxZ44G37NXhaghNWeGGGG3b4YYgjlnhiiiu2+GKMM5bxYI7d1fhjkEMWGc6OSzb5ZI9HVtkglFt2 mdiVY5Z5Zpqxffnmump+F2eee/b55351FnroY4E2+mikk1a6WqKbdlrNpZV+emr/qs2NutCqa7x6 61Sz5ohrsMMWe2ywvc6YbLTT7tjsg9R2++1h2ZZ7brrrtvtuZeH2Ge+H9Pb7b8ADN5Vvwgt3WnDE E1d88bgMd1xkxjl+fHLKH4/8csxLqnxzzjtvNHPQQxd9dPs8N/101BklfXW/C2f9ddh5rjt2eVNP k3bcy7Z9d9579/134IMXnu/ci496+FeNnxR5PJV3/lTm/30e5+ir13V67BG1fnvuu083+629F3/8 jcE3/3z05SLfz/Tbd/99+Dldf/6C4rd/JPqRfT//Wu/nH9b7BfBb/7udAA3INeIdUIELDF/3GPhA CEYQaAQMlgQteEEMdo2CG+Rg2Qc9mKgMhlCEIyRhpD54whmVEGamUyG0xtfCQ00Oht1CYQ2/NkOs OVCBNiQZDmnoOhjysIM+JOLBhEiwIiZRiUtkosEs10Qo1ueI4ovisqZYvgde8YhVNKHvuJhELX7q i8674hiJGEYemlGNWURjG6e4xhm6MVaxk+MJ4RjEOnrwjnvkYx9RlkdAFtCPwvOjXQKZt0K27pCL FAkeGfkm7D1SWIlUnCQtyTvlXRKRlORkJz35N02Gkn2ZE2UpTXlKVALsk6u8WioZycrzuVKWs6Rl LUEGS1z+LSAAOw== ------=_NextPart_000_000B_01C770F9.F933AEF0-- From Engleson@airsonictravel.com Wed Mar 28 12:40:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWbCB-0006ZY-AR for geopriv-archive@lists.ietf.org; Wed, 28 Mar 2007 12:40:23 -0400 Received: from 130.197.203.62.cust.bluewin.ch ([62.203.197.130] helo=71-70.0-85.cust.bluewin.ch) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWbBw-00068v-KG for geopriv-archive@lists.ietf.org; Wed, 28 Mar 2007 12:40:23 -0400 Received: from pc by airsonictravel.com with ASMTP id B9E05B41 for ; Wed, 28 Mar 2007 18:40:05 +0200 Received: from pc ([148.158.120.143]) by airsonictravel.com with ESMTP id 44FB19F33BAF for ; Wed, 28 Mar 2007 18:40:05 +0200 Message-ID: <000e01c77157$b3df0760$47460055@pc> From: "roundrobin" To: geopriv-archive@lists.ietf.org Subject: Operating Browser Firefox Explorer Date: Wed, 28 Mar 2007 18:39:49 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C77168.7767D760" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e ------=_NextPart_000_000A_01C77168.7767D760 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C77168.7767D760" ------=_NextPart_001_000B_01C77168.7767D760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable They our surviving theories, tantrums. Gmail howto robotstxt torrents ubuntu onlineweb blogweblog toolsi. Gui boot savers winners. Tcollings homepage, ledgedes advance, hartford = ct. Enabling joining domaina risks removable! Protecting privacyyes peopleyes peoplei votedolder, polls. Muchbetter = scion willing, activaion asas, serevices thenm offagain sameeffect? Robert soon parade germany signers. Breibart reuters pol wired knight ridder, toledo blade. Blogazoo junkie = linker gravee megite tome! ------=_NextPart_001_000B_01C77168.7767D760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

They our surviving theories, = tantrums.

Gmail howto robotstxt torrents ubuntu = onlineweb=20 blogweblog toolsi.

Gui boot savers winners. Tcollings = homepage,=20 ledgedes advance, hartford ct. Enabling joining domaina risks = removable!

Protecting privacyyes peopleyes peoplei = votedolder,=20 polls. Muchbetter scion willing, activaion asas, serevices thenm = offagain sameeffect?

Robert soon parade germany = signers.

Breibart reuters pol wired knight = ridder, toledo=20 blade. Blogazoo junkie linker gravee megite tome!

------=_NextPart_001_000B_01C77168.7767D760-- ------=_NextPart_000_000A_01C77168.7767D760 Content-Type: image/gif; name="glory.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c77157$b3df0760$47460055@pc> R0lGODlhRAFAAYcAAAAIB38CBgF9AICAAAIMgYQAiQmIi8C1wcXYyKG+70AjAVkbAIYXBq4iALgl CdQnAAM1ABhGDj83AG4/AIs5DKRJCsRGBtg8AABbBC1gAUJeDV1ZAHpUAJZgDcNZAOBTAQCFABJ5 AEN0DV+KCoN3AJeDA8uMC+aFBACpACSdADWsAFiaCoCRAKKUAMStAOCiAAGzACbOAEvCAGvBAH7A AKSxAMjHDue2BADgABnoADLrAFnnAIHVAazRALrqAOLpAAAANCABTEMATWoAQHkASKoJTMUJTtoA OA0VPyEVQjMhRWErS4ArSpskS74rN98UOwBLRRZOQkA0NF06P385PpZLO8RGQ+5IQQBTMxhTR0Ra Q1hlQ4VfAKpjMcRgMe1dNAByMy2LPzZ6NmOFTXeDOKl7O797ROF3RAKlRhObOEWtQlqnRIijQK6s PrGRTNiROgDFTiXINje+O2y9Noy4OqCyMbvLN+CzRwDTPi7YNzvlNWzUTnvpQpPdTbPeM+PgMwAA gSkAe0kCjWsJjnoDiq0CccgHc+gAdgAkgS4SeksUelQthY4Xg5guiL8lcesghAAxjCAzfUg4i2M2 g45KdaFNd7pLcdRMfgBhfB5Wcj5ghlpfi4hueKJtdsxkitVdgQB3eiiMcjWDi2GKdICAdaWEfL2C c+V4egCadS2hg06ljm2min6tepKai8mTgtSagwDNhRu3hTO8iWbHcYyzf6axgLbFi+a5igDchh7t d0zRc23bcovThKPUirftg+vojAsAwSwItkUAsmIAx4wBtpEDwLsDstEHwQsovxsXxk4nwVsguHUX zJknxMQXyNslsgBNyBQ3vkxGxVwxvnZKvpJAyMxAu98zuQpgsyJmujRqy2hjwXVcu5pYtMhSy+ps sQ58wCJ0xzR+zGl6tYiCwp9/yM51s+h2vwCYuSCizDiUylaVvYSkxZKizL2szOabvAfLyxTEwDW1 u2XCyXvBxJXBwP/t8KiYmIaIifgMBwD4Bvb+CQgA//IA8QD9+P//+SH5BAC6oLkALAAAAABEAUAB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePC+2JHEmypMmTKFOqXMmypcuX MGPKnEmzps2bMkHq3Mmz5z+cQIMKHUq0qNGjSJMqXcq0qdOnUKPW9Em1qtWrWLNqlcq1q9evYMOK 1Eq2rNmzaMmKXcu2rdu3KdPKtQq3rl2Wc/Pq3ctX792/QfsKHky4sOHDiBMrFgy4sdHFkCMndEy5 MljJmDNr3jzZsufPoEOLbsw58ujTSkurjggTAADUpDG6BlBw9kbbBHE3nM3bdWHdA3vTzs1bIPDV eYHOLrmcpPCRBKKrbD6SOkvh1oV2jB69IL/v4MEb/8fuGzlf5a6dp1ffGzp36SeByB8pH8hM7o3b 06+/37695c/B9pdGugFXXIHYHYTbcQ4xmFF2N+knknXNkbeegBieRB2FFzK3Hm8mAdhhayNWWN4/ tiUYnHAKOoiQgQsiyKJ556H32n8dQlhdjiPiCOJM2Zl4o48W7ijhhEeuxCF2KemYIVsElgfjcC1S ieJxM0qEpZQnWijjaxsG2FKQTGrY45Nt3eabjAptaeV4J2oZ55XDfUnnnXDmqWdEU9bpoIttvknj YFni+eKcf84ZKJVu7hkjbWwaWihDUxInqIWUKjpoX4UCauieKwq6aKi1ccmoqZKiaqmmh1pZaank Lf/E6qZ7dRpnpHBeOmuVkDaaqp+9nhqsqJ7CumquBrFYLENo1vWjkTc+G2aPTk5XJrTSfpjetM8S WS172YpppLdnNjuaAugqYFK67Ko7UgDwxhvvSenSJG8AJ90L70j12lNvv/YsIPDAHnZr7ZH65ruv Pfeau1ZVvR2Uz8QU5wMZxbRmrJHDUhHM8cdAaWxVvCKXbHJfJJ+sckMgP/XAy1CunFbLNNds8804 56zzzjz37DNcSf4slgACCFWuSProcxcETDMtk9NMES2S1EKzBQMMQiWt0tV2aY200jDhgENTKKAw UtktUS0S2ixh4PbbLEHNs9o40W0S22/hvbbZL+n/bU/ZfE9NNN2DF82S2najJDZJbr/UeNqG7wx4 4CJdzfVLYi9ekuWX23N5538DPlLTcp/tt+egp3Q63oVHLhLpEJDEdeetj9T440oO2eHbGHio3ktH l1R6ZRtBAcU/xhMk3z/LO0T0P88TFH30/1wtkPXjXUlqnEz/0/1Az1Of0PcEkc85DARhjz30AghE fffki8/Q9+Sz7377KxKUfINvRgw+/jLTXpzAAAaJEPAfBxxI85gHhGPd74ECSWACEVhAg0wPgAlZ oAIbGMECTvCDFaQgAUPIwIPUx3mFK1X2Nkich0wwTyd6ocomxZ2HFKo7AsFhDmu4whPhUIca3OAJ /xkSxBLu0CALXCAPiZMS+KwEGMCwBxRLMkUpRtE9JJmPS7SIRXs4kYuW0QgUBzLGghQRIWX8RxrX CAyCvCd/2hPId+TIDzgayyE6PCILvVNHOsKxS6ISyBkN8kMCuNGQ/8hjGv8xR4c0ciCFhCQiF4Oe 35XEiSr5Dkk0KRInYtKLBMiif7hYxSqCspOhRJIqWcJFMOLIJKY0JZE2yY8QfYuWI+HkKXe5yl5e Z0irvFDw7vIgV1HpjQ3JYx4nhSj/RTJUb0JmQ6BITUJOkiDUrKZCmmIwXb7SJSPSoiurRk40deiT KBGTtnYEmgC6853wjKdEyknPetrznvjMJ1zkmf8xfRaFnwANaEX8SdCC/kygCE2oPA26FGBOSElE OZpDjRI0ryiULhEKEVTANNHHvOiiMsMJvkgy0qe4y19dWYBFQSoZVxEkZQNxQEHgZRB0OSQALy2I AgqCMYHs1Kb/2OlAhNoQixFEpg6QaUFexhqGiiUjOBVIVAWi1H9U9R8LIIhRjUrVrjKkAQUB60Cm +o8HCMSsPv2pVHPqkKy2EEUEEatYO+LU1GCEqET9B1e5+o+pknWsgGVIXoNKELT2NbB6FQhXlXpV wRbErVgNDktVExR1nVQkDxhJZkfiAM3Sy1+XVUlJRTLazopEpad9l0kaIBLWviQfzKkOv+razoz/ qLWwAzEsXNdqEKY+ZLB5nSujcnuQpEYEsgJhwECUe9bJCpS5bD3sUAcCAeou97qUyo1Op+tTydZ0 sI49akytK5DqGoeutP2nRqBLEAq4tyDsdS8FCvK2h5DOIOYVCAf2+w8OlBch/uWfbvKb338w4MDl g4w+EYoC54KUnmDrioMnnJYGUzih5YxdejfM4Q57+MMgbsmFRxzSEJs4NCw9sYpvQs0Vh7gj/oPx rhiyRBLbmCLvkaaaAilgivBHlP5xz3vGlZIf98fFHi0mjzVSYzktWSFDFOKqvqQpX6kFyekcJlDw U5NbNolHwAQRtwzmIyJj2S3V4jIqUymiI10L/1wT9XKRWwnGFpspWhCys53P3BbysOfP5FLnmwN9 SUzKucxIGpKabRnmEeFn0Xxmi5+JPOZriXlJszQzon+J50Z3NNEjoVP/YnzjzRRHT3ZKESCFRSpQ LSshj2p1q+4IzRlbJNJDWRKmyzwtM/da0zJpM7ALRuyCfforpbZhM415alSvadWyxtWnnPwqgTC6 2NjGtVjC5VCDCWnTQtJdmz1tE3HtetOZBjRJkp0YTMFq1MD6FalFbeVpL6pPyHJUot6k7W1XFN2g 5rUwxYWtaw/7YHF+c5EM3m/PHPooD8/ymSo66IM3nCZXacBc2c1xnTxlXhfvt1V62vGJhDwpAv/D WckTc/KWuxw1K4/5yjgs85rbXCdNu7nOBQO4jmSuIJkLutgu8nKlJO3oEY7b8KAyudPZg3e9awnn SgJ13u28LDYiM0pEJ5XzTZ0kQtecQiZnQfldHTODY5/Z8+J19CVLVQkJ+kFal7ii91lbx/Y3RxM+ 8Lw7Keyas/tbmvY6uY3w8CMZofBIZxKvl8TIBwM4uqsFu+ER3h6MFzxRMnLC+nCQgZ7/PHAOP0Ll hV6DaWcI6Q9PkNIPxPUmPP3nRfh6GW5E8+UWVzb3vGhhH9kekJeJ7IN8bpMYOfhATsrZeXJ6Y+HK RTXMMUZ2X8ZqIzGJg7T38n1iI4mfZM9Okn3/UFps5+JTMZayzDbucaJkhIjn7ayOfZTb/yhg8djz oP/8+9+//asAZc/nd0UBOBLZZEUCmC3qFnmWhncJqHAVt35f4SQ6Yh05ZmhvBh5jsnAiMXwJ6C0m UYGO0X+0NoJktEj0Bn+2JisqMmVPJoKFwTMRB4HrF4NP5YJNpTM0KINpYoMesX48+INAGISbcXFC WIRGqBg6mISR9lcyg1zw5GGh9RK3sRCNpRN89YQ4YVr2oIWktTAMM1oiAVsjIYYr4VpAAYY1sVk8 g4Y7kxFztXFRNVVI1VhopVtUAV4RIS8aMTA6lVckt1uASCV4yBEVc16GKBB8GFkCkxlXOBBA/3FS J8WFnoVZJGFakpgSqPWINmGGrqWG9uCJKJFUplVSpEhaIgGJnDVbp6iKQiGKD/WKpRiGsvhNwKRx JAEwCAcVZmgUmaWGl0iJk/hQeVeJJKFxu6gSAJOJL6OGIDcSHqOGm8UAIyGNLIEvI2WJzrgu9kBY A7FxSIVb5zUnQBVeQoVX00VUkOVWhmVYcnWILQhd7LWMvLVWZlWHcaVxxOVbfUVTUkVTQdFZWhiF q8iK39QSJSWQKeEuqLiKCsmK1PiQ06iKCBlb7+KF9kCNt4guJcGF1ugc7PQfEskSGEmNWqiF0oiR JTmQKAWSJdGQLJGSIoGNW5iKWwiQABmTNP+pkSu5k2x4E7GjYSxpEhh5kcLzEqM1jKOTlK8zEhRA EhApEk0JlSIxkrKFlK8olVgJlBqmlUoZkSQRlfYAllHJlaF2EASWXNj1X+TlPQIxX22JlgWRcw1x loE4EAEWYMyVl2/5D24pXX6JAdGlEdWVXy7ljvQFEYCZYAyRmP/AmIyJQfU1EBb2D5NJdtRVYAqB mcAhlwLRc941EIx5iI6plmy5EJUJmpHpPgXRcw12mo0JmqSJmWZJXq7JlnRpXuaVep0pmbCpmEIB lIVXOplHEq4TNyYBnChBlk83ElgzEpFjOM3pOSuBnCpBnUdBEK45XIvpNq8pY1aSmpnJmXT/KRDc uZuUaZ7aOZ5uRxCAORqXxxKZYw9jI52VUxJcVzmzoxLzCTSyFZzWSRlRt3g/yZwkwTcG6pyI45wE GpwqFqCe8Z+OYZVro4QmAYiKsZ6RgUGZeYSb8nMiE5ocGqIi6n+iAQZIYaIUumKpZBRBliFYMXsj +lEg0UY6kUcWkYIEERUrGnnJt4FaFEqYhHweeRmyghaGZKMQEWXNVm2vlkgc0SsyCklR0oIWGqXH lENkpEaCxEEcRKNaGqWC0Uc7oZ148kPTtEhHKhBeSqNkmqZVyhBe+iCfqV0EIaY3aohQOhDhkV2A OEmTVJi7RaNxGmtFWieWIqXL1CV0mhDa/6R9ETFE2nlNXzqpsPaZgDocXKo8BSGpsLakccJ/CnFN kgopboQTK8pm0XKVSEkh/RmUwEcfAXeVsPpLr5Sqr/ghGzirujMmrTpRfBKoWXqIToqlRWqYlrpD ksqpVCqsbTqsxcqszIoTu+pF0NFJ1boSp6qqrRqUtsqtFLkSo5SrUkSA2vqq5ioSVySA0zGr50oT Lao7bnSsC+Gnc6qdZEosDbKoZMqnzGogsuFd9jqnCVFjKQKth9hkVsKpCoKnxmqvc+Km/LqvE3Gp m2qsbSKv0CRrFtqkG4uxEauvi3qja1KXJGsWEiujhkqyAduvndGr2wokxharwaZlShFmLv8LTkEy pP/xEffKsTx7K7vBsI5iqYhiQ4d6EcuKGfAWshNbGwK7fbSRolIrq1MbE9uns1WbtVrrEjHatQ+R opOFo4gxjgv7UvzYEBvnYEl7Fkw4EYOoEG2LXjehUil3EpIohmRYGT05E3m7EhMxVXbYEFWIEG/L EOmYEYO7EIW7MTiRiZk4W5flkiwRuTq5g3OxtsnSE1MlKjAFt3o4VmebMulCGICaWKarWKhbVNyl bC1oMVtFa2QFHPLIEFWFU2erWHwliqBLVp/rl/s4Va67VxMTtN1Ftp06HGCFj15lVQ7RWHEoEGn7 pnvBuwTBLgSRiMQ7j3zagjbVvQA7Xt3/Fb5wRaVExY/Am7qJZVRVpVTmiIiIFVXDe7pxm7lpJb4K QVRS0lxl9RBk1b7MG5ggARRcqIXQSBK9aJQtyatUexKb1cDA+ImqVa4QfBIHMVeH+78YrFspW7Ll O49vSFwNAVknexCQ5VdptbhLBY77i1jcOBjwKF7gu1vLKpuyWVOrmxB6aWBwqcPL678ovJba6b9W MroxXFV4Rbb3mq+xKbhFvLyJa8NNTBDQVcNyaxPyBZYMUxIlJZYtoZVLdxLKmRIjNcZT6ZVBqZxD uRIYSZZ92ZehSZdt/Jm3uZZUTL+leccK8cI7zLF92ZbvNV8HFl82Vl8gahCJecj/0z74/zOZjVme 5Gm0S0yeqcnIlFk27Jmaoakbo/nIBZGctvPJh6OgU7O1QhGdTrGfNei1kVHHIIG5qqxQlLwTnvnK B0HKtnzLuJzLSAYZJFQWvcw8FmF7DgGjwsoXxLwXx7wayVwWnLrMjogSO9oSP9ailDEk6noS0fwU 1AwTVYF/2GSC7hes4/smj3SxMlyCcYpEBpHOEMHObfKK2Tyu6GpFbRHPbrHNT0EdtZRL1trP1PrP HKUhvdqt4fpE8yzP0wpKKypuNDtmLZHNAd2q8LGikPdr4GquLVrR1BHNOVKV5LZFP8pLBnjN3HwR 9KqmKE2sw/p5HJS/W7pAYrqy0lux3f9x0s5KqkI70yD7tAhxzGXkpUmsss+8z/ZA1F9WqwctzwJ4 gFkkrtxqq0Rt1E3Uz6Xk1PjcFKkUzd40rVzdnwn91RLcJEid1AIo1d2KlEuNteuqUVdJ1F3tqura rWttq1l9rf/srWyN13V9Hf2Zred61SJ2EfO3QnKkpw3rXTZ9pcQ6wpmL0yUbTRZbqQZLY52M15bd aXl9aLaK2Tdr2Trr15rdn1Htz/Yc2Hd6iIKasdsj1Bbbsym4wa7mtJPqzrLdsckUryXL0gqU0mpE kX4917fq1a1KfJ391q6aTsId3AsshbKhqIidvRvsyq78rO74asehsK1yTHbNaZomZ5v/3d0bQhK9 V9w0y2uXnYNjQRXTnW+QXMW6bFc+sd4TK7a0rGDvjXv1nd/PfN8lod/+/d8lJ98fQcoSSjz/KlCY K+ABbFKAsbdEUVIFHjJU0bla0hBT9cODguFm4YQ6QVRzSBKP6xl4O7mVO4YGSZCwYR2uGIYUwy8l vozOWLcuwxTG2Fqu5VpmAVMU/lXQe7Q53WwJYYxrdbtEvBC2y7uhy1tThb1yeoi39cEtTFSuW8y0 a1z9KIdWvhBZtYg93uX1OxBMrhDs2I037LMGgVMR7DGzSIYdCRMOrJLuMq0LCVEsPotznhJJhZM7 6S433lqmWKFI+5l51b6wPVjRmxDP/9vjYrVXmWKIJqzkToy2q0tUc/XEECHTw2FU9sDmQNIhkuu4 YZ0SZvjWVsmJA3lSAW2z/X0R6wvmKoxWRa6/cRXCri7r3PjD7buO85jo82ttD1zAeq6SNiGT3RqL ExwTbW7ju7iQoM4SZhiLK84SwK7iNTmTxbjqFuG/7IXpaVm9DKHHvqu7c0lej97q3lM/CwFdQR3D FfGNoOLDfzuP5m5VxiVTjF3bc0yakr1b8H5bMLwR8tVeccmZAc/CnGnOgFhg4D4+5MXtPPzwlf2y QjnxPgmUCS1fYYmVTNkSVCkScKMSV9wSYHnx7nXifz55shrI2K60I3ue5YPuCDGe9//F3u+ZUR6P OzZRnPf5YqWmodsEFqjM309COX8BoX4L4Bm6dlnRN0Lf9P7EcfRdhArOLFVjyqasEnDAFVcPGqYc ZMUZHzex9fQp4T7hzBwRQr0cZcKcqcOsFb+MQEq729Q9EW+/GGa/EWuqqcAsSEYk93eff7PXZHr/ ELK39wrRqBmk99cNRNnn93yv0s6K3bhdEd4M+X1/gyymrmoGad4nErXkTSrx2/gcZNQcRSQ91eLt z0ZW2ith1BF9laxPReT617NK+u2KEuma1MDE1LkDZgoclOq6z1LtFAUN1iyR1rToEqYv8bLaaHFh x5H/+JIk+aH6VvtK/QWR2l8K1J//if27vTyzZyWi97GzTf59KqVYsbKlu++YKvfZxdjr//fu/9jZ 72M7XaXL6tiIv+6F6ti2DRD/CPwjWNAgQQAFE/5buPDgQ2AFIyJUWPHhRYwZNRIcyBEhAIceN/4D UrAkQ4sjB3YkiTFkyJMjU7YkGFOgwZAyZ078xzMnypH2gAGzVxRIUXtH7QFAyrSoU6RRpS6lCtUe v6hEn06dSgCp16UguXLVKhQp1q1px65l27bpW6pqra6F6rSu261QwRbdqzSp1L144zYVa9XvXMFm 4Q6uK1Yw2q8EAkv2CjZwW7tSDS9euxfsXcwgrY4Wzbmtzo2iHQ7leVOmaImxdeZU/40TNmrctl/m /qdW8W/EiYMnJo4ZadnOlKMqL972cnPomqNPp14d72uDLEf+5J2Re3fw4cXn/j4ed3nz6dWvZ3/Q +nDr8eVHLx3d/O32+fXv59/f/3//5hNwQAILNPBABBNUcC0AG3TwQQgjlHBCCiu08EIMM9RwQwsX 9PBDEENsjkMSSzTxRBRTVPEiEVt08UUYY5RxxqhWtFE8GnPUcUcee2TwRiCDFHJIIos08kgkk1Ry SSabdPJJKKNs0kcqq7TySgKl1FImLLv08kswf9ySxDDLNPNMNMcac002p0zzTanalHPOE+G08048 89RzTz4VpJPOPrH8c1BCKQz0UP9E7yx0UUYbdbTDRLN8tM1IZ5z0Ukx5q3RTTq/M9FNQM+rU0lBL NfVUVJccdVVWv0x1y1ZjlXXWHV+19VRac0XqVhZ19fVXYIvitbdgcx32WI2KbRVZZpt19lkJlfUQ WmqrtZYgabPV9lojtS2OW3CD9HZcYMOtkFx0FzR3XXbbdTe8dHV0Nl5667X3XnzteXdffsnMd75+ AwbwXysFNthBghPO8+AGFf6WYYwcdhHiDR2mODeJM9Z4Y447LvBikEMWeWQcPTZ5W4hPfphkjFV2 +WUQWY4QZjFl1pTmF/fFeWeee9YzZJ+DFtpTW4c2+ld2j1a6Ops1rLdpqKNecek1k4GmWl+ps9Za VI+39jrFjL829GqfdSb7bLdYRntttu1rt224pxJ77pvPptvmuIlLOe+2AwIAOw== ------=_NextPart_000_000A_01C77168.7767D760-- From geopriv-bounces@ietf.org Wed Mar 28 15:29:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWdow-0004Hr-WC; Wed, 28 Mar 2007 15:28:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWdow-0004HK-6J for geopriv@ietf.org; Wed, 28 Mar 2007 15:28:34 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HWdoq-00064l-OE for geopriv@ietf.org; Wed, 28 Mar 2007 15:28:34 -0400 Received: (qmail invoked by alias); 28 Mar 2007 19:28:24 -0000 Received: from ip-90-186-88-144.web.vodafone.de (EHLO [90.186.88.144]) [90.186.88.144] by mail.gmx.net (mp039) with SMTP; 28 Mar 2007 21:28:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19xRUZrl9VxuYu9v/Zigk2sgu9l/SeHsKlYVDmrgt LBghMi5XIVE3Q/ Message-ID: <460AC1D6.9080304@gmx.net> Date: Wed, 28 Mar 2007 21:28:22 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: GEOPRIV Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Geopriv] SDO Emergency Services Workshop: Reminder X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi all, a high-level agenda for the workshop is now available and the agenda will be updated frequently: http://www.emergency-services-coordination.info/2007/agenda.html Please do not forget to register for the workshop (by using the EDAS system as described at http://www.emergency-services-coordination.info/2007/, Section "Meeting Organization"). The size of the meeting venue is limited and for safety reasons we have to limit the number of participants. Hence, we may need to enforce a first come first serve policy. Best regards Jenny Hansen Marc Linsner Stephen McCann Christian Militeau Atle Monrad Henning Schulzrinne Hannes Tschofenig Harry Worstell _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 28 20:54: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 1HWiu8-0006e4-0h; Wed, 28 Mar 2007 20:54:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRMv5-0003JY-Cv; Wed, 14 Mar 2007 02:25:07 -0400 Received: from [2001:858:745:a0e4:20b:dbff:fe95:d83a] (helo=sil1.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRMuy-0003AJ-NQ; Wed, 14 Mar 2007 02:25:07 -0400 Received: from [81.223.16.197] (helo=[192.168.1.47]) by sil1.mah.priv.at with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1HRMuk-0006p2-5U; Wed, 14 Mar 2007 07:24:46 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0776CCB1-730D-438D-A89D-E92B8B31A917@mah.priv.at> Content-Transfer-Encoding: 7bit From: Haberler Michael Date: Wed, 14 Mar 2007 07:24:40 +0100 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.3) X-SA-Exim-Connect-IP: 81.223.16.197 X-SA-Exim-Mail-From: ml1234@mah.priv.at X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on sil1.mah.priv.at X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7-deb Subject: Re: [Geopriv] RE: Strawman Proposal X-SA-Exim-Version: 4.2.1 (built Wed, 07 Mar 2007 15:40:54 +0000) X-SA-Exim-Scanned: Yes (on sil1.mah.priv.at) X-Spam-Score: 0.5 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Wed, 28 Mar 2007 20:54:07 -0400 Cc: GEOPRIV WG , Marc Linsner , ecrit@ietf.org, Henning Schulzrinne X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Am 14.03.2007 um 00:29 schrieb Dawson, Martin: > > Secondly, one of the things that emergency services don't concern > themselves with in responding to callers is whether you really are the > individual they claim to be. Anonymous emergency calling via public > payphones, SIMless mobiles, and any other point a caller can lay their > hands on a device is an accepted feature of the service. just noting SIMless 911 seems to be not universally accepted - Switzerland explicitely denies SIMless emergency calls in Austria recommended procedure for mountaineers is to remove the SIM before the hike to get better coverage for 140 (mountain rescue) downside of this is - Vienna police gets a surge of SIMless 112 calls every saturday as stolen mobiles are tested for functionality on the flea markets by calling 112 more relevant (possibly to ECRIT towards PSAP contact publishing requirements) is - Switzerland publishes *routing numbers* as PSAP destinations which are meaningful only in a national interconnect scenario -Michael _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 28 20:58:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWixr-0001Ov-Pp; Wed, 28 Mar 2007 20:58:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRP4m-0004y3-Oq; Wed, 14 Mar 2007 04:43:17 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRP4h-0004Jn-4X; Wed, 14 Mar 2007 04:43:16 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3587820467; Wed, 14 Mar 2007 09:42:54 +0100 (CET) X-AuditID: c1b4fb3e-af9eebb0000061ca-e6-45f7b58edd40 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 16582203C2; Wed, 14 Mar 2007 09:42:54 +0100 (CET) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 09:42:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Re: [Geopriv] RE: Strawman Proposal Date: Wed, 14 Mar 2007 09:44:52 +0100 Message-ID: <0074F19FF6F8534E8F74C56BB84397BBB0C61D@esealmw118.eemea.ericsson.se> In-Reply-To: <0776CCB1-730D-438D-A89D-E92B8B31A917@mah.priv.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Geopriv] RE: Strawman Proposal Thread-Index: AcdmAbrVKswpGhPET36uGRpMxiVTdQAEdaPw From: "Raymond Forbes $CV/ETL$" To: "Dawson, Martin" X-OriginalArrivalTime: 14 Mar 2007 08:42:53.0436 (UTC) FILETIME=[C1746BC0:01C76614] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-Mailman-Approved-At: Wed, 28 Mar 2007 20:57:58 -0400 Cc: GEOPRIV WG , ecrit@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org =20 We have had similar discussion in ETSI many Times, I can confirm that Currently, Two Countries mandate by law that SIM-less Emergency Calls Shall be allowed. In Germany these calls are still traceable though the Mobile may not be uniquely identifiable, as a dummy CLI is allocated to the call, the actual Mobile Equipment may also be traced as the IMEI may be sent over the air. In Austria I am not aware of the solution. In the UK, Eire, Switzerland, and increasingly in other EU countries; SIM-Less Emergency Calls are forbidden as the Mobile traceability is mandated by law. In a number of countries like France and Portugal that did allow SIM-less Emergency calls though not by mandate the laws and systems now (or soon will) forbid them. The reason for this change is that the Emergency services were flooded with Anonymous calls from second hand traders of Mobile handsets.=20 Regards, Ray Forbes Ericsson Limited BU Networks (CV/ETL/BBC/D) Telephone: +44 (0) 24 7656 3106 Mobile: +44 (0) 771 851 1361 Email: Raymond.Forbes@Ericsson.com Registered Office: Unit 4, Midleton Gate, Guildford Business Park, Guildford, Surrey, GU2 8SG. Registered Number in England and Wales: 942215 This communication is confidential and intended solely for the addressee(s). Any unauthorised review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.=20 Ericsson Limited does not enter into contracts or contractual obligations via electronic mail, unless otherwise agreed in writing between the parties concerned. E-mail including attachments is susceptible to data corruption, interruption, unauthorised amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.=20 -----Original Message----- From: Haberler Michael [mailto:ml1234@mah.priv.at]=20 Sent: 14 March 2007 06:25 To: Dawson, Martin Cc: GEOPRIV WG; ecrit@ietf.org Subject: [Ecrit] Re: [Geopriv] RE: Strawman Proposal Am 14.03.2007 um 00:29 schrieb Dawson, Martin: > > Secondly, one of the things that emergency services don't concern=20 > themselves with in responding to callers is whether you really are the > individual they claim to be. Anonymous emergency calling via public=20 > payphones, SIMless mobiles, and any other point a caller can lay their > hands on a device is an accepted feature of the service. just noting SIMless 911 seems to be not universally accepted - Switzerland explicitely denies SIMless emergency calls in Austria recommended procedure for mountaineers is to remove the SIM before the hike to get better coverage for 140 (mountain rescue) downside of this is - Vienna police gets a surge of SIMless 112 calls every saturday as stolen mobiles are tested for functionality on the flea markets by calling 112 more relevant (possibly to ECRIT towards PSAP contact publishing requirements) is - Switzerland publishes *routing numbers* as PSAP destinations which are meaningful only in a national interconnect scenario -Michael _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 28 20:58:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWiyY-0001uL-BP; Wed, 28 Mar 2007 20:58:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRPdv-00034d-1O; Wed, 14 Mar 2007 05:19:35 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRPdp-0002Bf-6T; Wed, 14 Mar 2007 05:19:35 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9B3C5214AF; Wed, 14 Mar 2007 10:19:24 +0100 (CET) X-AuditID: c1b4fb3e-ad9eabb0000061ca-1b-45f7be1c2c4c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 81181211EF; Wed, 14 Mar 2007 10:19:24 +0100 (CET) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 10:19:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Re: [Geopriv] RE: Strawman Proposal Date: Wed, 14 Mar 2007 10:21:17 +0100 Message-ID: <0074F19FF6F8534E8F74C56BB84397BBB0C685@esealmw118.eemea.ericsson.se> In-Reply-To: <45F7B867.4040603@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Geopriv] RE: Strawman Proposal Thread-Index: AcdmFnf/CJIratAFRwGotgpeuuwAaAAAKSGA From: "Raymond Forbes $CV/ETL$" To: "Hannes Tschofenig" X-OriginalArrivalTime: 14 Mar 2007 09:19:18.0710 (UTC) FILETIME=[D7FAC560:01C76619] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 X-Mailman-Approved-At: Wed, 28 Mar 2007 20:58:41 -0400 Cc: GEOPRIV WG , ecrit@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org =20 Hannes, Currently By analogy with the GSM Regulation, The German and Austrian Regulators Demand Unauthenticated access on Publicly Licensed networks. The Private Corporate Networks (CSP IP access; in the IP context) are not subject to this regulation.=20 This will be confusing to the IETF as they do not differentiate between CSP networks and ISP networks. In their relationship with 3GPP the IETF considered 3GPP network as Private Enterprise networks. Some Private Enterprise Networks are nationally Licensed to Sell services to the Public (T-Mobil-D1 or Vodafone-D2), and subject to regulation [they must provide unauthenticated access, but authorise its use with IMEIs and Dummy CLIs; analogous to P_Asserted_Identies in Validated in Proxies], others Only provide corporate access (Siemens or Ericsson) and have a closed community and less or no regulation in this context). Germany and Austria are the only countries that mandate Unauthenticated Access you may be closer to what their governments are thinking about IP access In Other Countries the regulation may be exactly the Opposite un UK, Eire, Private Enterprise Networks are nationally Licensed to Sell services to the Public (T-Mobile-UK or Vodafone-UK), and subject to regulation they must forbid unauthenticated access. You do not need to consider the case of Corporate CSP access, But Publicly Incensed Enterprise Networks. In All cases calls have to be authorised calls to allow traceability. I am not sure that this helps except to say the technology need to provide all cases, except unauthorised. Currently the only Authentication Provide on VoIP Emergency calls is to the ISP/CSP access using Radius or IPSec. Regards, Ray Forbes Ericsson Limited BU Networks (CV/ETL/BBC/D) Telephone: +44 (0) 24 7656 3106 Mobile: +44 (0) 771 851 1361 Email: Raymond.Forbes@Ericsson.com Registered Office: Unit 4, Midleton Gate, Guildford Business Park, Guildford, Surrey, GU2 8SG. Registered Number in England and Wales: 942215 This communication is confidential and intended solely for the addressee(s). Any unauthorised review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.=20 Ericsson Limited does not enter into contracts or contractual obligations via electronic mail, unless otherwise agreed in writing between the parties concerned. E-mail including attachments is susceptible to data corruption, interruption, unauthorised amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: 14 March 2007 08:55 To: Raymond Forbes (CV/ETL) Cc: Dawson, Martin; GEOPRIV WG; ecrit@ietf.org Subject: Re: [Ecrit] Re: [Geopriv] RE: Strawman Proposal Hi Raymond, one issue that is quite important to me is whether regulators will demand * "unauthenticated network access" for emergency calls This means that an emergency caller can attach to a network even though it does not have credentials for this network. For example, someone might just use Ericsson enterprise network (or my private WLAN DSL home network) for an emergency call. * authenticated (but unauthorized) emergency calls where some form of authentication of the emergency caller needs to take place. None of these two aspect directly correspond the concept of SIMless emergency calls since the credentials for the two mechanisms are typically different. So, it remains open what it means to have SIM-less emergency calls on the Internet, from a technical and from a regulatory side. It might well be that the trend for a more restrictive user identification makes the entire subject irrelevant. Ciao Hannes Raymond Forbes (CV/ETL) wrote: > =20 > We have had similar discussion in ETSI many Times, I can confirm that > Currently, Two Countries mandate by law that SIM-less Emergency Calls > Shall be allowed. In Germany these calls are still traceable though the > Mobile may not be uniquely identifiable, as a dummy CLI is allocated to > the call, the actual Mobile Equipment may also be traced as the IMEI may > be sent over the air. In Austria I am not aware of the solution. > > In the UK, Eire, Switzerland, and increasingly in other EU countries; > SIM-Less Emergency Calls are forbidden as the Mobile traceability is > mandated by law. In a number of countries like France and Portugal that > did allow SIM-less Emergency calls though not by mandate the laws and > systems now (or soon will) forbid them. The reason for this change is > that the Emergency services were flooded with Anonymous calls from > second hand traders of Mobile handsets.=20 > > Regards, > > Ray Forbes > Ericsson Limited > BU Networks (CV/ETL/BBC/D) > Telephone: +44 (0) 24 7656 3106 > Mobile: +44 (0) 771 851 1361 > Email: Raymond.Forbes@Ericsson.com > > Registered Office: Unit 4, Midleton Gate, Guildford Business Park, > Guildford, Surrey, GU2 8SG. Registered Number in England and Wales: > 942215 > > This communication is confidential and intended solely for the > addressee(s). Any unauthorised review, use, disclosure or distribution > is prohibited. If you believe this message has been sent to you in > error, please notify the sender by replying to this transmission and > delete the message without disclosing it. Thank you.=20 > > Ericsson Limited does not enter into contracts or contractual > obligations via electronic mail, unless otherwise agreed in writing > between the parties concerned. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorised amendment, tampering and viruses, and we only > send and receive e-mails on the basis that we are not liable for any > such corruption, interception, amendment, tampering or viruses or any > consequences thereof.=20 > > -----Original Message----- > From: Haberler Michael [mailto:ml1234@mah.priv.at]=20 > Sent: 14 March 2007 06:25 > To: Dawson, Martin > Cc: GEOPRIV WG; ecrit@ietf.org > Subject: [Ecrit] Re: [Geopriv] RE: Strawman Proposal > > > Am 14.03.2007 um 00:29 schrieb Dawson, Martin: > =20 >> Secondly, one of the things that emergency services don't concern=20 >> themselves with in responding to callers is whether you really are the >> =20 > > =20 >> individual they claim to be. Anonymous emergency calling via public=20 >> payphones, SIMless mobiles, and any other point a caller can lay their >> =20 > > =20 >> hands on a device is an accepted feature of the service. >> =20 > > just noting SIMless 911 seems to be not universally accepted - > > Switzerland explicitely denies SIMless emergency calls > > in Austria recommended procedure for mountaineers is to remove the SIM > before the hike to get better coverage for 140 (mountain rescue) > > downside of this is - Vienna police gets a surge of SIMless 112 calls > every saturday as stolen mobiles are tested for functionality on the > flea markets by calling 112 > > more relevant (possibly to ECRIT towards PSAP contact publishing > requirements) is - Switzerland publishes *routing numbers* as PSAP > destinations which are meaningful only in a national interconnect > scenario > > -Michael > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > =20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Mar 28 21:05:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWj4t-0003ia-9k; Wed, 28 Mar 2007 21:05:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWZsS-0006lA-NS for geopriv@ietf.org; Wed, 28 Mar 2007 11:15:56 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWZs3-0006hv-LL for geopriv@ietf.org; Wed, 28 Mar 2007 11:15:56 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l2SFFS1f084945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Mar 2007 09:15:28 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.3) To: geopriv@ietf.org Message-Id: Content-Type: multipart/mixed; boundary=Apple-Mail-3--780769068 From: Robert Sparks Date: Wed, 28 Mar 2007 10:15:26 -0500 X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4eaba8a3f66804313fcc9b62b5e6d8a8 X-Mailman-Approved-At: Wed, 28 Mar 2007 21:05:13 -0400 Cc: Andrew Newton Subject: [Geopriv] Notes - geopriv@ietf68 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org --Apple-Mail-3--780769068 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Here are the raw notes/draft minutes for the geopriv meeting at ietf68. Attached in pdf and txt form RjS --Apple-Mail-3--780769068 Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-unix-mode=0644; x-mac-hide-extension=yes; name=geopriv-minutes.txt Content-Disposition: attachment; filename=geopriv-minutes.txt Topic - geopriv 68 - minutes - Thursday 3/22 9am - Notetaker: Robert Sparks - Summary - The group bashed the agenda to focus on l7-lcp. A series of hums confirmed that the group believed it was important to produce a single HTTP based l7-lcp solution. After hums did not produce a clear consensus choice between HELD and RELO, the group agreed to accept a plurality decision to move forward with the HELD document as the basis for continued work. - Steve Norreys volunteered to edit a document separating the On-Behalf-Of and Lis-to-Lis requirements from l7-lcp-ps - It was noted that elements in the Identity Extensions could be separated from the HELD documents - Raw Notes - Agenda Bashing - brian rosen - rearrange to focus on l7-lcp, don't talk about location signing (agenda so adjusted) - Document Status reported - jon points the group to the LC in SIP on location conveyance - pidf-lo-profile will be revved after meeting - Future Directions - Cullen Jennings - urges group to focus on making decisions around the analysis done so far. - LCP oriented polls: more than one lcp protocol? More than one l7-lcp? Will there be a SIP one? Will there be an HTTP one? - More than one lcp protocol - Brian Rosen - we made this decision - there is no one-size fits all - James Winterbottom - we have a WG requirements document for a new one - James Polk - There is already more than one, but there doesn't have to be more than one in the IETF - HUM: more than one ietf specified lcp protocol (in addition to LCP): - Strong Hum in favor. No hums opposed - jabber scribe reports strong support in the chatroom - SUBSCRIBE based approach using SIP - Brian Rosen: Each new option adds to the set of things each phone must implement - Rohan Mahy - I though this wasn't LCP, but was a general fetch mechanism for location information - Jon/Henning: (clarification that taking this discussion in the context of LCP doesn't constrain the general use of SUBSCRIBE mechanisms) - Jon/Henning: (can separate discussion into direct retrieval and mechanisms that include indirection) - Keith Drage: We had agreement that phones will have to implement all lcp protocols - earlier discussion that we're just creating options seems to go against that agreement. - HUM: Do we want to specify an event package that a target can use to subscribe to location (direct or indirect) - In favor: Strong - Opposed: None - No voices from jabber room - (non exclusive) Do we support a direct mechanism - Peter Blatherwick - are we talking about trying to change existing l2 mechanisms? (Room answers no) - HUM : Do we support a indirect mechanism - Favor : Strong - Opposed: None - HUM : Do we support an direct mechanism - Favor: Very faint - Opposed: Strong - Jabber room: some support reflected in favor on the jabber room - (Strong room consensus against, 13 in the jabber room for, but see note on delay) - Discussion: the delay on the jabber room may have confused the inputs on this hum from the jabber room. - HUM: Pursue extending existing l3 geopriv sponsored solutions w/ subscription (extending protocols like dhcp to support subscriptions) - Favor: Strong - Opposed: Some - Chairs: Consensus in Favor - HUM: Pursue solution for indirect lcp through layer 7 mechanisms - Favor: Strong - Opposed: None - HUM: Do we pursue an HTTP based approach - Favor: Strong - Opposed: none - (Long discussion on quality of reviewing requirements around dereferencing mechanism protocols ) - Kieth - urges us to make sure we're building towards the right things - Ted - confusion may stem from whether mechanisms are mandatory to implement - Henning - these hums are intended to prioritize work - HUM: Do we have more than one dereferencing mechanism (at least HTTP) - Favor: medium (clarified and repeated: strong) - Opposed: none - l7-lcp - discussion of document status - discussion of reorganization of document - discussion of obo and ltl requirements - Cullen: Privacy and Integrity need a viable story on these items before it could be brought in as a working group item. Its not clear that we can build a protocol meeting the OBO requirements - perhaps they should be pulled out and reintroduced when we're more convinced we can meet them. - Henning: Do we pull this document back for more editing and discussion? It's in WGLC now. - James: In constrained environments we feel we can meet the requirements. - Cullen: Difficult to pass documents that only work in specialized networks. - Henning: Delaying this document much will make it irrelevant - HUM: Do we keep obo and ltl requirements in this document - Favor: Strong - Opposed: Strong - chairs: That wasn't conclusive (15 in favor from jabber room) - Rohan: Could we put these in a separate document? - HUM: Would anyone be opposed to putting obo and lts requirements in a separate document - Result: no opposition - Steve Norreys volunteered to edit this separate document - Choosing an l7-lcp protocol - Presentations - HELD - Identity Extensions - Rohan: could be separated from held documents - Ted had a comment that I didn't capture (place holder for followup) - l7-lcp-requirements-compliance - RELO - Jon: Is it important to have exactly one answer to this question (other groups could chose one of many) - Ted: Between very similar solutions, we should go forward with one choice - Marc Linser : If we allow multiple solutions, we effectively require multiple must implements - Other comments in support of one: James Polk, Peter Blatherwick - HUM: Should this group produce a single HTTP based l7-lcp solution - Favor: Strong - Opposed: none - HUM : Are you informed enough to make this choice - Yes: Strong - No: Weak - jabber room is in favor - chair: result is yes - Rohan : when we pick one, the current contents of that will be subject to change - HUM: As a basis for the sole solution - Held: Strong (strong from jabber) - Relo: Strong - chairs: that was not conclusive - HUM: Is it important to solve that today - Yes: Strong - No: Few - Ted suggests we try to accept a plurality vote - HUM: Will the group accept a plurality for the decision? - Yes: Strong - No: none - Counts - Held: 22 (+15 in jabber) - Relo: 23 (+0 in jabber) (cullen cast the last vote in the room) - (ADs confer) : We appear to have a plurality. We agreed to accept a plurality - Ted: Your task now is how to bring this decision to the list. Stress the two above points. Give people who have not yet participated an opportunity to bring strong concerns with the process to the list. - Marc Linser: This decision was not on the agenda before the meeting - Henning: Would feel more comfortable if there were a representative design team on the new basis document - Andy: Can we hum on deferring the non lcp parts of held? - Otmar: We did not include the extensions in the process we just executed - geo URI scheme - Slides presented: Several members pointed to issues with the proposal. --Apple-Mail-3--780769068 Content-Transfer-Encoding: base64 Content-Type: application/pdf; x-unix-mode=0644; name=geopriv-minutes.pdf Content-Disposition: inline; filename=geopriv-minutes.pdf JVBERi0xLjMKJcTl8uXrp/Og0MTGCjIgMCBvYmoKPDwgL0xlbmd0aCA0IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeNrFXFt720aSfcev6Lexvy+E0fduveQb3zbOOBOvrVm/6AUi WxJiEmAAUIrm129VN3gF2RIE7o4TJyLFS/epqlN1qi9/kv8mf5I37xpKpg3JSDMlWaoy/4eRAh5k VHCpqWHkcgovhd9SJbjhHF6dkcn2ccI0TYW2QhEtFZkuyNtLQll4mf8/peRyQd58pCn8TC5vyKtb Vy3r4n6yKMpV65q0qvhrcvlH8uESxoUj4/BhWZZKlklNpFaEiVRJLTkjtSPfSXkw3O6fH/6NTKZU G5pI4UeQcma0VfjGG3ibtBQeGUMewvzffYM3fnsXn+POx+IMDaE8tUJIQxaEsZSKTDG5fXJOvvlp PP8TYX5WK6nY7idzc/iRexaboJWU4oJSkTxhJXLwffs2wu8JNmJplgQbXVbLYopWIbtWkZn/CE4J oqsUS5WmTG2ssmcIwB6+XLBgCaVoauGPCJbAD8S/gqXaZIZxsDgHozIN44GJcWWN6n7S1HbfkPQm ufNwQuHDqMyUIULxFD8V5/rm44KS99VmEv4NItEZuAZ8CTgYN6lWOrPEpkbxjGu6ntBBiGSZpEYJ eNdhWCTHAAcAjLC8Dziz+Oh4VBAY/oR0oQE/Xd6t6maWPxL+hjFi8wU898+qdW3+w9UX5Gt17eqW fFvm9Y/mdbJrr314leUpZRy++jS8/SmdgFdyH1b6NL7wfTQ1NgMn3uCbPI2vNtJCUJsnaecpfOHf A3y/rRaLvH7c92n4m0jw4vAlyvCUgQ/K52J04ILJhHKWAjBKESF4KoC0eAwjJVN4nxQ7PghR6mGj ySmMgCeEOuKDJOKDSQ8jISFKDjG6vHPktq5WS3KdN3duRlp4Ir915SwnbUVuqumqIVVJ5noyny5T 8nfSuLoAP61uyN1q0ZBpVV5xrraO6I2aSa74kOHumDTphsuzI+OtF36MeesH2o3czQt3D88XLXnI G1IsllXd5mWLM1jW1Ww1hTmRpihv5478cnn5BScLr4dJHYxbWq4oWOclI092gFbZ4cABPdJU81Vb VCXAeNO6OgA4K2akrNqdgU7nLq8R2MaVDcA/vasK+MW1ax+cK8kvHz6/J3k5I18/fP79px0c8tva IToVyadTt2zho5bzVZ3Pi/aRzNy0aOC78deL6t6R/Zkrboy1jI6euRaHM7+p6oe8npGHor3zo/UT mIFnLRzYCAyGT4JFigb8zU+8BTKEmTxU9Y+0T3E74StVilGrXk5x2/ClKuWCQZBGwldC2s4g/w6j OKA3Qa0cR3GArelTXAuOD9mhrt1jQ+7Bv8rWuTp4gZsV6AMbpBsHOSMHbG894r+Xk7fuLp/fTH6/ 8f70uWgmbTWB/8FU/lwVtcO3gVHqatERwGTZRO0hZCjbzmGPTHpkacweQqRgMqiihthDMvhsYOrR 9qBZj58+BQqCgF7zlJt3MBalh/3TDB5hRH74q4X4hpBEEl3NZxDgaxPBez3ovWiJJ3ze1Xvj8z23 IU+ZGPgca1UJnz0AfMqoZBrqiLHpHiqbQ+y/5g++UGr2Mn5y4KKoLAAaeoaMD7Uu0kEWRYmFqkAd qzpPZXyqBVPWjs73oFMOQfp7yO1vIdsDEfRqIxhvih4gdKKoSBm11LwQKRwE8+EpE65DoMoYUjAT +A72ZH2e7AazAb3BMjMyZYM7UFCeB1hd10VekrqCPAw1eA1Zuc7LW3ekMPoJIrT8GxQc+fwHya+r VUvm1TTHZA91x22JnHv1qqurGkjQsz9WDYT51esonYJA0txqeQY6hXoMo5WxmAWyzviD6FQpo7TI 6Hg67dcO79e561ubtyvMS1jauVkftY3fEqjhhtX0yUm/JVw+XdNLCyKa6WGgaWAEYTUfBxq6re11 W/4Ap1tWBeacbXEIPosPPr/DPPTt0xfvu2sXhZLr3j3m5dRFgTVdqjkHsMIHexRXQ1MptB1UbFGu GRCJHY0rcMohrstidjOZVxOo1L3kCdyZhALagEWlyuQLRU/44gSz2pFvBtnyUMznWCHU7h6lTu4F xMK59iiLbzgkkZqlUERx+3IWX3NIwnnwhVgXQGoYNriLGcLiNLOZlcME7hHFKAmDqD/A7uOqXcHX vodydtr6amtC3q3mc+D0X12JzLxbLyQ9p1c0NZAGX14ubH2eeaLgUfhUlkpjwY8GlAuQ/iBMhKXj Cgb0etHrUq3qW5D7GxLZJL5F/gOz2lpXNiSHl5RdA6HM54+o5yArOsx3N3mdRqlFUi++9DmohQbe iAk5iX1NcDk1kLSlhffT8eQie0ru8zug5LqAXAfRvazm8+YCdDqMBERESRBG7CAA9bTVtJr/TH7b /52vQn4m35ElwAI1tgtA+wWid71flKENgr/qm0WHPikU/1JkHhQRjAFCVgw1C8Ag8SEBEkJikDE9 J7lNUfLxQWaxHBRgxkdyPmgSpnt67reTJujjBumRYZMU1WjWtfk6dxZmKG5QimEUoNYJjBAr3CSz KNz0MG9WoOAypsbBBs8x25Nib33l/LWrnB8csMUMcURKWDeiJp0/FiiXEd5JU/zbkX43UQCcMBY7 sjcFQubISKFIyufzfgbdMSa1oemTPNOYJGJME3jHJhFjUuMXWZ67TJH4nkYGOcoINq78gOc47UnG X/MFZIDvUFC6+rpq22oRbHqX3yPHfP+v/XbRpt+EzbyclO4BjRsNl8x23H2AsCecgeGi1hQSQTgz KdTNeli8cGuV0meIF870cYi/VKAecQGoC4t8Dppz9rifB34i16u2C51Z5RqUnd4SkJyB2vdzxrrn 9OHyY8wAwpqulXMGA0jPRSpW5YDySQEi3tdMoCZP9+04qDrBxXgDiJ7Q/OVfvx3m28K1N6RZAl0d W+Awgiuqx1ESU0fHgisTO4mGXL0CM+azWdF2/XuoFa5eX5D9JXT8i0rUSgPFkzCmazsdZO5TFvVV 9K5F4bMggylcoBKBkGLNG2G0dyYzyKJA6gzIfWTmBkKFgdB+b7yuoED9ZbXAMLjJ76s6Jf+swqpL tVxWuAQ0IX/k19cgpZppXXh5hQ2GhjThzc1qiY/XcTS9y+H5ahGrmYTWQdk+E/hIycR44CkbA16r VEuonQcBb2CsFP47umTiuidWv/3r7bd3Xz+9/dCtsuVL8OR8ekdWuAKHJWmUipTuelBnoCIWaCaW C4RSKWgyawfhpzMKtcTYJR2kIisjtdMF+YDA+RS69NEPNNCsezmNa3EZtsVGbkMcvnJ5h8y1WDUt roKGlYco2lKH3tUZwKaBAaLOKmUKwkzyYSxBMwG1NB8NtujvwfhaId3/lt89AhV8Aiyr1e1dKFQf cp9bgWxDysV1nZzcutLV+ZzcuBbwXjighLJoFr7Y2fTTihIeLvzPUfSF6pTqGeDPAg9EfV3IlGNu HgI/CGur5HP6Wkkc/P4GjV+r8s0voQdzAVluOs/rI7kWRDdn2AQfl2tBQB0ZQmewsKMgdDSCSima 6appgjED91dQ//7lIw61+rr0wmX6ts67F629Y9U4fOGWCjeO0hxr+e+4BBgrtM/GuwS1gdqilRgX Ps0PikgKmkyz8R7R395x6BEQm+sl0X2TAAXOfEcPxtjWhbsH0HENe4tzsGlRTuerGRbCs3UD8AkD MAAtk9tO1BgDGJUKqE5UzABUpViy7eYfZFKFmwZiywf4jxlPiaqniP/hcKPG+zq/dRfkO8q8Wdha 4kWdR9WnmSb0pNfaY5NvUE/vFbDYcXV5PS+gzNoxov+kB/c3mCMuhpEpiB2/OSGkOqjB4Cubg30q gnNh5NMiLE4GOHHdE2EwCXJbwVwhmptuppuJp/1F5R2nydZ65plO0+8Sb50GCiCo+UyUyIHswxbc wx4BRO3JLrHQgF7G1bguMWJn2VH9BAN9cJAnwQfQI7x2unnEbqO7R8dY5tMf+a3rkAW+rW+hhMEg R77Ed6yuuzocHmyy6dWrLtQhxa7j+FgQb9UPcF6nRl5ahG/VD4USCZ+MsSi3z0+puIs3yxjj2kpp xisfmfWS2qdO7lyQoIG2K1VHoDJr/fBsoYhS8ThUwnOZjbV4uZF+m7cYVoMIISxlZ0CL9XLO70EK XoA2LN0mypMjUOm1VBgA1V6U70DFQwTHto5wLVPsO9JBUQ6eKm02rDWRHMdK9HIDyOd73IzYbQrr tLOXxD0f29IjV+uyfwA9JidyKuTncAwgApwSXkHLQTLDZiqDQnN8TpX93Z9Xr0ogMvcXFCNNce+u Xndcue4v5OtqZlO/ROlNruv4M9AbDfEYa+6A+Eozw+iw5o5hIJN1ps4QtP1c/cXh+vfbeY6N0Idi in3THEYCmOIeHCwjwjactn70RX2FzRvcvOP+KhpfZszZTrX4M2SZr+DGkKyaB1fjksQTKUasC+cz 2CALgR71aREOSwzzaS0UHhjhZ7CBPdYzJRc9R15n6Jgr04z6REGgmksBA/ryahtYxmomrSQ2BL2K Zh++PhMxLF1DJZ9Rakeu/GILVfVPR33EXE1OJ+stWoynBgZNX1xmbtEyIaRtrF2DGxb8O4ckoOfm 6ifyD0LFzPNydT88E055ClUgMy/M1TvhmegQeSqaq2Em3RJ2D6mTexfBgPhnZGcDo1MJ+azoLPt5 preIsHU3SLqoRNjz3S05FZzKxx3PYlIYdwgomKMYGpySQ3yOPULkPU6xo8F5Qf7H1Y9QVBdlGwGM WX8AjsszANbt4BKxvMws7XoVw3rXkBUk02eAS9uTAfokmTETfmBnIDMRgi+66ItL75qpTAyqphVM XuJp0vFsZvvdrm35fEGaarEN1Npdca4P1hw5HtF94RL/tg9qxbGhACfgAapOOJIqtDP79f2OMNpa cnMgeLwleaAAGSuFmM5S3C1ghllSWmPY2EN0aElNeb++71YbEaqdo1tdL+knPG9b9DDFRYOwttA4 58+MIPAzN88fjxWfW8DVOSoAFsgjVgDgWr4+uhclirRWSmRGnwFp3lNS7zcNxAsPp0friL+SBTzt e5NgjZtV0x1tLMrlqm3C64sG14K3J2123p3GWsRMZp1kOtwQZLbbR57bIu5IKbZZkQnrN+D2aZ5t NyD15aykVHuGHilntdBHu31fVnWzQj3VOij5wfe3yoqT9dnmZgmxUOGBtPXhx4Y8vFk3+pZdf2/7 Gdue8bz4Ada9my5DYzDw4u77mrhAYyLruifjBVrgG6tpTFvgan04iDUkG1MrMrD/GbZAaCVOFC97 ufhoa4sxG8TTGVpb4N0+UuLMwow/UD6Mw0GwQBKk41tbeEruZOUCiTgmLSDoUDqxMyiLCcv8ukHc r6j2M2ERbZH0w18AVniadXC1kBxiZXsy7N1dXtTNBXm3SXSQ3LyzxVZJWGa6Fsb4VZIJFAq4NUbG 2vIs0ydufIg6GSTFzGo2epnEUBkjzjUh+q0Dm64JLpy1d7XfhgCZDfKR3mlTxQiPWuM11jkIbyKo 3/KVxfISri8bm4n/FOEZzl5MeNTooK/OQXgyHJuNnm7crgX///dSECthB/ZSNjvaEqp16G28lPA2 O9qSCV4gAzo/2uqEqE4tp3IY4UEuEdZyNY7wtCZGqcjq5jIE7/oExf4Wt1jVCMk1SJszbCyYaO63 kUfPZ1MlUwF1qv4PhCeyn+EDo3MHK6k6bXKGTGH4k+cnKN7rgAcHhwUnh3Hx8XnCZtnJ2Cyfik0h u67GGYLTCr/3SMWadBSvXIDoVEOCk1LOoWwSo2PTUt2X3p9ReO9sLIF//1yFW0+qGzwwWbgH1BZ7 pxS602ozV7sb+FtO8RXb7XxbHRLfLkS5RG2gzhHUNBPdgdcI/FyEQ67DdlAqzYHF2eigtrynMf5R uPaOTEg4J7jyu1MX+Q/sZfn1ONzfc70q5rOwDIdXwYRzyXVxe9d2u1ejEDPhmxDiLBhT+eQZTAjs FHdE9Pd0UMFOn06ADzXiHBjLnja59DvVQyOj8GcvH0nTuq538XDncBV0d+8bLoUu8nKWt1X9uLc7 K4o03vhgtLJnQZpJv5E7yruUp0Dzhg5C2uJuHCXoeKRVT9l0mw/D4bTGhcMCiCaefipn4WKdZV1U ddHiaTW8oih2GoBm4V66/glKBHfYcYAJko31Kx0RSPEOBy35MOfVuMOaKj76PABMOlI8+X7c/imb UwR89SoHMeTypvWFVpyFbbidztCzOK5QT975EISEzewglJXkXJ2jJUdx/8vx4mrhZsVqcXo3tYHo YdKOvC+F0ezoILAWhqxau6XDW4wuunM0YL3eJXxb65nwLfwsfQEsHfEoWyxGDPU/yP4he7De/3m5 R6HGHljvba9z6JjlyCVPJ/gkcp3DBLea4rnLmMjXNEVDZPQYVifrPcMttcyMq/f8DVu8J8bCWffI zUVE+YsoBdPJAUjPL4o3twlMUP36S56S2MU5/tozeQSkTJw8swseaOGTzbgzu3gHTCZ7Wmu3Hr7Z uQPO36MTu/ZJUt+n0P079fCnYdc+Tagx/iB8/DTu5orZPfCYxU23pzwso5JRQ8d5mMdOZ3HsalfV t5CU/h12I++guZOS/hdsre94CmVuZHN0cmVhbQplbmRvYmoKNCAwIG9iago0ODk5CmVuZG9iagox IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMTMwIDAgUiAvUmVzb3VyY2VzIDMgMCBSIC9D b250ZW50cyAyIDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKMyAwIG9iago8 PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDUgMCBSID4+IC9G b250IDw8IC9GMS4wCjYgMCBSIC9GMi4wIDcgMCBSID4+IC9YT2JqZWN0IDw8IC9GbTEgOCAwIFIg Pj4gPj4KZW5kb2JqCjggMCBvYmoKPDwgL0xlbmd0aCAxMzEgMCBSIC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9Gb3JtIC9Gb3JtVHlwZSAxIC9CQm94ClszMDAgMzg5IDMxMyA0MDJdIC9SZXNvdXJj ZXMgOSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjaVY8xDgMxCAR7v2JfQAjG GNd5wb0B6ZQmxcn/l+JcLnIsqh1gFw5sOHB7dEF08Fk9kLkht0JqXgtel1biehcbqpIX0zKYUBsN GcxI1UXTZB+fQpwb2zKZyZtxXhwn+6VG+qdGblYXQ5+hp4rlML+O/i6m9aPAEzu2N+ZXM0MKZW5k c3RyZWFtCmVuZG9iagoxMzEgMCBvYmoKMTI3CmVuZG9iago5IDAgb2JqCjw8IC9Qcm9jU2V0IFsg L1BERiBdIC9Db2xvclNwYWNlIDw8IC9DczIgMTMyIDAgUiA+PiA+PgplbmRvYmoKMTMzIDAgb2Jq Cjw8IC9MZW5ndGggMTM0IDAgUiAvTiAxIC9BbHRlcm5hdGUgL0RldmljZUdyYXkgL0ZpbHRlciAv RmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnjalVNNaxNRFL0zVtyEKqKldPWWRZIwfiysu5ikadISY5qi EUHHmZdkmvnyzSSa0FU3bkS7EhduBH9Aly66cFHoRlEo1V/gon6AKHQpnpmJydgq6oX33pn7zr33 3PsYorF11XVNmRFZti8K1Uz9av0aO/KGZBqnBMFUzXMzlcpCgG3H5nTA9t6SFJzbqSAX/Z8d1rmn 4XyB5dzxXZ9IUoBPtGvVLHAOeFxzReCvAc/pnmYBPyE6dHwQG9jJAre5MDRWEGqPVYTTMMy41r/d /5MFs4nQt8thz9LES60juoNrSXpF5PO7fvCRddyeMJotn52emTnPUuyMopxlGUyIs6xjuR2fC1a0 tXSSqabJQqrHBPe46HI9TZbZ+dnbUawEt5cWcU4TyR+4lx9gydXV3DzwOfgndJ7LA1+Af7NhzBaB 01ibDTG7hPMU/Mzwi7XIL2/YZnkh8ssl2ylfAk6C89j1L1aB8Q7yfa+7mB/k+bqslio4J8AptZ35 gDMJjt9v1a4AH4P/Zr+VLUd+6TvVySROBtnYbWI0RyoJsrCrlCIX2KEG7g3wDCqELA6vQR61wS8A vw+xGmYaRZhUieGAuYvY3TD2NnXAjaKRqUyrSWVd+aQ8U94pn5Ud5SnQx7WpzrTrPnqwKm4Y2uuH X5AvqDzKF6lgA1VRZg0V/6TSx529T2MGy6QmvNZwDt4gQoVKD1EdcIOMqXhHDXttasjrEQsU8nvl vVh1PtQ5qn0rzN8OtXVDhoc9E9MQvUPU3TJuR2rB3lrZmIxX3Rl7fn07sbWybzZ6ON1s2E8fzIMz ir+NM6zXxHKGbP7biWrx+r/kwd/6A5+x8FEKZW5kc3RyZWFtCmVuZG9iagoxMzQgMCBvYmoKNjMx CmVuZG9iago1IDAgb2JqClsgL0lDQ0Jhc2VkIDEzMyAwIFIgXQplbmRvYmoKMTM1IDAgb2JqCjw8 IC9MZW5ndGggMTM2IDAgUiAvTiAzIC9BbHRlcm5hdGUgL0RldmljZVJHQiAvRmlsdGVyIC9GbGF0 ZURlY29kZQo+PgpzdHJlYW0KeNp9kk9IFFEcx7+zJUKsBWUmUvBOtgdXBu1gHYzd9W/Ktqxrpgiy zr7ZHZ2dnd7MbiUeQoguQdYxuljRSTqGBw8dAg8RgmJdIugoGQSCl5DtNzO77ojagzfvM7//v997 QF0obZp6gAF5wxbJ/ii7Oz7B6jdQhwYEQSutWGYkkRh2mWxxZO19heScm+Hj9f9dDYISAhJVgMas x9ccnvZ4wOH7tmkTTzqs5NIZYpO4TaSSMeJXxGezPp72cYZbCvEy8U3FFBQnkCIeKClZJ+YOsWxk NIPkl4m7MpaSJybfwFNnFl6Z9hDQfQU49bkmm7CA5XfApdaaLNQMXBwDVjprst2kOx+pad1SOztc kRSMAnU/yuXdVqD+BbD/vFz++7pc3n9DOb4DH3WlKEqVGUnSF8Drw12N/dzgQlOYc18JUVA1nftG erza69eLR/Ulq3QSezNxVxewRPcwdgYYegy8/AlcfQ9c+AAkGoDUdQQeobpt/sDNEyuYD4WWzdms Q5Y7WNg5OlmEXghnsULeLNpcsEFDaW9jaV1nrqnFBLe4KPFMO/J6sdrvOdpBboyO0EnzCqjc6q2w NJNJ99DdoJ14I8N7ep13Qbyoan2DzoXQ/qSKvlGPpfOaPZjyONBt6PHhCsMoxG97MbFj2tFkNb5V GumtymfStxJ0tpD8xmxhyLFpIt/QXC415rGUmsvF4hVexTh0cGgw6GuAIYl+RBGGCYECVNJoZKGR lLs2gtjC7LGWOhI+ZqTfJp9t1+ceiuTteN1BNI6FtoMITP4m/5a35CX5rfxrsaUYqmkWxJSmrD/7 Q3GdzNW4FW2lJi++QnkjpNWRJWn+oCfLV6mvOtVYbKlFcnLwJ/E9X5fclymMaTfSrJup5Oos+kZ8 2U6aHtmuza8213JtnV6Z3AyuzR+aVeFIV/ygq8P/NTu/P/8HzbABaAplbmRzdHJlYW0KZW5kb2Jq CjEzNiAwIG9iago3MDYKZW5kb2JqCjEzMiAwIG9iagpbIC9JQ0NCYXNlZCAxMzUgMCBSIF0KZW5k b2JqCjEzOCAwIG9iago8PCAvTGVuZ3RoIDE0MCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4K c3RyZWFtCnjaxVzZcttGFn3HV/RbnJoI6X3Ry1TiJDNOZWJPrKnUVPkFIlsiIhKgAVCM5uvn3m6Q ogSyJZioiuyyxQVLn77LObdv4zP5N/lMhCZGsFxILg1RRhMuc62MEpw0nvxOKkJzTcMPJyWh/Z+7 cKDSREmaXTCeC26N03jMDRyhHINX1pIt+fZty8jbj3DMx7dwPTgb01JYIcJ5Lg5eC53hGWcrYgkT uZNSWbIinOdMUs3V45tL8jHc/OmTZf3twclgQM5opfnhSYV9frZwn7MWTtPO8EyUaS0kYzK7mr10 37tLfX9FGI+fw/94CXK1It/+xHNKGLm6yd5c1ety9jW5+oP8eAUX7WeACZo7wZRCOIkGOI1wRu1n 4AnoUoTv2gy/e4FfhrvQLEIfTsZyJY0z4WT9jSpFbfwGXjJg1//Ba2TVcIQHLy+YhDlQVMOIqLW5 NToM99ufVoz8UB+ClwF4iB1nihtjyCuww8kN9jdAMOMOXvUYsh5D8ua3Ykt+rTvfPsXx+aDI00Fl g0EJnvMwFMV1DoOT9sSgSD8oKxxz3GZnDYpIMGQKX9mNKoujWpqL5Ww9akjDeQJfgWtqlSmqckad Ek+HFO0tHCGDJWkDd6SEzY021OEo4ScaE14NIcgOIaAwr8yyL5vXbAcBXIBRQ59P7LxsZ5u2LeuK 1DdwC3VzW1Tl/4quf2dezzYrX3UIUvYEJM1zNE8IYUbIAAG4H9yu0M7q/jfD3HEQsxMgEukgFgrK UhgKkTMIduYRxMzlFo4S5gmKh4ZEnbNWSOdegjFLW1KA0Zo0jPV1TYpqTpbdEu7n86ZsPGLYfp09 tzQDkQTwgohoIGYquAkVoTMUrp4EcehcEJbwDJJIKxEXuN0EikzlAgPMAYrM5FxTruRJFJUzDnE+ E0WYO8aofI7i281y6atL8qEp74vZQ8DwXdX526bsHkjl/ZwU5L4srpeetF3dPBDAu1v41pOy86uW XPubusEXZFZvlnN4Ta6benO76EhZkaKFw7d1c1dWt+QW3l+Hw3LyrmtJVcNBS180cMKiI1tPZkVF rjclnOZx3hADC3NiOWSz8xwyYMDscwwKsm7qrp7VS7LyvsNbhRGS99+/f2JK5IKsfbMo1i1+/EDa xW7AawRxTupNF/BrfFl1TT3fzODN7cJXMLSvAKMVAjWrq/uyCp/E8eIl8YSrPGmrdBe8J7BVrXMO qVenbJXK3Aqlxnm8EVQyyvkUtioGGfGfvqpgci7xdrcRdQCubPcRk1wXszsC9hih9vMyTCbOyWO0 +DvY3lctGufv//jlLRjhNgm8dipX1kIUmwB4pXIDbCwFvIZoLODrchTwcDPCajMJ8GqQsX4uVr69 hLiA1tt2TVFWYL8eDLmpq+gbMB833i+fG/UTB0rjbGMq11PgLGOgTdECbQUyPMB0BM7AkwWyoylg 1uZULP6hvPkkhO5JUhZDoFbUGMf0mVwTPjp67dlmCRNWk3XRPvpTGwNzXS0fQhBHp2nXflYWy/J/ YAGV7/DtFybWRHohpphYEaJS0n+MyEFVcD5qXik4JQA8xbxaeTpu+WXxENPLYdRabWYLsi0hmq2K u5BKy6bxS39fAAlMIatl0CuTIMtj2EmxQA38E0mgGxWarIJZc3KK0MSBpD7H9j//2uWDO+/XJ3kg mu4T1IfAWhBKqO+BcapeMvTkepd1X48r5TlycpBBLIQZbVO4KqDicKAahStzABaV58YiJ+DVkBP9 VNzXzSX5CDymun2MREewkjtp8Eqw8MrZCbBo9F2VAkuy3EFC1uOICTXg4NxMARbM0zOw3q/Xdevn r4IL5DhYFrcTwCVc9MdkOBQsl8A5xCi4lFBcojCaAC7FB7lmUZQN8ImrwPqLtvoKxUM1W27a8t6T T2+YQne9QRMkN029In8U19e+IU1drz59nQyJPCI9haQTNrplStJpzsZJYusgQRg2RTDUblAyqhcF 8Ie3QZcEhtzttBpIMdL6ddEUnd/HwL8noWQsNwquPwWUJjqtS0HJaK44VeMAtc6AtU6SubnVR7PL 7wHOonqoK49qr47eHtjSpgsK4zHrtIOscwT3ZO6hLIgzMUHyETo6fwp1CiiCZrPjaLBmxsEtnh8e 4DoDK/YtkNFLUGYR6hILYynIlKNBVrkpIFM0d/BjEpgp6/q60agUxIAHAHBTgMYHEu1j5yF0/loD cXxoyX293FSd9000UxTCkf28whSBjPQ3pizt61WvLDImis9CRu9O2aIyLqeWs1G4Mskkp2dHVCxX CzGUZIsaDDDUEEgsXe9rRUPkHsuzSru+evLFyO3Ls0JED02RIqVtrik3Y0UPnFfqCcqzQg1Ez4cG 8k7Vhap2O2REj3lGKdcXPF6ZZ4aM6DHPsOiZKRWjlM2BxPFRKoZTzbGaPUGawas8TzM//vLDYEkk Owhw0va1ihGk8dC6DgMcjU6WEiRKmhADDpZM9ghlJzkjGKCwUo0qUGTH45sd6JF3czAmLEn/+Gfn q/bAqHaIZZ8J8GH6qA1iFWCEUT1BDM6FlQYYOkw8OpdOkRclTI6HmjGQMdBwOqyRnYUYg2vBx+oE G9yX5Xexfx459cLD2/tKzzCaHYDJTa/7v5QJHoBpo/elNAsuVEIYdSNLoFQwq86uPUc0+UC0XAFu iwJXQ2b1KpRtQm3sHZmX8yBginW3aVC9rJfFzJNFvZyDZMFi9E29XNbbzTotXRQzfRXgfL7NTXTg VAFUMZ1jQh6FMlNKK8Gn0C9SDPRLzLAXhwz6AtBeL8uimvkkeHCpKDCegRd+Gwme3vlyAjyqcsOB q/9VVXqpBmLltx9/eT/MIo+kRDrdlwKekZJTGA2zyJ6UcBVdNJVopVM5flkNYiLV+nQakZxpjQuV ZwVFZCXSDLTFzzVExHdtqLGu1nXTFVUoey8KYM/+z2LWLXGF0wPfa7fgvvBR4M2fN74N6/Of3tSg qJu4ltn2wXW2AEEYDqtvyAqUYtrTpVW9xpjAWGX04lQ87dem6ZDxwEQk6rYQpZWbxFgdPRJOL8n3 vtt6X5F73zyQtlyVy6IhLWiXQBq/wRJGv8h6W2Mk3RbNnGzLbhGwBtTLdFSQRvWiYwKgRfT4VEiV Ru56bUYAbeCvBJuYAOiwhPEU6H8VzYz8UlYtGC2Y/g2CWmA+IitQ2eUa1/WfIO5vbvysK+89eEIf iR+/utq0wXOWL3dXgOf3lYUJwOcxlKRCstQit8BsR2EvjHaCSzkF9nyggd6HUNHzhVAMajdrjDqh Y6XylySsrJIP9fLuG/LBd/Dt75cFHrUtZ3dJdJXslc4E6LLYu5IM5kqE5kc5Cl5IMRLS6RTrpUoe X/v5GANEiNKxwWQdWy+w8AbKHYz2n1dXH8h1gTW7XsPvLD5VVZJS9kLpmeh6PcJ70cVpDAxJ+5VA kqUTowCecBEIdPEXLwJJIfr6wyuxSqxqMBf9OGmNIjrCKGsE2QH3JfgUWJnTa0AVOHaq3iG56BXQ Kz03Ue9gNnplqjYEfCq3jgo7yrAg1iK/01N4ruNHPBeS0Xdw8Yd6A3ERcvsqdJRg4xiSrrAQHnz6 VJY/MD7WVywncFRmohOm1nwkY7nEVpVRgHKuRdC051sf6uhngP4X+3Oe+Cn5d3YEKhholDYj/PRE IYnpaNJJ5klDx7d0oySAEHBuKeQElSTNBzLp1/qS/O6Lu2EP8h6nTDjWy5svw+nApDKmgv+lCt/C 0VwCURXHYDrVpAwh0nCJLfnnNUUGmORAKR0suZKy3a/HJlGzLGgRMwVqMjpZyrqEcbkDTj4KNUml VE5PgpqmR5e2L+HiuISFuD0c69/fJ4MMoOnrCCOSwXEal+22V6QQ0y6H6MbGGZqCW1WgpifovtXG HC1TQjboG2XJGpgvkuNvQv/gbNM0WGyb1VUXSDQw59gtjP1SWNXcXP8BegWTBoBf3SYFodC0L0mc z5oZj06bdGzlYgVvVKrAli6m7RRr2trJo6z5O+zLBkoMFooVSkQaOLF/FTEW0vWt7hPkWxpdOEX2 hLS5CkMcR2Cks0ZMwYxRGQ1a+pb7dh/y6U0bfznoVTlWATqAULi+UHA+hC66tEwtTwgADgPzSA4I bEgYZaeAkNvhMv+y3kOYEhfwbxT253MWG93RpnSY4CaPOwPHcBZNtYRbchNwFiPVqY6pru+Yilsn 9i1Tw51CByGP2SARzOszTHYq5JnoiMn+W8FMWDcaV2ykiktHuZhiYcFofjTmHSn7Qri79xHVrp4X D0mfpSbq8/NdVkdvTDbmCBp/43+VysD1vi9TGdyZXp2f77EqOqNIlV250zleRo9TGVZo6ZSewmPd UZXxk9+muB+3OgiDKbifDE7nkpv4uFVxz/Mo8iewhOu4mID8WSaOraq2m9tb38Y9JF3zgH5ZzGZ+ 3QFFWS83TbHEdf/7uktSO250r8rPp3Z7yBJgGpUzY+k4ZgeCTRk5RaXfCnq8WbEMm6J8Xws9AuSO 7839rAz7oVJBj2vVC/gJiqDRS02q84RrGb7N/qqohwulXxj1lOr1wPMmHfu4JPza2oraPZ0gAZWS OWeO2TFRjwlFHWNTlFaslseC3kH583jUkzKK9vODXvRAm9z9zaUITxngY4IeoARx2akpYp4daIe3 9QaXzkjC63B3N0r57OxCCrlQOW6+0oxlCZSECNuQzUso7WwpC13AAnc7uTN3pAVbcva4wuIc1NXf 4n6AvbBKlKA4lxGxCUpQF+CFaF88aV+cxy8lkMuO7OnW3LAvsa/smRc6po4LK7hrQI4eAgdvzMIW QzIr2rg9c4m/YGqN+6P8K7ZYcCZ6OX5+or2AnMBf6q3j+OwPnMxROUFaSdUku+ZxNeAZxJ/efPcD Nn9UNwFXLCiTYr0OW9n7ZpKDlJuHj28bH7uxhzk5CTeNe9GGm/xOpJUU3IApLj0ldwwxJ/smn8FT CrQ7DbejWvGzawUBb+mOdov8t94AvEV7h3u2sba6gP8Az+vmcUtlz2li3w6Yd9l2OeZu34ZN+6Tb Av7XNczPui5xSzL5B245Wvsauxu2i37yUF4/+I6si6YrZ+U6dE0WVdiP0HSbCnkUXOLpQwokRBvF 2QRJw+kBUY6D7OtMqPx9U7WxFwbHtW7qWRjjwbhTVsXsjr5O4MRARF6iy7hQGdEZ1YIEJseNnKJ9 AGnn6c4Y3It2aD67Ekt81gX4rq/mxe5RF/hO/5yIJMRG7qpO50OMvTSxGTeBsRE59siMq5PifgsV Numdj7FTJ7c+x01U4REB/WMwVjdYh8HnipRY0vfw5hb/KeBW1/vNA/coVNryFibCF6vdhFR+21ev T+9jOZgJvWPKE8wEtpS9VJDApVGY+XGtHEYr+JmitZZTNshY31Xzh0vytghLLItNQHLuIX01u8ed AHEnYX8LxLywzIIN4skdgkztuPUEuFr9ck2MqdjMOm7lXSnptLGTAMvdsMdrVTSBAMzLeQgaJZZl 5zFO+P1uhR3B2kVqmIY/sJnO/+lnG0gvqY1YTO7o+Ss7dxMbsS6cjvQtVSrCJ6FR3IU4rttLWziv mmArFqjoQUXt1tfkP7+9g4st/OpIh81jozMO1hyuGLym0Tk7vvsK9IDpFUUCrv5ZdCMjr7TaOCHP 33/F6ZAwfFyWEDhJH0nD5nR/74FvQu5agRxoIwOKlLRs241/SifWdVssDznE/wGGtskUCmVuZHN0 cmVhbQplbmRvYmoKMTQwIDAgb2JqCjQyNjIKZW5kb2JqCjEzNyAwIG9iago8PCAvVHlwZSAvUGFn ZSAvUGFyZW50IDEzMCAwIFIgL1Jlc291cmNlcyAxMzkgMCBSIC9Db250ZW50cyAxMzggMCBSCi9N ZWRpYUJveCBbMCAwIDYxMiA3OTJdID4+CmVuZG9iagoxMzkgMCBvYmoKPDwgL1Byb2NTZXQgWyAv UERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA1IDAgUiA+PiAvRm9udCA8PCAvRjIuMAo3 IDAgUiAvRjEuMCA2IDAgUiA+PiAvWE9iamVjdCA8PCAvRm0xIDggMCBSID4+ID4+CmVuZG9iagox MzAgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9NZWRpYUJveCBbMCAwIDYxMiA3OTJdIC9Db3VudCAy IC9LaWRzIFsgMSAwIFIgMTM3IDAgUgpdID4+CmVuZG9iagoyNjEgMCBvYmoKPDwgL1R5cGUgL0Nh dGFsb2cgL1BhZ2VzIDEzMCAwIFIgPj4KZW5kb2JqCjI2MiAwIG9iago8PCAvTGVuZ3RoIDI2MyAw IFIgL0xlbmd0aDEgMTk5MDAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjavXx5YBVF tndV9Xr77vu+5eZuWclKQgI0IRurLCIJGmTfFFkMYVGYqOwiKsgi4IILq5oQogQZfAzCBNQZwXHF ZXQEBp3JODMPnRG4ne903wSC43tv/njfu52qrq7uW131q1Pn/M7pzkUYIaRBjYhC4uTZE+e+/Yz3 Mah5ByFsmtxQH3jkm371UP4SIWrWtLnTZ+8/9G0HQsxQhPh90+9ePG3OndRIhLT/RKjorzOmTpzy 7a+20AhVXoI2CmdAhX4e8zZCVQE4Tp0xu35RwWeuY3BcDm0G7p4zeeKlg59KCFVPgfMbZk9cNJd/ XvUEHEN7KHDPxNlTxyy9uxGhQQ44Tpk759567he8Go5L4bhl7vypc+mH3Cwc/xX6B/dBGMnjkUeE MIv+x0/yYkQoGjEsx6sEtUaLdHqD0WSW6y3IarM7nC63x+vzB4IpoVQUjkRj8TSU3tVARmZWdq+c 3Lz8gsLeRcV9Skr79usvDigbWF6B/v9/Kqv+52uYY8jAHEUxphG56GzkR6jzE0jn5L00pvMi044M 0uzOv1ElcPFhORGpfyk6hh5B21ETYtEeKMfQeLQVncaz0GF8B2pFH2IfygKZoVEbGorewZ2dZ9E0 9AJcX4+Oo03oAOAfQ7ORFc6ux+HOJXAsQnkSWt75HEpFRWglOoqKodX1qKNzb+dBODsKjUH70H74 /ts4RA7Q5s5XOs8jHo2ENpfDmbOdQzubkAlloDI0AmqXozdwmDrXOQM5UAn0bgd6Bu1Ev0J/xg/i 1s4ZnQ2dZzq/QgTOetBo2JbiVvwV1USv7NzR+W2nBEjEUBrcdQLaiJ6H9ptgOwbiU4HvwvV4I95E RPIgaaVXMHYpATjEURVs1WgOWg0IHEYn0N/Rj/g74qAMVD11srOg8z+RGg2BUcojmYoaYFsF23oY 0xHM4l54IB6Bl+In8Cb8O5JGxpAaspAsIhep4dQd1GLqd/S9dAuzjtnKqqXvO490tnd+gOzIi25H 89EyGN1xdAZdRlcwBW15cBiX4DI8HrZGvJ0cxjvxYTICH8NnyD78e/w1/g5fJQzRECtJJ/VkI9lP jpPfUjOpTdST1O+p7+l+DGF2MhfYMPepNElaI/22s6Tzq85/ghbgURBmpgwNR3eiiTDauSgf/QJG 8TJsTTBrJ9BJdFrZvsYe1IH+CSiArsAunIuHwTYc34Kn4Zn4afw6bG8offmBwEQQFTESO/GQ0WQS mU0ayQekkXJTadRgahzVBNsp6kPqKnWVZmgzbaWr6EFoHT2b3gbbLnoP3UK/yxQz/ZjhzG1MI7OG WUdNZs4yH7LL2PVsC/sd+1cuxg3l5nDrYHZOg8z+6qZlQONU6H0uugdNxuV4EtoMs7ETT0RrQbqm 4NXQx7ko1llHLaOqSC+QhjfQfSCt29BStIa6A+3s/Jjahz4CSbkb2mpEu+ky5GW2wOw8iHqBFCU3 JMbT4rFoJJwaSgkG/D6vx+1yOuw2q8VsMhq0GrWg4jmWoSmCUUZFqHJCoDkyoZmOhKqrM+Xj0ESo mNijYkJzAKoqb76mOTBBuSxw85UiXDntJ1eKySvF61diQ6AUlWZmBCpCgebflIcCbXjcyBooP1Ie qg00dyjlYUr5MaWshXIwCF8IVDhmlAea8YRARXNlw4y1FRPKobnDIsAhZGbIikNEarnhZjRw4tIZ DtjJV1Q0u0LlFc3OULlyjgpXTJzSPGJkTUW5OxishTqoGlUD98jMmCn3Ez2smRKa8nCbiCZNkEsT 76hppibWNpMJclvG9GZ7qLzZvuSC48Zhd6liXY+TzSRcOXHq2kqA4OHq5OEE+WjiOjgaMjoAzZIV tTXNeEVXJ+Q+zipPdndqqEKumjAr0KwKlYVmrJ01AcBFo2paXKKrIjSxvLYZjahpcYpO5SAz47Bj WUkQRn84c0DmAHlfEnQsS+7/+FCy/r1jauW6E1/Cfsio6wBg+U6hQdDP5sBk5SYh6GyRnE0tQmsn F8Fl8KnFMMyZ0J+BzQRkhgo3M+FBE5sbR3d3Y0Z5snMTZpW3qJwueQwTymrh+glrDX3gNnC9IRRY +z2CKQx1/PnmmoldNWzY8D2Si/JEX5cVON9dblCAkW/nCM2Q57ehous45KjoUQHHMjRyn5stzblD RtQEmwO1UNGG0jOGtCHViJoDGK+vbcOdK9pQufcwUiHqzvFwOkMWtZnlcH84yMyAirQglLIyApXQ cKUsK4G1gbWDpqwNVAZmgDDRYWUPJ6aurc0GBEfXAE7oVrijWOu+XpxaW9sH2smW26GVdtbWQguz ulqYpbQADSTgol4ZQ2CYkRE1I2uaG8vdzWJ5LcwCiO+xETXNx2DiamvhqpzrPYX90pmOrj7nQp9z 0qCQl2xlNLQBTdSuXZs8CgWbj61d614rr7HkcRtGP60QuyrakNIAINqGG0copxpDQbeCeTAUhG7V ypjmg0h3S1QbKvjvES7siXBv6G2hgnDR/xLCxf8Own3+LYRLfh7hUuhziYxw3/87hPvdhHD//x5h sSfCA6C3ooJw2f8SwgP/HYTL/y2EK34e4Uroc4WMcNX/HcLVNyE86L9HeHBPhIdAbwcrCA/9X0J4 2L+D8PB/C+Fbfh7hEdDnW2SER/7fITyqB8KyzwNsGTHZ4BtQiEP9xCDDZgMxoblsCgkMnU1RxKVi uWyMnLxqdXDyfY709OGXS4clSocbfigdZkiUov6liVI55fTKMwaNUUg76fVt1/7AHL0ysI0edvVg 0sXaQc3Do5T7REQzeYpCjN3uQnHKSTO/Ch6pVtodlhheMbX8Iuo/rCOnF6ZCFB4VrA8yRxOtZKjc xnppPJnIfAAeWT9RZTGqzDZoQ3UE7wC+asE7RJ2IGumhBqfV9o/g3aMcbVzuCqXZDtfnro73O7oa 7w9tE441Guw2cygLRyPRSIGhd6GZjH8qu2pk7sbFGyrjRTZ1XckR5gPp3cc+lb6SvvjrE9K355fd /cSesbfg2B834rAypnLojx36Y0aFooY3IrMV+kMP1ZvlLiGkgi6peKfF+o9g/yRww6AXn/foh9nU u9BoiEaoPB+2+7DVwLFU1TNZlXIvtg2I9IqPL3ldGo8L13+Egzj41yew7Yd7py69PE/6+NIm6Qul D3cArZ1DW8Hr6C16qCUMCfDqJYKghZ6wS2hVgBKWIKem/yhH+nDD5WGXYaIud4OsHEAnCoJGmDpr 0Bgy3oFb9+NWaeh+/NoefEgatEcajF9T7rNPOoMb0TmkQ5miDYV0whReMMBNuHxhCuKd+slTk3co TXRcn8T3YRrthb0LC/Ij0VBBntXCcvsqPHpMZn84oeGsZkxmGqfmzr21sNWalJEx+AsyhGwBGQmI AsqmsItBIB9tuOxg8HVFRM4bLqJsWTrM0N8x+AdJIFsOK99tgkzunyJfOI0SZPnCU+TvTwnKnfup fPXOs4aazp49d+56CIDMUuQzXbRz2I63gJNFiMdEUYhQAoalQjmzHe+DvPcvZVZlpS81nMB1OA+H 8HtbpaytsrjL60ns/IT2MFuRHjzOeaJ9FYMreWuBnvEUcFpTETXHUaT2VXkNDScc73ckOlD/jv7Q l4GLxXzk1kZw2BVRhZmITeeIgZSbYtjNQ8nAQsmuscawmUDmFDwxZKQhS4cPTu/+PIDqkN1mNHAk GIhGjPm9TUFToTGfhFKI0WK35VHi/RPGLpP+IEnLZvZvwAVrdy16+ZmN2dWvMFsvHJDekT77D+kv Xx7BJZebcOWVC//Eoy7jEukD6fNPV7ydxOgEDPADZgOsttABHrfhPFFD05yG5jYzSKhSyYM68UGi GET78m9kueqHe+eBUJ14c1tk/THqh7Xm2l1X7qF+UNoCp4H2MU+hFLRLHF5IV9Jjmbu89/iW+Jbj VYRP48c573Le77zf86qTQSlYT3t0ziDncdIYMX69PsUsFJiZgH9BMEUT/AVXZJuToovqH/AXpaRW hZLgXu4wfN9xPqmeOoym4myTvRjD3lRcbIQM1Smwe2inJmyMqE26GFJZOACX1hqEGOatkAG+BgPu grbQ1B8nZTmUwrFcCMrBXJPVwrF6zEIFCOTgFb869kD+qM1LD1dF6ENU2QIc++HrxZWvrplUNMVF 6a7FD2PT3DlDCkbftXTjuiErjjSckX54/qUlVVOHFuaMnbVPwSUH5MfFbEM56IToH6QZnTk1Pjlz QXxBJrs5gofw6YIj3aKlfsyxFGjBcQuJFmOB4RdabY67IJXhCnK0js3RcmMbHizqhaKsOcQfDzxA RUleVW4PVCBXBA9AuZy4aOgwyPjI2CiQFGb3ckaQiol4wykRFlExRFN8L4DDE/LHkCvsiGEacwBX NmS+oBswi7gVsJLCaChVEHsAMMN1NCnIs4Hs5SaBY7kCH87L7QFjvgyjTYaRAwVoQSFsu/BLTazy 0PqXXt1pCps9EdvUAfO3Tm2tiDAt4j3Y+ulfqzIq5/1C+vs/o9h+6uH+87YueqIB42coEih67K76 RWVLnp176s3Dy0flef0HGn8jSUnZLev8DNZlIwqgI2J6tWm1nxRrKs1jzdPNdB9eo+WQRtDrdAtM ZrNJpw+YzBwy2wV7gdCGU0SX9hc6ndfUR0/TBYF2r9bIFbnmoKJASlUwier3HScA0I7+CUD0/OVu NGVRUxTFSdRVkdPLAQDHHH6sIhHKh2LQMX+A8YDcqRyQYT8dQ6wbMt6ZlD8ZUUOpDKmMZ535Jiyj shakQBDzcmmrhQRTUqMJ01Lx1me3HWqsW5G9Yza5lHimb27miJknsemq1NEk/acBz95W4nvn/s0v VIsqinpFmh8xB6U335beOvmOwgeGdX5Kh5inkRtF0V6xeKEL2/kwH3XWOFeiVXi1iqvihWA0WKDT Wah2rsDNRAtAHuPkAV+RcY5dIKVCao49XhVTgEkU3z9k1KIl2Q4Qui6Zk4Wuo1vU8sMRT0BvQywT Ceh9MRyxpsaQxwwlWe4wTfkNwRgO26Ix5DVBJsudsh5xUshkKXsA14Hes1lDYMdB092AI5SCjAZF BybhslpABVYdbTGEBizf0iL0G3/brFaskf50WvpswFI89IFHlu2qb3rmEebpH5eP6TVO+ka6dntm 7OL5N6Xf4Rw8E6tfx1OufP4fD97Tvm376qTNGQI6LBtkSo9Gi4WM2kmK1H00xdrB2jHkNnoSOcQJ 92tbtSe1FFFhra4P0tMqDdHyCM3R8UWql3TGKoMCEyzKC7J4gOIEbQVig0E51WErCzRFXiMmc2Hv YAGdXXGhZmymN6u9/NKaLdcuMY1PDZRajx3ZNvkzvA1v/svLryKwXmWdH4H+2AF8wI5y0dti1W14 rGqcvtY8BU9V3aWfaV4YVg0y3OdsCM0P3xu9P+f+3NXOVYFV0dVZq3O2OrVVfC4f1pFwrrrAaMxg CnyMvSBDS4qATq48pCuKz8nmi9xQftVSlJ1flddDqdzQKR3FXYpWmeOCtCxPwGSjtLZMSwxp0nUx LJh4EHMvZLSfxLA1yx5D2jTIOA8Tw1SA6aFNesxxj3nsOacI+Fs+zHlSidjkUBvMfSrU9SYvrGx8 6MH6zdNWv7hvxQPPb9ohvZp2y6UPfvtteWREbd6d0qWz0u/vX0KJK+4YsXLluKnzEyWrVj782MYH 5z5Pnk0f0fjsxU8eXzk6OzNeMOXZo9KPX3/8i8M58hoZ1PkxbQQdLa+R/WKWk0lnYrZqtoaZwaxx rnZtdakqeS4YjRYIgiNYYGDoAne7Q8uRUs6XY2nDY0S1FsXdD6QWabsXigJhonhpcrUouuTmheKP OF1qM6ZMYRJJ0cMqCRhhlVBOUCERNRyGdLBQ/GbIsAvUR1gTvYkdJDHESe1h1mFYKAX5pryA2WaV 6UJKpKAnutjA39W74oHXIqUHpr37t79cwsULy255SGp/7xzJPfDMfcu3r96Ex20q9n2EB905DJO3 38Qx6eL2b6Qf35Ze+WwXjjzS/PT2A0+se1HG6mtYKK10UPEvckUXk8ZRaYjlBBXQMwZPoWXHYkpw 0f1Jggbi382Oh4FZAhIBLM0I6euz8KGD5xIbFb5GEBBs2s6ckbki2iFWxUzV5hrzVO0CLTNTs1hD IrzeoLXq1SqH1aRV0wHDWJkTBt5yp7LYpM8x+PEUilIFHEUqV4o/J+AMpvwuOLnLC+kA32aYQhk6 LstsRlbsF4032INJmRKX00fz3rCH8Q9ALs4xAPto9wDs5CFDSdyTFjAMvUcmRTxZToetofzCm4kE 7mhvl5ouf3CyY+zyCcUt5feOSLXFFqzaLaYyLWfO0Kcx91XTrOWNdQ8se7Rp3i0p4QGVkx67v+JB GLkPfLe+wFkJEmC9nxNHVOMaPANTq6kt9FZhr9CmahPYGHBXjmUx4VUqyATEMXgdpuiARRDCJqiz MEzYBBeo1QylEmiWwWqCgfT6OL4N14oqmiKsSqAYONojmrSyZ8E8jZ8WnBrtzuC68YCZc/hlx7BE wqlMXWU5yK8dSDI4iYlSY3H/blNoLM5WrOEQ8JXpY+5m+kTtqixHVwUFFdSJ2vRus2koLeUggatW B0sfq7EZmDYVpEKYWv/7jhVfEeu5TYkjz7xDHiPjyJrEQmrylYG4TapWGPwWwIWGkoCssD4eFIvG accZZ5FZ2lnGJWRhkBukrTYSL+/X034zYBjlfXai9kV5Osc9U58TcqWprOGYzRlPa8N3Hgw2TOvp 9A5TFF1CWZ6JG6TJ5HAxvDPMRjgHnY4ZF58OUpAUAhgBVhgP2KegsUeRCgbsPZQWx8YxObGs8p4F ZQ9KT+GXDw3PeXToUmnBm2QheEziLfFh84om166QvkhspEaEej/6WK5HKk6MmzXwzmf7+BNXGfO2 2xc+XJsdTS+csHf9vS+BVIzrPMfMYy4gL0jKAbHEzWzBmxnKDyzjQbyKWWNmRvPUSq/RaGX7eClN H6vKR3w+J5VDSgw5RldAleN0+gM7g7Om9VwXl+WRw/pMaihD0nvpgzz2sDmiC7sjapsqF2kthlxs MuoNnAeOGETlYkxoSnBocpHeBBnvYnOBRkLWZc5lg57MFX0FC4fHdnDPFStukilj7zwwhopnA956 MET7cL7xePBkyyfS93/77rN7+/qOuzY0SR91olcuvPQ6rooxF6RzR9bvkt6VTkqS9B97ax+/9NTR 7b/BL+GKM39QdAgoKGYyyIkWOdB00b/KuNlEcnm1T0+Qz87zOWaXSxvWOZ2uD4MNa7o9SBkDWQAS ysAj2GYMWyMsx3A0R3GEY1jBwMNobZCpTOpczFnADisKIU0eV1geibz8DaRbBIwWjsDUn5k6oH5w iUv/yd+kZ06R0Th796aa7dLKRNM+a3RO7cOjq7ARZ13dypg/Oi6d/fao1KKMAfxeugPGoEYaNFxM 5Xw0raZ84K6qeJ+g5jVEoyGInUlKVC4dxYeRU6trw+qDwU3dA1KE+vJ5Y3JWlWCOIttJH9vYlXAT nX1tI5V+7QPq/qvHiZ852iqV7ZN0TXDrbv+b3gcHKlQsOuReqLp6wd6FXWrlzoK6DY+FO3/W887n 5Zv+9IahJurqtXfI2UR2u3KjpsQUeayTOz+Rn1eCzxhCZ8V+bnYlXkEoL/YzK/Eaz2sBRuT1tNVG GWbbltmI3mbU0itTDEaf2WSycn1SKCuv7eNShUgoRPlMbXiIaKDoHKrEEDa7wkKOz5kabsPTDwZn zb1J3hOKe5QUeUXmASOlqriuS7UpkpDhDiKNJxwAJ17jFkDCg5CxiM7FhGJotVebi1R+LhczBDJ0 Q+iT5hnkHSXjUUmBD+ammoMFgEQUhD7ULfRR6uKWT3NOpv7hpXekby5iuh0zlJRPVjT2mjr8obek q7/8zak3cFaQ+XrEvdKXOzdKv5XOSlekQ3/E5MVrfzk6J33w3vfxfDzv3BmizFl37E+N+otBXuWj CKExETie5sIs49JiIaxGTo1G+2ywQcbE0CP0p0T++pcqaMhm2igHkUKQh3aeJtdOn07Qp5mjiZ3k zisDSVNipHK/05BtUDS0vQ0QeF0Ju2SlozaEstsQye6VA+2ETp8+rQRTMAp1fkLNhuvNqExMUbFO drp6CbuFMItorFLRJqLdQKuMYeSyCmHOabG24ZEHg+tumjyZksKMKXQaFCwQnb44T6Y4shY25lGz e0+T/vDit0fumvdMju8kfu316b88eGHmzEWLZw98nfqdErcEjIYrGL0uLmGZMBPlq7kabiGzmtpK tVGnqD9y6l3ULpowTIyPq/aofiQMKAOeUVHvE8wwLM9zKkJiFBU2waJgZWMLVQytkjMKGL6KZwgt 0JSMPMvfxd7HXmIp9jr6WlA+469bIOdww8U6MLClgH2pEtGwF/OrhmWlM+BmyuaUNsgc8qSBL+Vh XtD8eXV4Xh3AioMqHMScMbTjOHkHmxNPkXopkZD+dBxmKZ+8k2i+tpF89ZWEusZMD4ExMyhHNCNC ER/N8JSLwyTMICfLteHRB3t2CvqEFHvfPykJ1uCOdnLp2kiYxr83QXtgj1m7Mo9vi7XleAgQCqyi bNhJfYQZM/ZQFrVbMxbXUO/jT6n31Z9qBMBDW0FWEnok2UJIXIhpi4QibRUZSxoIF56iFQhlAsDU GhPF8krUVQ4Tbhe1gp9SswkNJgmtH5b49tfMyGmRhXe4Qe7qeefl4mL4c5yXe51kmjJXASSHjFp8 QKtpw/taCcwEqKp9LYRQq5hhWUsS9NITq5jkHjCtmz8Pz6+bZ5YRBZHPLyzAIQxCZTWGtmAv3oWf x66jtFR3UhrHvMEcvRqhz10ZSE3OPLPwapz+KLPw8/xrT3VzWCZN0ZkCahAtvXEReHzYjqO4CteA GGFC5EHZgZ2BZeFhwDzLC5QgYJaHWYFzrzK0SyPztO2ioEJOtaZrpd60UGUllVTuMNDiYhpY2Kql J+WBYJAMLK9bDH87/kQuHv19Qv8G6QOdHkfvujKQfvHq7YqCp9CIzg+YS6B79eD1eNBaMWMV047a 8ZvkFH9aYAfy1j56yt2HU3mIx6M25VAunyNH7fT6Pv4JfbhOHhSlmYtcctSzK+aZK8c8c7GLh5KB hZJdY82VY5652Cm4c5GRdufeHPP8SchTdveRqcCAZCVqMQUpevuRDbtPSJukl4+//MQbuB67/yT9 7U/npS//ga065sKVN6Uz0qFznejLj/FgnPY+Nlx5Di/+HlO4VGqX3r0sHWDGd9nYfyp80oImigUz NTNNizVLTHS1pcYyw7LEQnO8z2gwCFinl22ewBPWpKFVFksO7bLpVWD6rLafMboJI4hd0uYakmZF 8fvNSjyMBXYQQgpPDOYWFjSRTSf++uEXUm471bio7F6pHq9buZs5+vmplzoTG+nDffwSNf8xWaZa QaYWKTIVRU+IJk47CFcztbiGmclMsSxieNsR3As7kRt7xLJQMBCZYJpnWmChTD6/xWOlgj6bhY6Y UsM+pFK5OZ+aRDxuPhC2+sM2Kkc/0+2K85FwVHDG4h8GN91MjC93vA+bopoSyeEUdzlNMqOvg326 TOdx7g3+m2tXvCIf9suuqd0K5i8bR5STIapq3fPz+06TXO1kz57Z786edNtYhqPUpqzLgobWcFOK l0gl7ZRn7oanin2SQHbmjE8s35MXmt948tZ4pSVoLr3t+8dy3Im1gMmEzg/oH0B2s1EvJInj4/po KBIp1BUEqyKTIkt0C1NVd/EOnT1ManUzdPtSKEHXJyU1RaBoj2OlJTs73dPHQtF90lW9iKDjjakp /livXkZH2D6ID8dcuf6wcRAKZztzcp8NzuqaYGDJN8iyyQgIGJXwTjdplmc+K5FXN09ZBcNiWUY/ 4kmERDLDbNgVoTJQOsrMUnZMGvgSXrM/HbmtjnTsdOBMOh2poup0HFbjLChzcch8Jg+ctHnSk6ET g+F6kOwGyZD9USUEkHRBFKgL8lPlcFkyegbev92mzIXVQsusozfGPi5/8pW5d7QMGfpc+5sj12HT 1T/igUf0Obefa942ruTMbzeNXCc99SfpL9u3U2QYPrd0+IZAv2cX5eWGMzMK7jj0a+n33zf0v/eJ SXfnBnplp5RMP3H5vXUP/4VWy3YmCOsKbD3iUL7owqwPcYTm5cAAukqoMENfZZ287GD+9MmVYmtA lpRHVsEC+rRkfEsyMkebrvyd0TUl4wP7gCvK3MaKbKhUDNmZKFNkoAREmD4GlY2y2SyqsMblwGGL 0+54Nrhp7s8pqVJYj1h5dpLkC0lFQ0WcYErrS2t/l7g9561BK6V10roVg8hA5ui1+mdnPfvy+Geo ddfapb9tkH7Awgasp4phrPmwLguhPyx6VCx/DD+LiYhvxcSG8SLmIibT6RnMappyxkjYRFE0kj1y BrgixYInztA8L9s4Qj3NIPw06+TWAypABWS3u7gY/pKut8wLwJyZirHMCGQ2AEZNBGOIEUVjhAnL rOKXGk4ombwWUd28efNVRH6IhQ1guHb+PnHpd4lvQP176a+vDOzm9mGEuHlwoMG3iZt4FV7ELVYt Uq/CK2mmCg8h5VQ1PYwvE9bwq4RTpJ1q506pNTXq6dwM9RqyklrJrVE/STZTm7ht6r1kF/Uit0+t Bwok8GonbxPGcqyapwXSL1YRY8Jg6VBYo1GraEypgTizGgYRXlBTHK+TnzYy7EqRp+jLAlFdblQj vFLj1N4EhisJiKsnKHYFFbsCS8eqrA5ApVUlqHihDW8T9SbZNWUomuVUvErg5ToBqBoF1UijXrXU wMvEiknnZYbFG24cDBm5+CAGfQ/feA2aAwpCKQ2qVHyyPRlyaIE3HFOSgVmScPAnHEphKS/PwPy6 unnAJ8wqnKeSnyWqYCYS2IqHfoyHYus5adlZ6WVp/1mpEaZkDL1fTmCVj1/tp0R90kCmqqDEg7Z/ VExbTWNLjAb5IRTID3Sf4QnPYYoGEeJ4FQWcGakBRIpuw0hUsYQwbBjzQOfQq+CddcMIS63YAcq7 b7YB2JKCIehuh7wiFOEqziplesjXIQbkkoeR0gDVCSWTRcusDAjWpzntEkjWrm8SH7RPA67Zjxy/ tjHRTEZQsxVeMarzM+UtTz0qQaXoc7EorRcWDMAHPdG8asNM1SwDV8ybNCrKnculqrwGjbcknWTF Sw6VkJLctLDJwDG8J5pi97ThtbDMvX4u6s1SE2+BupQrLfVYuHjanlRXP3fcM1gfLXL27fdLvAUU z2G8Gd2kqs8nTlynJspTCllFy0YrqyOrQzZiYMsUZR0r7G1NQdgZxoX6IHL4wO2zBSxBHExBvUkQ ubz2ICgmyNCN5xRdD8NSFT3SF+uw8sjQelMYsB/Ok82hUXZO4BZyjDYaico7Obzd24x184ffWbs5 OCN39qSc0bi1n1Xz0JJHSoLCHuYfzx9tWGAPa3zGtIxIXZpN1fu39286+vqWte+Oyxi063Grh9Vp PdnT8d18hiPzjtFD00b/ent19dbEFk8KRa3QsGUhsXrWq6s3vWDG52Xd2dD5BR1mjiMj8qG5YtYu brfnIw+Vwut9hEHI7mU4o+DzqtWWKO8KuLIMWTiOjE5/YFXwaF03JTh//roDBn/GYmMSPYfJxgo2 1hLBJgEyK2ePYLPKF0lGSGSYwIGQoTAZ5Sg+IGANpV4PTYMibmgqeWHCqR9/OLfk1tziXWTa448/ ct/hSNVx5njiT8NGSh3SZUlqLgkNW7P00ht7v3jt7JbxBxR7UNL5FXWGHo5cwF93i9m7nXirYw+/ z0EN5o3bLRRlYb0uTusFT4Rzu+2GqAlTUWJ0eYWo3enxtmHuYHD+0hs2onRYR3Hxz0XC8pGTD2us QgTpzIZIMgbmhCMGUUElBqa2aSNIb4JM5WAjcgws+DMxMEVekC0ZAeOUqDxIRV4ycm9AeRz58Gt7 k2H+spcG91q9Ye5DzibfX4+8dwWb3vfQw5s/mvzQntnP7vxszcIPTuK8i9iF+4AaRUWd56gOmFc1 8qKFYm5vXZVurG43vdfNhHkL0XsNiPd6ObNAvHY1k2XOMsSNJpdfHXU5ff5VwfllPYcPE/zTuXU5 PCoBYexQw9g8kCEniSDBzUdw1+zCqEw3nl9agbrbZe+jQB4Wkh9I/LBh59Kdu5as3ovXju7V9+Xn +r8056B05bsv8J2XPjr99ptn3iK9831DiPdKv02Ta3DmlW/xWNAh1Z3naBfoEA9KRWGsERdv4Z90 7fZTjI7oGYtVZ9JbLaJGtPBxFx6ifo1qx7+m2t0f85+oPvR/HLpkvxRStxvbTeQOngmm6rfZvKnF LMfZgl4PJ3ht6jC3xbPbcwjWAB226cMexiloOKMuqvdGGVc0NYuLOp2R6PvBXXVd7D4p+u8nkk8L ZPqbXXddTrqjRwpklSgEpoIhYOpp1g8OjMlgNlgMNKsJp7hTIyiAvBHs86rsXASprboI1upCriBU MZDxDpArrQEydP2ZqCI8aelpD4DXj+bVySIks7lg8qm7LEDyI0UlxoTycJL0gZ/Z+mFRoclw7Tvm sS2P3NrLcoC7JWfU4gGjTknfYscfsF8dG/zy/XsYHKKr7hoz8u7Bzz1/sq6wquTxrBEeA1gsFhhG mRRZUPngwbX4syRn8MCiszPvITsaJqZzXlbwUlhvKbZpWZPgBCOk0xrjdhNn0uv8OqK7ZnE6nNeC 05d1IVhXfEIBqifh66+8T2SSH++CqyCvC9YqPx2CrSCv4NVQ/1Zjqt3jVI8KtLS2bNrElOXfQcgL BI95Zf21KdSO9XsUe9NXKqEugaz4USbKQofEYYWWQfwgVQ1fq1qt2eve490b3ZV+2K0GlmFLietO CClgUmg27nUKJq+gz+KyshgPlWXLyowzrl4aXVTbLxL1OLN79VgglzuKFf/u/PfGGzalf/I1i65g YSjm8qmNqWFDJOSLRFDMBZlRrQsivU6jDXtTIjjqjoOe0IBDe3OwUFlF8sopyDMmQ1rRvC5Sr1iL VHlmUeS61gATg8n94/MKdpXOlU6//GfdIW2070PvihGqcOvSV6SrmHsdl7/wizcqwxvvP35LhnSW LusXGrjqWu47Dee2v1gdLd1w2+ejRvwDe7EWZ0k7j7Xcue3Vo02Tl5NMZZ6XA6iyTrGh0WIGrBre ztn5KB01L+AW8LxZS8xWhIxelrNqBG1cAMZtjSMbcO42zB4MTiq7+dmKTGBljVKM5QWiGAPleb5s GEPG/KSPYgwtbxXzxj74zejMw76cVXNfawXl/9nIYPHztU8nRpLnG3rXbPswcSrpB0D/cEnX+42F ooe7QEOnWUp5/ghyG+co+Qnkvhs9OZEoPXFd7JQ3xeSgpPwMcvkh+NBpVz9kjirvSnSek0bgIqVt I+oj+mivTocvEMSzZtmHUQlxGnO802Tu2XrP5oeBXGAgSyC/uB+W/QuLvDYjUVzU2io9tzinNdK/ Wev10x1nfsynQ3fQr13tvaDPJKB3GDUC7v9U4pK7xSm1BPfhsZPA4razY5npzGJ2EbeKOUydps5R QlcQkiLLyROwIChSbAIqyLCgcmabYMaUQCSTjEOCh4RoihU4VmBdWhUR4kjt1GhbgpMOYxu6PllK HLIrDNlfZkoYkkwKgRf/ipaZYR2z1HCsKwqJZVU0Xw5C5skElzOGGl/Gv70oTcMHLkotW14Gx2k/ bpfmJCYRz1rpHkWu1kDWV8E2LoIEdb3PR+JIfmN0302Cc+N1SpioNa2tyVfxkrLJhukqFEErxBKO 53Ss3s7bdXZ9lI+C+q523qaertaEwoLLG3IKhLaHg167VwsuCOv2hCmzEIN7GuOWNoxbXHEgAVgE +5YVhoXpjMbasLanAJ83XO643P2CIXgcoLM6FD+/+10IWZqtXdJs72Z7INRdMt1DulvE/Np5jcMz Ukufm/rx8LQjdw2b9eQhV3zutN2tdPbWW1L79k+tvG30jlvXJ3qTS3eNWL8r8Tg5Mjt3yNPvylJP kmsSdJwT2M54MecQ284SmrWwUUsDW88xFg2xOAzA4hDrUAsuzuVCmrjK5cFZjrgTOd2enyzN8z18 YhhXx43lKdN8a4+hRJNcVofhCC/fP3TfjPMjMg55ey0T44OLMt2teDf0f/yoZ8Y+J6/TSaVTtLay gnkzE+9CZ2GmSzo/oYPA0TTIAX1/TMzbym82PGl7kd7D7zLstbXxp/iP6Au6byyaPjzrdXAar0nt 5JxOK4nqXW5V1Op0uduwCpha3X8dcsxAdjqiNqvAahpJBHN2KDFaKAkWTQRhA2S8DYgZpWMjuMdb KKgu1VTQNUfyGyhgQQlw/iQZ+3JFr6Gvv7h58/MfYt816R+fS9ew6Y9sPdbv2jz+iWst+89T56Q/ AzVNSK/g9GvgAIgyH2uQxtBhGLoOpaB6MWMvv9tOYnzAY9SxXiunZ3VejzpFR6IOV6oALDsYT9E7 Q6k/y7IVA2PsfhblsbkR44rQEeSGgTE2yLBTF0GUne3iYkmunZoMxSmmAkwI7pJPk9Eg6yEg38YQ +fXucOXrRyrCkEtZTYXi7fe9Jh2q37Z4VK+S1sW/e6/xjgNHpmy7f+wu6sD6QbFS6RsY43Ob7yzw DUp8LstiqTQGZLEKxhhAS8S8Ike1o8axB+9m9njYGG+yU2pvgDOzlNeltuk4IJ22uNXiStFFvc5g ys+Szq6hdo3U7ddoEcER4obxafyQIQ8FtMin7h5pknbeCHt1M88CWa3ruh8w/zNa0fLLqmj6oLYF u/Gjt+dm7X8185mF+6W/J07jZeN3N0/c8nDdM2+/T/oNTK3cdCVCItVjsAaDl40Hd+srsgHGaUS3 iJEoFdH2pqpoWscbiE5lVGmivLzcjALvMmOZVyMwC224ApbZsh7LTDEK/U8kTshEIfluAepeYtc5 D+i4/dYX7mIcXoPbsHoDqITDhdsJ9QZFmuYntsqYl3V+RL1GDwF+k42zxEeLVFuZzaYnLVutW9PY WGo4WhisDFalVkVvSx0bnZY6PbJYs1i7WNcQqk+tD9dHdvn2ZJgpoJtMJp1lRi6r2+5xWDMtWTG9 eiYfCReGSThFK9DpZsevPV4zR3uztqWrszmVzkA4lB3MdvkdNkfU3i8W4aIxV47OHzX0Q9EsZ6+c luscWX6zRuFIxQYoJZ9QyE52Mkoqe+Cy6kyGR4fiTBKxhl2RoM4fRKoIF8RUBvjwTBqUvCaoc1sc QRzQpwRRMEWn5aNCEEfCKgFn0kHExiHzGT1BOToa7IqOymRKyW56e1rWZ90vWF4Pjyr6mvvX+GjS UH/Hh8v3TNnaN3rvo2sG1H96+O93DST7mEi/J6fNrIgNX3i8bOYnX3zXzuFDeMS4XmPH3l6RCt5F StqgB7b+cv24GX1zq4aLlWlOszc7o+KJR8988iz5EWTJ3vkdUTHjQAuOelWbJRzT4TbcXwzTtmI7 xeoEo0sO4mA2jqw6q57yU4S6ZnM6XcCfl/4sf85OEugOQ+K8YiRl1qwENbviDJECmULveW3//og1 R+uz+AdGl417/HFmnPTBxkRFkVmNyXoV/8B0cnKjwqkaO7+mvgC9ZYcejhf7tFlOWYjKzFucZqcl xi6kPgJSgRidgFitwICOdnAOB7i9WUJco3a5cFzu7HvdBub60r7xkL202NhtX26KvoZ6s0m9VGAM 4yJXr4d+WR5u3UdC+dM3XhidKb+ikCgelT9hz7iniO7q2af7pt365Kg15GOXvD7VYGC+pbMRcD4x qwyfxARNRzPIDGo6u4pezexGewhfhapJBT2YWUmvYdrpUww/KHZvTH66BiZFcU2GjFrc1jm3FZy1 AN2GHzpEUbNNBBMGyqKPBTYFd2JYOXSYjNwCxRLkyC3VRF7HMhNdfhA3sc7k+1Jffpn4adhWYQoc 0CjD8PPDuOQufcjIxWKYxJWwcLxHWLi7cSBtTQy60e7PBYQZzpAOf0DF5slBX7MSbMSfYR9OPynd fUxaQGdf20rNuHoWEMIIhsHshJIGB8RlVfQ+FUw/ruQGqVdRa/kVwlvkBPVr7jT/a+G0Wj2Nm8VP FWaqG7jFfIOwWL2CW6sW5GtJFbUQLWKosTFbDJYZXYJL6EfxozTbM7TLKqFdoSu0u52n6BMCUZ1Q I7xd49TKmPeMcv9kaN1h3ToZIQ0D2HAsIKTRqJlVhnT46xHnfVg0yxFRjqUZ+cLrsd6HRZ0c61Vr YNjKV5Ohc8PSEw5GprFynFcpyHHN6zUypZ03bx6wWjfJc8tYqgHOj3579q33Pm2VTh8597sj0tsA aSs19NphqurqWarvtTcB0C45/AqKsDfDV+2qZNDX980PP34qbcGLL0o/SNJ5vJjOllbhxUziauJT vEG6h4STv1GBrNIgxX+VGdJb4j1rrasdux2UzPuLTNWmGtN0biG1kFtn2Yq2MFutW2xb7HvQHpuh Gg2xVtlPW+ly5tcMWcXsQrtkG2xnUmOMw2q3gU9k1aj1Xl4nEyqbW37JD2TKbnU0aR61Aa96P7kC QMSGnXfcNBHJZQtTlOvMdoBHIIeIsfzgwWS1IptttsludzAYy4vDsQpkGqCVdzzssfwAbJ78HALn sRThiKJUlX8RKOzdD/cGZCkq2B55aFLZjsYdkbgvO82Qm21g+umk+newH9PZ06XHpT+/Ik1rZfkX tGzQwT+RSg8HUX5QxiofsG4FrOTn63eLZb3ZajQW1eCxLKx8PJ1dyKhgtbJxedXKz9QZisGkGLwf xLHFIB4Cx/TjXBpqsPxgveU6qTx//bWlRGmxkuGk/ep+ro7reuNgQdCK5fem8sl9iVaqX2INWXut Eb+7nkI7NyZgdQ0CvuuB/i1SYiRu5EcTxUL3BSe6ESvx2rSs3ygEYS7cvrjD/y8hk0DwveD0sp+o /A9vvEMrvyPSFThRHM3/KnYSLsizcqBe/yWGQsyt8PnXSIr/nXfar36oyKM8hnoYgzyaGjGHgK9v sHm12MMWO1UsYgSf8n9+2OX0xFWskdW7/C7iusY5vb6f63ziRte7ew4dD4L/jZN9zb8xBI71AmMN UfWtrYnvoLcb73NEndD5oU590gmErr6x8F6K3klwhrN4xfrrP/Xy9gpu+5360u+RkVeOj8d3/Wf3 Hrz6Ek5+axKB3OAbPxHDxqU4ApUozbtaI7x//Uz3p5ppRztJMVy6Ck0l+9B6SOX0S2go1O2D8hjY N8nn6XuRCOlE1z4HUhmkYZCGdJUHwXVfw34HcxvyQdoCbY+D9CKUm+ivURNbjCZ33e80jVAI6nfI 17P7lGt3wPkR8rVQboX9BPhOEMr7oJzPPYLCsE+D60dBaoDvl8C+CFI1tOeBfV9Iy3G7nDrPwflG KK+BtpfL9ZBKlO/di0phXGvgfBl8zw7HjVBWw31M8h6SFVI+JI+cAKN82G5DT6MvsQVX4il4Od5D bKSUnKLqaZ5+mr7EbGN7sXewX3CzuL/wy/gvVamq21SSUCgMFx5TC+pc9Rsai2aD5pJ2vq6f7m5d q96k/8IgGgVjvfEH0yRzhnmRJWCZa3na8pl1qPUe67e2Stsb9l72F+zfOt5yupz1LsHV5vrYfY/7 DU/As6jr//6q0V0gvXcjHqTZANtohLhL/D5EK2dla5icaxbOofKKEbcNvzW9eurdDVPrZ06eqKwB 5dM5FU392R/fqVbijoLyhqYO6aEVI7Rpln9XCNkUPe5S3qnxgheYisIogqIohuJI/n2hDCVKKb+3 kINyUR4qQIWoNypCxagPKkXlqAJVKr9HMwgNVn51Zhgajm5RfhlnFIzjVjQG8AaVh2rROHQ7ugPV JX8TpQ0NSm9D/SEVpMtv4g1wwBzvQo9BehYShWbih9FiSGsgPQmJvl7aC+kwfriF5sXX8WLkwoNF Ne2/1eL0OwS1/702zLY+7f/E8fUR7ERa9BV2tmiRaoCAn8XPoCnIj19EYbwEehzD2w7G7/ZPgFN7 0VxIjZAoJcd4b4sv1/8GzkBhGsN3IshH49f8f8zJ9F/IaSO4xX882kbD7lc+OBL1/mPep/3/4Z3u fwPS/uSpffE2+Tt7vXf7N/ra8LYW/wY5gNPifzy5W+CFr77mnx3f7J+So5wfurmN7G/xF8P520S1 v7Ao6C/wnvdnR9t4DMeZ3qH+tJzf+FO9ymUBaDQsGv0e70Z/Hzjl81ZE+0A6gvfh7SgNb28JD/a/ DkUY7sFB8aLNbfi+g9WxnHAbXiIWVsc2x6uj4fhQfzheGY1C+bZT3HLudm4Al8ulczEOnBzOzVl4 E2/gdbyGF3heflD7Ukt/P3sE70f9AZb9B3mWB+75ClTSR/DLSuXLh3iaJzziLW2dX7bK8mtpw/tb DXIJCq+xSoltwy8fTFa9LPppuUQrJwxEzpOvh4JbzRMQrGb8SBuLVtga+jv6m/oZiyvL/6tswk15 +n/9cWBv8+Yho2ua93lrm3PlQqe39vrJ9P/pU78AsqllCiE/2DB31jTlp05CFVMhTWh+uGGGo7lx UiBwYNbcrt9xiUyYNHmGvJ84tXluaGp586xQeeBAw7SfOT1NPt0QKj+AplXcWnNgmji1vKVBbFB+ 5eXgpLL5dTfda831e80v+5nGyuTG5sv3mlT3M6fr5NOT5HvVyfeqk+81SZyk3EseZ8XM0WX31oN0 BipmDgk0x0Y3Dxo5rqY5MLG2vA3vkn9TYAH6f4l9evMKZW5kc3RyZWFtCmVuZG9iagoyNjMgMCBv YmoKMTM5NDgKZW5kb2JqCjI2NCAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2Vu dCA3NzAgL0NhcEhlaWdodCA3MjcgL0Rlc2NlbnQgLTIzMCAvRmxhZ3MKMzIgL0ZvbnRCQm94IFsg LTE5NSAtNDQ0IDE0NDYgMTIwNyBdIC9Gb250TmFtZSAvREVQVk5UK0hlbHZldGljYSAvSXRhbGlj QW5nbGUKMCAvU3RlbVYgMCAvTWF4V2lkdGggMTUwMCAvWEhlaWdodCA1MzEgL0ZvbnRGaWxlMiAy NjIgMCBSID4+CmVuZG9iagoyNjUgMCBvYmoKWyAyNzggNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIg MTkxIDMzMyAzMzMgNzIyIDU4NCAyNzggMzMzIDI3OCAyNzggNTU2CjU1NiA1NTYgNTU2IDcyMiA1 NTYgNTU2IDU1NiA1NTYgNTU2IDI3OCA3MjIgNzIyIDcyMiA3MjIgNTU2IDcyMiA2NjcKNjY3IDcy MiA3MjIgNjY3IDYxMSA3NzggNzIyIDI3OCA1MDAgNjY3IDU1NiA4MzMgNzIyIDc3OCA2NjcgNzIy IDcyMgo2NjcgNjExIDcyMiA2NjcgOTQ0IDcyMiA2NjcgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIg NzIyIDU1NiA1NTYgNTAwCjU1NiA1NTYgMjc4IDU1NiA1NTYgMjIyIDIyMiA1MDAgMjIyIDgzMyA1 NTYgNTU2IDU1NiA1NTYgMzMzIDUwMCAyNzgKNTU2IDUwMCA3MjIgNTAwIDUwMCA1MDAgNzIyIDcy MiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMgo3MjIgNzIyIDcyMiA3MjIgNzIy IDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyCjcyMiA3MjIg NzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3 MjIKNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcy MiA3MjIgNzIyIDcyMgo3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIy IDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyCjcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIg NzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIKNzIyIDcyMiA3MjIgNTAwIDUwMCBd CmVuZG9iago2IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZv bnQgL0RFUFZOVCtIZWx2ZXRpY2EgL0ZvbnREZXNjcmlwdG9yCjI2NCAwIFIgL1dpZHRocyAyNjUg MCBSIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDIyMyAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2Rp bmcKPj4KZW5kb2JqCjI2NiAwIG9iago8PCAvTGVuZ3RoIDI2NyAwIFIgL0xlbmd0aDEgNTUyMCAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNq9WH1UVNe13/t+zAcfOoMgw8d473AHkI8R FeRDiFxwBlCEIKCdMZrMAGPQB4YklOjLIzV+RB3T1DaNMTTvGV95bR5Z6buMqRnj0sWydsXWuFZj VtK+9DWmfY01VWrbZ0wNZe7b9w4h2Nos/8jKPZy7z95n371/57fPZeYMIAAkwHZgQe7sDfSBC14i yxvUWzoH+sX7U/NkAMwEYHdt7Lu/9z+fur4BgHsBwDR6f8+2jd86Ej4JkNhO8/3dwUDX5XeeZQAs Z+n50m4yzN7FvwNgJRWc3b39WzMymZWkO0m39TzQGWCdTAfpVaTP6g1s7TP5zQdJX0W6uCXQGzz1 B+5N0ntIz+174OF+WA6TpH+b9AV9DwX7PK1llaSfofznyIagrUdbkQHcJNvBPmX5RxczY8zOGHPA 82Ng5U+Di38W7FwtRQL1Xeq/1GS0Tb3G/wzi1El1nC2hxFlavziByfBfYIRX4TGKcAFG0AwSjONi +G+0Yz78AqLwS/gNpMN+eIHuHriMN8AMH+J88imFHfBvcFjtgz6opnYZeUiBcvhQfVQ9q96EWgjB GTTiHLSrx6EI9lAbgucxgelQR8EGq+ARquQO+Am8q4bV31P8UvgArVjEVaq/opXyZKmAfTACr6ID JczHe9QPyG4jjOthRG1SB+i5a+RVBM3wKGX7NQqYgwU4hO+x4+p29SlaWybNrYFOar3wOByC5+Fl 3auDy+RTKL4bGmnuKdpDl+HPVJA8rMWtzNvs79k/cpXckHqGcKyhfH44jCyx4sQ12IV9+DK+gj/C G0wZE2Ar2Le5Pu4IYVsDe+EInITX4S34FVyBcfgEJpEjTMvwbnwU/5We+w1TzGxgBpknmXeZa+wi 9j3OyO3nd/MnVE59W/2EMM+DfKiEelgNXghS2whb4KvwNdiFRngWRuFHhPYiXMQ4tGARLsJ6bMd7 8J9wG3wTh/E1/B/8LV7CDwndHEZgJKaIGaB8O5h9zMtMmDnOjLNWtp8dZMfY99gbXAq3gRujdpF3 8f2GTEOjcXX029GLqks9oA5RXeZSc0IevWvLkCMWe2EXVXIfcfY8DNP79wMIQ1idwAo4A28Srl/D NfiYKpZJzYGLsRxbcDUh7MFe/BoeIoQjeIxQnsAT8HP8OU5Qi0IaY2ZczD1MgNlGbQgOMW/p/CSw DnY+62Ib2Tb1T+zL7Cj7Zy6bW8c9yD3KhbhD3GE+k7+L/wq/ju/jn+GP8ef4d/hr/HWD3bDHMGx4 xfCW0WQsMR4yRjGLsIiYDa/AKdp1B9k+0p2wHHdRVdfCG7R7x+HHMAE3YQy+j3aIslo1c9QjEFH3 UjVPwg/Zf4Eq+CbzNLNSrWZfZM24WP2YYi2keulNzs+bn5uT7ZSyHKIwz56ZkZ5mS52bkjwnyWqZ PSsxIT7ObDIaeI5lEAo9Up1fVHL8CpcjNTS4NF0KkCEww+BXRDLV3eqjiH7dTbzVUybPjX/jKcc8 5WlPtIhVUOUqFD2SqJx3S2IE16320vjrbsknKuP6uEkfH9DHiTR2OOgB0WPrdosK+kWPUjfQHfL4 3RTuOP2/hThXIRwHkCFeC6zA8sBgt42E5uFR0iW3R0mT3Pocm+0JdCktq70ed4bD4XMVKri8U+pQ QKpVZhdMPa49J5Jrq5dyuwo3afhhf0KX1LU/IkOHXxsF1nsVNuBTGL+Ww1qgpEpuJfWfP7B9pn46 8jw5Y1JhsusCwVAdUbO/Iab6NS3wJGmNbSKFZXb7vAru9sVA6NhjqwhKHs3i3ywqZqlW6g5t9hPn 0OINp8vpHsnv9inQ6g2nyWm64io8bnus0kGkHHfVuGo0WemwPRaTv9sZs18Yi9f9zrxPsrF1mhfU MkkrCKYidopaXImwlmu3YDmEOsvJjS4f0io3EZ7lCkNbic1W+OwVAWV72xSMQLd7Ctxmd9iclq6t wV/rI39/yLKU0pC/RRJDHwFVVhq/eqslMGUxZFs+Am2o1X96C9H8p+MBnRgtnU3q1so34JnSJZtn hoF0MrpdEcgvbIyAucU7iviUL4Lq7gi47cfpw4W9716aLtA23CY3pSOlsJAM+Q4aUdY6ilOn7Qwx JIZWdIXEOrGbthSXrUuaCIZ8RURYm5dogXavQ5F9GdPDoM+3lOIs0OJwepyQjyJsnoqwWY9AASbJ qaiwkVaV0+Jd7VW2uzMU2e0j0mmHjrV4lTGqk89HXgunkZIc3GSbwryIMC/Mp8HiWJQ2ikEhfKFQ TJMcylgolBHS3rSYHkH4W4M8ZYiAHoAIjOD2Fn1qu+TI0Cl2SA6C5dM4LaYN/OkGikDJ5zO8ZCbD pYR2ic5w2RfEcPmdMFxxRwwvvT3DlYR5qcZw1ZfH8F23MLzs8xmunsmwTGirdYZrviCGa++E4eV3 xLD79gx7CLNbY7juy2O4/haGGz6f4RUzGV5JaFfoDDd+QQyvuhOGm+6I4ebbM3w3YW7WGG758hhe PYPh2JliCIC+Q52mE4URlskO3mCn7yec0c5CHM/ZWZZJNxuMdoQ0k3nE0VNlKyhovl7VNFnVbLlR 1WSZrILqqskqrS9aWGx1WHOpD3Hfjfz1PH/6k2URrnXiB6Cfdhx0UDlHeYxQLiegId/IcCZzamo6 RNAbZrJ5ErLZQFnGHF99SM/SdH1ystkTdF9qgupqLT5SbK1x56L10Z9GPfzp6MTEcu4kfXtjoF59 lyvh7qOzzzzYInuem/viXGZPJq5I8SZ1J22N25YUSXl9ztkUk40xcPYLnHNeunHurLgEy6sJzuT4 eZbS2QKUzku1p4um0tQ0QdzjaGiOoRinlTZZKyavjxdB9fi4taKioroqJgnShgdhA+bk5khZRkNK curc4sWlZQ6D0eAQmSUWKF7MpSJrMTkWBg8sycws/npXuxmluPYnojejN/+CSX86j7wtmsGcuGtR 7TdWPbZ1xd6etTv6T2D5TUzD8siHOKzXaB8ROMKf02tUKWetglW4HtbT0WKUAc5gjNN5NOSikegL O1o8nxVJo4/Yq24aX7SQgBJ7eh+JXkRHrHN0TIs+MnFKO1PWEofPc0GIh1Q6aTXJ81NZNCXsTdhr YVMTbbM3JrK805ZsjHfOirfZTExpanq6qdSalpYewYGjtxJG/Gh0EVNE0kPw0IPO0iUlxBKRNLfY CQ4RlpRo9xRkrjzxxODgnj2DzILo1ejvqF3FZFp+GiZPvvWT8PDw6OjwcHhj9CVc88eruC76vauM TJwMRtu4IW4dJIIIK+W81DmmuMx0xika0w1xzjnxabNMibbEUkt6lkHIEGy5aWmOrEOOlimIk9d/ GwOZVEHsjNOftcJakUQFhZmVXJIEVgtIWbk52rZ2pJSWlRaz/Q8//p2l84JVrY8M2tEcnXxjx9oi V/QSWheU3LeTOXz66eatp5pckeeYiuil6LXo+9ELNU7P5Fn+2pH6vBWxd0HvhSMD0n2zqz4Cq0k/ xp/O+97/TUtHtI3eynPkZ57+VYCkIS+aB5CA0Xsn/iPuk7/7vcDAvw5D3P+Cg3sY6hk6P9O4lvog zZVAF1xAA67H16YwGOhsyUIPmIhNC7VWAONl0yhwUwiTpuIb6GQPDXevXLe6vaAh2DMQ7N/UGXDV PtDTNf2bhKqdVG93GaiXQR2d91uhDYD+qRfQRyf1Eur5BaMm+TU8AMkbrstmFDiIF36R9odTuICq ekm/K7hATkgEc+fOKqFz586GvBozNkIZhyCgB5y6dIedLwkRXBZ2SiTuigkmXGYnAbK5zClMlnUI fy2LmFDOEP7ifFr4mPoNZ7XwkXOR8Cb5/aysXjhfQ/Nh4Vx+hCHxU2eEQ3m2cNb5uPDDsjzhlbJK IZxLtrAwWkPimDBc9rjw3V265d/zdXHEGcGhsPCCJo4Jhyn+wZ36xDOxB3fERN8uPdEDR3Wx5WiE eemY0OvMETroQZTjhQ3OHmG9s0Jor4lgdlhoytXzrco9LzTW6BHkWKLSWPQlTh3x4ljaQucJYX4s Q5bmLc8RROcqwU7xC184SNP3CjX5EXzx1Yb5+c6G3IOlEbyu59DEMzGxJSY6c0/i96Ee8nAdZONz RxvyCDMeCAs7SQwdbZhflh1hL8tJwtHchtxd1EupZ1NfE8F2udD4rLHLuMZYbCww5hlzjA7jPGOG MdmUZLKYZpkSTHEmk8lg4kyMCUzJEfV9uUDbc8kGiyYMnHbn9LGF0e5MbNMyaGJgJUQMsHvuQLWt OmmZtaLOfZubf+pe8NllmzlGu3KQPgqVEbtPWawNVLuv4Iu5grV0a2zddrR125W1+plL8gSp+5X9 A3Q03t4hiqNXtk0dKHP8HZ3dmgwElW1S0K1ckdziaOva20yv1aZbJfcorPW0e0fXykF3uFVu1c5U vqMtnobmW3Ltm87V4LlNMI8WrEHL1dJ8m+lmbbpFy9Ws5WrWcrXILXquggLPprZa+H/p6eB9CmVu ZHN0cmVhbQplbmRvYmoKMjY3IDAgb2JqCjMzMzAKZW5kb2JqCjI2OCAwIG9iago8PCAvVHlwZSAv Rm9udERlc2NyaXB0b3IgL0FzY2VudCA3NzAgL0NhcEhlaWdodCA3MzEgL0Rlc2NlbnQgLTIzMCAv RmxhZ3MKMzIgL0ZvbnRCQm94IFsgLTIwNSAtNDQzIDE0MzcgMTI1NCBdIC9Gb250TmFtZSAvSE9K WlFUK0hlbHZldGljYS1Cb2xkCi9JdGFsaWNBbmdsZSAwIC9TdGVtViAwIC9NYXhXaWR0aCAxNTAw IC9YSGVpZ2h0IDU0MCAvRm9udEZpbGUyIDI2NiAwIFIKPj4KZW5kb2JqCjI2OSAwIG9iagpbIDYx MSA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIy IDU1NiA3MjIKNzIyIDcyMiA3MjIgNzIyIDI3OCA3MjIgNzIyIDcyMiA3MjIgNzIyIDYxMSA2MTEg XQplbmRvYmoKNyAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VG b250IC9IT0paUVQrSGVsdmV0aWNhLUJvbGQKL0ZvbnREZXNjcmlwdG9yIDI2OCAwIFIgL1dpZHRo cyAyNjkgMCBSIC9GaXJzdENoYXIgODQgL0xhc3RDaGFyIDExMgovRW5jb2RpbmcgL01hY1JvbWFu RW5jb2RpbmcgPj4KZW5kb2JqCjI3MCAwIG9iago8PCAvQXV0aG9yIChTeXN0ZW0gQWRtaW5pc3Ry YXRvcikgL0NyZWF0b3IgKE9tbmlPdXRsaW5lciBQcm8pIC9DcmVhdGlvbkRhdGUKKEQ6MjAwNzAz MjMxNjQ2NTkrMDEnMDAnKSAvTW9kRGF0ZSAoRDoyMDA3MDMyMzE2NDY1OSswMScwMCcpIC9Qcm9k dWNlcgooTWFjIE9TIFggMTAuNC44IFF1YXJ0eiBQREZDb250ZXh0KSAvVGl0bGUgKGdlb3ByaXYt bWludXRlcykgPj4KZW5kb2JqCnhyZWYKMCAyNzEKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDA1 MDE1IDAwMDAwIG4gCjAwMDAwMDAwMjIgMDAwMDAgbiAKMDAwMDAwNTEyMSAwMDAwMCBuIAowMDAw MDA0OTk1IDAwMDAwIG4gCjAwMDAwMDYzOTIgMDAwMDAgbiAKMDAwMDAyNzE0MCAwMDAwMCBuIAow MDAwMDMxMTMxIDAwMDAwIG4gCjAwMDAwMDUyNTcgMDAwMDAgbiAKMDAwMDAwNTU2NCAwMDAwMCBu IAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAw MCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAw MDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAw MCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAw MDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAw MDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAK MDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAg biAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAw MDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAg MDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAw MDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAw MDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAw MDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4g CjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAw IG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAw MDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAw IDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAw MDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAw MDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAow MDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBu IAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAw MCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAw MDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAw MCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAw MDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAw MDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAK MDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAg biAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAw MDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAg MDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAw MDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAw MDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAw MDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4g CjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAw IG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAw MDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAw IDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAw MDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAw MDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAow MDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBu IAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAw MCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAw MDAwMCBuIAowMDAwMDExOTEyIDAwMDAwIG4gCjAwMDAwMDU1NDMgMDAwMDAgbiAKMDAwMDAwNzI2 MSAwMDAwMCBuIAowMDAwMDA1NjM0IDAwMDAwIG4gCjAwMDAwMDYzNzEgMDAwMDAgbiAKMDAwMDAw NjQyOSAwMDAwMCBuIAowMDAwMDA3MjQwIDAwMDAwIG4gCjAwMDAwMTE2NjIgMDAwMDAgbiAKMDAw MDAwNzMwMCAwMDAwMCBuIAowMDAwMDExNzc0IDAwMDAwIG4gCjAwMDAwMTE2NDAgMDAwMDAgbiAK MDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAg biAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAw MDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAg MDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAw MDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAw MDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAw MDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4g CjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAw IG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAw MDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAw IDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAw MDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAw MDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAow MDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBu IAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAw MCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAw MDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAw MCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAw MDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAw MDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAK MDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAg biAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAw MDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAg MDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAw MDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAw MDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAw MDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4g CjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAw IG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAw MDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAw IDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAw MDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAw MDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAow MDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBu IAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAw MCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAwMCAw MDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDAw MCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAw MDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAw MDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAK MDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAg biAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAw MDAgbiAKMDAwMDAxMjAwNSAwMDAwMCBuIAowMDAwMDEyMDU4IDAwMDAwIG4gCjAwMDAwMjYwOTkg MDAwMDAgbiAKMDAwMDAyNjEyMiAwMDAwMCBuIAowMDAwMDI2MzUxIDAwMDAwIG4gCjAwMDAwMjcz MTYgMDAwMDAgbiAKMDAwMDAzMDczOCAwMDAwMCBuIAowMDAwMDMwNzYwIDAwMDAwIG4gCjAwMDAw MzA5OTQgMDAwMDAgbiAKMDAwMDAzMTMxMiAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDI3MSAv Um9vdCAyNjEgMCBSIC9JbmZvIDI3MCAwIFIgL0lEIFsgPGYzYjY1MjlmZmY3MmVhMzA5MGUyZjRi ZGI2YWE1ZmM0Pgo8ZjNiNjUyOWZmZjcyZWEzMDkwZTJmNGJkYjZhYTVmYzQ+IF0gPj4Kc3RhcnR4 cmVmCjMxNTQwCiUlRU9GCg== --Apple-Mail-3--780769068 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --Apple-Mail-3--780769068--

	Question from eBay Member -- Respond Now

Question from eBay Member -- Respond Now