On Wed, 2 Feb 2011 17:09:24 -0500 Derrick Brashear <[email protected]> wrote:
> from the explanation: > "an AFS-3 Volume Server service" is awkward. "an AFS-3 Volume Service"? > "As such, since there is only > one flag currently defined for DumpV2 (VOLDUMPV2_OMITDIRS), there is > only one flag defined for GetSizeV2" > flies in the face of the explanation that no parallel is required. The > whole explanation, really. Perhaps explain that as the intent is to > provide an extended interface as was done with DumpV2, > that the single existing flag used there is defined here, although no > requirement exists that.... Proposed text. Yes/no? >> The intention of the GetSizeV2 RPC is to provide an extension to the >> GetSize RPC, similar to how DumpV2 provided an analogous extension to >> Dump. As such, the only defined GetSizeV2 flag corresponds to the >> single existing DumpV2 flag, although there is no requirement that >> every GetSizeV2 flag have a DumpV2 equivalent, or vice versa. > Not all AFS-3 VVL implementations use a UserList. I'd say that > typically a per-server superuser list is used to control access to > .... and it SHOULD be applied to this also. An RFC2119 "SHOULD"? That seems too strong to me; I saw this as something that is completely up to the implementation, but I was just suggesting how OpenAFS does it / will do it. IMHO, I don't really see problems with access control here, but it seems like a good default. That is, it's not like there are common pitfalls that implementations need to carefully consider before changing it; it almost always doesn't matter. But I defer to others more used to using RFC2119 language. > Does it make sense to increase the size of the date fields now? I thought we were waiting on a document to standardize how we were representing time going forward, before diverging from the status quo, so we don't somehow get different interpretations of 64-bit time values in different RPCs/packages. That specification being included in the alleged "RPC Refresh" document; I'd rather not have to wait for it for this. We're going to have to change quite a few AFSVol RPCs when we update the time spec anyway; it might be preferable to do them all at once so the spec is the same for all, maybe give the new names all some consistent prefix/suffix, etc... > > I wasn't sure if my level of explaining AFS is sufficient or is too > > much, etc. I don't want to have to explain everything about what > > volumes are, the volume dump format, etc, but with too little the > > draft on its own is rather meaningless. I also don't really explain > > the motivation for *_OMITDIRS flags; do I need to? > > it exists already. it should nominally be explained in documentation > of the existing protocol. i realize that doesn't exist, but... Eh, I'm thinking I'll just do it. Treating this as a doc other implementors could in theory use, the specification really doesn't make a lot of sense without this explanation. -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
