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

[Ray Bellis <[e-mail]>]

On 26 Aug 2014, at 21:39, Alissa Cooper <[e-mail]> 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