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

[Alissa Cooper <[e-mail]>]

Martin,

Thanks. Just a couple of responses below:

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

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

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

>
>
>>> "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·incl
>ude·rounding,·which·would·would·generate·significant·errors·in·the·final·v
>alues."

s/would would/would/

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

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