is defining both version 0 and 1 - because someone can still choose
(and I'm not sure why they would, but they could) to implement only
what works in version 0 of this spec.
That this doc specifies both v0 and v1 needs to be said if anything
is said., and I think something needs to be said - given we're
obsoleting 3825 "for cause".
At 11:47 PM 6/10/2009, Bernard Aboba wrote:
>Thanks for pointing out the error.
>
>I guess we're pointing out that implementers should check the length
>field, then look at the 2 most significant bits
>of the last octet to determine the version, rather than just
>assuming that the length = 16.
>
>Should we point out that RFC 3825 was version 0, and that this
>specification defines version 1?
>Some text probably belongs in the IANA considerations section
>describing how version numbers are allocated
>(presumably by Standards Action, no?)
>
>
>----------
>Subject: RE: Datum field changes in RFC 3825bis (affecting Sections
>2, 2.1 and 6.2)
>Date: Wed, 10 Jun 2009 23:29:28 -0500
>From: Martin.Thomson@andrew.com
>To: bernard_aboba@hotmail.com; jmpolk@cisco.com; rbarnes@bbn.com;
>mlinsner@cisco.com
>CC: geopriv@ietf.org
>
>Hi Bernard,
>
>
>
>I think that you have these back to front. The version tags need to
>go in the MSB, so that old versions using the LSBs aren't
>affected. Other than that, I think that it's OK.
>
>
>
>Is it worth pointing out that the version tags can change anything,
>including the length of the entire option?
>
>
>
>--Martin
>
>
>
>From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
>Sent: Thursday, 11 June 2009 2:25 PM
>To: jmpolk@cisco.com; rbarnes@bbn.com; mlinsner@cisco.com
>Cc: Thomson, Martin; geopriv@ietf.org
>Subject: Datum field changes in RFC 3825bis (affecting Sections 2,
>2.1 and 6.2)
>
>
>
>Can someone enter a ticket for this?
>
>Below are the proposed changes. Please review. The -01 strawman with these
>changes is available here:
>http://www.drizzle.com/~aboba/GEOPRIV/draft-ietf-geopriv-rfc3825bis-01.txt
>
>In Section 2, change:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Code 123 | 16 | LaRes | Latitude +
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Latitude (cont'd) | LoRes | +
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Longitude |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | AT | AltRes | Altitude |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Alt (cont'd) | Datum |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>To:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Code 123 | 16 | LaRes | Latitude +
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Latitude (cont'd) | LoRes | +
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Longitude |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | AT | AltRes | Altitude |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Alt (cont'd) |Datum| Res |Ver|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>In Section 2.1, change:
>
> The Datum byte has 256 possibilities, of which 3 have been registered
>
>To:
>
> The Datum field is 3 bits, providing 8 possibilities, of which 3 have
> been registered
>
>At the end of Section 2.1 add:
>
> The Res field which is 3 bits, is reserved. These bits have been
> used by [IEEE-802.11y], but are not defined within this
> specification.
>
> The Ver field is two bits, and represents a version field, providing
> for 4 potential versions.
>
>In Section 6.2, add:
>
>[IEEE-802.11y]
> Information technology - Telecommunications and information
> exchange between systems - Local and metropolitan area
> networks - Specific requirements - Part 11: Wireless LAN
> Medium Access Control (MAC) and Physical Layer (PHY)
> specifications Amendment 3: 3650-3700 MHz Operation in USA,
> November 2008.
>
>
> > Date: Wed, 10 Jun 2009 15:56:49 -0500
> > To: Bernard_Aboba@hotmail.com; rbarnes@bbn.com; mlinsner@cisco.com
> > From: jmpolk@cisco.com
> > Subject: RE: Text for 3825bis
> > CC: Martin.Thomson@andrew.com
> >
> > Bernard
> >
> > I assume you can make the edits about splitting the datum field into
> > 3 parts, as I don't see that as controversial, and I think you have
> > much of the idea from Richard, and can look in section 2 of
> > http://www.ietf.org/internet-drafts/draft-polk-geopriv-3825-update-00.txt
> > for how the datum field is being broken up.
> >
> > James
>
>
>
>------------------------------------------------------------------------------------------------
>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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
