[AFS3-std] RxOSD claim on 2 structure members

[Jeffrey Altman]

Matt W. Benjamin wrote:
> 3. I would request that any other claimants of SyncCounter or of the spare0 and spare3 members in volintInfo (claimed as osdPolicy and filequota in rxosd) disclose their use here, or otherwise state here how they would be harmed by allocating these members to rxosd.
>
This is an impossible request.  Not all parties that may have developed
private uses for these fields participate on this list.  

The fact that at least two parties that are known have created private
uses for field that are otherwise unused in the OpenAFS implementation
simply demonstrates that reusing otherwise allocated protocol components
is dangerous and should not be done. 

Given the known collision I will not support the reuse of the
FetchStatus SyncCounter field for any use. 

We require new versions of many RPCs.  What we should start doing to
move the process forward is to collect a list of known requirements for
as many known sources as possible so that a single revision of each RPC
can be issued that addresses the protocol needs of the various
implementors for the next several years.   As an example of a requirement:

   1. Package RXAFS
         1. 32-bit unsigned value for OSD Protocol Version. 
               1. Affected RPCs: AFSFetchStatus
         2. 64-bit unsigned value for Read-Only Volume Version
               1. Affected RPCs: AFSFetchStatus
   2. Package AFSVol
         1. 32-bit signed value for OSD use of object storage
               1. Affected RPCs: SetInfo, ListVolumes, ListOneVolume
         1. 32-bit signed value for OSD updateCount value
               1. Affected RPCs: SetInfo, ListVolumes, ListOneVolume
         2. 32-bit signed value for OSD max number of files
               1. Affected RPCs: SetInfo, ListVolumes, ListOneVolume

This list should be extended to include all of the changes necessary to
support 64-bit time, long volume names, 64-bit volume IDs, volume UUIDs,
cell UUIDs, etc.

Once such a list of requirements is compiled (and I suggest this be done
on a wiki page to start which can eventually be published as an Internet
Draft when it begins to stabilize) the afs3 standardization community
can begin to layout new data structures and RPCs that can support all of
the functionality we expect to need over the next several years.   It
might prove in the end that we will miss something and require a
subsequent RPC revision.  However, the end result will be a much more
stable protocol and set of client/server implementations.

Jeffrey Altman