Re: [Geopriv] Short (5 page) ID to "update" RFC 3825

Date: Fri Apr 24 2009 - 03:19:06 EDT

> - this ID creates the "switch" the chairs were looking for indicating
> when the resolution fields should remain resolution values, or when
> they become confidence and uncertainty values. This is done by adding
> an Option 123 version field, which dictates one version has
> resolution fields, and another has confidence/uncertainty
> fields. This mechanism is backwards compatible, which is another
> goal from the chairs.
> - this ID modifies the existing 8-bit datum field into 3 separate
> fields (datum, version, and reserved). Reading the ID will give the
> story why this proposal does this.
> - this ID aligns with IEEE (which appears to be a goal)
> - this ID directs the reader towards how to define confidence and
> - this ID tells the reader of RFC 3825 to not bother with the
> appendix when there are no resolution fields, thus reducing confusion.
> - this ID does not add a v6 Option, but could with a little more text
> (that's fairly straightforward to write) -- if WG consensus wants this

Looks good to me, and it's interesting to note that for .11y IEEE have
already decided they only need a 3 bit datum field.

One thing though - is there any reason we can't call RFC 3825 "version 0",
so that the bit representation and the "human readable" version number
don't have an ongoing off-by-one discrepancy?



Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e:, t: +44 1865 332211
Geopriv mailing list
Received on Fri, 24 Apr 2009 08:19:06 +0100

This archive was generated by hypermail 2.1.8 : Fri Apr 24 2009 - 03:20:45 EDT