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

From: Ray.Bellis@nominet.org.uk
Date: Fri Apr 24 2009 - 03:19:06 EDT

>
http://www.ietf.org/internet-drafts/draft-polk-geopriv-3825-update-00.txt
>
> - 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
uncertainty
>
> - 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
added

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?

cheers,

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
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