On Mon, Jun 22, 2009 at 9:08 AM, Jeffrey Altman < [email protected]> wrote:
> Simon Wilkinson wrote: > > I think we should remember our reasons for separating out > > standardisation from OpenAFS. Whilst OpenAFS's concerns (as the major > > implementor) can certainly guide our discussions, I don't think what > > the gatekeepers feel they can or cannot implement should necessarily > > constrain those discussions. > Agreed. The point that I'm trying to drive home is that consideration > of the backward compatibility issues is important and that the > transition from one set of RPCs to the other is equally important to > many impacted by these changes. Future looking features should be > designed into the protocol. > > The corollary of Simon's statement is equally true. Just because > something gets into the protocol does not mean it will be implemented > within OpenAFS. > > > > So, I think there are two real issues here: > > > > a) Is it desirable that a future version of the AFS protocol be > > capable of supporting 64 bit volume IDs? > I believe the answer is 'yes'. > > b) Given a) do we want to include 64 bit volume IDs in the protocol > > revision we are currently discussing? > I believe the answer is 'maybe' leaning towards 'yes'. > If it is done (I think it should be) then recommendations to implementors to ease backwards compatibility should be provided in the extension document; Among those, from gatekeeper discussion notes, would be the suggestion to provide mappings or policy engine to allow volumes which older clients need to be placed within 32 bit space, and allocating temporary clone IDs outside the 32 bit space.
_______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
