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

Read the text. 

In 1) you define both a sending requirement and a receiving requirement for the existing codepoint. In 2 you define only a receiving requirement, and do not allow new implementations to send it (i.e. it is there only for dealing with legacy implementations that send it). 

regards

Keith

> -----Original Message-----
> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] 
> Sent: Monday, June 22, 2009 1:00 AM
> To: DRAGE, Keith (Keith); James M. Polk; Bernard Aboba; 
> 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)
> 
> Hi Keith,
> 
> I don't see any practical difference between the outcome of 1 
> and 2.  It's an exercise in labelling that materially changes 
> nothing.  We waste too much time on labelling.
> 
> --Martin
> 
> > -----Original Message-----
> > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]
> > Sent: Saturday, 20 June 2009 2:14 AM
> > To: James M. Polk; Bernard Aboba; Thomson, Martin; 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)
> > 
> > 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
> > >
> --------------------------------------------------------------
> ----------------------------------
> 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]
> 