Using Device-Provided Location-Related Measurements in Location Configuration Protocols
draft-ietf-geopriv-held-measurements-09

[Ballot comment]
I didn't check these comments against -09, they may
have been taked into account (or not:-)

- 4 IPR declarations and we start our 70 pages with "A
method is described" ... that gives me patent-cringe (sorry
for the snark;-)

- section 2: "Location-related measurement data does not
identify a Device" - that is too absolute, such data
certainly can identify a Device and a user (even if it
changes over time).

- section 3, 2nd last para: there are privacy issues even
without 3rd parties.

- section 3, last para: s/security/security and privacy/

- 4.1.1: last sentence - is that SHOULD correct? What do I
do if I'm not abiding by the SHOULD? e.g. can I put in 2
timestamps in one measurement element? If not, then isn't
that a MUST?

- 4.1.2: How do I know if an expires means which of these
things and how do they really differ? I can't see how a LIS
can programatically know that.

- 4.2 & 4.2.1: Don't you need to say how to calculate the
RMS error? Won't coders do different things otherwise?

- 5.4, typo: s/cellar/cellular/ nice typo if you consider
how serial killers in movies might make use of this
protocol though:-)

- 5.5.1, I wondered why there are no initial registrations
for e.g. Russian or Chinese GNSS systems. Not objecting but
I'm curious.

- 7.1.5, 1st sentence is broken, not sure what's meant

[Ballot discuss]

Thanks for clearing my discuss points. The IPR declaration
check/clear-up is the only remaining issue. Ping me when
you think that's sorted (or if its sorted already, sorry but
I've forgotten, and you need to ping me again:-)

(2) There are a bunch of IPR declarations on this. I didn't
see where the WG had discussed those. Can someone point me
at the relevant bit of WG archive or minutes? I did see
discussion on IPR related to 4119 but I've no idea if
that's the same thing or not. I'm also not clear if the 4
declarations are really one or not, but I expect the WG
know, so I'm just checking that the WG did consider all
that and were ok to proceed. (The write-up says there is
one disclosure and that was discussed, but I see 4, hence
the question, maybe its just the writeup or maybe all 4 are
really one thing, I dunno.)

[Ballot comment]

I didn't check these comments against -08, they may
have been taked into account (or not:-)

- 4 IPR declarations and we start our 70 pages with "A
method is described" ... that gives me patent-cringe (sorry
for the snark;-)

- section 2: "Location-related measurement data does not
identify a Device" - that is too absolute, such data
certainly can identify a Device and a user (even if it
changes over time).

- section 3, 2nd last para: there are privacy issues even
without 3rd parties.

- section 3, last para: s/security/security and privacy/

- 4.1.1: last sentence - is that SHOULD correct? What do I
do if I'm not abiding by the SHOULD? e.g. can I put in 2
timestamps in one measurement element? If not, then isn't
that a MUST?

- 4.1.2: How do I know if an expires means which of these
things and how do they really differ? I can't see how a LIS
can programatically know that.

- 4.2 & 4.2.1: Don't you need to say how to calculate the
RMS error? Won't coders do different things otherwise?

- 5.4, typo: s/cellar/cellular/ nice typo if you consider
how serial killers in movies might make use of this
protocol though:-)

- 5.5.1, I wondered why there are no initial registrations
for e.g. Russian or Chinese GNSS systems. Not objecting but
I'm curious.

- 7.1.5, 1st sentence is broken, not sure what's meant

[Ballot discuss]
One point remains from discussion; discussion pasted here for reference:

Barry:
>> There's probably just something basic I'm missing here, and when you tell me
>> I'll slap myself on the forehead.
>>
>> -- Section 3 --
>>    Location-related measurement data need not be provided exclusively by
>>    Devices.  A third party location requester can request location
>>    information using measurement data, if they are able and authorized.
>>
>> I am now confused.  Based on what I've read up to this point, I thought that
>> devices were giving the LIS measurement data, the LIS was using that to aid in
>> figuring out the locations of the devices, and then whenever any query was
>> made for a device's location, the LIS would give out whatever location it had
>> for the device, as long as the requestor was authorized to make the query.
>>
>> But now I'm not sure that's right.  I now think that the device asks for its own
>> location, and as part of the query it gives the measurement data.
>>  Do I have that right?  Or am I really completely confused?

Martin:
> Yes, the device requests its own location, providing measurement data along
> with the query.
>
> In the simple case, measurement data is only used for serving the request that
> it is contained in.  Though location by reference complicates things.  I've added
> a paragraph to the overview to make this clearer.

Barry:
I can't find that paragraph.  Can you point it out to me, please?

[Ballot comment]
Adrian:  I regret that we have not devised a way for a device to determine its location without giving away its location.

we have, (gps/loran/glonas/gnss).

unidirectional flows of information in general don't reveal much about the receiver .

using the network has a certain convenience factor, notwitstanding the commercial incentives for doing so.

I think there's enough discusses that cover any concerns I do have to ballot this as no objection on the basis that they will be responded to, to someone's satisfaction.

[Ballot comment]
As I observed in my Abstain on RFC 6772, I am not comfortable with the
motivation for this work, but I (of course) accept that there is a
working group chartered to do the work and that there is support from
part of the community.

In this document my concern manifests that, under the guise of a device
doing something to find out where it is located, the device supplies
information to a third party that allows that third party to work out
where is is located and then (possibly) report back to the device. I
can't see how that is consistent with privacy and I regret that we have
not devised a way for a device to determine its location without giving
away its location.

The argument that a Device does not have to supply information to an LIS
or ask for its location is true. However, I am exceedingly doubtful that
such features will be off by default or that they will be configurable
by the average user. We should be looking for ways to improve function
for the user without sacrificing privacy or security.

It is almost certain that this work could be turned around to allow the
Device to request, and the LIS to supply, information that the Device
could use together with its own measurements to determine its location.
Such an approach is computationally identical, but moves the venue of
the computation to the Device and so preserves privacy.

It seems doubtful that there is anything that the authors can do to this
document to resolve my concerns, and so rather than force a debate with
unlikely positive outcome, I will Abstain on this document.

---

There are so many Discusses and Comments on this document it is hard to
find something new to say. I would observe that I found the document
generally quite readable, and that the techncial work seems sound modulo
the concerns expressed by others.

---

Need to expand LIS in the Abstract.

---

4.1.2

  A Device can use this attribute to prevent the LIS
  from retaining measurement data or limit the time that a LIS retains
  this information.

I doubt this! I think the attribute is a request. The device cannot
actually control the LIS. And this is not mitigated by:

  The LIS MUST NOT keep location-related measurement data beyond the
  time indicated in the "expires" attribute.

You are attempting to use 2119 language to constrain implementations of
function that are not relevant to bits on the wire. Such statements are
at best false comforts. It would be better to not include them.

Perhaps there is a relationship to how the information is used in the
scope of this document that you *can* say. For example:

  The LIS MUST NOT use location-related measurement data to determine
  location information returned to the Device beyond the time indicated
  in the "expires" attribute.

---

6.1

  It is less desirable to distribute measurement data in the same
  fashion as location information.  Measurement data is less useful to
  location recipients than location information.  Therefore, a simple
  distribution model is desirable.

I think there is a double negative here. If there is an implicit
statement that location information is distributed in a privacy-safe
way, then you are probably saying that the measurement information is
less privacy-sensistive and could be distributed in a less privacy-safe
way. But that is not "it is less desirable" which would mean there is a
desire not to. Maybe "there is less need".

---

6.1

  No entity is permitted to redistribute measurement data.  The Device
  directs other entities in how measurement data is used and retained.

You surely understand that writing this in an RFC will not actually
have any impact on what implementations of an LIS do, or what the NSA
instructs operators to do. [Other secret agencies also exist.]

What, then, is the value of this statement?

Ditto 6.2

  A LIS MUST NOT reveal location-related measurement data or location
  information based on measurement data to any other entity unless
  directed to do so by the Device.

[Ballot comment]
This is a style nit; feel free to ignore, but consider this text:

  In the HELD protocol, the inclusion of a measurement request in an
  error response with a code of "locationUnknown" indicates that the
  LIS believes that providing the indicated measurements would increase
  the likelihood of a subsequent request being successful.

Of course, the LIS has no beliefs.  Rather, the LIS has capabilities—it can make use of certain types of information, and might want to indicate to the peer that measurements of that type might result in a location result being determined where none can presently be determined.  So I would phrase it thusly (and probably incorrectly—I'm just doing this to illustrate my gripe):

  In the HELD protocol, the inclusion of a measurement request in an
  error response with a code of "locationUnknown" indicates that the
  LIS has the capability to use the indicated measurements to increase
  the likelihood of a subsequent request being successful.

As I say, this is a style gripe, and if you want to just ignore it, I won't complain.  The use of the term "believes" to refer to capabilities also occurs earlier in this section, and may occur elsewhere in the document—I don't know because I haven't finished reading yet, but I won't call out any more of these that I see, since I think this gets the point across.

  Though many of the
  underlying protocols support extension, creation of specific XML-
  based extensions to the measurement format is favored over
  accommodating protocol-specific extensions in generic containers.

By "is favored" do you mean "works better because of X" or "we recommend as a standard practice for consistency" or something else?  It might be better to use the active voice here and be more explicit about what you mean.  This may be unnecessary for readers who are already deeply familiar with geopriv, so feel free to ignore this, but as a relatively naive reader I am left somewhat confused by this advice.

The definition for giaddr says the address is a dotted quad or an IPv6 address, but in the example you use an IPv6-encoded IPv4 address.  This seems contradictory.  If dotted quads and IPv6-encoded IPv4 addresses are interchangeable, the normative text should say so, but why create the opportunity for trouble here?  If it were up to me I would require dotted quad for IPv4 and IPv6 address representations only for IPv6 addresses.

In 5.3, this doesn't parse:

  parameter:  The "parameter" element identifies an optional
      measurements are requested for each measured access point.

I think someone might have made a cut-and-paste error here.  I don't know what this text is supposed to say, so I can't suggest an edit, but you ought to fix this prior to publication.

In 7.1.3, Would a LIS ever use GPS information provided by handsets in combination with WiFi information provided by mobile nodes to populate a mapping database that could then be used to determine locations of other mobile nodes that don't have GPS receivers?  IOW, is one benefit of this sort of attack that you could corrupt the LIS' measurement map?

In 8.6, the enterprise number is given as optional, but the field is always present in the remote ID option.  So why is it optional in the XML?

Cool stuff.

[Ballot comment]
This geopriv draft did not disappoint! My usual paranoid reaction of "oh my ... really" and "wow ... just think about the privacy issues" was topped by Stephen's reaction ... so what he said plus these nitty-nits: 

s1: r/otherwise/other metric ?

s4.1.1: r/The "time" attribute is optional
        /The "time" attribute is OPTIONAL
  Actually this happens in a lot of places in the draft.  Should the schema requirements match the text requirements?

s4.1.2: What's the requirement for support of the time attribute?
        Should the same statement about multiple measurement(s) be copied here too because expiry time is linked to measurement(s)?

s4.2: over a period of time redundant?: more than once over a period
    of time

s4.2: Is a very large value 100 or 10000000?  Maybe just say:

    If omitted, this value can be assumed to be a
    large enough so that the RMS error is an indication of the
    standard deviation of the sample set.

s5.4: Should WiMAX be listed here?

[Ballot discuss]

As a bit of background, geopriv's security and privacy
model does my head in (that's my fault, not yours;-).
I really do appreciate the obvious effort that's been
devoted to security and privacy issues in this draft, but
yet again, I don't see how it all adds up to being other
than privacy unfriendly. That said, I have a number of
specific discuss points - some of 'em should be very easy
to clear, so don't be put off that there's so many. There
may also be some that can be cleared based on a bit more
text describing the schema, which I didn't go over fully.

(1) I think this draft needs to say that a device MUST
include some interface(s) that allows for user or sysadmin
control over what measurements will be sent and to whom. I
don't think that can be done in a single sentence so I'm
not sure right now how to fix this. You may argue that
those controls are elsewhere in the geopriv set of RFCs,
but I didn't see any references that helped me on this. So
putting this as a question: how is an implementer supposed
to know when to just send a requested measurement and when
to not send some?  (If all implementers just make this up,
then the only way to get good interop seems to be if all
coders send all the measurements that they can all the
time.)

(2) There are a bunch of IPR declarations on this. I didn't
see where the WG had discussed those. Can someone point me
at the relevant bit of WG archive or minutes? I did see
discussion on IPR related to 4119 but I've no idea if
that's the same thing or not. I'm also not clear if the 4
declarations are really one or not, but I expect the WG
know, so I'm just checking that the WG did consider all
that and were ok to proceed. (The write-up says there is
one disclosure and that was discussed, but I see 4, hence
the question, maybe its just the writeup or maybe all 4 are
really one thing, I dunno.)

(3) section 3 says: "Use of location-related measurement
data is at the discretion of the LIS" - that's ambiguous
and in a possibly bad way. I think you mean that the LIS
can use the data its given in order to estimate a location
using any algorithm. There are two ambiguities in how its
stated though: a) it might be read as saying that the LIS
is in charge of telling the Device what location-related
measurements are to be supplied, and b) it might be read as
saying that the LIS can do whatever it wants with the
measurements, e.g. send all measurements off to big brother
for archiving or to a marketing company without asking.
Both a) and b) should be stated as not being at the
discretion of the LIS and the statement ought be
unambiguous.

(4) 4.1.2: What does "MUST NOT keep" mean? If the request
containing the measurements was logged has the LIS "kept"
the measurement?  I think you need to be clear on that. I'd
prefer if you said it means yes, the measurements MUST NOT
be logged. But will implementers really do that? If not,
then it seems that the draft is at least a bit misleading.

(5) 4.3: could a compromised LIS mount a nice DoS on a
network by asking a lot of devices to make many
measurements that impact on those devices but maybe also on
the n/w as a whole? Is that threat noted?  Should you
RECOMMEND that devices have some way to sanity check what
they're asked to do by/for a LIS?

(6) 5.1, if LLDP measurements expose IP addressing then
that may a) expose topology information that a sys admin
would rather hide and b) involve sending private IP
addresses over the public Internet. Don't you need to note
those issues and say how to deal with them? You do approach
saying that in section 6/7 but I think you need to be more
explicit and say which pieces of measurement information
are sensitive in which ways (e.g. by adding a list of them)
so that implementers can get this right.  As-is, I don't
think there's enough information in the draft for coders to
do a good job.

(7) 5.2, (just checking) - aren't there models for using
DHCP where the subscriber-id is considered sensitive
information? I seem to recall some cases like that but
didn't check. Did you?

(8) 5.2, if I tell the LIS my DHCP relay/server address
doesn't that allow the LIS to start pretending to be that
DHCP server in some networks? I didn't see that noted in
section 7.

(9) 5.3, Why is so much information about an AP allowed to
be sent? Why is that all needed? 

(10) section 6, why don't you say that measurement data
MUST be afforded the same protection as location
information and then say what that means for interop, e.g.
that if location data has to go via TLS, then so MUST
measurement data?

(11) 6.1, "No entity is permited to redistribute
measurement data" also needs a MUST NOT I think, as in "A
LIS MUST NOT redistribute measurement data." But then in
6.2 you (twice) say "unless directed to do so by the
Device" - I didn't get how a device can do that?

(12) 6.3 - I just want to check since I don't think I get
the implications. When would a device request a location
URI? What does "use the measurement data in serving
requests" mean? If it means, use the measurements to
generate the URI and location information that seems ok
(modulo the 1st question). If it means "also expose the
measurement when the location URI is de-referenced" that'd
be problematic I think.

(13) 6.4 - I don't understand how the "MUST be trusted" by
the LIS thing works. Can you explain?  And if that's not
covered here, where it it specified?  Otherwise how can it
be implemented so as to achieve interop?

(14) 7.1 - why are threats caused by a LIS revealing
location measurements or location information not part of
the threat model?

(15) 7.1.1 - I don't get this - are you saying that knowing
measurement data alone is enough to convince any LIS to
hand over location information? That would seem fatal if
true so I must be missing something.

(16) 7.2.1 to 7.2.3 - what are the mitigations here that I
can implement? I don't see 'em.

(17) 7.2.4 - this has a MUST saying to put "trusted"
location information first, but doesn't say how to decide
if location information is trusted or not so how can I
implement that MUST?

(18) 7.2.5 - I don't understand what "stateful examination"
might mean here so how can I implement something? Can you
clarify what you mean?

[Ballot comment]

- 4 IPR declarations and we start our 70 pages with "A
method is described" ... that gives me patent-cringe (sorry
for the snark;-)

- section 2: "Location-related measurement data does not
identify a Device" - that is too absolute, such data
certainly can identify a Device and a user (even if it
changes over time).

- section 3, 2nd last para: there are privacy issues even
without 3rd parties.

- section 3, last para: s/security/security and privacy/

- 4.1.1: last sentence - is that SHOULD correct? What do I
do if I'm not abiding by the SHOULD? e.g. can I put in 2
timestamps in one measurement element? If not, then isn't
that a MUST?

- 4.1.2: How do I know if an expires means which of these
things and how do they really differ? I can't see how a LIS
can programatically know that.

- 4.2 & 4.2.1: Don't you need to say how to calculate the
RMS error? Won't coders do different things otherwise?

- 5.4, typo: s/cellar/cellular/ nice typo if you consider
how serial killers in movies might make use of this
protocol though:-)

- 5.5.1, I wondered why there are no initial registrations
for e.g. Russian or Chinese GNSS systems. Not objecting but
I'm curious.

- 7.1.5, 1st sentence is broken, not sure what's meant

[Ballot discuss]
4.1.1. Time of Measurement
Do you require synchronized times between the Device and the LIS, or it doesn't matter because you don't need to correlate any information from different Devices?
AFAICT, the following sentence implies that synchronization is required:

  The LIS MUST NOT keep location-related measurement data beyond the
  time indicated in the "expires" attribute.

AFAICT, the LIS coul combine information from the Device and from the Third Party (other), so time synchronization is required between Device and Third Party devices as well.
I see section 4.2.1, but don't find the information in there.

Background: This is the typical syslog situation for which the NMS doesn't know if the time is synchronized.
The convention (at least in Cisco, http://www.cisco.com/en/US/technologies/collateral/tk869/tk769/white_paper_c11-557812.html) is:

    * Means that time is not authoritative: the software clock is not in sync or has never been set.
    The * (asterisk) and. (period) characters preceding a syslog message are indicators of a problem with NTP.

[Ballot comment]
- On the edge of being a DISCUSS... Not too happy about the "measurement" term.
http://www.collinsdictionary.com/dictionary/english/measurement?showCookiePolicy=true
I wonder what the measurement is: ATM VPI/VCI, VLAN STAG/CTAG, RADIUS fields, L2TP IP address/session, etc.. So basically these are not measurements, simply observed metadata, observed context information. Can you give one example of an attribute that is actually measured?
To prove my point, the definition correctly speaks about "physical properties", not measurement

    Location Measurement:  An observation about the physical properties
    of a particular Device's network access.

I don't know the WG history behind this term, but it confused me. I'll leave that point to the AD to make the right decision.


- without basic information about LCP and LIS (described in the introduction), the abstract didn't make sense to me. I had to read it multiple times to understand whether it was the device sending its location to the LIS for a kind of registration, or the LIS using clues (location- related measurement data) received from the device in order to generate more precisely the location for the device.
The introduction text helped me understand the abstract.
I wish the abstract would be unambiguous. You know, something such as:

  A method is described by which a Device is able to provide
  location-related measurement data that gives the location information server
  extra context information in order to help in a more precise estimation
  of the Device location.
  ...


EDITORIAL
- expand LIS in the abstract
-
  parameter:  The "parameter" element identifies an optional
      measurements are requested for each measured access point.

[Ballot discuss]
Discussion between Martin and Suresh (based on Suresh's Gen-ART review) resulted in an agreement to make some changes. Shouldn't we wait for the agreed changes to be submitted in a -08 before approving this document?

[Ballot comment]
4: The example in section 4 shows a "lm:measurements" element, and many examples in section 5 show a "measurements" element, but the text in 4.1 talks about a "measurement" element, and I only find a "measurement" element example in section 4.3. Which one is section 4.1 (and 4.1.1, 4.2, 4.2.1, and 4.3) intending to talk about?

4.1.1:

  The "time" attribute is optional...  However, time SHOULD
  be provided whenever possible.

I think your uppercasing is reversed. The "time" attribute is, as far as I can tell, OPTIONAL, in that it is not required for interoperation, but it should (or perhaps "is helpful to") be provided whenever possible.

4.1.2:

  A Device can use this attribute to prevent the LIS
  from retaining measurement data or limit the time that a LIS retains
  this information.
  [...]
  The LIS MUST NOT keep location-related measurement data beyond the
  time indicated in the "expires" attribute.

Is this a privacy requirement or is there some other reason why a device would want to "prevent" retention? Making expires mean something other than simple validity and making it a hard requirement to dispose of the data seems to indicate something is going on here that is unstated. If it's a privacy requirement, instead of putting the MUST here, just put a forward pointer to section 6.

[Ballot comment]
I'm a No Objection, but agree with Barry's Discuss on 7.1.5.

My comments follow. In general, I thought this document was fairly easy to follow given the breadth of networking and location measurement technologies being discussed, and wanted to note that the security considerations section reflected a lot of work.

In 3.  Location-Related Measurements in LCPs

  Use of location-related measurement data is at the discretion of the
  LIS, but the "method" parameter in the Presence Information Data
  Format - Location Object (PIDF-LO) [RFC4119] SHOULD be adjusted to
  reflect the method used.

Could you help me understand why this is an RFC 2119 SHOULD?

On the same page, in this text:

  Location-related measurement data need not be provided exclusively by
  Devices.  A third party location requester can request location
  information using measurement data, if they are able and authorized.

I'm somewhat confused because of a "requester/they" mismatch, so I'm not sure what noun "they" refers to, but I'm also confused by "can do foo if they are able". I'm not sure what "are able" means in this context.

In 4.1.1.  Time of Measurement

  The "time" attribute is attached to the root "measurement" element.
  If it is necessary to provide multiple sets of measurement data with
  different times, multiple "measurement" elements SHOULD be provided.

I am curious why this is a SHOULD, but I'm more curious if it's obvious how you provide multiple sets of measurement data from different times without providing multiple "measurement" elements. What did I miss?

I have the same questions about this text in 4.2.1.  Time RMS Error

  The "timeError" attribute does not apply where multiple samples of a
  measurement are taken over time.  If multiple samples are taken, each
  SHOULD be included in a different "measurement" element.

In 5.  Location-Related Measurement Data Types

  All included measurement data definitions allow for arbitrary
  extension in the corresponding schema.  As new parameters that are
  applicable to location determination are added, these can be added as
  new XML elements in a unique namespace.

I'm reading this "as parameters are added, these can be added". I'm pretty sure you're saying more than that. Perhaps "as new parameters are added in foo, they can also be added as new XML elements"? If so, including "in foo" would be helpful to newer readers.

In 5.3.  802.11 WLAN Measurements

  regclass:  The regulatory domain and class.  The "country" attribute
      optionally includes the applicable two character country
      identifier (dot11CountryString), which can be followed by an 'O',
      'I' or 'X'.  The element text content includes the value of the
      regulatory class: an 8-bit integer in decimal form.

if you could include an expansion of "o"/"I"/"X", and for a bonus include a reference, that would be lovely.

In 5.3.1.  Wifi Measurement Requests

  Two elements are defined for requesting WiFi measurements in a
  measurement request:

  type:  The "type" element identifies the desired type (or types that
      are requested.

is it obvious from the specification what the requester will get if the desired type(s) are not available? Something not desired, or nothing, or ...

In 5.4.  Cellular Measurements

  MCC and MNC are provided as digit sequences; a leading zero in an MCC
  or MNC is significant.  All other values are decimal integers.

We've had some extended discussions recently about numeric strings with a leading zero being assumed to be octal, and the broader IETF community is not of one mind on whether that's true or not. Based on those conversations, it might be helpful to add "... and the digit sequences must not be interpreted as octal integers".

In 5.5.3.  Per-Satellite Measurement Data

  codephase:  The observed code phase for the satellite signal,
      measured in milliseconds.  This is converted the system-specific
      value of chips or wavelengths into a system independent value.

The last sentence in this definition seems to be garbled.

In 7.1.4.  Measurement Replay

  For properties of a network, time-invariance is often directly as a
  result of the practicalities of operating the network.  Limiting the
  changes to a network ensures greater consistency of service.  A
  largely static network also greatly simplifies the data management
  tasks involved with providing a location service.

I happen to agree with this - and I managed a group that administered a network for three years, so that's based on my own experience - but I'm not sure why this is a security consideration. Is it actionable? Other than recognizing that "if you change stuff less, you'll screw stuff up less", how does a network operator respond to this reasonable observation?

In 7.1.4.  Measurement Replay

  Requesting additional supporting observations can reduce the size of
  the region over which location information can be altered by an
  attacker, or increase trust in the result, but each additional has a
  cost. 

This sentence is garbled, or a word is missing, or ...

In 7.2.4.  Attribution

  Including an authenticated identity for all sources of measurement
  data is presents a number of technical and operational challenges.

This sentence is garbled.

In 10.  Acknowledgements

  Thanks go to Simon Cox for his comments relating to terminology that
  have helped ensure that this document is aligns with ongoing work in
  the Open Geospatial Consortium (OGC).

I think "is aligns with" is just an editorial problem, but mention it during IESG evaluation because I don't know that.

[Ballot discuss]
Three points I'd like to clarify, please:

1...
There's probably just something basic I'm missing here, and when you tell me I'll slap myself on the forehead.

-- Section 3 --
  Location-related measurement data need not be provided exclusively by
  Devices.  A third party location requester can request location
  information using measurement data, if they are able and authorized.

I am now confused.  Based on what I've read up to this point, I thought that devices were giving the LIS masurement data, the LIS was using that to aid in figuring out the locations of the devices, and then whenever any query was made for a device's location, the LIS would give out whatever location it had for the device, as long as the requestor was authorized to make the query.

But now I'm not sure that's right.  I now think that the device asks for its own location, and as part of the query it gives the measurement data.  Do I have that right?  Or am I really completely confused?

And how do third parties "request location information using measurement data"?  Where do they get the measurement data from?  Did the device they're asking about give it to them, too?

2...
-- Section 7.1.5 --

  Measurement data that is susceptible to this sort of influence MUST
  be treated as though it were produced by an untrusted Device for
  those cases where a location recipient might attribute the location
  information to the LIS.

That's a very strong MUST: in order to have a MUST here, I think you have to be sure you've completely identified the "data that is susceptible to this sort of influence", or at least given enough information that implementors can reliably and completely do the identification.  That strikes me as a tall order, and I don't think you've met that here.

3...
-- Section 7.2.1 --

  Independent confirmation of the veracity of measurement data ensures
  that the measurement is accurate and that it applies to the correct
  Device.  By gathering the same measurement data from a trusted and
  independent source, the LIS is able to check that the measurement
  data is correct.

I don't understand: if the LIS can do that, what value is there in having the device sent it?  Isn't the whole point of this protocol that having the LIS do that is not possible, or is too difficult or expensive?

[Ballot comment]
Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:

-- Section 8 --
I did not review the schemas.  The shepherd says she has passed them through an automated validator, but that expert review of them is not necessary.  As these are variations on other, similar geopriv schemas, I think it's OK to accept that assessment, though I'd be happier to have some idea that they were at least thoroughly reviewed by the working group, and not just glossed over as routine.


-- Section 3 --
  Use of location-related measurement data is at the discretion of the
  LIS, but the "method" parameter in the Presence Information Data
  Format - Location Object (PIDF-LO) [RFC4119] SHOULD be adjusted to
  reflect the method used.

I don't see any connection between the bit before the "but" and the bit after it, so the conjunction seems weird.  If the "method" parameter is meant to give the LIS useful information for deciding whether to use the data, then it would help to say so.

-- Section 4 --

  The "time" attribute is attached to the root "measurement" element.
  If it is necessary to provide multiple sets of measurement data with
  different times, multiple "measurement" elements SHOULD be provided.

I don't understand the SHOULD: what's the alternative?  If it's *necessary* to provide multiple sets with different times, it seems to me that the *only* way to do that is to use multiple "measurement" elements.

-- Section 5.3 --
In the definition of regclass:
      which can be followed by an 'O',
      'I' or 'X'.

...which mean what?  You have no citation here, as you do in some of the other definitions, so I don't know where to find the meaning.

-- Section 7.1.5 --

In the discussion of altering radio signal strength, you say this:

  Note:  This particular "attack" is more often completely legitimate.
      Radio repeaters are commonplace mechanism used to increase radio
      coverage.

Well, sure, but by discussing radio signal strength here you're talking about situations when measuring the signal strength matters.  There had better NOT be a legitimate repeater involved in any situation of that sort!

-- Section 7.2.3.2 --

  Any
  costs in acquiring supporting observations are balanced against the
  degree of integrity desired of the resulting location information.

I think this is a really important, general point in this whole discussion, and shouldn't be hidden down here in the outback.  I think you should change "acquiring supporting observations" to "validation", and move that sentence up to Section 7.2.

========
Other comments; no need to respond to these. Take them or modify them
as you please:

Please expand "LIS" in the abstract.

-- Introduction --
  A location information server (LIS) is the server that
  provides location information; information that is available due to
  the knowledge about the network and physical environment that is
  available to the LIS.

The semicolon is the wrong punctuation for that: a comma will work, or perhaps a colon, but not a semicolon.  But anyway, it's an odd sentence.  The first part is too obvious to mention.  How about this?:

NEW
  A location information server (LIS) is the server that
  provides location information that is available due to the
  knowledge it has about the network and physical environment.

(or I might say "...that is derivable from the knowledge...").

  As a part of the access network, the LIS is able to acquire
  measurement results from network Devices within the network that are
  related to Device location.

This looks like it's the Devices that are related to Device location.  I think you mean that the measurement results are related to Device location.  Try this:

NEW
  As a part of the access network, the LIS is able to acquire,
  from network Devices within the network, measurement results that
  are related to the locations of those Devices.

I would also remove the "However," at the end of the paragraph.

-- Section 3 --
  Measurement data that the LIS does not support or understand can be
  ignored.

This is a sentence that just screams for active voice: is there any entity that would ignore it other than the LIS?

NEW
  The LIS can ignore measurement data it does not support or understand.

-- Section 4 --
  In the HELD protocol, the inclusion of a measurement request in an
  error response with a code of "locationUnknown" indicates that the
  LIS believes that providing the indicated measurements would increase
  the likelihood of a subsequent request being successful.


Someone recently said, "Servers hate to be anthropomorphized."  I don't think any location information server *believes* anything.  Maybe remove "the LIS believes that"?  And maybe also avoid two consecutive uses of "indicate" while you're about it?


-- Section 5.3.1 --
      The "parameter" element identifies an optional
      measurements are requested for each measured access point.

You have a number disagreement and what appears to be a missing word; please fix this sentence.

-- Section 5.4 --
  Cellular Devices are common throughout the world and base station
  identifiers can provide a good source of coarse location information.
  This information can be provided to a LIS run by the cellar operator,
  or may be provided to an alternative LIS operator that has access to
  one of several global cell-id to location mapping databases.

The second sentence mentions the "cellar operator".  Perhaps too much wine was involved, which could explain a lot.  The second sentence starts with "This information", which appears to refer to the "coarse location information."  But I think, from the rest of the sentence, that you mean it to refer to the "base station identifiers".  If that's so, the sentence should start with "These identifiers can be provided".

-- Section 7 --
  A Device that provides location location-related measurement data
  might use data to:

You're one short: the punch line to the old joke is "Location, location, location."

-- Section 7.1.2 --
  Allowing requests with measurements might be used to collect
  information about a network topology.  This is possible if requests
  containing measurements are permitted.

As "allow" and "permit" are synonyms, I bet you can see how these two sentences don't go together.

-- Section 7.1.3 --
Another sentence that needs some fixing:

  Some types of measurement data are relatively easy to falsify in a
  way that the resulting location information to be selected with
  little or no error.

You're doing a lot of repeating in this section:

  An attacker gains if they are able to coerce the LIS into providing
  location information based on falsified measurement data and that
  information can be attributed to the LIS.

Some variation on that is stated in paragrahs 1, 3, 4, 5, and 7.  They don't all say exactly the same thing, of course, but I found myself saying, "Yes, they said that already," and then, "THEY SAID THAT ALREADY!"  Please have a look through here and see how you might better organize Section 7.1.3 to minimize that effect.  (Along the same line, I'll note that paragraph 8 says exactly the same thing twice.)

-- Section 7.1.5 --

  Some types of measurement data can be altered or influenced by a
  third party so that a Device.

Yes...?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-geopriv-held-measurements-07. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible.

IANA understands that, upon approval of this document, there are three IANA actions which must be completed.

First, a new registry will be created called the "Global Navigation Satellite System (GNSS) types."

The new registry will be maintained through "Specification Required" as defined in RFC 5226. An expert reviewer will also be provided for the new registry.

Each entry in the registry requires the following information:

GNSS name: the name of the GNSS

Brief description: a brief description of the GNSS

GNSS token: a token that can be used to identify the GNSS

Signals: a set of tokens that represent each of the signals that the system provides

Documentation reference: a reference to one or more stable, public specifications that outline usage of the GNSS, including (but not limited to) signal specifications and time systems.

The initial contents of the registry:

  GNSS name:  Global Positioning System (GPS)

  Brief description:  a system of satellites that use spread-spectrum
      transmission, operated by the US military for commercial and
      military applications

  GNSS token:  gps

  Signals:  L1, L2, L1C, L2C, L5

  Documentation reference:  Navstar GPS Space Segment/Navigation User
      Interface [GPS.ICD]


  GNSS name:  Galileo

  Brief description:  a system of satellites that operate in the same
      spectrum as GPS, operated by the European Union for commercial
      applications

  GNSS Token:  galileo

  Signals:  L1, E5A, E5B, E5A+B, E6

  Documentation Reference:  Galileo Open Service Signal In Space
      Interface Control Document (SIS ICD) [Galileo.ICD]


Second, in the IETF XML namgespace registry located at:

http://www.iana.org/assignments/xml-registry/xml-registry.xml#ns

the following nine new namespaces will be registered as follows:

ID: geopriv10:lmsrc
URI: urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
Filename: ns/geopriv10/lmsrc.txt
Reference: [ RFC-to-be ]

ID: geopriv:lm
URI: urn:ietf:params:xml:ns:geopriv:lm
Filename: ns/geopriv/lm.txt
Reference: [ RFC-to-be ]

ID: geopriv:lm:basetypes
URI: urn:ietf:params:xml:ns:geopriv:lm:basetypes
Filename: ns/geopriv/lm/basetypes.txt
Reference: [ RFC-to-be ]

ID: geopriv:lm:lldp
URI: urn:ietf:params:xml:ns:geopriv:lm:lldp
Filename: ns/geopriv/lm/lldp.txt
Reference: [ RFC-to-be ]

ID: geopriv:lm:dhcp
URI: urn:ietf:params:xml:ns:geopriv:lm:dhcp
Filename: ns/geopriv/lm/dhcp.txt
Reference: [ RFC-to-be ]

ID: geopriv:lm:wifi
URI: urn:ietf:params:xml:ns:geopriv:lm:wifi
Filename: ns/geopriv/lm/wifi.txt
Reference: [ RFC-to-be ]

ID: geopriv:lm:cell
URI: urn:ietf:params:xml:ns:geopriv:lm:cell
Filename: ns/geopriv/lm/cell.txt
Reference: [ RFC-to-be ]

ID: geopriv:lm:gnss
URI: urn:ietf:params:xml:ns:geopriv:lm:gnss
Filename: ns/geopriv/lm/gnss
Reference: [ RFC-to-be ]

ID: geopriv:lm:dsl
URI: urn:ietf:params:xml:ns:geopriv:lm:dsl
Filename: ns/geopriv/lm/dsl
Reference: [ RFC-to-be ]


Third, in the IETF XML schema registry located at:

http://www.iana.org/assignments/xml-registry/xml-registry.xml#schema

nine new schema will be registered as follows:

ID: geopriv10:lmsrc
URI: urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc
Filename: schema/geopriv10/lmsrc.txt
Reference: [ RFC-to-be ]

ID: lm
URI: urn:ietf:params:xml:schema:lm
Filename: schema/lm.txt
Reference: [ RFC-to-be ]

ID: lm:basetypes
URI: urn:ietf:params:xml:schema:lm:basetypes
Filename: schema/lm/basetypes.txt
Reference: [ RFC-to-be ]

ID: lm:lldp
URI: urn:ietf:params:xml:schema:lm:lldp
Filename: schema/lm/lldp.txt
Reference: [ RFC-to-be ]

ID: lm:dhcp
URI: urn:ietf:params:xml:schema:lm:dhcp
Filename: schema/lm/dhcp.txt
Reference: [ RFC-to-be ]

ID: lm:wifi
URI: urn:ietf:params:xml:schema:lm:wifi
Filename: schema/lm/wifi.txt
Reference: [ RFC-to-be ]

ID: lm:cellular
URI: urn:ietf:params:xml:schema:lm:cellular
Filename: schema/lm/cellular.txt
Reference: [schema RFC-to-be ]

ID: lm:gnss
URI: urn:ietf:params:xml:schema:lm:gnss
Filename: schema/lm/gnss.txt
Reference: [ RFC-to-be ]

ID: lm:dsl
URI: urn:ietf:params:xml:schema:lm:dsl
Filename: schema/lm/dsl.txt
Reference: [ RFC-to-be ]


IANA understands that these three actions are the only ones needed to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce:;
CC:
Bcc:
Reply-To: IETF Discussion List
Sender:
Subject: Last Call:  (Using Device-provided Location-Related Measurements in Location Configuration Protocols) to Proposed Standard


The IESG has received a request from the Geographic Location/Privacy WG
(geopriv) to consider the following document:
- 'Using Device-provided Location-Related Measurements in Location
  Configuration Protocols'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-05-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  A method is described by which a Device is able to provide location-
  related measurement data to a LIS within a request for location
  information.  Location-related measurement information are
  observations concerning properties related to the position of a
  Device, which could be data about network attachment or about the
  physical environment.  When a LIS generates location information for
  a Device, information from the Device can improve the accuracy of the
  location estimate.  A basic set of location-related measurements are
  defined, including common modes of network attachment as well as
  assisted Global Navigation Satellite System (GNSS) parameters.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-geopriv-held-measurements/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-geopriv-held-measurements/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1561/
  http://datatracker.ietf.org/ipr/1563/
  http://datatracker.ietf.org/ipr/1590/
  http://datatracker.ietf.org/ipr/1807/

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The type of RFC being requested is Proposed Standard. Proposed Standard is appropriate because this document defines an extension to a current Proposed Standard RFC (RFC 5985). The title page header indicates that the document is to be Standards Track.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

A method is described by which a Device is able to provide location-
related measurement data to a LIS within a request for location
information. Location-related measurement information are
observations concerning properties related to the position of a
Device, which could be data about network attachment or about the
physical environment. When a LIS generates location information for
a Device, information from the Device can improve the accuracy of the
location estimate. A basic set of location-related measurements are
defined, including common modes of network attachment as well as
assisted Global Navigation Satellite System (GNSS) parameters.

Working Group Summary:

There is strong consensus around this document in the working group. It is required for the HELD protocol to meet many use cases that are satisfied with proprietary protocols today.

Document Quality:

There are a few existing prototype implementations of the protocol. Prototype implementations were deployed at a few IETF meetings. The document references standards from several other SDOs, so the authors solicited reviews by experts on the relevant standards. The document has been updated to the satisfaction of those experts.


Personnel:

The Document Shepherd is Alissa Cooper.
The responsible Area Director is Richard Barnes.


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed this document, and find it clear and implementable.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

I do not have concerns about the depth or breadth of review that has been performed.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

This document defines new XML data structures, and extends the HELD schema (RFC 5985). It has not been reviewed by the XML directorate, but its use of XML is straightforward enough that I do not believe a review to be necessary.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I do not have any specific concerns.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors have confirmed that all relevent IPR disclosures have been filed.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

One IPR disclosure has been filed against this document. There was some discussion of the disclosure, and the WG agreed that it should not be blocking for this document.


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is strong consensus for this document. Several WG participants have expressed the opinion that it address a necessary use case.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There are no threatened appeals.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are a few reference issues that need to be fixed: the RFC 0020 reference should be removed, and the ASCII reference does not display properly. Otherwise, the document has no nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

This document does not require any formal reviews.


(13) Have all references within this document been identified as either normative or informative?

Yes. References are divided into normative and informative.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There are no such references.


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no such references.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document does not change the status of any existing RFCs.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document's IANA Considerations section correctly registers all parameters required by the document.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The document creates a new IANA registry for GNSS types, operating under "Specification Required" rules. As the registration space is not a scarce resource, the bar for the designated expert's expertise need not be especially high. The designee need not be an expert in GNSS systems; the key is to find someone capable of detecting unsubtle attempts at fraud or obvious duplication.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

I have validated that all XML schemas are valid, and all XML examples are well-formed, using the W3C online XML validator.