Subject: Re: [Geopriv] draft-jones-geopriv-sigpos-survey

From: Kipp Jones <[email-masked]>
Date: Thu, 18 Oct 2012 08:59:47 -0500

Thanks again for all of the comments and apologies for a delayed response.  I've attempted to assimilate all of the comments and responses here and will provide an revision of the draft that incorporates these and cleans up a couple of other nits.

>>>Usage Models [Martin Thompson]
There seem to be two verydifferent usage models: (1) crowd-source, (2) contracted to do asurvey with specialized equipment  ... These models seem to be quite different, especially when one talks about licensing

On reviewing the comments and discussions, I think this issue muddies the water.  The primary purpose of this specification is for 'formal' and 'semi-formal' (directed) surveys of a given venue.  Therefore, I'm stripping out language and consideration for the 'crowdsourcing' of venue surveys and explicitly identifying this as not addressed.  I believe there will be many different models that will be experimented with for the crowdsource model and I think it is too early to try to nail down a specific model/specification to encompass these use cases.

However the process of performing a directed venue survey has been something that has been going on for years and should be able to be wrangled into a structure that supports a more common model for interoperability, privacy, and extensibility.

>Licensing / Terms of Use

There were several discussions on the topic of licensing, ownership and related topics.  I'll try to summarize and respond below.

The primary intent for including the licensing component in the specification is to provide both data provenance as well as rights declarations for usage of the data. I've simplified the structure to support a more focused set of licensing terms and clarified their meanings in this context.

As several pointed out, the idea of data 'ownership' is a tricky one, especially in light of the fact that this specification is covering signals that are broadcast and in the public spectrum.  However, it is not the signal information that is being addressed, rather the location information.  To whit, the signals are associated with locations, some of which may be within controlled access areas in a given venue.  For example, it is reasonable that a corporation would desire to have accurate indoor location within it's facilities, but they may not want this to be publicly accessible.

The specific data is a product of the venue owner that either produced it or contracted to have it produced.  Thus, there are no specific deterrents from another person/company producing a similar dataset, excepting perhaps gaining legal access to the facility for this purpose.

To make this more clear, I've changed the wording from 'owner' to 'licensor', as this better describes the relationship and allows some flexibility as to who the licensor is (venue owner, proprietor, leaser, etc.).

>>>>[Martin Thompson]: This is a minor structuring point, but I think the
location of the beacon is a property of the venue (at a point in time)
instead of a property of the survey. I see a survey as a collection of
measurements

I agree with Martin's point, the intent is for the venue owner/manager to be able to retain rights to the location data that is generated during a venue survey. Thus the rights to the location data generated by the survey is the property of the licensor.  It is feasible that somebody could surreptitiously survey a venue without the consent of the venue owner, but I don't think we want/should deal with that scenario within this specification.

>Data Usage and Rights

There is an additional issue having to do with derivative uses of the data.  Survey data at a high quality could be used to 'seed' a location system, allowing an organization to build their own beacon location database over time. At some point, the original data could be removed but the derived database could continue to be used.  For data licensors who wish to protect from this, the notion of derivative rights is included in the license structure.

>>>>[Robin Wilton]
I think the 'finesse' here might be to draw the distinction between
i - the venue owner's entitlement to exercise their rights relating to the premises, the private networks etc
ii - the rights individuals might have relating to data about them that is captured as a result of their presence/movement/actions in a given space

This specification does not address the actual determination of end users locations.  Instead, it is concerned with the rights of the Venue data licensor with respect to their hardware and the location of that data and the related signals.  And, as I noted above, I am excluding the 'crowdsource' model from this specification, thus eliminating the concerns (I hope) with respect to the location data of end users.

>>>> [Martin Thompson] it may be possible to deal with licensing declarations out of band, I am interested in hearing a clear argument for why in-band declaration of licensing in the interchange is the
right way forward

While I agree that it would be possible to deal with licensing in an out-of-band model, the lack of connectivity between the data and the licensing is at best disconcerting.  Including the terms of use with the data means that the terms travel with the data. There is no doubt about the terms.  I'm leaning on my experience with software, wherein the license terms are either spelled out within the code or have a reference to a specific license or set of terms of use.

I believe the explicit linkage of data to the license provides a stronger bond between the two and thus more assurance that the terms will be honored.

>>>Transport Mechanism
[Adam Roach]What appears to be missing is a discussion of how these documents move around the network. Based on the microphone discussion with the author, it appears that the current plan for moving this information around is something like using PUT or POST requests over https. I think it would be of great use to cover this topic, either in this document or in a separate one.

Thanks Adam, excellent call.  I will add this to the new revision.  The focus will be HTTP/TLS as transport.

Key things to consider would be:
* What https URL is used for the PUT or POST?

I would expect the URL to be service provider dependent.  Thus if Venue X produced a survey of their Venue, they would likely already be in contact with a location service provider to acquire the proper URL and credentials. It would also be reasonable for them to know their own URL in the case of self-provisioning.

  o How is it provisioned into survey devices?

The URL and credentials would be added during the configuration/set up for the survey along with additional information (e.g. Licensor information, Building location, Licensing info, etc.).

  o Is it valid to use http instead of https?

HTTPS

* What kind of authentication is used? Basic? Digest? Client certs? S/MIME signatures? Something else?

Basic over HTTPS

* What can the client infer from the HTTP response code regarding the state of the information it has submitted?

Good question. I'm using RFC5985 (HELD) as a template for defining this section.  If there is a better model, feel free to point it out.  The draft revision will include this information.

* Is there utility in defining additional transport mechanisms?

Not currently, do you think there needs to be?

  o SIP SUBCRIBE/NOTIFY?

Not sure why this would be necessary.

  o Is there value in distributing this information in Atom over HTTP?

Again, not sure the value of this. Can you elaborate?

* Do we need to define an inter-server protocol for exchanging information between survey aggregators?

I believe the same mechanism can be used for inter-aggregator communication.

>>>Capturing EMEA/Ephemerides
[Martin Thompson] You might also consider capturing ephemerides if you are capturing EMEA sentences and if you want an archival format.

I'm looking into this to see what additional value the ephemeris data would provide and how common this practice is.

>>>Privacy Concerns wrt Device Characteristics
[Martin Thompson] There are privacy implications on the use of device characteristics, useful as they are.

I believe the privacy concerns would be more applicable in a 'crowdsource' model of survey.  Do you still have concerns with respect to device characteristics in the directed survey model?

Kipp

..............................................
Kipp Jones
Chief Architect/Privacy Czar
[email-masked]<mailto:[email-masked]>
m: 404.213.9293 | @skykipp