Re: [Geopriv] Datum field changes in RFC 3825bis (affecting Sections 2, 2.1 and 6.2)

I dont agree with the specifics of:

> Given that this bis doc is going to obsolete 3825, then this 
> bis doc 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".
>

The fact that the bis exists does not remove RFC 3825 from existence, it merely labels it obsolete. Moreover implementations to RFC 3825 continue to exist. There is no automatic requirement that an implementation conformant to RFC 3825 is also conformant to the bis. What we need is compatibility. So in effect two options exist for each change (between which the group has to decide) while maintaining compatibility:

1)	The existing behaviour is decided by the group to be useful for new implementations, in addition to the proposed new behaviour. In which case, the bis document defines both (for both sender and receiver).

2)	The existing behaviour is decided by the group to be not preferred. In that case the new behaviour is specified. For compatibility with existing implementations, new implementations have to be required to receive what old implementations send.

There is a third option that the existing behaviour is so broken that existing implementations do not work with each other, in which case any compatibility requirements are moot. This however does not apply in this case.

regards

Keith

> -----Original Message-----
> From: geopriv-bounces@ietf.org 
> [mailto:geopriv-bounces@ietf.org] On Behalf Of James M. Polk
> Sent: Thursday, June 11, 2009 10:42 PM
> To: Bernard Aboba; martin.thomson@andrew.com; 
> rbarnes@bbn.com; mlinsner@cisco.com
> Cc: geopriv@ietf.org
> Subject: Re: [Geopriv] Datum field changes in RFC 3825bis 
> (affecting Sections 2, 2.1 and 6.2)
> 
> Given that this bis doc is going to obsolete 3825, then this 
> bis doc 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-rfc3
> 825bis-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-0
> > > 0.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
> 