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] |
