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

From: Ray Bellis <[email-masked]>
Date: Tue, 2 Sep 2014 12:24:53 +0000

On 26 Aug 2014, at 21:39, Alissa Cooper <[email-masked]> wrote:

> I have reviewed draft-ietf-geopriv-uncertainty-02 in preparation for IETF
> LC. The document is in good shape.

Thanks Alissa! :)

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

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!

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

WG - do you have any comments on Alissa's suggestion regarding documents potentially "updated" by this draft?

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

What about §5 of RFC 5491?

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

Martin and James (and anyone else) please chime in with your thoughts on the above.

> Nits:

and please pick these up in the next rev!

thanks,

Ray

---

From: Martin Thomson <[email-masked]>
Date: Thu, 11 Sep 2014 00:26:09 +0100

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.

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

>> second sentence saying something new or different?

Yes.  [6d5b97e]

>> that are not present are considered to be uncertain.”

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

>>   is assumed for the combination of the uncertainty on each axis.”

[df6c6ce]

> What about §5 of RFC 5491?

Indeed, both.

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

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

>> 1) Elaborate on the note in 3.2 about why uncertainty may be withheld for

   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.

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 12 Sep 2014 14:48:10 -0400

Martin,

Thanks. Just a couple of responses below:

On 9/10/14, 7:26 PM, "Martin Thomson" <[email-masked]> wrote:

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

I’m good with this. Ray, does this work for you?

>"·rounded·only·for·formatting·reasons;·the·actual·calculations·do·not·incl
>ude·rounding,·which·would·would·generate·significant·errors·in·the·final·v
>alues."

s/would would/would/

>   be perfectly protected for the reasons described in Section 13.5 of

s/though it is noted that this information might not be perfectly
protected for the reasons described in Section 13.5 of [RFC6772]./though
it is noted that this information might not be perfectly protected due to
difficulties associated with location obfuscation, as described in Section
13.5 of [RFC6772]./

Otherwise this is good, thanks.

Alissa

---

From: Martin Thomson <[email-masked]>
Date: Fri, 12 Sep 2014 13:35:03 -0700

> Otherwise this is good, thanks.

Cool, changes all committed.  I'll await Ray's input.

I'll apologize in advance for any reduced availability over the next two weeks.

---

From: Ray Bellis <[email-masked]>
Date: Tue, 16 Sep 2014 07:48:57 +0000

> I'll apologize in advance for any reduced availability over the next two weeks.

and I’ll apologize in arrears for my reduced availability over the last few days…

Please go ahead and post it.

Ray

---

From: Martin Thomson <[email-masked]>
Date: Tue, 16 Sep 2014 13:19:41 -0700

> Please go ahead and post it.

Done.