From brianh@cisco.com Thu Nov 1 17:46:41 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B3F21F97C5 for ; Thu, 1 Nov 2012 17:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4JuvejZRVxn for ; Thu, 1 Nov 2012 17:46:40 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 30BEB21F97AD for ; Thu, 1 Nov 2012 17:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10105; q=dns/txt; s=iport; t=1351817200; x=1353026800; h=from:to:subject:date:message-id:mime-version; bh=5P03Lu+m1hkwfm+hRg0mICaB7aR6tC8eRZP9lsoNOEk=; b=jL9Lay1ReFb50NWNd/1rmCt1t14ci/7pqVj7DIICOHi2iPTkx684l3qg XzIE3pWuBj+ZANVdfzUk2Kpyl7eaDvBMUGC2kXguK3zBzzTdSvOG0OzoI QVXV8YON7/vHv7PIASGwYQMSr2H1ndjmhubnBvGIGtXndHpP/tZDK4M1/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIIWk1CtJV2Y/2dsb2JhbABEgknAaYEIgiABBBIBBQ8GXgEqViYBBBsah2SbYIEsoB2Le4VaYQOkUIFrgm+BZDU X-IronPort-AV: E=Sophos;i="4.80,695,1344211200"; d="scan'208,217";a="137956301" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 02 Nov 2012 00:46:39 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA20kd6N017815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 2 Nov 2012 00:46:39 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.218]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 19:46:39 -0500 From: "Brian Hart (brianh)" To: "geopriv@ietf.org" Thread-Topic: Comments on updated draft-jones-geopriv-sigpos-survey Thread-Index: Ac24kkPPev5h7qA9QQ2TXDqQkidMyg== Date: Fri, 2 Nov 2012 00:46:38 +0000 Message-ID: <0F00DA11850C7146AEF5F0DD38701E620C07AB@xmb-aln-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.35.69.178] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19328.001 x-tm-as-result: No--30.617000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_0F00DA11850C7146AEF5F0DD38701E620C07ABxmbalnx14ciscocom_" MIME-Version: 1.0 Subject: [Geopriv] Comments on updated draft-jones-geopriv-sigpos-survey X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 15:07:37 -0000 --_000_0F00DA11850C7146AEF5F0DD38701E620C07ABxmbalnx14ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kipp I am new to IETF so apologies if this email is coming at the wrong time/wro= ng way ... if so, please do redirect me. Minor edits: 1 "WiFi" =3D> "Wi-Fi", 2 "regclass" =3D> "operatingclass" (802.11-2012 has changed from Re= gulatory Classes to Operating Classes) [and, apologies, my review is not co= mplete yet] 3 Magnetic anomaly data could be explicitly called out as an observ= able environmental measurement in the abstract Additional topics: 4 The license describes usage conditions for the LIS, but sometimes= this is not enough ... assuming LIS->device->app, then how do we express = the idea that specific classes of devices or specific apps on devices are l= icensed to use the survey information in computing location but other class= es of device or apps cannot? 5 The LIS could be an end device or even an app (I realize "LIS" is= just a label, but the label appears to be limiting) 6 Recall a certain large company has introduced "_nomap" for AP pr= ivacy, but IEEE 802.11 is being asked to look at a more standardized versio= n of that. There could be some overlap between the two efforts, which could= be worthy of further study. Basic question that I should probably know the answer to already: 7 Is there a binary version of this schema? Regards Brian --_000_0F00DA11850C7146AEF5F0DD38701E620C07ABxmbalnx14ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kipp

 

I am new to IETF so apologies if this email is comin= g at the wrong time/wrong way … if so, please do redirect me.

 

Minor edits:

1       = ;  "WiFi" =3D> "Wi-Fi",

2       = ;  "regclass" =3D> "operatingclass&q= uot; (802.11-2012 has changed from Regulatory Classes to Operating Classes)= [and, apologies, my review is not complete yet]

3       = ;  Magnetic anomaly data could be explicitly called ou= t as an observable environmental measurement in the abstract

 

Additional topics:

4       = ;  The license describes usage conditions for the LIS,= but sometimes this is not enough ... assuming LIS->device->app, then=   how do we express the idea that specific classes of devices or speci= fic apps on devices are licensed to use the survey information in computing location but other classes of device or ap= ps cannot?

5       = ;  The LIS could be an end device or even an app (I re= alize "LIS" is just a label, but the label appears to be limiting= )

6       = ;  Recall a certain large company has  introduced= "_nomap" for AP privacy, but IEEE 802.11 is being asked to look = at a more standardized version of that. There could be some overlap between= the two efforts, which could be worthy of further study.

 

Basic question that I should probably know the an= swer to already:

7       = ;  Is there a binary version of this schema?

 

Regards

Brian

 

 

--_000_0F00DA11850C7146AEF5F0DD38701E620C07ABxmbalnx14ciscocom_-- From kippster@yahoo.com Fri Nov 2 10:03:35 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408F621F8E5B for ; Fri, 2 Nov 2012 10:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooZjkZCdVIA3 for ; Fri, 2 Nov 2012 10:03:34 -0700 (PDT) Received: from nm21-vm1.bullet.mail.ne1.yahoo.com (nm21-vm1.bullet.mail.ne1.yahoo.com [98.138.91.46]) by ietfa.amsl.com (Postfix) with ESMTP id 54D3721F8E57 for ; Fri, 2 Nov 2012 10:03:34 -0700 (PDT) Received: from [98.138.90.52] by nm21.bullet.mail.ne1.yahoo.com with NNFMP; 02 Nov 2012 17:03:31 -0000 Received: from [98.138.84.35] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 02 Nov 2012 17:03:31 -0000 Received: from [127.0.0.1] by smtp103.mail.ne1.yahoo.com with NNFMP; 02 Nov 2012 17:03:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351875811; bh=aQ612TznC1c9OAwwKaKtYYY8uEBaWxSm8jqmNKNgBaI=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer; b=DMhYM+2tH2syFRK0unIV+At9fGz/K6SZn3El+L8g1BdWCLauU/CNPgPi1IQj7ibcX+zKRxlHPR3TITHHAg87n9r378BcPj6rs1/iqsCPfbK1MNlsN3mBbZrrMFaKFVgFhKg6qEwln0dRp85qmdRS6ZRJ9faksFxaioishUdKSv0= X-Yahoo-Newman-Id: 27599.67794.bm@smtp103.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ARoykl4VM1kP9B3VWRezPHgNdl8g.YGUSddLFnRW0T1d3Hj 42h8zXRAlJhUMOxkBaYrnwWZPPYpQ.XP9TQUvjP9rX80pI_QTkaF6bMAVXQr 4hsHb4k4SNabcyWjWec9Wws4JvT8pegTYLLlqYjiSiIlXgjtbjriv5Goz4T0 eeACZrh7pkoXDBuPV9DGm_ZZAwkR7yHrxuSGbg4TgXBkhB2gd3.0xgFSyuey Hyso7AhAwrVnmQBi9LMOeAk752sjhjSMLqshrbyRuG.Xg8STrLLZ9c6WSHGT xT0Jgug5wRMdKFWN1kgRa4wEXuc.pvJBvbTDkgVvTbteB60lzC2i3rg_OWbj MYqf4rmCECFdqIQyPoJMaB3McO.r6.sKFwhOWqAcdqU3W0UAXAv2wc.91Hn8 98fWCGSvj8iilatTrZju6WueiFndBGk.EZFaMloSMRAu_xLjw.g9Yw4viXMt F2BZhB5UbDQ-- X-Yahoo-SMTP: HmLCT5SswBC7N.etVHWYSJO6E8PQ Received: from [10.42.105.172] (kippster@209.23.222.234 with plain) by smtp103.mail.ne1.yahoo.com with SMTP; 02 Nov 2012 10:03:30 -0700 PDT Content-Type: multipart/alternative; boundary="Apple-Mail=_02BE3279-D52E-4594-91A8-48E08B38EAE3" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Kipp Jones In-Reply-To: <0F00DA11850C7146AEF5F0DD38701E620C07AB@xmb-aln-x14.cisco.com> Date: Fri, 2 Nov 2012 13:03:30 -0400 Message-Id: References: <0F00DA11850C7146AEF5F0DD38701E620C07AB@xmb-aln-x14.cisco.com> To: "Brian Hart (brianh)" X-Mailer: Apple Mail (2.1499) Cc: "geopriv@ietf.org" Subject: Re: [Geopriv] Comments on updated draft-jones-geopriv-sigpos-survey X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 17:03:35 -0000 --Apple-Mail=_02BE3279-D52E-4594-91A8-48E08B38EAE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for you comments and questions Brian. It'll take me a little = longer to work up a proper response, just wanted to let you know I'm = working on it and appreciate the feedback! Cheers, Kipp On Nov 1, 2012, at 8:46 PM, "Brian Hart (brianh)" = wrote: > Hi Kipp > =20 > I am new to IETF so apologies if this email is coming at the wrong = time/wrong way =85 if so, please do redirect me. > =20 > Minor edits: > 1 "WiFi" =3D> "Wi-Fi", > 2 "regclass" =3D> "operatingclass" (802.11-2012 has changed = from Regulatory Classes to Operating Classes) [and, apologies, my review = is not complete yet] > 3 Magnetic anomaly data could be explicitly called out as an = observable environmental measurement in the abstract > =20 > Additional topics: > 4 The license describes usage conditions for the LIS, but = sometimes this is not enough ... assuming LIS->device->app, then how do = we express the idea that specific classes of devices or specific apps on = devices are licensed to use the survey information in computing location = but other classes of device or apps cannot? > 5 The LIS could be an end device or even an app (I realize = "LIS" is just a label, but the label appears to be limiting) > 6 Recall a certain large company has introduced "_nomap" for = AP privacy, but IEEE 802.11 is being asked to look at a more = standardized version of that. There could be some overlap between the = two efforts, which could be worthy of further study. > =20 > Basic question that I should probably know the answer to already: > 7 Is there a binary version of this schema? > =20 > Regards > Brian > =20 > =20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv --Apple-Mail=_02BE3279-D52E-4594-91A8-48E08B38EAE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Thanks for you comments and = questions Brian.  It'll take me a little longer to work up a proper = response, just wanted to let you know I'm working on it and appreciate = the = feedback!

Cheers,

Kipp


On Nov 1, 2012, at 8:46 PM, "Brian Hart = (brianh)" <brianh@cisco.com>= wrote:

Hi Kipp
I am new to IETF so = apologies if this email is coming at the wrong time/wrong way =85 if so, = please do redirect me.
Minor = edits:
 "WiFi" =3D> = "Wi-Fi",
 "regclass" = =3D> "operatingclass" (802.11-2012 has changed from Regulatory = Classes to Operating Classes) [and, apologies, my review is not complete = yet]
 Magnetic = anomaly data could be explicitly called out as an observable = environmental measurement in the abstract
 
4 The license = describes usage conditions for the LIS, but sometimes this is not enough = ... assuming LIS->device->app, then  how do we express the = idea that specific classes of devices or specific apps on devices are = licensed to use the survey information in computing location but other = classes of device or apps cannot?
5 The LIS could = be an end device or even an app (I realize "LIS" is just a label, but = the label appears to be limiting)
6 Recall a = certain large company has  introduced "_nomap" for AP privacy, but = IEEE 802.11 is being asked to look at a more standardized version of = that. There could be some overlap between the two efforts, which could = be worthy of further study.
Basic question that = I should probably know the answer to already:
7 Is there a = binary version of this schema?
In-Reply-To: Date: Mon, 5 Nov 2012 15:02:29 -0500 Message-Id: References: <0F00DA11850C7146AEF5F0DD38701E620C07AB@xmb-aln-x14.cisco.com> To: "Brian Hart (brianh)" X-Mailer: Apple Mail (2.1499) Cc: "geopriv@ietf.org" Subject: Re: [Geopriv] Comments on updated draft-jones-geopriv-sigpos-survey X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 20:02:39 -0000 --Apple-Mail=_C7AF1646-5768-4FA6-B304-195484C7500F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Brain, I haven't addressed these items in draft-01, but will cover them = in Atlanta on Wednesday and in a subsequent draft. See below for some = comments... On Nov 2, 2012, at 1:03 PM, Kipp Jones wrote: > Thanks for you comments and questions Brian. It'll take me a little = longer to work up a proper response, just wanted to let you know I'm = working on it and appreciate the feedback! >=20 > Cheers, >=20 > Kipp >=20 >=20 > On Nov 1, 2012, at 8:46 PM, "Brian Hart (brianh)" = wrote: >=20 >> Hi Kipp >> =20 >> I am new to IETF so apologies if this email is coming at the wrong = time/wrong way =85 if so, please do redirect me. >> =20 >> Minor edits: >> 1 "WiFi" =3D> "Wi-Fi", right, will correct in -02. >> 2 "regclass" =3D> "operatingclass" (802.11-2012 has changed = from Regulatory Classes to Operating Classes) [and, apologies, my review = is not complete yet] thanks, missed that one, will address in -02. >> 3 Magnetic anomaly data could be explicitly called out as an = observable environmental measurement in the abstract I like the idea. Just to be clear, you are talking about the 'Residual = total intensity of Earth's magnetic field' at each survey point? For = example the data available from the USGS? = http://mrdata.usgs.gov/metadata/usaeromag.faq.html =20 Are you aware of a standard format for this data or would that need to = be part of this specification? >> =20 >> Additional topics: >> 4 The license describes usage conditions for the LIS, but = sometimes this is not enough ... assuming LIS->device->app, then how do = we express the idea that specific classes of devices or specific apps on = devices are licensed to use the survey information in computing location = but other classes of device or apps cannot? Good question. I don't have a great answer yet. Let me chew on it some = more. >> 5 The LIS could be an end device or even an app (I realize = "LIS" is just a label, but the label appears to be limiting) I'm not sure I follow. In what instances would the end device or app be = the LIS? Certainly for location resolution it can be (e.g. on device = location resolution), do you see other scenarios in which this would be = the case? >> 6 Recall a certain large company has introduced "_nomap" for = AP privacy, but IEEE 802.11 is being asked to look at a more = standardized version of that. There could be some overlap between the = two efforts, which could be worthy of further study. Valid point, I'm just not sure this would/should be part of this = particular specification. Although I could see how we might want to = specify that any such standard SHOULD be followed by the survey device. >> =20 >> Basic question that I should probably know the answer to already: >> 7 Is there a binary version of this schema? No binary version available yet. Are you referring to something like = the Efficient XML Interchange (EFI), the binary xml format recommended = by W3C? Or are you referring to something different? Cheers, Kipp >> =20 >> Regards >> Brian >> =20 >> =20 >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv --Apple-Mail=_C7AF1646-5768-4FA6-B304-195484C7500F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 kippster@yahoo.com> = wrote:

Thanks for you comments and = questions Brian.  It'll take me a little longer to work up a proper = response, just wanted to let you know I'm working on it and appreciate = the = feedback!

Cheers,

Kipp


On Nov 1, 2012, at 8:46 PM, "Brian Hart = (brianh)" <brianh@cisco.com>= wrote:

Hi Kipp
I am new to IETF so = apologies if this email is coming at the wrong time/wrong way =85 if so, = please do redirect me.
Minor = edits:
 "WiFi" =3D> = "Wi-Fi",

right, will correct in -02.

2 "regclass" = =3D> "operatingclass" (802.11-2012 has changed from Regulatory = Classes to Operating Classes) [and, apologies, my review is not complete = yet]

thanks, missed that one, will address in = -02.


3 Magnetic = anomaly data could be explicitly called out as an observable = environmental measurement in the = abstract

I like the idea.  Just to be clear, you are = talking about the 'Residual total intensity of Earth's magnetic field' = at each survey point?  For example the data available from the = USGS? http://mrdata.= usgs.gov/metadata/usaeromag.faq.html =  

Are you aware of a standard format for = this data or would that need to be part of this = specification?


 
4 The license = describes usage conditions for the LIS, but sometimes this is not enough = ... assuming LIS->device->app, then  how do we express the = idea that specific classes of devices or specific apps on devices are = licensed to use the survey information in computing location but other = classes of device or apps = cannot?

Good question.  I don't have a great answer = yet.  Let me chew on it some more.

5 The LIS could = be an end device or even an app (I realize "LIS" is just a label, but = the label appears to be = limiting)


I'm not sure I follow.  In = what instances would the end device or app be the LIS?  Certainly = for location resolution it can be (e.g. on device location resolution), = do you see other scenarios in which this would be the = case?

6 Recall a = certain large company has  introduced "_nomap" for AP privacy, but = IEEE 802.11 is being asked to look at a more standardized version of = that. There could be some overlap between the two efforts, which could = be worthy of further = study.
=

Valid point, I'm just not sure this would/should be = part of this particular specification.  Although I could see how we = might want to specify that any such standard SHOULD be followed by the = survey device.

 
Basic = question that I should probably know the answer to = already:
 Is there a = binary version of this = schema?

No binary version available yet.  Are you referring = to something like the Efficient XML Interchange (EFI), the binary xml = format recommended by W3C?  Or are you referring to something = different?


Cheers,

<= /div>
Kipp


 
Geopriv@ietf.org
https://www.ietf.= org/mailman/listinfo/geopriv

= --Apple-Mail=_C7AF1646-5768-4FA6-B304-195484C7500F-- From kippster@yahoo.com Mon Nov 5 13:27:03 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8715321F8676 for ; Mon, 5 Nov 2012 13:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9P9neF+bbRt for ; Mon, 5 Nov 2012 13:27:02 -0800 (PST) Received: from nm3-vm5.bullet.mail.gq1.yahoo.com (nm3-vm5.bullet.mail.gq1.yahoo.com [98.136.218.148]) by ietfa.amsl.com (Postfix) with ESMTP id D695421F86B3 for ; Mon, 5 Nov 2012 13:27:01 -0800 (PST) Received: from [98.137.12.191] by nm3.bullet.mail.gq1.yahoo.com with NNFMP; 05 Nov 2012 21:27:01 -0000 Received: from [208.71.42.191] by tm12.bullet.mail.gq1.yahoo.com with NNFMP; 05 Nov 2012 21:27:01 -0000 Received: from [127.0.0.1] by smtp202.mail.gq1.yahoo.com with NNFMP; 05 Nov 2012 21:27:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1352150821; bh=vaq8SZHRxSRyvQNGh9zVwQt0UWPBA6zls80onj0b3NA=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer; b=VMCV6w9p6Tdx3fwsfmIe/MHL3UY1goBbfJeeV8/BrSl7qnK5JacY5UWPwgm07rjLDu/xwxJQQ/UuFTxFwfWzuQN76ylASZWjho2uu9FxhtXIpCF8JX4NYCCx1/v1eI4A0N6A8FB7rtkYrIknR5IB0h3OWyy5rux7XjRUl3g1p+E= X-Yahoo-Newman-Id: 104665.48256.bm@smtp202.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: LUDqRkYVM1kxPkIsPj.SdSIqhg_kbV9f94QlGD2xGsLT3TG khsnaadaKsoaT2VkjxnbLDmW6DtOArUPITMPzR1IxuiT8vke0SntEChfKw7_ RrtiGvbs08JM8_3XsdLfuabTfU98YpL5Z7YgYApAOIoQu4nwDvF9D9FZSMnz q3M8xc52SgBZ0PH40uTLYMtzaQnZCYyob4L60yIHGz4rBQJ_vTWiNEaQQbKu zchGFYfep0arU8KzqL3vZEi4XlVEwRLI4eBgKUJ9kNN9QRzDslneGAjDkiX5 Q_WCB5j6jpy0xelJ43tr2e1PDw_OYdLLZiDE.a2ysacynv5VD6ZEYrj4Rydp xq8FuO.m6gOC2l1OkXhTiWhZiVphQT_DkDQG0widQX0nVTDBsXQbW4UOKea2 mRjQkRiUXkp6gSJokyqqZFywmbhfXGdSb78u0L46sngd0HhmhUMrXlq_UO.h CXIasX_wZljx4fLgZRp0gJ6zWoIlee7yWdhvB.oESpufQ6idvJ.X4Pdg5HPx 6QGLfypMEiflv.dLP5yKohhvG9XjSEzrSdKrXc988anu1MFbDmH0uWZl.JQW sXw-- X-Yahoo-SMTP: HmLCT5SswBC7N.etVHWYSJO6E8PQ Received: from [10.42.105.172] (kippster@209.23.222.234 with plain) by smtp202.mail.gq1.yahoo.com with SMTP; 05 Nov 2012 13:27:00 -0800 PST Content-Type: multipart/alternative; boundary="Apple-Mail=_565C9ECC-54C4-41FF-8875-D59F4A36265E" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Kipp Jones In-Reply-To: Date: Mon, 5 Nov 2012 16:26:58 -0500 Message-Id: References: <0F00DA11850C7146AEF5F0DD38701E620C07AB@xmb-aln-x14.cisco.com> To: "Brian Hart (brianh)" X-Mailer: Apple Mail (2.1499) Cc: "geopriv@ietf.org" Subject: Re: [Geopriv] Comments on updated draft-jones-geopriv-sigpos-survey X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 21:27:03 -0000 --Apple-Mail=_565C9ECC-54C4-41FF-8875-D59F4A36265E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thoughts on the data licensing: I believe there are two orthogonal issues that are being 'bundled' in = the data license and it might make sense to explicitly peel these out = into distinct items and restructure that part of the specification. In particular, I believe the two intents for the data licensing are: 1) ensure that the data provided is not used by a location provider = (e.g. LIS) to derive additional beacon information in such a way as to = obviate the need for the original survey data. This is the 'no = derivative' clause. 2) provide access control to the location derived from the survey data. = In other words, a provider of survey data (licensor) may want to = restrict the location derived from the signal/beacon location data to = only a particular set of users or applications. Regardless of the specifics configuration of these two data constraints, = once a location is derived and the end device/user has been determined = to be authorized, the actual returned location is unencumbered by this = license. In other words, the license requirements apply only to the LIS/Location = provider and not to an end user. I'll go over this in person on Wednesday to solicit more feedback, but = feel free to respond at will. Cheers, Kipp On Nov 5, 2012, at 3:02 PM, Kipp Jones wrote: > Brain, I haven't addressed these items in draft-01, but will cover = them in Atlanta on Wednesday and in a subsequent draft. See below for = some comments... >=20 >=20 > On Nov 2, 2012, at 1:03 PM, Kipp Jones wrote: >=20 >> Thanks for you comments and questions Brian. It'll take me a little = longer to work up a proper response, just wanted to let you know I'm = working on it and appreciate the feedback! >>=20 >> Cheers, >>=20 >> Kipp >>=20 >>=20 >> On Nov 1, 2012, at 8:46 PM, "Brian Hart (brianh)" = wrote: >>=20 >>> Hi Kipp >>> =20 >>> I am new to IETF so apologies if this email is coming at the wrong = time/wrong way =85 if so, please do redirect me. >>> =20 >>> Minor edits: >>> 1 "WiFi" =3D> "Wi-Fi", >=20 > right, will correct in -02. >=20 >>> 2 "regclass" =3D> "operatingclass" (802.11-2012 has changed = from Regulatory Classes to Operating Classes) [and, apologies, my review = is not complete yet] >=20 > thanks, missed that one, will address in -02. >=20 >=20 >>> 3 Magnetic anomaly data could be explicitly called out as an = observable environmental measurement in the abstract >=20 > I like the idea. Just to be clear, you are talking about the = 'Residual total intensity of Earth's magnetic field' at each survey = point? For example the data available from the USGS? = http://mrdata.usgs.gov/metadata/usaeromag.faq.html =20 >=20 > Are you aware of a standard format for this data or would that need to = be part of this specification? >=20 >=20 >>> =20 >>> Additional topics: >>> 4 The license describes usage conditions for the LIS, but = sometimes this is not enough ... assuming LIS->device->app, then how do = we express the idea that specific classes of devices or specific apps on = devices are licensed to use the survey information in computing location = but other classes of device or apps cannot? >=20 > Good question. I don't have a great answer yet. Let me chew on it = some more. >=20 >>> 5 The LIS could be an end device or even an app (I realize = "LIS" is just a label, but the label appears to be limiting) >=20 >=20 > I'm not sure I follow. In what instances would the end device or app = be the LIS? Certainly for location resolution it can be (e.g. on device = location resolution), do you see other scenarios in which this would be = the case? >=20 >>> 6 Recall a certain large company has introduced "_nomap" = for AP privacy, but IEEE 802.11 is being asked to look at a more = standardized version of that. There could be some overlap between the = two efforts, which could be worthy of further study. >=20 > Valid point, I'm just not sure this would/should be part of this = particular specification. Although I could see how we might want to = specify that any such standard SHOULD be followed by the survey device. >=20 >>> =20 >>> Basic question that I should probably know the answer to already: >>> 7 Is there a binary version of this schema? >=20 > No binary version available yet. Are you referring to something like = the Efficient XML Interchange (EFI), the binary xml format recommended = by W3C? Or are you referring to something different? >=20 >=20 > Cheers, >=20 > Kipp >=20 >=20 >>> =20 >>> Regards >>> Brian >>> =20 >>> =20 >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www.ietf.org/mailman/listinfo/geopriv >>=20 >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv --Apple-Mail=_565C9ECC-54C4-41FF-8875-D59F4A36265E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 kippster@yahoo.com> = wrote:

kippster@yahoo.com> = wrote:

Thanks for you comments and = questions Brian.  It'll take me a little longer to work up a proper = response, just wanted to let you know I'm working on it and appreciate = the = feedback!

Cheers,

Kipp


On Nov 1, 2012, at 8:46 PM, "Brian Hart = (brianh)" <brianh@cisco.com>= wrote:

Hi Kipp
I am new to IETF so = apologies if this email is coming at the wrong time/wrong way =85 if so, = please do redirect me.
Minor = edits:
 "WiFi" =3D> = "Wi-Fi",

right, will correct in -02.

2 "regclass" = =3D> "operatingclass" (802.11-2012 has changed from Regulatory = Classes to Operating Classes) [and, apologies, my review is not complete = yet]

thank= s, missed that one, will address in = -02.


3 Magnetic = anomaly data could be explicitly called out as an observable = environmental measurement in the = abstract

I= like the idea.  Just to be clear, you are talking about the = 'Residual total intensity of Earth's magnetic field' at each survey = point?  For example the data available from the USGS? http://mrdata.= usgs.gov/metadata/usaeromag.faq.html =  

Are you aware of a standard format for = this data or would that need to be part of this = specification?


 
4 The license = describes usage conditions for the LIS, but sometimes this is not enough = ... assuming LIS->device->app, then  how do we express the = idea that specific classes of devices or specific apps on devices are = licensed to use the survey information in computing location but other = classes of device or apps = cannot?

Good question.  I don't have a great answer yet.  Let me = chew on it some more.
5 The LIS could = be an end device or even an app (I realize "LIS" is just a label, but = the label appears to be = limiting)

=

I'm not sure I follow.  In what instances would = the end device or app be the LIS?  Certainly for location = resolution it can be (e.g. on device location resolution), do you see = other scenarios in which this would be the = case?

6 Recall a = certain large company has  introduced "_nomap" for AP privacy, but = IEEE 802.11 is being asked to look at a more standardized version of = that. There could be some overlap between the two efforts, which could = be worthy of further = study.

Valid point, I'm just not sure this would/should be part of this = particular specification.  Although I could see how we might want = to specify that any such standard SHOULD be followed by the survey = device.

 
Basic = question that I should probably know the answer to = already:
 Is there a = binary version of this = schema?

No= binary version available yet.  Are you referring to something like = the Efficient XML Interchange (EFI), the binary xml format recommended = by W3C?  Or are you referring to something = different?


Cheers,
_____= __________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.= org/mailman/listinfo/geopriv

= --Apple-Mail=_565C9ECC-54C4-41FF-8875-D59F4A36265E-- From creed@opengeospatial.org Mon Nov 5 15:58:07 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4284221F87A3 for ; Mon, 5 Nov 2012 15:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bou9NeyA2fAY for ; Mon, 5 Nov 2012 15:58:06 -0800 (PST) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id CA8D421F85CB for ; Mon, 5 Nov 2012 15:58:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id BC881942E4; Mon, 5 Nov 2012 18:58:04 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (scale.ogcinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vV962W+jn0h2; Mon, 5 Nov 2012 18:58:03 -0500 (EST) Received: from OfficeHP (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail.opengeospatial.org (Postfix) with ESMTPSA id EA9789428C; Mon, 5 Nov 2012 18:58:02 -0500 (EST) Message-ID: From: "Carl Reed" To: "Kipp Jones" , "Brian Hart \(brianh\)" References: <0F00DA11850C7146AEF5F0DD38701E620C07AB@xmb-aln-x14.cisco.com> In-Reply-To: Date: Mon, 5 Nov 2012 16:53:05 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_036A_01CDBB76.06ABF480" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Cc: geopriv@ietf.org Subject: Re: [Geopriv] Comments on updated draft-jones-geopriv-sigpos-survey X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 23:58:07 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_036A_01CDBB76.06ABF480 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Kipp - There are a couple of OGC/ISO documents on geo-rights management, = including licensing, that you might be interested in. These documents = include use cases, requirements, a reference model, and so forth. http://www.opengeospatial.org/standards/as/geodrmrm for example. There are some excellent PP presentations and other supporting = materials. Cheers Carl From: Kipp Jones=20 Sent: Monday, November 05, 2012 2:26 PM To: Brian Hart (brianh)=20 Cc: geopriv@ietf.org=20 Subject: Re: [Geopriv] Comments on updated = draft-jones-geopriv-sigpos-survey Thoughts on the data licensing:=20 I believe there are two orthogonal issues that are being 'bundled' in = the data license and it might make sense to explicitly peel these out = into distinct items and restructure that part of the specification. In particular, I believe the two intents for the data licensing are: 1) ensure that the data provided is not used by a location provider = (e.g. LIS) to derive additional beacon information in such a way as to = obviate the need for the original survey data. This is the 'no = derivative' clause. 2) provide access control to the location derived from the survey data. = In other words, a provider of survey data (licensor) may want to = restrict the location derived from the signal/beacon location data to = only a particular set of users or applications. Regardless of the specifics configuration of these two data constraints, = once a location is derived and the end device/user has been determined = to be authorized, the actual returned location is unencumbered by this = license. In other words, the license requirements apply only to the LIS/Location = provider and not to an end user. I'll go over this in person on Wednesday to solicit more feedback, but = feel free to respond at will. Cheers, Kipp On Nov 5, 2012, at 3:02 PM, Kipp Jones wrote: Brain, I haven't addressed these items in draft-01, but will cover = them in Atlanta on Wednesday and in a subsequent draft. See below for = some comments...=20 On Nov 2, 2012, at 1:03 PM, Kipp Jones wrote: Thanks for you comments and questions Brian. It'll take me a little = longer to work up a proper response, just wanted to let you know I'm = working on it and appreciate the feedback!=20 Cheers, Kipp On Nov 1, 2012, at 8:46 PM, "Brian Hart (brianh)" = wrote: Hi Kipp =20 I am new to IETF so apologies if this email is coming at the wrong = time/wrong way =85 if so, please do redirect me. =20 Minor edits: 1 "WiFi" =3D> "Wi-Fi", right, will correct in -02. 2 "regclass" =3D> "operatingclass" (802.11-2012 has = changed from Regulatory Classes to Operating Classes) [and, apologies, = my review is not complete yet] thanks, missed that one, will address in -02. 3 Magnetic anomaly data could be explicitly called out as = an observable environmental measurement in the abstract I like the idea. Just to be clear, you are talking about the = 'Residual total intensity of Earth's magnetic field' at each survey = point? For example the data available from the USGS? = http://mrdata.usgs.gov/metadata/usaeromag.faq.html =20 Are you aware of a standard format for this data or would that need to = be part of this specification? =20 Additional topics: 4 The license describes usage conditions for the LIS, but = sometimes this is not enough ... assuming LIS->device->app, then how do = we express the idea that specific classes of devices or specific apps on = devices are licensed to use the survey information in computing location = but other classes of device or apps cannot? Good question. I don't have a great answer yet. Let me chew on it = some more. 5 The LIS could be an end device or even an app (I realize = "LIS" is just a label, but the label appears to be limiting) I'm not sure I follow. In what instances would the end device or app = be the LIS? Certainly for location resolution it can be (e.g. on device = location resolution), do you see other scenarios in which this would be = the case? 6 Recall a certain large company has introduced "_nomap" = for AP privacy, but IEEE 802.11 is being asked to look at a more = standardized version of that. There could be some overlap between the = two efforts, which could be worthy of further study. Valid point, I'm just not sure this would/should be part of this = particular specification. Although I could see how we might want to = specify that any such standard SHOULD be followed by the survey device. =20 Basic question that I should probably know the answer to already: 7 Is there a binary version of this schema? No binary version available yet. Are you referring to something like = the Efficient XML Interchange (EFI), the binary xml format recommended = by W3C? Or are you referring to something different? Cheers, Kipp =20 Regards Brian =20 =20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv -------------------------------------------------------------------------= ------- _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv ------=_NextPart_000_036A_01CDBB76.06ABF480 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Kipp -
 
There are a couple of OGC/ISO documents on geo-rights management, = including=20 licensing, that you might be interested in. These documents include use = cases,=20 requirements, a reference model, and so forth.
 
 
There are some excellent PP presentations and other supporting=20 materials.
 
Cheers

Carl
 
 
From: Kipp Jones
Sent: Monday, November 05, 2012 2:26 PM
Subject: Re: [Geopriv] Comments on updated=20 draft-jones-geopriv-sigpos-survey
 
Thoughts=20 on the data licensing:=20
 
I believe there are two orthogonal issues that are being 'bundled' = in the=20 data license and it might make sense to explicitly peel these out into = distinct=20 items and restructure that part of the specification.
 
In particular, I believe the two intents for the data licensing = are:
 
1) ensure that the data provided is not used by a location provider = (e.g.=20 LIS) to derive additional beacon information in such a way as to obviate = the=20 need for the original survey data.  This is the 'no derivative'=20 clause.
 
2) provide access control to the location derived from the survey = data. In=20 other words, a provider of survey data (licensor) may want to restrict = the=20 location derived from the signal/beacon location data to only a = particular set=20 of users or applications.
 
Regardless of the specifics configuration of these two data = constraints,=20 once a location is derived and the end device/user has been determined = to be=20 authorized, the actual returned location is unencumbered by this = license.
 
In other words, the license requirements apply only to the = LIS/Location=20 provider and not to an end user.
 
 
I'll go over this in person on Wednesday to solicit more feedback, = but feel=20 free to respond at will.
 
Cheers,
 
Kipp
 
 
On Nov 5, 2012, at 3:02 PM, Kipp Jones <kippster@yahoo.com> = wrote:
Brain,=20 I haven't addressed these items in draft-01, but will cover them in = Atlanta on=20 Wednesday and in a subsequent draft.  See below for some = comments...=20
 
 
On Nov 2, 2012, at 1:03 PM, Kipp Jones <kippster@yahoo.com> = wrote:

Thanks=20 for you comments and questions Brian.  It'll take me a little = longer to=20 work up a proper response, just wanted to let you know I'm working = on it and=20 appreciate the feedback!=20
 
Cheers,
 
Kipp
 
 
On Nov 1, 2012, at 8:46 PM, "Brian Hart (brianh)" <brianh@cisco.com> = wrote:
Hi=20 Kipp
 
I=20 am new to IETF so apologies if this email is coming at the wrong=20 time/wrong way =85 if so, please do redirect me.
 
Minor=20 edits:
1       =20  "WiFi" =3D>=20 = "Wi-Fi",
 
right, will correct in -02.

2       =20  "regclass"=20 =3D> "operatingclass" (802.11-2012 has changed from Regulatory = Classes to=20 Operating Classes) [and, apologies, my review is not complete=20 yet]
 
thanks, missed that one, will address in -02.
 

3       =20  Magnetic=20 anomaly data could be explicitly called out as an observable = environmental=20 measurement in the = abstract
 
I like the idea.  Just to be clear, you are = talking=20 about the 'Residual total intensity of Earth's magnetic field' at each = survey=20 point?  For example the data available from the USGS? http://mrdata= .usgs.gov/metadata/usaeromag.faq.html =20
 
Are you aware of a standard format for this data or would that = need to be=20 part of this specification?
 
 
 
Additional=20 topics: 4       =20  The = license=20 describes usage conditions for the LIS, but sometimes this is not = enough=20 ... assuming LIS->device->app, then  how do we express = the idea=20 that specific classes of devices or specific apps on devices are = licensed=20 to use the survey information in computing location but other = classes of=20 device or apps = cannot?
 
Good question.  I don't have a great answer yet.  Let = me chew=20 on it some more.

5       =20  The = LIS could=20 be an end device or even an app (I realize "LIS" is just a label, = but the=20 label appears to be=20 limiting)
 
 
I'm not sure I follow.  In what instances would the end = device or=20 app be the LIS?  Certainly for location resolution it can be = (e.g. on=20 device location resolution), do you see other scenarios in which this = would be=20 the case?
 
6       =20  Recall a=20 certain large company has  introduced "_nomap" for AP = privacy, but=20 IEEE 802.11 is being asked to look at a more standardized version = of that.=20 There could be some overlap between the two efforts, which could = be worthy=20 of further = study.
 
Valid point, I'm just not sure this would/should be part of this=20 particular specification.  Although I could see how we might want = to=20 specify that any such standard SHOULD be followed by the survey = device.
 
  Basic=20 question that I should probably know the answer to=20 already: 7       =20  Is = there a=20 binary version of this=20 schema?
 
No binary version available yet.  Are you = referring to=20 something like the Efficient XML Interchange (EFI), the binary xml = format=20 recommended by W3C?  Or are you referring to something = different?
 
 
Cheers,
 
Kipp
 

 
Regards
Brian    ______________________________________= _________
Geopriv=20 mailing list
Geopriv@ietf.org
https://www.ietf.o= rg/mailman/listinfo/geopriv
=
 
_______________________________________________Geopriv=20 mailing list
Geopriv@ietf.org
https://www.ietf.o= rg/mailman/listinfo/geopriv
=
 
____________________________________________= ___
Geopriv=20 mailing list
Geopriv@ietf.org
https://www.ietf= .org/mailman/listinfo/geopriv
 


_______________________________________________
Geopriv mailing=20 list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv=
------=_NextPart_000_036A_01CDBB76.06ABF480-- From brianh@cisco.com Tue Nov 6 09:35:25 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D5321F8738 for ; Tue, 6 Nov 2012 09:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.009 X-Spam-Level: X-Spam-Status: No, score=-10.009 tagged_above=-999 required=5 tests=[AWL=0.589, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80yfE-f09Eqq for ; Tue, 6 Nov 2012 09:35:20 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD8E21F8850 for ; Tue, 6 Nov 2012 09:35:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33762; q=dns/txt; s=iport; t=1352223318; x=1353432918; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Q2HbBrKcsGDSweasvGKW/JvV6rMvFIiQNEK132SPwmM=; b=PxXRtUhjC0d/kkeyrQL5hyCzOxXjVITUq4pl6u3hQMRtDJZ78hpdkdgo 1yGudc3uPGcksItM2mQVS3Cv2/DI55uWcY+klRUE856ilu5rBlU2g1nX8 zz9FroMPaEQ5t4We6YEOK0YnnsMAIUbVUy6d5CtVhEeDHiJWPMtrIbcO2 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFANhImVCtJV2c/2dsb2JhbABEgkmuSIk2AYhngQiCHgEBAQQBAQEPAQUPBkEGBRACAQgRAQMBAQsWAQYHJwsTAQMGCAEBBA4FCBqHVgMPC5wNj2SQSosbaBuFWWEDlCqCbYoXgyaBa4JvgWQXHg X-IronPort-AV: E=Sophos;i="4.80,722,1344211200"; d="scan'208,217";a="139385137" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 06 Nov 2012 17:35:17 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA6HZHQS015655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Nov 2012 17:35:17 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.218]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 11:35:16 -0600 From: "Brian Hart (brianh)" To: Kipp Jones Thread-Topic: [Geopriv] Comments on updated draft-jones-geopriv-sigpos-survey Thread-Index: Ac24kkPPev5h7qA9QQ2TXDqQkidMygAs6CgAAJ84fIAAAvNXAAAcWz4Q Date: Tue, 6 Nov 2012 17:35:15 +0000 Message-ID: <0F00DA11850C7146AEF5F0DD38701E620C3B7A@xmb-aln-x14.cisco.com> References: <0F00DA11850C7146AEF5F0DD38701E620C07AB@xmb-aln-x14.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.95] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19344.002 x-tm-as-result: No--50.666300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_0F00DA11850C7146AEF5F0DD38701E620C3B7Axmbalnx14ciscocom_" MIME-Version: 1.0 Cc: "geopriv@ietf.org" Subject: Re: [Geopriv] Comments on updated draft-jones-geopriv-sigpos-survey X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 17:35:25 -0000 --_000_0F00DA11850C7146AEF5F0DD38701E620C3B7Axmbalnx14ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kipp - many thanks for your thoughts - additional thoughts inline - B From: Kipp Jones [mailto:kippster@yahoo.com] Sent: Monday, November 05, 2012 1:27 PM To: Brian Hart (brianh) Cc: geopriv@ietf.org Subject: Re: [Geopriv] Comments on updated draft-jones-geopriv-sigpos-surve= y Thoughts on the data licensing: I believe there are two orthogonal issues that are being 'bundled' in the d= ata license and it might make sense to explicitly peel these out into disti= nct items and restructure that part of the specification. In particular, I believe the two intents for the data licensing are: 1) ensure that the data provided is not used by a location provider (e.g. L= IS) to derive additional beacon information in such a way as to obviate the= need for the original survey data. This is the 'no derivative' clause. 2) provide access control to the location derived from the survey data. In = other words, a provider of survey data (licensor) may want to restrict the = location derived from the signal/beacon location data to only a particular = set of users or applications. Regardless of the specifics configuration of these two data constraints, on= ce a location is derived and the end device/user has been determined to be = authorized, the actual returned location is unencumbered by this license. In other words, the license requirements apply only to the LIS/Location pro= vider and not to an end user. [Agreed - and the licensor is delegating responsibility to the LSI/Location= provider to perform some measure of (authentication)/authorization of the = end device/user, and performing that (A)A service is an explicit condition = of the license.] I'll go over this in person on Wednesday to solicit more feedback, but feel= free to respond at will. [Apologies that I cannot be there in person, but we have, I think, some pro= mising ideas to address the above use case, so would be very happy to work = with you offline to refine them into a more mature proposal.] Cheers, Kipp On Nov 5, 2012, at 3:02 PM, Kipp Jones > wrote: Brain, I haven't addressed these items in draft-01, but will cover them in = Atlanta on Wednesday and in a subsequent draft. See below for some comment= s... On Nov 2, 2012, at 1:03 PM, Kipp Jones > wrote: Thanks for you comments and questions Brian. It'll take me a little longer= to work up a proper response, just wanted to let you know I'm working on i= t and appreciate the feedback! Cheers, Kipp On Nov 1, 2012, at 8:46 PM, "Brian Hart (brianh)" > wrote: Hi Kipp I am new to IETF so apologies if this email is coming at the wrong time/wro= ng way ... if so, please do redirect me. Minor edits: 1 "WiFi" =3D> "Wi-Fi", [:)] right, will correct in -02. 2 "regclass" =3D> "operatingclass" (802.11-2012 has changed from Re= gulatory Classes to Operating Classes) [and, apologies, my review is not co= mplete yet] thanks, missed that one, will address in -02. [:)] 3 Magnetic anomaly data could be explicitly called out as an observ= able environmental measurement in the abstract I like the idea. Just to be clear, you are talking about the 'Residual tot= al intensity of Earth's magnetic field' at each survey point? For example = the data available from the USGS? http://mrdata.usgs.gov/metadata/usaeromag= .faq.html [Yes] Are you aware of a standard format for this data or would that need to be p= art of this specification? [Oops - more research required ... I was just at the conceptual/example sta= ge, and I suspect the details of what is needed to get this to work usefull= y will need some study first. Leave purely as an example, or omit if an ex= ample without a defined format is not appropriate?] Additional topics: 4 The license describes usage conditions for the LIS, but sometimes= this is not enough ... assuming LIS->device->app, then how do we express = the idea that specific classes of devices or specific apps on devices are l= icensed to use the survey information in computing location but other class= es of device or apps cannot? Good question. I don't have a great answer yet. Let me chew on it some mo= re. [As above, happy to work with you offline to refine some ideas.] 5 The LIS could be an end device or even an app (I realize "LIS" is= just a label, but the label appears to be limiting) I'm not sure I follow. In what instances would the end device or app be th= e LIS? Certainly for location resolution it can be (e.g. on device locatio= n resolution), do you see other scenarios in which this would be the case? [Agreed, I'm thinking of the LIS as potentially also residing within the en= d user device. At a high level, this is a complicated space and getting more complicated := (. At one extreme, we see aggregators like Skyhook providing a classic LSI.= At the other extreme we see one-stop-shop LBS app developers who do a site= survey and wrap that data directly in the app (or in a library that higher= -level developers can just compile in), so they're running a fingerprinting= alg directly in the app. The next step is for the app/library to be multi-= venue, and get such site survey information more locally from each venue. T= his is not a great architecture for reasons of power, latency and impaired = data-fusion, but people do it when they don't have better options. As well = we see examples of the location engine running in/under the OS and again re= trieving site survey information from a local server to form a location est= imate - and directly fuse it with other location sources such as GPS and se= nsors. This is a better architecture. But all architectures can work and ar= e complementary to a classic LSI - and geopriv makes a lot of sense in all = these cases for all the same reasons.] 6 Recall a certain large company has introduced "_nomap" for AP pr= ivacy, but IEEE 802.11 is being asked to look at a more standardized versio= n of that. There could be some overlap between the two efforts, which could= be worthy of further study. Valid point, I'm just not sure this would/should be part of this particular= specification. Although I could see how we might want to specify that any= such standard SHOULD be followed by the survey device. [Fair point that this is not really the right spec for such a purpose. Thin= king about your latter point, which was very stimulating, I was looking at = RFC4119 to confirm that "should" was used there too. Rather I found "permit= ted" - . " 'retransmission-allowed': When the value of this element is 'no', the Recipient of this Location Object is not permitted to share the enclosed Location Information, or the object as a whole, with other parties. When the value of this element is 'yes', distributing this Location is permitted (barring an existing out- of-band agreement or obligation to the contrary). " Since this group is about geopriv, and the "_nomap" seems to be a request (= that is onerous to invoke!) for geopriv, it seems appropriate for this spec= to offer it the same level of respect and protection as conventionally-re= quested geopriv. Ditto for anything that IEEE might standardize.] Basic question that I should probably know the answer to already: 7 Is there a binary version of this schema? No binary version available yet. Are you referring to something like the E= fficient XML Interchange (EFI), the binary xml format recommended by W3C? = Or are you referring to something different? [That's the reference - yes, many thanks!] Cheers, Kipp Regards Brian _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv --_000_0F00DA11850C7146AEF5F0DD38701E620C3B7Axmbalnx14ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kipp – many than= ks for your thoughts – additional thoughts inline - B

From: Kipp Jon= es [mailto:kippster@yahoo.com]
Sent: Monday, November 05, 2012 1:27 PM
To: Brian Hart (brianh)
Cc: geopriv@ietf.org
Subject: Re: [Geopriv] Comments on updated draft-jones-geopriv-sigpo= s-survey

 

Thoughts on the data licensing:

 

I believe there are two orthogonal issues that are b= eing 'bundled' in the data license and it might make sense to explicitly pe= el these out into distinct items and restructure that part of the specifica= tion.

 

In particular, I believe the two intents for the dat= a licensing are:

 

1) ensure that the data provided is not used by a lo= cation provider (e.g. LIS) to derive additional beacon information in such = a way as to obviate the need for the original survey data.  This is th= e 'no derivative' clause.

 

2) provide access control to the location derived fr= om the survey data. In other words, a provider of survey data (licensor) ma= y want to restrict the location derived from the signal/beacon location dat= a to only a particular set of users or applications.

 

Regardless of the specifics configuration of these t= wo data constraints, once a location is derived and the end device/user has= been determined to be authorized, the actual returned location is unencumb= ered by this license.

 

In other words, the license requirements apply only = to the LIS/Location provider and not to an end user.

[Agreed – and th= e licensor is delegating responsibility to the LSI/Location provider to per= form some measure of (authentication)/authorization of the end device/user,= and performing that (A)A service is an explicit condition of the license.]

 

I'll go over this in person on Wednesday to solicit = more feedback, but feel free to respond at will.

[Apologies that I cann= ot be there in person, but we have, I think, some promising ideas to addres= s the above use case, so would be very happy to work with you offline to re= fine them into a more mature proposal.]

 

Cheers,

 

Kipp

 

 

On Nov 5, 2012, at 3:02 PM, Kipp Jones <kippster@yahoo.com> wrote:=



Brain, I haven't addressed these items in draft-01, = but will cover them in Atlanta on Wednesday and in a subsequent draft. &nbs= p;See below for some comments...

 

 

On Nov 2, 2012, at 1:03 PM, Kipp Jones <kippster@yahoo.com> wrote:=



Thanks for you comments and questions Brian.  I= t'll take me a little longer to work up a proper response, just wanted to l= et you know I'm working on it and appreciate the feedback!

 

Cheers,

 

Kipp

 

 

On Nov 1, 2012, at 8:46 PM, "Brian Hart (brianh= )" <brianh@cisco.com> wr= ote:



Hi Kipp

 

I am new to IETF so apologies if this e= mail is coming at the wrong time/wrong way … if so, please do redirec= t me.

 

Minor edits:

1       &nb= sp; &= quot;WiFi" =3D> "Wi-Fi",

[J]

right, will correct in -02.

2         "regclass" =3D> "operatingclass" (802.11-2012 has changed from Regulator= y Classes to Operating Classes) [and, apologies, my review is not complete = yet]

 

thanks, missed that one, will address in -02.

[J]

3       &nb= sp; M= agnetic anomaly data could be explicitly called out as an observable environmental= measurement in the abstract

 

I like the idea.  Just to be clear, you are tal= king about the 'Residual total intensity of Earth's magnetic field' at each= survey point?  For example the data available from the USGS? http://mrdata.u= sgs.gov/metadata/usaeromag.faq.html  

[Yes]

Are you aware of a standard format for this data or = would that need to be part of this specification?

[Oops – more res= earch required … I was just at the conceptual/example stage, and I su= spect the details of what is needed to get this to work usefully will need = some study first. Leave purely as an example, or omit if an  example without a defined format is not appropriate?]

 

 

Additional topics:

4       &nb= sp; T= he license describes usage conditions for the LIS, but sometimes this is not = enough ... assuming LIS->device->app, then  how do we express th= e idea that specific classes of devices or specific apps on devices are lic= ensed to use the survey information in computing location but other classes of device or apps cannot?

 

Good question.  I don't have a great answer yet= .  Let me chew on it some more.

[As above, happy to wo= rk with you offline to refine some ideas.]

5       &nb= sp; T= he LIS could be an end device or even an app (I realize "LIS" is ju= st a label, but the label appears to be limiting)

 

 

I'm not sure I follow.  In what instances would= the end device or app be the LIS?  Certainly for location resolution = it can be (e.g. on device location resolution), do you see other scenarios = in which this would be the case?

[Agreed, I’m thi= nking of the LIS as potentially also residing within the end user device.

 

At a high level, this = is a complicated space and getting more complicated L. At one extreme, we see aggregators like Skyhook pro= viding a classic LSI. At the other extreme we see one-stop-shop LBS app dev= elopers who do a site survey and wrap that data directly in the app (or in a library that higher-level developer= s can just compile in), so they’re running a fingerprinting alg direc= tly in the app. The next step is for the app/library to be multi-venue, and= get such site survey information more locally from each venue. This is not a great architecture for reasons of p= ower, latency and impaired data-fusion, but people do it when they don̵= 7;t have better options. As well we see examples of the location engine run= ning in/under the OS and again retrieving site survey information from a local server to form a location estimate &#= 8211; and directly fuse it with other location sources such as GPS and sens= ors. This is a better architecture. But all architectures can work and are = complementary to a classic LSI – and geopriv makes a lot of sense in all these cases for all the same reasons.]

 <= /p>

6       &nb= sp; R= ecall a certain large company has  introduced "_nomap" for AP pri= vacy, but IEEE 802.11 is being asked to look at a more standardized version= of that. There could be some overlap between the two efforts, which could = be worthy of further study.

 

Valid point, I'm just not sure this would/should be = part of this particular specification.  Although I could see how we mi= ght want to specify that any such standard SHOULD be followed by the survey= device.

[Fair point that this = is not really the right spec for such a purpose. Thinking about your latter= point, which was very stimulating, I was looking at RFC4119 to confirm tha= t “should” was used there too. Rather I found “permitted” - .

=

'retransmission-allowed': When the value of this element i= s 'no', the

      Recipient of this Location = Object is not permitted to share the

      enclosed Location Informati= on, or the object as a whole, with

      other parties.  When t= he value of this element is 'yes',

      distributing this Location = is permitted (barring an existing out-

      of-band agreement or = obligation to the contrary). 

=

Since this group is about= geopriv, and the “_nomap” seems to be a request (that is onero= us to invoke!) for geopriv, it seems appropriate for this spec  to off= er it the same level of respect and protection as conventionally-requested ge= opriv. Ditto for anything that IEEE might standardize.]

 

Basic question that I should probably k= now the answer to already:

7       &nb= sp; I= s there a binary version of this schema?

 

No binary version available yet.  Are you refer= ring to something like the Efficient XML Interchange (EFI), the binary xml = format recommended by W3C?  Or are you referring to something differen= t?

[That’s the refe= rence – yes, many thanks!]

 

Cheers,

 

Kipp

 



 

Regards

Brian

 

 

_____________________________________= __________
Geopriv mailing list
Geopriv@ie= tf.org
https://www.ietf.org/mailman/listinfo/geopriv

 

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.= org/mailman/listinfo/geopriv

 

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

 

--_000_0F00DA11850C7146AEF5F0DD38701E620C3B7Axmbalnx14ciscocom_-- From Ray.Bellis@nominet.org.uk Tue Nov 6 09:48:11 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1FD21F85C6 for ; Tue, 6 Nov 2012 09:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4b4oB6v4pEA for ; Tue, 6 Nov 2012 09:48:09 -0800 (PST) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id D4F7E21F87F2 for ; Tue, 6 Nov 2012 09:48:07 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=ghI+HLa7ZK29/KiLnMa5XXKYO8k1Uht5DJb3slQtb6SaE27W8WKyIGVV UHz7aZseVeKWNRmvEcfQGljagGdI0Lb0XN1XBfM3qa/i2ioOgmpTo0jhJ jnJwd/ON40xZwEV; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1352224089; x=1383760089; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Flow=20Identity=20Draft|Date:=20Tue,=206=20No v=202012=2017:47:58=20+0000|Message-ID:=20<61AB09FA-2276- 43B6-8ACC-1CE8258F84D4@nominet.org.uk>|To:=20"geopriv@iet f.org=20WG"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<7e91f179-a305-46d6-84ee-8b1c8924bb3b>; bh=2JEyYJdgWn3dZUsodCDBPn3dRoCTWNZhdpgRlL5K2dk=; b=r/xWNa8FsnzzoxdjHfCtojepP2WpnFYK351q2UJ33uGRHlvXsIXeCkFB mI5QXQ6h0OYGDDggL/Gt8vFWlrEcSsS2ouws6QllTtRGMHpP7SexmeA3c qO71VpNi+SRJBeG; X-IronPort-AV: E=Sophos;i="4.80,723,1344207600"; d="scan'208";a="36559593" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 06 Nov 2012 17:47:58 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi; Tue, 6 Nov 2012 17:47:58 +0000 From: Ray Bellis To: "geopriv@ietf.org WG" Thread-Topic: Flow Identity Draft Thread-Index: AQHNvEbbOxNbJmGlZUOU+fpliG7DvQ== Date: Tue, 6 Nov 2012 17:47:58 +0000 Message-ID: <61AB09FA-2276-43B6-8ACC-1CE8258F84D4@nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <7e91f179-a305-46d6-84ee-8b1c8924bb3b> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Geopriv] Flow Identity Draft X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 17:48:11 -0000 I understand that the chairs are planning to finish the WGLC on the Flow Id= entity draft during Thursday's meeting. If you haven't already, please give it a quick read. The draft is very sho= rt, and uncontentious. AIUI, the chairs just need enough people to confirm= they're happy with it so it can be pushed to the IESG. https://datatracker.ietf.org/doc/draft-ietf-geopriv-flow-identity/ thanks, Ray From Ray.Bellis@nominet.org.uk Tue Nov 6 09:52:16 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2056D21F8B13 for ; Tue, 6 Nov 2012 09:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZvmt3i7fMF1 for ; Tue, 6 Nov 2012 09:52:15 -0800 (PST) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id 253B121F8AC3 for ; Tue, 6 Nov 2012 09:52:14 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=FlZdXIjiFunYVrIdlTyx9hEH4hfnH2/dlMHcRNX94Qq++pedl3GIY/8d taiu8IMm/CKALlwBFYzAYMgKu1Xi5CEZXt+rwpi6ByqpmAA59zo4oMbOg dLbQ77T95B1C6J3; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1352224335; x=1383760335; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[Geopriv]=20Flow=20Identity=20Draft |Date:=20Tue,=206=20Nov=202012=2017:52:14=20+0000 |Message-ID:=20|To:=20"geopriv@ietf.org=20WG"=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20qu oted-printable|Content-ID:=20<7a3a949b-e92f-43fb-9f09-c83 d97d891c1>|In-Reply-To:=20<61AB09FA-2276-43B6-8ACC-1CE825 8F84D4@nominet.org.uk>|References:=20<61AB09FA-2276-43B6- 8ACC-1CE8258F84D4@nominet.org.uk>; bh=b5NKMTqbj00ObL4Rvsz5bscPbhpS6ir5fNNHofKntpE=; b=o/LBjeQyzn9PbAQawTXNMyKANS3lS+YoktkcDXKXB+kAt4n7tVqggbRw xQx5kTA7qg1x8dzhoHidl6zvqPNLoQA/L9qTlhyP/8A/lOfjsErbQpt46 gJzvkvSXfUJjWNU; X-IronPort-AV: E=Sophos;i="4.80,723,1344207600"; d="scan'208";a="44439308" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 06 Nov 2012 17:52:14 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi; Tue, 6 Nov 2012 17:52:13 +0000 From: Ray Bellis To: "geopriv@ietf.org WG" Thread-Topic: [Geopriv] Flow Identity Draft Thread-Index: AQHNvEdzWIc54aBTkkagqj5mNCwSIw== Date: Tue, 6 Nov 2012 17:52:14 +0000 Message-ID: References: <61AB09FA-2276-43B6-8ACC-1CE8258F84D4@nominet.org.uk> In-Reply-To: <61AB09FA-2276-43B6-8ACC-1CE8258F84D4@nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <7a3a949b-e92f-43fb-9f09-c83d97d891c1> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Geopriv] Flow Identity Draft X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 17:52:16 -0000 On 6 Nov 2012, at 12:47, Ray Bellis wrote: > I understand that the chairs are planning to finish the WGLC on the Flow = Identity draft during Thursday's meeting. s/Thursday/Wednesday/ oops! Ray From martin.thomson@gmail.com Wed Nov 7 12:15:33 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC16821F8CBC for ; Wed, 7 Nov 2012 12:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.008 X-Spam-Level: X-Spam-Status: No, score=-4.008 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdjLenTPo-OT for ; Wed, 7 Nov 2012 12:15:32 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 972AD21F8A12 for ; Wed, 7 Nov 2012 12:15:31 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id k13so1739534lbo.31 for ; Wed, 07 Nov 2012 12:15:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZsA4KPVY11LJ/CwcGtiostWVf0Azk99CJ/BtWBJ4tQ8=; b=nixT82uLAWmhLd7o49IgfxuswhBMsVO9L8HGGUm+8hN/4c8SJEcCc8arurlwplb9Nq yZtMmCHZ1w4qciaAqUZR+tq3gSeBNaPaxIOJrOmQsHdqgJ1LNktdhy5T/UOiKvompIiU R6t8J2EiQLbJh9Lt1ZE0fyvZosfvjns4/2E+k/U8TK8p5y4uDtCuqvFLv+Cr9kFuzIo2 ATHIavVKAQnTq2VxHEyJDQkBP/cXQ386YciDQkMKYgpfL3fDNTGJbBcK8Lbl7gWpoXul d1yOolRkkbdBNfM5ljI7ad0/kr45tq0L3AzY+MHLAlYMwMPNpssVI7x3HsmM3iGh2M4Z Bi2g== MIME-Version: 1.0 Received: by 10.112.28.169 with SMTP id c9mr2317051lbh.59.1352319329930; Wed, 07 Nov 2012 12:15:29 -0800 (PST) Received: by 10.112.83.2 with HTTP; Wed, 7 Nov 2012 12:15:29 -0800 (PST) Date: Wed, 7 Nov 2012 15:15:29 -0500 Message-ID: From: Martin Thomson To: GEOPRIV WG Content-Type: text/plain; charset=UTF-8 Subject: [Geopriv] draft-jones-geopriv-sigpos-survey-01 section-10 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 20:15:34 -0000 I see that this is largely cribbed from HELD. We made a number of choices for HELD that were ...special. These were as a consequence of the source address validation that is required by the protocol. These considerations should not apply to this application. Copying HELD is not appropriate. --Martin From rbarnes@bbn.com Wed Nov 7 12:20:18 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEB821F8CAE for ; Wed, 7 Nov 2012 12:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.099 X-Spam-Level: X-Spam-Status: No, score=-107.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CT3xOWCQX8sI for ; Wed, 7 Nov 2012 12:20:14 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9598F21F8C63 for ; Wed, 7 Nov 2012 12:20:13 -0800 (PST) Received: from [128.89.253.79] (port=57850) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TWC6d-000Eld-4V; Wed, 07 Nov 2012 15:20:11 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Richard L. Barnes" In-Reply-To: Date: Wed, 7 Nov 2012 15:20:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <119A358E-71EE-47A5-953B-5A74D5623B1B@bbn.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.1499) Cc: GEOPRIV WG Subject: Re: [Geopriv] draft-jones-geopriv-sigpos-survey-01 section-10 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 20:20:18 -0000 Yeah, this section is pretty pro-forma. Honestly, I think it can be safely deleted. Adam commented at IETF84 = that he expected some protocol aspect to this, but it seems to me that = (1) we have tons of ways to pass around XML documents, and (2) we don't = really know right now which one of those will make sense in a larger = system. So it's fine to focus this on the XML syntax, and that can drop = into transports later.=20 On Nov 7, 2012, at 3:15 PM, Martin Thomson = wrote: > I see that this is largely cribbed from HELD. >=20 > We made a number of choices for HELD that were ...special. These > were as a consequence of the source address validation that is > required by the protocol. These considerations should not apply to > this application. Copying HELD is not appropriate. >=20 > --Martin > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From jopicken@cisco.com Wed Nov 7 12:22:15 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29CC21F8CC4 for ; Wed, 7 Nov 2012 12:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYTxoPreqQNw for ; Wed, 7 Nov 2012 12:22:14 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC8121F8CB3 for ; Wed, 7 Nov 2012 12:22:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1563; q=dns/txt; s=iport; t=1352319725; x=1353529325; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2FN56VhrUxOGwWfB2vD+4+/uT65udIsMiUJuf+NNRS0=; b=MkLZnHrbFbEQAhWbV0kdjNN9jEu5ysV3ZM2hGvzBRiG7hkHI1VU4g3rR XUk0DOBPtSoZG6IIRI8eW7QK6+GE1woZnMxXdrupMFe1GXlnMN0unUVK+ Q6vvc+mUUR7pnbufcYyG8niHhb67JKMzddcIRbn2w9m0jNHZHLvRLLE7g 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFABvCmlCtJV2d/2dsb2JhbABEw2qBCIIeAQEBAwEBAQEPAQUiNAsFBwQCAQgRBAEBCxQJByEGCxQJCAIEAQ0FCBqHVgMJBgucMJZRDYlQBIskaYVmYQOUJo0IgyaBa4JvgV0kGA X-IronPort-AV: E=Sophos;i="4.80,732,1344211200"; d="scan'208";a="139854733" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 07 Nov 2012 20:22:05 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA7KM5ah007196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 20:22:05 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.234]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 14:22:04 -0600 From: "John Pickens (jopicken)" To: "Richard L. Barnes" , Martin Thomson Thread-Topic: [Geopriv] draft-jones-geopriv-sigpos-survey-01 section-10 Thread-Index: AQHNvSSoqUR9Irp470uBrZ5/vARjMJffNOAA//+btrA= Date: Wed, 7 Nov 2012 20:22:03 +0000 Message-ID: References: <119A358E-71EE-47A5-953B-5A74D5623B1B@bbn.com> In-Reply-To: <119A358E-71EE-47A5-953B-5A74D5623B1B@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.8.16] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19346.005 x-tm-as-result: No--26.767500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: GEOPRIV WG Subject: Re: [Geopriv] draft-jones-geopriv-sigpos-survey-01 section-10 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 20:22:16 -0000 Also noticed the three tiers of metadata, including "rights", and "hardware= ". These elements seem out of scope. =20 J -----Original Message----- From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf = Of Richard L. Barnes Sent: Wednesday, November 07, 2012 3:20 PM To: Martin Thomson Cc: GEOPRIV WG Subject: Re: [Geopriv] draft-jones-geopriv-sigpos-survey-01 section-10 Yeah, this section is pretty pro-forma. Honestly, I think it can be safely deleted. Adam commented at IETF84 that = he expected some protocol aspect to this, but it seems to me that (1) we ha= ve tons of ways to pass around XML documents, and (2) we don't really know = right now which one of those will make sense in a larger system. So it's f= ine to focus this on the XML syntax, and that can drop into transports late= r.=20 On Nov 7, 2012, at 3:15 PM, Martin Thomson wrote= : > I see that this is largely cribbed from HELD. >=20 > We made a number of choices for HELD that were ...special. These=20 > were as a consequence of the source address validation that is=20 > required by the protocol. These considerations should not apply to=20 > this application. Copying HELD is not appropriate. >=20 > --Martin > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv From martin.thomson@gmail.com Wed Nov 7 12:25:46 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C48C21F8B71 for ; Wed, 7 Nov 2012 12:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.962 X-Spam-Level: X-Spam-Status: No, score=-3.962 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hn7T4HfbGjcR for ; Wed, 7 Nov 2012 12:25:45 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2199821F8889 for ; Wed, 7 Nov 2012 12:25:32 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id k13so1747112lbo.31 for ; Wed, 07 Nov 2012 12:25:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=N0FywWCXYOHdWqMEDfsi9y+7RBKy+4qlEW6QWNw2AJQ=; b=bUJBklmuH87s6Lj6+yU3hrnpajxevl7na+6o1l3XbMeKNagR+67ltRX/yWmWffVYH6 JEybUYVBDAzKfAdfH4JAedq1F+FZvNpcU/DU6IxUhl72EPD2lCPDniUk+bIvUdUbIoAK VespFYAPhhoyw4FMCXfZ76Gx/UJQOp9WT/Kc3866lvug+4K+qom6g6JHbroc+sicpb/S lX/m0CtBawPNfGa/5HbWn9CIQiW1P5xyA5w0iusKe9iqHFxWMql970eakS7cMq0H9rnJ S5Rjtjj1RE+uUNTJbQVVRPX3HjU9G72dc/V/bvieS3laeaUZH4MC95AsWelNqXnj01yJ h2+Q== MIME-Version: 1.0 Received: by 10.152.148.40 with SMTP id tp8mr5363323lab.30.1352319931710; Wed, 07 Nov 2012 12:25:31 -0800 (PST) Received: by 10.112.83.2 with HTTP; Wed, 7 Nov 2012 12:25:31 -0800 (PST) In-Reply-To: <119A358E-71EE-47A5-953B-5A74D5623B1B@bbn.com> References: <119A358E-71EE-47A5-953B-5A74D5623B1B@bbn.com> Date: Wed, 7 Nov 2012 15:25:31 -0500 Message-ID: From: Martin Thomson To: "Richard L. Barnes" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: GEOPRIV WG Subject: Re: [Geopriv] draft-jones-geopriv-sigpos-survey-01 section-10 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 20:25:46 -0000 I was going to make exactly the same comment. While context is valuable, I don't see a need for the definition of a protocol. On 7 November 2012 15:20, Richard L. Barnes wrote: > Yeah, this section is pretty pro-forma. > > Honestly, I think it can be safely deleted. Adam commented at IETF84 tha= t he expected some protocol aspect to this, but it seems to me that (1) we = have tons of ways to pass around XML documents, and (2) we don't really kno= w right now which one of those will make sense in a larger system. So it's= fine to focus this on the XML syntax, and that can drop into transports la= ter. > > > On Nov 7, 2012, at 3:15 PM, Martin Thomson wro= te: > >> I see that this is largely cribbed from HELD. >> >> We made a number of choices for HELD that were ...special. These >> were as a consequence of the source address validation that is >> required by the protocol. These considerations should not apply to >> this application. Copying HELD is not appropriate. >> >> --Martin >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv > From kippster@yahoo.com Wed Nov 7 13:27:17 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603CC21F8889 for ; Wed, 7 Nov 2012 13:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlTO02DHFKuf for ; Wed, 7 Nov 2012 13:27:16 -0800 (PST) Received: from nm29-vm1.bullet.mail.ne1.yahoo.com (nm29-vm1.bullet.mail.ne1.yahoo.com [98.138.90.63]) by ietfa.amsl.com (Postfix) with ESMTP id 5050721F8AF0 for ; Wed, 7 Nov 2012 13:27:16 -0800 (PST) Received: from [98.138.90.55] by nm29.bullet.mail.ne1.yahoo.com with NNFMP; 07 Nov 2012 21:27:13 -0000 Received: from [98.138.226.127] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 07 Nov 2012 21:27:13 -0000 Received: from [127.0.0.1] by smtp206.mail.ne1.yahoo.com with NNFMP; 07 Nov 2012 21:27:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1352323633; bh=jS4v9OZkaXf0gQwhwoR9MDSonw3t8L29Trh4hej6Uws=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=R3HNlkL+Pj+letxUP/clftVk13oiaznJLf1AcTtdTEC5HCGWC6g1246Ta6PA3e09SS/IhPraZe/t3fANL5aLDOnvQGOIpY1wgpW1JXJc+bglz/PaEfunCPYIgv1w5ABtnePH9l9GrGTFMAIYpNmYGHOde0oBTx7c8i+sL7KkmVo= X-Yahoo-Newman-Id: 241622.4860.bm@smtp206.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 3i.DCcgVM1mcw1bVcSN7pmxyoTnHDYiKxA3Y3.MM9ZVg1QM Ix6i75i48SNv6bjlLsJcL.opWIQpyN7wluia4JPkBrs_PmsrvhTRV7P9Qx9h wO_ZFa5d47WXObhmz2qtGIdaSHRz4NcVkoukQwVk8_2r0pyI4zKy65JZ3.wE KpiFDJHhtMXTV.GM5.06c7wDbhNj1iguRjC0b7vFXDdviZZk40qRE3T7vPQx Flm01aa4_EPe.6GcpR.WQU4b.N_1GNmQvMgpeQvopxcSpnRLCuedOBgc23Wr hRvKbU0GsfXBXRPNAD2igQJ3FCnLtWLfxcmthq5roaah9ynnovPC9huc4EN0 jul61ijjUk1DeB7JIN6oWi4AglGxdOuUEvV_ah_CzBrcBy3kdrGjaSQrsTbZ TQpq78.1jQ6PImf.ozpfTnvyJKZaKWroFTSCpjHvQ3QzdMeiUJjKL2elczbr zSdMwaVYZ X-Yahoo-SMTP: HmLCT5SswBC7N.etVHWYSJO6E8PQ Received: from dhcp-1536.meeting.ietf.org (kippster@130.129.21.54 with plain) by smtp206.mail.ne1.yahoo.com with SMTP; 07 Nov 2012 13:27:13 -0800 PST Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Kipp Jones In-Reply-To: Date: Wed, 7 Nov 2012 16:27:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <119A358E-71EE-47A5-953B-5A74D5623B1B@bbn.com> To: Martin Thomson X-Mailer: Apple Mail (2.1499) Cc: GEOPRIV WG Subject: Re: [Geopriv] draft-jones-geopriv-sigpos-survey-01 section-10 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 21:27:17 -0000 Fair enough, thanks for the feedback...happy to proceed without it. Kipp On Nov 7, 2012, at 3:25 PM, Martin Thomson = wrote: > I was going to make exactly the same comment. While context is > valuable, I don't see a need for the definition of a protocol. >=20 > On 7 November 2012 15:20, Richard L. Barnes wrote: >> Yeah, this section is pretty pro-forma. >>=20 >> Honestly, I think it can be safely deleted. Adam commented at IETF84 = that he expected some protocol aspect to this, but it seems to me that = (1) we have tons of ways to pass around XML documents, and (2) we don't = really know right now which one of those will make sense in a larger = system. So it's fine to focus this on the XML syntax, and that can drop = into transports later. >>=20 >>=20 >> On Nov 7, 2012, at 3:15 PM, Martin Thomson = wrote: >>=20 >>> I see that this is largely cribbed from HELD. >>>=20 >>> We made a number of choices for HELD that were ...special. These >>> were as a consequence of the source address validation that is >>> required by the protocol. These considerations should not apply to >>> this application. Copying HELD is not appropriate. >>>=20 >>> --Martin >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www.ietf.org/mailman/listinfo/geopriv >>=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From ammar.salih@auis.edu.iq Sat Nov 10 07:05:34 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D76321F8622 for ; Sat, 10 Nov 2012 07:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7ROkM6keK0t for ; Sat, 10 Nov 2012 07:05:28 -0800 (PST) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with SMTP id B598F21F85F3 for ; Sat, 10 Nov 2012 07:05:27 -0800 (PST) Received: from mail-ee0-f70.google.com ([74.125.83.70]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKUJ5tNoAjnh4ONpnzGILIqalkEMstF130@postini.com; Sat, 10 Nov 2012 07:05:27 PST Received: by mail-ee0-f70.google.com with SMTP id d4so94133eek.1 for ; Sat, 10 Nov 2012 07:05:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language:x-gm-message-state; bh=ygui1i6RnwUHIE5p3BV0nJyEqvBmt17A46KveaX9eaw=; b=UzVvB/PKaLa5elKQ6pFxQ3W2bQ4GelZK+vhR+tvODTpRAeDPTVPa+9TccR1Sc120No eq+6UqEqEiM31jOK+zuM5NFK8osDDqvEdyuFmFtUheTOOoUHnPqmmKgWh8RcGD8o7i8E mRh32Ek9fX/OPXd3OC2ivxznG7Ra2rlY21jenXwXF5rMzyjJe00UMqLn5MXlFL52JsQK GKe145/nFDroi49Wgm/k7rBO5A/kBK08CGKAKPHKEcggmxJdvCzQB4ADNaFkGCZA5b4y syO1bzonntcEyaHDE1QRmVR7y5X2S2NP6n2nUFFvFm58Z5dutVTlCjOT6TbFdINMw54E j9Yw== Received: by 10.14.193.134 with SMTP id k6mr5485587een.15.1352559925650; Sat, 10 Nov 2012 07:05:25 -0800 (PST) Received: by 10.14.193.134 with SMTP id k6mr5485576een.15.1352559925510; Sat, 10 Nov 2012 07:05:25 -0800 (PST) Received: from AMMARSALIH ([37.237.187.220]) by mx.google.com with ESMTPS id f2sm3983557eep.2.2012.11.10.07.05.17 (version=SSLv3 cipher=OTHER); Sat, 10 Nov 2012 07:05:24 -0800 (PST) From: "Ammar Salih" To: Date: Sat, 10 Nov 2012 18:05:11 +0300 Message-ID: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01CDBF6D.F2530540" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2/VMZri4Yb+IJ0QpqrzX+gy+wtKA== Content-Language: en-us X-Gm-Message-State: ALoCoQmacM0dUVyuXK4VAUqoFLGZ7Hu65JX0/Xhj29VkG8ll5c+iKnI9oeW0xQO7Lv8+k5j6NXtjkBPvKqrxDMtKtF2TWTLo0e+0hIBvPy2RD6NODNtO6zRLM8mf9oTejewinXJhUPt2z8zW1Ji6snpyEEYvmHmoqw== Cc: geopriv@ietf.org Subject: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 15:05:34 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000D_01CDBF6D.F2530540 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello IETF, based on my discussions with both ipv6 and geopriv teams, I've written the below document to summarize few ideas. Is it possible to publish this on IETF website? even if it will not be implemented now, at least for documentation and requesting feedback from the community. Many thanks. Ammar Ammar J. Salih Baghdad, Iraq October 30, 2012 Title: IP-LOC Adding GPS location to IPv6 header Abstract: ========= This document describes IP-LOC, an extension to IPv6 header which suggests adding GPS coordinates, as the current method of determining the location of IP traffic is through IP address registration database, which is not very accurate as it depends on how the ISP registers its IP subnets, that is normally done in a country/city format. It also assumes that in the future, GPS capability will be added to the router itself (just like smart phones) and packet marking and classification based on geo-location will be required. QoS, firewall and routing based on geo-location will be highly required when mobile routers move from one geo-location to another which has different policy. Benefits of adding GPS location to IPv6 header (IP-LOC) ======================================================= Web Services: getting more accurate locations will enhance many services provided by the web, like targeted commercials (for example, I can get Ads regarding restaurants available in my neighborhoods instead of all restaurants in the city), another good example would be webpage's language, my language will be detected more accurately based on my area rather than my country, as there are many countries with more than one popular language, not mentioning that many ip registrations does not even reflect the traffic originating country. ------------------------------- Information accuracy and control: Nowadays, locations are assigned to IP addresses without user awareness or control, every time a user performs ip-lookup query the response would be different based on how the ISP has registered this IP subnet, IP-LOC suggests making locations more accurate and controllable through OS and network devices, exactly like IP addresses (user can change his/her IP address, but router can also modify the header information - in case it's required). ------------------------------- Routing: Policy based routing, based on geo-location, like routing predefined traffic through certain server or path, for different purposes (security, manageability, serviceability like choosing language, or routing traffic to specific cashing or proxy server based on country .. etc) ------------------------------- Copyright law: It happens when certain media/web content is not allowed in certain countries due to copyright law, the current method of determining locations is not accurate at all, on other hand, If layer-7 application to be used then the user might be able to manipulate the location field, in this case (if it's required in future) the ISP can tag traffic with country/city more accurately as traffic passes through ISP's boarder routers. ------------------------------- Maps, navigation, emergency calls and many other services will be also enhanced with accurate locations. CURRENT ARGUMENTS AGAINST THIS IDEA: ======================================== "Adding GPS position to every IPv6 header would add a lot of overhead" Response: It does not have to be in every IPv6 header, only when there is location update, also the host should have the option of not to send location updates. ------------------------------- "What about privacy?" Response: User should have the option of not sending location updates. User should also have the ability to set location to all zeros, in this case no router will modify the location field and user loses the location-based services. If it's router-to-router link, then no need to be worried about privacy as such information usually configured on a separate network. -------------------------------- "a good alternative would be to create application layer protocols that could request and send GPS positions" Response: the layer-7 location request will not be detected by layer-3 devices (Routers), I am assuming that in the future, GPS capability will be added to the router itself (just like smart phones), features like packet marking and classification based on geo-location will be required to enforce the new geo-location policies. -------------------------------- "For location-based routing protocols: Why would you want this? Geographical location isn't actually that important a metric for routing; what you care about there is *topological* location, how far I am away from you in terms of hops or latency" Response: For shortest path maybe yes, hops or latency is important, not for policy-based routing, in our case you might want to do location-based routing, like, routing traffic coming from French speaking users (in multi-language country like Canada) to google.fr --------------------------------- "For geolocation-based ACLs: you have the problem that if the geolocation is attached by the endpoint, then it can't be trusted, since the endpoint would lie to get past the ACL. If it's attached by a router, the ACL needs to have proof that the router attached it (and not the endpoint), which means that you would need a signed geolocation header" Response: You could have the router modify the location field anyways, just like L3 QoS fields, if you don't trust the host, so no need for encryption or security, additionally, ACL is not only for security, it could be used for routing, QoS ..etc, so the host will not always has the motivation to manipulate the location field. --------------------------------- "Why can't you simply implement rules related to geo-locations statically on the network device (router, firewall .. etc)?" Response: To enforce new geo-location policies automatically, let's assume that a mobile router (like a mobile BTS in a GSM network) moved from city-x to city-y, and according to city-x regulations VoIP calls over GSM network is allowed, but city-y regulations do not allow that. Now the topology may reflect same network metrics in both cities but there is no rule that triggers configuration change based on geo-location. --------------------------------- What do you think? Author/Contact Information: Ammar J. Salih Baghdad, Iraq Phone: +964 770 533 0306 Email: ammar.alsalih@gmail.com ------=_NextPart_000_000D_01CDBF6D.F2530540 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello IETF, = based on my discussions with both ipv6 and geopriv teams, I’ve = written the below document to summarize few = ideas.

Is it possible = to publish this on IETF website? even if it will not be implemented now, = at least for documentation and requesting feedback from the = community.

 

Many = thanks.

Ammar=

 

 

Ammar J. = Salih

Baghdad, = Iraq           =

October 30, = 2012

Title: = IP-LOC

 

 

   =             &= nbsp;     

Adding GPS location to IPv6 header

 

Abstract:

=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

   This = document describes IP-LOC, an extension to IPv6 header which suggests = adding GPS coordinates, as the current method of determining the = location of IP traffic is through IP address registration database, = which is not very accurate as it depends on how the ISP registers its IP = subnets, that is normally done in a country/city = format.

 

It also assumes = that in the future, GPS capability will be added to the router itself = (just like smart phones) and packet marking and classification based on = geo-location will be required.

 

QoS, firewall and = routing based on geo-location will be highly required when mobile = routers move from one geo-location to another which has different = policy.

 

 

 

 

 

Benefits of = adding GPS location to IPv6 header (IP-LOC)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 

 

Web Services: getting more accurate locations will = enhance many services provided by the web, like targeted commercials = (for example, I can get Ads regarding restaurants available in my = neighborhoods instead of all restaurants in the city), another good = example would be webpage’s language, my language will be detected = more accurately based on my area rather than my country, as there are = many countries with more than one popular language, not mentioning that = many ip registrations does not even reflect the traffic originating = country.

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

 

Information accuracy and control: Nowadays, = locations are assigned to IP addresses without user awareness or = control, every time a user performs ip-lookup query the response would = be different based on how the ISP has registered this IP subnet, IP-LOC = suggests making locations more accurate and controllable through OS and = network devices, exactly like IP addresses (user can change his/her IP = address, but router can also modify the header information - in case = it's required).

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

 

Routing: Policy based = routing, based on geo-location, like routing predefined traffic through = certain server or path, for different purposes (security, manageability, = serviceability like choosing language, or routing traffic to specific = cashing or proxy server based on country .. etc)

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

 

Copyright law: It happens = when certain media/web content is not allowed in certain countries due = to copyright law, the current method of determining locations is not = accurate at all, on other hand, If layer-7 application to be used then = the user might be able to manipulate the location field, in this case = (if it’s required in future) the ISP can tag traffic with = country/city more accurately as traffic passes through ISP’s = boarder routers.

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

 

Maps, = navigation, emergency calls and many other services will be also = enhanced with accurate locations.

 

 

 

 

CURRENT ARGUMENTS AGAINST =
THIS IDEA:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

“Adding GPS position to every IPv6 = header would add a lot of overhead”

 

Response: It does not have to be in every IPv6 = header, only when there is location update, also the host should have = the option of not to send location updates.

 

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

 

“What about privacy?”

 

Response: User should have the option of not = sending location updates. User should also have the ability to set = location to all zeros, in this case no router will modify the location = field and user loses the location-based services.

 

If = it’s router-to-router link, then no need to be worried about = privacy as such information usually configured on a separate = network.

 

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

 

“a good alternative would be to create = application layer protocols that could request and send GPS = positions”

 

Response: the layer-7 location request will not be = detected by layer-3 devices (Routers), I am assuming that in the future, = GPS capability will be added to the router itself (just like smart = phones), features like packet marking and classification based on = geo-location will be required to enforce the new geo-location = policies.

 

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

 

“For location-based routing protocols: Why = would you want this?  Geographical location isn't actually that = important a metric for routing; what you care about there is = *topological* location, how far I am away from you in terms of hops or = latency”

 

Response: For shortest path maybe yes, hops or = latency is important, not for policy-based routing, in our case you = might want to do location-based routing, like, routing traffic coming = from French speaking users (in multi-language country like Canada) to = google.fr

 

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

 

“For geolocation-based ACLs: you have the = problem that if the geolocation is attached by the endpoint, then it = can't be trusted, since the endpoint would lie to get past the = ACL.  If it's attached by a router, the ACL needs to have proof = that the router attached it (and not the endpoint), which means that you = would need a signed geolocation header”

 

Response: You could have the router modify the = location field anyways, just like L3 QoS fields, if you don't trust the = host, so no need for encryption or security, additionally,  ACL is = not only for security, it could be used for routing, QoS ..etc, so the = host will not always has the motivation to manipulate the location = field.

 

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

 

“Why can’t you simply implement rules = related to geo-locations statically on the network device (router, = firewall .. etc)?”

 

Response: To enforce new geo-location policies = automatically, let’s assume that a mobile router (like a mobile = BTS in a GSM network) moved from city-x to city-y, and according to = city-x regulations VoIP calls over GSM network is allowed, but city-y = regulations do not allow that. Now the topology may reflect same network = metrics in both cities but there is no rule that triggers configuration = change based on geo-location.

 

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

 

 

What do you = think?

 

 

Author/Contact = Information:

 

   = Ammar J. Salih

   = Baghdad, Iraq

 

   = Phone: +964 770 533 0306

   = Email: ammar.alsalih@gmail.com<= /o:p>

 

------=_NextPart_000_000D_01CDBF6D.F2530540-- From ammar.salih@auis.edu.iq Sun Nov 11 14:15:22 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED0921F8502 for ; Sun, 11 Nov 2012 14:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJu4kIhi3BJv for ; Sun, 11 Nov 2012 14:15:16 -0800 (PST) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with SMTP id 1B58221F84E6 for ; Sun, 11 Nov 2012 14:15:15 -0800 (PST) Received: from mail-bk0-f70.google.com ([209.85.214.70]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKUKAjc7S8DfGAJd06gL7/yK+kAUtwqkdo@postini.com; Sun, 11 Nov 2012 14:15:16 PST Received: by mail-bk0-f70.google.com with SMTP id jk13so4379218bkc.1 for ; Sun, 11 Nov 2012 14:15:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=2r2h7SA6Ni7EGzyzLeSjQEd/6DLYI8QKsRK2iE3u6BM=; b=dwsBRqIgErTSKuszHyJhzCAGXnu1g//sOSUX8MOu9P0cl5Ld+Xe4jafbL22rhISNPc WsNu4s9zHQJ/M2LFTaMN8LPMV3EST1xYQzPSWm1SupY3sop+y2SsN+ZeTpoyyZlpYWKk Jman6twCGtxNGGfY0kPhGO0ogbEgwEJ1lQah/XlYSaieIKcqu98LK9nJTnq0c4gRYCaH KaWNmXrWsDMEdcGr3qP0jP8UMGyvRQ0sqZFwov8YgZPiG56h5PJYs/BknYBLs9+O4Z/o YRU39yfJj9f4RCHnvj8qQocYBgAhE4dOv279L8jBYenRVuacqe41pxLAAADiIOKlQSJA BSXg== Received: by 10.14.179.69 with SMTP id g45mr57135383eem.42.1352672114200; Sun, 11 Nov 2012 14:15:14 -0800 (PST) Received: by 10.14.179.69 with SMTP id g45mr57135370eem.42.1352672114102; Sun, 11 Nov 2012 14:15:14 -0800 (PST) Received: from AMMARSALIH ([37.237.134.134]) by mx.google.com with ESMTPS id c6sm12303910eep.17.2012.11.11.14.15.11 (version=SSLv3 cipher=OTHER); Sun, 11 Nov 2012 14:15:13 -0800 (PST) From: "Ammar Salih" To: "'Eitan Adler'" References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> In-Reply-To: Date: Mon, 12 Nov 2012 01:15:07 +0300 Message-ID: <50a02371.86d60e0a.4f2d.02f1@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3AL297kpihIUG6TnCCup7Csk+eJwAHHb5A Content-Language: en-us X-Gm-Message-State: ALoCoQkIYQqYZRX6b2XjYR6jTuMizIEHInZLjSUxOAZdbuzFRytghGPxh/Zv3J3yDT0pst0dYm0Y0QjhxikUw5IPAjJL/EBQNN7flH84PWgFnXJbCBN/a/B8lkgOXWcUqbCooUrWIy1nc6jX9Nli11N3XaDNoFJdpg== Cc: geopriv@ietf.org, ipv6@ietf.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 22:15:22 -0000 > another good example would be webpage=E2=80=99s language, my language = will be=20 > detected more accurately based on my area rather than my country, > This is a very bad idea. There are already mechanisms for determining=20 > preferred languages. =20 If those mechanisms are successful then why websites like google do not = use them? They use IP address instead, and it's not always about http = applications, how about VoIP applications, now you need another = mechanism? .. how about detecting your preferred language for layer-3 = routing? > In many cases people don't speak the language of the area they are = located. Not many cases, maybe only while you are travelling to certain places of = a language that you don't speak, in that rare case you can manually = change the language via whatever application you are using. >as there are many countries with more than one popular language, not=20 >mentioning that many ip registrations does not even reflect the traffic = =20 >originating country. >Why does this need to be in the IP header? There already exist=20 >application layer mechanisms for obtaining location information. >Leaving it at the application layer also allows for appropriate privacy = >UI controls. I've explained this in previous parts of the document, mainly because = Layer-3 devices won't be able to recognize the feature, and also to = unify the location implementations at different layers. > Routing: Policy based routing, based on geo-location, like routing=20 > predefined traffic through certain server or path, for different=20 > purposes (security, manageability, serviceability like choosing=20 > language, or routing traffic to specific cashing or proxy server based = > on country .. etc) >This is the only somewhat sane use case I could see for this = information.=20 >Even then, location of the originating request isn't always the correct = >item to route on. It doesn't have to be always .. at least now you partially agree :) > Copyright law: It happens when certain media/web content is not=20 > allowed in certain countries due to copyright law, the current method=20 > of determining locations is not accurate at all, on other hand, If=20 > layer-7 application to be used then the user might be able to=20 > manipulate the location field, in this case (if it=E2=80=99s required = in=20 > future) the ISP can tag traffic with country/city more accurately as=20 > traffic passes through ISP=E2=80=99s boarder routers. > The user can manipulate or control the lower layer IP traffic too. If=20 > they can't this is an absurd privacy violation. Users currently have absolutely *NO* control over IP<->location mapping, = it's totally how your IP owner has registered the IP subnet, what I am = suggesting is that your local ISP *can* tag the city location "if it's = required", unless you want to share your exact location or set the = location to all zeros, in this case you are asking the ISP not to tag = your location, but in this case you give up all location based services. > Maps, navigation, emergency calls and many other services will be also = > enhanced with accurate locations. > Once again - this should be done at the application layer. > Response: It does not have to be in every IPv6 header, only when there = > is location update, also the host should have the option of not to=20 > send location updates. > Didn't you just mention above that information would be added by ISP=20 > routers I said under the copyright law section "(if it=E2=80=99s required in = future) the ISP can tag traffic with country/city more accurately as = traffic passes through ISP=E2=80=99s boarder routers" ... which means = the user has the option to put his/her real location, or set the = location field to all zeros, or leave it without location tagging .. = *BUT* if it's required by the government/or any other organization or = third party in the future for the sake of protecting the copyright laws = then the feature will be available to support that as well. > Response: For shortest path maybe yes, hops or latency is important,=20 > not for policy-based routing, in our case you might want to do=20 > location-based routing, like, routing traffic coming from French=20 > speaking users (in multi-language country like Canada) to google.fr > I'm not sure what you mean here. It is easy to redirect users from=20 > google.com -> google.fr based on their application layer language=20 > preference. Google.fr example is confusing many people, which I will modify, policy = based routing has much more than routing tcp:80 traffic.=20 -- Eitan Adler From bob.hinden@gmail.com Sun Nov 11 08:49:56 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217E821F85B4; Sun, 11 Nov 2012 08:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.51 X-Spam-Level: X-Spam-Status: No, score=-103.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vcq9iHY79O2; Sun, 11 Nov 2012 08:49:55 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1DA21F854C; Sun, 11 Nov 2012 08:49:54 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so2367917eaa.31 for ; Sun, 11 Nov 2012 08:49:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=a82f6ESVdvTCk8dGwQ5odq0KLY5aZSrzqTwNE6U56mo=; b=0wPGmzONDGzqNiTirgL0hYBKKLQRVxoQxeBBIdhDsRu8QjgPbo+qcc/uhRF2uwD55Z O26FsRJxf+jSZtjuCT1iN5jKuk5wpcK/1gTtJ15iw6b1Zm7TC/NVG41sNY23HzujQCXI 0i9DQoss8Oy5e8jECwb2UbBGzbimfe7h7ZghH/zT2Q4vsqYL2TCGjhsqZ2oCHxcuQHFY XmBpHSa7AkI/NQY47YK61uJkhKNyZBEL6Ot2zb1z1YxYr2zNDDOevmYRig4/x5CcrF0K 3U8fhJXGb9gOTR36xDR8mkT5a7S3rlEAhmsdB3NXGXLm1fRqOKbdu/BEUlPDKwwUbGH4 U67A== Received: by 10.14.184.1 with SMTP id r1mr55259633eem.4.1352652593367; Sun, 11 Nov 2012 08:49:53 -0800 (PST) Received: from [10.0.0.38] (c-24-130-151-138.hsd1.ca.comcast.net. [24.130.151.138]) by mx.google.com with ESMTPS id k2sm10747697eep.15.2012.11.11.08.49.51 (version=SSLv3 cipher=OTHER); Sun, 11 Nov 2012 08:49:53 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Bob Hinden In-Reply-To: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> Date: Sun, 11 Nov 2012 11:49:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2822260E-F9AF-464D-95A2-01FEE9D598DC@gmail.com> References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> To: Ammar Salih X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Sun, 11 Nov 2012 16:26:27 -0800 Cc: geopriv@ietf.org, ipv6@ietf.org, Bob Hinden Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 16:49:56 -0000 Ammar, On Nov 10, 2012, at 10:05 AM, Ammar Salih wrote: > Hello IETF, based on my discussions with both ipv6 and geopriv teams, = I=92ve written the below document to summarize few ideas. >=20 > Is it possible to publish this on IETF website? even if it will not be = implemented now, at least for documentation and requesting feedback from = the community. The best procedure for presenting new ideas to the IETF is to write an = Internet Draft. Suggest you take a look at the IETF web site at http://www.ietf.org. = Especially: Getting started in the IETF: http://www.ietf.org/newcomers.html =20 The Tao of IETF: http://www.ietf.org/tao.html Procedures to submit an Internet Draft: http://www.ietf.org/id-info/ Regards, Bob =20 >=20 > =20 >=20 > Many thanks. >=20 > Ammar >=20 > =20 >=20 > =20 >=20 > Ammar J. Salih > Baghdad, Iraq =20 > October 30, 2012 > Title: IP-LOC > =20 > =20 > =20 > Adding GPS location to IPv6 header > =20 > Abstract: > =3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > This document describes IP-LOC, an extension to IPv6 header which = suggests adding GPS coordinates, as the current method of determining = the location of IP traffic is through IP address registration database, = which is not very accurate as it depends on how the ISP registers its IP = subnets, that is normally done in a country/city format. > =20 > It also assumes that in the future, GPS capability will be added to = the router itself (just like smart phones) and packet marking and = classification based on geo-location will be required. > =20 > QoS, firewall and routing based on geo-location will be highly = required when mobile routers move from one geo-location to another which = has different policy. > =20 > =20 > =20 > =20 > =20 > Benefits of adding GPS location to IPv6 header (IP-LOC) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > =20 > =20 > Web Services: getting more accurate locations will enhance many = services provided by the web, like targeted commercials (for example, I = can get Ads regarding restaurants available in my neighborhoods instead = of all restaurants in the city), another good example would be webpage=92s= language, my language will be detected more accurately based on my area = rather than my country, as there are many countries with more than one = popular language, not mentioning that many ip registrations does not = even reflect the traffic originating country. >=20 > ------------------------------- > =20 > Information accuracy and control: Nowadays, locations are assigned to = IP addresses without user awareness or control, every time a user = performs ip-lookup query the response would be different based on how = the ISP has registered this IP subnet, IP-LOC suggests making locations = more accurate and controllable through OS and network devices, exactly = like IP addresses (user can change his/her IP address, but router can = also modify the header information - in case it's required). >=20 > ------------------------------- > =20 >=20 > Routing: Policy based routing, based on geo-location, like routing = predefined traffic through certain server or path, for different = purposes (security, manageability, serviceability like choosing = language, or routing traffic to specific cashing or proxy server based = on country .. etc) >=20 > ------------------------------- > =20 >=20 > Copyright law: It happens when certain media/web content is not = allowed in certain countries due to copyright law, the current method of = determining locations is not accurate at all, on other hand, If layer-7 = application to be used then the user might be able to manipulate the = location field, in this case (if it=92s required in future) the ISP can = tag traffic with country/city more accurately as traffic passes through = ISP=92s boarder routers. >=20 > ------------------------------- > =20 > Maps, navigation, emergency calls and many other services will be also = enhanced with accurate locations. > =20 > =20 > =20 > =20 >=20 > CURRENT ARGUMENTS AGAINST THIS IDEA: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > =93Adding GPS position to every IPv6 header would add a lot of = overhead=94 > =20 > Response: It does not have to be in every IPv6 header, only when there = is location update, also the host should have the option of not to send = location updates. > =20 > ------------------------------- > =20 > =93What about privacy?=94 > =20 > Response: User should have the option of not sending location updates. = User should also have the ability to set location to all zeros, in this = case no router will modify the location field and user loses the = location-based services. > =20 > If it=92s router-to-router link, then no need to be worried about = privacy as such information usually configured on a separate network. > =20 > -------------------------------- > =20 > =93a good alternative would be to create application layer protocols = that could request and send GPS positions=94 > =20 > Response: the layer-7 location request will not be detected by layer-3 = devices (Routers), I am assuming that in the future, GPS capability will = be added to the router itself (just like smart phones), features like = packet marking and classification based on geo-location will be required = to enforce the new geo-location policies. > =20 > -------------------------------- > =20 > =93For location-based routing protocols: Why would you want this? = Geographical location isn't actually that important a metric for = routing; what you care about there is *topological* location, how far I = am away from you in terms of hops or latency=94 > =20 > Response: For shortest path maybe yes, hops or latency is important, = not for policy-based routing, in our case you might want to do = location-based routing, like, routing traffic coming from French = speaking users (in multi-language country like Canada) to google.fr > =20 > --------------------------------- > =20 > =93For geolocation-based ACLs: you have the problem that if the = geolocation is attached by the endpoint, then it can't be trusted, since = the endpoint would lie to get past the ACL. If it's attached by a = router, the ACL needs to have proof that the router attached it (and not = the endpoint), which means that you would need a signed geolocation = header=94 > =20 > Response: You could have the router modify the location field anyways, = just like L3 QoS fields, if you don't trust the host, so no need for = encryption or security, additionally, ACL is not only for security, it = could be used for routing, QoS ..etc, so the host will not always has = the motivation to manipulate the location field. > =20 > --------------------------------- > =20 > =93Why can=92t you simply implement rules related to geo-locations = statically on the network device (router, firewall .. etc)?=94 > =20 > Response: To enforce new geo-location policies automatically, let=92s = assume that a mobile router (like a mobile BTS in a GSM network) moved = from city-x to city-y, and according to city-x regulations VoIP calls = over GSM network is allowed, but city-y regulations do not allow that. = Now the topology may reflect same network metrics in both cities but = there is no rule that triggers configuration change based on = geo-location. > =20 >=20 > --------------------------------- > =20 >=20 > =20 > What do you think? > =20 > =20 > Author/Contact Information: > =20 > Ammar J. Salih > Baghdad, Iraq > =20 > Phone: +964 770 533 0306 > Email: ammar.alsalih@gmail.com > =20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From shane@castlepoint.net Sun Nov 11 09:08:57 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE30121F857C for ; Sun, 11 Nov 2012 09:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.436 X-Spam-Level: X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvFWYARO8rIN for ; Sun, 11 Nov 2012 09:08:56 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7A36321F855B for ; Sun, 11 Nov 2012 09:08:56 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 465BE20D0 for ; Sun, 11 Nov 2012 17:08:55 +0000 (UTC) Received: from mbp.castlepoint.net (174-29-211-99.hlrn.qwest.net [174.29.211.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 0019720C5; Sun, 11 Nov 2012 10:08:53 -0700 (MST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E54385E1-BE28-44C1-9CBC-3E927D8A899D" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> Date: Sun, 11 Nov 2012 10:08:52 -0700 Message-Id: <0859AA2F-2972-4168-90DD-8A42B8C349C9@castlepoint.net> References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> To: Ammar Salih X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sun Nov 11 10:08:55 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 509fdba7199631804121297 X-DSPAM-Factors: 27, Information+#+#+#+Baghdad, 0.40000, Information+#+#+#+Baghdad, 0.40000, the+DNS, 0.40000, the+DNS, 0.40000, targeted+#+for, 0.40000, targeted+#+for, 0.40000, proof+#+the, 0.40000, proof+#+the, 0.40000, awareness+#+#+#+time, 0.40000, awareness+#+#+#+time, 0.40000, To*Ammar+Salih, 0.40000, salih+#+#+#+wrote, 0.40000, salih+#+#+#+wrote, 0.40000, suggests+#+#+#+as, 0.40000, suggests+#+#+#+as, 0.40000, configuration+#+#+#+geo, 0.40000, configuration+#+#+#+geo, 0.40000, depends+#+#+the, 0.40000, depends+#+#+the, 0.40000, targeted+#+the, 0.40000, targeted+#+the, 0.40000, city+#+#+do, 0.40000, city+#+#+do, 0.40000, not+#+#+#+layer, 0.40000, not+#+#+#+layer, 0.40000, able+#+#+the, 0.40000, able+#+#+the, 0.40000 X-Mailman-Approved-At: Sun, 11 Nov 2012 16:26:27 -0800 Cc: geopriv@ietf.org, "ipv6@ietf.org List" Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 17:08:58 -0000 --Apple-Mail=_E54385E1-BE28-44C1-9CBC-3E927D8A899D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ammar, Instead of adding GeoLoc information in an IPv6 Extension Header, you = may wish to take a look at past & current attempts to *potentially* = encode such information in the DNS. The most recent proposal to do so = is the following: http://tools.ietf.org/html/draft-gersch-dnsop-revdns-cidr-03 Take a look at Appendix A for specific encoding examples that are = possible within the DNS, with currently shipping BIND 9. I base this on = production deployment experience of encoding IP prefixes in the reverse = DNS tree, as per draft-gersch, although *not* for geolocation = information, but rather for SRO (Secure Route Origin) RR's. If you're = interested in draft-gersch-dnsop-revdns-cidr, it is targeted at the = DNSOP WG of the IETF, so you may wish to subscribe to that mailing list = and discuss it over there. Lastly, I would note that the above complements RFC 1876 & RFC 2317 by = providing a nomenclature for "better" encoding of VLSM (Variable Length = Subnet Mask) IP prefixes in the reverse DNS tree. -shane On Nov 10, 2012, at 8:05 AM, Ammar Salih = wrote: > Hello IETF, based on my discussions with both ipv6 and geopriv teams, = I=92ve written the below document to summarize few ideas. >=20 > Is it possible to publish this on IETF website? even if it will not be = implemented now, at least for documentation and requesting feedback from = the community. >=20 > =20 >=20 > Many thanks. >=20 > Ammar >=20 > =20 >=20 > =20 >=20 > Ammar J. Salih > Baghdad, Iraq =20 > October 30, 2012 > Title: IP-LOC > =20 > =20 > =20 > Adding GPS location to IPv6 header > =20 > Abstract: > =3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > This document describes IP-LOC, an extension to IPv6 header which = suggests adding GPS coordinates, as the current method of determining = the location of IP traffic is through IP address registration database, = which is not very accurate as it depends on how the ISP registers its IP = subnets, that is normally done in a country/city format. > =20 > It also assumes that in the future, GPS capability will be added to = the router itself (just like smart phones) and packet marking and = classification based on geo-location will be required. > =20 > QoS, firewall and routing based on geo-location will be highly = required when mobile routers move from one geo-location to another which = has different policy. > =20 > =20 > =20 > =20 > =20 > Benefits of adding GPS location to IPv6 header (IP-LOC) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > =20 > =20 > Web Services: getting more accurate locations will enhance many = services provided by the web, like targeted commercials (for example, I = can get Ads regarding restaurants available in my neighborhoods instead = of all restaurants in the city), another good example would be webpage=92s= language, my language will be detected more accurately based on my area = rather than my country, as there are many countries with more than one = popular language, not mentioning that many ip registrations does not = even reflect the traffic originating country. >=20 > ------------------------------- > =20 > Information accuracy and control: Nowadays, locations are assigned to = IP addresses without user awareness or control, every time a user = performs ip-lookup query the response would be different based on how = the ISP has registered this IP subnet, IP-LOC suggests making locations = more accurate and controllable through OS and network devices, exactly = like IP addresses (user can change his/her IP address, but router can = also modify the header information - in case it's required). >=20 > ------------------------------- > =20 >=20 > Routing: Policy based routing, based on geo-location, like routing = predefined traffic through certain server or path, for different = purposes (security, manageability, serviceability like choosing = language, or routing traffic to specific cashing or proxy server based = on country .. etc) >=20 > ------------------------------- > =20 >=20 > Copyright law: It happens when certain media/web content is not = allowed in certain countries due to copyright law, the current method of = determining locations is not accurate at all, on other hand, If layer-7 = application to be used then the user might be able to manipulate the = location field, in this case (if it=92s required in future) the ISP can = tag traffic with country/city more accurately as traffic passes through = ISP=92s boarder routers. >=20 > ------------------------------- > =20 > Maps, navigation, emergency calls and many other services will be also = enhanced with accurate locations. > =20 > =20 > =20 > =20 >=20 > CURRENT ARGUMENTS AGAINST THIS IDEA: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > =93Adding GPS position to every IPv6 header would add a lot of = overhead=94 > =20 > Response: It does not have to be in every IPv6 header, only when there = is location update, also the host should have the option of not to send = location updates. > =20 > ------------------------------- > =20 > =93What about privacy?=94 > =20 > Response: User should have the option of not sending location updates. = User should also have the ability to set location to all zeros, in this = case no router will modify the location field and user loses the = location-based services. > =20 > If it=92s router-to-router link, then no need to be worried about = privacy as such information usually configured on a separate network. > =20 > -------------------------------- > =20 > =93a good alternative would be to create application layer protocols = that could request and send GPS positions=94 > =20 > Response: the layer-7 location request will not be detected by layer-3 = devices (Routers), I am assuming that in the future, GPS capability will = be added to the router itself (just like smart phones), features like = packet marking and classification based on geo-location will be required = to enforce the new geo-location policies. > =20 > -------------------------------- > =20 > =93For location-based routing protocols: Why would you want this? = Geographical location isn't actually that important a metric for = routing; what you care about there is *topological* location, how far I = am away from you in terms of hops or latency=94 > =20 > Response: For shortest path maybe yes, hops or latency is important, = not for policy-based routing, in our case you might want to do = location-based routing, like, routing traffic coming from French = speaking users (in multi-language country like Canada) to google.fr > =20 > --------------------------------- > =20 > =93For geolocation-based ACLs: you have the problem that if the = geolocation is attached by the endpoint, then it can't be trusted, since = the endpoint would lie to get past the ACL. If it's attached by a = router, the ACL needs to have proof that the router attached it (and not = the endpoint), which means that you would need a signed geolocation = header=94 > =20 > Response: You could have the router modify the location field anyways, = just like L3 QoS fields, if you don't trust the host, so no need for = encryption or security, additionally, ACL is not only for security, it = could be used for routing, QoS ..etc, so the host will not always has = the motivation to manipulate the location field. > =20 > --------------------------------- > =20 > =93Why can=92t you simply implement rules related to geo-locations = statically on the network device (router, firewall .. etc)?=94 > =20 > Response: To enforce new geo-location policies automatically, let=92s = assume that a mobile router (like a mobile BTS in a GSM network) moved = from city-x to city-y, and according to city-x regulations VoIP calls = over GSM network is allowed, but city-y regulations do not allow that. = Now the topology may reflect same network metrics in both cities but = there is no rule that triggers configuration change based on = geo-location. > =20 >=20 > --------------------------------- > =20 >=20 > =20 > What do you think? > =20 > =20 > Author/Contact Information: > =20 > Ammar J. Salih > Baghdad, Iraq > =20 > Phone: +964 770 533 0306 > Email: ammar.alsalih@gmail.com > =20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_E54385E1-BE28-44C1-9CBC-3E927D8A899D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 http= ://tools.ietf.org/html/draft-gersch-dnsop-revdns-cidr-03
Tak= e a look at Appendix A for specific encoding examples that are possible = within the DNS, with currently shipping BIND 9.  I base this on = production deployment experience of encoding IP prefixes in the reverse = DNS tree, as per draft-gersch, although *not* for geolocation = information, but rather for SRO (Secure Route Origin) RR's.  If = you're interested in draft-gersch-dnsop-revdns-cidr, it is targeted = at the DNSOP WG of the IETF, so you may wish to subscribe to that = mailing list and discuss it over there.

Lastly, = I would note that the above complements RFC 1876 & RFC 2317 by = providing a nomenclature for "better" encoding of VLSM (Variable Length = Subnet Mask) IP prefixes in the reverse DNS = tree.

-shane


<= div>
On Nov 10, 2012, at 8:05 AM, Ammar Salih <ammar.salih@auis.edu.iq> = wrote:

Hello IETF, based on my discussions with both ipv6 = and geopriv teams, I=92ve written the below document to summarize few = ideas.

Is it possible to publish this on IETF website? even = if it will not be implemented now, at least for documentation and = requesting feedback from the community.

Many thanks.

Ammar

 

Ammar J. Salih
Baghdad, = Iraq          
October 30, = 2012
Title: = IP-LOC
Adding GPS = location to IPv6 header
 
Abstract:
=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
It also assumes that in the future, GPS capability will be added = to the router itself (just like smart phones) and packet marking and = classification based on geo-location will be = required.
QoS, = firewall and routing based on geo-location will be highly required when = mobile routers move from one geo-location to another which has different = policy.
Benefits = of adding GPS location to IPv6 header = (IP-LOC)
 
Web Services: getting more accurate = locations will enhance many services provided by the web, like targeted = commercials (for example, I can get Ads regarding restaurants available = in my neighborhoods instead of all restaurants in the city), another = good example would be webpage=92s language, my language will be detected = more accurately based on my area rather than my country, as there are = many countries with more than one popular language, not mentioning that = many ip registrations does not even reflect the traffic originating = country.

Information accuracy and control: = Nowadays, locations are assigned to IP addresses without user awareness = or control, every time a user performs ip-lookup query the response = would be different based on how the ISP has registered this IP subnet, = IP-LOC suggests making locations more accurate and controllable through = OS and network devices, exactly like IP addresses (user can change = his/her IP address, but router can also modify the header information - = in case it's required).

 

Routing: Policy based routing, based on geo-location, like = routing predefined traffic through certain server or path, for different = purposes (security, manageability, serviceability like choosing = language, or routing traffic to specific cashing or proxy server based = on country .. etc)

 

Copyright law: It happens when certain media/web content is = not allowed in certain countries due to copyright law, the current = method of determining locations is not accurate at all, on other hand, = If layer-7 application to be used then the user might be able to = manipulate the location field, in this case (if it=92s required in = future) the ISP can tag traffic with country/city more accurately as = traffic passes through ISP=92s boarder = routers.

Maps, navigation, emergency = calls and many other services will be also enhanced with accurate = locations.
 

CURRENT =
ARGUMENTS AGAINST THIS IDEA:

=93Adding GPS position to every IPv6 header would add a lot = of overhead=94

 
Response: It does not have to be in every IPv6 header, only = when there is location update, also the host should have the option of = not to send location updates.
=93What about = privacy?=94
 
Response: User should have the option of not sending = location updates. User should also have the ability to set location to = all zeros, in this case no router will modify the location field and = user loses the location-based services.
 
If it=92s = router-to-router link, then no need to be worried about privacy as such = information usually configured on a separate = network.
 
--------------------------------
 
=93a good = alternative would be to create application layer protocols that could = request and send GPS positions=94
Response: the layer-7 = location request will not be detected by layer-3 devices (Routers), I am = assuming that in the future, GPS capability will be added to the router = itself (just like smart phones), features like packet marking and = classification based on geo-location will be required to enforce the new = geo-location policies.
=93For location-based = routing protocols: Why would you want this?  Geographical location = isn't actually that important a metric for routing; what you care about = there is *topological* location, how far I am away from you in terms of = hops or latency=94
Response: For shortest path = maybe yes, hops or latency is important, not for policy-based routing, = in our case you might want to do location-based routing, like, routing = traffic coming from French speaking users (in multi-language country = like Canada) to google.fr
=93For geolocation-based = ACLs: you have the problem that if the geolocation is attached by the = endpoint, then it can't be trusted, since the endpoint would lie to get = past the ACL.  If it's attached by a router, the ACL needs to have = proof that the router attached it (and not the endpoint), which means = that you would need a signed geolocation header=94
 
Response: You = could have the router modify the location field anyways, just like L3 = QoS fields, if you don't trust the host, so no need for encryption or = security, additionally,  ACL is not only for security, it could be = used for routing, QoS ..etc, so the host will not always has the = motivation to manipulate the location field.
 
=93Why can=92t you simply = implement rules related to geo-locations statically on the network = device (router, firewall .. etc)?=94
Response: To enforce new = geo-location policies automatically, let=92s assume that a mobile router = (like a mobile BTS in a GSM network) moved from city-x to city-y, and = according to city-x regulations VoIP calls over GSM network is allowed, = but city-y regulations do not allow that. Now the topology may reflect = same network metrics in both cities but there is no rule that triggers = configuration change based on geo-location.

 

 
What do you think?
 
 
Author/Contact Information:
 
   Ammar J. Salih
   Baghdad, = Iraq
   Email: ipv6@ietf.org
Administrative Requests:  To: "'Mark Smith'" References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <50a02371.86d60e0a.4f2d.02f1@mx.google.com> <1352708088.50386.YahooMailNeo@web32503.mail.mud.yahoo.com> In-Reply-To: <1352708088.50386.YahooMailNeo@web32503.mail.mud.yahoo.com> Date: Mon, 12 Nov 2012 11:42:27 +0300 Message-ID: <50a0b679.82da0e0a.5577.64b9@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac3Arcm7cApiiiLDT36fXhUtjT5CWAAAZmGQ Content-Language: en-us X-Gm-Message-State: ALoCoQnbKjB1AtcH9hq0G6Hgq28pKmmYBAG/NWUEikfWXrbq4nLHS+mkq56B7O+ZgkroRmklaqs+yFmRKg0Gs1fpQ6X+DDBetyI86pNwEoY8PYziPWhkJJaSPMASGiWhpKRRWqRDNzHAOK9kJsNbp0MPytbF3L+ARg== Cc: geopriv@ietf.org, 'Eitan Adler' , ipv6@ietf.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 08:42:43 -0000 > IP addresses identify a device and it's location on the Internet, not = it's=20 > geographical location (although there is some correlation, assuming no = > tunnels), or the person who is using it. Sounds very reasonable and I totally agree .. but don't we use IP = address to determine geographic locations? Isn't that what google, = youtube and other big names use to determine locations?=20 > There is a Geolocation API for web browsers, perhaps it could be=20 > generalised to suit other applications. > http://dev.w3.org/geo/api/spec-source.html This is exactly what I am talking about, too many applications for the = same purpose, we need one lower layer mechanism to unify all of them and = make integration more flexible and compatible. > To identify people, to then determine their attributes (e.g. their=20 > preferred language), you have to use "attributes" of them, not the = machine=20 > they're currently using or where it is located on the Internet e.g. = what=20 > they know, what they are or what they have. This is how the majority of Internet work today, based on IP address, I = gave google as an example, plus language is not the only benefit, how = about other benefits, like Ads and commercials, I mentioned an example = of getting Ads of restaurants in my city instead of getting Ads about = all restaurants in country.=20 Ammar ----- Original Message ----- > From: Ammar Salih > To: 'Eitan Adler' > Cc: geopriv@ietf.org; ipv6@ietf.org > Sent: Monday, 12 November 2012 9:15 AM > Subject: RE: Adding GPS location to IPv6 header >=20 >> another good example would be webpage=E2=80=99s language, my = language will=20 >> be detected more accurately based on my area rather than my country, >=20 >> This is a very bad idea. There are already mechanisms for=20 >> determining preferred languages. >=20 > If those mechanisms are successful then why websites like google do=20 > not use them? They use IP address instead, and it's not always about=20 > http applications, how about VoIP applications, now you need another = mechanism? .. > how about detecting your preferred language for layer-3 routing? >=20 >=20 >> In many cases people don't speak the language of the area they are > located. >=20 > Not many cases, maybe only while you are travelling to certain places=20 > of a language that you don't speak, in that rare case you can manually = > change the language via whatever application you are using. >=20 >=20 >> as there are many countries with more than one popular language, not = >> mentioning that many ip registrations does not even reflect the=20 >> traffic originating country. >=20 >> Why does this need to be in the IP header? There already exist=20 >> application layer mechanisms for obtaining location information. >> Leaving it at the application layer also allows for appropriate=20 >> privacy UI controls. >=20 > I've explained this in previous parts of the document, mainly because > Layer-3 devices won't be able to recognize the feature, and also to=20 > unify the location implementations at different layers. >=20 >> Routing: Policy based routing, based on geo-location, like routing =20 >> predefined traffic through certain server or path, for different =20 >> purposes (security, manageability, serviceability like choosing =20 >> language, or routing traffic to specific cashing or proxy server=20 >> based on country .. etc) >=20 >> This is the only somewhat sane use case I could see for this = information.=20 >> Even then, location of the originating request isn't always the=20 >> correct item to route on. >=20 > It doesn't have to be always .. at least now you partially agree :) >=20 >> Copyright law: It happens when certain media/web content is not =20 >> allowed in certain countries due to copyright law, the current method = =20 >> of determining locations is not accurate at all, on other hand, If >> layer-7 application to be used then the user might be able to =20 >> manipulate the location field, in this case (if it=E2=80=99s required = in >> future) the ISP can tag traffic with country/city more accurately as = =20 >> traffic passes through ISP=E2=80=99s boarder routers. >=20 >> The user can manipulate or control the lower layer IP traffic too.=20 >> If they can't this is an absurd privacy violation. >=20 > Users currently have absolutely *NO* control over IP<->location=20 > mapping, it's totally how your IP owner has registered the IP subnet,=20 > what I am suggesting is that your local ISP *can* tag the city=20 > location "if it's required", unless you want to share your exact=20 > location or set the location to all zeros, in this case you are asking = > the ISP not to tag your location, but in this case you give up all = location based services. >=20 >=20 >> Maps, navigation, emergency calls and many other services will be=20 >> also enhanced with accurate locations. >=20 >> Once again - this should be done at the application layer. >=20 >> Response: It does not have to be in every IPv6 header, only when=20 >> there is location update, also the host should have the option of=20 >> not to send location updates. >=20 >> Didn't you just mention above that information would be added by ISP = =20 >> routers >=20 > I said under the copyright law section "(if it=E2=80=99s required in = future)=20 > the ISP can tag traffic with country/city more accurately as traffic=20 > passes through ISP=E2=80=99s boarder routers" ... which means the user = has the=20 > option to put his/her real location, or set the location field to all=20 > zeros, or leave it without location tagging .. *BUT* if it's required=20 > by the government/or any other organization or third party in the=20 > future for the sake of protecting the copyright laws then the feature = will be available to support that as well. >=20 >> Response: For shortest path maybe yes, hops or latency is important, = =20 >> not for policy-based routing, in our case you might want to do =20 >> location-based routing, like, routing traffic coming from French =20 >> speaking users (in multi-language country like Canada) to google.fr >=20 >> I'm not sure what you mean here. It is easy to redirect users from =20 >> google.com -> google.fr based on their application layer language =20 >> preference. >=20 > Google.fr example is confusing many people, which I will modify,=20 > policy based routing has much more than routing tcp:80 traffic. >=20 > -- > Eitan Adler >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From wilton@isoc.org Mon Nov 12 02:10:26 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5923D21F846A for ; Mon, 12 Nov 2012 02:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCVFbqNzsNQg for ; Mon, 12 Nov 2012 02:10:25 -0800 (PST) Received: from smtp122.iad.emailsrvr.com (smtp122.iad.emailsrvr.com [207.97.245.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1D10221F8475 for ; Mon, 12 Nov 2012 02:10:25 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp42.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 7BBD2148861; Mon, 12 Nov 2012 05:10:24 -0500 (EST) X-Virus-Scanned: OK Received: by smtp42.relay.iad1a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 298A01487A1; Mon, 12 Nov 2012 05:10:24 -0500 (EST) References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <50a02371.86d60e0a.4f2d.02f1@mx.google.com> <1352708088.50386.YahooMailNeo@web32503.mail.mud.yahoo.com> <50a0b679.82da0e0a.5577.64b9@mx.google.com> In-Reply-To: <50a0b679.82da0e0a.5577.64b9@mx.google.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <7D096E9B-457E-4247-B131-9F185152310B@isoc.org> X-Mailer: iPad Mail (9B206) From: Robin Wilton Date: Mon, 12 Nov 2012 10:11:21 +0000 To: Ammar Salih Cc: "geopriv@ietf.org" , Eitan Adler , Mark Smith , "ipv6@ietf.org" Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 10:10:26 -0000 Coming to this quite late in the discussion, here's my 2=C2=A2, in case it h= elps provide a relatively disinterested (but not *un*-interested) summary so= far: - The benefits expected from the proposed enhancement seem very hard for the= mailing list to pin down and express (some are disputed as benefits, while o= thers are acknowledged, but minor...). - Some use-cases have been described, but I think it would be fair to say th= at none of them describes an absolute "can't live without it" need for the e= nhancement. Most of the claimed benefits seem to be realisable by other mean= s, potentially for less effort. - The people who would have to do the work to implement and deploy the enhan= cement are not the ones who would get the direct benefit - which makes it ha= rd to build a rationale for doing it. =46rom an identity, privacy an policy perspective, there's also this: any ti= me you have something which builds identity (and for the sake of this discus= sion I'm going to treat 'long-term and relatively accurate data about locati= on' as a form of identity) into the online infrastructure, there is often so= me claimed benefit from it, but there is also a corresponding drawback in te= rms of privacy and security.=20 For instance, copyright law enforcement has been cited as one possible use o= f the location data - but actually, GPS precision is almost certainly excess= ive for this purpose, given that copyright regimes apply at the level of the= nation state, not the GPS co-ordinate... And once the data is in the header= , it will get used for whatever purpose people can find to exploit or moneti= ze it. It is by no means certain that all those purposes will be in the inte= rests of the end user, For example, 'language preference expression' may seem like a neutral enough= goal, but then we should also consider - what happens if the technical infr= astructure starts to identify you specifically as a Bosnian Muslim, or as an= Arab Israeli, or as a Kurd living in Turkey...=20 As I say, these are just my thoughts as someone coming late to the discussio= n and with no particular 'investment' in it to pursue... hope this is useful= , though. Yrs., Robin Robin Wilton Technical Outreach Director - Identity and Privacy On 12 Nov 2012, at 08:42, "Ammar Salih" wrote: >> IP addresses identify a device and it's location on the Internet, not it'= s=20 >> geographical location (although there is some correlation, assuming no=20= >> tunnels), or the person who is using it. >=20 > Sounds very reasonable and I totally agree .. but don't we use IP address t= o determine geographic locations? Isn't that what google, youtube and other b= ig names use to determine locations?=20 >=20 >=20 >> There is a Geolocation API for web browsers, perhaps it could be=20 >> generalised to suit other applications. >=20 >> http://dev.w3.org/geo/api/spec-source.html >=20 > This is exactly what I am talking about, too many applications for the sam= e purpose, we need one lower layer mechanism to unify all of them and make i= ntegration more flexible and compatible. >=20 >=20 >> To identify people, to then determine their attributes (e.g. their=20 >> preferred language), you have to use "attributes" of them, not the machin= e=20 >> they're currently using or where it is located on the Internet e.g. what=20= >> they know, what they are or what they have. >=20 > This is how the majority of Internet work today, based on IP address, I ga= ve google as an example, plus language is not the only benefit, how about ot= her benefits, like Ads and commercials, I mentioned an example of getting Ad= s of restaurants in my city instead of getting Ads about all restaurants in c= ountry.=20 >=20 >=20 > Ammar >=20 >=20 > ----- Original Message ----- >> From: Ammar Salih >> To: 'Eitan Adler' >> Cc: geopriv@ietf.org; ipv6@ietf.org >> Sent: Monday, 12 November 2012 9:15 AM >> Subject: RE: Adding GPS location to IPv6 header >>=20 >>> another good example would be webpage=E2=80=99s language, my language wi= ll=20 >>> be detected more accurately based on my area rather than my country, >>=20 >>> This is a very bad idea. There are already mechanisms for=20 >>> determining preferred languages. >>=20 >> If those mechanisms are successful then why websites like google do=20 >> not use them? They use IP address instead, and it's not always about=20 >> http applications, how about VoIP applications, now you need another mech= anism? .. >> how about detecting your preferred language for layer-3 routing? >>=20 >>=20 >>> In many cases people don't speak the language of the area they are >> located. >>=20 >> Not many cases, maybe only while you are travelling to certain places=20 >> of a language that you don't speak, in that rare case you can manually=20= >> change the language via whatever application you are using. >>=20 >>=20 >>> as there are many countries with more than one popular language, not=20= >>> mentioning that many ip registrations does not even reflect the=20 >>> traffic originating country. >>=20 >>> Why does this need to be in the IP header? There already exist=20 >>> application layer mechanisms for obtaining location information. >>> Leaving it at the application layer also allows for appropriate=20 >>> privacy UI controls. >>=20 >> I've explained this in previous parts of the document, mainly because >> Layer-3 devices won't be able to recognize the feature, and also to=20 >> unify the location implementations at different layers. >>=20 >>> Routing: Policy based routing, based on geo-location, like routing =20 >>> predefined traffic through certain server or path, for different =20 >>> purposes (security, manageability, serviceability like choosing =20 >>> language, or routing traffic to specific cashing or proxy server=20 >>> based on country .. etc) >>=20 >>> This is the only somewhat sane use case I could see for this information= .=20 >>> Even then, location of the originating request isn't always the=20 >>> correct item to route on. >>=20 >> It doesn't have to be always .. at least now you partially agree :) >>=20 >>> Copyright law: It happens when certain media/web content is not =20 >>> allowed in certain countries due to copyright law, the current method =20= >>> of determining locations is not accurate at all, on other hand, If >>> layer-7 application to be used then the user might be able to =20 >>> manipulate the location field, in this case (if it=E2=80=99s required in= >>> future) the ISP can tag traffic with country/city more accurately as =20= >>> traffic passes through ISP=E2=80=99s boarder routers. >>=20 >>> The user can manipulate or control the lower layer IP traffic too.=20 >>> If they can't this is an absurd privacy violation. >>=20 >> Users currently have absolutely *NO* control over IP<->location=20 >> mapping, it's totally how your IP owner has registered the IP subnet,=20 >> what I am suggesting is that your local ISP *can* tag the city=20 >> location "if it's required", unless you want to share your exact=20 >> location or set the location to all zeros, in this case you are asking=20= >> the ISP not to tag your location, but in this case you give up all locati= on based services. >>=20 >>=20 >>> Maps, navigation, emergency calls and many other services will be=20 >>> also enhanced with accurate locations. >>=20 >>> Once again - this should be done at the application layer. >>=20 >>> Response: It does not have to be in every IPv6 header, only when=20 >>> there is location update, also the host should have the option of=20 >>> not to send location updates. >>=20 >>> Didn't you just mention above that information would be added by ISP =20= >>> routers >>=20 >> I said under the copyright law section "(if it=E2=80=99s required in futu= re)=20 >> the ISP can tag traffic with country/city more accurately as traffic=20 >> passes through ISP=E2=80=99s boarder routers" ... which means the user ha= s the=20 >> option to put his/her real location, or set the location field to all=20 >> zeros, or leave it without location tagging .. *BUT* if it's required=20 >> by the government/or any other organization or third party in the=20 >> future for the sake of protecting the copyright laws then the feature wil= l be available to support that as well. >>=20 >>> Response: For shortest path maybe yes, hops or latency is important, =20= >>> not for policy-based routing, in our case you might want to do =20 >>> location-based routing, like, routing traffic coming from French =20 >>> speaking users (in multi-language country like Canada) to google.fr >>=20 >>> I'm not sure what you mean here. It is easy to redirect users from =20 >>> google.com -> google.fr based on their application layer language =20 >>> preference. >>=20 >> Google.fr example is confusing many people, which I will modify,=20 >> policy based routing has much more than routing tcp:80 traffic. >>=20 >> -- >> Eitan Adler >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From ammar.salih@auis.edu.iq Mon Nov 12 03:17:47 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21C721F8514 for ; Mon, 12 Nov 2012 03:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKgRgU8o7zTL for ; Mon, 12 Nov 2012 03:17:46 -0800 (PST) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with SMTP id 3C4C321F84CD for ; Mon, 12 Nov 2012 03:17:45 -0800 (PST) Received: from mail-ea0-f198.google.com ([209.85.215.198]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKUKDa2VjG9k/792dlSkdcdoAc6z4MgBgi@postini.com; Mon, 12 Nov 2012 03:17:46 PST Received: by mail-ea0-f198.google.com with SMTP id c11so4637233eaa.1 for ; Mon, 12 Nov 2012 03:17:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=0pHSElEOGU7EKBOYqLW2eNlV36eTpv4epbPhKGp1m8c=; b=awxhjfbeXgzzim/cxz6EUVHut2FA4hhLDrDD1DUXZm3+F7qxarc76aZdAL1QFB7ZDu nKNNZsFVg8fVoPCmZevoGDcyT+QNt/tu2vOGvsz2CcDv6jgPiW0IeWmtec2KmacOb1TP dwfftpUVeWlmLMyLKYbH/o+pZN/0aELrq+7UqowZTpcpoSJQhUXUhDlaisAQ9aa0E/pI 28A9LsM+PFXHNf4nrK0QCfQr55frCxB8FDPzAqUFMziQKGWvs428cRt1uPKswHXrU4q8 iuik8TpI68rS6WdnTji4Ir1LGmBcKp+4wBJbReigZT0RAu7g18+qqJCyLKd5tl8dtOM2 y1Pw== Received: by 10.152.123.103 with SMTP id lz7mr17718197lab.21.1352719064011; Mon, 12 Nov 2012 03:17:44 -0800 (PST) Received: by 10.152.123.103 with SMTP id lz7mr17718186lab.21.1352719063861; Mon, 12 Nov 2012 03:17:43 -0800 (PST) Received: from AMMARSALIH ([37.237.150.197]) by mx.google.com with ESMTPS id ti4sm2367554lab.1.2012.11.12.03.17.40 (version=SSLv3 cipher=OTHER); Mon, 12 Nov 2012 03:17:42 -0800 (PST) From: "Ammar Salih" To: "'Robin Wilton'" References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <50a02371.86d60e0a.4f2d.02f1@mx.google.com> <1352708088.50386.YahooMailNeo@web32503.mail.mud.yahoo.com> <50a0b679.82da0e0a.5577.64b9@mx.google.com> <7D096E9B-457E-4247-B131-9F185152310B@isoc.org> In-Reply-To: <7D096E9B-457E-4247-B131-9F185152310B@isoc.org> Date: Mon, 12 Nov 2012 14:17:36 +0300 Message-ID: <50a0dad6.4493980a.6c29.6b0e@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac3Ave63P3UpKbOsT22uvwXuQHWL0gAAjymA Content-Language: en-us X-Gm-Message-State: ALoCoQmfNbtAWIr7DP9jxOGO31h82mTZI+ICzCSZuydoONNNgOTuYvYFT+fp9Jbckt6LhJaierFUSfoEljYU1N4ksukrpMGLxPee2bWvytm87FdHtXlc7ao1SbN8ALwZRAoej4Hd7BpnECom3A6QlOmi11aqWjCm2g== Cc: geopriv@ietf.org, 'Eitan Adler' , 'Mark Smith' , ipv6@ietf.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 11:17:47 -0000 Robin, > Coming to this quite late in the discussion, here's my 2=C2=A2, in = case it=20 > helps provide a relatively disinterested (but not *un*-interested) = summary=20 > so far: I am happy to hear from all of you guys, your notes are highly = appreciated!=20 > From an identity, privacy an policy perspective, there's also this: = any=20 > time you have something which builds identity (and for the sake of = this=20 > discussion I'm going to treat 'long-term and relatively accurate data=20 > about location' as a form of identity) into the online infrastructure, = > there is often some claimed benefit from it, but there is also a=20 > corresponding drawback in terms of privacy and security.=20 > For instance, copyright law enforcement has been cited as one possible = use=20 > of the location data - but actually, GPS precision is almost certainly = > excessive for this purpose, given that copyright regimes apply at the=20 > level of the nation state, not the GPS co-ordinate... And once the = data is=20 > in the header, it will get used for whatever purpose people can find = to=20 > exploit or monetize it. It is by no means certain that all those = purposes=20 > will be in the interests of the end user. User should have the option of not sending location update by setting = all zeros in the location field, telling the ISP routers not to do so as = well, in that case the user protects his/her privacy but loses the = benefits of location-based services .. and if you choose to let the ISP = routers to tag your packets with location updates then it will not be = very accurate, it will be based on your physical connection like mobile = tower your connected to, or even less accurate like the city (or even = country) your are connecting from. In a way that allows the = implementation of copyright law without compromising the privacy. > For example, 'language preference expression' may seem like a neutral=20 > enough goal, but then we should also consider - what happens if the=20 > technical infrastructure starts to identify you specifically as a = Bosnian=20 > Muslim, or as an Arab Israeli, or as a Kurd living in Turkey...=20 technical infrastructure can do much more if they have bad intents, they = can simply identify Muslims, Arabs, Kurds based on destinations (like = Islamic websites or VoIP calls with area code) so it's not only source, = in fact they can do layer-7 classification and marking based on the = actual content of each packet - unless your data are encrypted, and get = much more information than your physical location... again it's users = option to set the location to all zeros. > As I say, these are just my thoughts as someone coming late to the=20 > discussion and with no particular 'investment' in it to pursue... hope = > this is useful, though. I would like to thank you very much, your professional points will = defiantly add more value to the draft. Yrs., Robin Robin Wilton Technical Outreach Director - Identity and Privacy On 12 Nov 2012, at 08:42, "Ammar Salih" wrote: >> IP addresses identify a device and it's location on the Internet, not = >> it's geographical location (although there is some correlation,=20 >> assuming no tunnels), or the person who is using it. >=20 > Sounds very reasonable and I totally agree .. but don't we use IP = address to determine geographic locations? Isn't that what google, = youtube and other big names use to determine locations?=20 >=20 >=20 >> There is a Geolocation API for web browsers, perhaps it could be=20 >> generalised to suit other applications. >=20 >> http://dev.w3.org/geo/api/spec-source.html >=20 > This is exactly what I am talking about, too many applications for the = same purpose, we need one lower layer mechanism to unify all of them and = make integration more flexible and compatible. >=20 >=20 >> To identify people, to then determine their attributes (e.g. their=20 >> preferred language), you have to use "attributes" of them, not the=20 >> machine they're currently using or where it is located on the=20 >> Internet e.g. what they know, what they are or what they have. >=20 > This is how the majority of Internet work today, based on IP address, = I gave google as an example, plus language is not the only benefit, how = about other benefits, like Ads and commercials, I mentioned an example = of getting Ads of restaurants in my city instead of getting Ads about = all restaurants in country.=20 >=20 >=20 > Ammar >=20 >=20 > ----- Original Message ----- >> From: Ammar Salih >> To: 'Eitan Adler' >> Cc: geopriv@ietf.org; ipv6@ietf.org >> Sent: Monday, 12 November 2012 9:15 AM >> Subject: RE: Adding GPS location to IPv6 header >>=20 >>> another good example would be webpage=E2=80=99s language, my = language will=20 >>> be detected more accurately based on my area rather than my=20 >>> country, >>=20 >>> This is a very bad idea. There are already mechanisms for=20 >>> determining preferred languages. >>=20 >> If those mechanisms are successful then why websites like google do=20 >> not use them? They use IP address instead, and it's not always about=20 >> http applications, how about VoIP applications, now you need another = mechanism? .. >> how about detecting your preferred language for layer-3 routing? >>=20 >>=20 >>> In many cases people don't speak the language of the area they are >> located. >>=20 >> Not many cases, maybe only while you are travelling to certain places = >> of a language that you don't speak, in that rare case you can=20 >> manually change the language via whatever application you are using. >>=20 >>=20 >>> as there are many countries with more than one popular language, =20 >>> not mentioning that many ip registrations does not even reflect the=20 >>> traffic originating country. >>=20 >>> Why does this need to be in the IP header? There already exist=20 >>> application layer mechanisms for obtaining location information. >>> Leaving it at the application layer also allows for appropriate=20 >>> privacy UI controls. >>=20 >> I've explained this in previous parts of the document, mainly because >> Layer-3 devices won't be able to recognize the feature, and also to=20 >> unify the location implementations at different layers. >>=20 >>> Routing: Policy based routing, based on geo-location, like routing=20 >>> predefined traffic through certain server or path, for different=20 >>> purposes (security, manageability, serviceability like choosing=20 >>> language, or routing traffic to specific cashing or proxy server=20 >>> based on country .. etc) >>=20 >>> This is the only somewhat sane use case I could see for this = information.=20 >>> Even then, location of the originating request isn't always the=20 >>> correct item to route on. >>=20 >> It doesn't have to be always .. at least now you partially agree :) >>=20 >>> Copyright law: It happens when certain media/web content is not=20 >>> allowed in certain countries due to copyright law, the current=20 >>> method of determining locations is not accurate at all, on other=20 >>> hand, If >>> layer-7 application to be used then the user might be able to=20 >>> manipulate the location field, in this case (if it=E2=80=99s = required in >>> future) the ISP can tag traffic with country/city more accurately as = >>> traffic passes through ISP=E2=80=99s boarder routers. >>=20 >>> The user can manipulate or control the lower layer IP traffic too.=20 >>> If they can't this is an absurd privacy violation. >>=20 >> Users currently have absolutely *NO* control over IP<->location=20 >> mapping, it's totally how your IP owner has registered the IP subnet, = >> what I am suggesting is that your local ISP *can* tag the city=20 >> location "if it's required", unless you want to share your exact=20 >> location or set the location to all zeros, in this case you are=20 >> asking the ISP not to tag your location, but in this case you give up = all location based services. >>=20 >>=20 >>> Maps, navigation, emergency calls and many other services will be=20 >>> also enhanced with accurate locations. >>=20 >>> Once again - this should be done at the application layer. >>=20 >>> Response: It does not have to be in every IPv6 header, only when=20 >>> there is location update, also the host should have the option of=20 >>> not to send location updates. >>=20 >>> Didn't you just mention above that information would be added by ISP = >>> routers >>=20 >> I said under the copyright law section "(if it=E2=80=99s required in = future)=20 >> the ISP can tag traffic with country/city more accurately as traffic=20 >> passes through ISP=E2=80=99s boarder routers" ... which means the = user has=20 >> the option to put his/her real location, or set the location field to = >> all zeros, or leave it without location tagging .. *BUT* if it's=20 >> required by the government/or any other organization or third party=20 >> in the future for the sake of protecting the copyright laws then the = feature will be available to support that as well. >>=20 >>> Response: For shortest path maybe yes, hops or latency is important, = >>> not for policy-based routing, in our case you might want to do=20 >>> location-based routing, like, routing traffic coming from French=20 >>> speaking users (in multi-language country like Canada) to google.fr >>=20 >>> I'm not sure what you mean here. It is easy to redirect users from=20 >>> google.com -> google.fr based on their application layer language=20 >>> preference. >>=20 >> Google.fr example is confusing many people, which I will modify,=20 >> policy based routing has much more than routing tcp:80 traffic. >>=20 >> -- >> Eitan Adler >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From markzzzsmith@yahoo.com.au Mon Nov 12 00:14:50 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB9621F851B for ; Mon, 12 Nov 2012 00:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.244 X-Spam-Level: X-Spam-Status: No, score=-1.244 tagged_above=-999 required=5 tests=[AWL=0.855, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AKRKbkbRxnO for ; Mon, 12 Nov 2012 00:14:49 -0800 (PST) Received: from nm20.bullet.mail.sp2.yahoo.com (nm20.bullet.mail.sp2.yahoo.com [98.139.91.90]) by ietfa.amsl.com (Postfix) with ESMTP id 61ED721F84C6 for ; Mon, 12 Nov 2012 00:14:49 -0800 (PST) Received: from [98.139.91.63] by nm20.bullet.mail.sp2.yahoo.com with NNFMP; 12 Nov 2012 08:14:49 -0000 Received: from [72.30.22.203] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 12 Nov 2012 08:14:49 -0000 Received: from [127.0.0.1] by omp1065.mail.sp2.yahoo.com with NNFMP; 12 Nov 2012 08:14:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 321328.14035.bm@omp1065.mail.sp2.yahoo.com Received: (qmail 87329 invoked by uid 60001); 12 Nov 2012 08:14:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1352708088; bh=uHffojyb6oxwjpPTnUrGq1QIUKTy0D657m/1ajupWCg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xJg+g9kiWewH/kGFx32yvTJX7E5GQztYXud6uLNRer249CHwSHZP10QIYll5zokRQmHauO02T9pe13WI4MIZ+zaffLwJQNrbtTw1+lIHlcsBmRGqnt9crFH1dUeiBFBH8nICRw+POKydyszYLDzStnaK/hi315ssmFz0CSaY380= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=N6VIHSaYp6E6wUPgQE9E53DasBC3AxQ4rtWaO/yZdGt4FgO4eyf5G1Ids/L12lUmFToVNwQSjGV4GVVSvtgys5x+uKNWPhzUtXRImSEMSNAQQeK7EZH/4lX7JJV9MR2JkoJbEvl0m6ENUxNA/Jt+e1vGKEgJhDZa0HmlMCa9RN0=; X-YMail-OSG: 7AYoCtMVM1kqyDhGKYDDVURvoOYw.445S_m0AePWdrVX6ut dVTny8iXZsd.rMQJl0z8JOVE8Z9FRobAeQ7VXQodKoras95ghwiYRrvB93hr RLAE5bSziEc_3foN7ftbrHqPcL70sWog5v3LR.YteWqixuOZlXGlwVOeYedq 6QnzAcaq6yorY8.Pz_xYsrCej_PSaXxLDRukJYOLf9ryhBSqh55Wa7Id8Qrr ZeIac1kvY5xbDihXma8QxwkOYhs.NrF8.pkGoOXs3XN9P0cLh_x9GhVD6nul mX1RPHCTru_3R_fcKV2rt8jHAsHDeMTAWU3MBLk6m1PPLfVyYfPhKwXryW4n s.nFOXbHqz3f5_M2FO1tHIX1u_HYHK_3PfqnSn9ZDxZhawulsFOnKmaY_yK2 eGzW5aTueH06CwAQk6WuVBPvn.OaDpWXYbTAosxUEMOa1Flg8HMjEjdXjAk1 Uf0bsJWfisAdMaZjB4fS5zDQTYJphdvmiBKXEOa4cWpc3VJiSfRL6IuI6Vpo Z45aIPIIapqVTXvcrwPg7b8Qj.2PV7zkxS5VtaUz3wsrNfiAyETP3vHPkoHI Qz_K8bWON9EkVt5PUy0WmsfxR15befgHNtniU25qtmsOBKTzi960jbTtrizq ymekQpFUSwBug9uNJkZtZ_R18kUt_rQTwaxjxZ7b2i5y7RXrbxdwqmOiueQ- - Received: from [150.101.221.237] by web32503.mail.mud.yahoo.com via HTTP; Mon, 12 Nov 2012 00:14:48 PST X-Rocket-MIMEInfo: 001.001, SVAgYWRkcmVzc2VzIGlkZW50aWZ5IGEgZGV2aWNlIGFuZCBpdCdzIGxvY2F0aW9uIG9uIHRoZSBJbnRlcm5ldCwgbm90IGl0J3MgZ2VvZ3JhcGhpY2FsIGxvY2F0aW9uIChhbHRob3VnaCB0aGVyZSBpcyBzb21lIGNvcnJlbGF0aW9uLCBhc3N1bWluZyBubyB0dW5uZWxzKSwgb3IgdGhlIHBlcnNvbiB3aG8gaXMgdXNpbmcgaXQuCgpUaGVyZSBpcyBhIEdlb2xvY2F0aW9uIEFQSSBmb3Igd2ViIGJyb3dzZXJzLCBwZXJoYXBzIGl0IGNvdWxkIGJlIGdlbmVyYWxpc2VkIHRvIHN1aXQgb3RoZXIgYXBwbGljYXRpb24BMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <50a02371.86d60e0a.4f2d.02f1@mx.google.com> Message-ID: <1352708088.50386.YahooMailNeo@web32503.mail.mud.yahoo.com> Date: Mon, 12 Nov 2012 00:14:48 -0800 (PST) From: Mark Smith To: Ammar Salih , 'Eitan Adler' In-Reply-To: <50a02371.86d60e0a.4f2d.02f1@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 12 Nov 2012 06:34:20 -0800 Cc: "geopriv@ietf.org" , "ipv6@ietf.org" Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 08:14:50 -0000 IP addresses identify a device and it's location on the Internet, not it's = geographical location (although there is some correlation, assuming no tunn= els), or the person who is using it.=0A=0AThere is a Geolocation API for we= b browsers, perhaps it could be generalised to suit other applications.=0A= =0A=C2=A0http://dev.w3.org/geo/api/spec-source.html=0A=0ATo identify people= , to then determine their attributes (e.g. their preferred language), you h= ave to use "attributes" of them, not the machine they're currently using or= where it is located on the Internet e.g. what they know, what they are or = what they have.=0A=0A=0A=0A=0A----- Original Message -----=0A> From: Ammar = Salih =0A> To: 'Eitan Adler' =0A> Cc: geopriv@ietf.org; ipv6@ietf.org=0A> Sent: Monday, 12 November 201= 2 9:15 AM=0A> Subject: RE: Adding GPS location to IPv6 header=0A> =0A>> an= other good example would be webpage=E2=80=99s language, my language will be= =0A>> detected more accurately based on my area rather than my country,= =0A> =0A>> This is a very bad idea. There are already mechanisms for deter= mining =0A>> preferred languages.=C2=A0 =0A> =0A> If those mechanisms are = successful then why websites like google do not use =0A> them? They use IP = address instead, and it's not always about http =0A> applications, how abou= t VoIP applications, now you need another mechanism? .. =0A> how about dete= cting your preferred language for layer-3 routing?=0A> =0A> =0A>> In many = cases people don't speak the language of the area they are =0A> located.=0A= > =0A> Not many cases, maybe only while you are travelling to certain place= s of a =0A> language that you don't speak, in that rare case you can manual= ly change the =0A> language via whatever application you are using.=0A> =0A= > =0A>> as there are many countries with more than one popular language,=C2= =A0 not =0A>> mentioning that many ip registrations does not even reflect t= he traffic=C2=A0 =0A>> originating country.=0A> =0A>> Why does this need to= be in the IP header? There already exist =0A>> application layer mechanism= s for obtaining location information.=0A>> Leaving it at the application la= yer also allows for appropriate privacy =0A>> UI controls.=0A> =0A> I've ex= plained this in previous parts of the document, mainly because =0A> Layer-3= devices won't be able to recognize the feature, and also to unify =0A> the= location implementations at different layers.=0A> =0A>> Routing: Policy b= ased routing, based on geo-location, like routing =0A>> predefined traffic= through certain server or path, for different =0A>> purposes (security, m= anageability, serviceability like choosing =0A>> language, or routing traf= fic to specific cashing or proxy server based =0A>> on country .. etc)=0A>= =0A>> This is the only somewhat sane use case I could see for this informa= tion. =0A>> Even then, location of the originating request isn't always the= correct =0A>> item to route on.=0A> =0A> It doesn't have to be always .. a= t least now you partially agree :)=0A> =0A>> Copyright law: It happens whe= n certain media/web content is not =0A>> allowed in certain countries due = to copyright law, the current method =0A>> of determining locations is not= accurate at all, on other hand, If =0A>> layer-7 application to be used t= hen the user might be able to =0A>> manipulate the location field, in this= case (if it=E2=80=99s required in =0A>> future) the ISP can tag traffic w= ith country/city more accurately as =0A>> traffic passes through ISP=E2=80= =99s boarder routers.=0A> =0A>> The user can manipulate or control the low= er layer IP traffic too. If =0A>> they can't this is an absurd privacy vio= lation.=0A> =0A> Users currently have absolutely *NO* control over IP<->loc= ation mapping, =0A> it's totally how your IP owner has registered the IP su= bnet, what I am =0A> suggesting is that your local ISP *can* tag the city l= ocation "if it's =0A> required", unless you want to share your exact locati= on or set the location =0A> to all zeros, in this case you are asking the I= SP not to tag your location, but =0A> in this case you give up all location= based services.=0A> =0A> =0A>> Maps, navigation, emergency calls and many= other services will be also =0A>> enhanced with accurate locations.=0A> = =0A>> Once again - this should be done at the application layer.=0A> =0A>>= Response: It does not have to be in every IPv6 header, only when there = =0A>> is location update, also the host should have the option of not to = =0A>> send location updates.=0A> =0A>> Didn't you just mention above that= information would be added by ISP =0A>> routers=0A> =0A> I said under the= copyright law section "(if it=E2=80=99s required in future) the =0A> ISP c= an tag traffic with country/city more accurately as traffic passes through = =0A> ISP=E2=80=99s boarder routers" ... which means the user has the option= to put =0A> his/her real location, or set the location field to all zeros,= or leave it =0A> without location tagging .. *BUT* if it's required by the= government/or any =0A> other organization or third party in the future for= the sake of protecting the =0A> copyright laws then the feature will be av= ailable to support that as well.=0A> =0A>> Response: For shortest path may= be yes, hops or latency is important, =0A>> not for policy-based routing, = in our case you might want to do =0A>> location-based routing, like, routi= ng traffic coming from French =0A>> speaking users (in multi-language coun= try like Canada) to google.fr=0A> =0A>> I'm not sure what you mean here. I= t is easy to redirect users from =0A>> google.com -> google.fr based on th= eir application layer language =0A>> preference.=0A> =0A> Google.fr exampl= e is confusing many people, which I will modify, policy based =0A> routing = has much more than routing tcp:80 traffic. =0A> =0A> --=0A> Eitan Adler=0A>= =0A> --------------------------------------------------------------------= =0A> IETF IPv6 working group mailing list=0A> ipv6@ietf.org=0A> Administrat= ive Requests: https://www.ietf.org/mailman/listinfo/ipv6=0A> --------------= ------------------------------------------------------=0A> From tglassey@earthlink.net Mon Nov 12 07:13:02 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CC821F85A2 for ; Mon, 12 Nov 2012 07:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awlxs09mKVr5 for ; Mon, 12 Nov 2012 07:12:55 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 940E721F85C2 for ; Mon, 12 Nov 2012 07:12:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=pXqWr+kLdvCjz7zxKHsQwg2V6Fftkndvm/1pIAF4lhfPL0gvRp8XnJjacyGbbhMB; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.21] (helo=[192.168.15.2]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TXvh0-0000E4-RL for geopriv@ietf.org; Mon, 12 Nov 2012 10:12:55 -0500 Message-ID: <50A111F5.6090504@earthlink.net> Date: Mon, 12 Nov 2012 07:12:53 -0800 From: tglassey User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: geopriv@ietf.org References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <50a02371.86d60e0a.4f2d.02f1@mx.google.com> <1352708088.50386.YahooMailNeo@web32503.mail.mud.yahoo.com> In-Reply-To: <1352708088.50386.YahooMailNeo@web32503.mail.mud.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79038ed9f051407307bbc2dbaa80f9ee58350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.21 Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 15:13:02 -0000 On 11/12/2012 12:14 AM, Mark Smith wrote: > IP addresses identify a device and it's location on the Internet, not it's geographical location (although there is some correlation, assuming no tunnels), or the person who is using it. > > There is a Geolocation API for web browsers, perhaps it could be generalised to suit other applications. > > http://dev.w3.org/geo/api/spec-source.html > > To identify people, to then determine their attributes (e.g. their preferred language), you have to use "attributes" of them, not the machine they're currently using or where it is located on the Internet e.g. what they know, what they are or what they have. So the real issue is whether your trying to create something that links data to a specific reciever or of the like. What the location controls and information are used for is very important and there are a number of things to address including how you would integrate SAASM control data into that or L2 Token Pairs. Todd ----- Original Message ----- >> From: Ammar Salih >> To: 'Eitan Adler' >> Cc: geopriv@ietf.org; ipv6@ietf.org >> Sent: Monday, 12 November 2012 9:15 AM >> Subject: RE: Adding GPS location to IPv6 header >> >>> another good example would be webpage’s language, my language will be >>> detected more accurately based on my area rather than my country, >>> This is a very bad idea. There are already mechanisms for determining >>> preferred languages. >> If those mechanisms are successful then why websites like google do not use >> them? They use IP address instead, and it's not always about http >> applications, how about VoIP applications, now you need another mechanism? .. >> how about detecting your preferred language for layer-3 routing? >> >> >>> In many cases people don't speak the language of the area they are >> located. >> >> Not many cases, maybe only while you are travelling to certain places of a >> language that you don't speak, in that rare case you can manually change the >> language via whatever application you are using. >> >> >>> as there are many countries with more than one popular language, not >>> mentioning that many ip registrations does not even reflect the traffic >>> originating country. >>> Why does this need to be in the IP header? There already exist >>> application layer mechanisms for obtaining location information. >>> Leaving it at the application layer also allows for appropriate privacy >>> UI controls. >> I've explained this in previous parts of the document, mainly because >> Layer-3 devices won't be able to recognize the feature, and also to unify >> the location implementations at different layers. >> >>> Routing: Policy based routing, based on geo-location, like routing >>> predefined traffic through certain server or path, for different >>> purposes (security, manageability, serviceability like choosing >>> language, or routing traffic to specific cashing or proxy server based >>> on country .. etc) >>> This is the only somewhat sane use case I could see for this information. >>> Even then, location of the originating request isn't always the correct >>> item to route on. >> It doesn't have to be always .. at least now you partially agree :) >> >>> Copyright law: It happens when certain media/web content is not >>> allowed in certain countries due to copyright law, the current method >>> of determining locations is not accurate at all, on other hand, If >>> layer-7 application to be used then the user might be able to >>> manipulate the location field, in this case (if it’s required in >>> future) the ISP can tag traffic with country/city more accurately as >>> traffic passes through ISP’s boarder routers. >>> The user can manipulate or control the lower layer IP traffic too. If >>> they can't this is an absurd privacy violation. >> Users currently have absolutely *NO* control over IP<->location mapping, >> it's totally how your IP owner has registered the IP subnet, what I am >> suggesting is that your local ISP *can* tag the city location "if it's >> required", unless you want to share your exact location or set the location >> to all zeros, in this case you are asking the ISP not to tag your location, but >> in this case you give up all location based services. >> >> >>> Maps, navigation, emergency calls and many other services will be also >>> enhanced with accurate locations. >>> Once again - this should be done at the application layer. >>> Response: It does not have to be in every IPv6 header, only when there >>> is location update, also the host should have the option of not to >>> send location updates. >>> Didn't you just mention above that information would be added by ISP >>> routers >> I said under the copyright law section "(if it’s required in future) the >> ISP can tag traffic with country/city more accurately as traffic passes through >> ISP’s boarder routers" ... which means the user has the option to put >> his/her real location, or set the location field to all zeros, or leave it >> without location tagging .. *BUT* if it's required by the government/or any >> other organization or third party in the future for the sake of protecting the >> copyright laws then the feature will be available to support that as well. >> >>> Response: For shortest path maybe yes, hops or latency is important, >>> not for policy-based routing, in our case you might want to do >>> location-based routing, like, routing traffic coming from French >>> speaking users (in multi-language country like Canada) to google.fr >>> I'm not sure what you mean here. It is easy to redirect users from >>> google.com -> google.fr based on their application layer language >>> preference. >> Google.fr example is confusing many people, which I will modify, policy based >> routing has much more than routing tcp:80 traffic. >> >> -- >> Eitan Adler >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv -- Regards TSG "Ex-Cruce-Leo" //Confidential Mailing - Please destroy this if you are not the intended recipient. From kjones@skyhookwireless.com Mon Nov 12 07:21:31 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451F221F868D; Mon, 12 Nov 2012 07:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22p96IyfulTV; Mon, 12 Nov 2012 07:21:30 -0800 (PST) Received: from server505.appriver.com (server505e.appriver.com [98.129.35.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0395821F858F; Mon, 12 Nov 2012 07:21:29 -0800 (PST) X-Note-AR-ScanTimeLocal: 11/12/2012 9:21:26 AM X-Policy: GLOBAL - skyhookwireless.com X-Policy: GLOBAL - skyhookwireless.com X-Policy: GLOBAL - skyhookwireless.com X-Policy: GLOBAL - skyhookwireless.com X-Policy: GLOBAL - skyhookwireless.com X-Primary: kjones@skyhookwireless.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @skyhookwireless.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: smtp.exg5.exghost.com X-Note-Return-Path: kjones@skyhookwireless.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G329 G330 G331 G332 G336 G337 G348 G444 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.8) with ESMTPS id 334496910; Mon, 12 Nov 2012 09:21:26 -0600 Received: from MBX02.exg5.exghost.com ([169.254.2.43]) by HT08-E5.exg5.exghost.com ([98.129.23.244]) with mapi; Mon, 12 Nov 2012 09:21:22 -0600 From: Kipp Jones To: Mark Smith Date: Mon, 12 Nov 2012 09:21:20 -0600 Thread-Topic: [Geopriv] Adding GPS location to IPv6 header Thread-Index: Ac3A6V5+qcxoW8AoTeOQF4Id3uG+3w== Message-ID: <61FAC6A5-056D-427A-B695-6FE072D550F5@skyhookwireless.com> References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <50a02371.86d60e0a.4f2d.02f1@mx.google.com> <1352708088.50386.YahooMailNeo@web32503.mail.mud.yahoo.com> In-Reply-To: <1352708088.50386.YahooMailNeo@web32503.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "geopriv@ietf.org" , Eitan Adler , Ammar Salih , "ipv6@ietf.org" Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 15:21:31 -0000 Indeed, many operating systems now include a location API -- this has been = driven by the mobile operating systems but is now included in other operati= on systems such as Apples OS X. These location API's use various technique= s such as Wi-Fi, Cell, GPS, and IP positioning to attempt to determine the = location of the device. In general these services are invoked by various a= pplications, but can also be utilized by the operating system itself. Note= that use of this information, and access to these APIs is sometimes contro= lled in order to require user permission for applications to access the loc= ation of the device. Any discussion of automatically including location information in device co= mmunication needs a very thorough vetting with respect to privacy. Includin= g precise latitude and longitude with every packet seems overkill. How applications use this information (e.g. preferred language) is dependen= t on the application and the user experience desired. The same is true wit= h how web sites use the location information provided via W3C's geolocation= API. Many web sites do not take advantage of the W3C geolocation API as i= t requires a pop-up notification to the user that many people find annoying= at best. Kipp ..............................................=20 Kipp Jones Chief Architect/Privacy Czar kjones@skyhookwireless.com m: 404.213.9293 | @skykipp On Nov 12, 2012, at 3:14 AM, Mark Smith wrote: > IP addresses identify a device and it's location on the Internet, not it'= s geographical location (although there is some correlation, assuming no tu= nnels), or the person who is using it. >=20 > There is a Geolocation API for web browsers, perhaps it could be generali= sed to suit other applications. >=20 > http://dev.w3.org/geo/api/spec-source.html >=20 > To identify people, to then determine their attributes (e.g. their prefer= red language), you have to use "attributes" of them, not the machine they'r= e currently using or where it is located on the Internet e.g. what they kno= w, what they are or what they have. >=20 >=20 >=20 >=20 > ----- Original Message ----- >> From: Ammar Salih >> To: 'Eitan Adler' >> Cc: geopriv@ietf.org; ipv6@ietf.org >> Sent: Monday, 12 November 2012 9:15 AM >> Subject: RE: Adding GPS location to IPv6 header >>=20 >>> another good example would be webpage=92s language, my language will be= =20 >>> detected more accurately based on my area rather than my country, >>=20 >>> This is a very bad idea. There are already mechanisms for determining=20 >>> preferred languages. =20 >>=20 >> If those mechanisms are successful then why websites like google do not = use=20 >> them? They use IP address instead, and it's not always about http=20 >> applications, how about VoIP applications, now you need another mechanis= m? ..=20 >> how about detecting your preferred language for layer-3 routing? >>=20 >>=20 >>> In many cases people don't speak the language of the area they are=20 >> located. >>=20 >> Not many cases, maybe only while you are travelling to certain places of= a=20 >> language that you don't speak, in that rare case you can manually change= the=20 >> language via whatever application you are using. >>=20 >>=20 >>> as there are many countries with more than one popular language, not=20 >>> mentioning that many ip registrations does not even reflect the traffic= =20 >>> originating country. >>=20 >>> Why does this need to be in the IP header? There already exist=20 >>> application layer mechanisms for obtaining location information. >>> Leaving it at the application layer also allows for appropriate privacy= =20 >>> UI controls. >>=20 >> I've explained this in previous parts of the document, mainly because=20 >> Layer-3 devices won't be able to recognize the feature, and also to unif= y=20 >> the location implementations at different layers. >>=20 >>> Routing: Policy based routing, based on geo-location, like routing=20 >>> predefined traffic through certain server or path, for different=20 >>> purposes (security, manageability, serviceability like choosing=20 >>> language, or routing traffic to specific cashing or proxy server based= =20 >>> on country .. etc) >>=20 >>> This is the only somewhat sane use case I could see for this informatio= n.=20 >>> Even then, location of the originating request isn't always the correct= =20 >>> item to route on. >>=20 >> It doesn't have to be always .. at least now you partially agree :) >>=20 >>> Copyright law: It happens when certain media/web content is not=20 >>> allowed in certain countries due to copyright law, the current method=20 >>> of determining locations is not accurate at all, on other hand, If=20 >>> layer-7 application to be used then the user might be able to=20 >>> manipulate the location field, in this case (if it=92s required in=20 >>> future) the ISP can tag traffic with country/city more accurately as=20 >>> traffic passes through ISP=92s boarder routers. >>=20 >>> The user can manipulate or control the lower layer IP traffic too. If=20 >>> they can't this is an absurd privacy violation. >>=20 >> Users currently have absolutely *NO* control over IP<->location mapping,= =20 >> it's totally how your IP owner has registered the IP subnet, what I am=20 >> suggesting is that your local ISP *can* tag the city location "if it's=20 >> required", unless you want to share your exact location or set the locat= ion=20 >> to all zeros, in this case you are asking the ISP not to tag your locati= on, but=20 >> in this case you give up all location based services. >>=20 >>=20 >>> Maps, navigation, emergency calls and many other services will be also= =20 >>> enhanced with accurate locations. >>=20 >>> Once again - this should be done at the application layer. >>=20 >>> Response: It does not have to be in every IPv6 header, only when there= =20 >>> is location update, also the host should have the option of not to=20 >>> send location updates. >>=20 >>> Didn't you just mention above that information would be added by ISP=20 >>> routers >>=20 >> I said under the copyright law section "(if it=92s required in future) t= he=20 >> ISP can tag traffic with country/city more accurately as traffic passes = through=20 >> ISP=92s boarder routers" ... which means the user has the option to put= =20 >> his/her real location, or set the location field to all zeros, or leave = it=20 >> without location tagging .. *BUT* if it's required by the government/or = any=20 >> other organization or third party in the future for the sake of protecti= ng the=20 >> copyright laws then the feature will be available to support that as wel= l. >>=20 >>> Response: For shortest path maybe yes, hops or latency is important,=20 >>> not for policy-based routing, in our case you might want to do=20 >>> location-based routing, like, routing traffic coming from French=20 >>> speaking users (in multi-language country like Canada) to google.fr >>=20 >>> I'm not sure what you mean here. It is easy to redirect users from=20 >>> google.com -> google.fr based on their application layer language=20 >>> preference. >>=20 >> Google.fr example is confusing many people, which I will modify, policy = based=20 >> routing has much more than routing tcp:80 traffic.=20 >>=20 >> -- >> Eitan Adler >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From matthew.lutze@gmail.com Mon Nov 12 09:32:50 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2646121F8472 for ; Mon, 12 Nov 2012 09:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lN-bs8NNkQ0T for ; Mon, 12 Nov 2012 09:32:48 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0FA221F862E for ; Mon, 12 Nov 2012 09:32:47 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so7098701vcb.31 for ; Mon, 12 Nov 2012 09:32:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; bh=MI8UtLRTQMT32e8Mf/CDu6YZdgxtLh/YDyUjNyfrPCY=; b=ayMeAHij8EtSMW/hUPmzfFpXB/hZPeSgiwFsl+Iw1RrAbzwCTMvEmVWb6JI+xFBvGN 62TquXtWmxnZeOcUgHRYUOp0SIy0CSLHkFU84jB5NqMh18koDOd1npIqEjBwO2CFEvV4 yniblLH8ea1LrKB5XankU2d8/lmm8aWIp8YBKKm98uPte40MYQz4zHRBxenztahHJivg NW1Q2GLo/3nI0IUHKRs2/Un2jxGH5MtbQP0dAYbcrHYJzFE1kANiwVpQHgfSaNjMYFFP GVShd21YFSLKojrSne6XPXPR7tqPWlvwsFtCg176wY03YLbvovQm9n0XZ/+aqTOE1V/l Xtyg== Received: by 10.52.75.70 with SMTP id a6mr23076652vdw.5.1352741566725; Mon, 12 Nov 2012 09:32:46 -0800 (PST) Received: from [10.1.10.32] (c-69-143-14-148.hsd1.va.comcast.net. [69.143.14.148]) by mx.google.com with ESMTPS id wc12sm7493206vdc.8.2012.11.12.09.32.44 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Nov 2012 09:32:46 -0800 (PST) From: Matt Lutze Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_43AD48C6-A9A7-4DC9-9F53-C0AE3AB052B3" Date: Mon, 12 Nov 2012 12:32:40 -0500 In-Reply-To: To: geopriv@ietf.org References: Message-Id: X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Mon, 12 Nov 2012 09:47:58 -0800 Subject: Re: [Geopriv] Geopriv Digest, Vol 102, Issue 8, message 1 & 3 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 17:37:16 -0000 --Apple-Mail=_43AD48C6-A9A7-4DC9-9F53-C0AE3AB052B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Good day, I have a comment and a few observations, if I may expose my ignorance to = ask them (and apologize if the topics have already been discussed): First, the comment: >> IP addresses identify a device and it's location on the Internet, not = it's=20 >> geographical location (although there is some correlation, assuming = no=20 >> tunnels), or the person who is using it. >=20 > Sounds very reasonable and I totally agree .. but don't we use IP = address to determine geographic locations? Isn't that what google, = youtube and other big names use to determine locations?=20 Outside of generally looking at an IP address to guess at a host's = regional location, I would posit that services today determine location = by asking a device to allow the service to use an Application layer = method for location detection=97accessing a GPS and/or Wi-Fi radio on = the device. =20 A few observations: The arguments for this extension seem to generally be focused on = providing services that may require or be preferred to have different = policies and implementations for the various higher level services that = actually need them. Another way, it would seem to me that a router using = GPS to indicate its physical location will use that differently than a = mobile device replying with its location to a web application.=20 Particularly, implementing GPS as an extension of IP means that special = considerations needed by an upper level protocol=97perhaps setting a TTL = for the location, or specifying a quality or resolution=97would all have = to be supported in IP, unnecessarily increasing the complexity of the = extension in a protocol whose paramount strength is its simplicity. = Ammar, is illustrated by the arguments you make in message 3 = below=97periodicity of updates should be a function of the application = layer protocol, not IP.=20 Further, given the notion that the IP header "should" be stripped from a = datagram before the payload is passed up to higher level protocols, I = would find it more logical that the GPS location be implemented in the = final protocol and not require the fuzzy layer boundary violations this = would imply.=20 Generally, I think my resistance is that IP is supposed to handle = internetwork addressing. Relaying a GPS location doesn't immediately = correlate with the purpose of providing a device with an address, or = servicing that address, and so it seems to me that GPS location doesn't = belong.=20 An HTTP-GPS, ICMP-GPS, etc., extension would seem the appropriate = implementation.=20 Respectfully, Matt Lutze On Nov 12, 2012, at 6:17 AM, geopriv-request@ietf.org wrote: >=20 >=20 > Message: 1 > Date: Mon, 12 Nov 2012 11:42:27 +0300 > From: "Ammar Salih" > To: "'Mark Smith'" > Cc: geopriv@ietf.org, 'Eitan Adler' , > ipv6@ietf.org > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > Message-ID: <50a0b679.82da0e0a.5577.64b9@mx.google.com> > Content-Type: text/plain; charset=3D"UTF-8" >=20 >> IP addresses identify a device and it's location on the Internet, not = it's=20 >> geographical location (although there is some correlation, assuming = no=20 >> tunnels), or the person who is using it. >=20 > Sounds very reasonable and I totally agree .. but don't we use IP = address to determine geographic locations? Isn't that what google, = youtube and other big names use to determine locations?=20 >=20 >=20 >> There is a Geolocation API for web browsers, perhaps it could be=20 >> generalised to suit other applications. >=20 >> http://dev.w3.org/geo/api/spec-source.html >=20 > This is exactly what I am talking about, too many applications for the = same purpose, we need one lower layer mechanism to unify all of them and = make integration more flexible and compatible. >=20 >=20 >> To identify people, to then determine their attributes (e.g. their=20 >> preferred language), you have to use "attributes" of them, not the = machine=20 >> they're currently using or where it is located on the Internet e.g. = what=20 >> they know, what they are or what they have. >=20 > This is how the majority of Internet work today, based on IP address, = I gave google as an example, plus language is not the only benefit, how = about other benefits, like Ads and commercials, I mentioned an example = of getting Ads of restaurants in my city instead of getting Ads about = all restaurants in country.=20 >=20 >=20 > Ammar >=20 > [=85] > ----- Original Message ----- >=20 > Message: 2 > Date: Mon, 12 Nov 2012 10:11:21 +0000 > From: Robin Wilton > To: Ammar Salih > Cc: "geopriv@ietf.org" , Eitan Adler > , Mark Smith , > "ipv6@ietf.org" > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > Message-ID: <7D096E9B-457E-4247-B131-9F185152310B@isoc.org> > Content-Type: text/plain; charset=3Dutf-8 >=20 > Coming to this quite late in the discussion, here's my 2?, in case it = helps provide a relatively disinterested (but not *un*-interested) = summary so far: >=20 > - The benefits expected from the proposed enhancement seem very hard = for the mailing list to pin down and express (some are disputed as = benefits, while others are acknowledged, but minor...). >=20 > - Some use-cases have been described, but I think it would be fair to = say that none of them describes an absolute "can't live without it" need = for the enhancement. Most of the claimed benefits seem to be realisable = by other means, potentially for less effort. >=20 > - The people who would have to do the work to implement and deploy the = enhancement are not the ones who would get the direct benefit - which = makes it hard to build a rationale for doing it. >=20 > =46rom an identity, privacy an policy perspective, there's also this: = any time you have something which builds identity (and for the sake of = this discussion I'm going to treat 'long-term and relatively accurate = data about location' as a form of identity) into the online = infrastructure, there is often some claimed benefit from it, but there = is also a corresponding drawback in terms of privacy and security.=20 >=20 > For instance, copyright law enforcement has been cited as one possible = use of the location data - but actually, GPS precision is almost = certainly excessive for this purpose, given that copyright regimes apply = at the level of the nation state, not the GPS co-ordinate... And once = the data is in the header, it will get used for whatever purpose people = can find to exploit or monetize it. It is by no means certain that all = those purposes will be in the interests of the end user, >=20 > For example, 'language preference expression' may seem like a neutral = enough goal, but then we should also consider - what happens if the = technical infrastructure starts to identify you specifically as a = Bosnian Muslim, or as an Arab Israeli, or as a Kurd living in Turkey...=20= >=20 > As I say, these are just my thoughts as someone coming late to the = discussion and with no particular 'investment' in it to pursue... hope = this is useful, though. >=20 > Yrs., >=20 > Robin >=20 >=20 >=20 >=20 > Robin Wilton >=20 > Technical Outreach Director - Identity and Privacy >>>=20 >>> -- [=85] > Message: 3 > Date: Mon, 12 Nov 2012 14:17:36 +0300 > From: "Ammar Salih" > To: "'Robin Wilton'" > Cc: geopriv@ietf.org, 'Eitan Adler' , 'Mark > Smith' , ipv6@ietf.org > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > Message-ID: <50a0dad6.4493980a.6c29.6b0e@mx.google.com> > Content-Type: text/plain; charset=3D"UTF-8" >=20 > Robin, >=20 >> Coming to this quite late in the discussion, here's my 2?, in case it=20= >> helps provide a relatively disinterested (but not *un*-interested) = summary=20 >> so far: >=20 > I am happy to hear from all of you guys, your notes are highly = appreciated!=20 >=20 >> =46rom an identity, privacy an policy perspective, there's also this: = any=20 >> time you have something which builds identity (and for the sake of = this=20 >> discussion I'm going to treat 'long-term and relatively accurate data=20= >> about location' as a form of identity) into the online = infrastructure,=20 >> there is often some claimed benefit from it, but there is also a=20 >> corresponding drawback in terms of privacy and security.=20 >=20 >> For instance, copyright law enforcement has been cited as one = possible use=20 >> of the location data - but actually, GPS precision is almost = certainly=20 >> excessive for this purpose, given that copyright regimes apply at the=20= >> level of the nation state, not the GPS co-ordinate... And once the = data is=20 >> in the header, it will get used for whatever purpose people can find = to=20 >> exploit or monetize it. It is by no means certain that all those = purposes=20 >> will be in the interests of the end user. >=20 > User should have the option of not sending location update by setting = all zeros in the location field, telling the ISP routers not to do so as = well, in that case the user protects his/her privacy but loses the = benefits of location-based services .. and if you choose to let the ISP = routers to tag your packets with location updates then it will not be = very accurate, it will be based on your physical connection like mobile = tower your connected to, or even less accurate like the city (or even = country) your are connecting from. In a way that allows the = implementation of copyright law without compromising the privacy. >=20 >=20 >> For example, 'language preference expression' may seem like a neutral=20= >> enough goal, but then we should also consider - what happens if the=20= >> technical infrastructure starts to identify you specifically as a = Bosnian=20 >> Muslim, or as an Arab Israeli, or as a Kurd living in Turkey...=20 >=20 > technical infrastructure can do much more if they have bad intents, = they can simply identify Muslims, Arabs, Kurds based on destinations = (like Islamic websites or VoIP calls with area code) so it's not only = source, in fact they can do layer-7 classification and marking based on = the actual content of each packet - unless your data are encrypted, and = get much more information than your physical location... again it's = users option to set the location to all zeros. >=20 >> As I say, these are just my thoughts as someone coming late to the=20 >> discussion and with no particular 'investment' in it to pursue... = hope=20 >> this is useful, though. >=20 > I would like to thank you very much, your professional points will = defiantly add more value to the draft. >=20 >=20 > [=85] >=20 > End of Geopriv Digest, Vol 102, Issue 8 > *************************************** --Apple-Mail=_43AD48C6-A9A7-4DC9-9F53-C0AE3AB052B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
IP addresses identify a = device and it's location on the Internet, not = it's 
geographical = location (although there is some correlation, assuming = no 
tunnels), or the = person who is using it.

Sounds very reasonable and I = totally agree .. but don't we use IP address to determine geographic = locations? Isn't that what google, youtube and other big names use to = determine = locations? 
















Message: = 1
Date: Mon, 12 Nov 2012 11:42:27 +0300
From: "Ammar Salih" <ammar.salih@auis.edu.iq>To: "'Mark Smith'" <markzzzsmith@yahoo.com.au>= ;
Cc: geopriv@ietf.org, = 'Eitan Adler' <lists@eitanadler.com>,
ipv6@ietf.org
Subject: Re: = [Geopriv] Adding GPS location to IPv6 header
Message-ID: = <50a0b679.82da0e0a.5577.64b9@mx.google.com>
Content-Type: = text/plain; = charset=3D"UTF-8"

IP addresses = identify a device and it's location on the Internet, not it's =
geographical location = (although there is some correlation, assuming no =
tunnels), or the person who = is using it.

Sounds very reasonable and I totally = agree .. but don't we use IP address to determine geographic locations? = Isn't that what google, youtube and other big names use to determine = locations?


There is a Geolocation = API for web browsers, perhaps it could be
generalised to suit other = applications.

http://dev.w3.org/geo/api/spec-source.html
<= br>This is exactly what I am talking about, too many applications for = the same purpose, we need one lower layer mechanism to unify all of them = and make integration more flexible and = compatible.


To identify people, to = then determine their attributes (e.g. their
preferred language), you have to use "attributes" of them, = not the machine
they're = currently using or where it is located on the Internet e.g. what =
they know, what they are or = what they have.

This is how the majority of Internet = work today, based on IP address, I gave google as an example, plus = language is not the only benefit, how about other benefits, like Ads and = commercials, I mentioned an example of getting Ads of restaurants in my = city instead of getting Ads about all restaurants in country. =


Ammar

[=85]

----- Original Message -----

Message: = 2
Date: Mon, 12 Nov 2012 10:11:21 +0000
From: Robin Wilton <wilton@isoc.org>
To: Ammar = Salih <ammar.salih@auis.edu.iq>Cc: "geopriv@ietf.org" <geopriv@ietf.org>, Eitan = Adler
= <lists@eitanadler.com>, Mark = Smith <markzzzsmith@yahoo.com.au>= ;,
= "ipv6@ietf.org" <ipv6@ietf.org>
Subject: Re: = [Geopriv] Adding GPS location to IPv6 header
Message-ID: <7D096E9B-457= E-4247-B131-9F185152310B@isoc.org>
Content-Type: = text/plain; = charset=3Dutf-8

Coming to this quite late in the = discussion, here's my 2?, in case it helps provide a relatively = disinterested (but not *un*-interested) summary so far:

- The = benefits expected from the proposed enhancement seem very hard for the = mailing list to pin down and express (some are disputed as benefits, = while others are acknowledged, but minor...).

- Some use-cases = have been described, but I think it would be fair to say that none of = them describes an absolute "can't live without it" need for the = enhancement. Most of the claimed benefits seem to be realisable by other = means, potentially for less effort.

- The people who would have = to do the work to implement and deploy the enhancement are not the ones = who would get the direct benefit - which makes it hard to build a = rationale for doing it.

=46rom an identity, privacy an policy = perspective, there's also this: any time you have something which builds = identity (and for the sake of this discussion I'm going to treat = 'long-term and relatively accurate data about location' as a form of = identity) into the online infrastructure, there is often some claimed = benefit from it, but there is also a corresponding drawback in terms of = privacy and security.

For instance, copyright law enforcement = has been cited as one possible use of the location data - but actually, = GPS precision is almost certainly excessive for this purpose, given that = copyright regimes apply at the level of the nation state, not the GPS = co-ordinate... And once the data is in the header, it will get used for = whatever purpose people can find to exploit or monetize it. It is by no = means certain that all those purposes will be in the interests of the = end user,

For example, 'language preference expression' may seem = like a neutral enough goal, but then we should also consider - what = happens if the technical infrastructure starts to identify you = specifically as a Bosnian Muslim, or as an Arab Israeli, or as a Kurd = living in Turkey...

As I say, these are just my thoughts as = someone coming late to the discussion and with no particular = 'investment' in it to pursue... hope this is useful, = though.

Yrs.,

Robin




Robin = Wilton

Technical Outreach Director - Identity and = Privacy

--

[=85]

Message: 3
Date: = Mon, 12 Nov 2012 14:17:36 +0300
From: "Ammar Salih" <ammar.salih@auis.edu.iq>To: "'Robin Wilton'" <wilton@isoc.org>
Cc: geopriv@ietf.org, 'Eitan Adler' = <lists@eitanadler.com>, = 'Mark
= Smith' <markzzzsmith@yahoo.com.au>= ;, ipv6@ietf.org
Subject: Re: = [Geopriv] Adding GPS location to IPv6 header
Message-ID: <50a0dad6.4493980= a.6c29.6b0e@mx.google.com>
Content-Type: text/plain; = charset=3D"UTF-8"

Robin,

Coming to this quite late in the discussion, here's my 2?, = in case it
helps provide a = relatively disinterested (but not *un*-interested) summary =
so far:

I = am happy to hear from all of you guys, your notes are highly = appreciated!

=46rom an identity, = privacy an policy perspective, there's also this: any =
time you have something which = builds identity (and for the sake of this
discussion I'm going to treat 'long-term and relatively = accurate data
about location' = as a form of identity) into the online infrastructure, =
there is often some claimed = benefit from it, but there is also a
corresponding drawback in terms of privacy and security. =

For instance, copyright = law enforcement has been cited as one possible use =
of the location data - but = actually, GPS precision is almost certainly
excessive for this purpose, given that copyright regimes = apply at the
level of the = nation state, not the GPS co-ordinate... And once the data is =
in the header, it will get = used for whatever purpose people can find to =
exploit or monetize it. It is = by no means certain that all those purposes
will be in the interests of the end = user.

User should have the option of not sending = location update by setting all zeros in the location field, telling the = ISP routers not to do so as well, in that case the user protects his/her = privacy but loses the benefits of location-based services .. and if you = choose to let the ISP routers to tag your packets with location updates = then it will not be very accurate, it will be based on your physical = connection like mobile tower your connected to, or even less accurate = like the city (or even country) your are connecting from. In a way that = allows the implementation of copyright law without compromising the = privacy.


For example, 'language = preference expression' may seem like a neutral =
enough goal, but then we = should also consider - what happens if the
technical infrastructure starts to identify you = specifically as a Bosnian
Muslim, or as an Arab Israeli, or as a Kurd living in = Turkey...

technical infrastructure can do much more = if they have bad intents, they can simply identify Muslims, Arabs, Kurds = based on destinations (like Islamic websites or VoIP calls with area = code) so it's not only source, in fact they can do layer-7 = classification and marking based on the actual content of each packet - = unless your data are encrypted, and get much more information than your = physical location... again it's users option to set the location to all = zeros.

As I say, these are just my = thoughts as someone coming late to the
discussion and with no particular 'investment' in it to = pursue... hope
this is = useful, though.

I would like to thank you very much, = your professional points will defiantly add more value to the = draft.


[=85]

End of Geopriv Digest, Vol 102, Issue = 8
***************************************
<= br>= --Apple-Mail=_43AD48C6-A9A7-4DC9-9F53-C0AE3AB052B3-- From creed@opengeospatial.org Mon Nov 12 10:31:52 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB9E21F8748 for ; Mon, 12 Nov 2012 10:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhtzwMuJ5ZiK for ; Mon, 12 Nov 2012 10:31:51 -0800 (PST) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id 02C5A21F870B for ; Mon, 12 Nov 2012 10:31:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 970D294134; Mon, 12 Nov 2012 13:31:49 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (scale.ogcinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uw5fQwNANO+a; Mon, 12 Nov 2012 13:31:48 -0500 (EST) Received: from OfficeHP (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail.opengeospatial.org (Postfix) with ESMTPSA id D4D529412E; Mon, 12 Nov 2012 13:31:47 -0500 (EST) Message-ID: <6BC2112C874C4F2281D01F28A9C0D01D@OfficeHP> From: "Carl Reed" To: "Matt Lutze" , References: In-Reply-To: Date: Mon, 12 Nov 2012 11:31:21 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0F1A_01CDC0C9.3D62B150" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Subject: Re: [Geopriv] Geopriv Digest, Vol 102, Issue 8, message 1 & 3 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 18:31:52 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0F1A_01CDC0C9.3D62B150 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Also perhaps exposing my ignorance (not about geo but about IPv6), but = what about the location option to DHCP? =93Dynamic Host Configuration Protocol Options for Coordinate-Based = Location Configuration Information=94 [RFC 6225] This document specifies Dynamic Host Configuration Protocol options (both DHCPv4 and DHCPv6) for the coordinate-based geographic location of the client. Why not leverage existing work that has been = harmonized with location encodings and abstract models used in the IETF, = ISO, JTC1, OASIS, and the OGC? Cheers Carl From: Matt Lutze=20 Sent: Monday, November 12, 2012 10:32 AM To: geopriv@ietf.org=20 Subject: Re: [Geopriv] Geopriv Digest, Vol 102, Issue 8, message 1 & 3 Good day, I have a comment and a few observations, if I may expose my ignorance to = ask them (and apologize if the topics have already been discussed): First, the comment: IP addresses identify a device and it's location on the Internet, = not it's=20 geographical location (although there is some correlation, assuming = no=20 tunnels), or the person who is using it. Sounds very reasonable and I totally agree .. but don't we use IP = address to determine geographic locations? Isn't that what google, = youtube and other big names use to determine locations?=20 Outside of generally looking at an IP address to guess at a host's = regional location, I would posit that services today determine location = by asking a device to allow the service to use an Application layer = method for location detection=97accessing a GPS and/or Wi-Fi radio on = the device. =20 A few observations: The arguments for this extension seem to generally be focused on = providing services that may require or be preferred to have different = policies and implementations for the various higher level services that = actually need them. Another way, it would seem to me that a router using = GPS to indicate its physical location will use that differently than a = mobile device replying with its location to a web application.=20 Particularly, implementing GPS as an extension of IP means that special = considerations needed by an upper level protocol=97perhaps setting a TTL = for the location, or specifying a quality or resolution=97would all have = to be supported in IP, unnecessarily increasing the complexity of the = extension in a protocol whose paramount strength is its simplicity. = Ammar, is illustrated by the arguments you make in message 3 = below=97periodicity of updates should be a function of the application = layer protocol, not IP.=20 Further, given the notion that the IP header "should" be stripped from a = datagram before the payload is passed up to higher level protocols, I = would find it more logical that the GPS location be implemented in the = final protocol and not require the fuzzy layer boundary violations this = would imply.=20 Generally, I think my resistance is that IP is supposed to handle = internetwork addressing. Relaying a GPS location doesn't immediately = correlate with the purpose of providing a device with an address, or = servicing that address, and so it seems to me that GPS location doesn't = belong.=20 An HTTP-GPS, ICMP-GPS, etc., extension would seem the appropriate = implementation.=20 Respectfully, Matt Lutze On Nov 12, 2012, at 6:17 AM, geopriv-request@ietf.org wrote: Message: 1 Date: Mon, 12 Nov 2012 11:42:27 +0300 From: "Ammar Salih" To: "'Mark Smith'" Cc: geopriv@ietf.org, 'Eitan Adler' , ipv6@ietf.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header Message-ID: <50a0b679.82da0e0a.5577.64b9@mx.google.com> Content-Type: text/plain; charset=3D"UTF-8" IP addresses identify a device and it's location on the Internet, = not it's=20 geographical location (although there is some correlation, assuming = no=20 tunnels), or the person who is using it. Sounds very reasonable and I totally agree .. but don't we use IP = address to determine geographic locations? Isn't that what google, = youtube and other big names use to determine locations?=20 There is a Geolocation API for web browsers, perhaps it could be=20 generalised to suit other applications. http://dev.w3.org/geo/api/spec-source.html This is exactly what I am talking about, too many applications for the = same purpose, we need one lower layer mechanism to unify all of them and = make integration more flexible and compatible. To identify people, to then determine their attributes (e.g. their=20 preferred language), you have to use "attributes" of them, not the = machine=20 they're currently using or where it is located on the Internet e.g. = what=20 they know, what they are or what they have. This is how the majority of Internet work today, based on IP address, = I gave google as an example, plus language is not the only benefit, how = about other benefits, like Ads and commercials, I mentioned an example = of getting Ads of restaurants in my city instead of getting Ads about = all restaurants in country.=20 Ammar [=85] ----- Original Message ----- Message: 2 Date: Mon, 12 Nov 2012 10:11:21 +0000 From: Robin Wilton To: Ammar Salih Cc: "geopriv@ietf.org" , Eitan Adler , Mark Smith , "ipv6@ietf.org" Subject: Re: [Geopriv] Adding GPS location to IPv6 header Message-ID: <7D096E9B-457E-4247-B131-9F185152310B@isoc.org> Content-Type: text/plain; charset=3Dutf-8 Coming to this quite late in the discussion, here's my 2?, in case it = helps provide a relatively disinterested (but not *un*-interested) = summary so far: - The benefits expected from the proposed enhancement seem very hard = for the mailing list to pin down and express (some are disputed as = benefits, while others are acknowledged, but minor...). - Some use-cases have been described, but I think it would be fair to = say that none of them describes an absolute "can't live without it" need = for the enhancement. Most of the claimed benefits seem to be realisable = by other means, potentially for less effort. - The people who would have to do the work to implement and deploy the = enhancement are not the ones who would get the direct benefit - which = makes it hard to build a rationale for doing it. From an identity, privacy an policy perspective, there's also this: = any time you have something which builds identity (and for the sake of = this discussion I'm going to treat 'long-term and relatively accurate = data about location' as a form of identity) into the online = infrastructure, there is often some claimed benefit from it, but there = is also a corresponding drawback in terms of privacy and security.=20 For instance, copyright law enforcement has been cited as one possible = use of the location data - but actually, GPS precision is almost = certainly excessive for this purpose, given that copyright regimes apply = at the level of the nation state, not the GPS co-ordinate... And once = the data is in the header, it will get used for whatever purpose people = can find to exploit or monetize it. It is by no means certain that all = those purposes will be in the interests of the end user, For example, 'language preference expression' may seem like a neutral = enough goal, but then we should also consider - what happens if the = technical infrastructure starts to identify you specifically as a = Bosnian Muslim, or as an Arab Israeli, or as a Kurd living in Turkey...=20 As I say, these are just my thoughts as someone coming late to the = discussion and with no particular 'investment' in it to pursue... hope = this is useful, though. Yrs., Robin Robin Wilton Technical Outreach Director - Identity and Privacy -- [=85] Message: 3 Date: Mon, 12 Nov 2012 14:17:36 +0300 From: "Ammar Salih" To: "'Robin Wilton'" Cc: geopriv@ietf.org, 'Eitan Adler' , 'Mark Smith' , ipv6@ietf.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header Message-ID: <50a0dad6.4493980a.6c29.6b0e@mx.google.com> Content-Type: text/plain; charset=3D"UTF-8" Robin, Coming to this quite late in the discussion, here's my 2?, in case = it=20 helps provide a relatively disinterested (but not *un*-interested) = summary=20 so far: I am happy to hear from all of you guys, your notes are highly = appreciated!=20 From an identity, privacy an policy perspective, there's also this: = any=20 time you have something which builds identity (and for the sake of = this=20 discussion I'm going to treat 'long-term and relatively accurate = data=20 about location' as a form of identity) into the online = infrastructure,=20 there is often some claimed benefit from it, but there is also a=20 corresponding drawback in terms of privacy and security.=20 For instance, copyright law enforcement has been cited as one = possible use=20 of the location data - but actually, GPS precision is almost = certainly=20 excessive for this purpose, given that copyright regimes apply at = the=20 level of the nation state, not the GPS co-ordinate... And once the = data is=20 in the header, it will get used for whatever purpose people can find = to=20 exploit or monetize it. It is by no means certain that all those = purposes=20 will be in the interests of the end user. User should have the option of not sending location update by setting = all zeros in the location field, telling the ISP routers not to do so as = well, in that case the user protects his/her privacy but loses the = benefits of location-based services .. and if you choose to let the ISP = routers to tag your packets with location updates then it will not be = very accurate, it will be based on your physical connection like mobile = tower your connected to, or even less accurate like the city (or even = country) your are connecting from. In a way that allows the = implementation of copyright law without compromising the privacy. For example, 'language preference expression' may seem like a = neutral=20 enough goal, but then we should also consider - what happens if the=20 technical infrastructure starts to identify you specifically as a = Bosnian=20 Muslim, or as an Arab Israeli, or as a Kurd living in Turkey...=20 technical infrastructure can do much more if they have bad intents, = they can simply identify Muslims, Arabs, Kurds based on destinations = (like Islamic websites or VoIP calls with area code) so it's not only = source, in fact they can do layer-7 classification and marking based on = the actual content of each packet - unless your data are encrypted, and = get much more information than your physical location... again it's = users option to set the location to all zeros. As I say, these are just my thoughts as someone coming late to the=20 discussion and with no particular 'investment' in it to pursue... = hope=20 this is useful, though. I would like to thank you very much, your professional points will = defiantly add more value to the draft. [=85] End of Geopriv Digest, Vol 102, Issue 8 *************************************** -------------------------------------------------------------------------= ------- _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv ------=_NextPart_000_0F1A_01CDC0C9.3D62B150 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Also perhaps exposing my ignorance (not about geo but about IPv6), = but what=20 about the location option to DHCP?
 
=93Dynamic Host Configuration Protocol Options for = Coordinate-Based Location Configuration = Information=94 [RFC=20 6225]
 
This document specifies =
Dynamic Host Configuration Protocol options
   (both DHCPv4 and DHCPv6) for the coordinate-based geographic location
   of the client. 
Why not leverage existing = work that has=20 been harmonized with location encodings and abstract models used in the = IETF,=20 ISO, JTC1, OASIS, and the OGC?
 
Cheers
 
Carl
 
 
From: Matt Lutze
Sent: Monday, November 12, 2012 10:32 AM
Subject: Re: [Geopriv] Geopriv Digest, Vol 102, Issue 8, = message 1=20 & 3
 
Good day,
 
I have a comment and a few observations, if I may expose my = ignorance to=20 ask them (and apologize if the topics have already been = discussed):
 
First, the comment:
 
IP addresses identify a device and it's = location on=20 the Internet, not it's
geographical location (although there is = some=20 correlation, assuming no
tunnels), or the person who is using=20 it.

Sounds very reasonable and I totally agree .. = but=20 don't we use IP address to determine geographic locations? Isn't that = what=20 google, youtube and other big names use to determine locations?=20
 
Outside of generally looking at an IP address to guess at a host's = regional=20 location, I would posit that services today determine location by asking = a=20 device to allow the service to use an Application layer method for = location=20 detection=97accessing a GPS and/or Wi-Fi radio on the device.  =
 
 
A few observations:
 
The arguments for this extension seem to generally be focused on = providing=20 services that may require or be preferred to have different policies and = implementations for the various higher level services that actually need = them.=20 Another way, it would seem to me that a router using GPS to indicate its = physical location will use that differently than a mobile device = replying with=20 its location to a web application.
 
Particularly, implementing GPS as an extension of IP means that = special=20 considerations needed by an upper level protocol=97perhaps setting a TTL = for the=20 location, or specifying a quality or resolution=97would all have to be = supported=20 in IP, unnecessarily increasing the complexity of the extension in a = protocol=20 whose paramount strength is its simplicity. Ammar, is illustrated by the = arguments you make in message 3 below=97periodicity of updates should be = a=20 function of the application layer protocol, not IP.
 
Further, given the notion that the IP header "should" be stripped = from a=20 datagram before the payload is passed up to higher level protocols, I = would find=20 it more logical that the GPS location be implemented in the final = protocol and=20 not require the fuzzy layer boundary violations this would imply.
 
 
 
Generally, I think my resistance is that IP is supposed to handle=20 internetwork addressing. Relaying a GPS location doesn't immediately = correlate=20 with the purpose of providing a device with an address, or servicing = that=20 address, and so it seems to me that GPS location doesn't belong.
 
An HTTP-GPS, ICMP-GPS, etc., extension would seem the appropriate=20 implementation.
 
 
Respectfully,
Matt Lutze
 
 
On Nov 12, 2012, at 6:17 AM, geopriv-request@ietf.org = wrote:


Message:=20 1
Date: Mon, 12 Nov 2012 11:42:27 +0300
From: "Ammar Salih" = <ammar.salih@auis.edu.iq>To:=20 "'Mark Smith'" <markzzzsmith@yahoo.com.au&g= t;
Cc:=20 geopriv@ietf.org, 'Eitan = Adler' <lists@eitanadler.com>,
ipv6@ietf.org
Subject: Re: = [Geopriv] Adding=20 GPS location to IPv6 header
Message-ID:=20 <50a0b679.82da0e0a.5577.64b9@mx.google.com>
Content-Type:=20 text/plain;=20 charset=3D"UTF-8"

IP addresses identify a device and it's = location on=20 the Internet, not it's
geographical location (although there is = some=20 correlation, assuming no
tunnels), or the person who is using=20 it.

Sounds very reasonable and I totally agree .. = but=20 don't we use IP address to determine geographic locations? Isn't that = what=20 google, youtube and other big names use to determine locations? =


There is a Geolocation API for web browsers, = perhaps=20 it could be
generalised to suit other=20 applications.

http://dev.w3.org/geo/api/spec-source.html
=
This=20 is exactly what I am talking about, too many applications for the same = purpose, we need one lower layer mechanism to unify all of them and = make=20 integration more flexible and compatible.


To identify people, to then determine their=20 attributes (e.g. their
preferred language), you have to use = "attributes" of=20 them, not the machine
they're currently using or where it is = located on=20 the Internet e.g. what
they know, what they are or what they=20 have.

This is how the majority of Internet work = today,=20 based on IP address, I gave google as an example, plus language is not = the=20 only benefit, how about other benefits, like Ads and commercials, I = mentioned=20 an example of getting Ads of restaurants in my city instead of getting = Ads=20 about all restaurants in country.=20


Ammar

[=85]

----- Original Message -----

Message: 2
Date: Mon, 12 Nov 2012 = 10:11:21=20 +0000
From: Robin Wilton <wilton@isoc.org>
To: Ammar = Salih=20 <ammar.salih@auis.edu.iq>Cc:=20 "geopriv@ietf.org" <geopriv@ietf.org>, Eitan = Adler
<lists@eitanadler.com>, Mark Smith = <markzzzsmith@yahoo.com.au&g= t;,
"ipv6@ietf.org" <ipv6@ietf.org>
Subject: Re: = [Geopriv]=20 Adding GPS location to IPv6 header
Message-ID: <7D096E9B-45= 7E-4247-B131-9F185152310B@isoc.org>
Content-Type:=20 text/plain;=20 charset=3Dutf-8

Coming to this quite late in the = discussion,=20 here's my 2?, in case it helps provide a relatively disinterested (but = not=20 *un*-interested) summary so far:

- The benefits expected from = the=20 proposed enhancement seem very hard for the mailing list to pin down = and=20 express (some are disputed as benefits, while others are acknowledged, = but=20 minor...).

- Some use-cases have been described, but I think it = would=20 be fair to say that none of them describes an absolute "can't live = without it"=20 need for the enhancement. Most of the claimed benefits seem to be = realisable=20 by other means, potentially for less effort.

- The people who = would=20 have to do the work to implement and deploy the enhancement are not = the ones=20 who would get the direct benefit - which makes it hard to build a = rationale=20 for doing it.

From an identity, privacy an policy perspective, = there's=20 also this: any time you have something which builds identity (and for = the sake=20 of this discussion I'm going to treat 'long-term and relatively = accurate data=20 about location' as a form of identity) into the online infrastructure, = there=20 is often some claimed benefit from it, but there is also a = corresponding=20 drawback in terms of privacy and security.

For instance, = copyright law=20 enforcement has been cited as one possible use of the location data - = but=20 actually, GPS precision is almost certainly excessive for this = purpose, given=20 that copyright regimes apply at the level of the nation state, not the = GPS=20 co-ordinate... And once the data is in the header, it will get used = for=20 whatever purpose people can find to exploit or monetize it. It is by = no means=20 certain that all those purposes will be in the interests of the end=20 user,

For example, 'language preference expression' may seem = like a=20 neutral enough goal, but then we should also consider - what happens = if the=20 technical infrastructure starts to identify you specifically as a = Bosnian=20 Muslim, or as an Arab Israeli, or as a Kurd living in Turkey... =

As I=20 say, these are just my thoughts as someone coming late to the = discussion and=20 with no particular 'investment' in it to pursue... hope this is = useful,=20 though.

Yrs.,

Robin




Robin=20 Wilton

Technical Outreach Director - Identity and Privacy

--
 
[=85]

Message: 3
Date: Mon, 12 Nov 2012 14:17:36 +0300
From: = "Ammar=20 Salih" <ammar.salih@auis.edu.iq>To:=20 "'Robin Wilton'" <wilton@isoc.org>
Cc: geopriv@ietf.org, 'Eitan Adler' = <lists@eitanadler.com>, = 'Mark
Smith' <markzzzsmith@yahoo.com.au&g= t;, ipv6@ietf.org
Subject: Re: = [Geopriv] Adding=20 GPS location to IPv6 header
Message-ID: <50a0dad6.449398= 0a.6c29.6b0e@mx.google.com>
Content-Type:=20 text/plain;=20 charset=3D"UTF-8"

Robin,

Coming to this quite late in the discussion, = here's=20 my 2?, in case it
helps provide a relatively disinterested = (but not=20 *un*-interested) summary
so far:

I am happy to = hear from=20 all of you guys, your notes are highly appreciated!

From an identity, privacy an policy = perspective,=20 there's also this: any
time you have something which builds = identity (and=20 for the sake of this
discussion I'm going to treat 'long-term and = relatively accurate data
about location' as a form of identity) into = the=20 online infrastructure,
there is often some claimed benefit from it, = but=20 there is also a
corresponding drawback in terms of privacy = and=20 security.

For instance, copyright law enforcement has = been=20 cited as one possible use
of the location data - but actually, GPS = precision=20 is almost certainly
excessive for this purpose, given that = copyright=20 regimes apply at the
level of the nation state, not the GPS=20 co-ordinate... And once the data is
in the header, it will get used for whatever = purpose=20 people can find to
exploit or monetize it. It is by no means = certain=20 that all those purposes
will be in the interests of the end=20 user.

User should have the option of not sending = location=20 update by setting all zeros in the location field, telling the ISP = routers not=20 to do so as well, in that case the user protects his/her privacy but = loses the=20 benefits of location-based services .. and if you choose to let the = ISP=20 routers to tag your packets with location updates then it will not be = very=20 accurate, it will be based on your physical connection like mobile = tower your=20 connected to, or even less accurate like the city (or even country) = your are=20 connecting from. In a way that allows the implementation of copyright = law=20 without compromising the privacy.


For example, 'language preference = expression' may=20 seem like a neutral
enough goal, but then we should also = consider - what=20 happens if the
technical infrastructure starts to identify = you=20 specifically as a Bosnian
Muslim, or as an Arab Israeli, or as a Kurd = living=20 in Turkey...

technical infrastructure can do = much more if=20 they have bad intents, they can simply identify Muslims, Arabs, Kurds = based on=20 destinations (like Islamic websites or VoIP calls with area code) so = it's not=20 only source, in fact they can do layer-7 classification and marking = based on=20 the actual content of each packet - unless your data are encrypted, = and get=20 much more information than your physical location... again it's users = option=20 to set the location to all zeros.

As I say, these are just my thoughts as = someone=20 coming late to the
discussion and with no particular = 'investment' in it=20 to pursue... hope
this is useful, = though.

I would=20 like to thank you very much, your professional points will defiantly = add more=20 value to the draft.


[=85]

End of Geopriv Digest, Vol = 102,=20 Issue=20 8
***************************************
=


_______________________________________________
Geopriv mailing=20 list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv=
------=_NextPart_000_0F1A_01CDC0C9.3D62B150-- From kjones@skyhookwireless.com Mon Nov 12 11:22:54 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EAF21F8512 for ; Mon, 12 Nov 2012 11:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUIkm0iGWYE4 for ; Mon, 12 Nov 2012 11:22:52 -0800 (PST) Received: from server505.appriver.com (server505a.appriver.com [98.129.35.4]) by ietfa.amsl.com (Postfix) with ESMTP id CE88921F8751 for ; Mon, 12 Nov 2012 11:22:50 -0800 (PST) X-Note-AR-ScanTimeLocal: 11/12/2012 1:22:50 PM X-Policy: GLOBAL - skyhookwireless.com X-Policy: GLOBAL - skyhookwireless.com X-Policy: GLOBAL - skyhookwireless.com X-Primary: kjones@skyhookwireless.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @skyhookwireless.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: smtp.exg5.exghost.com X-Note-Return-Path: kjones@skyhookwireless.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G329 G330 G331 G332 G336 G337 G348 G444 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.8) with ESMTPS id 335919521; Mon, 12 Nov 2012 13:22:49 -0600 Received: from MBX02.exg5.exghost.com ([169.254.2.43]) by HT03.exg5.exghost.com ([98.129.23.45]) with mapi; Mon, 12 Nov 2012 13:22:46 -0600 From: Kipp Jones To: Carl Reed Date: Mon, 12 Nov 2012 13:22:42 -0600 Thread-Topic: [Geopriv] Geopriv Digest, Vol 102, Issue 8, message 1 & 3 Thread-Index: Ac3BCxgFxsCTNREzRU6C1AKMITx05Q== Message-ID: <4FAEF0E6-795E-4345-851C-6E6BC4C682DB@skyhookwireless.com> References: <6BC2112C874C4F2281D01F28A9C0D01D@OfficeHP> In-Reply-To: <6BC2112C874C4F2281D01F28A9C0D01D@OfficeHP> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4FAEF0E6795E4345851C6E6BC4C682DBskyhookwirelesscom_" MIME-Version: 1.0 Cc: "geopriv@ietf.org" , Matt Lutze Subject: Re: [Geopriv] Geopriv Digest, Vol 102, Issue 8, message 1 & 3 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 19:22:54 -0000 --_000_4FAEF0E6795E4345851C6E6BC4C682DBskyhookwirelesscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdCBhIG1pbm9yIHBvaW50LCBidXQgaGFzIGFueWJvZHkgY29uc2lkZXJlZCBob3cgbWFueSBy b3V0ZXJzIGJ1cmllZCBkZWVwIGluIGJ1aWxkaW5nIGluZnJhc3RydWN0dXJlIGNhbiBhY3R1YWxs eSByZWNlaXZlIGEgcmVsaWFibGUgR1BTIHNpZ25hbD8NCg0KSWYgZ2VvbG9jYXRpb24gaXMgdGhl IGludGVudCwgSSB3b3VsZCBzdWdnZXN0IHVzaW5nIGEgdGVjaG5vbG9neSBhZ25vc3RpYyBtb25p a2VyIHJhdGhlciB0aGFuIEdQUyB0byBpbmRpY2F0ZSB0aGF0IGludGVudC4NCg0KS2lwcA0KDQpT ZW50IGZyb20gbXkgaVBob25lDQoNCk9uIE5vdiAxMiwgMjAxMiwgYXQgMTozMSBQTSwgIkNhcmwg UmVlZCIgPGNyZWVkQG9wZW5nZW9zcGF0aWFsLm9yZzxtYWlsdG86Y3JlZWRAb3Blbmdlb3NwYXRp YWwub3JnPj4gd3JvdGU6DQoNCkFsc28gcGVyaGFwcyBleHBvc2luZyBteSBpZ25vcmFuY2UgKG5v dCBhYm91dCBnZW8gYnV0IGFib3V0IElQdjYpLCBidXQgd2hhdCBhYm91dCB0aGUgbG9jYXRpb24g b3B0aW9uIHRvIERIQ1A/DQoNCuKAnER5bmFtaWMgSG9zdCBDb25maWd1cmF0aW9uIFByb3RvY29s IE9wdGlvbnMgZm9yIENvb3JkaW5hdGUtQmFzZWQgTG9jYXRpb24gQ29uZmlndXJhdGlvbiBJbmZv cm1hdGlvbuKAnSBbUkZDIDYyMjVdDQoNCg0KVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgRHluYW1p YyBIb3N0IENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgb3B0aW9ucw0KICAgKGJvdGggREhDUHY0IGFu ZCBESENQdjYpIGZvciB0aGUgY29vcmRpbmF0ZS1iYXNlZCBnZW9ncmFwaGljIGxvY2F0aW9uDQog ICBvZiB0aGUgY2xpZW50Lg0KDQpXaHkgbm90IGxldmVyYWdlIGV4aXN0aW5nIHdvcmsgdGhhdCBo YXMgYmVlbiBoYXJtb25pemVkIHdpdGggbG9jYXRpb24gZW5jb2RpbmdzIGFuZCBhYnN0cmFjdCBt b2RlbHMgdXNlZCBpbiB0aGUgSUVURiwgSVNPLCBKVEMxLCBPQVNJUywgYW5kIHRoZSBPR0M/DQoN CkNoZWVycw0KDQpDYXJsDQoNCg0KRnJvbTogTWF0dCBMdXR6ZTxtYWlsdG86bWF0dGhldy5sdXR6 ZUBnbWFpbC5jb20+DQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDEyLCAyMDEyIDEwOjMyIEFNDQpU bzogZ2VvcHJpdkBpZXRmLm9yZzxtYWlsdG86Z2VvcHJpdkBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbR2VvcHJpdl0gR2VvcHJpdiBEaWdlc3QsIFZvbCAxMDIsIElzc3VlIDgsIG1lc3NhZ2UgMSAm IDMNCg0KR29vZCBkYXksDQoNCkkgaGF2ZSBhIGNvbW1lbnQgYW5kIGEgZmV3IG9ic2VydmF0aW9u cywgaWYgSSBtYXkgZXhwb3NlIG15IGlnbm9yYW5jZSB0byBhc2sgdGhlbSAoYW5kIGFwb2xvZ2l6 ZSBpZiB0aGUgdG9waWNzIGhhdmUgYWxyZWFkeSBiZWVuIGRpc2N1c3NlZCk6DQoNCkZpcnN0LCB0 aGUgY29tbWVudDoNCg0KSVAgYWRkcmVzc2VzIGlkZW50aWZ5IGEgZGV2aWNlIGFuZCBpdCdzIGxv Y2F0aW9uIG9uIHRoZSBJbnRlcm5ldCwgbm90IGl0J3MNCmdlb2dyYXBoaWNhbCBsb2NhdGlvbiAo YWx0aG91Z2ggdGhlcmUgaXMgc29tZSBjb3JyZWxhdGlvbiwgYXNzdW1pbmcgbm8NCnR1bm5lbHMp LCBvciB0aGUgcGVyc29uIHdobyBpcyB1c2luZyBpdC4NCg0KU291bmRzIHZlcnkgcmVhc29uYWJs ZSBhbmQgSSB0b3RhbGx5IGFncmVlIC4uIGJ1dCBkb24ndCB3ZSB1c2UgSVAgYWRkcmVzcyB0byBk ZXRlcm1pbmUgZ2VvZ3JhcGhpYyBsb2NhdGlvbnM/IElzbid0IHRoYXQgd2hhdCBnb29nbGUsIHlv dXR1YmUgYW5kIG90aGVyIGJpZyBuYW1lcyB1c2UgdG8gZGV0ZXJtaW5lIGxvY2F0aW9ucz8NCg0K T3V0c2lkZSBvZiBnZW5lcmFsbHkgbG9va2luZyBhdCBhbiBJUCBhZGRyZXNzIHRvIGd1ZXNzIGF0 IGEgaG9zdCdzIHJlZ2lvbmFsIGxvY2F0aW9uLCBJIHdvdWxkIHBvc2l0IHRoYXQgc2VydmljZXMg dG9kYXkgZGV0ZXJtaW5lIGxvY2F0aW9uIGJ5IGFza2luZyBhIGRldmljZSB0byBhbGxvdyB0aGUg c2VydmljZSB0byB1c2UgYW4gQXBwbGljYXRpb24gbGF5ZXIgbWV0aG9kIGZvciBsb2NhdGlvbiBk ZXRlY3Rpb27igJRhY2Nlc3NpbmcgYSBHUFMgYW5kL29yIFdpLUZpIHJhZGlvIG9uIHRoZSBkZXZp Y2UuDQoNCg0KQSBmZXcgb2JzZXJ2YXRpb25zOg0KDQpUaGUgYXJndW1lbnRzIGZvciB0aGlzIGV4 dGVuc2lvbiBzZWVtIHRvIGdlbmVyYWxseSBiZSBmb2N1c2VkIG9uIHByb3ZpZGluZyBzZXJ2aWNl cyB0aGF0IG1heSByZXF1aXJlIG9yIGJlIHByZWZlcnJlZCB0byBoYXZlIGRpZmZlcmVudCBwb2xp Y2llcyBhbmQgaW1wbGVtZW50YXRpb25zIGZvciB0aGUgdmFyaW91cyBoaWdoZXIgbGV2ZWwgc2Vy dmljZXMgdGhhdCBhY3R1YWxseSBuZWVkIHRoZW0uIEFub3RoZXIgd2F5LCBpdCB3b3VsZCBzZWVt IHRvIG1lIHRoYXQgYSByb3V0ZXIgdXNpbmcgR1BTIHRvIGluZGljYXRlIGl0cyBwaHlzaWNhbCBs b2NhdGlvbiB3aWxsIHVzZSB0aGF0IGRpZmZlcmVudGx5IHRoYW4gYSBtb2JpbGUgZGV2aWNlIHJl cGx5aW5nIHdpdGggaXRzIGxvY2F0aW9uIHRvIGEgd2ViIGFwcGxpY2F0aW9uLg0KDQpQYXJ0aWN1 bGFybHksIGltcGxlbWVudGluZyBHUFMgYXMgYW4gZXh0ZW5zaW9uIG9mIElQIG1lYW5zIHRoYXQg c3BlY2lhbCBjb25zaWRlcmF0aW9ucyBuZWVkZWQgYnkgYW4gdXBwZXIgbGV2ZWwgcHJvdG9jb2zi gJRwZXJoYXBzIHNldHRpbmcgYSBUVEwgZm9yIHRoZSBsb2NhdGlvbiwgb3Igc3BlY2lmeWluZyBh IHF1YWxpdHkgb3IgcmVzb2x1dGlvbuKAlHdvdWxkIGFsbCBoYXZlIHRvIGJlIHN1cHBvcnRlZCBp biBJUCwgdW5uZWNlc3NhcmlseSBpbmNyZWFzaW5nIHRoZSBjb21wbGV4aXR5IG9mIHRoZSBleHRl bnNpb24gaW4gYSBwcm90b2NvbCB3aG9zZSBwYXJhbW91bnQgc3RyZW5ndGggaXMgaXRzIHNpbXBs aWNpdHkuIEFtbWFyLCBpcyBpbGx1c3RyYXRlZCBieSB0aGUgYXJndW1lbnRzIHlvdSBtYWtlIGlu IG1lc3NhZ2UgMyBiZWxvd+KAlHBlcmlvZGljaXR5IG9mIHVwZGF0ZXMgc2hvdWxkIGJlIGEgZnVu Y3Rpb24gb2YgdGhlIGFwcGxpY2F0aW9uIGxheWVyIHByb3RvY29sLCBub3QgSVAuDQoNCkZ1cnRo ZXIsIGdpdmVuIHRoZSBub3Rpb24gdGhhdCB0aGUgSVAgaGVhZGVyICJzaG91bGQiIGJlIHN0cmlw cGVkIGZyb20gYSBkYXRhZ3JhbSBiZWZvcmUgdGhlIHBheWxvYWQgaXMgcGFzc2VkIHVwIHRvIGhp Z2hlciBsZXZlbCBwcm90b2NvbHMsIEkgd291bGQgZmluZCBpdCBtb3JlIGxvZ2ljYWwgdGhhdCB0 aGUgR1BTIGxvY2F0aW9uIGJlIGltcGxlbWVudGVkIGluIHRoZSBmaW5hbCBwcm90b2NvbCBhbmQg bm90IHJlcXVpcmUgdGhlIGZ1enp5IGxheWVyIGJvdW5kYXJ5IHZpb2xhdGlvbnMgdGhpcyB3b3Vs ZCBpbXBseS4NCg0KDQoNCkdlbmVyYWxseSwgSSB0aGluayBteSByZXNpc3RhbmNlIGlzIHRoYXQg SVAgaXMgc3VwcG9zZWQgdG8gaGFuZGxlIGludGVybmV0d29yayBhZGRyZXNzaW5nLiBSZWxheWlu ZyBhIEdQUyBsb2NhdGlvbiBkb2Vzbid0IGltbWVkaWF0ZWx5IGNvcnJlbGF0ZSB3aXRoIHRoZSBw dXJwb3NlIG9mIHByb3ZpZGluZyBhIGRldmljZSB3aXRoIGFuIGFkZHJlc3MsIG9yIHNlcnZpY2lu ZyB0aGF0IGFkZHJlc3MsIGFuZCBzbyBpdCBzZWVtcyB0byBtZSB0aGF0IEdQUyBsb2NhdGlvbiBk b2Vzbid0IGJlbG9uZy4NCg0KQW4gSFRUUC1HUFMsIElDTVAtR1BTLCBldGMuLCBleHRlbnNpb24g d291bGQgc2VlbSB0aGUgYXBwcm9wcmlhdGUgaW1wbGVtZW50YXRpb24uDQoNCg0KUmVzcGVjdGZ1 bGx5LA0KTWF0dCBMdXR6ZQ0KDQoNCk9uIE5vdiAxMiwgMjAxMiwgYXQgNjoxNyBBTSwgZ2VvcHJp di1yZXF1ZXN0QGlldGYub3JnPG1haWx0bzpnZW9wcml2LXJlcXVlc3RAaWV0Zi5vcmc+IHdyb3Rl Og0KDQoNCk1lc3NhZ2U6IDENCkRhdGU6IE1vbiwgMTIgTm92IDIwMTIgMTE6NDI6MjcgKzAzMDAN CkZyb206ICJBbW1hciBTYWxpaCIgPGFtbWFyLnNhbGloQGF1aXMuZWR1LmlxPG1haWx0bzphbW1h ci5zYWxpaEBhdWlzLmVkdS5pcT4+DQpUbzogIidNYXJrIFNtaXRoJyIgPG1hcmt6enpzbWl0aEB5 YWhvby5jb20uYXU8bWFpbHRvOm1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU+Pg0KQ2M6IGdlb3By aXZAaWV0Zi5vcmc8bWFpbHRvOmdlb3ByaXZAaWV0Zi5vcmc+LCAnRWl0YW4gQWRsZXInIDxsaXN0 c0BlaXRhbmFkbGVyLmNvbTxtYWlsdG86bGlzdHNAZWl0YW5hZGxlci5jb20+PiwNCmlwdjZAaWV0 Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0dlb3ByaXZdIEFkZGlu ZyBHUFMgbG9jYXRpb24gdG8gSVB2NiBoZWFkZXINCk1lc3NhZ2UtSUQ6IDw1MGEwYjY3OS44MmRh MGUwYS41NTc3LjY0YjlAbXguZ29vZ2xlLmNvbTxtYWlsdG86NTBhMGI2NzkuODJkYTBlMGEuNTU3 Ny42NGI5QG14Lmdvb2dsZS5jb20+Pg0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0 PSJVVEYtOCINCg0KSVAgYWRkcmVzc2VzIGlkZW50aWZ5IGEgZGV2aWNlIGFuZCBpdCdzIGxvY2F0 aW9uIG9uIHRoZSBJbnRlcm5ldCwgbm90IGl0J3MNCmdlb2dyYXBoaWNhbCBsb2NhdGlvbiAoYWx0 aG91Z2ggdGhlcmUgaXMgc29tZSBjb3JyZWxhdGlvbiwgYXNzdW1pbmcgbm8NCnR1bm5lbHMpLCBv ciB0aGUgcGVyc29uIHdobyBpcyB1c2luZyBpdC4NCg0KU291bmRzIHZlcnkgcmVhc29uYWJsZSBh bmQgSSB0b3RhbGx5IGFncmVlIC4uIGJ1dCBkb24ndCB3ZSB1c2UgSVAgYWRkcmVzcyB0byBkZXRl cm1pbmUgZ2VvZ3JhcGhpYyBsb2NhdGlvbnM/IElzbid0IHRoYXQgd2hhdCBnb29nbGUsIHlvdXR1 YmUgYW5kIG90aGVyIGJpZyBuYW1lcyB1c2UgdG8gZGV0ZXJtaW5lIGxvY2F0aW9ucz8NCg0KDQpU aGVyZSBpcyBhIEdlb2xvY2F0aW9uIEFQSSBmb3Igd2ViIGJyb3dzZXJzLCBwZXJoYXBzIGl0IGNv dWxkIGJlDQpnZW5lcmFsaXNlZCB0byBzdWl0IG90aGVyIGFwcGxpY2F0aW9ucy4NCg0KaHR0cDov L2Rldi53My5vcmcvZ2VvL2FwaS9zcGVjLXNvdXJjZS5odG1sDQoNClRoaXMgaXMgZXhhY3RseSB3 aGF0IEkgYW0gdGFsa2luZyBhYm91dCwgdG9vIG1hbnkgYXBwbGljYXRpb25zIGZvciB0aGUgc2Ft ZSBwdXJwb3NlLCB3ZSBuZWVkIG9uZSBsb3dlciBsYXllciBtZWNoYW5pc20gdG8gdW5pZnkgYWxs IG9mIHRoZW0gYW5kIG1ha2UgaW50ZWdyYXRpb24gbW9yZSBmbGV4aWJsZSBhbmQgY29tcGF0aWJs ZS4NCg0KDQpUbyBpZGVudGlmeSBwZW9wbGUsIHRvIHRoZW4gZGV0ZXJtaW5lIHRoZWlyIGF0dHJp YnV0ZXMgKGUuZy4gdGhlaXINCnByZWZlcnJlZCBsYW5ndWFnZSksIHlvdSBoYXZlIHRvIHVzZSAi YXR0cmlidXRlcyIgb2YgdGhlbSwgbm90IHRoZSBtYWNoaW5lDQp0aGV5J3JlIGN1cnJlbnRseSB1 c2luZyBvciB3aGVyZSBpdCBpcyBsb2NhdGVkIG9uIHRoZSBJbnRlcm5ldCBlLmcuIHdoYXQNCnRo ZXkga25vdywgd2hhdCB0aGV5IGFyZSBvciB3aGF0IHRoZXkgaGF2ZS4NCg0KVGhpcyBpcyBob3cg dGhlIG1ham9yaXR5IG9mIEludGVybmV0IHdvcmsgdG9kYXksIGJhc2VkIG9uIElQIGFkZHJlc3Ms IEkgZ2F2ZSBnb29nbGUgYXMgYW4gZXhhbXBsZSwgcGx1cyBsYW5ndWFnZSBpcyBub3QgdGhlIG9u bHkgYmVuZWZpdCwgaG93IGFib3V0IG90aGVyIGJlbmVmaXRzLCBsaWtlIEFkcyBhbmQgY29tbWVy Y2lhbHMsIEkgbWVudGlvbmVkIGFuIGV4YW1wbGUgb2YgZ2V0dGluZyBBZHMgb2YgcmVzdGF1cmFu dHMgaW4gbXkgY2l0eSBpbnN0ZWFkIG9mIGdldHRpbmcgQWRzIGFib3V0IGFsbCByZXN0YXVyYW50 cyBpbiBjb3VudHJ5Lg0KDQoNCkFtbWFyDQoNClvigKZdDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0NCg0KTWVzc2FnZTogMg0KRGF0ZTogTW9uLCAxMiBOb3YgMjAxMiAxMDoxMToyMSAr MDAwMA0KRnJvbTogUm9iaW4gV2lsdG9uIDx3aWx0b25AaXNvYy5vcmc8bWFpbHRvOndpbHRvbkBp c29jLm9yZz4+DQpUbzogQW1tYXIgU2FsaWggPGFtbWFyLnNhbGloQGF1aXMuZWR1LmlxPG1haWx0 bzphbW1hci5zYWxpaEBhdWlzLmVkdS5pcT4+DQpDYzogImdlb3ByaXZAaWV0Zi5vcmc8bWFpbHRv Omdlb3ByaXZAaWV0Zi5vcmc+IiA8Z2VvcHJpdkBpZXRmLm9yZzxtYWlsdG86Z2VvcHJpdkBpZXRm Lm9yZz4+LCBFaXRhbiBBZGxlcg0KPGxpc3RzQGVpdGFuYWRsZXIuY29tPG1haWx0bzpsaXN0c0Bl aXRhbmFkbGVyLmNvbT4+LCBNYXJrIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1PG1h aWx0bzptYXJrenp6c21pdGhAeWFob28uY29tLmF1Pj4sDQoiaXB2NkBpZXRmLm9yZzxtYWlsdG86 aXB2NkBpZXRmLm9yZz4iIDxpcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYub3JnPj4NClN1 YmplY3Q6IFJlOiBbR2VvcHJpdl0gQWRkaW5nIEdQUyBsb2NhdGlvbiB0byBJUHY2IGhlYWRlcg0K TWVzc2FnZS1JRDogPDdEMDk2RTlCLTQ1N0UtNDI0Ny1CMTMxLTlGMTg1MTUyMzEwQkBpc29jLm9y ZzxtYWlsdG86N0QwOTZFOUItNDU3RS00MjQ3LUIxMzEtOUYxODUxNTIzMTBCQGlzb2Mub3JnPj4N CkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD11dGYtOA0KDQpDb21pbmcgdG8gdGhp cyBxdWl0ZSBsYXRlIGluIHRoZSBkaXNjdXNzaW9uLCBoZXJlJ3MgbXkgMj8sIGluIGNhc2UgaXQg aGVscHMgcHJvdmlkZSBhIHJlbGF0aXZlbHkgZGlzaW50ZXJlc3RlZCAoYnV0IG5vdCAqdW4qLWlu dGVyZXN0ZWQpIHN1bW1hcnkgc28gZmFyOg0KDQotIFRoZSBiZW5lZml0cyBleHBlY3RlZCBmcm9t IHRoZSBwcm9wb3NlZCBlbmhhbmNlbWVudCBzZWVtIHZlcnkgaGFyZCBmb3IgdGhlIG1haWxpbmcg bGlzdCB0byBwaW4gZG93biBhbmQgZXhwcmVzcyAoc29tZSBhcmUgZGlzcHV0ZWQgYXMgYmVuZWZp dHMsIHdoaWxlIG90aGVycyBhcmUgYWNrbm93bGVkZ2VkLCBidXQgbWlub3IuLi4pLg0KDQotIFNv bWUgdXNlLWNhc2VzIGhhdmUgYmVlbiBkZXNjcmliZWQsIGJ1dCBJIHRoaW5rIGl0IHdvdWxkIGJl IGZhaXIgdG8gc2F5IHRoYXQgbm9uZSBvZiB0aGVtIGRlc2NyaWJlcyBhbiBhYnNvbHV0ZSAiY2Fu J3QgbGl2ZSB3aXRob3V0IGl0IiBuZWVkIGZvciB0aGUgZW5oYW5jZW1lbnQuIE1vc3Qgb2YgdGhl IGNsYWltZWQgYmVuZWZpdHMgc2VlbSB0byBiZSByZWFsaXNhYmxlIGJ5IG90aGVyIG1lYW5zLCBw b3RlbnRpYWxseSBmb3IgbGVzcyBlZmZvcnQuDQoNCi0gVGhlIHBlb3BsZSB3aG8gd291bGQgaGF2 ZSB0byBkbyB0aGUgd29yayB0byBpbXBsZW1lbnQgYW5kIGRlcGxveSB0aGUgZW5oYW5jZW1lbnQg YXJlIG5vdCB0aGUgb25lcyB3aG8gd291bGQgZ2V0IHRoZSBkaXJlY3QgYmVuZWZpdCAtIHdoaWNo IG1ha2VzIGl0IGhhcmQgdG8gYnVpbGQgYSByYXRpb25hbGUgZm9yIGRvaW5nIGl0Lg0KDQpGcm9t IGFuIGlkZW50aXR5LCBwcml2YWN5IGFuIHBvbGljeSBwZXJzcGVjdGl2ZSwgdGhlcmUncyBhbHNv IHRoaXM6IGFueSB0aW1lIHlvdSBoYXZlIHNvbWV0aGluZyB3aGljaCBidWlsZHMgaWRlbnRpdHkg KGFuZCBmb3IgdGhlIHNha2Ugb2YgdGhpcyBkaXNjdXNzaW9uIEknbSBnb2luZyB0byB0cmVhdCAn bG9uZy10ZXJtIGFuZCByZWxhdGl2ZWx5IGFjY3VyYXRlIGRhdGEgYWJvdXQgbG9jYXRpb24nIGFz IGEgZm9ybSBvZiBpZGVudGl0eSkgaW50byB0aGUgb25saW5lIGluZnJhc3RydWN0dXJlLCB0aGVy ZSBpcyBvZnRlbiBzb21lIGNsYWltZWQgYmVuZWZpdCBmcm9tIGl0LCBidXQgdGhlcmUgaXMgYWxz byBhIGNvcnJlc3BvbmRpbmcgZHJhd2JhY2sgaW4gdGVybXMgb2YgcHJpdmFjeSBhbmQgc2VjdXJp dHkuDQoNCkZvciBpbnN0YW5jZSwgY29weXJpZ2h0IGxhdyBlbmZvcmNlbWVudCBoYXMgYmVlbiBj aXRlZCBhcyBvbmUgcG9zc2libGUgdXNlIG9mIHRoZSBsb2NhdGlvbiBkYXRhIC0gYnV0IGFjdHVh bGx5LCBHUFMgcHJlY2lzaW9uIGlzIGFsbW9zdCBjZXJ0YWlubHkgZXhjZXNzaXZlIGZvciB0aGlz IHB1cnBvc2UsIGdpdmVuIHRoYXQgY29weXJpZ2h0IHJlZ2ltZXMgYXBwbHkgYXQgdGhlIGxldmVs IG9mIHRoZSBuYXRpb24gc3RhdGUsIG5vdCB0aGUgR1BTIGNvLW9yZGluYXRlLi4uIEFuZCBvbmNl IHRoZSBkYXRhIGlzIGluIHRoZSBoZWFkZXIsIGl0IHdpbGwgZ2V0IHVzZWQgZm9yIHdoYXRldmVy IHB1cnBvc2UgcGVvcGxlIGNhbiBmaW5kIHRvIGV4cGxvaXQgb3IgbW9uZXRpemUgaXQuIEl0IGlz IGJ5IG5vIG1lYW5zIGNlcnRhaW4gdGhhdCBhbGwgdGhvc2UgcHVycG9zZXMgd2lsbCBiZSBpbiB0 aGUgaW50ZXJlc3RzIG9mIHRoZSBlbmQgdXNlciwNCg0KRm9yIGV4YW1wbGUsICdsYW5ndWFnZSBw cmVmZXJlbmNlIGV4cHJlc3Npb24nIG1heSBzZWVtIGxpa2UgYSBuZXV0cmFsIGVub3VnaCBnb2Fs LCBidXQgdGhlbiB3ZSBzaG91bGQgYWxzbyBjb25zaWRlciAtIHdoYXQgaGFwcGVucyBpZiB0aGUg dGVjaG5pY2FsIGluZnJhc3RydWN0dXJlIHN0YXJ0cyB0byBpZGVudGlmeSB5b3Ugc3BlY2lmaWNh bGx5IGFzIGEgQm9zbmlhbiBNdXNsaW0sIG9yIGFzIGFuIEFyYWIgSXNyYWVsaSwgb3IgYXMgYSBL dXJkIGxpdmluZyBpbiBUdXJrZXkuLi4NCg0KQXMgSSBzYXksIHRoZXNlIGFyZSBqdXN0IG15IHRo b3VnaHRzIGFzIHNvbWVvbmUgY29taW5nIGxhdGUgdG8gdGhlIGRpc2N1c3Npb24gYW5kIHdpdGgg bm8gcGFydGljdWxhciAnaW52ZXN0bWVudCcgaW4gaXQgdG8gcHVyc3VlLi4uIGhvcGUgdGhpcyBp cyB1c2VmdWwsIHRob3VnaC4NCg0KWXJzLiwNCg0KUm9iaW4NCg0KDQoNCg0KUm9iaW4gV2lsdG9u DQoNClRlY2huaWNhbCBPdXRyZWFjaCBEaXJlY3RvciAtIElkZW50aXR5IGFuZCBQcml2YWN5DQoN Ci0tDQoNClvigKZdDQoNCk1lc3NhZ2U6IDMNCkRhdGU6IE1vbiwgMTIgTm92IDIwMTIgMTQ6MTc6 MzYgKzAzMDANCkZyb206ICJBbW1hciBTYWxpaCIgPGFtbWFyLnNhbGloQGF1aXMuZWR1LmlxPG1h aWx0bzphbW1hci5zYWxpaEBhdWlzLmVkdS5pcT4+DQpUbzogIidSb2JpbiBXaWx0b24nIiA8d2ls dG9uQGlzb2Mub3JnPG1haWx0bzp3aWx0b25AaXNvYy5vcmc+Pg0KQ2M6IGdlb3ByaXZAaWV0Zi5v cmc8bWFpbHRvOmdlb3ByaXZAaWV0Zi5vcmc+LCAnRWl0YW4gQWRsZXInIDxsaXN0c0BlaXRhbmFk bGVyLmNvbTxtYWlsdG86bGlzdHNAZWl0YW5hZGxlci5jb20+PiwgJ01hcmsNClNtaXRoJyA8bWFy a3p6enNtaXRoQHlhaG9vLmNvbS5hdTxtYWlsdG86bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4+ LCBpcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtHZW9w cml2XSBBZGRpbmcgR1BTIGxvY2F0aW9uIHRvIElQdjYgaGVhZGVyDQpNZXNzYWdlLUlEOiA8NTBh MGRhZDYuNDQ5Mzk4MGEuNmMyOS42YjBlQG14Lmdvb2dsZS5jb208bWFpbHRvOjUwYTBkYWQ2LjQ0 OTM5ODBhLjZjMjkuNmIwZUBteC5nb29nbGUuY29tPj4NCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFp bjsgY2hhcnNldD0iVVRGLTgiDQoNClJvYmluLA0KDQpDb21pbmcgdG8gdGhpcyBxdWl0ZSBsYXRl IGluIHRoZSBkaXNjdXNzaW9uLCBoZXJlJ3MgbXkgMj8sIGluIGNhc2UgaXQNCmhlbHBzIHByb3Zp ZGUgYSByZWxhdGl2ZWx5IGRpc2ludGVyZXN0ZWQgKGJ1dCBub3QgKnVuKi1pbnRlcmVzdGVkKSBz dW1tYXJ5DQpzbyBmYXI6DQoNCkkgYW0gaGFwcHkgdG8gaGVhciBmcm9tIGFsbCBvZiB5b3UgZ3V5 cywgeW91ciBub3RlcyBhcmUgaGlnaGx5IGFwcHJlY2lhdGVkIQ0KDQpGcm9tIGFuIGlkZW50aXR5 LCBwcml2YWN5IGFuIHBvbGljeSBwZXJzcGVjdGl2ZSwgdGhlcmUncyBhbHNvIHRoaXM6IGFueQ0K dGltZSB5b3UgaGF2ZSBzb21ldGhpbmcgd2hpY2ggYnVpbGRzIGlkZW50aXR5IChhbmQgZm9yIHRo ZSBzYWtlIG9mIHRoaXMNCmRpc2N1c3Npb24gSSdtIGdvaW5nIHRvIHRyZWF0ICdsb25nLXRlcm0g YW5kIHJlbGF0aXZlbHkgYWNjdXJhdGUgZGF0YQ0KYWJvdXQgbG9jYXRpb24nIGFzIGEgZm9ybSBv ZiBpZGVudGl0eSkgaW50byB0aGUgb25saW5lIGluZnJhc3RydWN0dXJlLA0KdGhlcmUgaXMgb2Z0 ZW4gc29tZSBjbGFpbWVkIGJlbmVmaXQgZnJvbSBpdCwgYnV0IHRoZXJlIGlzIGFsc28gYQ0KY29y cmVzcG9uZGluZyBkcmF3YmFjayBpbiB0ZXJtcyBvZiBwcml2YWN5IGFuZCBzZWN1cml0eS4NCg0K Rm9yIGluc3RhbmNlLCBjb3B5cmlnaHQgbGF3IGVuZm9yY2VtZW50IGhhcyBiZWVuIGNpdGVkIGFz IG9uZSBwb3NzaWJsZSB1c2UNCm9mIHRoZSBsb2NhdGlvbiBkYXRhIC0gYnV0IGFjdHVhbGx5LCBH UFMgcHJlY2lzaW9uIGlzIGFsbW9zdCBjZXJ0YWlubHkNCmV4Y2Vzc2l2ZSBmb3IgdGhpcyBwdXJw b3NlLCBnaXZlbiB0aGF0IGNvcHlyaWdodCByZWdpbWVzIGFwcGx5IGF0IHRoZQ0KbGV2ZWwgb2Yg dGhlIG5hdGlvbiBzdGF0ZSwgbm90IHRoZSBHUFMgY28tb3JkaW5hdGUuLi4gQW5kIG9uY2UgdGhl IGRhdGEgaXMNCmluIHRoZSBoZWFkZXIsIGl0IHdpbGwgZ2V0IHVzZWQgZm9yIHdoYXRldmVyIHB1 cnBvc2UgcGVvcGxlIGNhbiBmaW5kIHRvDQpleHBsb2l0IG9yIG1vbmV0aXplIGl0LiBJdCBpcyBi eSBubyBtZWFucyBjZXJ0YWluIHRoYXQgYWxsIHRob3NlIHB1cnBvc2VzDQp3aWxsIGJlIGluIHRo ZSBpbnRlcmVzdHMgb2YgdGhlIGVuZCB1c2VyLg0KDQpVc2VyIHNob3VsZCBoYXZlIHRoZSBvcHRp b24gb2Ygbm90IHNlbmRpbmcgbG9jYXRpb24gdXBkYXRlIGJ5IHNldHRpbmcgYWxsIHplcm9zIGlu IHRoZSBsb2NhdGlvbiBmaWVsZCwgdGVsbGluZyB0aGUgSVNQIHJvdXRlcnMgbm90IHRvIGRvIHNv IGFzIHdlbGwsIGluIHRoYXQgY2FzZSB0aGUgdXNlciBwcm90ZWN0cyBoaXMvaGVyIHByaXZhY3kg YnV0IGxvc2VzIHRoZSBiZW5lZml0cyBvZiBsb2NhdGlvbi1iYXNlZCBzZXJ2aWNlcyAuLiBhbmQg aWYgeW91IGNob29zZSB0byBsZXQgdGhlIElTUCByb3V0ZXJzIHRvIHRhZyB5b3VyIHBhY2tldHMg d2l0aCBsb2NhdGlvbiB1cGRhdGVzIHRoZW4gaXQgd2lsbCBub3QgYmUgdmVyeSBhY2N1cmF0ZSwg aXQgd2lsbCBiZSBiYXNlZCBvbiB5b3VyIHBoeXNpY2FsIGNvbm5lY3Rpb24gbGlrZSBtb2JpbGUg dG93ZXIgeW91ciBjb25uZWN0ZWQgdG8sIG9yIGV2ZW4gbGVzcyBhY2N1cmF0ZSBsaWtlIHRoZSBj aXR5IChvciBldmVuIGNvdW50cnkpIHlvdXIgYXJlIGNvbm5lY3RpbmcgZnJvbS4gSW4gYSB3YXkg dGhhdCBhbGxvd3MgdGhlIGltcGxlbWVudGF0aW9uIG9mIGNvcHlyaWdodCBsYXcgd2l0aG91dCBj b21wcm9taXNpbmcgdGhlIHByaXZhY3kuDQoNCg0KRm9yIGV4YW1wbGUsICdsYW5ndWFnZSBwcmVm ZXJlbmNlIGV4cHJlc3Npb24nIG1heSBzZWVtIGxpa2UgYSBuZXV0cmFsDQplbm91Z2ggZ29hbCwg YnV0IHRoZW4gd2Ugc2hvdWxkIGFsc28gY29uc2lkZXIgLSB3aGF0IGhhcHBlbnMgaWYgdGhlDQp0 ZWNobmljYWwgaW5mcmFzdHJ1Y3R1cmUgc3RhcnRzIHRvIGlkZW50aWZ5IHlvdSBzcGVjaWZpY2Fs bHkgYXMgYSBCb3NuaWFuDQpNdXNsaW0sIG9yIGFzIGFuIEFyYWIgSXNyYWVsaSwgb3IgYXMgYSBL dXJkIGxpdmluZyBpbiBUdXJrZXkuLi4NCg0KdGVjaG5pY2FsIGluZnJhc3RydWN0dXJlIGNhbiBk byBtdWNoIG1vcmUgaWYgdGhleSBoYXZlIGJhZCBpbnRlbnRzLCB0aGV5IGNhbiBzaW1wbHkgaWRl bnRpZnkgTXVzbGltcywgQXJhYnMsIEt1cmRzIGJhc2VkIG9uIGRlc3RpbmF0aW9ucyAobGlrZSBJ c2xhbWljIHdlYnNpdGVzIG9yIFZvSVAgY2FsbHMgd2l0aCBhcmVhIGNvZGUpIHNvIGl0J3Mgbm90 IG9ubHkgc291cmNlLCBpbiBmYWN0IHRoZXkgY2FuIGRvIGxheWVyLTcgY2xhc3NpZmljYXRpb24g YW5kIG1hcmtpbmcgYmFzZWQgb24gdGhlIGFjdHVhbCBjb250ZW50IG9mIGVhY2ggcGFja2V0IC0g dW5sZXNzIHlvdXIgZGF0YSBhcmUgZW5jcnlwdGVkLCBhbmQgZ2V0IG11Y2ggbW9yZSBpbmZvcm1h dGlvbiB0aGFuIHlvdXIgcGh5c2ljYWwgbG9jYXRpb24uLi4gYWdhaW4gaXQncyB1c2VycyBvcHRp b24gdG8gc2V0IHRoZSBsb2NhdGlvbiB0byBhbGwgemVyb3MuDQoNCkFzIEkgc2F5LCB0aGVzZSBh cmUganVzdCBteSB0aG91Z2h0cyBhcyBzb21lb25lIGNvbWluZyBsYXRlIHRvIHRoZQ0KZGlzY3Vz c2lvbiBhbmQgd2l0aCBubyBwYXJ0aWN1bGFyICdpbnZlc3RtZW50JyBpbiBpdCB0byBwdXJzdWUu Li4gaG9wZQ0KdGhpcyBpcyB1c2VmdWwsIHRob3VnaC4NCg0KSSB3b3VsZCBsaWtlIHRvIHRoYW5r IHlvdSB2ZXJ5IG11Y2gsIHlvdXIgcHJvZmVzc2lvbmFsIHBvaW50cyB3aWxsIGRlZmlhbnRseSBh ZGQgbW9yZSB2YWx1ZSB0byB0aGUgZHJhZnQuDQoNCg0KW+KApl0NCg0KRW5kIG9mIEdlb3ByaXYg RGlnZXN0LCBWb2wgMTAyLCBJc3N1ZSA4DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkdlb3ByaXYgbWFpbGluZyBs aXN0DQpHZW9wcml2QGlldGYub3JnPG1haWx0bzpHZW9wcml2QGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nZW9wcml2DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KR2VvcHJpdiBtYWlsaW5nIGxpc3QNCkdlb3By aXZAaWV0Zi5vcmc8bWFpbHRvOkdlb3ByaXZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2dlb3ByaXYNCg== --_000_4FAEF0E6795E4345851C6E6BC4C682DBskyhookwirelesscom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+SnVzdCBh IG1pbm9yIHBvaW50LCBidXQgaGFzIGFueWJvZHkgY29uc2lkZXJlZCBob3cgbWFueSByb3V0ZXJz IGJ1cmllZCBkZWVwIGluIGJ1aWxkaW5nIGluZnJhc3RydWN0dXJlIGNhbiBhY3R1YWxseSByZWNl aXZlIGEgcmVsaWFibGUgR1BTIHNpZ25hbD88L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PklmIGdl b2xvY2F0aW9uIGlzIHRoZSBpbnRlbnQsIEkgd291bGQgc3VnZ2VzdCB1c2luZyBhIHRlY2hub2xv Z3kgYWdub3N0aWMgbW9uaWtlciByYXRoZXIgdGhhbiBHUFMgdG8gaW5kaWNhdGUgdGhhdCBpbnRl bnQuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5LaXBwPC9kaXY+PGRpdj48YnI+U2VudCBmcm9t IG15IGlQaG9uZTwvZGl2PjxkaXY+PGJyPk9uIE5vdiAxMiwgMjAxMiwgYXQgMTozMSBQTSwgIkNh cmwgUmVlZCIgJmx0OzxhIGhyZWY9Im1haWx0bzpjcmVlZEBvcGVuZ2Vvc3BhdGlhbC5vcmciPmNy ZWVkQG9wZW5nZW9zcGF0aWFsLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+PC9kaXY+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj4NCg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IENPTE9SOiAjMDAwMDAwOyBGT05ULVNJWkU6 IDEycHQiPg0KPGRpdj5BbHNvIHBlcmhhcHMgZXhwb3NpbmcgbXkgaWdub3JhbmNlIChub3QgYWJv dXQgZ2VvIGJ1dCBhYm91dCBJUHY2KSwgYnV0IHdoYXQgDQphYm91dCB0aGUgbG9jYXRpb24gb3B0 aW9uIHRvIERIQ1A/PC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNzPSJoMSI+PC9zcGFuPiZuYnNwOzwv ZGl2Pg0KPGRpdj48c3BhbiBjbGFzcz0iaDEiPuKAnER5bmFtaWMgSG9zdCBDb25maWd1cmF0aW9u IFByb3RvY29sIE9wdGlvbnMgZm9yIA0KPC9zcGFuPjxzcGFuIGNsYXNzPSJoMSI+Q29vcmRpbmF0 ZS1CYXNlZCBMb2NhdGlvbiBDb25maWd1cmF0aW9uIEluZm9ybWF0aW9u4oCdIFtSRkMgDQo2MjI1 XTwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9ImgxIj48L3NwYW4+Jm5ic3A7PC9kaXY+ PHByZT5UaGlzIGRvY3VtZW50IHNwZWNpZmllcyBEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBQ cm90b2NvbCBvcHRpb25zDQogICAoYm90aCBESENQdjQgYW5kIERIQ1B2NikgZm9yIHRoZSBjb29y ZGluYXRlLWJhc2VkIGdlb2dyYXBoaWMgbG9jYXRpb24NCiAgIG9mIHRoZSBjbGllbnQuIDwvcHJl Pg0KPGRpdiBzdHlsZT0iRk9OVC1TVFlMRTogbm9ybWFsOyBESVNQTEFZOiBpbmxpbmU7IEZPTlQt RkFNSUxZOiAnQ2FsaWJyaSc7IENPTE9SOiAjMDAwMDAwOyBGT05ULVNJWkU6IHNtYWxsOyBGT05U LVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046IG5vbmUiPg0KPGRpdiBzdHlsZT0iRk9O VDogMTBwdCB0YWhvbWEiPg0KPGRpdj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPldoeSBub3QgbGV2ZXJhZ2UgZXhpc3Rpbmcgd29yayB0aGF0IGhhcyANCmJlZW4gaGFybW9u aXplZCB3aXRoIGxvY2F0aW9uIGVuY29kaW5ncyBhbmQgYWJzdHJhY3QgbW9kZWxzIHVzZWQgaW4g dGhlIElFVEYsIA0KSVNPLCBKVEMxLCBPQVNJUywgYW5kIHRoZSBPR0M/PC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjwvZm9udD4mbmJzcDs8 L2Rpdj4NCjxkaXY+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5DaGVlcnM8 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PC9mb250PiZuYnNwOzwvZGl2Pg0KPGRpdj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPkNhcmw8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PC9mb250PiZuYnNwOzwvZGl2Pg0KPGRpdj48Zm9udCBzaXplPSIzIiBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjwvZm9udD4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkJBQ0tH Uk9VTkQ6ICNmNWY1ZjUiPg0KPGRpdiBzdHlsZT0iZm9udC1jb2xvcjogYmxhY2siPjxiPkZyb206 PC9iPiA8YSB0aXRsZT0ibWF0dGhldy5sdXR6ZUBnbWFpbC5jb20iIGhyZWY9Im1haWx0bzptYXR0 aGV3Lmx1dHplQGdtYWlsLmNvbSI+TWF0dCBMdXR6ZTwvYT4gPC9kaXY+DQo8ZGl2PjxiPlNlbnQ6 PC9iPiBNb25kYXksIE5vdmVtYmVyIDEyLCAyMDEyIDEwOjMyIEFNPC9kaXY+DQo8ZGl2PjxiPlRv OjwvYj4gPGEgdGl0bGU9Imdlb3ByaXZAaWV0Zi5vcmciIGhyZWY9Im1haWx0bzpnZW9wcml2QGll dGYub3JnIj5nZW9wcml2QGlldGYub3JnPC9hPiA8L2Rpdj4NCjxkaXY+PGI+U3ViamVjdDo8L2I+ IFJlOiBbR2VvcHJpdl0gR2VvcHJpdiBEaWdlc3QsIFZvbCAxMDIsIElzc3VlIDgsIG1lc3NhZ2Ug MSANCiZhbXA7IDM8L2Rpdj48L2Rpdj48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJGT05ULVNUWUxFOiBub3JtYWw7IERJU1BMQVk6IGlubGluZTsgRk9OVC1GQU1J TFk6ICdDYWxpYnJpJzsgQ09MT1I6ICMwMDAwMDA7IEZPTlQtU0laRTogc21hbGw7IEZPTlQtV0VJ R0hUOiBub3JtYWw7IFRFWFQtREVDT1JBVElPTjogbm9uZSI+DQo8ZGl2Pkdvb2QgZGF5LDwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SSBoYXZlIGEgY29tbWVudCBhbmQgYSBmZXcgb2Jz ZXJ2YXRpb25zLCBpZiBJIG1heSBleHBvc2UgbXkgaWdub3JhbmNlIHRvIA0KYXNrIHRoZW0gKGFu ZCBhcG9sb2dpemUgaWYgdGhlIHRvcGljcyBoYXZlIGFscmVhZHkgYmVlbiBkaXNjdXNzZWQpOjwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Rmlyc3QsIHRoZSBjb21tZW50OjwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgPGRp dj4NCiAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+SVAgYWRkcmVzc2VzIGlkZW50aWZ5IGEgZGV2 aWNlIGFuZCBpdCdzIGxvY2F0aW9uIG9uIA0KICAgIHRoZSBJbnRlcm5ldCwgbm90IGl0J3MgPGJy PjwvYmxvY2txdW90ZT4NCiAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+Z2VvZ3JhcGhpY2FsIGxv Y2F0aW9uIChhbHRob3VnaCB0aGVyZSBpcyBzb21lIA0KICAgIGNvcnJlbGF0aW9uLCBhc3N1bWlu ZyBubyA8YnI+PC9ibG9ja3F1b3RlPg0KICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj50dW5uZWxz KSwgb3IgdGhlIHBlcnNvbiB3aG8gaXMgdXNpbmcgDQogIGl0Ljxicj48L2Jsb2NrcXVvdGU+PGJy PlNvdW5kcyB2ZXJ5IHJlYXNvbmFibGUgYW5kIEkgdG90YWxseSBhZ3JlZSAuLiBidXQgDQogIGRv bid0IHdlIHVzZSBJUCBhZGRyZXNzIHRvIGRldGVybWluZSBnZW9ncmFwaGljIGxvY2F0aW9ucz8g SXNuJ3QgdGhhdCB3aGF0IA0KICBnb29nbGUsIHlvdXR1YmUgYW5kIG90aGVyIGJpZyBuYW1lcyB1 c2UgdG8gZGV0ZXJtaW5lIGxvY2F0aW9ucz8gDQo8L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5PdXRzaWRlIG9mIGdlbmVyYWxseSBsb29raW5nIGF0IGFu IElQIGFkZHJlc3MgdG8gZ3Vlc3MgYXQgYSBob3N0J3MgcmVnaW9uYWwgDQpsb2NhdGlvbiwgSSB3 b3VsZCBwb3NpdCB0aGF0IHNlcnZpY2VzIHRvZGF5IGRldGVybWluZSBsb2NhdGlvbiBieSBhc2tp bmcgYSANCmRldmljZSB0byBhbGxvdyB0aGUgc2VydmljZSB0byB1c2UgYW4gQXBwbGljYXRpb24g bGF5ZXIgbWV0aG9kIGZvciBsb2NhdGlvbiANCmRldGVjdGlvbuKAlGFjY2Vzc2luZyBhIEdQUyBh bmQvb3IgV2ktRmkgcmFkaW8gb24gdGhlIGRldmljZS4mbmJzcDsgPC9kaXY+DQo8ZGl2PiZuYnNw OzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+QSBmZXcgb2JzZXJ2YXRpb25zOjwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+VGhlIGFyZ3VtZW50cyBmb3IgdGhpcyBleHRlbnNp b24gc2VlbSB0byBnZW5lcmFsbHkgYmUgZm9jdXNlZCBvbiBwcm92aWRpbmcgDQpzZXJ2aWNlcyB0 aGF0IG1heSByZXF1aXJlIG9yIGJlIHByZWZlcnJlZCB0byBoYXZlIGRpZmZlcmVudCBwb2xpY2ll cyBhbmQgDQppbXBsZW1lbnRhdGlvbnMgZm9yIHRoZSB2YXJpb3VzIGhpZ2hlciBsZXZlbCBzZXJ2 aWNlcyB0aGF0IGFjdHVhbGx5IG5lZWQgdGhlbS4gDQpBbm90aGVyIHdheSwgaXQgd291bGQgc2Vl bSB0byBtZSB0aGF0IGEgcm91dGVyIHVzaW5nIEdQUyB0byBpbmRpY2F0ZSBpdHMgDQpwaHlzaWNh bCBsb2NhdGlvbiB3aWxsIHVzZSB0aGF0IGRpZmZlcmVudGx5IHRoYW4gYSBtb2JpbGUgZGV2aWNl IHJlcGx5aW5nIHdpdGggDQppdHMgbG9jYXRpb24gdG8gYSB3ZWIgYXBwbGljYXRpb24uIDwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+UGFydGljdWxhcmx5LCBpbXBsZW1lbnRpbmcgR1BT IGFzIGFuIGV4dGVuc2lvbiBvZiBJUCBtZWFucyB0aGF0IHNwZWNpYWwgDQpjb25zaWRlcmF0aW9u cyBuZWVkZWQgYnkgYW4gdXBwZXIgbGV2ZWwgcHJvdG9jb2zigJRwZXJoYXBzIHNldHRpbmcgYSBU VEwgZm9yIHRoZSANCmxvY2F0aW9uLCBvciBzcGVjaWZ5aW5nIGEgcXVhbGl0eSBvciByZXNvbHV0 aW9u4oCUd291bGQgYWxsIGhhdmUgdG8gYmUgc3VwcG9ydGVkIA0KaW4gSVAsIHVubmVjZXNzYXJp bHkgaW5jcmVhc2luZyB0aGUgY29tcGxleGl0eSBvZiB0aGUgZXh0ZW5zaW9uIGluIGEgcHJvdG9j b2wgDQp3aG9zZSBwYXJhbW91bnQgc3RyZW5ndGggaXMgaXRzIHNpbXBsaWNpdHkuIEFtbWFyLCBp cyBpbGx1c3RyYXRlZCBieSB0aGUgDQphcmd1bWVudHMgeW91IG1ha2UgaW4gbWVzc2FnZSAzIGJl bG934oCUcGVyaW9kaWNpdHkgb2YgdXBkYXRlcyBzaG91bGQgYmUgYSANCmZ1bmN0aW9uIG9mIHRo ZSBhcHBsaWNhdGlvbiBsYXllciBwcm90b2NvbCwgbm90IElQLiA8L2Rpdj4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8ZGl2PkZ1cnRoZXIsIGdpdmVuIHRoZSBub3Rpb24gdGhhdCB0aGUgSVAgaGVhZGVy ICJzaG91bGQiIGJlIHN0cmlwcGVkIGZyb20gYSANCmRhdGFncmFtIGJlZm9yZSB0aGUgcGF5bG9h ZCBpcyBwYXNzZWQgdXAgdG8gaGlnaGVyIGxldmVsIHByb3RvY29scywgSSB3b3VsZCBmaW5kIA0K aXQgbW9yZSBsb2dpY2FsIHRoYXQgdGhlIEdQUyBsb2NhdGlvbiBiZSBpbXBsZW1lbnRlZCBpbiB0 aGUgZmluYWwgcHJvdG9jb2wgYW5kIA0Kbm90IHJlcXVpcmUgdGhlIGZ1enp5IGxheWVyIGJvdW5k YXJ5IHZpb2xhdGlvbnMgdGhpcyB3b3VsZCBpbXBseS4gPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkdlbmVyYWxseSwg SSB0aGluayBteSByZXNpc3RhbmNlIGlzIHRoYXQgSVAgaXMgc3VwcG9zZWQgdG8gaGFuZGxlIA0K aW50ZXJuZXR3b3JrIGFkZHJlc3NpbmcuIFJlbGF5aW5nIGEgR1BTIGxvY2F0aW9uIGRvZXNuJ3Qg aW1tZWRpYXRlbHkgY29ycmVsYXRlIA0Kd2l0aCB0aGUgcHVycG9zZSBvZiBwcm92aWRpbmcgYSBk ZXZpY2Ugd2l0aCBhbiBhZGRyZXNzLCBvciBzZXJ2aWNpbmcgdGhhdCANCmFkZHJlc3MsIGFuZCBz byBpdCBzZWVtcyB0byBtZSB0aGF0IEdQUyBsb2NhdGlvbiBkb2Vzbid0IGJlbG9uZy4gPC9kaXY+ DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5BbiBIVFRQLUdQUywgSUNNUC1HUFMsIGV0Yy4sIGV4 dGVuc2lvbiB3b3VsZCBzZWVtIHRoZSBhcHByb3ByaWF0ZSANCmltcGxlbWVudGF0aW9uLiA8L2Rp dj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5SZXNwZWN0ZnVs bHksPC9kaXY+DQo8ZGl2Pk1hdHQgTHV0emU8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGRpdj4NCjxkaXY+T24gTm92IDEyLCAyMDEyLCBhdCA2OjE3IEFNLCA8 YSBocmVmPSJtYWlsdG86Z2VvcHJpdi1yZXF1ZXN0QGlldGYub3JnIj5nZW9wcml2LXJlcXVlc3RA aWV0Zi5vcmc8L2E+IHdyb3RlOjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogIDxk aXY+PGZvbnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGNvbG9yPSIjMDAwMDAwIj48YnI+PC9m b250Pjxicj5NZXNzYWdlOiANCiAgMTxicj5EYXRlOiBNb24sIDEyIE5vdiAyMDEyIDExOjQyOjI3 ICswMzAwPGJyPkZyb206ICJBbW1hciBTYWxpaCIgJmx0OzxhIGhyZWY9Im1haWx0bzphbW1hci5z YWxpaEBhdWlzLmVkdS5pcSI+YW1tYXIuc2FsaWhAYXVpcy5lZHUuaXE8L2E+Jmd0Ozxicj5Ubzog DQogICInTWFyayBTbWl0aCciICZsdDs8YSBocmVmPSJtYWlsdG86bWFya3p6enNtaXRoQHlhaG9v LmNvbS5hdSI+bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdTwvYT4mZ3Q7PGJyPkNjOiANCiAgPGEg aHJlZj0ibWFpbHRvOmdlb3ByaXZAaWV0Zi5vcmciPmdlb3ByaXZAaWV0Zi5vcmc8L2E+LCAnRWl0 YW4gQWRsZXInICZsdDs8YSBocmVmPSJtYWlsdG86bGlzdHNAZWl0YW5hZGxlci5jb20iPmxpc3Rz QGVpdGFuYWRsZXIuY29tPC9hPiZndDssPGJyPjxzcGFuIHN0eWxlPSJXSElURS1TUEFDRTogcHJl IiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86aXB2NkBpZXRm Lm9yZyI+aXB2NkBpZXRmLm9yZzwvYT48YnI+U3ViamVjdDogUmU6IFtHZW9wcml2XSBBZGRpbmcg DQogIEdQUyBsb2NhdGlvbiB0byBJUHY2IGhlYWRlcjxicj5NZXNzYWdlLUlEOiANCiAgJmx0Ozxh IGhyZWY9Im1haWx0bzo1MGEwYjY3OS44MmRhMGUwYS41NTc3LjY0YjlAbXguZ29vZ2xlLmNvbSI+ NTBhMGI2NzkuODJkYTBlMGEuNTU3Ny42NGI5QG14Lmdvb2dsZS5jb208L2E+Jmd0Ozxicj5Db250 ZW50LVR5cGU6IA0KICB0ZXh0L3BsYWluOzxzcGFuIHN0eWxlPSJXSElURS1TUEFDRTogcHJlIiBj bGFzcz0iQXBwbGUtdGFiLXNwYW4iPiANCiAgPC9zcGFuPmNoYXJzZXQ9IlVURi04Ijxicj48YnI+ DQogIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPklQIGFkZHJlc3NlcyBpZGVudGlmeSBhIGRldmlj ZSBhbmQgaXQncyBsb2NhdGlvbiBvbiANCiAgICB0aGUgSW50ZXJuZXQsIG5vdCBpdCdzIDxicj48 L2Jsb2NrcXVvdGU+DQogIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPmdlb2dyYXBoaWNhbCBsb2Nh dGlvbiAoYWx0aG91Z2ggdGhlcmUgaXMgc29tZSANCiAgICBjb3JyZWxhdGlvbiwgYXNzdW1pbmcg bm8gPGJyPjwvYmxvY2txdW90ZT4NCiAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+dHVubmVscyks IG9yIHRoZSBwZXJzb24gd2hvIGlzIHVzaW5nIA0KICBpdC48YnI+PC9ibG9ja3F1b3RlPjxicj5T b3VuZHMgdmVyeSByZWFzb25hYmxlIGFuZCBJIHRvdGFsbHkgYWdyZWUgLi4gYnV0IA0KICBkb24n dCB3ZSB1c2UgSVAgYWRkcmVzcyB0byBkZXRlcm1pbmUgZ2VvZ3JhcGhpYyBsb2NhdGlvbnM/IElz bid0IHRoYXQgd2hhdCANCiAgZ29vZ2xlLCB5b3V0dWJlIGFuZCBvdGhlciBiaWcgbmFtZXMgdXNl IHRvIGRldGVybWluZSBsb2NhdGlvbnM/IDxicj48YnI+PGJyPg0KICA8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj5UaGVyZSBpcyBhIEdlb2xvY2F0aW9uIEFQSSBmb3Igd2ViIGJyb3dzZXJzLCBwZXJo YXBzIA0KICAgIGl0IGNvdWxkIGJlIDxicj48L2Jsb2NrcXVvdGU+DQogIDxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPmdlbmVyYWxpc2VkIHRvIHN1aXQgb3RoZXIgDQogIGFwcGxpY2F0aW9ucy48YnI+ PC9ibG9ja3F1b3RlPjxicj4NCiAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGEgaHJlZj0iaHR0 cDovL2Rldi53My5vcmcvZ2VvL2FwaS9zcGVjLXNvdXJjZS5odG1sIj5odHRwOi8vZGV2LnczLm9y Zy9nZW8vYXBpL3NwZWMtc291cmNlLmh0bWw8L2E+PGJyPjwvYmxvY2txdW90ZT48YnI+VGhpcyAN CiAgaXMgZXhhY3RseSB3aGF0IEkgYW0gdGFsa2luZyBhYm91dCwgdG9vIG1hbnkgYXBwbGljYXRp b25zIGZvciB0aGUgc2FtZSANCiAgcHVycG9zZSwgd2UgbmVlZCBvbmUgbG93ZXIgbGF5ZXIgbWVj aGFuaXNtIHRvIHVuaWZ5IGFsbCBvZiB0aGVtIGFuZCBtYWtlIA0KICBpbnRlZ3JhdGlvbiBtb3Jl IGZsZXhpYmxlIGFuZCBjb21wYXRpYmxlLjxicj48YnI+PGJyPg0KICA8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj5UbyBpZGVudGlmeSBwZW9wbGUsIHRvIHRoZW4gZGV0ZXJtaW5lIHRoZWlyIA0KICAg IGF0dHJpYnV0ZXMgKGUuZy4gdGhlaXIgPGJyPjwvYmxvY2txdW90ZT4NCiAgPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+cHJlZmVycmVkIGxhbmd1YWdlKSwgeW91IGhhdmUgdG8gdXNlICJhdHRyaWJ1 dGVzIiBvZiANCiAgICB0aGVtLCBub3QgdGhlIG1hY2hpbmUgPGJyPjwvYmxvY2txdW90ZT4NCiAg PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+dGhleSdyZSBjdXJyZW50bHkgdXNpbmcgb3Igd2hlcmUg aXQgaXMgbG9jYXRlZCBvbiANCiAgICB0aGUgSW50ZXJuZXQgZS5nLiB3aGF0IDxicj48L2Jsb2Nr cXVvdGU+DQogIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPnRoZXkga25vdywgd2hhdCB0aGV5IGFy ZSBvciB3aGF0IHRoZXkgDQogIGhhdmUuPGJyPjwvYmxvY2txdW90ZT48YnI+VGhpcyBpcyBob3cg dGhlIG1ham9yaXR5IG9mIEludGVybmV0IHdvcmsgdG9kYXksIA0KICBiYXNlZCBvbiBJUCBhZGRy ZXNzLCBJIGdhdmUgZ29vZ2xlIGFzIGFuIGV4YW1wbGUsIHBsdXMgbGFuZ3VhZ2UgaXMgbm90IHRo ZSANCiAgb25seSBiZW5lZml0LCBob3cgYWJvdXQgb3RoZXIgYmVuZWZpdHMsIGxpa2UgQWRzIGFu ZCBjb21tZXJjaWFscywgSSBtZW50aW9uZWQgDQogIGFuIGV4YW1wbGUgb2YgZ2V0dGluZyBBZHMg b2YgcmVzdGF1cmFudHMgaW4gbXkgY2l0eSBpbnN0ZWFkIG9mIGdldHRpbmcgQWRzIA0KICBhYm91 dCBhbGwgcmVzdGF1cmFudHMgaW4gY291bnRyeS4gDQo8YnI+PGJyPjxicj5BbW1hcjxicj48YnI+ W+KApl08YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi Pg0KICA8ZGl2Pi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08YnI+PGZvbnQgY2xhc3M9IkFw cGxlLXN0eWxlLXNwYW4iIGNvbG9yPSIjMDA3YjAzIj48YnI+PC9mb250Pk1lc3NhZ2U6IDI8YnI+ RGF0ZTogTW9uLCAxMiBOb3YgMjAxMiAxMDoxMToyMSANCiAgKzAwMDA8YnI+RnJvbTogUm9iaW4g V2lsdG9uICZsdDs8YSBocmVmPSJtYWlsdG86d2lsdG9uQGlzb2Mub3JnIj53aWx0b25AaXNvYy5v cmc8L2E+Jmd0Ozxicj5UbzogQW1tYXIgU2FsaWggDQogICZsdDs8YSBocmVmPSJtYWlsdG86YW1t YXIuc2FsaWhAYXVpcy5lZHUuaXEiPmFtbWFyLnNhbGloQGF1aXMuZWR1LmlxPC9hPiZndDs8YnI+ Q2M6IA0KICAiPGEgaHJlZj0ibWFpbHRvOmdlb3ByaXZAaWV0Zi5vcmciPmdlb3ByaXZAaWV0Zi5v cmc8L2E+IiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdlb3ByaXZAaWV0Zi5vcmciPmdlb3ByaXZAaWV0 Zi5vcmc8L2E+Jmd0OywgRWl0YW4gQWRsZXI8YnI+PHNwYW4gc3R5bGU9IldISVRFLVNQQUNFOiBw cmUiIGNsYXNzPSJBcHBsZS10YWItc3BhbiI+PC9zcGFuPiZsdDs8YSBocmVmPSJtYWlsdG86bGlz dHNAZWl0YW5hZGxlci5jb20iPmxpc3RzQGVpdGFuYWRsZXIuY29tPC9hPiZndDssPHNwYW4gc3R5 bGU9IldISVRFLVNQQUNFOiBwcmUiIGNsYXNzPSJBcHBsZS10YWItc3BhbiI+IDwvc3Bhbj5NYXJr IFNtaXRoICZsdDs8YSBocmVmPSJtYWlsdG86bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdSI+bWFy a3p6enNtaXRoQHlhaG9vLmNvbS5hdTwvYT4mZ3Q7LDxicj48c3BhbiBzdHlsZT0iV0hJVEUtU1BB Q0U6IHByZSIgY2xhc3M9IkFwcGxlLXRhYi1zcGFuIj48L3NwYW4+IjxhIGhyZWY9Im1haWx0bzpp cHY2QGlldGYub3JnIj5pcHY2QGlldGYub3JnPC9hPiIgJmx0OzxhIGhyZWY9Im1haWx0bzppcHY2 QGlldGYub3JnIj5pcHY2QGlldGYub3JnPC9hPiZndDs8YnI+U3ViamVjdDogUmU6IFtHZW9wcml2 XSANCiAgQWRkaW5nIEdQUyBsb2NhdGlvbiB0byBJUHY2IGhlYWRlcjxicj5NZXNzYWdlLUlEOiAm bHQ7PGEgaHJlZj0ibWFpbHRvOjdEMDk2RTlCLTQ1N0UtNDI0Ny1CMTMxLTlGMTg1MTUyMzEwQkBp c29jLm9yZyI+N0QwOTZFOUItNDU3RS00MjQ3LUIxMzEtOUYxODUxNTIzMTBCQGlzb2Mub3JnPC9h PiZndDs8YnI+Q29udGVudC1UeXBlOiANCiAgdGV4dC9wbGFpbjs8c3BhbiBzdHlsZT0iV0hJVEUt U1BBQ0U6IHByZSIgY2xhc3M9IkFwcGxlLXRhYi1zcGFuIj4gDQogIDwvc3Bhbj5jaGFyc2V0PXV0 Zi04PGJyPjxicj5Db21pbmcgdG8gdGhpcyBxdWl0ZSBsYXRlIGluIHRoZSBkaXNjdXNzaW9uLCAN CiAgaGVyZSdzIG15IDI/LCBpbiBjYXNlIGl0IGhlbHBzIHByb3ZpZGUgYSByZWxhdGl2ZWx5IGRp c2ludGVyZXN0ZWQgKGJ1dCBub3QgDQogICp1biotaW50ZXJlc3RlZCkgc3VtbWFyeSBzbyBmYXI6 PGJyPjxicj4tIFRoZSBiZW5lZml0cyBleHBlY3RlZCBmcm9tIHRoZSANCiAgcHJvcG9zZWQgZW5o YW5jZW1lbnQgc2VlbSB2ZXJ5IGhhcmQgZm9yIHRoZSBtYWlsaW5nIGxpc3QgdG8gcGluIGRvd24g YW5kIA0KICBleHByZXNzIChzb21lIGFyZSBkaXNwdXRlZCBhcyBiZW5lZml0cywgd2hpbGUgb3Ro ZXJzIGFyZSBhY2tub3dsZWRnZWQsIGJ1dCANCiAgbWlub3IuLi4pLjxicj48YnI+LSBTb21lIHVz ZS1jYXNlcyBoYXZlIGJlZW4gZGVzY3JpYmVkLCBidXQgSSB0aGluayBpdCB3b3VsZCANCiAgYmUg ZmFpciB0byBzYXkgdGhhdCBub25lIG9mIHRoZW0gZGVzY3JpYmVzIGFuIGFic29sdXRlICJjYW4n dCBsaXZlIHdpdGhvdXQgaXQiIA0KICBuZWVkIGZvciB0aGUgZW5oYW5jZW1lbnQuIE1vc3Qgb2Yg dGhlIGNsYWltZWQgYmVuZWZpdHMgc2VlbSB0byBiZSByZWFsaXNhYmxlIA0KICBieSBvdGhlciBt ZWFucywgcG90ZW50aWFsbHkgZm9yIGxlc3MgZWZmb3J0Ljxicj48YnI+LSBUaGUgcGVvcGxlIHdo byB3b3VsZCANCiAgaGF2ZSB0byBkbyB0aGUgd29yayB0byBpbXBsZW1lbnQgYW5kIGRlcGxveSB0 aGUgZW5oYW5jZW1lbnQgYXJlIG5vdCB0aGUgb25lcyANCiAgd2hvIHdvdWxkIGdldCB0aGUgZGly ZWN0IGJlbmVmaXQgLSB3aGljaCBtYWtlcyBpdCBoYXJkIHRvIGJ1aWxkIGEgcmF0aW9uYWxlIA0K ICBmb3IgZG9pbmcgaXQuPGJyPjxicj5Gcm9tIGFuIGlkZW50aXR5LCBwcml2YWN5IGFuIHBvbGlj eSBwZXJzcGVjdGl2ZSwgdGhlcmUncyANCiAgYWxzbyB0aGlzOiBhbnkgdGltZSB5b3UgaGF2ZSBz b21ldGhpbmcgd2hpY2ggYnVpbGRzIGlkZW50aXR5IChhbmQgZm9yIHRoZSBzYWtlIA0KICBvZiB0 aGlzIGRpc2N1c3Npb24gSSdtIGdvaW5nIHRvIHRyZWF0ICdsb25nLXRlcm0gYW5kIHJlbGF0aXZl bHkgYWNjdXJhdGUgZGF0YSANCiAgYWJvdXQgbG9jYXRpb24nIGFzIGEgZm9ybSBvZiBpZGVudGl0 eSkgaW50byB0aGUgb25saW5lIGluZnJhc3RydWN0dXJlLCB0aGVyZSANCiAgaXMgb2Z0ZW4gc29t ZSBjbGFpbWVkIGJlbmVmaXQgZnJvbSBpdCwgYnV0IHRoZXJlIGlzIGFsc28gYSBjb3JyZXNwb25k aW5nIA0KICBkcmF3YmFjayBpbiB0ZXJtcyBvZiBwcml2YWN5IGFuZCBzZWN1cml0eS4gPGJyPjxi cj5Gb3IgaW5zdGFuY2UsIGNvcHlyaWdodCBsYXcgDQogIGVuZm9yY2VtZW50IGhhcyBiZWVuIGNp dGVkIGFzIG9uZSBwb3NzaWJsZSB1c2Ugb2YgdGhlIGxvY2F0aW9uIGRhdGEgLSBidXQgDQogIGFj dHVhbGx5LCBHUFMgcHJlY2lzaW9uIGlzIGFsbW9zdCBjZXJ0YWlubHkgZXhjZXNzaXZlIGZvciB0 aGlzIHB1cnBvc2UsIGdpdmVuIA0KICB0aGF0IGNvcHlyaWdodCByZWdpbWVzIGFwcGx5IGF0IHRo ZSBsZXZlbCBvZiB0aGUgbmF0aW9uIHN0YXRlLCBub3QgdGhlIEdQUyANCiAgY28tb3JkaW5hdGUu Li4gQW5kIG9uY2UgdGhlIGRhdGEgaXMgaW4gdGhlIGhlYWRlciwgaXQgd2lsbCBnZXQgdXNlZCBm b3IgDQogIHdoYXRldmVyIHB1cnBvc2UgcGVvcGxlIGNhbiBmaW5kIHRvIGV4cGxvaXQgb3IgbW9u ZXRpemUgaXQuIEl0IGlzIGJ5IG5vIG1lYW5zIA0KICBjZXJ0YWluIHRoYXQgYWxsIHRob3NlIHB1 cnBvc2VzIHdpbGwgYmUgaW4gdGhlIGludGVyZXN0cyBvZiB0aGUgZW5kIA0KICB1c2VyLDxicj48 YnI+Rm9yIGV4YW1wbGUsICdsYW5ndWFnZSBwcmVmZXJlbmNlIGV4cHJlc3Npb24nIG1heSBzZWVt IGxpa2UgYSANCiAgbmV1dHJhbCBlbm91Z2ggZ29hbCwgYnV0IHRoZW4gd2Ugc2hvdWxkIGFsc28g Y29uc2lkZXIgLSB3aGF0IGhhcHBlbnMgaWYgdGhlIA0KICB0ZWNobmljYWwgaW5mcmFzdHJ1Y3R1 cmUgc3RhcnRzIHRvIGlkZW50aWZ5IHlvdSBzcGVjaWZpY2FsbHkgYXMgYSBCb3NuaWFuIA0KICBN dXNsaW0sIG9yIGFzIGFuIEFyYWIgSXNyYWVsaSwgb3IgYXMgYSBLdXJkIGxpdmluZyBpbiBUdXJr ZXkuLi4gPGJyPjxicj5BcyBJIA0KICBzYXksIHRoZXNlIGFyZSBqdXN0IG15IHRob3VnaHRzIGFz IHNvbWVvbmUgY29taW5nIGxhdGUgdG8gdGhlIGRpc2N1c3Npb24gYW5kIA0KICB3aXRoIG5vIHBh cnRpY3VsYXIgJ2ludmVzdG1lbnQnIGluIGl0IHRvIHB1cnN1ZS4uLiBob3BlIHRoaXMgaXMgdXNl ZnVsLCANCiAgdGhvdWdoLjxicj48YnI+WXJzLiw8YnI+PGJyPlJvYmluPGJyPjxicj48YnI+PGJy Pjxicj5Sb2JpbiANCiAgV2lsdG9uPGJyPjxicj5UZWNobmljYWwgT3V0cmVhY2ggRGlyZWN0b3Ig LSBJZGVudGl0eSBhbmQgUHJpdmFjeTxicj4NCiAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQog ICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGZvbnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4i IGNvbG9yPSIjMDA1N2NlIj48YnI+PC9mb250PjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+DQog IDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPi0t PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48L2Rpdj48L2Jsb2NrcXVvdGU+DQo8ZGl2PiZuYnNw OzwvZGl2Pg0KPGRpdj5b4oCmXTwvZGl2Pjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K ICA8ZGl2Pk1lc3NhZ2U6IDM8YnI+RGF0ZTogTW9uLCAxMiBOb3YgMjAxMiAxNDoxNzozNiArMDMw MDxicj5Gcm9tOiAiQW1tYXIgDQogIFNhbGloIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFtbWFyLnNh bGloQGF1aXMuZWR1LmlxIj5hbW1hci5zYWxpaEBhdWlzLmVkdS5pcTwvYT4mZ3Q7PGJyPlRvOiAN CiAgIidSb2JpbiBXaWx0b24nIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOndpbHRvbkBpc29jLm9yZyI+ d2lsdG9uQGlzb2Mub3JnPC9hPiZndDs8YnI+Q2M6IDxhIGhyZWY9Im1haWx0bzpnZW9wcml2QGll dGYub3JnIj5nZW9wcml2QGlldGYub3JnPC9hPiwgJ0VpdGFuIEFkbGVyJyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmxpc3RzQGVpdGFuYWRsZXIuY29tIj5saXN0c0BlaXRhbmFkbGVyLmNvbTwvYT4mZ3Q7 LDxzcGFuIHN0eWxlPSJXSElURS1TUEFDRTogcHJlIiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iPiA8 L3NwYW4+J01hcms8YnI+PHNwYW4gc3R5bGU9IldISVRFLVNQQUNFOiBwcmUiIGNsYXNzPSJBcHBs ZS10YWItc3BhbiI+PC9zcGFuPlNtaXRoJyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcmt6enpzbWl0 aEB5YWhvby5jb20uYXUiPm1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU8L2E+Jmd0OywgPGEgaHJl Zj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmciPmlwdjZAaWV0Zi5vcmc8L2E+PGJyPlN1YmplY3Q6IFJl OiBbR2VvcHJpdl0gQWRkaW5nIA0KICBHUFMgbG9jYXRpb24gdG8gSVB2NiBoZWFkZXI8YnI+TWVz c2FnZS1JRDogJmx0OzxhIGhyZWY9Im1haWx0bzo1MGEwZGFkNi40NDkzOTgwYS42YzI5LjZiMGVA bXguZ29vZ2xlLmNvbSI+NTBhMGRhZDYuNDQ5Mzk4MGEuNmMyOS42YjBlQG14Lmdvb2dsZS5jb208 L2E+Jmd0Ozxicj5Db250ZW50LVR5cGU6IA0KICB0ZXh0L3BsYWluOzxzcGFuIHN0eWxlPSJXSElU RS1TUEFDRTogcHJlIiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iPiANCiAgPC9zcGFuPmNoYXJzZXQ9 IlVURi04Ijxicj48YnI+Um9iaW4sPGJyPjxicj4NCiAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ Q29taW5nIHRvIHRoaXMgcXVpdGUgbGF0ZSBpbiB0aGUgZGlzY3Vzc2lvbiwgaGVyZSdzIA0KICAg IG15IDI/LCBpbiBjYXNlIGl0IDxicj48L2Jsb2NrcXVvdGU+DQogIDxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPmhlbHBzIHByb3ZpZGUgYSByZWxhdGl2ZWx5IGRpc2ludGVyZXN0ZWQgKGJ1dCBub3Qg DQogICAgKnVuKi1pbnRlcmVzdGVkKSBzdW1tYXJ5IDxicj48L2Jsb2NrcXVvdGU+DQogIDxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPnNvIGZhcjo8YnI+PC9ibG9ja3F1b3RlPjxicj5JIGFtIGhhcHB5 IHRvIGhlYXIgZnJvbSANCiAgYWxsIG9mIHlvdSBndXlzLCB5b3VyIG5vdGVzIGFyZSBoaWdobHkg YXBwcmVjaWF0ZWQhIDxicj48YnI+DQogIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPkZyb20gYW4g aWRlbnRpdHksIHByaXZhY3kgYW4gcG9saWN5IHBlcnNwZWN0aXZlLCANCiAgICB0aGVyZSdzIGFs c28gdGhpczogYW55IDxicj48L2Jsb2NrcXVvdGU+DQogIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PnRpbWUgeW91IGhhdmUgc29tZXRoaW5nIHdoaWNoIGJ1aWxkcyBpZGVudGl0eSAoYW5kIA0KICAg IGZvciB0aGUgc2FrZSBvZiB0aGlzIDxicj48L2Jsb2NrcXVvdGU+DQogIDxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPmRpc2N1c3Npb24gSSdtIGdvaW5nIHRvIHRyZWF0ICdsb25nLXRlcm0gYW5kIA0K ICAgIHJlbGF0aXZlbHkgYWNjdXJhdGUgZGF0YSA8YnI+PC9ibG9ja3F1b3RlPg0KICA8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj5hYm91dCBsb2NhdGlvbicgYXMgYSBmb3JtIG9mIGlkZW50aXR5KSBp bnRvIHRoZSANCiAgICBvbmxpbmUgaW5mcmFzdHJ1Y3R1cmUsIDxicj48L2Jsb2NrcXVvdGU+DQog IDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPnRoZXJlIGlzIG9mdGVuIHNvbWUgY2xhaW1lZCBiZW5l Zml0IGZyb20gaXQsIGJ1dCANCiAgICB0aGVyZSBpcyBhbHNvIGEgPGJyPjwvYmxvY2txdW90ZT4N CiAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+Y29ycmVzcG9uZGluZyBkcmF3YmFjayBpbiB0ZXJt cyBvZiBwcml2YWN5IGFuZCANCiAgICBzZWN1cml0eS4gPGJyPjwvYmxvY2txdW90ZT48YnI+DQog IDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPkZvciBpbnN0YW5jZSwgY29weXJpZ2h0IGxhdyBlbmZv cmNlbWVudCBoYXMgYmVlbiANCiAgICBjaXRlZCBhcyBvbmUgcG9zc2libGUgdXNlIDxicj48L2Js b2NrcXVvdGU+DQogIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPm9mIHRoZSBsb2NhdGlvbiBkYXRh IC0gYnV0IGFjdHVhbGx5LCBHUFMgcHJlY2lzaW9uIA0KICAgIGlzIGFsbW9zdCBjZXJ0YWlubHkg PGJyPjwvYmxvY2txdW90ZT4NCiAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ZXhjZXNzaXZlIGZv ciB0aGlzIHB1cnBvc2UsIGdpdmVuIHRoYXQgY29weXJpZ2h0IA0KICAgIHJlZ2ltZXMgYXBwbHkg YXQgdGhlIDxicj48L2Jsb2NrcXVvdGU+DQogIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPmxldmVs IG9mIHRoZSBuYXRpb24gc3RhdGUsIG5vdCB0aGUgR1BTIA0KICAgIGNvLW9yZGluYXRlLi4uIEFu ZCBvbmNlIHRoZSBkYXRhIGlzIDxicj48L2Jsb2NrcXVvdGU+DQogIDxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPmluIHRoZSBoZWFkZXIsIGl0IHdpbGwgZ2V0IHVzZWQgZm9yIHdoYXRldmVyIHB1cnBv c2UgDQogICAgcGVvcGxlIGNhbiBmaW5kIHRvIDxicj48L2Jsb2NrcXVvdGU+DQogIDxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPmV4cGxvaXQgb3IgbW9uZXRpemUgaXQuIEl0IGlzIGJ5IG5vIG1lYW5z IGNlcnRhaW4gDQogICAgdGhhdCBhbGwgdGhvc2UgcHVycG9zZXMgPGJyPjwvYmxvY2txdW90ZT4N CiAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+d2lsbCBiZSBpbiB0aGUgaW50ZXJlc3RzIG9mIHRo ZSBlbmQgDQogIHVzZXIuPGJyPjwvYmxvY2txdW90ZT48YnI+VXNlciBzaG91bGQgaGF2ZSB0aGUg b3B0aW9uIG9mIG5vdCBzZW5kaW5nIGxvY2F0aW9uIA0KICB1cGRhdGUgYnkgc2V0dGluZyBhbGwg emVyb3MgaW4gdGhlIGxvY2F0aW9uIGZpZWxkLCB0ZWxsaW5nIHRoZSBJU1Agcm91dGVycyBub3Qg DQogIHRvIGRvIHNvIGFzIHdlbGwsIGluIHRoYXQgY2FzZSB0aGUgdXNlciBwcm90ZWN0cyBoaXMv aGVyIHByaXZhY3kgYnV0IGxvc2VzIHRoZSANCiAgYmVuZWZpdHMgb2YgbG9jYXRpb24tYmFzZWQg c2VydmljZXMgLi4gYW5kIGlmIHlvdSBjaG9vc2UgdG8gbGV0IHRoZSBJU1AgDQogIHJvdXRlcnMg dG8gdGFnIHlvdXIgcGFja2V0cyB3aXRoIGxvY2F0aW9uIHVwZGF0ZXMgdGhlbiBpdCB3aWxsIG5v dCBiZSB2ZXJ5IA0KICBhY2N1cmF0ZSwgaXQgd2lsbCBiZSBiYXNlZCBvbiB5b3VyIHBoeXNpY2Fs IGNvbm5lY3Rpb24gbGlrZSBtb2JpbGUgdG93ZXIgeW91ciANCiAgY29ubmVjdGVkIHRvLCBvciBl dmVuIGxlc3MgYWNjdXJhdGUgbGlrZSB0aGUgY2l0eSAob3IgZXZlbiBjb3VudHJ5KSB5b3VyIGFy ZSANCiAgY29ubmVjdGluZyBmcm9tLiBJbiBhIHdheSB0aGF0IGFsbG93cyB0aGUgaW1wbGVtZW50 YXRpb24gb2YgY29weXJpZ2h0IGxhdyANCiAgd2l0aG91dCBjb21wcm9taXNpbmcgdGhlIHByaXZh Y3kuPGJyPjxicj48YnI+DQogIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPkZvciBleGFtcGxlLCAn bGFuZ3VhZ2UgcHJlZmVyZW5jZSBleHByZXNzaW9uJyBtYXkgDQogICAgc2VlbSBsaWtlIGEgbmV1 dHJhbCA8YnI+PC9ibG9ja3F1b3RlPg0KICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5lbm91Z2gg Z29hbCwgYnV0IHRoZW4gd2Ugc2hvdWxkIGFsc28gY29uc2lkZXIgLSB3aGF0IA0KICAgIGhhcHBl bnMgaWYgdGhlIDxicj48L2Jsb2NrcXVvdGU+DQogIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPnRl Y2huaWNhbCBpbmZyYXN0cnVjdHVyZSBzdGFydHMgdG8gaWRlbnRpZnkgeW91IA0KICAgIHNwZWNp ZmljYWxseSBhcyBhIEJvc25pYW4gPGJyPjwvYmxvY2txdW90ZT4NCiAgPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+TXVzbGltLCBvciBhcyBhbiBBcmFiIElzcmFlbGksIG9yIGFzIGEgS3VyZCBsaXZp bmcgDQogICAgaW4gVHVya2V5Li4uIDxicj48L2Jsb2NrcXVvdGU+PGJyPnRlY2huaWNhbCBpbmZy YXN0cnVjdHVyZSBjYW4gZG8gbXVjaCBtb3JlIGlmIA0KICB0aGV5IGhhdmUgYmFkIGludGVudHMs IHRoZXkgY2FuIHNpbXBseSBpZGVudGlmeSBNdXNsaW1zLCBBcmFicywgS3VyZHMgYmFzZWQgb24g DQogIGRlc3RpbmF0aW9ucyAobGlrZSBJc2xhbWljIHdlYnNpdGVzIG9yIFZvSVAgY2FsbHMgd2l0 aCBhcmVhIGNvZGUpIHNvIGl0J3Mgbm90IA0KICBvbmx5IHNvdXJjZSwgaW4gZmFjdCB0aGV5IGNh biBkbyBsYXllci03IGNsYXNzaWZpY2F0aW9uIGFuZCBtYXJraW5nIGJhc2VkIG9uIA0KICB0aGUg YWN0dWFsIGNvbnRlbnQgb2YgZWFjaCBwYWNrZXQgLSB1bmxlc3MgeW91ciBkYXRhIGFyZSBlbmNy eXB0ZWQsIGFuZCBnZXQgDQogIG11Y2ggbW9yZSBpbmZvcm1hdGlvbiB0aGFuIHlvdXIgcGh5c2lj YWwgbG9jYXRpb24uLi4gYWdhaW4gaXQncyB1c2VycyBvcHRpb24gDQogIHRvIHNldCB0aGUgbG9j YXRpb24gdG8gYWxsIHplcm9zLjxicj48YnI+DQogIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPkFz IEkgc2F5LCB0aGVzZSBhcmUganVzdCBteSB0aG91Z2h0cyBhcyBzb21lb25lIA0KICAgIGNvbWlu ZyBsYXRlIHRvIHRoZSA8YnI+PC9ibG9ja3F1b3RlPg0KICA8YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij5kaXNjdXNzaW9uIGFuZCB3aXRoIG5vIHBhcnRpY3VsYXIgJ2ludmVzdG1lbnQnIGluIGl0IA0K ICAgIHRvIHB1cnN1ZS4uLiBob3BlIDxicj48L2Jsb2NrcXVvdGU+DQogIDxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPnRoaXMgaXMgdXNlZnVsLCB0aG91Z2guPGJyPjwvYmxvY2txdW90ZT48YnI+SSB3 b3VsZCANCiAgbGlrZSB0byB0aGFuayB5b3UgdmVyeSBtdWNoLCB5b3VyIHByb2Zlc3Npb25hbCBw b2ludHMgd2lsbCBkZWZpYW50bHkgYWRkIG1vcmUgDQogIHZhbHVlIHRvIHRoZSBkcmFmdC48YnI+ PGJyPjxicj5b4oCmXTxicj48YnI+RW5kIG9mIEdlb3ByaXYgRGlnZXN0LCBWb2wgMTAyLCANCiAg SXNzdWUgDQo4PGJyPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj48 L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPg0KPHA+DQo8L3A+PGhyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+R2VvcHJpdiBtYWlsaW5nIA0K bGlzdDxicj48YSBocmVmPSJtYWlsdG86R2VvcHJpdkBpZXRmLm9yZyI+R2VvcHJpdkBpZXRmLm9y ZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9n ZW9wcml2Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dlb3ByaXY8L2E+ PGJyPjwvZGl2PjwvZGl2PjwvZGl2Pg0KPC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxkaXY+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188L3NwYW4+PGJyPjxzcGFuPkdlb3ByaXYgbWFpbGluZyBsaXN0PC9zcGFuPjxi cj48c3Bhbj48YSBocmVmPSJtYWlsdG86R2VvcHJpdkBpZXRmLm9yZyI+R2VvcHJpdkBpZXRmLm9y ZzwvYT48L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZ2VvcHJpdiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9nZW9wcml2PC9hPjwvc3Bhbj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+ --_000_4FAEF0E6795E4345851C6E6BC4C682DBskyhookwirelesscom_-- From acooper@cdt.org Tue Nov 13 04:40:23 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A1F21F8450 for ; Tue, 13 Nov 2012 04:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3frbSm-6BUr for ; Tue, 13 Nov 2012 04:40:18 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 2528521F844D for ; Tue, 13 Nov 2012 04:40:17 -0800 (PST) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for geopriv@ietf.org; Tue, 13 Nov 2012 07:40:14 -0500 From: Alissa Cooper Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Nov 2012 07:40:13 -0500 Message-Id: <251A78F7-B864-4855-A310-513E6630E224@cdt.org> To: GEOPRIV WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Geopriv] IETF 85 Minutes X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 12:40:23 -0000 Minutes - GEOPRIV - IETF 85 Summary 1. WGLC for draft-geopriv-flow-identity WGLC completed with several expressions of support from the room. =20 2. draft-jones-geopriv-sigpos-survey Continued interest in this draft from the room. Kipp will rev before we = issue call for adoption. 3. self-published-geo Development of yet-to-be-published draft = = will continue, alignment with geopriv formats possible.=20 Raw Notes from Roger Marshall ----------------------------- Geopriv Notes Chairs: Alissa Cooper, Richard Barnes Wed, 14:40-15:40 Notewell Covered Agenda Bashed Document Status (Alissa) geopriv-flow-identity =96 need at least one more person to say = that it should go to WGLC Kip Jones: concur that it is ready to go Brian Rosen: also have read, concur it=92s ready for WGLC Alissa: Ok, thanks. =20 --Presentations: -- draft-jones-geopriv-sigpos-survey Kip Jones presented Henning Schulzrinne: 2 kinds of signal info =96 Access Points & Metrics, = e.g., Android phone measures =96 are you talking about both? Kip: yes, both. More general case is the survey =96 more focused on a = professional survey, not so much for the crowd-sourced model. Henning: One of the big concerns was how do you trace the information = back. Kip: more explanation scenario Henning: Metadata - Want to be sure that data is properly attributed, = also want to know that the data is properly represented, on a known = schedule, update frequency, expiration of the data, notion of trust of = data vs. =93use extreme caution=94. Martin Thomson: question the validity of data =96 =93expiration=94 may = be the thing you don=92t want. Henning: need a way to characterize =96 need to know what =93expiration=94= means. AP may/may not be where it was 3 years ago. Martin: reason why expiration is important to define Bernard Aboba: Rights to the data covered? Martin: Licensing gets interesting, essentially talking about copyright. Kip: Licensing is an important piece, but also a fuzzy area currently. = Metadata is important and will need to be looked at. Kip: Henning: well imagine that Universities may not have objection to = Creative Commons, but want to be attributed. Kip: Looking at Geo DRM =96 pretty heavy right now, may not need to be = as heavy =96 need to look at it. Alissa: Not just licenses, right? Kip: Looks at enforcement =96 not a requirement now, but points to the = ability to do this kind of stuff. Kip: Derivative rights, thoughts about location data being unencumbered. Martin: There is a thought of the location being restricted to rights. = Impacts to the Rulemaker. Kip: Access control part of this =96 idea that the location may be = unencumbered is the user has authorization to get it. Kip: Happy to get comments. Henning: You may want to look at Open Data Commons Attribute licence Kip: Yes, did take a look, will need to look at it further. Kip: Went over changes in version -01 Kip: Known Issues (slide) Kip: Additional issues (from Brian Hart), includes: Definition of a LIS still needs some work =93_nomap=94 for AP privacy =96 don=92t know how you would put this into = the document Henning: questions on this Richard: This is something =96 a consideration that would go into the = privacy section. Kip: Also, to Henning=92s point, not sure where the ownership belongs James: Suggest a fairly lean privacy section, and then maybe use a = separate document to go deeper. Richard: I don=92t think we=92re going to list all the privacy laws in = this document. Henning: I see this as more of, =93we are aware that these things = exist=94, etc. do your due diligence. Even in post cleanup =96 if you = knew of it at the time, you shouldn=92t have gathered it, and marking it = isn=92t going to do anything to help. Kip: binary version Brian: Please don=92t do that. Martin: we have this gzip =96 and it produces binary really well. Kip: Okay. Now with Brad engaged, I=92ve got a cohort to work through = these issues. And the licensing issues need worked through. Alissa: Are there other non-IETF folks out there that are willing to = help? Kip: Yeah, I think we can engage more =96 but a chicken and egg thing. Richard: It=92d be good to get some of the companies doing this = surveying Henning: Yeah, Kip=92s company is one of those Henning: It seems at least two options, one: punt, we=92ve got tools = for, go at it =96 you don=92t want to ship data files every night, or = two: publish/subscribe model Kip: How do you propagate this document to all the interested parties. Henning: Seems like a much harder generic problem =96 probably have = business=92 that are data aggregators =96 seems like well beyond the = scope of this=85 Henning: Speaking from Public Safety model, down the road =96 = far-fetched at the moment, the Fire Marshal, next to checking fire = suppression, could be checking floor plan data, etc. =96 like I said, = far-fetched for now. Richard: Seems to be some interest in the room. =20 --next Presentation Self-published-geo Eric Klein presenter (not a regular geopriv follower, usually do IPv6) IP-Geo =96 people have different views, but at Google people get really = pissed if it routes the user incorrectly. Eric: example scenarios given Examples: https://registration.icann.org/geo/goole.csv 199.91.192.0/21,US,US-CA,Los Angeles, 2620:f:8000::/48,US,US-CA,Los Angeles, Martin Thomson: Thank you =96 explains just how _unsuccessful_ this work = group has been! Eric: This is for special use. Martin: When I travel I send a header that specifies EN, English =96 and = get local context based on IP-Geo Eric: May be useful if there are local data constraints Martin: A lot of sites Richard: This is one input, a channel to push published geolocation. In = terms of geopriv context, when compared to geopriv=92s data elements, = aligns quite well. Richard: how do you find the URIs? Eric: 3 of them, Ad-hoc, Various =93$-sign=94 databases (e.g., Whois), = Reverse DNS, etc. Richard: which mechanism is recommended for a user? Eric: Henning: Distributed databases mentioned, privacy mentioned, DSLAM level = information, restricted for Public Safety use only, and we want to = figure out how we provision the data. Also, rights, sources, metadata =96 = across the board issues, also, who wants the data =96 may be good to = bring efforts together, rather than treat as two separate universes. Andrew: Surprisingly good to located =96 at least in the UK example. Eric: Depends on the region Alissa: Thanks for presenting (End of Meeting) 15:40= From sm@resistor.net Thu Nov 15 17:31:10 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8700111E8097; Thu, 15 Nov 2012 17:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx2zORz0NI4P; Thu, 15 Nov 2012 17:31:09 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBAB1F0C44; Thu, 15 Nov 2012 17:31:09 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qAG1UqZO019497; Thu, 15 Nov 2012 17:30:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1353029458; bh=bxVAWHjPB/K8tk38GJ46AOC3Gfw7Q/dvPT+U1MAwGXU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=B7mPqILc9PnnZcWWEPZCest2JYZncY1XF53tg8GZRBFVo0R/E1nxfFH9KgGmCLrXP rF5YA3oaZ9XGcMP/OsPVjZF9+B5VWKaUN2HIzpqebm2vq121gg1ED+MLpyVSrA2c2k AxwqZ1y7c+B/3jyL/ARfRXqXiCxVPUM9DS6X+dio= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1353029458; i=@resistor.net; bh=bxVAWHjPB/K8tk38GJ46AOC3Gfw7Q/dvPT+U1MAwGXU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=m1xZjD+XnZsUaSWa9w5I2BX+Hhz9KWGK8eA/iWF9Lz8IHnlXkypf0crN1sO5DGggC S9TWbF46YPpDj9vrNd84noWELTrR3f/iHU0fajEiRZks1/hyTSkeweulNHIG0Gvn7z xaWlf8sEX6ajEY9vaSNm8+gbj3DyYv7KyNL2vBwg= Message-Id: <6.2.5.6.2.20121115172402.0a97eea0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 15 Nov 2012 17:25:48 -0800 To: Robin Wilton From: SM In-Reply-To: <7D096E9B-457E-4247-B131-9F185152310B@isoc.org> References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <50a02371.86d60e0a.4f2d.02f1@mx.google.com> <1352708088.50386.YahooMailNeo@web32503.mail.mud.yahoo.com> <50a0b679.82da0e0a.5577.64b9@mx.google.com> <7D096E9B-457E-4247-B131-9F185152310B@isoc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Fri, 16 Nov 2012 06:08:09 -0800 Cc: geopriv@ietf.org, Ammar Salih , ipv6@ietf.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 01:31:10 -0000 At 02:11 12-11-2012, Robin Wilton wrote: >- The people who would have to do the work to implement and deploy >the enhancement are not the ones who would get the direct benefit - >which makes it hard to build a rationale for doing it. http://www.cleanitproject.eu/ Regards, -sm From fred@cisco.com Thu Nov 15 19:05:16 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B9621F88E0; Thu, 15 Nov 2012 19:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.51 X-Spam-Level: X-Spam-Status: No, score=-110.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjvv0xY-S+Em; Thu, 15 Nov 2012 19:05:14 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6B13D21F8784; Thu, 15 Nov 2012 19:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44092; q=dns/txt; s=iport; t=1353035113; x=1354244713; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7sWAMhm4+0yQBlgMWyQL5kDqV77NvzN36/tt6ahJlgE=; b=jHMlcKOEHpZBeFJ4bg2A5U/at6OnGP8aBB8rNEc2SyPFNKhzmVStfHWG qcbVKOw2sgwv+V9LFETBnFXu7p1wmCBo/39f1pOxHD5/pxv4UA4fKXpn/ WSmDXRgxF2LXojCM+bYehRnMaGgcGBqtbOB86/rfBB5GYHY5/Tc3ixm3s Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAGAMyspVCtJXG9/2dsb2JhbABBAw6CO614iQUBiQCBCIIXCAEBBAEBAQ8BUwgLDgICAQgiFgEGBxsGBgsUEQEBBA4FCAELDoUnB4IrAw8LnSSPKYZtDYlUBItEaYFhgkthA4pJiV6CcYoWA4MjgWuCMj2BWwcCFx4 X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="143021279" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 16 Nov 2012 03:05:12 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAG35Cwh006518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 16 Nov 2012 03:05:12 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.196]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 21:05:12 -0600 From: "Fred Baker (fred)" To: Ammar Salih Thread-Topic: Adding GPS location to IPv6 header Thread-Index: Ac2/VMZri4Yb+IJ0QpqrzX+gy+wtKAEhLRsA Date: Fri, 16 Nov 2012 03:05:11 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com> References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> In-Reply-To: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.36.192] Content-Type: multipart/alternative; boundary="_000_8C48B86A895913448548E6D15DA7553B1B92F4xmbrcdx09ciscocom_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 16 Nov 2012 06:08:09 -0800 Cc: "" , "" Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 03:05:16 -0000 --_000_8C48B86A895913448548E6D15DA7553B1B92F4xmbrcdx09ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable You may certainly file an internet draft with your ideas. You will want to = read about what an Internet Draft is and how to file one. http://www.ietf.o= rg/id-info/ Filing an Internet Draft does not imply consensus around the specification,= and you will need to build that consensus. You will want to make your case= , and I would suggest starting on the geopriv mailing list, although the ca= se will eventually have to be made to 6man. http://datatracker.ietf.org/wg/= geopriv/charter/. One consideration you should take in view is that the IPv6 header is not en= crypted, so information found in it is globally readable. If there is ever = a case in which your GPS location is needed by the application but may need= to be guarded for privacy reasons, you will want to put it in the applicat= ion layer (above the transport, guarded by IPsec or TLS), not the network l= ayer. In fact, I would expect that 6man might tell you that the IPv6 header= has one primary purpose, which is to conduct a datagram from the sender's = system to the intended receiver's system; if the data doesn't help achieve = that, it's probably in the wrong header. On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: Hello IETF, based on my discussions with both ipv6 and geopriv teams, I=92v= e written the below document to summarize few ideas. Is it possible to publish this on IETF website? even if it will not be impl= emented now, at least for documentation and requesting feedback from the co= mmunity. Many thanks. Ammar Ammar J. Salih Baghdad, Iraq October 30, 2012 Title: IP-LOC Adding GPS location to IPv6 header Abstract: =3D=3D=3D=3D=3D=3D=3D=3D=3D This document describes IP-LOC, an extension to IPv6 header which sugges= ts adding GPS coordinates, as the current method of determining the locatio= n of IP traffic is through IP address registration database, which is not v= ery accurate as it depends on how the ISP registers its IP subnets, that is= normally done in a country/city format. It also assumes that in the future, GPS capability will be added to the rou= ter itself (just like smart phones) and packet marking and classification b= ased on geo-location will be required. QoS, firewall and routing based on geo-location will be highly required whe= n mobile routers move from one geo-location to another which has different = policy. Benefits of adding GPS location to IPv6 header (IP-LOC) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Web Services: getting more accurate locations will enhance many services pr= ovided by the web, like targeted commercials (for example, I can get Ads re= garding restaurants available in my neighborhoods instead of all restaurant= s in the city), another good example would be webpage=92s language, my lang= uage will be detected more accurately based on my area rather than my count= ry, as there are many countries with more than one popular language, not me= ntioning that many ip registrations does not even reflect the traffic origi= nating country. ------------------------------- Information accuracy and control: Nowadays, locations are assigned to IP ad= dresses without user awareness or control, every time a user performs ip-lo= okup query the response would be different based on how the ISP has registe= red this IP subnet, IP-LOC suggests making locations more accurate and cont= rollable through OS and network devices, exactly like IP addresses (user ca= n change his/her IP address, but router can also modify the header informat= ion - in case it's required). ------------------------------- Routing: Policy based routing, based on geo-location, like routing predefin= ed traffic through certain server or path, for different purposes (security= , manageability, serviceability like choosing language, or routing traffic = to specific cashing or proxy server based on country .. etc) ------------------------------- Copyright law: It happens when certain media/web content is not allowed in = certain countries due to copyright law, the current method of determining l= ocations is not accurate at all, on other hand, If layer-7 application to b= e used then the user might be able to manipulate the location field, in thi= s case (if it=92s required in future) the ISP can tag traffic with country/= city more accurately as traffic passes through ISP=92s boarder routers. ------------------------------- Maps, navigation, emergency calls and many other services will be also enha= nced with accurate locations. CURRENT ARGUMENTS AGAINST THIS IDEA: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =93Adding GPS position to every IPv6 header would add a lot of overhead=94 Response: It does not have to be in every IPv6 header, only when there is l= ocation update, also the host should have the option of not to send locatio= n updates. ------------------------------- =93What about privacy?=94 Response: User should have the option of not sending location updates. User= should also have the ability to set location to all zeros, in this case no= router will modify the location field and user loses the location-based se= rvices. If it=92s router-to-router link, then no need to be worried about privacy a= s such information usually configured on a separate network. -------------------------------- =93a good alternative would be to create application layer protocols that c= ould request and send GPS positions=94 Response: the layer-7 location request will not be detected by layer-3 devi= ces (Routers), I am assuming that in the future, GPS capability will be add= ed to the router itself (just like smart phones), features like packet mark= ing and classification based on geo-location will be required to enforce th= e new geo-location policies. -------------------------------- =93For location-based routing protocols: Why would you want this? Geograph= ical location isn't actually that important a metric for routing; what you = care about there is *topological* location, how far I am away from you in t= erms of hops or latency=94 Response: For shortest path maybe yes, hops or latency is important, not fo= r policy-based routing, in our case you might want to do location-based rou= ting, like, routing traffic coming from French speaking users (in multi-lan= guage country like Canada) to google.fr --------------------------------- =93For geolocation-based ACLs: you have the problem that if the geolocation= is attached by the endpoint, then it can't be trusted, since the endpoint = would lie to get past the ACL. If it's attached by a router, the ACL needs= to have proof that the router attached it (and not the endpoint), which me= ans that you would need a signed geolocation header=94 Response: You could have the router modify the location field anyways, just= like L3 QoS fields, if you don't trust the host, so no need for encryption= or security, additionally, ACL is not only for security, it could be used= for routing, QoS ..etc, so the host will not always has the motivation to = manipulate the location field. --------------------------------- =93Why can=92t you simply implement rules related to geo-locations statical= ly on the network device (router, firewall .. etc)?=94 Response: To enforce new geo-location policies automatically, let=92s assum= e that a mobile router (like a mobile BTS in a GSM network) moved from city= -x to city-y, and according to city-x regulations VoIP calls over GSM netwo= rk is allowed, but city-y regulations do not allow that. Now the topology m= ay reflect same network metrics in both cities but there is no rule that tr= iggers configuration change based on geo-location. --------------------------------- What do you think? Author/Contact Information: Ammar J. Salih Baghdad, Iraq Phone: +964 770 533 0306 Email: ammar.alsalih@gmail.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially. - Marshall McLuhan --_000_8C48B86A895913448548E6D15DA7553B1B92F4xmbrcdx09ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2850D3E83C37DE489F9179EEF01CC275@cisco.com> Content-Transfer-Encoding: quoted-printable You may certainly file an internet draft with your ideas. You will want to = read about what an Internet Draft is and how to file one. http://www.ietf.org/id-info/

Filing an Internet Draft does not imply consensus around the specifica= tion, and you will need to build that consensus. You will want to make your= case, and I would suggest starting on the geopriv mailing list, although t= he case will eventually have to be made to 6man. http://datatracker.ietf.org/wg/geopriv/charter/

One consideration you should take in view is that the IPv6 header is n= ot encrypted, so information found in it is globally readable. If ther= e is ever a case in which your GPS location is needed by the application bu= t may need to be guarded for privacy reasons, you will want to put it in the application layer (above the trans= port, guarded by IPsec or TLS), not the network layer. In fact, I would exp= ect that 6man might tell you that the IPv6 header has one primary purpose, = which is to conduct a datagram from the sender's system to the intended receiver's system; if the data doesn't= help achieve that, it's probably in the wrong header.

On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote:

H= ello IETF, based on my discussions with both ipv6 and geopriv teams, I=92ve= written the below document to summarize few ideas.

I= s it possible to publish this on IETF website? even if it will not be imple= mented now, at least for documentation and requesting feedback from the com= munity.

<= o:p> 

M= any thanks.

A= mmar

 

 

Ammar J. Sali= h
Baghdad, Iraq=           
October 30, 2= 012
Title: IP-LOC=
 
 
   =             &nb= sp;     
Adding GPS= location to IPv6 header
 = ;
Abstract:
=3D=3D=3D=3D= =3D=3D=3D=3D=3D
 
   = This document describes IP-LOC, an extension to IPv6 header which suggests = adding GPS coordinates, as the current method of determining the location o= f IP traffic is through IP address registration database, which is not very accurate as it depends on how the ISP register= s its IP subnets, that is normally done in a country/city format.
 
It also assum= es that in the future, GPS capability will be added to the router itself (j= ust like smart phones) and packet marking and classification based on geo-l= ocation will be required.
 
QoS, firewall= and routing based on geo-location will be highly required when mobile rout= ers move from one geo-location to another which has different policy.<= /o:p>
 
 
 
 
 
Benefits of a= dding GPS location to IPv6 header (IP-LOC)
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
 
 

Web Services: getting more accurate location= s will enhance many services provided by the web, like targeted commercials= (for example, I can get Ads regarding restaurants available in my neighbor= hoods instead of all restaurants in the city), another good example would be webpage=92s language, my language= will be detected more accurately based on my area rather than my country, = as there are many countries with more than one popular language, not mentio= ning that many ip registrations does not even reflect the traffic originating country.

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

Information accuracy and control: Nowadays, = locations are assigned to IP addresses without user awareness or control, e= very time a user performs ip-lookup query the response would be different b= ased on how the ISP has registered this IP subnet, IP-LOC suggests making locations more accurate and control= lable through OS and network devices, exactly like IP addresses (user can c= hange his/her IP address, but router can also modify the header information= - in case it's required).

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

 

Routing: Policy based routing, based on geo-= location, like routing predefined traffic through certain server or path, f= or different purposes (security, manageability, serviceability like choosin= g language, or routing traffic to specific cashing or proxy server based on country .. etc)

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

 

Copyright law: It happens when certain media= /web content is not allowed in certain countries due to copyright law, the = current method of determining locations is not accurate at all, on other ha= nd, If layer-7 application to be used then the user might be able to manipulate the location field, in this case= (if it=92s required in future) the ISP can tag traffic with country/city m= ore accurately as traffic passes through ISP=92s boarder routers.

-------------------------------
 
Maps, navigation, emergency calls and many other services will be also enha= nced with accurate locations.
 
 
 

 

CURRENT AR=
GUMENTS AGAINST THIS IDEA:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=93Adding GPS position to every IPv6 header would add a lot of overhead=94<= o:p>
 
Response: It does not have to be in every IPv6 header, only when there is l= ocation update, also the host should have the option of not to send locatio= n updates.
 
-------------------------------
 
=93What about privacy?=94
 
Response: User should have the option of not sending location updates. User= should also have the ability to set location to all zeros, in this case no= router will modify the location field and user loses the location-based se= rvices.
 
If it=92s router-to-router link, then no need to be worried about privacy a= s such information usually configured on a separate network.
 
--------------------------------
 
=93a good alternative would be to create application layer protocols that c= ould request and send GPS positions=94
 
Response: the layer-7 location request will not be detected by layer-3 devi= ces (Routers), I am assuming that in the future, GPS capability will be add= ed to the router itself (just like smart phones), features like packet mark= ing and classification based on geo-location will be required to enforce the new geo-location policies.
 
--------------------------------
 
=93For location-based routing protocols: Why would you want this?  Geo= graphical location isn't actually that important a metric for routing; what= you care about there is *topological* location, how far I am away from you= in terms of hops or latency=94
 
Response: For shortest path maybe yes, hops or latency is important, not fo= r policy-based routing, in our case you might want to do location-based rou= ting, like, routing traffic coming from French speaking users (in multi-lan= guage country like Canada) to google.fr
 
---------------------------------
 
=93For geolocation-based ACLs: you have the problem that if the geolocation= is attached by the endpoint, then it can't be trusted, since the endpoint = would lie to get past the ACL.  If it's attached by a router, the ACL = needs to have proof that the router attached it (and not the endpoint), which means that you would need a signed geoloc= ation header=94
 
Response: You could have the router modify the location field anyways, just= like L3 QoS fields, if you don't trust the host, so no need for encryption= or security, additionally,  ACL is not only for security, it could be= used for routing, QoS ..etc, so the host will not always has the motivation to manipulate the location field.<= o:p>
 
---------------------------------
 
=93Why can=92t you simply implement rules related to geo-locations statical= ly on the network device (router, firewall .. etc)?=94
 
Response: To enforce new geo-location policies automatically, let=92s assum= e that a mobile router (like a mobile BTS in a GSM network) moved from city= -x to city-y, and according to city-x regulations VoIP calls over GSM netwo= rk is allowed, but city-y regulations do not allow that. Now the topology may reflect same network metrics in bo= th cities but there is no rule that triggers configuration change based on = geo-location.

 

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

 

 
What do you t= hink?
 
 
Author/Contac= t Information:
 
   = Ammar J. Salih
   = Baghdad, Iraq
 
   = Phone: +964 770 533 0306
   = Email:   

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6<= /a>
--------------------------------------------------------------------

----------------------------------------------------
The = ;ignorance of how to use new=  = knowledge stockpiles exponentially. 
   - Marshall McLuhan

--_000_8C48B86A895913448548E6D15DA7553B1B92F4xmbrcdx09ciscocom_-- From ammar.salih@auis.edu.iq Sun Nov 18 06:51:16 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D13921F84C6 for ; Sun, 18 Nov 2012 06:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tn--fqYvg0C5 for ; Sun, 18 Nov 2012 06:51:10 -0800 (PST) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with SMTP id 2907621F84A1 for ; Sun, 18 Nov 2012 06:51:09 -0800 (PST) Received: from mail-pb0-f70.google.com ([209.85.160.70]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKUKj13bUwS++9MMWL1BZJqz79wBYfU/Df@postini.com; Sun, 18 Nov 2012 06:51:10 PST Received: by mail-pb0-f70.google.com with SMTP id ro2so2188099pbb.1 for ; Sun, 18 Nov 2012 06:51:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=W26sxjewoyWwEKxxFZd9lrN88DMn0mMNdGq3RxzH10g=; b=bdigbw0j0RXTm5Hzt2vRHCNtll4CDWX4BF7tbvIDjmf8Q8u6NJHHCjTIRtmfm1J9RZ nxc2gHPrXiNJlShH2VaVz5dVNu0R8XnOmn6JNOivgNlqF377EJTdqB7dYxFHmWEzEmXX RVlz1TsM3rAW1Jb3htBZEYo+uOrWBtRJ0jXVXy0OX0Lv2mIpWBBK2Mdl56v2DAmTddE6 DMwRX8jQyCJx8ZhKbby6rzGkVuA06p1S9TKYB77iz0qXdOAfweXRwM3dJfKVGzE7+CXr HowOcEMULL2FBdGK854llFnYyWXWX3u2zhuX9dvsp3hweslI67i7RfTRWCruAPZgcuZB NbFA== Received: by 10.68.137.41 with SMTP id qf9mr31521652pbb.103.1353250269091; Sun, 18 Nov 2012 06:51:09 -0800 (PST) Received: by 10.68.137.41 with SMTP id qf9mr31521638pbb.103.1353250268949; Sun, 18 Nov 2012 06:51:08 -0800 (PST) Received: from AMMARSALIH ([46.30.228.16]) by mx.google.com with ESMTPS id hc4sm4586079pbc.30.2012.11.18.06.51.04 (version=SSLv3 cipher=OTHER); Sun, 18 Nov 2012 06:51:07 -0800 (PST) From: "Ammar Salih" To: "'Fred Baker \(fred\)'" References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com> Date: Sun, 18 Nov 2012 17:51:00 +0300 Message-ID: <50a8f5db.04c0440a.320d.5d9e@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01CDC5B5.4803E660" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2/VMZri4Yb+IJ0QpqrzX+gy+wtKAEhLRsAAHAIoNA= Content-Language: en-us X-Gm-Message-State: ALoCoQnWYdtqJ9F8mWUZiUtBnOrsm8JJmC8ZU+nJd9GIX+/4og5QKwWZKGi+OS1hlQ2oYCCeux5XGBYEng/82kYsTCeiqIrJ0HVu1qrA1+CQWHHOsIylUiDGg/eIr5v6hxtJCkDQV3zmCmm+NWKsmOW2DO9LPS5seA== Cc: geopriv@ietf.org, ipv6@ietf.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 14:51:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000B_01CDC5B5.4803E660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Fred, You may certainly file an internet draft with your ideas. You will want to read about what an Internet Draft is and how to file one. http://www.ietf.org/id-info/ Filing an Internet Draft does not imply consensus around the specification, and you will need to build that consensus. You will want to make your case, and I would suggest starting on the geopriv mailing list, although the case will eventually have to be made to 6man. http://datatracker.ietf.org/wg/geopriv/charter/. Appreciate it, the first draft has been submitted already http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t ext=1 One consideration you should take in view is that the IPv6 header is not encrypted, so information found in it is globally readable. If there is ever a case in which your GPS location is needed by the application but may need to be guarded for privacy reasons, you will want to put it in the application layer (above the transport, guarded by IPsec or TLS), not the network layer. I have suggested few solutions to cover the privacy concern and also why I am suggesting the network layer instead of the application layer, you could find them included in the internet draft above. I would expect that 6man might tell you that the IPv6 header has one primary purpose, which is to conduct a datagram from the sender's system to the intended receiver's system; if the data doesn't help achieve that, it's probably in the wrong header. I agree, also from OSI perspective, I would think twice before including location field into network layer, then again, it's the only layer that makes the field useable to routers. Thanks, Ammar From: Fred Baker (fred) [mailto:fred@cisco.com] Sent: Friday, November 16, 2012 6:05 AM To: Ammar Salih Cc: ; Subject: Re: Adding GPS location to IPv6 header You may certainly file an internet draft with your ideas. You will want to read about what an Internet Draft is and how to file one. http://www.ietf.org/id-info/ Filing an Internet Draft does not imply consensus around the specification, and you will need to build that consensus. You will want to make your case, and I would suggest starting on the geopriv mailing list, although the case will eventually have to be made to 6man. http://datatracker.ietf.org/wg/geopriv/charter/. One consideration you should take in view is that the IPv6 header is not encrypted, so information found in it is globally readable. If there is ever a case in which your GPS location is needed by the application but may need to be guarded for privacy reasons, you will want to put it in the application layer (above the transport, guarded by IPsec or TLS), not the network layer. In fact, I would expect that 6man might tell you that the IPv6 header has one primary purpose, which is to conduct a datagram from the sender's system to the intended receiver's system; if the data doesn't help achieve that, it's probably in the wrong header. On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: Hello IETF, based on my discussions with both ipv6 and geopriv teams, I've written the below document to summarize few ideas. Is it possible to publish this on IETF website? even if it will not be implemented now, at least for documentation and requesting feedback from the community. Many thanks. Ammar Ammar J. Salih Baghdad, Iraq October 30, 2012 Title: IP-LOC Adding GPS location to IPv6 header Abstract: ========= This document describes IP-LOC, an extension to IPv6 header which suggests adding GPS coordinates, as the current method of determining the location of IP traffic is through IP address registration database, which is not very accurate as it depends on how the ISP registers its IP subnets, that is normally done in a country/city format. It also assumes that in the future, GPS capability will be added to the router itself (just like smart phones) and packet marking and classification based on geo-location will be required. QoS, firewall and routing based on geo-location will be highly required when mobile routers move from one geo-location to another which has different policy. Benefits of adding GPS location to IPv6 header (IP-LOC) ======================================================= Web Services: getting more accurate locations will enhance many services provided by the web, like targeted commercials (for example, I can get Ads regarding restaurants available in my neighborhoods instead of all restaurants in the city), another good example would be webpage's language, my language will be detected more accurately based on my area rather than my country, as there are many countries with more than one popular language, not mentioning that many ip registrations does not even reflect the traffic originating country. ------------------------------- Information accuracy and control: Nowadays, locations are assigned to IP addresses without user awareness or control, every time a user performs ip-lookup query the response would be different based on how the ISP has registered this IP subnet, IP-LOC suggests making locations more accurate and controllable through OS and network devices, exactly like IP addresses (user can change his/her IP address, but router can also modify the header information - in case it's required). ------------------------------- Routing: Policy based routing, based on geo-location, like routing predefined traffic through certain server or path, for different purposes (security, manageability, serviceability like choosing language, or routing traffic to specific cashing or proxy server based on country .. etc) ------------------------------- Copyright law: It happens when certain media/web content is not allowed in certain countries due to copyright law, the current method of determining locations is not accurate at all, on other hand, If layer-7 application to be used then the user might be able to manipulate the location field, in this case (if it's required in future) the ISP can tag traffic with country/city more accurately as traffic passes through ISP's boarder routers. ------------------------------- Maps, navigation, emergency calls and many other services will be also enhanced with accurate locations. CURRENT ARGUMENTS AGAINST THIS IDEA: ======================================== "Adding GPS position to every IPv6 header would add a lot of overhead" Response: It does not have to be in every IPv6 header, only when there is location update, also the host should have the option of not to send location updates. ------------------------------- "What about privacy?" Response: User should have the option of not sending location updates. User should also have the ability to set location to all zeros, in this case no router will modify the location field and user loses the location-based services. If it's router-to-router link, then no need to be worried about privacy as such information usually configured on a separate network. -------------------------------- "a good alternative would be to create application layer protocols that could request and send GPS positions" Response: the layer-7 location request will not be detected by layer-3 devices (Routers), I am assuming that in the future, GPS capability will be added to the router itself (just like smart phones), features like packet marking and classification based on geo-location will be required to enforce the new geo-location policies. -------------------------------- "For location-based routing protocols: Why would you want this? Geographical location isn't actually that important a metric for routing; what you care about there is *topological* location, how far I am away from you in terms of hops or latency" Response: For shortest path maybe yes, hops or latency is important, not for policy-based routing, in our case you might want to do location-based routing, like, routing traffic coming from French speaking users (in multi-language country like Canada) to google.fr --------------------------------- "For geolocation-based ACLs: you have the problem that if the geolocation is attached by the endpoint, then it can't be trusted, since the endpoint would lie to get past the ACL. If it's attached by a router, the ACL needs to have proof that the router attached it (and not the endpoint), which means that you would need a signed geolocation header" Response: You could have the router modify the location field anyways, just like L3 QoS fields, if you don't trust the host, so no need for encryption or security, additionally, ACL is not only for security, it could be used for routing, QoS ..etc, so the host will not always has the motivation to manipulate the location field. --------------------------------- "Why can't you simply implement rules related to geo-locations statically on the network device (router, firewall .. etc)?" Response: To enforce new geo-location policies automatically, let's assume that a mobile router (like a mobile BTS in a GSM network) moved from city-x to city-y, and according to city-x regulations VoIP calls over GSM network is allowed, but city-y regulations do not allow that. Now the topology may reflect same network metrics in both cities but there is no rule that triggers configuration change based on geo-location. --------------------------------- What do you think? Author/Contact Information: Ammar J. Salih Baghdad, Iraq Phone: +964 770 533 0306 Email: ammar.alsalih@gmail.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially. - Marshall McLuhan ------=_NextPart_000_000B_01CDC5B5.4803E660 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Fred,

 

You may = certainly file an internet draft with your ideas. You will want to read = about what an Internet Draft is and how to file one. http://www.ietf.org/id-info/ =

 

Filing an Internet Draft does not imply consensus = around the specification, and you will need to build that consensus. You = will want to make your case, and I would suggest starting on the geopriv = mailing list, although the case will eventually have to be made to = 6man. http://datatrack= er.ietf.org/wg/geopriv/charter/

 

Appreciate it, the first draft has been submitted already  = http://datatracker.ietf.org/doc/draft-add-location-to= -ipv6-header/?include_text=3D1  

 

One consideration = you should take in view is that the IPv6 header is not encrypted, so = information found in it is globally readable. If there is ever a = case in which your GPS location is needed by the application but may = need to be guarded for privacy reasons, you will want to put it in the = application layer (above the transport, guarded by IPsec or TLS), not = the network layer.

 

I have suggested few solutions to cover the privacy concern and also = why I am suggesting the network layer instead of the application layer, = you could find them included in the internet draft = above.

 

I would expect that 6man might tell you that the IPv6 = header has one primary purpose, which is to conduct a datagram from the = sender's system to the intended receiver's system; if the data doesn't = help achieve that, it's probably in the wrong header.

 

I agree, also from OSI perspective, I would think twice before = including location field into network layer, then again, it’s the = only layer that makes the field useable to routers. =

 

Thanks,

Ammar

 

 

From:= = Fred Baker (fred) [mailto:fred@cisco.com]
Sent: Friday, = November 16, 2012 6:05 AM
To: Ammar Salih
Cc: = <ipv6@ietf.org>; <geopriv@ietf.org>
Subject: Re: = Adding GPS location to IPv6 header

 

You may = certainly file an internet draft with your ideas. You will want to read = about what an Internet Draft is and how to file one. http://www.ietf.org/id-info/ =

 

Filing an Internet Draft does not imply consensus = around the specification, and you will need to build that consensus. You = will want to make your case, and I would suggest starting on the geopriv = mailing list, although the case will eventually have to be made to = 6man. http://datatrack= er.ietf.org/wg/geopriv/charter/

 

One consideration you should take in view is that the = IPv6 header is not encrypted, so information found in it is globally = readable. If there is ever a case in which your GPS location is = needed by the application but may need to be guarded for privacy = reasons, you will want to put it in the application layer (above the = transport, guarded by IPsec or TLS), not the network layer. In fact, I = would expect that 6man might tell you that the IPv6 header has one = primary purpose, which is to conduct a datagram from the sender's system = to the intended receiver's system; if the data doesn't help achieve = that, it's probably in the wrong = header.

 

On = Nov 10, 2012, at 7:05 AM, Ammar Salih wrote:



Hello IETF, based on my discussions with both ipv6 and geopriv teams, = I’ve written the below document to summarize few = ideas.=

Is it possible to publish this on IETF website? even if it will not be = implemented now, at least for documentation and requesting feedback from = the community.=

 =

Many thanks.=

Ammar=

 =

 =

Ammar J. = Salih=

Baghdad, = Iraq          =

October 30, = 2012=

Title: = IP-LOC=

 =

 =

   =             &= nbsp;     =

Adding GPS location = to IPv6 header=

 =

Abstract:=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=

 =

   This = document describes IP-LOC, an extension to IPv6 header which suggests = adding GPS coordinates, as the current method of determining the = location of IP traffic is through IP address registration database, = which is not very accurate as it depends on how the ISP registers its IP = subnets, that is normally done in a country/city format.=

 =

It also assumes = that in the future, GPS capability will be added to the router itself = (just like smart phones) and packet marking and classification based on = geo-location will be required.=

 =

QoS, firewall and = routing based on geo-location will be highly required when mobile = routers move from one geo-location to another which has different = policy.=

 =

 =

 =

 =

 =

Benefits of adding = GPS location to IPv6 header (IP-LOC)=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=

 =

 =

Web Services: getting more accurate locations will enhance many = services provided by the web, like targeted commercials (for example, I = can get Ads regarding restaurants available in my neighborhoods instead = of all restaurants in the city), another good example would be = webpage’s language, my language will be detected more accurately = based on my area rather than my country, as there are many countries = with more than one popular language, not mentioning that many ip = registrations does not even reflect the traffic originating = country.=

-------------------------= ------

 <= /p>

Information accuracy and control: Nowadays, locations are assigned to = IP addresses without user awareness or control, every time a user = performs ip-lookup query the response would be different based on how = the ISP has registered this IP subnet, IP-LOC suggests making locations = more accurate and controllable through OS and network devices, exactly = like IP addresses (user can change his/her IP address, but router can = also modify the header information - in case it's required).=

-------------------------= ------

 =

Routing: Policy based routing, based on geo-location, like routing = predefined traffic through certain server or path, for different = purposes (security, manageability, serviceability like choosing = language, or routing traffic to specific cashing or proxy server based = on country .. etc)=

-------------------------= ------

 =

Copyright law: It happens when certain media/web content is not allowed = in certain countries due to copyright law, the current method of = determining locations is not accurate at all, on other hand, If layer-7 = application to be used then the user might be able to manipulate the = location field, in this case (if it’s required in future) the ISP = can tag traffic with country/city more accurately as traffic passes = through ISP’s boarder routers.=

-------------------------= ------

 <= /p>

Maps, navigation, = emergency calls and many other services will be also enhanced with = accurate locations.

 =

 =

 =

 =

CURRENT ARGUMENTS AGAINST THIS =
IDEA:

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

“Adding GPS = position to every IPv6 header would add a lot of = overhead”

 <= /p>

Response: It does not = have to be in every IPv6 header, only when there is location update, = also the host should have the option of not to send location = updates.

 <= /p>

-------------------------= ------

 <= /p>

“What about = privacy?”

 <= /p>

Response: User should = have the option of not sending location updates. User should also have = the ability to set location to all zeros, in this case no router will = modify the location field and user loses the location-based = services.

 <= /p>

If it’s = router-to-router link, then no need to be worried about privacy as such = information usually configured on a separate = network.

 <= /p>

-------------------------= -------

 <= /p>

“a good = alternative would be to create application layer protocols that could = request and send GPS positions”

 <= /p>

Response: the layer-7 = location request will not be detected by layer-3 devices (Routers), I am = assuming that in the future, GPS capability will be added to the router = itself (just like smart phones), features like packet marking and = classification based on geo-location will be required to enforce the new = geo-location policies.

 <= /p>

-------------------------= -------

 <= /p>

“For = location-based routing protocols: Why would you want this?  = Geographical location isn't actually that important a metric for = routing; what you care about there is *topological* location, how far I = am away from you in terms of hops or = latency”

 <= /p>

Response: For shortest = path maybe yes, hops or latency is important, not for policy-based = routing, in our case you might want to do location-based routing, like, = routing traffic coming from French speaking users (in multi-language = country like Canada) to google.fr

=

 <= /p>

-------------------------= --------

 <= /p>

“For = geolocation-based ACLs: you have the problem that if the geolocation is = attached by the endpoint, then it can't be trusted, since the endpoint = would lie to get past the ACL.  If it's attached by a router, the = ACL needs to have proof that the router attached it (and not the = endpoint), which means that you would need a signed geolocation = header”

 <= /p>

Response: You could have = the router modify the location field anyways, just like L3 QoS fields, = if you don't trust the host, so no need for encryption or security, = additionally,  ACL is not only for security, it could be used for = routing, QoS ..etc, so the host will not always has the motivation to = manipulate the location field.

 <= /p>

-------------------------= --------

 <= /p>

“Why can’t = you simply implement rules related to geo-locations statically on the = network device (router, firewall .. = etc)?”

 <= /p>

Response: To enforce new = geo-location policies automatically, let’s assume that a mobile = router (like a mobile BTS in a GSM network) moved from city-x to city-y, = and according to city-x regulations VoIP calls over GSM network is = allowed, but city-y regulations do not allow that. Now the topology may = reflect same network metrics in both cities but there is no rule that = triggers configuration change based on = geo-location.

 =

-------------------------= --------

 =

 =

What do you = think?=

 =

 =

Author/Contact = Information:=

 =

   Ammar = J. Salih=

   = Baghdad, Iraq=

 =

   Phone: = +964 770 533 0306=

   = Email: ammar.alsalih@gmail.com=

 =

---------= -----------------------------------------------------------
IETF IPv6 = working group mailing list
ipv6@ietf.org
Administrative = Requests: https://www.ietf.org/= mailman/listinfo/ipv6
--------------------------------------------= ------------------------

 

----------------------------------------------------=

The = = ignorance of how = to = use new knowledge&= nbsp;= stockpiles exponentially.<= span = style=3D'font-size:13.5pt;font-family:"Helvetica","sans-serif";color:blac= k'> 

   - Marshall = McLuhan

 

------=_NextPart_000_000B_01CDC5B5.4803E660-- From jeanjour@comcast.net Sun Nov 18 15:41:21 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5314A21F84EC for ; Sun, 18 Nov 2012 15:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-rIpaZpyJMW for ; Sun, 18 Nov 2012 15:41:20 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 5C22421F85CF for ; Sun, 18 Nov 2012 15:41:20 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta03.westchester.pa.mail.comcast.net with comcast id R82n1k0041ZXKqc53BhKFt; Sun, 18 Nov 2012 23:41:19 +0000 Received: from [10.0.1.3] ([98.229.211.49]) by omta21.westchester.pa.mail.comcast.net with comcast id RBhJ1k00W14WE023hBhJEY; Sun, 18 Nov 2012 23:41:19 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <50a02371.86d60e0a.4f2d.02f1@mx.google.com> Date: Sun, 18 Nov 2012 18:39:16 -0500 To: Eitan Adler , Ammar Salih From: John Day Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailman-Approved-At: Sun, 18 Nov 2012 17:43:48 -0800 Cc: geopriv@ietf.org, ipv6@ietf.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 23:41:21 -0000 It has been interesting to watch this discussion, but Eitan and others have it correct. The purpose of network addresses is to locate an entity in the graph of the network. Network addresses are intended to facilitate forwarding. For forwarding, only the structure of the graph is important. (Notice I did not say "topology." A topology refers to the invariant properties of a mapping among sets. A graph is not a topology. A set of graphs might be. Yes, I know the field abuses the term all the time. Another failure of education.) Physical location has nothing to do with the operation of the network layer. It is all about forwarding packets within the graph formed by the layer. When one says that network addresses are location dependent (and they are) it is with respect to the graph of the network. This is also why addresses must be assigned *by* the network. Only the network knows where in the graph the nodes are. (Yes, this means that so-called MAC addresses are not addresses. They are serial numbers. Neither were IP addresses pre-CIDR.) All identifiers in computing are addresses and locate something. As Saltzer says, to resolve a name is to locate an object in a given context. Things like a so-called flat address is really just an address used outside its context. For example, MAC addresses locate the manufacturer and however else the manufacturer used the space. This is all pretty basic stuff. At 18:22 -0500 2012/11/11, Eitan Adler wrote: >On 11 November 2012 17:15, Ammar Salih wrote: > >They use IP address instead, and it's not always about http >applications, how about VoIP applications, now you need another >mechanism? I believe you were referring to Google here. The wonderful thing about software is that it is possible for not very good programmers to do dumb things that will work for awhile. As we have seen in this field since its inception, it is dangerous to confuse economic success with good science. "Well, it works!" is merely an excuse, not an argument for good science. Take care, John Day > >Nothing stops application layer protocols from sharing one mechanism > >> .. how about detecting your preferred language for layer-3 routing? > >Why does language matter ever matter in the network layer? It has nothing do with physical location either. So, if you would put that in why not something else. > >>>as there are many countries with more than one popular language, not >>>mentioning that many ip registrations does not even reflect the traffic >>>originating country. > >Exactly. You can't infer language from location. Some locations have >multiple valid languages. This isn't a valid use case. > >> I've explained this in previous parts of the document, mainly >>because Layer-3 devices won't be able to recognize the feature, and >>also to unify the location implementations at different layers. > >Why do layer 3 devices need this information? So far you have >mentioned exactly one use case that *might* be useful. > >> It doesn't have to be always .. at least now you partially agree :) > >I didn't say that. I said that this is the first time I you have >mentioned anything that *could* (not necc. should) be acting at layer >3. > >> Users currently have absolutely *NO* control over IP<->location >>mapping, it's totally how your IP owner has >> registered the IP subnet, what I am suggesting is that your local >>ISP *can* tag the city location "if it's required", unless you want >>to share your exact location or set the location to all zeros, in >>this case you are asking the ISP not to tag your location, but in >>this case you give up all location based services. > >Unless the ISP decides to ignore your "request" and provide the >information anyways. Also, what if your actual location differs from >the IP address range your request is coming from. This can easily >occur from tunnels or mobile networks. > >>> Response: It does not have to be in every IPv6 header, only when there >>> is location update, also the host should have the option of not to >>> send location updates. > >How does the IP layer know when the *application layer* needs this >information? > >>*BUT* if it's required by the government/or any other >>>organization or third party in the future for the sake >>of >protecting the copyright laws then the feature will >>be >available to support that as well. > >How would my ISP know my GPS coordinates? Once again please think >about this in the context of tunnels and mobile networks. > >> Google.fr example is confusing many people, which I will modify, >>policy based routing has much more than routing tcp:80 traffic. > >Why should the policy differ based on GPS coordinates? > > >-- >Eitan Adler >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From ammar.salih@auis.edu.iq Tue Nov 20 03:34:09 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB2821F8534 for ; Tue, 20 Nov 2012 03:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eA2tWCQQEPHs for ; Tue, 20 Nov 2012 03:34:08 -0800 (PST) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with SMTP id 9EC5621F8522 for ; Tue, 20 Nov 2012 03:34:08 -0800 (PST) Received: from mail-pa0-f70.google.com ([209.85.220.70]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKUKtqsDMG7CLw22vIvPkFAufrO7HnPE45@postini.com; Tue, 20 Nov 2012 03:34:08 PST Received: by mail-pa0-f70.google.com with SMTP id hz11so3306646pad.1 for ; Tue, 20 Nov 2012 03:34:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=onfxfs/KPoRUcz017V+XnsIn6yD4S1sReghKBlPS7/g=; b=ZYHlND4onMgXSyCaWRdj/wZc4pq9qDdHlgIdhPNQLxad34UA7ytMGeNgEDony/bIrz v2cLsPAItGv+MDqDC6ifvY8vvuX3/cz9AOIbldRvB56v+St9t8GycACmMR17xVQ/yfjq xJa1idV9UY0amsa7jPkSHbn/1pgbE6Us1o/LnlEQYPmsd1JSse9KCB/49poBHNRtHYNe Huzn6aAGQZN3EcqBSsVFF3Vu2sBSTi/+SQu1CxIRwV636qlM5wi/s7t/IdfQ9G4t/Oz1 YoCfqB+VnOPdtpQIYB0HLJVuxyArGtY6943PN2JE9eZlx0vDHpAOtbwAFSSkwZkg2l6q wB4w== Received: by 10.66.80.166 with SMTP id s6mr7127134pax.21.1353411247651; Tue, 20 Nov 2012 03:34:07 -0800 (PST) Received: by 10.66.80.166 with SMTP id s6mr7127126pax.21.1353411247562; Tue, 20 Nov 2012 03:34:07 -0800 (PST) Received: from AMMARSALIH ([46.30.228.16]) by mx.google.com with ESMTPS id iu8sm7938722pbc.71.2012.11.20.03.34.02 (version=SSLv3 cipher=OTHER); Tue, 20 Nov 2012 03:34:05 -0800 (PST) From: "Ammar Salih" To: "'John Day'" References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <50a02371.86d60e0a.4f2d.02f1@mx.google.com> In-Reply-To: Date: Tue, 20 Nov 2012 14:33:57 +0300 Message-ID: <50ab6aad.88c5440a.7553.7395@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac3F5jZuO5mIMHp4QxiM9PQiSDfLRABB0+hA Content-Language: en-us X-Gm-Message-State: ALoCoQlpEiJ4qdyy3wnwIqD57OonrVKaxso3Fsm5oBi5nExgCEfSYt/QhY9YO9bz+xsbbIskZAU5ivRsRn1XlBdG++J7vhvzL3dlGRyG9asWp4KVYuGV5omLRGgGD+iVgDns3qvb5RiCrW9ZZZa8xYlW8zPw2ZMbsg== Cc: geopriv@ietf.org, 'Eitan Adler' , ipv6@ietf.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 11:34:09 -0000 John, > The purpose of network addresses is to locate an entity in the graph of > the network. Network addresses are intended to facilitate forwarding. > For forwarding, only the structure of the graph is important. (Notice I > did not say "topology." A topology refers to the invariant properties of > a mapping among sets. A graph is not a topology. A set of graphs might be. > Yes, I know the field abuses the term all the time. Another failure of > education.) I do understand that the intial purpose of layer-3 is to route data through topological map, but that was 30 years ago, the IP concept is even older, I believe it's about time to look into what has been done so far, and to let some changes take place, and to give more space to new applications and services to be introduces by providing the proper infrastructure. > Physical location has nothing to do with the operation of the network > layer. It is all about forwarding packets within the graph formed by the > layer. When one says that network addresses are location dependent (and > they are) it is with respect to the graph of the network. This is also > why addresses must be assigned *by* the network. Only the network knows > where in the graph the nodes are. Once you provide location-based services, physical and network locations will be strongly binded together, otherwise network will not know where to forward these packets and topological location alone will be useless. > I believe you were referring to Google here. The wonderful thing about > software is that it is possible for not very good programmers to do dumb > things that will work for awhile. As we have seen in this field since its > inception, it is dangerous to confuse economic success with good science. > "Well, it works!" is merely an excuse, not an argument for good science. Good science should be practical enough to be applied in real life, business and services invest technology to make peoples life easier and more prodective .. I may not agree with you in refferring to google and others as "not very good programmers to do dumb things that will work for awhile". Thanks, Ammar -----Original Message----- From: John Day [mailto:jeanjour@comcast.net] Sent: Monday, November 19, 2012 2:39 AM To: Eitan Adler; Ammar Salih Cc: geopriv@ietf.org; ipv6@ietf.org Subject: Re: Adding GPS location to IPv6 header It has been interesting to watch this discussion, but Eitan and others have it correct. The purpose of network addresses is to locate an entity in the graph of the network. Network addresses are intended to facilitate forwarding. For forwarding, only the structure of the graph is important. (Notice I did not say "topology." A topology refers to the invariant properties of a mapping among sets. A graph is not a topology. A set of graphs might be. Yes, I know the field abuses the term all the time. Another failure of education.) Physical location has nothing to do with the operation of the network layer. It is all about forwarding packets within the graph formed by the layer. When one says that network addresses are location dependent (and they are) it is with respect to the graph of the network. This is also why addresses must be assigned *by* the network. Only the network knows where in the graph the nodes are. (Yes, this means that so-called MAC addresses are not addresses. They are serial numbers. Neither were IP addresses pre-CIDR.) All identifiers in computing are addresses and locate something. As Saltzer says, to resolve a name is to locate an object in a given context. Things like a so-called flat address is really just an address used outside its context. For example, MAC addresses locate the manufacturer and however else the manufacturer used the space. This is all pretty basic stuff. At 18:22 -0500 2012/11/11, Eitan Adler wrote: >On 11 November 2012 17:15, Ammar Salih wrote: > >They use IP address instead, and it's not always about http >applications, how about VoIP applications, now you need another >mechanism? I believe you were referring to Google here. The wonderful thing about software is that it is possible for not very good programmers to do dumb things that will work for awhile. As we have seen in this field since its inception, it is dangerous to confuse economic success with good science. "Well, it works!" is merely an excuse, not an argument for good science. Take care, John Day > >Nothing stops application layer protocols from sharing one mechanism > >> .. how about detecting your preferred language for layer-3 routing? > >Why does language matter ever matter in the network layer? It has nothing do with physical location either. So, if you would put that in why not something else. > >>>as there are many countries with more than one popular language, not >>>mentioning that many ip registrations does not even reflect the >>>traffic originating country. > >Exactly. You can't infer language from location. Some locations have >multiple valid languages. This isn't a valid use case. > >> I've explained this in previous parts of the document, mainly >>because Layer-3 devices won't be able to recognize the feature, and >>also to unify the location implementations at different layers. > >Why do layer 3 devices need this information? So far you have >mentioned exactly one use case that *might* be useful. > >> It doesn't have to be always .. at least now you partially agree :) > >I didn't say that. I said that this is the first time I you have >mentioned anything that *could* (not necc. should) be acting at layer >3. > >> Users currently have absolutely *NO* control over IP<->location >>mapping, it's totally how your IP owner has >> registered the IP subnet, what I am suggesting is that your local >>ISP *can* tag the city location "if it's required", unless you want to >>share your exact location or set the location to all zeros, in this >>case you are asking the ISP not to tag your location, but in this case >>you give up all location based services. > >Unless the ISP decides to ignore your "request" and provide the >information anyways. Also, what if your actual location differs from >the IP address range your request is coming from. This can easily occur >from tunnels or mobile networks. > >>> Response: It does not have to be in every IPv6 header, only when >>> there is location update, also the host should have the option of >>> not to send location updates. > >How does the IP layer know when the *application layer* needs this >information? > >>*BUT* if it's required by the government/or any other >>>organization or third party in the future for the sake >>of >protecting the copyright laws then the feature will be >available >>to support that as well. > >How would my ISP know my GPS coordinates? Once again please think >about this in the context of tunnels and mobile networks. > >> Google.fr example is confusing many people, which I will modify, >>policy based routing has much more than routing tcp:80 traffic. > >Why should the policy differ based on GPS coordinates? > > >-- >Eitan Adler >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From rbarnes@bbn.com Tue Nov 20 10:49:54 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D30721F87D2; Tue, 20 Nov 2012 10:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.682 X-Spam-Level: X-Spam-Status: No, score=-106.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSvbhNzs6-SA; Tue, 20 Nov 2012 10:49:53 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B34BE21F87A3; Tue, 20 Nov 2012 10:49:52 -0800 (PST) Received: from [128.89.253.219] (port=49728) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TastI-0008dC-Q3; Tue, 20 Nov 2012 13:49:48 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Richard L. Barnes" In-Reply-To: <50a8f5db.04c0440a.320d.5d9e@mx.google.com> Date: Tue, 20 Nov 2012 13:49:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com> <50a8f5db.04c0440a.320d.5d9e@mx.google.com> To: Ammar Salih X-Mailer: Apple Mail (2.1499) Cc: geopriv@ietf.org, ipv6@ietf.org, "'Fred Baker \(fred\)'" Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 18:49:54 -0000 Hi Ammar, I have read your draft. =46rom what I can tell, it is just a summary of = the arguments in this thread. It would be more helpful if you could add = a level of technical detail to help people understand. I would want to = see at least: 1. The format of the IPv6 option 2. Where it is to be added to / removed from a packet 3. Requirements for routers / hosts 4. Privacy considerations 5. Security considerations Also, it will be slightly easier to read if you use some of the standard = tools for authoring Internet drafts. See, for example: Technically speaking, I'm not yet convinced that this option is very = useful, but it does not seem to me that this option would be harmful to = the network, only possibly the privacy of users. In specifying the = privacy mechanisms in your detailed description, I would suggest that = you make this mechanism "opt-in" by end hosts. For example, you could = have an all-zero geolocation option indicate that a host wishes to = disclose its location, but doesn't know its geolocation to put in the = option; then you could require that a router SHOULD NOT populate this = option unless an all-zero geolocation option is already present = (indicating consent). It would also be helpful to clarify how this option would relate to = other similar options, such as the line identifier option: Hope this helps, --Richard On Nov 18, 2012, at 9:51 AM, Ammar Salih = wrote: > Hello Fred, >=20 > =20 > You may certainly file an internet draft with your ideas. You will = want to read about what an Internet Draft is and how to file one. = http://www.ietf.org/id-info/ > =20 > Filing an Internet Draft does not imply consensus around the = specification, and you will need to build that consensus. You will want = to make your case, and I would suggest starting on the geopriv mailing = list, although the case will eventually have to be made to 6man. = http://datatracker.ietf.org/wg/geopriv/charter/.=20 > =20 > Appreciate it, the first draft has been submitted already = http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include= _text=3D1 =20 >=20 > =20 > One consideration you should take in view is that the IPv6 header is = not encrypted, so information found in it is globally readable. If there = is ever a case in which your GPS location is needed by the application = but may need to be guarded for privacy reasons, you will want to put it = in the application layer (above the transport, guarded by IPsec or TLS), = not the network layer. > =20 > I have suggested few solutions to cover the privacy concern and also = why I am suggesting the network layer instead of the application layer, = you could find them included in the internet draft above. >=20 > =20 > I would expect that 6man might tell you that the IPv6 header has one = primary purpose, which is to conduct a datagram from the sender's system = to the intended receiver's system; if the data doesn't help achieve = that, it's probably in the wrong header. > =20 > I agree, also from OSI perspective, I would think twice before = including location field into network layer, then again, it=92s the only = layer that makes the field useable to routers. >=20 > =20 >=20 > Thanks, >=20 > Ammar >=20 > =20 > =20 > From: Fred Baker (fred) [mailto:fred@cisco.com]=20 > Sent: Friday, November 16, 2012 6:05 AM > To: Ammar Salih > Cc: ; > Subject: Re: Adding GPS location to IPv6 header > =20 > You may certainly file an internet draft with your ideas. You will = want to read about what an Internet Draft is and how to file one. = http://www.ietf.org/id-info/ > =20 > Filing an Internet Draft does not imply consensus around the = specification, and you will need to build that consensus. You will want = to make your case, and I would suggest starting on the geopriv mailing = list, although the case will eventually have to be made to 6man. = http://datatracker.ietf.org/wg/geopriv/charter/.=20 > =20 > One consideration you should take in view is that the IPv6 header is = not encrypted, so information found in it is globally readable. If there = is ever a case in which your GPS location is needed by the application = but may need to be guarded for privacy reasons, you will want to put it = in the application layer (above the transport, guarded by IPsec or TLS), = not the network layer. In fact, I would expect that 6man might tell you = that the IPv6 header has one primary purpose, which is to conduct a = datagram from the sender's system to the intended receiver's system; if = the data doesn't help achieve that, it's probably in the wrong header. > =20 > On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: >=20 >=20 > Hello IETF, based on my discussions with both ipv6 and geopriv teams, = I=92ve written the below document to summarize few ideas. >=20 > Is it possible to publish this on IETF website? even if it will not be = implemented now, at least for documentation and requesting feedback from = the community. >=20 > =20 >=20 > Many thanks. >=20 > Ammar >=20 > =20 >=20 > =20 >=20 > Ammar J. Salih > Baghdad, Iraq =20 > October 30, 2012 > Title: IP-LOC > =20 > =20 > =20 > Adding GPS location to IPv6 header > =20 > Abstract: > =3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > This document describes IP-LOC, an extension to IPv6 header which = suggests adding GPS coordinates, as the current method of determining = the location of IP traffic is through IP address registration database, = which is not very accurate as it depends on how the ISP registers its IP = subnets, that is normally done in a country/city format. > =20 > It also assumes that in the future, GPS capability will be added to = the router itself (just like smart phones) and packet marking and = classification based on geo-location will be required. > =20 > QoS, firewall and routing based on geo-location will be highly = required when mobile routers move from one geo-location to another which = has different policy. > =20 > =20 > =20 > =20 > =20 > Benefits of adding GPS location to IPv6 header (IP-LOC) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > =20 > =20 > Web Services: getting more accurate locations will enhance many = services provided by the web, like targeted commercials (for example, I = can get Ads regarding restaurants available in my neighborhoods instead = of all restaurants in the city), another good example would be webpage=92s= language, my language will be detected more accurately based on my area = rather than my country, as there are many countries with more than one = popular language, not mentioning that many ip registrations does not = even reflect the traffic originating country. >=20 > ------------------------------- > =20 > Information accuracy and control: Nowadays, locations are assigned to = IP addresses without user awareness or control, every time a user = performs ip-lookup query the response would be different based on how = the ISP has registered this IP subnet, IP-LOC suggests making locations = more accurate and controllable through OS and network devices, exactly = like IP addresses (user can change his/her IP address, but router can = also modify the header information - in case it's required). >=20 > ------------------------------- > =20 >=20 > Routing: Policy based routing, based on geo-location, like routing = predefined traffic through certain server or path, for different = purposes (security, manageability, serviceability like choosing = language, or routing traffic to specific cashing or proxy server based = on country .. etc) >=20 > ------------------------------- > =20 >=20 > Copyright law: It happens when certain media/web content is not = allowed in certain countries due to copyright law, the current method of = determining locations is not accurate at all, on other hand, If layer-7 = application to be used then the user might be able to manipulate the = location field, in this case (if it=92s required in future) the ISP can = tag traffic with country/city more accurately as traffic passes through = ISP=92s boarder routers. >=20 > ------------------------------- > =20 > Maps, navigation, emergency calls and many other services will be also = enhanced with accurate locations. > =20 > =20 > =20 > =20 >=20 > CURRENT ARGUMENTS AGAINST THIS IDEA: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > =93Adding GPS position to every IPv6 header would add a lot of = overhead=94 > =20 > Response: It does not have to be in every IPv6 header, only when there = is location update, also the host should have the option of not to send = location updates. > =20 > ------------------------------- > =20 > =93What about privacy?=94 > =20 > Response: User should have the option of not sending location updates. = User should also have the ability to set location to all zeros, in this = case no router will modify the location field and user loses the = location-based services. > =20 > If it=92s router-to-router link, then no need to be worried about = privacy as such information usually configured on a separate network. > =20 > -------------------------------- > =20 > =93a good alternative would be to create application layer protocols = that could request and send GPS positions=94 > =20 > Response: the layer-7 location request will not be detected by layer-3 = devices (Routers), I am assuming that in the future, GPS capability will = be added to the router itself (just like smart phones), features like = packet marking and classification based on geo-location will be required = to enforce the new geo-location policies. > =20 > -------------------------------- > =20 > =93For location-based routing protocols: Why would you want this? = Geographical location isn't actually that important a metric for = routing; what you care about there is *topological* location, how far I = am away from you in terms of hops or latency=94 > =20 > Response: For shortest path maybe yes, hops or latency is important, = not for policy-based routing, in our case you might want to do = location-based routing, like, routing traffic coming from French = speaking users (in multi-language country like Canada) to google.fr > =20 > --------------------------------- > =20 > =93For geolocation-based ACLs: you have the problem that if the = geolocation is attached by the endpoint, then it can't be trusted, since = the endpoint would lie to get past the ACL. If it's attached by a = router, the ACL needs to have proof that the router attached it (and not = the endpoint), which means that you would need a signed geolocation = header=94 > =20 > Response: You could have the router modify the location field anyways, = just like L3 QoS fields, if you don't trust the host, so no need for = encryption or security, additionally, ACL is not only for security, it = could be used for routing, QoS ..etc, so the host will not always has = the motivation to manipulate the location field. > =20 > --------------------------------- > =20 > =93Why can=92t you simply implement rules related to geo-locations = statically on the network device (router, firewall .. etc)?=94 > =20 > Response: To enforce new geo-location policies automatically, let=92s = assume that a mobile router (like a mobile BTS in a GSM network) moved = from city-x to city-y, and according to city-x regulations VoIP calls = over GSM network is allowed, but city-y regulations do not allow that. = Now the topology may reflect same network metrics in both cities but = there is no rule that triggers configuration change based on = geo-location. > =20 >=20 > --------------------------------- > =20 >=20 > =20 > What do you think? > =20 > =20 > Author/Contact Information: > =20 > Ammar J. Salih > Baghdad, Iraq > =20 > Phone: +964 770 533 0306 > Email: ammar.alsalih@gmail.com > =20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > =20 > ---------------------------------------------------- > The ignorance of how to use new knowledge stockpiles exponentially.=20 > - Marshall McLuhan > =20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From creed@opengeospatial.org Tue Nov 20 11:55:38 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE0221F851F; Tue, 20 Nov 2012 11:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.609 X-Spam-Level: X-Spam-Status: No, score=-0.609 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, STOX_REPLY_TYPE=0.001, TVD_FINGER_02=2.134] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hzVT0A9iavS; Tue, 20 Nov 2012 11:55:36 -0800 (PST) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDBB21F8516; Tue, 20 Nov 2012 11:55:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 3EC69940AD; Tue, 20 Nov 2012 14:55:35 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (scale.ogcinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vb0wivcQcSAU; Tue, 20 Nov 2012 14:55:34 -0500 (EST) Received: from OfficeHP (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail.opengeospatial.org (Postfix) with ESMTPSA id B055894064; Tue, 20 Nov 2012 14:55:33 -0500 (EST) Message-ID: From: "Carl Reed" To: "Richard L. Barnes" , "Ammar Salih" References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com><8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com><50a8f5db.04c0440a.320d.5d9e@mx.google.com> <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> In-Reply-To: <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> Date: Tue, 20 Nov 2012 12:52:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Cc: geopriv@ietf.org, ipv6@ietf.org, "'Fred Baker \(fred\)'" Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 19:55:38 -0000 Hi - I asked this question before and did not get a response (maybe because my question was off base). There is a location extension for DHCP. This extension is consistent with other location object definitions used in the IETF as well as what is used and specified in various ISO, OGC, OASIS and other standards. Why not use the DHCP location extension? Why define yet another location element for IPv6? Thanks Carl Reed, PhD CTO OGC -----Original Message----- From: Richard L. Barnes Sent: Tuesday, November 20, 2012 11:49 AM To: Ammar Salih Cc: geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' Subject: Re: [Geopriv] Adding GPS location to IPv6 header Hi Ammar, I have read your draft. From what I can tell, it is just a summary of the arguments in this thread. It would be more helpful if you could add a level of technical detail to help people understand. I would want to see at least: 1. The format of the IPv6 option 2. Where it is to be added to / removed from a packet 3. Requirements for routers / hosts 4. Privacy considerations 5. Security considerations Also, it will be slightly easier to read if you use some of the standard tools for authoring Internet drafts. See, for example: Technically speaking, I'm not yet convinced that this option is very useful, but it does not seem to me that this option would be harmful to the network, only possibly the privacy of users. In specifying the privacy mechanisms in your detailed description, I would suggest that you make this mechanism "opt-in" by end hosts. For example, you could have an all-zero geolocation option indicate that a host wishes to disclose its location, but doesn't know its geolocation to put in the option; then you could require that a router SHOULD NOT populate this option unless an all-zero geolocation option is already present (indicating consent). It would also be helpful to clarify how this option would relate to other similar options, such as the line identifier option: Hope this helps, --Richard On Nov 18, 2012, at 9:51 AM, Ammar Salih wrote: > Hello Fred, > > > You may certainly file an internet draft with your ideas. You will want to > read about what an Internet Draft is and how to file one. > http://www.ietf.org/id-info/ > > Filing an Internet Draft does not imply consensus around the > specification, and you will need to build that consensus. You will want to > make your case, and I would suggest starting on the geopriv mailing list, > although the case will eventually have to be made to 6man. > http://datatracker.ietf.org/wg/geopriv/charter/. > > Appreciate it, the first draft has been submitted already > http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_text=1 > > > One consideration you should take in view is that the IPv6 header is not > encrypted, so information found in it is globally readable. If there is > ever a case in which your GPS location is needed by the application but > may need to be guarded for privacy reasons, you will want to put it in the > application layer (above the transport, guarded by IPsec or TLS), not the > network layer. > > I have suggested few solutions to cover the privacy concern and also why I > am suggesting the network layer instead of the application layer, you > could find them included in the internet draft above. > > > I would expect that 6man might tell you that the IPv6 header has one > primary purpose, which is to conduct a datagram from the sender's system > to the intended receiver's system; if the data doesn't help achieve that, > it's probably in the wrong header. > > I agree, also from OSI perspective, I would think twice before including > location field into network layer, then again, its the only layer that > makes the field useable to routers. > > > > Thanks, > > Ammar > > > > From: Fred Baker (fred) [mailto:fred@cisco.com] > Sent: Friday, November 16, 2012 6:05 AM > To: Ammar Salih > Cc: ; > Subject: Re: Adding GPS location to IPv6 header > > You may certainly file an internet draft with your ideas. You will want to > read about what an Internet Draft is and how to file one. > http://www.ietf.org/id-info/ > > Filing an Internet Draft does not imply consensus around the > specification, and you will need to build that consensus. You will want to > make your case, and I would suggest starting on the geopriv mailing list, > although the case will eventually have to be made to 6man. > http://datatracker.ietf.org/wg/geopriv/charter/. > > One consideration you should take in view is that the IPv6 header is not > encrypted, so information found in it is globally readable. If there is > ever a case in which your GPS location is needed by the application but > may need to be guarded for privacy reasons, you will want to put it in the > application layer (above the transport, guarded by IPsec or TLS), not the > network layer. In fact, I would expect that 6man might tell you that the > IPv6 header has one primary purpose, which is to conduct a datagram from > the sender's system to the intended receiver's system; if the data doesn't > help achieve that, it's probably in the wrong header. > > On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: > > > Hello IETF, based on my discussions with both ipv6 and geopriv teams, Ive > written the below document to summarize few ideas. > > Is it possible to publish this on IETF website? even if it will not be > implemented now, at least for documentation and requesting feedback from > the community. > > > > Many thanks. > > Ammar > > > > > > Ammar J. Salih > Baghdad, Iraq > October 30, 2012 > Title: IP-LOC > > > > Adding GPS location to IPv6 header > > Abstract: > ========= > > This document describes IP-LOC, an extension to IPv6 header which > suggests adding GPS coordinates, as the current method of determining the > location of IP traffic is through IP address registration database, which > is not very accurate as it depends on how the ISP registers its IP > subnets, that is normally done in a country/city format. > > It also assumes that in the future, GPS capability will be added to the > router itself (just like smart phones) and packet marking and > classification based on geo-location will be required. > > QoS, firewall and routing based on geo-location will be highly required > when mobile routers move from one geo-location to another which has > different policy. > > > > > > Benefits of adding GPS location to IPv6 header (IP-LOC) > ======================================================= > > > Web Services: getting more accurate locations will enhance many services > provided by the web, like targeted commercials (for example, I can get Ads > regarding restaurants available in my neighborhoods instead of all > restaurants in the city), another good example would be webpages > language, my language will be detected more accurately based on my area > rather than my country, as there are many countries with more than one > popular language, not mentioning that many ip registrations does not even > reflect the traffic originating country. > > ------------------------------- > > Information accuracy and control: Nowadays, locations are assigned to IP > addresses without user awareness or control, every time a user performs > ip-lookup query the response would be different based on how the ISP has > registered this IP subnet, IP-LOC suggests making locations more accurate > and controllable through OS and network devices, exactly like IP addresses > (user can change his/her IP address, but router can also modify the header > information - in case it's required). > > ------------------------------- > > > Routing: Policy based routing, based on geo-location, like routing > predefined traffic through certain server or path, for different purposes > (security, manageability, serviceability like choosing language, or > routing traffic to specific cashing or proxy server based on country .. > etc) > > ------------------------------- > > > Copyright law: It happens when certain media/web content is not allowed in > certain countries due to copyright law, the current method of determining > locations is not accurate at all, on other hand, If layer-7 application to > be used then the user might be able to manipulate the location field, in > this case (if its required in future) the ISP can tag traffic with > country/city more accurately as traffic passes through ISPs boarder > routers. > > ------------------------------- > > Maps, navigation, emergency calls and many other services will be also > enhanced with accurate locations. > > > > > > CURRENT ARGUMENTS AGAINST THIS IDEA: > ======================================== > > Adding GPS position to every IPv6 header would add a lot of overhead > > Response: It does not have to be in every IPv6 header, only when there is > location update, also the host should have the option of not to send > location updates. > > ------------------------------- > > What about privacy? > > Response: User should have the option of not sending location updates. > User should also have the ability to set location to all zeros, in this > case no router will modify the location field and user loses the > location-based services. > > If its router-to-router link, then no need to be worried about privacy as > such information usually configured on a separate network. > > -------------------------------- > > a good alternative would be to create application layer protocols that > could request and send GPS positions > > Response: the layer-7 location request will not be detected by layer-3 > devices (Routers), I am assuming that in the future, GPS capability will > be added to the router itself (just like smart phones), features like > packet marking and classification based on geo-location will be required > to enforce the new geo-location policies. > > -------------------------------- > > For location-based routing protocols: Why would you want this? > Geographical location isn't actually that important a metric for routing; > what you care about there is *topological* location, how far I am away > from you in terms of hops or latency > > Response: For shortest path maybe yes, hops or latency is important, not > for policy-based routing, in our case you might want to do location-based > routing, like, routing traffic coming from French speaking users (in > multi-language country like Canada) to google.fr > > --------------------------------- > > For geolocation-based ACLs: you have the problem that if the geolocation > is attached by the endpoint, then it can't be trusted, since the endpoint > would lie to get past the ACL. If it's attached by a router, the ACL > needs to have proof that the router attached it (and not the endpoint), > which means that you would need a signed geolocation header > > Response: You could have the router modify the location field anyways, > just like L3 QoS fields, if you don't trust the host, so no need for > encryption or security, additionally, ACL is not only for security, it > could be used for routing, QoS ..etc, so the host will not always has the > motivation to manipulate the location field. > > --------------------------------- > > Why cant you simply implement rules related to geo-locations statically > on the network device (router, firewall .. etc)? > > Response: To enforce new geo-location policies automatically, lets assume > that a mobile router (like a mobile BTS in a GSM network) moved from > city-x to city-y, and according to city-x regulations VoIP calls over GSM > network is allowed, but city-y regulations do not allow that. Now the > topology may reflect same network metrics in both cities but there is no > rule that triggers configuration change based on geo-location. > > > --------------------------------- > > > > What do you think? > > > Author/Contact Information: > > Ammar J. Salih > Baghdad, Iraq > > Phone: +964 770 533 0306 > Email: ammar.alsalih@gmail.com > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > ---------------------------------------------------- > The ignorance of how to use new knowledge stockpiles exponentially. > - Marshall McLuhan > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv From rbarnes@bbn.com Tue Nov 20 12:13:01 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769CE21F87F7; Tue, 20 Nov 2012 12:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.676 X-Spam-Level: X-Spam-Status: No, score=-106.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AAzY--TeHUT; Tue, 20 Nov 2012 12:13:00 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 04C0221F8765; Tue, 20 Nov 2012 12:12:59 -0800 (PST) Received: from [128.89.253.219] (port=50226) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TauBj-0009gu-KP; Tue, 20 Nov 2012 15:12:55 -0500 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" X-Priority: 3 In-Reply-To: Date: Tue, 20 Nov 2012 15:12:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4D7DF3B7-F749-44B6-A60B-3E804037F47B@bbn.com> References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com><8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com><50a8f5db.04c0440a.320d.5d9e@mx.google.com> <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> To: "Carl Reed" X-Mailer: Apple Mail (2.1499) Cc: geopriv@ietf.org, ipv6@ietf.org, Ammar Salih , "'Fred Baker \(fred\)'" Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 20:13:01 -0000 References for DHCP location: If I understand the proposal correctly, this is an orthogonal problem to = the one DHCP location solves. DHCP geolocation sends location from the DHCP server to the end host. = This IPv6 option would send location from a host to the destination of a = packet (e.g., a server) and intermediate routers. On Nov 20, 2012, at 2:52 PM, "Carl Reed" = wrote: > Hi - >=20 > I asked this question before and did not get a response (maybe because = my question was off base). >=20 > There is a location extension for DHCP. This extension is consistent = with other location object definitions used in the IETF as well as what = is used and specified in various ISO, OGC, OASIS and other standards. >=20 > Why not use the DHCP location extension? Why define yet another = location element for IPv6? >=20 > Thanks >=20 > Carl Reed, PhD > CTO > OGC >=20 >=20 > -----Original Message----- From: Richard L. Barnes > Sent: Tuesday, November 20, 2012 11:49 AM > To: Ammar Salih > Cc: geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' > Subject: Re: [Geopriv] Adding GPS location to IPv6 header >=20 > Hi Ammar, >=20 > I have read your draft. =46rom what I can tell, it is just a summary = of the arguments in this thread. It would be more helpful if you could = add a level of technical detail to help people understand. I would want = to see at least: > 1. The format of the IPv6 option > 2. Where it is to be added to / removed from a packet > 3. Requirements for routers / hosts > 4. Privacy considerations > 5. Security considerations >=20 > Also, it will be slightly easier to read if you use some of the = standard tools for authoring Internet drafts. See, for example: > >=20 > Technically speaking, I'm not yet convinced that this option is very = useful, but it does not seem to me that this option would be harmful to = the network, only possibly the privacy of users. In specifying the = privacy mechanisms in your detailed description, I would suggest that = you make this mechanism "opt-in" by end hosts. For example, you could = have an all-zero geolocation option indicate that a host wishes to = disclose its location, but doesn't know its geolocation to put in the = option; then you could require that a router SHOULD NOT populate this = option unless an all-zero geolocation option is already present = (indicating consent). >=20 > It would also be helpful to clarify how this option would relate to = other similar options, such as the line identifier option: > >=20 > Hope this helps, > --Richard >=20 >=20 >=20 >=20 > On Nov 18, 2012, at 9:51 AM, Ammar Salih = wrote: >=20 >> Hello Fred, >>=20 >>=20 >> You may certainly file an internet draft with your ideas. You will = want to read about what an Internet Draft is and how to file one. = http://www.ietf.org/id-info/ >>=20 >> Filing an Internet Draft does not imply consensus around the = specification, and you will need to build that consensus. You will want = to make your case, and I would suggest starting on the geopriv mailing = list, although the case will eventually have to be made to 6man. = http://datatracker.ietf.org/wg/geopriv/charter/. >>=20 >> Appreciate it, the first draft has been submitted already = http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include= _text=3D1 >>=20 >>=20 >> One consideration you should take in view is that the IPv6 header is = not encrypted, so information found in it is globally readable. If there = is ever a case in which your GPS location is needed by the application = but may need to be guarded for privacy reasons, you will want to put it = in the application layer (above the transport, guarded by IPsec or TLS), = not the network layer. >>=20 >> I have suggested few solutions to cover the privacy concern and also = why I am suggesting the network layer instead of the application layer, = you could find them included in the internet draft above. >>=20 >>=20 >> I would expect that 6man might tell you that the IPv6 header has one = primary purpose, which is to conduct a datagram from the sender's system = to the intended receiver's system; if the data doesn't help achieve = that, it's probably in the wrong header. >>=20 >> I agree, also from OSI perspective, I would think twice before = including location field into network layer, then again, it=92s the only = layer that makes the field useable to routers. >>=20 >>=20 >>=20 >> Thanks, >>=20 >> Ammar >>=20 >>=20 >>=20 >> From: Fred Baker (fred) [mailto:fred@cisco.com] >> Sent: Friday, November 16, 2012 6:05 AM >> To: Ammar Salih >> Cc: ; >> Subject: Re: Adding GPS location to IPv6 header >>=20 >> You may certainly file an internet draft with your ideas. You will = want to read about what an Internet Draft is and how to file one. = http://www.ietf.org/id-info/ >>=20 >> Filing an Internet Draft does not imply consensus around the = specification, and you will need to build that consensus. You will want = to make your case, and I would suggest starting on the geopriv mailing = list, although the case will eventually have to be made to 6man. = http://datatracker.ietf.org/wg/geopriv/charter/. >>=20 >> One consideration you should take in view is that the IPv6 header is = not encrypted, so information found in it is globally readable. If there = is ever a case in which your GPS location is needed by the application = but may need to be guarded for privacy reasons, you will want to put it = in the application layer (above the transport, guarded by IPsec or TLS), = not the network layer. In fact, I would expect that 6man might tell you = that the IPv6 header has one primary purpose, which is to conduct a = datagram from the sender's system to the intended receiver's system; if = the data doesn't help achieve that, it's probably in the wrong header. >>=20 >> On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: >>=20 >>=20 >> Hello IETF, based on my discussions with both ipv6 and geopriv teams, = I=92ve written the below document to summarize few ideas. >>=20 >> Is it possible to publish this on IETF website? even if it will not = be implemented now, at least for documentation and requesting feedback = from the community. >>=20 >>=20 >>=20 >> Many thanks. >>=20 >> Ammar >>=20 >>=20 >>=20 >>=20 >>=20 >> Ammar J. Salih >> Baghdad, Iraq >> October 30, 2012 >> Title: IP-LOC >>=20 >>=20 >>=20 >> Adding GPS location to IPv6 header >>=20 >> Abstract: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> This document describes IP-LOC, an extension to IPv6 header which = suggests adding GPS coordinates, as the current method of determining = the location of IP traffic is through IP address registration database, = which is not very accurate as it depends on how the ISP registers its IP = subnets, that is normally done in a country/city format. >>=20 >> It also assumes that in the future, GPS capability will be added to = the router itself (just like smart phones) and packet marking and = classification based on geo-location will be required. >>=20 >> QoS, firewall and routing based on geo-location will be highly = required when mobile routers move from one geo-location to another which = has different policy. >>=20 >>=20 >>=20 >>=20 >>=20 >> Benefits of adding GPS location to IPv6 header (IP-LOC) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >>=20 >>=20 >> Web Services: getting more accurate locations will enhance many = services provided by the web, like targeted commercials (for example, I = can get Ads regarding restaurants available in my neighborhoods instead = of all restaurants in the city), another good example would be webpage=92s= language, my language will be detected more accurately based on my area = rather than my country, as there are many countries with more than one = popular language, not mentioning that many ip registrations does not = even reflect the traffic originating country. >>=20 >> ------------------------------- >>=20 >> Information accuracy and control: Nowadays, locations are assigned to = IP addresses without user awareness or control, every time a user = performs ip-lookup query the response would be different based on how = the ISP has registered this IP subnet, IP-LOC suggests making locations = more accurate and controllable through OS and network devices, exactly = like IP addresses (user can change his/her IP address, but router can = also modify the header information - in case it's required). >>=20 >> ------------------------------- >>=20 >>=20 >> Routing: Policy based routing, based on geo-location, like routing = predefined traffic through certain server or path, for different = purposes (security, manageability, serviceability like choosing = language, or routing traffic to specific cashing or proxy server based = on country .. etc) >>=20 >> ------------------------------- >>=20 >>=20 >> Copyright law: It happens when certain media/web content is not = allowed in certain countries due to copyright law, the current method of = determining locations is not accurate at all, on other hand, If layer-7 = application to be used then the user might be able to manipulate the = location field, in this case (if it=92s required in future) the ISP can = tag traffic with country/city more accurately as traffic passes through = ISP=92s boarder routers. >>=20 >> ------------------------------- >>=20 >> Maps, navigation, emergency calls and many other services will be = also enhanced with accurate locations. >>=20 >>=20 >>=20 >>=20 >>=20 >> CURRENT ARGUMENTS AGAINST THIS IDEA: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> =93Adding GPS position to every IPv6 header would add a lot of = overhead=94 >>=20 >> Response: It does not have to be in every IPv6 header, only when = there is location update, also the host should have the option of not to = send location updates. >>=20 >> ------------------------------- >>=20 >> =93What about privacy?=94 >>=20 >> Response: User should have the option of not sending location = updates. User should also have the ability to set location to all zeros, = in this case no router will modify the location field and user loses the = location-based services. >>=20 >> If it=92s router-to-router link, then no need to be worried about = privacy as such information usually configured on a separate network. >>=20 >> -------------------------------- >>=20 >> =93a good alternative would be to create application layer protocols = that could request and send GPS positions=94 >>=20 >> Response: the layer-7 location request will not be detected by = layer-3 devices (Routers), I am assuming that in the future, GPS = capability will be added to the router itself (just like smart phones), = features like packet marking and classification based on geo-location = will be required to enforce the new geo-location policies. >>=20 >> -------------------------------- >>=20 >> =93For location-based routing protocols: Why would you want this? = Geographical location isn't actually that important a metric for = routing; what you care about there is *topological* location, how far I = am away from you in terms of hops or latency=94 >>=20 >> Response: For shortest path maybe yes, hops or latency is important, = not for policy-based routing, in our case you might want to do = location-based routing, like, routing traffic coming from French = speaking users (in multi-language country like Canada) to google.fr >>=20 >> --------------------------------- >>=20 >> =93For geolocation-based ACLs: you have the problem that if the = geolocation is attached by the endpoint, then it can't be trusted, since = the endpoint would lie to get past the ACL. If it's attached by a = router, the ACL needs to have proof that the router attached it (and not = the endpoint), which means that you would need a signed geolocation = header=94 >>=20 >> Response: You could have the router modify the location field = anyways, just like L3 QoS fields, if you don't trust the host, so no = need for encryption or security, additionally, ACL is not only for = security, it could be used for routing, QoS ..etc, so the host will not = always has the motivation to manipulate the location field. >>=20 >> --------------------------------- >>=20 >> =93Why can=92t you simply implement rules related to geo-locations = statically on the network device (router, firewall .. etc)?=94 >>=20 >> Response: To enforce new geo-location policies automatically, let=92s = assume that a mobile router (like a mobile BTS in a GSM network) moved = from city-x to city-y, and according to city-x regulations VoIP calls = over GSM network is allowed, but city-y regulations do not allow that. = Now the topology may reflect same network metrics in both cities but = there is no rule that triggers configuration change based on = geo-location. >>=20 >>=20 >> --------------------------------- >>=20 >>=20 >>=20 >> What do you think? >>=20 >>=20 >> Author/Contact Information: >>=20 >> Ammar J. Salih >> Baghdad, Iraq >>=20 >> Phone: +964 770 533 0306 >> Email: ammar.alsalih@gmail.com >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >> ---------------------------------------------------- >> The ignorance of how to use new knowledge stockpiles exponentially. >> - Marshall McLuhan >>=20 >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv=20 From creed@opengeospatial.org Tue Nov 20 12:26:05 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D529721F867C; Tue, 20 Nov 2012 12:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.253 X-Spam-Level: X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, STOX_REPLY_TYPE=0.001, TVD_FINGER_02=2.134] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euuJayyCI1L5; Tue, 20 Nov 2012 12:26:04 -0800 (PST) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0F06E21F86D0; Tue, 20 Nov 2012 12:26:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 9DBDD9417F; Tue, 20 Nov 2012 15:26:03 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (scale.ogcinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdzJCm7mcwnH; Tue, 20 Nov 2012 15:26:01 -0500 (EST) Received: from OfficeHP (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail.opengeospatial.org (Postfix) with ESMTPSA id 090FD94181; Tue, 20 Nov 2012 15:26:00 -0500 (EST) Message-ID: <202EF1AE79AE413CAF7B9F24A3D08314@OfficeHP> From: "Carl Reed" To: "Richard L. Barnes" References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com><8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com><50a8f5db.04c0440a.320d.5d9e@mx.google.com> <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> <4D7DF3B7-F749-44B6-A60B-3E804037F47B@bbn.com> In-Reply-To: <4D7DF3B7-F749-44B6-A60B-3E804037F47B@bbn.com> Date: Tue, 20 Nov 2012 13:14:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Cc: geopriv@ietf.org, ipv6@ietf.org, Ammar Salih , "'Fred Baker \(fred\)'" Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 20:26:06 -0000 Gotcha - thanks! Carl -----Original Message----- From: Richard L. Barnes Sent: Tuesday, November 20, 2012 1:12 PM To: Carl Reed Cc: Ammar Salih ; geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' Subject: Re: [Geopriv] Adding GPS location to IPv6 header References for DHCP location: If I understand the proposal correctly, this is an orthogonal problem to the one DHCP location solves. DHCP geolocation sends location from the DHCP server to the end host. This IPv6 option would send location from a host to the destination of a packet (e.g., a server) and intermediate routers. On Nov 20, 2012, at 2:52 PM, "Carl Reed" wrote: > Hi - > > I asked this question before and did not get a response (maybe because my > question was off base). > > There is a location extension for DHCP. This extension is consistent with > other location object definitions used in the IETF as well as what is used > and specified in various ISO, OGC, OASIS and other standards. > > Why not use the DHCP location extension? Why define yet another location > element for IPv6? > > Thanks > > Carl Reed, PhD > CTO > OGC > > > -----Original Message----- From: Richard L. Barnes > Sent: Tuesday, November 20, 2012 11:49 AM > To: Ammar Salih > Cc: geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > Hi Ammar, > > I have read your draft. From what I can tell, it is just a summary of the > arguments in this thread. It would be more helpful if you could add a > level of technical detail to help people understand. I would want to see > at least: > 1. The format of the IPv6 option > 2. Where it is to be added to / removed from a packet > 3. Requirements for routers / hosts > 4. Privacy considerations > 5. Security considerations > > Also, it will be slightly easier to read if you use some of the standard > tools for authoring Internet drafts. See, for example: > > > Technically speaking, I'm not yet convinced that this option is very > useful, but it does not seem to me that this option would be harmful to > the network, only possibly the privacy of users. In specifying the > privacy mechanisms in your detailed description, I would suggest that you > make this mechanism "opt-in" by end hosts. For example, you could have an > all-zero geolocation option indicate that a host wishes to disclose its > location, but doesn't know its geolocation to put in the option; then you > could require that a router SHOULD NOT populate this option unless an > all-zero geolocation option is already present (indicating consent). > > It would also be helpful to clarify how this option would relate to other > similar options, such as the line identifier option: > > > Hope this helps, > --Richard > > > > > On Nov 18, 2012, at 9:51 AM, Ammar Salih wrote: > >> Hello Fred, >> >> >> You may certainly file an internet draft with your ideas. You will want >> to read about what an Internet Draft is and how to file one. >> http://www.ietf.org/id-info/ >> >> Filing an Internet Draft does not imply consensus around the >> specification, and you will need to build that consensus. You will want >> to make your case, and I would suggest starting on the geopriv mailing >> list, although the case will eventually have to be made to 6man. >> http://datatracker.ietf.org/wg/geopriv/charter/. >> >> Appreciate it, the first draft has been submitted already >> http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_text=1 >> >> >> One consideration you should take in view is that the IPv6 header is not >> encrypted, so information found in it is globally readable. If there is >> ever a case in which your GPS location is needed by the application but >> may need to be guarded for privacy reasons, you will want to put it in >> the application layer (above the transport, guarded by IPsec or TLS), not >> the network layer. >> >> I have suggested few solutions to cover the privacy concern and also why >> I am suggesting the network layer instead of the application layer, you >> could find them included in the internet draft above. >> >> >> I would expect that 6man might tell you that the IPv6 header has one >> primary purpose, which is to conduct a datagram from the sender's system >> to the intended receiver's system; if the data doesn't help achieve that, >> it's probably in the wrong header. >> >> I agree, also from OSI perspective, I would think twice before including >> location field into network layer, then again, its the only layer that >> makes the field useable to routers. >> >> >> >> Thanks, >> >> Ammar >> >> >> >> From: Fred Baker (fred) [mailto:fred@cisco.com] >> Sent: Friday, November 16, 2012 6:05 AM >> To: Ammar Salih >> Cc: ; >> Subject: Re: Adding GPS location to IPv6 header >> >> You may certainly file an internet draft with your ideas. You will want >> to read about what an Internet Draft is and how to file one. >> http://www.ietf.org/id-info/ >> >> Filing an Internet Draft does not imply consensus around the >> specification, and you will need to build that consensus. You will want >> to make your case, and I would suggest starting on the geopriv mailing >> list, although the case will eventually have to be made to 6man. >> http://datatracker.ietf.org/wg/geopriv/charter/. >> >> One consideration you should take in view is that the IPv6 header is not >> encrypted, so information found in it is globally readable. If there is >> ever a case in which your GPS location is needed by the application but >> may need to be guarded for privacy reasons, you will want to put it in >> the application layer (above the transport, guarded by IPsec or TLS), not >> the network layer. In fact, I would expect that 6man might tell you that >> the IPv6 header has one primary purpose, which is to conduct a datagram >> from the sender's system to the intended receiver's system; if the data >> doesn't help achieve that, it's probably in the wrong header. >> >> On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: >> >> >> Hello IETF, based on my discussions with both ipv6 and geopriv teams, Ive >> written the below document to summarize few ideas. >> >> Is it possible to publish this on IETF website? even if it will not be >> implemented now, at least for documentation and requesting feedback from >> the community. >> >> >> >> Many thanks. >> >> Ammar >> >> >> >> >> >> Ammar J. Salih >> Baghdad, Iraq >> October 30, 2012 >> Title: IP-LOC >> >> >> >> Adding GPS location to IPv6 header >> >> Abstract: >> ========= >> >> This document describes IP-LOC, an extension to IPv6 header which >> suggests adding GPS coordinates, as the current method of determining the >> location of IP traffic is through IP address registration database, which >> is not very accurate as it depends on how the ISP registers its IP >> subnets, that is normally done in a country/city format. >> >> It also assumes that in the future, GPS capability will be added to the >> router itself (just like smart phones) and packet marking and >> classification based on geo-location will be required. >> >> QoS, firewall and routing based on geo-location will be highly required >> when mobile routers move from one geo-location to another which has >> different policy. >> >> >> >> >> >> Benefits of adding GPS location to IPv6 header (IP-LOC) >> ======================================================= >> >> >> Web Services: getting more accurate locations will enhance many services >> provided by the web, like targeted commercials (for example, I can get >> Ads regarding restaurants available in my neighborhoods instead of all >> restaurants in the city), another good example would be webpages >> language, my language will be detected more accurately based on my area >> rather than my country, as there are many countries with more than one >> popular language, not mentioning that many ip registrations does not even >> reflect the traffic originating country. >> >> ------------------------------- >> >> Information accuracy and control: Nowadays, locations are assigned to IP >> addresses without user awareness or control, every time a user performs >> ip-lookup query the response would be different based on how the ISP has >> registered this IP subnet, IP-LOC suggests making locations more accurate >> and controllable through OS and network devices, exactly like IP >> addresses (user can change his/her IP address, but router can also modify >> the header information - in case it's required). >> >> ------------------------------- >> >> >> Routing: Policy based routing, based on geo-location, like routing >> predefined traffic through certain server or path, for different purposes >> (security, manageability, serviceability like choosing language, or >> routing traffic to specific cashing or proxy server based on country .. >> etc) >> >> ------------------------------- >> >> >> Copyright law: It happens when certain media/web content is not allowed >> in certain countries due to copyright law, the current method of >> determining locations is not accurate at all, on other hand, If layer-7 >> application to be used then the user might be able to manipulate the >> location field, in this case (if its required in future) the ISP can tag >> traffic with country/city more accurately as traffic passes through ISPs >> boarder routers. >> >> ------------------------------- >> >> Maps, navigation, emergency calls and many other services will be also >> enhanced with accurate locations. >> >> >> >> >> >> CURRENT ARGUMENTS AGAINST THIS IDEA: >> ======================================== >> >> Adding GPS position to every IPv6 header would add a lot of overhead >> >> Response: It does not have to be in every IPv6 header, only when there is >> location update, also the host should have the option of not to send >> location updates. >> >> ------------------------------- >> >> What about privacy? >> >> Response: User should have the option of not sending location updates. >> User should also have the ability to set location to all zeros, in this >> case no router will modify the location field and user loses the >> location-based services. >> >> If its router-to-router link, then no need to be worried about privacy >> as such information usually configured on a separate network. >> >> -------------------------------- >> >> a good alternative would be to create application layer protocols that >> could request and send GPS positions >> >> Response: the layer-7 location request will not be detected by layer-3 >> devices (Routers), I am assuming that in the future, GPS capability will >> be added to the router itself (just like smart phones), features like >> packet marking and classification based on geo-location will be required >> to enforce the new geo-location policies. >> >> -------------------------------- >> >> For location-based routing protocols: Why would you want this? >> Geographical location isn't actually that important a metric for routing; >> what you care about there is *topological* location, how far I am away >> from you in terms of hops or latency >> >> Response: For shortest path maybe yes, hops or latency is important, not >> for policy-based routing, in our case you might want to do location-based >> routing, like, routing traffic coming from French speaking users (in >> multi-language country like Canada) to google.fr >> >> --------------------------------- >> >> For geolocation-based ACLs: you have the problem that if the geolocation >> is attached by the endpoint, then it can't be trusted, since the endpoint >> would lie to get past the ACL. If it's attached by a router, the ACL >> needs to have proof that the router attached it (and not the endpoint), >> which means that you would need a signed geolocation header >> >> Response: You could have the router modify the location field anyways, >> just like L3 QoS fields, if you don't trust the host, so no need for >> encryption or security, additionally, ACL is not only for security, it >> could be used for routing, QoS ..etc, so the host will not always has the >> motivation to manipulate the location field. >> >> --------------------------------- >> >> Why cant you simply implement rules related to geo-locations statically >> on the network device (router, firewall .. etc)? >> >> Response: To enforce new geo-location policies automatically, lets >> assume that a mobile router (like a mobile BTS in a GSM network) moved >> from city-x to city-y, and according to city-x regulations VoIP calls >> over GSM network is allowed, but city-y regulations do not allow that. >> Now the topology may reflect same network metrics in both cities but >> there is no rule that triggers configuration change based on >> geo-location. >> >> >> --------------------------------- >> >> >> >> What do you think? >> >> >> Author/Contact Information: >> >> Ammar J. Salih >> Baghdad, Iraq >> >> Phone: +964 770 533 0306 >> Email: ammar.alsalih@gmail.com >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> ---------------------------------------------------- >> The ignorance of how to use new knowledge stockpiles exponentially. >> - Marshall McLuhan >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From jopicken@cisco.com Tue Nov 20 12:48:21 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1112421F87D5; Tue, 20 Nov 2012 12:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qRSrZ8zH4yb; Tue, 20 Nov 2012 12:48:19 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA0221F87B7; Tue, 20 Nov 2012 12:48:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15912; q=dns/txt; s=iport; t=1353444499; x=1354654099; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ztq4Mq1qa2NBMAAaLwIrAnQAe0QC1u/BF9lrzhKSRIc=; b=Fi54cHt8Q1xFpCMXbtipIPI/R1da9TgJJQ1Jfeby7/RK/DtdjaWIv3n4 Hl/KMzMNFCQxqqpOmiko01wz9GHisBnXEewC9JRsoT/ZJp7e8mwxOf0dc j8oBAD73F6hHpu3LKJPKeU2Q8T9OAYd8Sx4IqPtfBvkivesNnzqVKqWni U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHrrq1CtJXG//2dsb2JhbABCA8JbFnOCFwcBAQEDAQEBATcsCAsFBwICAgEIDgMEAQEBChQJBxsGBgsUCQgCBAENBQgBCweFLgeCKwMJBQELrlc8hl4NiVQEi0hpgUmCS2EDikuBAIhegnGFPYRZA4UMgm+BWwcCFx4 X-IronPort-AV: E=McAfee;i="5400,1158,6902"; a="144546247" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 20 Nov 2012 20:48:18 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAKKmIio025353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Nov 2012 20:48:18 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.196]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Tue, 20 Nov 2012 14:48:18 -0600 From: "John Pickens (jopicken)" To: Carl Reed , "Richard L. Barnes" Thread-Topic: [Geopriv] Adding GPS location to IPv6 header Thread-Index: Ac2/VMZri4Yb+IJ0QpqrzX+gy+wtKAEhLRsAAHAIoNAAeh94AAACLgyAAAC47QAAABFvgAALiJEg Date: Tue, 20 Nov 2012 20:48:17 +0000 Message-ID: References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com><8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com><50a8f5db.04c0440a.320d.5d9e@mx.google.com> <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> <4D7DF3B7-F749-44B6-A60B-3E804037F47B@bbn.com> <202EF1AE79AE413CAF7B9F24A3D08314@OfficeHP> In-Reply-To: <202EF1AE79AE413CAF7B9F24A3D08314@OfficeHP> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.51.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "geopriv@ietf.org" , Ammar Salih , "ipv6@ietf.org" , "Fred Baker \(fred\)" Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 20:48:21 -0000 I've been monitoring this thread. In the IETF the objective is to respect = privacy of correlation of IP address to location metadata. Essentially as= mentioned below the client device receives it in the extant protocols. Th= e consumer can provide authorization as to the granularity of location that= is visible to other entities. As to this schema mentioned below, embeddi= ng location info in packet headers is potentially exposing the location coo= rdinate to "snoopers". If encrypted, then.... =20 Thoughts of others? J -----Original Message----- From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf = Of Carl Reed Sent: Tuesday, November 20, 2012 12:15 PM To: Richard L. Barnes Cc: geopriv@ietf.org; ipv6@ietf.org; Ammar Salih; Fred Baker (fred) Subject: Re: [Geopriv] Adding GPS location to IPv6 header Gotcha - thanks! Carl -----Original Message----- From: Richard L. Barnes Sent: Tuesday, November 20, 2012 1:12 PM To: Carl Reed Cc: Ammar Salih ; geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' Subject: Re: [Geopriv] Adding GPS location to IPv6 header References for DHCP location: If I understand the proposal correctly, this is an orthogonal problem to th= e one DHCP location solves. DHCP geolocation sends location from the DHCP server to the end host. This IPv6 option would send location from a host to the destination of a packet = (e.g., a server) and intermediate routers. On Nov 20, 2012, at 2:52 PM, "Carl Reed" wrote: > Hi - > > I asked this question before and did not get a response (maybe because=20 > my question was off base). > > There is a location extension for DHCP. This extension is consistent=20 > with other location object definitions used in the IETF as well as=20 > what is used and specified in various ISO, OGC, OASIS and other standards= . > > Why not use the DHCP location extension? Why define yet another=20 > location element for IPv6? > > Thanks > > Carl Reed, PhD > CTO > OGC > > > -----Original Message----- From: Richard L. Barnes > Sent: Tuesday, November 20, 2012 11:49 AM > To: Ammar Salih > Cc: geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > Hi Ammar, > > I have read your draft. From what I can tell, it is just a summary of=20 > the arguments in this thread. It would be more helpful if you could=20 > add a level of technical detail to help people understand. I would=20 > want to see at least: > 1. The format of the IPv6 option > 2. Where it is to be added to / removed from a packet 3. Requirements=20 > for routers / hosts 4. Privacy considerations 5. Security=20 > considerations > > Also, it will be slightly easier to read if you use some of the=20 > standard tools for authoring Internet drafts. See, for example: > > > Technically speaking, I'm not yet convinced that this option is very=20 > useful, but it does not seem to me that this option would be harmful=20 > to the network, only possibly the privacy of users. In specifying the=20 > privacy mechanisms in your detailed description, I would suggest that=20 > you make this mechanism "opt-in" by end hosts. For example, you could=20 > have an all-zero geolocation option indicate that a host wishes to=20 > disclose its location, but doesn't know its geolocation to put in the=20 > option; then you could require that a router SHOULD NOT populate this=20 > option unless an all-zero geolocation option is already present (indicati= ng consent). > > It would also be helpful to clarify how this option would relate to=20 > other similar options, such as the line identifier option: > > > Hope this helps, > --Richard > > > > > On Nov 18, 2012, at 9:51 AM, Ammar Salih wrote: > >> Hello Fred, >> >> >> You may certainly file an internet draft with your ideas. You will=20 >> want to read about what an Internet Draft is and how to file one. >> http://www.ietf.org/id-info/ >> >> Filing an Internet Draft does not imply consensus around the=20 >> specification, and you will need to build that consensus. You will=20 >> want to make your case, and I would suggest starting on the geopriv=20 >> mailing list, although the case will eventually have to be made to 6man. >> http://datatracker.ietf.org/wg/geopriv/charter/. >> >> Appreciate it, the first draft has been submitted already >> http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?in >> clude_text=3D1 >> >> >> One consideration you should take in view is that the IPv6 header is=20 >> not encrypted, so information found in it is globally readable. If=20 >> there is ever a case in which your GPS location is needed by the=20 >> application but may need to be guarded for privacy reasons, you will=20 >> want to put it in the application layer (above the transport, guarded=20 >> by IPsec or TLS), not the network layer. >> >> I have suggested few solutions to cover the privacy concern and also=20 >> why I am suggesting the network layer instead of the application=20 >> layer, you could find them included in the internet draft above. >> >> >> I would expect that 6man might tell you that the IPv6 header has one=20 >> primary purpose, which is to conduct a datagram from the sender's=20 >> system to the intended receiver's system; if the data doesn't help=20 >> achieve that, it's probably in the wrong header. >> >> I agree, also from OSI perspective, I would think twice before=20 >> including location field into network layer, then again, it's the=20 >> only layer that makes the field useable to routers. >> >> >> >> Thanks, >> >> Ammar >> >> >> >> From: Fred Baker (fred) [mailto:fred@cisco.com] >> Sent: Friday, November 16, 2012 6:05 AM >> To: Ammar Salih >> Cc: ; >> Subject: Re: Adding GPS location to IPv6 header >> >> You may certainly file an internet draft with your ideas. You will=20 >> want to read about what an Internet Draft is and how to file one. >> http://www.ietf.org/id-info/ >> >> Filing an Internet Draft does not imply consensus around the=20 >> specification, and you will need to build that consensus. You will=20 >> want to make your case, and I would suggest starting on the geopriv=20 >> mailing list, although the case will eventually have to be made to 6man. >> http://datatracker.ietf.org/wg/geopriv/charter/. >> >> One consideration you should take in view is that the IPv6 header is=20 >> not encrypted, so information found in it is globally readable. If=20 >> there is ever a case in which your GPS location is needed by the=20 >> application but may need to be guarded for privacy reasons, you will=20 >> want to put it in the application layer (above the transport, guarded=20 >> by IPsec or TLS), not the network layer. In fact, I would expect that=20 >> 6man might tell you that the IPv6 header has one primary purpose,=20 >> which is to conduct a datagram from the sender's system to the=20 >> intended receiver's system; if the data doesn't help achieve that, it's = probably in the wrong header. >> >> On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: >> >> >> Hello IETF, based on my discussions with both ipv6 and geopriv teams,=20 >> I've written the below document to summarize few ideas. >> >> Is it possible to publish this on IETF website? even if it will not=20 >> be implemented now, at least for documentation and requesting=20 >> feedback from the community. >> >> >> >> Many thanks. >> >> Ammar >> >> >> >> >> >> Ammar J. Salih >> Baghdad, Iraq >> October 30, 2012 >> Title: IP-LOC >> >> >> >> Adding GPS location to IPv6 header >> >> Abstract: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> This document describes IP-LOC, an extension to IPv6 header which=20 >> suggests adding GPS coordinates, as the current method of determining=20 >> the location of IP traffic is through IP address registration=20 >> database, which is not very accurate as it depends on how the ISP=20 >> registers its IP subnets, that is normally done in a country/city format= . >> >> It also assumes that in the future, GPS capability will be added to=20 >> the router itself (just like smart phones) and packet marking and=20 >> classification based on geo-location will be required. >> >> QoS, firewall and routing based on geo-location will be highly=20 >> required when mobile routers move from one geo-location to another=20 >> which has different policy. >> >> >> >> >> >> Benefits of adding GPS location to IPv6 header (IP-LOC)=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> >> >> Web Services: getting more accurate locations will enhance many=20 >> services provided by the web, like targeted commercials (for example,=20 >> I can get Ads regarding restaurants available in my neighborhoods=20 >> instead of all restaurants in the city), another good example would=20 >> be webpage's language, my language will be detected more accurately=20 >> based on my area rather than my country, as there are many countries=20 >> with more than one popular language, not mentioning that many ip=20 >> registrations does not even reflect the traffic originating country. >> >> ------------------------------- >> >> Information accuracy and control: Nowadays, locations are assigned to=20 >> IP addresses without user awareness or control, every time a user=20 >> performs ip-lookup query the response would be different based on how=20 >> the ISP has registered this IP subnet, IP-LOC suggests making=20 >> locations more accurate and controllable through OS and network=20 >> devices, exactly like IP addresses (user can change his/her IP=20 >> address, but router can also modify the header information - in case it'= s required). >> >> ------------------------------- >> >> >> Routing: Policy based routing, based on geo-location, like routing=20 >> predefined traffic through certain server or path, for different=20 >> purposes (security, manageability, serviceability like choosing=20 >> language, or routing traffic to specific cashing or proxy server based o= n country .. >> etc) >> >> ------------------------------- >> >> >> Copyright law: It happens when certain media/web content is not=20 >> allowed in certain countries due to copyright law, the current method=20 >> of determining locations is not accurate at all, on other hand, If=20 >> layer-7 application to be used then the user might be able to=20 >> manipulate the location field, in this case (if it's required in=20 >> future) the ISP can tag traffic with country/city more accurately as=20 >> traffic passes through ISP's boarder routers. >> >> ------------------------------- >> >> Maps, navigation, emergency calls and many other services will be=20 >> also enhanced with accurate locations. >> >> >> >> >> >> CURRENT ARGUMENTS AGAINST THIS IDEA: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> "Adding GPS position to every IPv6 header would add a lot of overhead" >> >> Response: It does not have to be in every IPv6 header, only when=20 >> there is location update, also the host should have the option of not=20 >> to send location updates. >> >> ------------------------------- >> >> "What about privacy?" >> >> Response: User should have the option of not sending location updates.=20 >> User should also have the ability to set location to all zeros, in=20 >> this case no router will modify the location field and user loses the=20 >> location-based services. >> >> If it's router-to-router link, then no need to be worried about=20 >> privacy as such information usually configured on a separate network. >> >> -------------------------------- >> >> "a good alternative would be to create application layer protocols=20 >> that could request and send GPS positions" >> >> Response: the layer-7 location request will not be detected by=20 >> layer-3 devices (Routers), I am assuming that in the future, GPS=20 >> capability will be added to the router itself (just like smart=20 >> phones), features like packet marking and classification based on=20 >> geo-location will be required to enforce the new geo-location policies. >> >> -------------------------------- >> >> "For location-based routing protocols: Why would you want this?=20 >> Geographical location isn't actually that important a metric for=20 >> routing; what you care about there is *topological* location, how far=20 >> I am away from you in terms of hops or latency" >> >> Response: For shortest path maybe yes, hops or latency is important,=20 >> not for policy-based routing, in our case you might want to do=20 >> location-based routing, like, routing traffic coming from French=20 >> speaking users (in multi-language country like Canada) to google.fr >> >> --------------------------------- >> >> "For geolocation-based ACLs: you have the problem that if the=20 >> geolocation is attached by the endpoint, then it can't be trusted,=20 >> since the endpoint would lie to get past the ACL. If it's attached=20 >> by a router, the ACL needs to have proof that the router attached it=20 >> (and not the endpoint), which means that you would need a signed geoloca= tion header" >> >> Response: You could have the router modify the location field=20 >> anyways, just like L3 QoS fields, if you don't trust the host, so no=20 >> need for encryption or security, additionally, ACL is not only for=20 >> security, it could be used for routing, QoS ..etc, so the host will=20 >> not always has the motivation to manipulate the location field. >> >> --------------------------------- >> >> "Why can't you simply implement rules related to geo-locations=20 >> statically on the network device (router, firewall .. etc)?" >> >> Response: To enforce new geo-location policies automatically, let's=20 >> assume that a mobile router (like a mobile BTS in a GSM network)=20 >> moved from city-x to city-y, and according to city-x regulations VoIP=20 >> calls over GSM network is allowed, but city-y regulations do not allow t= hat. >> Now the topology may reflect same network metrics in both cities but=20 >> there is no rule that triggers configuration change based on=20 >> geo-location. >> >> >> --------------------------------- >> >> >> >> What do you think? >> >> >> Author/Contact Information: >> >> Ammar J. Salih >> Baghdad, Iraq >> >> Phone: +964 770 533 0306 >> Email: ammar.alsalih@gmail.com >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> ---------------------------------------------------- >> The ignorance of how to use new knowledge stockpiles exponentially. >> - Marshall McLuhan >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv From ammar.salih@auis.edu.iq Tue Nov 20 14:03:22 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0301C21F874B for ; Tue, 20 Nov 2012 14:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34tqYWgCemhz for ; Tue, 20 Nov 2012 14:03:20 -0800 (PST) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with SMTP id EB6E821F873F for ; Tue, 20 Nov 2012 14:03:19 -0800 (PST) Received: from mail-ee0-f70.google.com ([74.125.83.70]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKUKv+J+HxKFUgaCJJWUYJePbB9RGF6WhB@postini.com; Tue, 20 Nov 2012 14:03:20 PST Received: by mail-ee0-f70.google.com with SMTP id l10so6161582eei.1 for ; Tue, 20 Nov 2012 14:03:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=KoNZmXUd8o5pcH2nGr2oxUeq8A9oNze+BcPzh8JMOr0=; b=AKzgS/INLIrbHL5LUFB+Y7pip6G45VRoUTRdh4AUPl6l2tnWeKi+HznDGnCZFwEmJd JY2ZqUVQD9dD1eQi9sw8Ix4bCNdZcB16RgjXxtciC7aPLFq8kwZ7mSuww7fcLfqtBq86 qa7fyhkYb1xAPMAP7ylAf8o6VviiY0dBZqv9YCDdSdko6Krr6TV4UIId0lHdP8kOsIc/ SWqZigXlViskbc6iEAJvNLTnW4maFBs1xO9cddr155k6j3Rjr+NQ9BHVLHcMGL4mxvhd kRqxlcza8/lokvWTkt1vp6ZJ1m1hMs91QppBqJeI7n4KFlsX68RFAxyQGEkLI13tppLO +0hQ== Received: by 10.14.194.72 with SMTP id l48mr38138472een.9.1353448997968; Tue, 20 Nov 2012 14:03:17 -0800 (PST) Received: by 10.14.194.72 with SMTP id l48mr38138455een.9.1353448997845; Tue, 20 Nov 2012 14:03:17 -0800 (PST) Received: from AMMARSALIH ([95.159.78.43]) by mx.google.com with ESMTPS id k2sm33083026eep.15.2012.11.20.14.03.09 (version=SSLv3 cipher=OTHER); Tue, 20 Nov 2012 14:03:13 -0800 (PST) From: "Ammar Salih" To: "'John Pickens \(jopicken\)'" References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com><8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com><50a8f5db.04c0440a.320d.5d9e@mx.google.com> <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> <4D7DF3B7-F749-44B6-A60B-3E804037F47B@bbn.com> <202EF1AE79AE413CAF7B9F24A3D08314@OfficeHP> In-Reply-To: Date: Wed, 21 Nov 2012 01:03:06 +0300 Message-ID: <50abfe21.82da0e0a.5c65.ffff96d7@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2/VMZri4Yb+IJ0QpqrzX+gy+wtKAEhLRsAAHAIoNAAeh94AAACLgyAAAC47QAAABFvgAALiJEgABU7kzA= Content-Language: en-us X-Gm-Message-State: ALoCoQk7KrIZHIHy2fYUQ9hM/9HWx0zJl9nRhUC3KszFcwMR/4JMZHdu/2YTNHF0BFDy04B6KmImzOnpedBEgr4lPw5hqgEyS9wmycslxRF8w8SxSZGW2OO/wYO1ma8qv2zqH0NYWTuSZQAbPsBBb0166zgCQC4NZQ== Cc: geopriv@ietf.org, ipv6@ietf.org, "'Fred Baker \(fred\)'" Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 22:03:22 -0000 > As to this schema mentioned below, embedding location info in packet headers is potentially exposing the location coordinate to "snoopers Ok, I would like to shed some light regarding privacy issue: First, user should have the option of not sending location updates. Second, user will be routed through an ISP, if we don't trust the ISP then I can assure you that ISP can get much more information than physical location, any un-encrypted traffic -which is the majority- can be analyzed at the ISP level (up to layer-7). Other than ISP, the sniffer could be connected to the same layer-2/layer-3 device as mine, in this case I would worry about usernames/passwords/accounts/files/keys/pictures/messages .. etc, but not location as the sniffer in this case is mostly sitting at the same physical location as mine. Thanks Ammar -----Original Message----- From: John Pickens (jopicken) [mailto:jopicken@cisco.com] Sent: Tuesday, November 20, 2012 11:48 PM To: Carl Reed; Richard L. Barnes Cc: geopriv@ietf.org; ipv6@ietf.org; Ammar Salih; Fred Baker (fred) Subject: RE: [Geopriv] Adding GPS location to IPv6 header I've been monitoring this thread. In the IETF the objective is to respect privacy of correlation of IP address to location metadata. Essentially as mentioned below the client device receives it in the extant protocols. The consumer can provide authorization as to the granularity of location that is visible to other entities. As to this schema mentioned below, embedding location info in packet headers is potentially exposing the location coordinate to "snoopers". If encrypted, then.... Thoughts of others? J -----Original Message----- From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Carl Reed Sent: Tuesday, November 20, 2012 12:15 PM To: Richard L. Barnes Cc: geopriv@ietf.org; ipv6@ietf.org; Ammar Salih; Fred Baker (fred) Subject: Re: [Geopriv] Adding GPS location to IPv6 header Gotcha - thanks! Carl -----Original Message----- From: Richard L. Barnes Sent: Tuesday, November 20, 2012 1:12 PM To: Carl Reed Cc: Ammar Salih ; geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' Subject: Re: [Geopriv] Adding GPS location to IPv6 header References for DHCP location: If I understand the proposal correctly, this is an orthogonal problem to the one DHCP location solves. DHCP geolocation sends location from the DHCP server to the end host. This IPv6 option would send location from a host to the destination of a packet (e.g., a server) and intermediate routers. On Nov 20, 2012, at 2:52 PM, "Carl Reed" wrote: > Hi - > > I asked this question before and did not get a response (maybe because > my question was off base). > > There is a location extension for DHCP. This extension is consistent > with other location object definitions used in the IETF as well as > what is used and specified in various ISO, OGC, OASIS and other standards. > > Why not use the DHCP location extension? Why define yet another > location element for IPv6? > > Thanks > > Carl Reed, PhD > CTO > OGC > > > -----Original Message----- From: Richard L. Barnes > Sent: Tuesday, November 20, 2012 11:49 AM > To: Ammar Salih > Cc: geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > Hi Ammar, > > I have read your draft. From what I can tell, it is just a summary of > the arguments in this thread. It would be more helpful if you could > add a level of technical detail to help people understand. I would > want to see at least: > 1. The format of the IPv6 option > 2. Where it is to be added to / removed from a packet 3. Requirements > for routers / hosts 4. Privacy considerations 5. Security > considerations > > Also, it will be slightly easier to read if you use some of the > standard tools for authoring Internet drafts. See, for example: > > > Technically speaking, I'm not yet convinced that this option is very > useful, but it does not seem to me that this option would be harmful > to the network, only possibly the privacy of users. In specifying the > privacy mechanisms in your detailed description, I would suggest that > you make this mechanism "opt-in" by end hosts. For example, you could > have an all-zero geolocation option indicate that a host wishes to > disclose its location, but doesn't know its geolocation to put in the > option; then you could require that a router SHOULD NOT populate this > option unless an all-zero geolocation option is already present (indicating consent). > > It would also be helpful to clarify how this option would relate to > other similar options, such as the line identifier option: > > > Hope this helps, > --Richard > > > > > On Nov 18, 2012, at 9:51 AM, Ammar Salih wrote: > >> Hello Fred, >> >> >> You may certainly file an internet draft with your ideas. You will >> want to read about what an Internet Draft is and how to file one. >> http://www.ietf.org/id-info/ >> >> Filing an Internet Draft does not imply consensus around the >> specification, and you will need to build that consensus. You will >> want to make your case, and I would suggest starting on the geopriv >> mailing list, although the case will eventually have to be made to 6man. >> http://datatracker.ietf.org/wg/geopriv/charter/. >> >> Appreciate it, the first draft has been submitted already >> http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?in >> clude_text=1 >> >> >> One consideration you should take in view is that the IPv6 header is >> not encrypted, so information found in it is globally readable. If >> there is ever a case in which your GPS location is needed by the >> application but may need to be guarded for privacy reasons, you will >> want to put it in the application layer (above the transport, guarded >> by IPsec or TLS), not the network layer. >> >> I have suggested few solutions to cover the privacy concern and also >> why I am suggesting the network layer instead of the application >> layer, you could find them included in the internet draft above. >> >> >> I would expect that 6man might tell you that the IPv6 header has one >> primary purpose, which is to conduct a datagram from the sender's >> system to the intended receiver's system; if the data doesn't help >> achieve that, it's probably in the wrong header. >> >> I agree, also from OSI perspective, I would think twice before >> including location field into network layer, then again, it's the >> only layer that makes the field useable to routers. >> >> >> >> Thanks, >> >> Ammar >> >> >> >> From: Fred Baker (fred) [mailto:fred@cisco.com] >> Sent: Friday, November 16, 2012 6:05 AM >> To: Ammar Salih >> Cc: ; >> Subject: Re: Adding GPS location to IPv6 header >> >> You may certainly file an internet draft with your ideas. You will >> want to read about what an Internet Draft is and how to file one. >> http://www.ietf.org/id-info/ >> >> Filing an Internet Draft does not imply consensus around the >> specification, and you will need to build that consensus. You will >> want to make your case, and I would suggest starting on the geopriv >> mailing list, although the case will eventually have to be made to 6man. >> http://datatracker.ietf.org/wg/geopriv/charter/. >> >> One consideration you should take in view is that the IPv6 header is >> not encrypted, so information found in it is globally readable. If >> there is ever a case in which your GPS location is needed by the >> application but may need to be guarded for privacy reasons, you will >> want to put it in the application layer (above the transport, guarded >> by IPsec or TLS), not the network layer. In fact, I would expect that >> 6man might tell you that the IPv6 header has one primary purpose, >> which is to conduct a datagram from the sender's system to the >> intended receiver's system; if the data doesn't help achieve that, it's probably in the wrong header. >> >> On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: >> >> >> Hello IETF, based on my discussions with both ipv6 and geopriv teams, >> I've written the below document to summarize few ideas. >> >> Is it possible to publish this on IETF website? even if it will not >> be implemented now, at least for documentation and requesting >> feedback from the community. >> >> >> >> Many thanks. >> >> Ammar >> >> >> >> >> >> Ammar J. Salih >> Baghdad, Iraq >> October 30, 2012 >> Title: IP-LOC >> >> >> >> Adding GPS location to IPv6 header >> >> Abstract: >> ========= >> >> This document describes IP-LOC, an extension to IPv6 header which >> suggests adding GPS coordinates, as the current method of determining >> the location of IP traffic is through IP address registration >> database, which is not very accurate as it depends on how the ISP >> registers its IP subnets, that is normally done in a country/city format. >> >> It also assumes that in the future, GPS capability will be added to >> the router itself (just like smart phones) and packet marking and >> classification based on geo-location will be required. >> >> QoS, firewall and routing based on geo-location will be highly >> required when mobile routers move from one geo-location to another >> which has different policy. >> >> >> >> >> >> Benefits of adding GPS location to IPv6 header (IP-LOC) >> ======================================================= >> >> >> Web Services: getting more accurate locations will enhance many >> services provided by the web, like targeted commercials (for example, >> I can get Ads regarding restaurants available in my neighborhoods >> instead of all restaurants in the city), another good example would >> be webpage's language, my language will be detected more accurately >> based on my area rather than my country, as there are many countries >> with more than one popular language, not mentioning that many ip >> registrations does not even reflect the traffic originating country. >> >> ------------------------------- >> >> Information accuracy and control: Nowadays, locations are assigned to >> IP addresses without user awareness or control, every time a user >> performs ip-lookup query the response would be different based on how >> the ISP has registered this IP subnet, IP-LOC suggests making >> locations more accurate and controllable through OS and network >> devices, exactly like IP addresses (user can change his/her IP >> address, but router can also modify the header information - in case it's required). >> >> ------------------------------- >> >> >> Routing: Policy based routing, based on geo-location, like routing >> predefined traffic through certain server or path, for different >> purposes (security, manageability, serviceability like choosing >> language, or routing traffic to specific cashing or proxy server based on country .. >> etc) >> >> ------------------------------- >> >> >> Copyright law: It happens when certain media/web content is not >> allowed in certain countries due to copyright law, the current method >> of determining locations is not accurate at all, on other hand, If >> layer-7 application to be used then the user might be able to >> manipulate the location field, in this case (if it's required in >> future) the ISP can tag traffic with country/city more accurately as >> traffic passes through ISP's boarder routers. >> >> ------------------------------- >> >> Maps, navigation, emergency calls and many other services will be >> also enhanced with accurate locations. >> >> >> >> >> >> CURRENT ARGUMENTS AGAINST THIS IDEA: >> ======================================== >> >> "Adding GPS position to every IPv6 header would add a lot of overhead" >> >> Response: It does not have to be in every IPv6 header, only when >> there is location update, also the host should have the option of not >> to send location updates. >> >> ------------------------------- >> >> "What about privacy?" >> >> Response: User should have the option of not sending location updates. >> User should also have the ability to set location to all zeros, in >> this case no router will modify the location field and user loses the >> location-based services. >> >> If it's router-to-router link, then no need to be worried about >> privacy as such information usually configured on a separate network. >> >> -------------------------------- >> >> "a good alternative would be to create application layer protocols >> that could request and send GPS positions" >> >> Response: the layer-7 location request will not be detected by >> layer-3 devices (Routers), I am assuming that in the future, GPS >> capability will be added to the router itself (just like smart >> phones), features like packet marking and classification based on >> geo-location will be required to enforce the new geo-location policies. >> >> -------------------------------- >> >> "For location-based routing protocols: Why would you want this? >> Geographical location isn't actually that important a metric for >> routing; what you care about there is *topological* location, how far >> I am away from you in terms of hops or latency" >> >> Response: For shortest path maybe yes, hops or latency is important, >> not for policy-based routing, in our case you might want to do >> location-based routing, like, routing traffic coming from French >> speaking users (in multi-language country like Canada) to google.fr >> >> --------------------------------- >> >> "For geolocation-based ACLs: you have the problem that if the >> geolocation is attached by the endpoint, then it can't be trusted, >> since the endpoint would lie to get past the ACL. If it's attached >> by a router, the ACL needs to have proof that the router attached it >> (and not the endpoint), which means that you would need a signed geolocation header" >> >> Response: You could have the router modify the location field >> anyways, just like L3 QoS fields, if you don't trust the host, so no >> need for encryption or security, additionally, ACL is not only for >> security, it could be used for routing, QoS ..etc, so the host will >> not always has the motivation to manipulate the location field. >> >> --------------------------------- >> >> "Why can't you simply implement rules related to geo-locations >> statically on the network device (router, firewall .. etc)?" >> >> Response: To enforce new geo-location policies automatically, let's >> assume that a mobile router (like a mobile BTS in a GSM network) >> moved from city-x to city-y, and according to city-x regulations VoIP >> calls over GSM network is allowed, but city-y regulations do not allow that. >> Now the topology may reflect same network metrics in both cities but >> there is no rule that triggers configuration change based on >> geo-location. >> >> >> --------------------------------- >> >> >> >> What do you think? >> >> >> Author/Contact Information: >> >> Ammar J. Salih >> Baghdad, Iraq >> >> Phone: +964 770 533 0306 >> Email: ammar.alsalih@gmail.com >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> ---------------------------------------------------- >> The ignorance of how to use new knowledge stockpiles exponentially. >> - Marshall McLuhan >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv From ammar.salih@auis.edu.iq Tue Nov 20 14:18:37 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6592121F8821 for ; Tue, 20 Nov 2012 14:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEjckRwEG+VZ for ; Tue, 20 Nov 2012 14:18:35 -0800 (PST) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with SMTP id 3F4E421F8815 for ; Tue, 20 Nov 2012 14:18:34 -0800 (PST) Received: from mail-ee0-f70.google.com ([74.125.83.70]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKUKwBusMqIz7uldECNMDBi7WCU6QMmroH@postini.com; Tue, 20 Nov 2012 14:18:35 PST Received: by mail-ee0-f70.google.com with SMTP id l10so6171483eei.1 for ; Tue, 20 Nov 2012 14:18:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=/fgwbMMcZgBSiU0yXnyVvacqJ4hKXakQKkSuhAjcBI0=; b=CdTln6CJb/i2Ww43CTzlHFJCkOeQfWNF53U+fSc4t7lgbR7DLkyqBWSEZmhlf6GEKP vG4IwkS7Isk+yhipe+Qg84Ig7V0t42kN6G2PukE6EoZ4DFH5SwwSxAl930BoEyBAPl7V lG5G3rfFgEOGX2NEFiKkyh/6fVxK3JbSOegMjlzK3m3001ANczBEO7zw+R5cxVW0q4s3 yX+Y54DAfyXlQTEGWmUEMZOqjwTtAe6o2t0GBnqCSZPmaIN547lm96N87ZGf+/KdsQww ET7ay7QuSeTkjv7PipJLq2/YksVMAIjCFeaQsW+LjDmngtNDmD6D/j5D/Z85Sg1i/2oK gHmw== Received: by 10.14.0.3 with SMTP id 3mr21451972eea.16.1353449913403; Tue, 20 Nov 2012 14:18:33 -0800 (PST) Received: by 10.14.0.3 with SMTP id 3mr21451948eea.16.1353449913235; Tue, 20 Nov 2012 14:18:33 -0800 (PST) Received: from AMMARSALIH ([95.159.78.43]) by mx.google.com with ESMTPS id a44sm33152997eeo.7.2012.11.20.14.18.28 (version=SSLv3 cipher=OTHER); Tue, 20 Nov 2012 14:18:31 -0800 (PST) From: "Ammar Salih" To: "'Richard L. Barnes'" References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com> <50a8f5db.04c0440a.320d.5d9e@mx.google.com> <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> In-Reply-To: <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> Date: Wed, 21 Nov 2012 01:18:24 +0300 Message-ID: <50ac01b7.44c90e0a.0a60.ffff99aa@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3HT9TKPG+YHbyKT6qv3ZMZHOlG8AAGw52g Content-Language: en-us X-Gm-Message-State: ALoCoQnco0qC1+NbVBPyKwxfcWh8AqTzzOQYJPAUQPOAk/Jhay8H29xdEllRFiyJdgcy9cFI0ls1Fy6fZ1tU19dj8EPFZBZDAhqS5FvdwGrYTHosyAGse1srkiZjSxztELwdDTDrDOmrU5eof98GAa010bfu+27Ang== Cc: geopriv@ietf.org, ipv6@ietf.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 22:18:37 -0000 Hello Richard, > I have read your draft. From what I can tell, it is just a summary of the > arguments in this thread. It would be more helpful if you could add a > level of technical detail to help people understand. I would want to see > at least: > 1. The format of the IPv6 option > 2. Where it is to be added to / removed from a packet 3. Requirements for > routers / hosts 4. Privacy considerations 5. Security considerations I've been thinking about this also, and I was trying to see the general feeling about the idea and getting some feedback first, then proceed with more technical details, thanks for your interest! > Also, it will be slightly easier to read if you use some of the standard > tools for authoring Internet drafts. See, for example: > I am quite new to the IETF, still reading documents and exploring tools, thanks for the note, appreciate it! Thanks, Ammar -----Original Message----- From: Richard L. Barnes [mailto:rbarnes@bbn.com] Sent: Tuesday, November 20, 2012 9:50 PM To: Ammar Salih Cc: 'Fred Baker (fred)'; geopriv@ietf.org; ipv6@ietf.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header Hi Ammar, I have read your draft. From what I can tell, it is just a summary of the arguments in this thread. It would be more helpful if you could add a level of technical detail to help people understand. I would want to see at least: 1. The format of the IPv6 option 2. Where it is to be added to / removed from a packet 3. Requirements for routers / hosts 4. Privacy considerations 5. Security considerations Also, it will be slightly easier to read if you use some of the standard tools for authoring Internet drafts. See, for example: Technically speaking, I'm not yet convinced that this option is very useful, but it does not seem to me that this option would be harmful to the network, only possibly the privacy of users. In specifying the privacy mechanisms in your detailed description, I would suggest that you make this mechanism "opt-in" by end hosts. For example, you could have an all-zero geolocation option indicate that a host wishes to disclose its location, but doesn't know its geolocation to put in the option; then you could require that a router SHOULD NOT populate this option unless an all-zero geolocation option is already present (indicating consent). It would also be helpful to clarify how this option would relate to other similar options, such as the line identifier option: Hope this helps, --Richard On Nov 18, 2012, at 9:51 AM, Ammar Salih wrote: > Hello Fred, > > > You may certainly file an internet draft with your ideas. You will > want to read about what an Internet Draft is and how to file one. > http://www.ietf.org/id-info/ > > Filing an Internet Draft does not imply consensus around the specification, and you will need to build that consensus. You will want to make your case, and I would suggest starting on the geopriv mailing list, although the case will eventually have to be made to 6man. http://datatracker.ietf.org/wg/geopriv/charter/. > > Appreciate it, the first draft has been submitted already > http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?inc > lude_text=1 > > > One consideration you should take in view is that the IPv6 header is not encrypted, so information found in it is globally readable. If there is ever a case in which your GPS location is needed by the application but may need to be guarded for privacy reasons, you will want to put it in the application layer (above the transport, guarded by IPsec or TLS), not the network layer. > > I have suggested few solutions to cover the privacy concern and also why I am suggesting the network layer instead of the application layer, you could find them included in the internet draft above. > > > I would expect that 6man might tell you that the IPv6 header has one primary purpose, which is to conduct a datagram from the sender's system to the intended receiver's system; if the data doesn't help achieve that, it's probably in the wrong header. > > I agree, also from OSI perspective, I would think twice before including location field into network layer, then again, it's the only layer that makes the field useable to routers. > > > > Thanks, > > Ammar > > > > From: Fred Baker (fred) [mailto:fred@cisco.com] > Sent: Friday, November 16, 2012 6:05 AM > To: Ammar Salih > Cc: ; > Subject: Re: Adding GPS location to IPv6 header > > You may certainly file an internet draft with your ideas. You will > want to read about what an Internet Draft is and how to file one. > http://www.ietf.org/id-info/ > > Filing an Internet Draft does not imply consensus around the specification, and you will need to build that consensus. You will want to make your case, and I would suggest starting on the geopriv mailing list, although the case will eventually have to be made to 6man. http://datatracker.ietf.org/wg/geopriv/charter/. > > One consideration you should take in view is that the IPv6 header is not encrypted, so information found in it is globally readable. If there is ever a case in which your GPS location is needed by the application but may need to be guarded for privacy reasons, you will want to put it in the application layer (above the transport, guarded by IPsec or TLS), not the network layer. In fact, I would expect that 6man might tell you that the IPv6 header has one primary purpose, which is to conduct a datagram from the sender's system to the intended receiver's system; if the data doesn't help achieve that, it's probably in the wrong header. > > On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: > > > Hello IETF, based on my discussions with both ipv6 and geopriv teams, I've written the below document to summarize few ideas. > > Is it possible to publish this on IETF website? even if it will not be implemented now, at least for documentation and requesting feedback from the community. > > > > Many thanks. > > Ammar > > > > > > Ammar J. Salih > Baghdad, Iraq > October 30, 2012 > Title: IP-LOC > > > > Adding GPS location to IPv6 header > > Abstract: > ========= > > This document describes IP-LOC, an extension to IPv6 header which suggests adding GPS coordinates, as the current method of determining the location of IP traffic is through IP address registration database, which is not very accurate as it depends on how the ISP registers its IP subnets, that is normally done in a country/city format. > > It also assumes that in the future, GPS capability will be added to the router itself (just like smart phones) and packet marking and classification based on geo-location will be required. > > QoS, firewall and routing based on geo-location will be highly required when mobile routers move from one geo-location to another which has different policy. > > > > > > Benefits of adding GPS location to IPv6 header (IP-LOC) > ======================================================= > > > Web Services: getting more accurate locations will enhance many services provided by the web, like targeted commercials (for example, I can get Ads regarding restaurants available in my neighborhoods instead of all restaurants in the city), another good example would be webpage's language, my language will be detected more accurately based on my area rather than my country, as there are many countries with more than one popular language, not mentioning that many ip registrations does not even reflect the traffic originating country. > > ------------------------------- > > Information accuracy and control: Nowadays, locations are assigned to IP addresses without user awareness or control, every time a user performs ip-lookup query the response would be different based on how the ISP has registered this IP subnet, IP-LOC suggests making locations more accurate and controllable through OS and network devices, exactly like IP addresses (user can change his/her IP address, but router can also modify the header information - in case it's required). > > ------------------------------- > > > Routing: Policy based routing, based on geo-location, like routing > predefined traffic through certain server or path, for different > purposes (security, manageability, serviceability like choosing > language, or routing traffic to specific cashing or proxy server based > on country .. etc) > > ------------------------------- > > > Copyright law: It happens when certain media/web content is not allowed in certain countries due to copyright law, the current method of determining locations is not accurate at all, on other hand, If layer-7 application to be used then the user might be able to manipulate the location field, in this case (if it's required in future) the ISP can tag traffic with country/city more accurately as traffic passes through ISP's boarder routers. > > ------------------------------- > > Maps, navigation, emergency calls and many other services will be also enhanced with accurate locations. > > > > > > CURRENT ARGUMENTS AGAINST THIS IDEA: > ======================================== > > "Adding GPS position to every IPv6 header would add a lot of overhead" > > Response: It does not have to be in every IPv6 header, only when there is location update, also the host should have the option of not to send location updates. > > ------------------------------- > > "What about privacy?" > > Response: User should have the option of not sending location updates. User should also have the ability to set location to all zeros, in this case no router will modify the location field and user loses the location-based services. > > If it's router-to-router link, then no need to be worried about privacy as such information usually configured on a separate network. > > -------------------------------- > > "a good alternative would be to create application layer protocols that could request and send GPS positions" > > Response: the layer-7 location request will not be detected by layer-3 devices (Routers), I am assuming that in the future, GPS capability will be added to the router itself (just like smart phones), features like packet marking and classification based on geo-location will be required to enforce the new geo-location policies. > > -------------------------------- > > "For location-based routing protocols: Why would you want this? Geographical location isn't actually that important a metric for routing; what you care about there is *topological* location, how far I am away from you in terms of hops or latency" > > Response: For shortest path maybe yes, hops or latency is important, > not for policy-based routing, in our case you might want to do > location-based routing, like, routing traffic coming from French > speaking users (in multi-language country like Canada) to google.fr > > --------------------------------- > > "For geolocation-based ACLs: you have the problem that if the geolocation is attached by the endpoint, then it can't be trusted, since the endpoint would lie to get past the ACL. If it's attached by a router, the ACL needs to have proof that the router attached it (and not the endpoint), which means that you would need a signed geolocation header" > > Response: You could have the router modify the location field anyways, just like L3 QoS fields, if you don't trust the host, so no need for encryption or security, additionally, ACL is not only for security, it could be used for routing, QoS ..etc, so the host will not always has the motivation to manipulate the location field. > > --------------------------------- > > "Why can't you simply implement rules related to geo-locations statically on the network device (router, firewall .. etc)?" > > Response: To enforce new geo-location policies automatically, let's assume that a mobile router (like a mobile BTS in a GSM network) moved from city-x to city-y, and according to city-x regulations VoIP calls over GSM network is allowed, but city-y regulations do not allow that. Now the topology may reflect same network metrics in both cities but there is no rule that triggers configuration change based on geo-location. > > > --------------------------------- > > > > What do you think? > > > Author/Contact Information: > > Ammar J. Salih > Baghdad, Iraq > > Phone: +964 770 533 0306 > Email: ammar.alsalih@gmail.com > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > ---------------------------------------------------- > The ignorance of how to use new knowledge stockpiles exponentially. > - Marshall McLuhan > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From ammar.salih@auis.edu.iq Wed Nov 21 00:24:05 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A1321F8835 for ; Wed, 21 Nov 2012 00:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-YsjpAyBlok for ; Wed, 21 Nov 2012 00:24:04 -0800 (PST) Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) by ietfa.amsl.com (Postfix) with SMTP id A842521F884E for ; Wed, 21 Nov 2012 00:24:03 -0800 (PST) Received: from mail-da0-f70.google.com ([209.85.210.70]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKUKyPogMJ5/ePTXsH7sQ72FwdSQN/6CYk@postini.com; Wed, 21 Nov 2012 00:24:03 PST Received: by mail-da0-f70.google.com with SMTP id t11so2784428daj.1 for ; Wed, 21 Nov 2012 00:24:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=n9xsU9HodZVk02sxMu4puZdAWsLZEEbPc9er/OMCvWU=; b=XCfyyTRaBtlwo4pT7kBmypN0e/x9i/ICl/eDRUQdCNUO8BGVKpE3xm7UrUhGmW626T yOggCUsL6ne/nlGqmgD6Y/ar/FF5kvJ4DnkcmF9WEUsoGDUkaxX/Jz8tHbRJ9sbXQ+ZB ErF7gxPuaQjf+/mqjyw7nKFaUpOHwX/SE774n4BAWLYhO08CLKVIV0iH/ZWInaEgZJi1 g565Qz8D1Y55fqwk693iOt3Cvd6oQPAt2AHtTAPYXjTEnJdjK7tzryrqqOLfBrkQB7WD m7avgEWr0oRhzvAksypyp8MuDO/RbLpukfW9rvUmkZicbKFifMdWfhyDzI1oa1ZVZa/y ojEA== Received: by 10.68.236.131 with SMTP id uu3mr51374462pbc.104.1353486242492; Wed, 21 Nov 2012 00:24:02 -0800 (PST) Received: by 10.68.236.131 with SMTP id uu3mr51374446pbc.104.1353486242354; Wed, 21 Nov 2012 00:24:02 -0800 (PST) Received: from AMMARSALIH ([46.30.228.16]) by mx.google.com with ESMTPS id qp6sm9552247pbc.25.2012.11.21.00.23.58 (version=SSLv3 cipher=OTHER); Wed, 21 Nov 2012 00:24:00 -0800 (PST) From: "Ammar Salih" To: "'Mark Andrews'" References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com><8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com><50a8f5db.04c0440a.320d.5d9e@mx.google.com> <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> <4D7DF3B7-F749-44B6-A60B-3E804037F47B@bbn.com> <202EF1AE79AE413CAF7B9F24A3D08314@OfficeHP> <50abfe21.82da0e0a.5c65.ffff96d7@mx.google.com> <20121121070529.A53E42B7AEA8@drugs.dv.isc.org> In-Reply-To: <20121121070529.A53E42B7AEA8@drugs.dv.isc.org> Date: Wed, 21 Nov 2012 11:23:52 +0300 Message-ID: <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3HtqDWcfMHKYA8Q0676luoHAAUZAAB+nGQ Content-Language: en-us X-Gm-Message-State: ALoCoQl3ometbUe7TevurkhpjfJfDaoFF1WieLS/a4O3LVAAZKk6xlSx7j2Pg8X7VtTxRwtIo+m17YS56by1ZwqzxY7ce6HYFEO2Gj+F/maGkdM0ZObwDRmYbsKAiZRgOH1rz0QNnuUo2VAYfjdDUInh+EktNa3RBg== Cc: geopriv@ietf.org, ipv6@ietf.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 08:24:05 -0000 Mark, > There are LOTS of ISPs between the client and the destination. Most of > these can get nothing about your location. They can get much more! trust me, the point is that if you don't trust the ISP then you should be worried about all your un-encrypted traffic, not only location. Anythink you write on facebook for example *if you don't use https* can be easily detected, including location tags,relationships,activities, wall posts, friends ... and much more, all your http traffic, including documents you read, messages, usernames, passwords, bank accounts ...etc. One last point, is that your current IP address reflects your location, I can simply do ip lookup and find out your location. Would that be also considered as privacy breach? Thanks, Ammar -----Original Message----- From: Mark Andrews [mailto:marka@isc.org] Sent: Wednesday, November 21, 2012 10:05 AM To: Ammar Salih Cc: 'John Pickens (jopicken)'; geopriv@ietf.org; ipv6@ietf.org; 'Fred Baker (fred)' Subject: Re: [Geopriv] Adding GPS location to IPv6 header In message <50abfe21.82da0e0a.5c65.ffff96d7@mx.google.com>, "Ammar Salih" writes: > > As to this schema mentioned below, embedding location info in packet > headers is potentially exposing the location coordinate to "snoopers > > Ok, I would like to shed some light regarding privacy issue: > > First, user should have the option of not sending location updates. > > Second, user will be routed through an ISP, if we don't trust the ISP > then I can assure you that ISP can get much more information than > physical location, any un-encrypted traffic -which is the majority- > can be analyzed at the ISP level (up to layer-7). There are LOTS of ISPs between the client and the destination. Most of these can get nothing about your location. > Other than ISP, the sniffer could be connected to the same > layer-2/layer-3 device as mine, in this case I would worry about > usernames/passwords/accounts/files/keys/pictures/messages .. etc, but > not location as the sniffer in this case is mostly sitting at the same > physical location as mine. > > Thanks > Ammar > > > > -----Original Message----- > From: John Pickens (jopicken) [mailto:jopicken@cisco.com] > Sent: Tuesday, November 20, 2012 11:48 PM > To: Carl Reed; Richard L. Barnes > Cc: geopriv@ietf.org; ipv6@ietf.org; Ammar Salih; Fred Baker (fred) > Subject: RE: [Geopriv] Adding GPS location to IPv6 header > > I've been monitoring this thread. In the IETF the objective is to respect > privacy of correlation of IP address to location metadata. Essentially as > mentioned below the client device receives it in the extant protocols. > The consumer can provide authorization as to the granularity of location that is > visible to other entities. As to this schema mentioned below, embedding > location info in packet headers is potentially exposing the location > coordinate to "snoopers". If encrypted, then.... > > Thoughts of others? > > J > > -----Original Message----- > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On > Behalf Of Carl Reed > Sent: Tuesday, November 20, 2012 12:15 PM > To: Richard L. Barnes > Cc: geopriv@ietf.org; ipv6@ietf.org; Ammar Salih; Fred Baker (fred) > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > Gotcha - thanks! > > Carl > > > -----Original Message----- > From: Richard L. Barnes > Sent: Tuesday, November 20, 2012 1:12 PM > To: Carl Reed > Cc: Ammar Salih ; geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > References for DHCP location: > > > > If I understand the proposal correctly, this is an orthogonal problem > to the one DHCP location solves. > > DHCP geolocation sends location from the DHCP server to the end host. > This > IPv6 option would send location from a host to the destination of a > packet (e.g., a server) and intermediate routers. > > > > On Nov 20, 2012, at 2:52 PM, "Carl Reed" wrote: > > > Hi - > > > > I asked this question before and did not get a response (maybe > > because my question was off base). > > > > There is a location extension for DHCP. This extension is consistent > > with other location object definitions used in the IETF as well as > > what is used and specified in various ISO, OGC, OASIS and other standards. > > > > Why not use the DHCP location extension? Why define yet another > > location element for IPv6? > > > > Thanks > > > > Carl Reed, PhD > > CTO > > OGC > > > > > > -----Original Message----- From: Richard L. Barnes > > Sent: Tuesday, November 20, 2012 11:49 AM > > To: Ammar Salih > > Cc: geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' > > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > > > Hi Ammar, > > > > I have read your draft. From what I can tell, it is just a summary > > of the arguments in this thread. It would be more helpful if you > > could add a level of technical detail to help people understand. I > > would want to see at least: > > 1. The format of the IPv6 option > > 2. Where it is to be added to / removed from a packet 3. > > Requirements for routers / hosts 4. Privacy considerations 5. > > Security considerations > > > > Also, it will be slightly easier to read if you use some of the > > standard tools for authoring Internet drafts. See, for example: > > > > > > Technically speaking, I'm not yet convinced that this option is very > > useful, but it does not seem to me that this option would be harmful > > to the network, only possibly the privacy of users. In specifying > > the privacy mechanisms in your detailed description, I would suggest > > that you make this mechanism "opt-in" by end hosts. For example, > > you could have an all-zero geolocation option indicate that a host > > wishes to disclose its location, but doesn't know its geolocation to > > put in the option; then you could require that a router SHOULD NOT > > populate this option unless an all-zero geolocation option is > > already present > (indicating consent). > > > > It would also be helpful to clarify how this option would relate to > > other similar options, such as the line identifier option: > > > > > > Hope this helps, > > --Richard > > > > > > > > > > On Nov 18, 2012, at 9:51 AM, Ammar Salih wrote: > > > >> Hello Fred, > >> > >> > >> You may certainly file an internet draft with your ideas. You will > >> want to read about what an Internet Draft is and how to file one. > >> http://www.ietf.org/id-info/ > >> > >> Filing an Internet Draft does not imply consensus around the > >> specification, and you will need to build that consensus. You will > >> want to make your case, and I would suggest starting on the geopriv > >> mailing list, although the case will eventually have to be made to 6man. > >> http://datatracker.ietf.org/wg/geopriv/charter/. > >> > >> Appreciate it, the first draft has been submitted already > >> http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/? > >> in > >> clude_text=1 > >> > >> > >> One consideration you should take in view is that the IPv6 header > >> is not encrypted, so information found in it is globally readable. > >> If there is ever a case in which your GPS location is needed by the > >> application but may need to be guarded for privacy reasons, you > >> will want to put it in the application layer (above the transport, > >> guarded by IPsec or TLS), not the network layer. > >> > >> I have suggested few solutions to cover the privacy concern and > >> also why I am suggesting the network layer instead of the > >> application layer, you could find them included in the internet draft above. > >> > >> > >> I would expect that 6man might tell you that the IPv6 header has > >> one primary purpose, which is to conduct a datagram from the > >> sender's system to the intended receiver's system; if the data > >> doesn't help achieve that, it's probably in the wrong header. > >> > >> I agree, also from OSI perspective, I would think twice before > >> including location field into network layer, then again, it's the > >> only layer that makes the field useable to routers. > >> > >> > >> > >> Thanks, > >> > >> Ammar > >> > >> > >> > >> From: Fred Baker (fred) [mailto:fred@cisco.com] > >> Sent: Friday, November 16, 2012 6:05 AM > >> To: Ammar Salih > >> Cc: ; > >> Subject: Re: Adding GPS location to IPv6 header > >> > >> You may certainly file an internet draft with your ideas. You will > >> want to read about what an Internet Draft is and how to file one. > >> http://www.ietf.org/id-info/ > >> > >> Filing an Internet Draft does not imply consensus around the > >> specification, and you will need to build that consensus. You will > >> want to make your case, and I would suggest starting on the geopriv > >> mailing list, although the case will eventually have to be made to 6man. > >> http://datatracker.ietf.org/wg/geopriv/charter/. > >> > >> One consideration you should take in view is that the IPv6 header > >> is not encrypted, so information found in it is globally readable. > >> If there is ever a case in which your GPS location is needed by the > >> application but may need to be guarded for privacy reasons, you > >> will want to put it in the application layer (above the transport, > >> guarded by IPsec or TLS), not the network layer. In fact, I would > >> expect that 6man might tell you that the IPv6 header has one > >> primary purpose, which is to conduct a datagram from the sender's > >> system to the intended receiver's system; if the data doesn't help > >> achieve that, it's > probably in the wrong header. > >> > >> On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: > >> > >> > >> Hello IETF, based on my discussions with both ipv6 and geopriv > >> teams, I've written the below document to summarize few ideas. > >> > >> Is it possible to publish this on IETF website? even if it will not > >> be implemented now, at least for documentation and requesting > >> feedback from the community. > >> > >> > >> > >> Many thanks. > >> > >> Ammar > >> > >> > >> > >> > >> > >> Ammar J. Salih > >> Baghdad, Iraq > >> October 30, 2012 > >> Title: IP-LOC > >> > >> > >> > >> Adding GPS location to IPv6 header > >> > >> Abstract: > >> ========= > >> > >> This document describes IP-LOC, an extension to IPv6 header which > >> suggests adding GPS coordinates, as the current method of > >> determining the location of IP traffic is through IP address > >> registration database, which is not very accurate as it depends on > >> how the ISP registers its IP subnets, that is normally done in a country/city format. > >> > >> It also assumes that in the future, GPS capability will be added to > >> the router itself (just like smart phones) and packet marking and > >> classification based on geo-location will be required. > >> > >> QoS, firewall and routing based on geo-location will be highly > >> required when mobile routers move from one geo-location to another > >> which has different policy. > >> > >> > >> > >> > >> > >> Benefits of adding GPS location to IPv6 header (IP-LOC) > >> ======================================================= > >> > >> > >> Web Services: getting more accurate locations will enhance many > >> services provided by the web, like targeted commercials (for > >> example, I can get Ads regarding restaurants available in my > >> neighborhoods instead of all restaurants in the city), another good > >> example would be webpage's language, my language will be detected > >> more accurately based on my area rather than my country, as there > >> are many countries with more than one popular language, not > >> mentioning that many ip registrations does not even reflect the traffic originating country. > >> > >> ------------------------------- > >> > >> Information accuracy and control: Nowadays, locations are assigned > >> to IP addresses without user awareness or control, every time a > >> user performs ip-lookup query the response would be different based > >> on how the ISP has registered this IP subnet, IP-LOC suggests > >> making locations more accurate and controllable through OS and > >> network devices, exactly like IP addresses (user can change his/her > >> IP address, but router can also modify the header information - in > >> case it's > required). > >> > >> ------------------------------- > >> > >> > >> Routing: Policy based routing, based on geo-location, like routing > >> predefined traffic through certain server or path, for different > >> purposes (security, manageability, serviceability like choosing > >> language, or routing traffic to specific cashing or proxy server > >> based on > country .. > >> etc) > >> > >> ------------------------------- > >> > >> > >> Copyright law: It happens when certain media/web content is not > >> allowed in certain countries due to copyright law, the current > >> method of determining locations is not accurate at all, on other > >> hand, If > >> layer-7 application to be used then the user might be able to > >> manipulate the location field, in this case (if it's required in > >> future) the ISP can tag traffic with country/city more accurately > >> as traffic passes through ISP's boarder routers. > >> > >> ------------------------------- > >> > >> Maps, navigation, emergency calls and many other services will be > >> also enhanced with accurate locations. > >> > >> > >> > >> > >> > >> CURRENT ARGUMENTS AGAINST THIS IDEA: > >> ======================================== > >> > >> "Adding GPS position to every IPv6 header would add a lot of overhead" > >> > >> Response: It does not have to be in every IPv6 header, only when > >> there is location update, also the host should have the option of > >> not to send location updates. > >> > >> ------------------------------- > >> > >> "What about privacy?" > >> > >> Response: User should have the option of not sending location updates. > >> User should also have the ability to set location to all zeros, in > >> this case no router will modify the location field and user loses > >> the location-based services. > >> > >> If it's router-to-router link, then no need to be worried about > >> privacy as such information usually configured on a separate network. > >> > >> -------------------------------- > >> > >> "a good alternative would be to create application layer protocols > >> that could request and send GPS positions" > >> > >> Response: the layer-7 location request will not be detected by > >> layer-3 devices (Routers), I am assuming that in the future, GPS > >> capability will be added to the router itself (just like smart > >> phones), features like packet marking and classification based on > >> geo-location will be required to enforce the new geo-location policies. > >> > >> -------------------------------- > >> > >> "For location-based routing protocols: Why would you want this? > >> Geographical location isn't actually that important a metric for > >> routing; what you care about there is *topological* location, how > >> far I am away from you in terms of hops or latency" > >> > >> Response: For shortest path maybe yes, hops or latency is > >> important, not for policy-based routing, in our case you might want > >> to do location-based routing, like, routing traffic coming from > >> French speaking users (in multi-language country like Canada) to > >> google.fr > >> > >> --------------------------------- > >> > >> "For geolocation-based ACLs: you have the problem that if the > >> geolocation is attached by the endpoint, then it can't be trusted, > >> since the endpoint would lie to get past the ACL. If it's attached > >> by a router, the ACL needs to have proof that the router attached > >> it (and not the endpoint), which means that you would need a signed > geolocation header" > >> > >> Response: You could have the router modify the location field > >> anyways, just like L3 QoS fields, if you don't trust the host, so > >> no need for encryption or security, additionally, ACL is not only > >> for security, it could be used for routing, QoS ..etc, so the host > >> will not always has the motivation to manipulate the location field. > >> > >> --------------------------------- > >> > >> "Why can't you simply implement rules related to geo-locations > >> statically on the network device (router, firewall .. etc)?" > >> > >> Response: To enforce new geo-location policies automatically, let's > >> assume that a mobile router (like a mobile BTS in a GSM network) > >> moved from city-x to city-y, and according to city-x regulations > >> VoIP calls over GSM network is allowed, but city-y regulations do > >> not allow > that. > >> Now the topology may reflect same network metrics in both cities > >> but there is no rule that triggers configuration change based on > >> geo-location. > >> > >> > >> --------------------------------- > >> > >> > >> > >> What do you think? > >> > >> > >> Author/Contact Information: > >> > >> Ammar J. Salih > >> Baghdad, Iraq > >> > >> Phone: +964 770 533 0306 > >> Email: ammar.alsalih@gmail.com > >> > >> > >> ------------------------------------------------------------------- > >> - IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> ------------------------------------------------------------------- > >> - > >> > >> ---------------------------------------------------- > >> The ignorance of how to use new knowledge stockpiles exponentially. > >> - Marshall McLuhan > >> > >> _______________________________________________ > >> Geopriv mailing list > >> Geopriv@ietf.org > >> https://www.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From oneingray@gmail.com Wed Nov 21 01:37:03 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAA321F85AA; Wed, 21 Nov 2012 01:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D54kpUs577UY; Wed, 21 Nov 2012 01:37:03 -0800 (PST) Received: from gray.siamics.net (unknown [IPv6:2002:bc78:e7e5::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C09521F85C7; Wed, 21 Nov 2012 01:37:02 -0800 (PST) Received: from localhost ([::1] helo=gray.siamics.net) by gray.siamics.net with esmtp (Exim 4.72) (envelope-from ) id 1Tb6jp-0005K1-6r; Wed, 21 Nov 2012 16:36:57 +0700 From: Ivan Shmakov To: geopriv@ietf.org, ipv6@ietf.org References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com> <50a8f5db.04c0440a.320d.5d9e@mx.google.com> <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> <4D7DF3B7-F749-44B6-A60B-3E804037F47B@bbn.com> <202EF1AE79AE413CAF7B9F24A3D08314@OfficeHP> <50abfe21.82da0e0a.5c65.ffff96d7@mx.google.com> <20121121070529.A53E42B7AEA8@drugs.dv.isc.org> <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> Sender: ivan@gray.siamics.net Date: Wed, 21 Nov 2012 16:36:56 +0700 In-Reply-To: <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> (Ammar Salih's message of "Wed, 21 Nov 2012 11:23:52 +0300") Message-ID: <86vccz70w7.fsf@gray.siamics.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 09:37:03 -0000 >>>>> Ammar Salih writes: >> There are LOTS of ISPs between the client and the destination. Most >> of these can get nothing about your location. > They can get much more! trust me, the point is that if you don't > trust the ISP then you should be worried about all your un-encrypted > traffic, not only location. > Anythink you write on facebook for example *if you don't use https* > can be easily detected, including location tags, relationships, > activities, wall posts, friends ... and much more, all your http > traffic, including documents you read, messages, usernames, > passwords, bank accounts ...etc. That's precisely the reason to never, ever consider plain, un-encrypted HTTP for anything that requires authentication. To note is that the majority of sites don't allow logins over plain HTTP, and I've never seen a bank providing access to one's account over plain HTTP. Once again, in the typical case, there're way too many networks between you and the service you use to trust them all. The same applies to the non-TLS (non-SSL) versions of the other protocols, such as IMAP or XMPP, just as well. > One last point, is that your current IP address reflects your > location, I can simply do ip lookup and find out your location. It's not actually as simple as it may seem, as long as the possibility of a tunnel (VPN) is considered. Such tunnels is also a reason why it isn't sensible for an ISP to validate or provide geolocation information within the traffic routed. > Would that be also considered as privacy breach? Yes. This is why one may occasionally want to relay one's traffic via Tor [1]. [1] https://www.torproject.org/ -- FSF associate member #7257 From ammar.salih@auis.edu.iq Wed Nov 21 04:41:52 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBA121F866F for ; Wed, 21 Nov 2012 04:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKj-2cLNrG8B for ; Wed, 21 Nov 2012 04:41:51 -0800 (PST) Received: from na3sys010aog111.obsmtp.com (na3sys010aog111.obsmtp.com [74.125.245.90]) by ietfa.amsl.com (Postfix) with SMTP id 45DA721F866B for ; Wed, 21 Nov 2012 04:41:51 -0800 (PST) Received: from mail-pa0-f70.google.com ([209.85.220.70]) (using TLSv1) by na3sys010aob111.postini.com ([74.125.244.12]) with SMTP ID DSNKUKzMDlr4hZTsRBKpHCmHtmqoLYqK8jEG@postini.com; Wed, 21 Nov 2012 04:41:51 PST Received: by mail-pa0-f70.google.com with SMTP id hz11so4781143pad.1 for ; Wed, 21 Nov 2012 04:41:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=YWFD+WrbAgVALu7MXIgWQxA+QDJU2w1DLssAUjcJclI=; b=g752pIbaojAWDbRKWLOjaj/wOBsYaXRi+zhEA6iKkTwtVlFfqddhoEk8qqplyZfwJH OQeHVlucSWC4AYAmSUr9LhghJnpgrtQ9iaxTe3mQHk/S2JnPGq6ZEAihz6/w27eG4PNA QZIfVODhJWk8Dkr2qbEM3xi0E/7iwIVyV/kChSbMvDbwRMwakCj4R2ajAeUsjVFjwEZ0 sV3OGHsfpei1FGCwo9+Dg/k0W2XAEJelzOv/O7o6rqetE84o/nanJkGg1Yrp+tHqA3vs vBPt+0IaZGITsEJoPhTrZkPiZhk8Ix/YAQ5otEsDVEYJusO53nCLMj7xw+MsJ1oVRjLo zV6w== Received: by 10.68.237.6 with SMTP id uy6mr57793970pbc.147.1353501710367; Wed, 21 Nov 2012 04:41:50 -0800 (PST) Received: by 10.68.237.6 with SMTP id uy6mr57793948pbc.147.1353501710201; Wed, 21 Nov 2012 04:41:50 -0800 (PST) Received: from AMMARSALIH ([46.30.228.16]) by mx.google.com with ESMTPS id vo8sm194468pbc.16.2012.11.21.04.41.46 (version=SSLv3 cipher=OTHER); Wed, 21 Nov 2012 04:41:48 -0800 (PST) From: "Ammar Salih" To: References: <50abfe21.82da0e0a.5c65.ffff96d7@mx.google.com> <20121121070529.A53E42B7AEA8@drugs.dv.isc.org> <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> <20121121.121147.74690387.sthaug@nethelp.no> In-Reply-To: <20121121.121147.74690387.sthaug@nethelp.no> Date: Wed, 21 Nov 2012 15:41:41 +0300 Message-ID: <50accc0c.08ef440a.0ab6.1740@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3H2QIPlpAZp1X7QESINWNAuS9iGgACkuZA Content-Language: en-us X-Gm-Message-State: ALoCoQka2B7UDoMM+PIsBejbzNmJOHJCOrm8rCrrzr7iD0x7oBrAkL6HPM/EQY//Z8x5u9en+DGYw4/EexOKelcT1aTP3TESB969vJJDHXgQJ6WH7mwPFG6i6HRHsGhuFgn3zyBbEkp/ZzoMhLL649U6HVN3BakRug== Cc: geopriv@ietf.org, ipv6@ietf.org, marka@isc.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 12:41:52 -0000 > You can probably get a *hint* about my location from an IP lookup. You can > definitely not be certain my location Well, with the new draft, you can do the same, location accuracy can be tweaked to reflect city only, or city and region..etc. > it tells me the correct *country* for the IP. However, both the region and > the city are wrong. That is the whole point, why are we happy with providing incorrect information? It's even without our awareness or control. Thanks, Ammar -----Original Message----- From: sthaug@nethelp.no [mailto:sthaug@nethelp.no] Sent: Wednesday, November 21, 2012 2:12 PM To: ammar.salih@auis.edu.iq Cc: marka@isc.org; geopriv@ietf.org; ipv6@ietf.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header > One last point, is that your current IP address reflects your > location, I can simply do ip lookup and find out your location. Would > that be also considered as privacy breach? You can probably get a *hint* about my location from an IP lookup. You can definitely not be certain my location - since you don't know if the RIR info is correct, you don't know about any tunnels I might use, etc. For instance - if I put the address of my mail server into Geo IP Tool (one of several such services), http://www.geoiptool.com/en/?IP=195.1.209.33 it tells me the correct *country* for the IP. However, both the region and the city are wrong. How valuable is location with contry granularity? Steinar Haug, Nethelp consulting, sthaug@nethelp.no From marka@isc.org Tue Nov 20 23:05:57 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F2F21F87E1; Tue, 20 Nov 2012 23:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HS_INDEX_PARAM=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QV-Qu0aTJnMC; Tue, 20 Nov 2012 23:05:45 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id CE4EC21F8450; Tue, 20 Nov 2012 23:05:44 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 7C7C7C985C; Wed, 21 Nov 2012 07:05:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:3c0e:404f:1fe2:ca82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id CA448216C81; Wed, 21 Nov 2012 07:05:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id A53E42B7AEA8; Wed, 21 Nov 2012 18:05:29 +1100 (EST) To: "Ammar Salih" From: Mark Andrews References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com><8C48B86A895913448548E6D15DA7553B1B92F4@xmb-rcd-x09.cisco.com><50a8f5db.04c0440a.320d.5d9e@mx.google.com> <992B5474-5E13-4270-8A22-1BE391F87C06@bbn.com> <4D7DF3B7-F749-44B6-A60B-3E804037F47B@bbn.com> <202EF1AE79AE413CAF7B9F24A3D08314@OfficeHP> <50abfe21.82da0e0a.5c65.ffff96d7@mx.google.com> In-reply-to: Your message of "Wed, 21 Nov 2012 01:03:06 +0300." <50abfe21.82da0e0a.5c65.ffff96d7@mx.google.com> Date: Wed, 21 Nov 2012 18:05:29 +1100 Message-Id: <20121121070529.A53E42B7AEA8@drugs.dv.isc.org> X-Mailman-Approved-At: Wed, 21 Nov 2012 06:02:17 -0800 Cc: geopriv@ietf.org, ipv6@ietf.org, "'Fred Baker \(fred\)'" Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 07:05:57 -0000 In message <50abfe21.82da0e0a.5c65.ffff96d7@mx.google.com>, "Ammar Salih" writes: > > As to this schema mentioned below, embedding location info in packet > headers is potentially exposing the location coordinate to "snoopers > > Ok, I would like to shed some light regarding privacy issue: > > First, user should have the option of not sending location updates. > > Second, user will be routed through an ISP, if we don't trust the ISP then I > can assure you that ISP can get much more information than physical > location, any un-encrypted traffic -which is the majority- can be analyzed > at the ISP level (up to layer-7). There are LOTS of ISPs between the client and the destination. Most of these can get nothing about your location. > Other than ISP, the sniffer could be connected to the same layer-2/layer-3 > device as mine, in this case I would worry about > usernames/passwords/accounts/files/keys/pictures/messages .. etc, but not > location as the sniffer in this case is mostly sitting at the same physical > location as mine. > > Thanks > Ammar > > > > -----Original Message----- > From: John Pickens (jopicken) [mailto:jopicken@cisco.com] > Sent: Tuesday, November 20, 2012 11:48 PM > To: Carl Reed; Richard L. Barnes > Cc: geopriv@ietf.org; ipv6@ietf.org; Ammar Salih; Fred Baker (fred) > Subject: RE: [Geopriv] Adding GPS location to IPv6 header > > I've been monitoring this thread. In the IETF the objective is to respect > privacy of correlation of IP address to location metadata. Essentially as > mentioned below the client device receives it in the extant protocols. The > consumer can provide authorization as to the granularity of location that is > visible to other entities. As to this schema mentioned below, embedding > location info in packet headers is potentially exposing the location > coordinate to "snoopers". If encrypted, then.... > > Thoughts of others? > > J > > -----Original Message----- > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf > Of Carl Reed > Sent: Tuesday, November 20, 2012 12:15 PM > To: Richard L. Barnes > Cc: geopriv@ietf.org; ipv6@ietf.org; Ammar Salih; Fred Baker (fred) > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > Gotcha - thanks! > > Carl > > > -----Original Message----- > From: Richard L. Barnes > Sent: Tuesday, November 20, 2012 1:12 PM > To: Carl Reed > Cc: Ammar Salih ; geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > References for DHCP location: > > > > If I understand the proposal correctly, this is an orthogonal problem to the > one DHCP location solves. > > DHCP geolocation sends location from the DHCP server to the end host. This > IPv6 option would send location from a host to the destination of a packet > (e.g., a server) and intermediate routers. > > > > On Nov 20, 2012, at 2:52 PM, "Carl Reed" wrote: > > > Hi - > > > > I asked this question before and did not get a response (maybe because > > my question was off base). > > > > There is a location extension for DHCP. This extension is consistent > > with other location object definitions used in the IETF as well as > > what is used and specified in various ISO, OGC, OASIS and other standards. > > > > Why not use the DHCP location extension? Why define yet another > > location element for IPv6? > > > > Thanks > > > > Carl Reed, PhD > > CTO > > OGC > > > > > > -----Original Message----- From: Richard L. Barnes > > Sent: Tuesday, November 20, 2012 11:49 AM > > To: Ammar Salih > > Cc: geopriv@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)' > > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > > > Hi Ammar, > > > > I have read your draft. From what I can tell, it is just a summary of > > the arguments in this thread. It would be more helpful if you could > > add a level of technical detail to help people understand. I would > > want to see at least: > > 1. The format of the IPv6 option > > 2. Where it is to be added to / removed from a packet 3. Requirements > > for routers / hosts 4. Privacy considerations 5. Security > > considerations > > > > Also, it will be slightly easier to read if you use some of the > > standard tools for authoring Internet drafts. See, for example: > > > > > > Technically speaking, I'm not yet convinced that this option is very > > useful, but it does not seem to me that this option would be harmful > > to the network, only possibly the privacy of users. In specifying the > > privacy mechanisms in your detailed description, I would suggest that > > you make this mechanism "opt-in" by end hosts. For example, you could > > have an all-zero geolocation option indicate that a host wishes to > > disclose its location, but doesn't know its geolocation to put in the > > option; then you could require that a router SHOULD NOT populate this > > option unless an all-zero geolocation option is already present > (indicating consent). > > > > It would also be helpful to clarify how this option would relate to > > other similar options, such as the line identifier option: > > > > > > Hope this helps, > > --Richard > > > > > > > > > > On Nov 18, 2012, at 9:51 AM, Ammar Salih wrote: > > > >> Hello Fred, > >> > >> > >> You may certainly file an internet draft with your ideas. You will > >> want to read about what an Internet Draft is and how to file one. > >> http://www.ietf.org/id-info/ > >> > >> Filing an Internet Draft does not imply consensus around the > >> specification, and you will need to build that consensus. You will > >> want to make your case, and I would suggest starting on the geopriv > >> mailing list, although the case will eventually have to be made to 6man. > >> http://datatracker.ietf.org/wg/geopriv/charter/. > >> > >> Appreciate it, the first draft has been submitted already > >> http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?in > >> clude_text=1 > >> > >> > >> One consideration you should take in view is that the IPv6 header is > >> not encrypted, so information found in it is globally readable. If > >> there is ever a case in which your GPS location is needed by the > >> application but may need to be guarded for privacy reasons, you will > >> want to put it in the application layer (above the transport, guarded > >> by IPsec or TLS), not the network layer. > >> > >> I have suggested few solutions to cover the privacy concern and also > >> why I am suggesting the network layer instead of the application > >> layer, you could find them included in the internet draft above. > >> > >> > >> I would expect that 6man might tell you that the IPv6 header has one > >> primary purpose, which is to conduct a datagram from the sender's > >> system to the intended receiver's system; if the data doesn't help > >> achieve that, it's probably in the wrong header. > >> > >> I agree, also from OSI perspective, I would think twice before > >> including location field into network layer, then again, it's the > >> only layer that makes the field useable to routers. > >> > >> > >> > >> Thanks, > >> > >> Ammar > >> > >> > >> > >> From: Fred Baker (fred) [mailto:fred@cisco.com] > >> Sent: Friday, November 16, 2012 6:05 AM > >> To: Ammar Salih > >> Cc: ; > >> Subject: Re: Adding GPS location to IPv6 header > >> > >> You may certainly file an internet draft with your ideas. You will > >> want to read about what an Internet Draft is and how to file one. > >> http://www.ietf.org/id-info/ > >> > >> Filing an Internet Draft does not imply consensus around the > >> specification, and you will need to build that consensus. You will > >> want to make your case, and I would suggest starting on the geopriv > >> mailing list, although the case will eventually have to be made to 6man. > >> http://datatracker.ietf.org/wg/geopriv/charter/. > >> > >> One consideration you should take in view is that the IPv6 header is > >> not encrypted, so information found in it is globally readable. If > >> there is ever a case in which your GPS location is needed by the > >> application but may need to be guarded for privacy reasons, you will > >> want to put it in the application layer (above the transport, guarded > >> by IPsec or TLS), not the network layer. In fact, I would expect that > >> 6man might tell you that the IPv6 header has one primary purpose, > >> which is to conduct a datagram from the sender's system to the > >> intended receiver's system; if the data doesn't help achieve that, it's > probably in the wrong header. > >> > >> On Nov 10, 2012, at 7:05 AM, Ammar Salih wrote: > >> > >> > >> Hello IETF, based on my discussions with both ipv6 and geopriv teams, > >> I've written the below document to summarize few ideas. > >> > >> Is it possible to publish this on IETF website? even if it will not > >> be implemented now, at least for documentation and requesting > >> feedback from the community. > >> > >> > >> > >> Many thanks. > >> > >> Ammar > >> > >> > >> > >> > >> > >> Ammar J. Salih > >> Baghdad, Iraq > >> October 30, 2012 > >> Title: IP-LOC > >> > >> > >> > >> Adding GPS location to IPv6 header > >> > >> Abstract: > >> ========= > >> > >> This document describes IP-LOC, an extension to IPv6 header which > >> suggests adding GPS coordinates, as the current method of determining > >> the location of IP traffic is through IP address registration > >> database, which is not very accurate as it depends on how the ISP > >> registers its IP subnets, that is normally done in a country/city format. > >> > >> It also assumes that in the future, GPS capability will be added to > >> the router itself (just like smart phones) and packet marking and > >> classification based on geo-location will be required. > >> > >> QoS, firewall and routing based on geo-location will be highly > >> required when mobile routers move from one geo-location to another > >> which has different policy. > >> > >> > >> > >> > >> > >> Benefits of adding GPS location to IPv6 header (IP-LOC) > >> ======================================================= > >> > >> > >> Web Services: getting more accurate locations will enhance many > >> services provided by the web, like targeted commercials (for example, > >> I can get Ads regarding restaurants available in my neighborhoods > >> instead of all restaurants in the city), another good example would > >> be webpage's language, my language will be detected more accurately > >> based on my area rather than my country, as there are many countries > >> with more than one popular language, not mentioning that many ip > >> registrations does not even reflect the traffic originating country. > >> > >> ------------------------------- > >> > >> Information accuracy and control: Nowadays, locations are assigned to > >> IP addresses without user awareness or control, every time a user > >> performs ip-lookup query the response would be different based on how > >> the ISP has registered this IP subnet, IP-LOC suggests making > >> locations more accurate and controllable through OS and network > >> devices, exactly like IP addresses (user can change his/her IP > >> address, but router can also modify the header information - in case it's > required). > >> > >> ------------------------------- > >> > >> > >> Routing: Policy based routing, based on geo-location, like routing > >> predefined traffic through certain server or path, for different > >> purposes (security, manageability, serviceability like choosing > >> language, or routing traffic to specific cashing or proxy server based on > country .. > >> etc) > >> > >> ------------------------------- > >> > >> > >> Copyright law: It happens when certain media/web content is not > >> allowed in certain countries due to copyright law, the current method > >> of determining locations is not accurate at all, on other hand, If > >> layer-7 application to be used then the user might be able to > >> manipulate the location field, in this case (if it's required in > >> future) the ISP can tag traffic with country/city more accurately as > >> traffic passes through ISP's boarder routers. > >> > >> ------------------------------- > >> > >> Maps, navigation, emergency calls and many other services will be > >> also enhanced with accurate locations. > >> > >> > >> > >> > >> > >> CURRENT ARGUMENTS AGAINST THIS IDEA: > >> ======================================== > >> > >> "Adding GPS position to every IPv6 header would add a lot of overhead" > >> > >> Response: It does not have to be in every IPv6 header, only when > >> there is location update, also the host should have the option of not > >> to send location updates. > >> > >> ------------------------------- > >> > >> "What about privacy?" > >> > >> Response: User should have the option of not sending location updates. > >> User should also have the ability to set location to all zeros, in > >> this case no router will modify the location field and user loses the > >> location-based services. > >> > >> If it's router-to-router link, then no need to be worried about > >> privacy as such information usually configured on a separate network. > >> > >> -------------------------------- > >> > >> "a good alternative would be to create application layer protocols > >> that could request and send GPS positions" > >> > >> Response: the layer-7 location request will not be detected by > >> layer-3 devices (Routers), I am assuming that in the future, GPS > >> capability will be added to the router itself (just like smart > >> phones), features like packet marking and classification based on > >> geo-location will be required to enforce the new geo-location policies. > >> > >> -------------------------------- > >> > >> "For location-based routing protocols: Why would you want this? > >> Geographical location isn't actually that important a metric for > >> routing; what you care about there is *topological* location, how far > >> I am away from you in terms of hops or latency" > >> > >> Response: For shortest path maybe yes, hops or latency is important, > >> not for policy-based routing, in our case you might want to do > >> location-based routing, like, routing traffic coming from French > >> speaking users (in multi-language country like Canada) to google.fr > >> > >> --------------------------------- > >> > >> "For geolocation-based ACLs: you have the problem that if the > >> geolocation is attached by the endpoint, then it can't be trusted, > >> since the endpoint would lie to get past the ACL. If it's attached > >> by a router, the ACL needs to have proof that the router attached it > >> (and not the endpoint), which means that you would need a signed > geolocation header" > >> > >> Response: You could have the router modify the location field > >> anyways, just like L3 QoS fields, if you don't trust the host, so no > >> need for encryption or security, additionally, ACL is not only for > >> security, it could be used for routing, QoS ..etc, so the host will > >> not always has the motivation to manipulate the location field. > >> > >> --------------------------------- > >> > >> "Why can't you simply implement rules related to geo-locations > >> statically on the network device (router, firewall .. etc)?" > >> > >> Response: To enforce new geo-location policies automatically, let's > >> assume that a mobile router (like a mobile BTS in a GSM network) > >> moved from city-x to city-y, and according to city-x regulations VoIP > >> calls over GSM network is allowed, but city-y regulations do not allow > that. > >> Now the topology may reflect same network metrics in both cities but > >> there is no rule that triggers configuration change based on > >> geo-location. > >> > >> > >> --------------------------------- > >> > >> > >> > >> What do you think? > >> > >> > >> Author/Contact Information: > >> > >> Ammar J. Salih > >> Baghdad, Iraq > >> > >> Phone: +964 770 533 0306 > >> Email: ammar.alsalih@gmail.com > >> > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > >> > >> ---------------------------------------------------- > >> The ignorance of how to use new knowledge stockpiles exponentially. > >> - Marshall McLuhan > >> > >> _______________________________________________ > >> Geopriv mailing list > >> Geopriv@ietf.org > >> https://www.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From sthaug@nethelp.no Wed Nov 21 03:11:52 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E97E21F85E0 for ; Wed, 21 Nov 2012 03:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fK+hN5IvI8v for ; Wed, 21 Nov 2012 03:11:51 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 00E2C21F85D8 for ; Wed, 21 Nov 2012 03:11:50 -0800 (PST) Received: (qmail 60051 invoked from network); 21 Nov 2012 11:11:47 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 21 Nov 2012 11:11:47 -0000 Date: Wed, 21 Nov 2012 12:11:47 +0100 (CET) Message-Id: <20121121.121147.74690387.sthaug@nethelp.no> To: ammar.salih@auis.edu.iq From: sthaug@nethelp.no In-Reply-To: <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> References: <50abfe21.82da0e0a.5c65.ffff96d7@mx.google.com> <20121121070529.A53E42B7AEA8@drugs.dv.isc.org> <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 21 Nov 2012 06:02:17 -0800 Cc: geopriv@ietf.org, ipv6@ietf.org, marka@isc.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 11:11:52 -0000 > One last point, is that your current IP address reflects your location, I > can simply do ip lookup and find out your location. Would that be also > considered as privacy breach? You can probably get a *hint* about my location from an IP lookup. You can definitely not be certain my location - since you don't know if the RIR info is correct, you don't know about any tunnels I might use, etc. For instance - if I put the address of my mail server into Geo IP Tool (one of several such services), http://www.geoiptool.com/en/?IP=195.1.209.33 it tells me the correct *country* for the IP. However, both the region and the city are wrong. How valuable is location with contry granularity? Steinar Haug, Nethelp consulting, sthaug@nethelp.no From sthaug@nethelp.no Wed Nov 21 07:27:57 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F2B21F869A for ; Wed, 21 Nov 2012 07:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXZrMtI-OjXK for ; Wed, 21 Nov 2012 07:27:56 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id BA49C21F8697 for ; Wed, 21 Nov 2012 07:27:55 -0800 (PST) Received: (qmail 67997 invoked from network); 21 Nov 2012 15:27:53 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 21 Nov 2012 15:27:53 -0000 Date: Wed, 21 Nov 2012 16:27:53 +0100 (CET) Message-Id: <20121121.162753.74683810.sthaug@nethelp.no> To: ammar.salih@auis.edu.iq From: sthaug@nethelp.no In-Reply-To: <50accc0c.08ef440a.0ab6.1740@mx.google.com> References: <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> <20121121.121147.74690387.sthaug@nethelp.no> <50accc0c.08ef440a.0ab6.1740@mx.google.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: geopriv@ietf.org, ipv6@ietf.org, marka@isc.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 15:27:57 -0000 > > You can probably get a *hint* about my location from an IP lookup. You can > > definitely not be certain my location > > Well, with the new draft, you can do the same, location accuracy can be > tweaked to reflect city only, or city and region..etc. And what makes you think I'm interested in publishing this? > > it tells me the correct *country* for the IP. However, both the region and > > the city are wrong. > > That is the whole point, why are we happy with providing incorrect > information? It's even without our awareness or control. I don't particularly *want* to publish this information. Therefore, if the geolocation data is to a large degree wrong, that's just fine! My whole point was simply meant as a counterargument to your "I can simply do ip lookup and find out your location". And my claim is that no, you can't really "simply" do that. And I like it that way. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From ammar.salih@auis.edu.iq Wed Nov 21 23:43:49 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D583721F8856 for ; Wed, 21 Nov 2012 23:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2pNmAs9zSUf for ; Wed, 21 Nov 2012 23:43:49 -0800 (PST) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with SMTP id 089DB21F8824 for ; Wed, 21 Nov 2012 23:43:48 -0800 (PST) Received: from mail-da0-f70.google.com ([209.85.210.70]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKUK3XtI2IQLI6sFDt+di+lpjcGYAbDiH8@postini.com; Wed, 21 Nov 2012 23:43:49 PST Received: by mail-da0-f70.google.com with SMTP id t11so3670778daj.1 for ; Wed, 21 Nov 2012 23:43:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=UEUM70xsHT7fcPwrQg1i8ro9KgaK/gLeXoKRvX4U3a0=; b=acPObtc1qYfTYYuzFt21qofawN+sdvHQNkg4DM8hV/xbIemhkVFhfYJTCWJWzhOCx2 EOHGhv9AHp+wcnxMa3AmN90XiYPRYNa3653IwYSD74Ed9viyLGs35jGhvJdzNCj3olMF RVsmOQ27wPMeKEFr669NTCRvxwwSyqCstnLJEdq5ldRz1LzLk+CdG/gTSEUNDFRmzQlT cHpfof+BsNRldgbzzniUywOpxtkbfqajteUutXda0eh7/b7kyOZtcgNLewl0RM1mz1hS zCYzIlqfGLmBZdwED0cyxtuRmfTo62myGGU0VxftVxrkt6aV2o3cVp7ANbQs5aKiThFW SnmQ== Received: by 10.69.1.35 with SMTP id bd3mr2250402pbd.141.1353570227987; Wed, 21 Nov 2012 23:43:47 -0800 (PST) Received: by 10.69.1.35 with SMTP id bd3mr2250391pbd.141.1353570227925; Wed, 21 Nov 2012 23:43:47 -0800 (PST) Received: from AMMARSALIH ([46.30.228.16]) by mx.google.com with ESMTPS id j4sm1469785pax.31.2012.11.21.23.43.43 (version=SSLv3 cipher=OTHER); Wed, 21 Nov 2012 23:43:45 -0800 (PST) From: "Ammar Salih" To: , , , References: <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> <20121121.121147.74690387.sthaug@nethelp.no> <50accc0c.08ef440a.0ab6.1740@mx.google.com> <20121121.162753.74683810.sthaug@nethelp.no> In-Reply-To: <20121121.162753.74683810.sthaug@nethelp.no> Date: Thu, 22 Nov 2012 10:43:38 +0300 Message-ID: <50add7b1.844f420a.69e7.78cc@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3H/MjoEWrWsAZpTTaPNZion/FFJAAhJfAQ Content-Language: en-us X-Gm-Message-State: ALoCoQm0OahI1oRUVzZYCWQWeiaOnC0n8MGwCBODjiV7boe7JAHE4gOfppx2uVK0sObZFrNFSPPw0RNJjaoc2T0tOYWVeJ/e/L4h7hhatmb9qxGQo7e6TSPNk6M/4gvSw2cQ/pcZNpnfsGoBYDBDMQBhqBy8BJxv6w== Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 07:43:50 -0000 Dears, I can see almost everyone agrees to that the RIR info is not accurate and in many cases is incorrect, so why the hassle of assigning wrong locations? And why developers are building their applications based on incorrect information. And frankly speaking, I don't agree to *sending wrong location information to protect our privacy*, it's either you send correct ones and get the benefits of location-based services or you don't. Thanks, Ammar -----Original Message----- From: sthaug@nethelp.no [mailto:sthaug@nethelp.no] Sent: Wednesday, November 21, 2012 6:28 PM To: ammar.salih@auis.edu.iq Cc: marka@isc.org; geopriv@ietf.org; ipv6@ietf.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header > > You can probably get a *hint* about my location from an IP lookup. > > You can definitely not be certain my location > > Well, with the new draft, you can do the same, location accuracy can > be tweaked to reflect city only, or city and region..etc. And what makes you think I'm interested in publishing this? > > it tells me the correct *country* for the IP. However, both the > > region and the city are wrong. > > That is the whole point, why are we happy with providing incorrect > information? It's even without our awareness or control. I don't particularly *want* to publish this information. Therefore, if the geolocation data is to a large degree wrong, that's just fine! My whole point was simply meant as a counterargument to your "I can simply do ip lookup and find out your location". And my claim is that no, you can't really "simply" do that. And I like it that way. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From sm@resistor.net Thu Nov 22 03:29:27 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E804E21F8944; Thu, 22 Nov 2012 03:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmBEem-NXHZ3; Thu, 22 Nov 2012 03:29:27 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3FA21F861E; Thu, 22 Nov 2012 03:29:26 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qAMBTJuX009891; Thu, 22 Nov 2012 03:29:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1353583764; bh=ZEGGTynl5Icfli8zJQrlXfgAmYAsBdbSyo67ZlhAn+I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ksyXaXNjufnaUB9yIHV+jPJCs+mkbUJEqBB2mCqoerFEYJHsfaYZ0cJBafrfBSPgp /xQeMOjUjGxCLNHNwiAdPtZ9Bugo7iGhaeTRM3TOfcTLLmAgrYXt6JYLB0esbYr6MB 5k4mPZqdq993n+FjUVveAVYfjuQe3sOWlwb426FI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1353583764; i=@resistor.net; bh=ZEGGTynl5Icfli8zJQrlXfgAmYAsBdbSyo67ZlhAn+I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=f1lzqiyrMTzaon+6OGsz2NDrYoggPeFX+THU4jpP93L1p7Gxw0NrjkDHQyozklDC5 iCZkDcSDGDCPggt2rne4+aqS3kGH9P/VRYO9KrAMVRi0FEAYuf2TA6tjltbwHvgKra S3UUpIt94yX69IqkffiIiX2F2Pc55p9EKPGZaIXs= Message-Id: <6.2.5.6.2.20121122031329.0b7bea18@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 22 Nov 2012 03:27:06 -0800 To: Ammar Salih From: SM In-Reply-To: <50add7b1.844f420a.69e7.78cc@mx.google.com> References: <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> <20121121.121147.74690387.sthaug@nethelp.no> <50accc0c.08ef440a.0ab6.1740@mx.google.com> <20121121.162753.74683810.sthaug@nethelp.no> <50add7b1.844f420a.69e7.78cc@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: geopriv@ietf.org, ipv6@ietf.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 11:29:28 -0000 Hi Ammar, At 23:43 21-11-2012, Ammar Salih wrote: >many cases is incorrect, so why the hassle of assigning wrong locations? And >why developers are building their applications based on incorrect >information. Developers take the data wherever they can find it. The information which is distilled from that is a best guess [1]. A RIR can be asked to "clarify that Puerto Rico is part of the United States" [2]. Regards, -sm 1. http://meetings.apnic.net/__data/assets/pdf_file/0005/23486/Lepinski-APNIC-30-Geolocation-Registry.pdf 2. https://www.arin.net/participate/acsp/suggestions/2010-2.html From joelja@bogus.com Thu Nov 22 08:31:05 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1D421F8A5C; Thu, 22 Nov 2012 08:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfWVEbKbBxrJ; Thu, 22 Nov 2012 08:31:05 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2F23E21F8A15; Thu, 22 Nov 2012 08:31:05 -0800 (PST) Received: from joels-MacBook-Air.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qAMGV0NO067117 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 22 Nov 2012 16:31:00 GMT (envelope-from joelja@bogus.com) Message-ID: <50AE533F.7010207@bogus.com> Date: Thu, 22 Nov 2012 08:30:55 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ammar Salih References: <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> <20121121.121147.74690387.sthaug@nethelp.no> <50accc0c.08ef440a.0ab6.1740@mx.google.com> <20121121.162753.74683810.sthaug@nethelp.no> <50add7b1.844f420a.69e7.78cc@mx.google.com> In-Reply-To: <50add7b1.844f420a.69e7.78cc@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 22 Nov 2012 16:31:01 +0000 (UTC) X-Mailman-Approved-At: Sat, 24 Nov 2012 03:47:57 -0800 Cc: geopriv@ietf.org, ipv6@ietf.org, marka@isc.org, sthaug@nethelp.no Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 16:31:06 -0000 On 11/21/12 11:43 PM, Ammar Salih wrote: > Dears, > > I can see almost everyone agrees to that the RIR info is not accurate and in > many cases is incorrect, so why the hassle of assigning wrong locations? And > why developers are building their applications based on incorrect > information. The RIR isn't in the business of tracking location, it's in the business of allocating resources. if you want to know the location of the party which recieved the allocation, ask an RIR. Where the block is used rather than to whom it is allocated, that is none of their business. > > And frankly speaking, I don't agree to *sending wrong location information > to protect our privacy*, it's either you send correct ones and get the > benefits of location-based services or you don't. > > Thanks, > Ammar > > > > > -----Original Message----- > From: sthaug@nethelp.no [mailto:sthaug@nethelp.no] > Sent: Wednesday, November 21, 2012 6:28 PM > To: ammar.salih@auis.edu.iq > Cc: marka@isc.org; geopriv@ietf.org; ipv6@ietf.org > Subject: Re: [Geopriv] Adding GPS location to IPv6 header > >>> You can probably get a *hint* about my location from an IP lookup. >>> You can definitely not be certain my location >> Well, with the new draft, you can do the same, location accuracy can >> be tweaked to reflect city only, or city and region..etc. > And what makes you think I'm interested in publishing this? > >>> it tells me the correct *country* for the IP. However, both the >>> region and the city are wrong. >> That is the whole point, why are we happy with providing incorrect >> information? It's even without our awareness or control. > I don't particularly *want* to publish this information. Therefore, if the > geolocation data is to a large degree wrong, that's just fine! > > My whole point was simply meant as a counterargument to your "I can simply > do ip lookup and find out your location". And my claim is that no, you can't > really "simply" do that. And I like it that way. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From ignatios@cs.uni-bonn.de Fri Nov 23 04:46:05 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4762B21F85CF; Fri, 23 Nov 2012 04:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.76 X-Spam-Level: X-Spam-Status: No, score=-4.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDQu-7F0kOyy; Fri, 23 Nov 2012 04:46:03 -0800 (PST) Received: from postfix.iai.uni-bonn.de (postfix.iai.uni-bonn.de [131.220.8.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4E10621F8600; Fri, 23 Nov 2012 04:46:00 -0800 (PST) X-IAI-Env-From: : [131.220.4.211] Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by postfix.iai.uni-bonn.de (Postfix) with ESMTP id 075D45C401; Fri, 23 Nov 2012 13:45:59 +0100 (MET) (envelope-from ignatios@cs.uni-bonn.de) (envelope-to VARIOUS) (2) (internal use: ta=0, tu=1, te=0, am=-, au=-) Received: from jaguar-alpha.cs.uni-bonn.de (jaguar-alpha.cs.uni-bonn.de [131.220.4.131]) by theory.cs.uni-bonn.de (Postfix) with SMTP id DCD4A1BC0C; Fri, 23 Nov 2012 13:45:58 +0100 (CET) Received: (nullmailer pid 1751 invoked by uid 1501); Fri, 23 Nov 2012 12:45:52 -0000 Date: Fri, 23 Nov 2012 13:45:52 +0100 From: Ignatios Souvatzis To: geopriv@ietf.org, ipv6@ietf.org Message-ID: <20121123124552.GA1860@cs.uni-bonn.de> References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com> <50a02371.86d60e0a.4f2d.02f1@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50a02371.86d60e0a.4f2d.02f1@mx.google.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sat, 24 Nov 2012 03:47:57 -0800 Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 12:46:05 -0000 On Mon, Nov 12, 2012 at 01:15:07AM +0300, Ammar Salih wrote: > If those mechanisms are successful then why websites like google > do not use them? They use IP address instead, and it's not always > about http applications, how about VoIP applications, now you need > another mechanism? .. how about detecting your preferred language > for layer-3 routing? No *this* is a very bad idea. We have lots of foreign students here, and information I'd want to look up is often more precise in English, than say, German. It's bad enough that I have to apply a dozen mouse clicks to get some websites to give me the language I want; I don't want another mechanism with an even higher perceived accuracy for that. -is From acooper@cdt.org Sat Nov 24 03:57:42 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8F821F854F; Sat, 24 Nov 2012 03:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpIej1E+w-bw; Sat, 24 Nov 2012 03:57:41 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB8321F854A; Sat, 24 Nov 2012 03:57:41 -0800 (PST) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Sat, 24 Nov 2012 06:57:36 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <50add7b1.844f420a.69e7.78cc@mx.google.com> Date: Sat, 24 Nov 2012 06:57:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50ac8fa0.e6de440a.74ed.ffffedc3@mx.google.com> <20121121.121147.74690387.sthaug@nethelp.no> <50accc0c.08ef440a.0ab6.1740@mx.google.com> <20121121.162753.74683810.sthaug@nethelp.no> <50add7b1.844f420a.69e7.78cc@mx.google.com> To: Ammar Salih X-Mailer: Apple Mail (2.1084) Cc: GEOPRIV WG , ipv6@ietf.org Subject: Re: [Geopriv] Adding GPS location to IPv6 header X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 11:57:42 -0000 Hi Ammar, On Nov 22, 2012, at 2:43 AM, Ammar Salih wrote: > I can see almost everyone agrees to that the RIR info is not accurate = and in > many cases is incorrect, so why the hassle of assigning wrong = locations? And > why developers are building their applications based on incorrect > information. If this information is for application-layer consumption, it should be = provided at the application layer. If existing application-layer = mechanisms aren't providing what developers need, they should be = improved. >=20 > And frankly speaking, I don't agree to *sending wrong location = information > to protect our privacy*, it's either you send correct ones and get the > benefits of location-based services or you don't. There is an important set of use cases where sending precise but spoofed = location information can be very important (stalking, domestic violence, = labor disputes/whistleblowing, etc.) -- when someone else who is = tracking your location needs to see a location reported other than where = you were. Again since the use context is required for supporting these, = application-layer mechanisms and controls are the best tools for = delivering this sort of privacy protection. Alissa =20 >=20 > Thanks, > Ammar=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: sthaug@nethelp.no [mailto:sthaug@nethelp.no]=20 > Sent: Wednesday, November 21, 2012 6:28 PM > To: ammar.salih@auis.edu.iq > Cc: marka@isc.org; geopriv@ietf.org; ipv6@ietf.org > Subject: Re: [Geopriv] Adding GPS location to IPv6 header >=20 >>> You can probably get a *hint* about my location from an IP lookup.=20= >>> You can definitely not be certain my location >>=20 >> Well, with the new draft, you can do the same, location accuracy can=20= >> be tweaked to reflect city only, or city and region..etc. >=20 > And what makes you think I'm interested in publishing this? >=20 >>> it tells me the correct *country* for the IP. However, both the=20 >>> region and the city are wrong. >>=20 >> That is the whole point, why are we happy with providing incorrect=20 >> information? It's even without our awareness or control. >=20 > I don't particularly *want* to publish this information. Therefore, if = the > geolocation data is to a large degree wrong, that's just fine! >=20 > My whole point was simply meant as a counterargument to your "I can = simply > do ip lookup and find out your location". And my claim is that no, you = can't > really "simply" do that. And I like it that way. >=20 > Steinar Haug, Nethelp consulting, sthaug@nethelp.no >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv >=20 From kjones@skyhookwireless.com Fri Nov 30 05:05:24 2012 Return-Path: X-Original-To: geopriv@ietfa.amsl.com Delivered-To: geopriv@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A84321F84F2 for ; Fri, 30 Nov 2012 05:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-LeawaX4QuO for ; Fri, 30 Nov 2012 05:05:23 -0800 (PST) Received: from server505.appriver.com (server505l.appriver.com [98.129.35.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E07321F84E1 for ; Fri, 30 Nov 2012 05:05:16 -0800 (PST) X-Note-AR-ScanTimeLocal: 11/30/2012 7:05:16 AM X-Note-AR-Scan: None - PIPE Received: by server505.appriver.com (CommuniGate Pro PIPE 5.4.8) with PIPE id 51833259; Fri, 30 Nov 2012 07:05:16 -0600 Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.8) with ESMTPS id 51833254 for geopriv@ietf.org; Fri, 30 Nov 2012 07:05:15 -0600 Received: from MBX02.exg5.exghost.com ([169.254.2.43]) by HT03.exg5.exghost.com ([98.129.23.45]) with mapi; Fri, 30 Nov 2012 07:05:14 -0600 From: Kipp Jones To: "WG geopriv@ietf.org" Date: Fri, 30 Nov 2012 07:05:07 -0600 Thread-Topic: geopriv activities in the press Thread-Index: Ac3O+1Y23U53bDLvQumPsQVfu9FDJg== Message-ID: <432B7A11-E882-4FDC-A172-A873226F2262@skyhookwireless.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_EA4C2996-FA5C-4A97-8E1E-084A05247F20"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Note-AR-ScanTimeLocal: 11/30/2012 7:05:15 AM X-Policy: GLOBAL - skyhookwireless.com X-Primary: kjones@skyhookwireless.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @skyhookwireless.com ALLOWED X-Note: VCH-CT/SI:0-2138/SG:1 11/30/2012 7:04:43 AM X-Virus-Scan: V-X0 X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: X-Note-Return-Path: kjones@skyhookwireless.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G328 G329 G330 G331 G335 G336 G347 G443 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER Subject: [Geopriv] geopriv activities in the press X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 13:05:24 -0000 --Apple-Mail=_EA4C2996-FA5C-4A97-8E1E-084A05247F20 Content-Type: multipart/alternative; boundary="Apple-Mail=_89415BDA-128E-4D16-B0C2-34EB3432556F" --Apple-Mail=_89415BDA-128E-4D16-B0C2-34EB3432556F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Although not mentioned directly, the press picked up some action on the = venue survey specification that the group has been working on. I = thought folks might be interested in this as well as some of the other = activities going on concurrently. =46rom the Economist yesterday: There is some light at the end of the shopping mall, however. A draft = now working its way through the Internet Engineering Task Force, a body = that develops online standards, proposes a standard set of = location-related measurements and data-rights disclosures. This would = provide a common format for wireless-signal surveys and give venue = owners a voice in how their indoor maps could be used. = http://www.economist.com/news/technology-quarterly/21567197-navigation-tec= hnology-using-satellites-determine-your-position-only-works Cheers, Kipp ..............................................=20 Kipp Jones Chief Architect/Privacy Czar kjones@skyhookwireless.com m: 404.213.9293 | @skykipp --Apple-Mail=_89415BDA-128E-4D16-B0C2-34EB3432556F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
There is some light at the end of the shopping = mall, however. A draft now working its way through the Internet = Engineering Task Force, a body that develops online standards, proposes = a standard set of location-related measurements and data-rights = disclosures. This would provide a common format for wireless-signal = surveys and give venue owners a voice in how their indoor maps could be = used.


Chief Architect/Privacy Czar
m: 404.213.9293 | = @skykipp
=

= --Apple-Mail=_89415BDA-128E-4D16-B0C2-34EB3432556F-- --Apple-Mail=_EA4C2996-FA5C-4A97-8E1E-084A05247F20 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iEYEARECAAYFAlC4rwkACgkQ9Fg8if2vNyfjAQCfa8bCR5PK4gNpJtdx32/NsPjx JwoAnA6hVmd/0xQ0vmrDV8f9CwN8eXiB =B7Bz -----END PGP SIGNATURE----- --Apple-Mail=_EA4C2996-FA5C-4A97-8E1E-084A05247F20--