Subject: [Geopriv] The 3825bis draft...

From: "Alexander Mayrhofer" <[email-masked]>
Date: Mon, 20 Aug 2007 16:42:24 +0200

Hi,

I spent some time on reviewing the (expired) 3825bis draft - i think all
those issues with RFC3825 definitely justifies to update it, so i very
much appreciate this work. I see the following two issues with 3825:

- weak definition of reference systems used (looks good in 3825bis)
- the famous "resolution" issue (how many valid bits in 0111 vs. 1000? -
i understand that one of the main reasons for 3825bis was that issue)

I'd really like to see 3825bis going forward, because that data format
is popping up in other places as well (LLDP-MED, and i think that won't
be the last one), so the earlier we get that fixed, the better. 

My comments on the -00 version:

- Section 1.2, content: should also include that some of the field names
have changes (Res -> Unc). It should also mention that it actually
changes the existing IANA registrations of the reference systems (for
good, from what i as a non-gis person see).

- Section 2.1, typo: "LongUnc" should be "Longitude Uncertainty", the
text says "Latitude". 

- Section 2.2, content: I think the OptLen description is redundant,
too, unless RFC3315 explicitly requests it there. 

- A section on "backwards compatibility" to the old "resolution"
semantics would be good. Honestly, i don't get from the text whether
only the interpretation of the values has changed, or encoding/decoding
now yields different numbers...

- Section 2.3, content: The sentenct "New datums MAY change the way.."
is a bit too broad to me. Is a new datum registration also allowed to
eg. change the split of the 34 bits between integer and fraction (eg.
some datum uses 30 bits integer, 4 bit fraction, or probably even
something like false northings/eastings, as UTM does [ok, UTM is a
*projection* rather than a *datum*])

- I know it's probably cheesy, but i'd really like to see an ASCII art
of the uncertainty in Section 2.3.1 (BTW, i had to read that section
about 4 times, and i think there still might be some detail i missed :)

What's the reason for using a prism as the spatial representation of
uncertainty? The "natural" way to represent uncertainty would be an
ellipse (or, and ellipsoid). Is it that such a surface (or volume) is
too different to represent/calculate?

I'm also missing a bit of wording about what level of probability the
"uncertainty" volume should cover... is that 50%? 95%? Up to the
implementor?. If there would be the option to *completely* redesign that
data format, i'd look into adding a representation the following values:

- probability used when calculating uncertainty
- bearing/speed vector (with uncertainty)
- location ttl (instructing the client when to issue a new query,
clashes with lease duration, though?)

(i know that because of backwards compatibility, this is not possible)

- I think the IANA section needs to say that it actually changes the
registration of the Datum enumerators (or, clarifies the reference
systems used). Right now it lists what is there, instead of instructing
IANA what to do.

Overall, i think this is a very valueable document, and i'd definitely
like to see this going forward - what is the general direction with
this, and how do we proceed from here?

comments appreciated.

--
Alexander Mayrhofer 

nic.at Internet Verwaltungs- und BetriebsGmbH
Jakob-Haringer-Strasse 8, A-5020 Salzburg
LG Salzburg, FN 172568b

E: <[email-masked]> W: http://www.nic.at/
T: +43 1 5056416 34, F: +43 1 5056416 934

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 20 Aug 2007 19:26:16 -0500

Hi Alexander,

Thanks for the very detailed review of draft-thomson-geopriv-3825bis-00
if people see a need for this we will certainly update it to address the
issues you highlight. This document was our attempt to show how
uncertainty could be represented using the existing 3825 constraints
without introducing significant errors, I am glad that it seems to have
achieved that. Alas this document is not the geopriv WG document for
correcting 3825 encoding. From what I can understand you seem to be the
only group that have actually tried to understand and implement the
various 3825 encodings and hence have a real grasp of what Martin T and
I have been concerned about. 

Currently the WG document to "clarify" 3825 is
draft-ietf-geopriv-binary-lci-00, which incidentally has also expired.
Klaus posted some comments on this document indicating that it did not
address the confusion raised in 3825, and that the encoding was obscure.
It would be good if could elaborate on these points a little, so that we
as a WG can make sure they are addressed properly.

Cheers
James

> -----Original Message-----
> From: Alexander Mayrhofer [mailto:[email-masked]]
> Sent: Tuesday, 21 August 2007 12:42 AM
> To: [email-masked]
> Subject: [Geopriv] The 3825bis draft...
> 
> 
> Hi,
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]