On Fri, Feb 4, 2011 at 4:01 PM, Andrew Deason <[email protected]> wrote: > 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"?
sure >> "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 current text can be interpreted contradictory so i'd say 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"? yes > 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. perhaps my phrasing was (also) poor. intent: the same controls applied elsewhere SHOULD be applied here. > 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. so a short "64 bit time" document would seem to be called for. the ubik proposal will also want it. do we want ns granular time? > 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... on one hand, yes, on the other, bloating the code supporting X and X2 and Y and Y2... >> > 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. fair. _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
