I went back to the archives of IETF 71, and reviewed the presentation.
Here is a potential revision to Section 1.2 to address the comments:
1.2. Resolution and Uncertainty
The DHCP options defined in this document include fields quantifying
the resolution or uncertainty associated with a target location. No
inferences relating to privacy policies can be drawn from either
uncertainty or resolution values.
As utilized in this document, resolution refers to the accuracy of a
reported location, as expressed by the number of valid bits in each
of the Latitude, Longitude and Altitude fields.
In the context of location technology, uncertainty is a
quantification of errors. Any method for determining location is
subject to some sources of error; uncertainty describes the amount of
error that is present. Uncertainty might be the coverage area of a
wireless transmitter, the extent of a building or a single room.
Uncertainty is usually represented as an area within which the target
is located. In this document, each of the three axes can be assigned
an uncertainty value. In effect, this describes a rectangular prism,
which may be used as a coarse representation of a more complex shape
that fits within it. See Section 2.3.2 for more detail on the
correspondence between shapes and uncertainty.
When representing locations from sources that can quantify
uncertainty, the goal is to find the smallest possible rectangular
prism that this format can describe. This is achieved by taking the
minimum and maximum values on each axis and ensuring that the final
encoding covers these points. This increases the region of
uncertainty, but ensures that the region that is described
encompasses the target location.
The DHCPv4 option format defined in this document supports both
resolution and uncertainty parameters. Version 0 of the DHCPv4
option format includes a resolution parameter for each of the
dimensions of location. Since this resolution parameter need not
apply to all dimensions equally, a resolution value is included for
each of the three location elements. However, due to the definition
of resolution, using version 0 of the DHCP option format, it may
not be possible to define a PIDF-LO that captures both the
location as well as the uncertainty region surrounding it.
Since version 0 of the DHCPv6 option format is not defined, the
DHCPv6 option does not support a resolution parameter. Version 1
of the DHCPv4 and DHCPv6 option format utilizes an uncertainty
parameter. Using version 1 of the DHCP option format, it is
typically possible to define a PIDF-LO that encloses
the location as well as the uncertainty region surrounding it.
Appendix A describes the mapping of DHCP option values
to GML. Appendix B of this document provides examples showing
the calculation of resolution values. Appendix C provides an
example demonstrating calculation of uncertainty values.
From: rbarnes@bbn.com
To: bernard_aboba@hotmail.com
Subject: Fwd: [Geopriv] AD review: draft-ietf-geopriv-rfc3825bis-12
Date: Thu, 28 Oct 2010 18:37:52 -0400
Hey Bernard,
Don't think this ever got a follow-up. Do you recall the discussion that Robert is talking about here? It goes back to some intensive discussion (around the Philadelphia IETF, IIRC) about how the resolution representation is unsuitable for privacy in part because it represents some regions so poorly, e.g., those near the equator.
Would you mind drafting some text, or at least proposing some clarifications to Section 1.2? These don't necessarily need to go into a new rev right now, since the change is pretty minor, but if you could at least send out an acknowledgement, that would be helpful.
Thanks,
--Richard
Begin forwarded message:
From: Robert Sparks <rjsparks@nostrum.com>Date: October 11, 2010 5:16:27 PM EDTTo: GEOPRIV <geopriv@ietf.org>Subject: [Geopriv] AD review: draft-ietf-geopriv-rfc3825bis-12_______________________________________________Bernard and the chairs tell me that this is ready to go again - I've requested IETF Last Call.Please consider the following early IETF LC comments:Comment:
This document doesn't capture the issues with the version 0 DHCPv4
option that we discussed in Philadelphia.
(See <http://www.ietf.org/proceedings/71/slides/geopriv-2/geopriv-2.htm>).
It may not need to, since it is not trying to specify using the version 0
DHCPv4 option to return an area covering another area. However, given the
amount of conversation that went into understanding the limitation, some
text explaining it seems warranted. It would also help motivate _why_ there
is now a version 1. (That said, there is text in section 1.2 that could
be read to say a version 0 response could cover an arbitrary region to
a desired level of precision - that text should be adjusted to make it
clear that's not what's being claimed).
Nits:
Section 2.4 should call out that it is defining AType values.
In this section (and elsewhere in the document), the older "AT"
tag in the prose should be changed to use the "AType" tag in the
new format layout.
The last equation in section 2.4.5 has x on both sides. I suspect
log2(x) should have been log2(Uncertainty)Please double-check the XML templates - there are a few spurious semicolons.
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
