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

[Martin Thomson <[e-mail]>]

Apologies for the delay getting to this, it's not super-high on the
priority list.

I've made commits to my repo
(https://github.com/martinthomson/drafts/), which you can find using
the commit tags, if you are especially interested.  I'll await
instruction (and confirmation of any needed consensus) before posting
a real update.

On 2 September 2014 13:24, Ray Bellis <[e-mail]> wrote:
> On 26 Aug 2014, at 21:39, Alissa Cooper <[e-mail]> wrote:
>> 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.
>
> In the write-up I meant "augments" in the sense that the schema extends the Standards Track PIDF-LO in the same way that 6915 and 6155 do, but without changing any existing semantics.  Neither of the aforementioned were considered to "update" 5139 (or 4119).
>
> This was just a rationale for why this doc should also be standards track (i.e. this is, because the baseline spec is).  Happy to remove that, of course!

A lot of that was based on the draft being in two pieces (and this
piece being original Informational).

Based on the discussion below, I think that we should just add all
three (3693, 4119 and 5491) to the updates attribute.  The cost there
being that we need to highlight why fairly prominently.  I'm happy to
do that.

Given that 3693 is now deprecated, and its successor doesn't use the
terms we deprecate here, maybe we could remove the offending section
(2.2. Deprecation of the Terms Precision and Resolution).

For now, I've added all three. [08001cd]

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

Yes.  [6d5b97e]

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

Yes, that is more correct. I removed "considered to be". [72f5027]

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

[df6c6ce]

>> 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.
>
> What about §5 of RFC 5491?

Indeed, both.

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

Because it is wrong.  I didn't correctly fix all the examples when I
updated the draft to capture the decision to make it mandatory.
[54019cd]

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

I think that I fixed it with this: [9cf7d5f]

"·rounded·only·for·formatting·reasons;·the·actual·calculations·do·not·include·rounding,·which·would·would·generate·significant·errors·in·the·final·values."

(Ignore the odd characters, they won't appear in the final product.)

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

   Providing uncertainty and confidence information can reveal
   information about the process by which location information is
   generated.  For instance, it might reveal information that could be
   used to infer that a user is using a mobile device with a GPS, or
   that a user is acquiring location information from a particular
   network-based service.  A Rule Maker might choose to remove
   uncertainty-related fields from a location object in order to protect
   this information; though it is noted that this information might not
   be perfectly protected for the reasons described in Section 13.5 of
   [RFC6772].

Is that clear enough? [0971e0b]

>> 2) Incorporate the RFC 4119 security considerations by reference.

Done.  [0971e0b]

>> Nits:

All done [d38ecc0], except
s/area of the concert hall/area of a concert hall/

I'm surprised that you didn't ask whether "concert hall" was a
standard unit of area :)

It's actually a proper noun in this context, but I realized that I
hadn't actually explained where Bob's location was.  Which is unfair.
I have now done so.  And I capitalized correctly.