[AFS3-std] Re: AFSVol GetSizeV2 draft

[Andrew Deason]

On Wed, 2 Feb 2011 17:09:24 -0500
Derrick Brashear <shadow@gmail.com> 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
adeason@sinenomine.net