[AFS3-std] Re: AFSVol GetSizeV2 draft

[Derrick Brashear]

On Fri, Feb 4, 2011 at 4:01 PM, Andrew Deason <adeason@sinenomine.net> wrot=
e:
> 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"?

sure

>> "As such, since there is only
>> =A0 =A0one flag currently defined for DumpV2 (VOLDUMPV2_OMITDIRS), there=
 is
>> =A0 =A0only 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 else=
where
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.