Subject: [Geopriv] Comments on updated draft-jones-geopriv-sigpos-survey

From: "Brian Hart (brianh)" <[email-masked]>
Date: Fri, 2 Nov 2012 00:46:38 +0000

Hi Kipp

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

Minor edits:

1         "WiFi" => "Wi-Fi",

2         "regclass" => "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

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.

Basic question that I should probably know the answer to already:

7         Is there a binary version of this schema?

Regards

Brian

---

From: Kipp Jones <[email-masked]>
Date: Fri, 2 Nov 2012 13:03:30 -0400

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)" <[email-masked]> wrote:

> Hi Kipp
>  
> I am new to IETF so apologies if this email is coming at the wrong time/wrong way … if so, please do redirect me.
>  
> Minor edits:
> 1         "WiFi" => "Wi-Fi",
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: Kipp Jones <[email-masked]>
Date: Mon, 5 Nov 2012 15:02:29 -0500

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...

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

right, will correct in -02.

>> 2         "regclass" => "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 s…

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…

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.

>> 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

---

From: Kipp Jones <[email-masked]>
Date: Mon, 5 Nov 2012 16:26:58 -0500

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

---

From: "Carl Reed" <[email-masked]>
Date: Mon, 5 Nov 2012 16:53:05 -0700

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 
Sent: Monday, November 05, 2012 2:26 PM
To: Brian Hart (brianh) 
Cc: [email-masked] 
Subject: Re: [Geopriv] Comments on updated draft-jones-geopriv-sigpos-survey

Cheers,

Kipp

    Cheers,

    Kipp

      Hi Kipp

      Minor edits:
      1         "WiFi" => "Wi-Fi",

       
      Additional topics:

  Cheers,

  Kipp

      Regards
      Brian

--------------------------------------------------------------------------------
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Brian Hart (brianh)" <[email-masked]>
Date: Tue, 6 Nov 2012 17:35:15 +0000

Hi Kipp - many thanks for your thoughts - additional thoughts inline - B
From: Kipp Jones [mailto:[email-masked]]
Sent: Monday, November 05, 2012 1:27 PM
To: Brian Hart (brianh)
Cc: [email-masked]
Subject: Re: [Geopriv] Comments on updated draft-jones-geopriv-sigpos-survey

In other words, the license requirements apply only to the LIS/Location provider 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 promising 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 <[email-masked]<mailto:[email-masked]>> wrote:

On Nov 2, 2012, at 1:03 PM, Kipp Jones <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,

Kipp

On Nov 1, 2012, at 8:46 PM, "Brian Hart (brianh)" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kipp

Minor edits:
1         "WiFi" => "Wi-Fi",
[:)]

[:)]

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
[Yes]
Are you aware of a standard format for this data or would that need to be part of this specification?
[Oops - more research required ... I was just at the conceptual/example stage, and I suspect 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:

Good question.  I don't have a great answer yet.  Let me chew on it some more.
[As above, happy to work with you offline to refine some ideas.]

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 thinking 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 :(. 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. This 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 retrieving site survey information from a local server to form a location estimate - and directly fuse it with other location sources such as GPS and sensors. 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.]

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. Thinking about your latter point, which was very stimulating, I was looking at RFC4119 to confirm that "should" was used there too. Rather I found "permitted" - .
"
'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-requested geopriv. Ditto for anything that IEEE might standardize.]

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?
[That's the reference - yes, many thanks!]

Cheers,

Kipp

Regards
Brian

_______________________________________________
Geopriv mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/geopriv