[Geopriv] AD review of draft-ietf-geopriv-uncertainty-02

[Alissa Cooper <[e-mail]>]

I have reviewed draft-ietf-geopriv-uncertainty-02 in preparation for IETF
LC. The document is in good shape. I have a number of questions and
comments I’d like to see resolved before issuing the LC. I’ve also
included a number of nits that should be fixed in the next rev.

Questions and comments:

== Documents updated ==
The shepherd write-up says that this document “augments” RFC 5139. This is
likely to confuse some ADs, or cause them to wonder why this document
doesn’t update RFC 5139. So I would suggest deleting that phrase.

Furthermore, as explained below, I think this document actually
normatively updates RFC 3693 and RFC 4119, so those indications should be
added to the document header, abstract, and shepherd write-up (assuming
the WG agrees).

== Section 2.1 ==
"A rectangular PDF is
      often described by the half-width of the distribution; that is,
      half the width of the distribution.
...
For a rectangular distribution, half of
   the width of the distribution is used.”

Are these two sentences saying the same thing — that the half-width of a
rectangular distribution is used to describe the distribution? Or is the
second sentence saying something new or different?

== Section 2.2 ==
Since this document is deprecating terminology defined in RFC 3693, I
think it should declare that it is normatively updating RFC 3693.

== Section 3.3 ==
"In this case, uncertainty is effectively described by the
   presence or absence of elements -- elements that are not present are
   deemed to be uncertain.”

I think the above is true from the perspective of the location recipient.
The sender may have more certainty about some elements but may choose not
to send them. I would suggest the following edit:

"In this case, uncertainty is effectively described by the presence or
absence of elements. To the recipient of location information, elements
that are not present are considered to be uncertain.”

== Section 3.4 ==
"[RFC6225] defines a means for representing uncertainty, but a value
   for confidence is not specified.  A default value of 95% confidence
   is assumed for the combination of the uncertainty on each axis.”

s/is/should be/

Otherwise it’s hard to know how to interpret this (did all location
information previously sent via a GeoLoc option have 95% confidence?)

== Section 4.1 ==
This is the section that causes me to think that this document updates RFC
4119.

== Section 6.1 ==
Why doesn’t Figure 8 have a confidence element?

"Note that the numbers shown are all rounded; no rounding is possible
during this
   process since rounding would contribute significant errors.”

Does this mean that the numbers shown in the document are rounded for
display purposes, but that when making the actual calculations rounding
did not occur? If so, this needs a little clarification.

== Section 9 ==
I think it would be useful in this section to:
1) Elaborate on the note in 3.2 about why uncertainty may be withheld for
privacy purposes, and
2) Incorporate the RFC 4119 security considerations by reference.


Nits:

== Section 1 ==
s/based on their location estimate/based on its location estimate/

== Section 1.1 ==
s/in particular Target./in particular the term “Target.”/

== Section 2.1 ==
s/are related to the standard deviation/are related to the standard
deviation of the function/

== Section 4 ==
s/On the whole, a fixed definition for confidence is preferable. Primarily
because it ensures consistency between implementations./On the whole, a
fixed definition for confidence is preferable, primarily because it
ensures consistency between implementations.

s/generators might unable/generators might be unable/

== Section 5.4.1 ==
s/“Co" and "Cb" are the confidence values associated with each
region./“Co" and "Cr" are the confidence values associated with each
region./

== Section 6.2 ==
s/Assuming that confidence is known to be 19%/Assume that confidence is
known to be 19%/

s/area of the concert hall/area of a concert hall/