[AFS3-std] AFSVol GetSizeV2 draft

[Derrick Brashear]

> I'm not entirely clear on if it's appropriate to have the registrar
> maintain the flag values for the new RPC (as opposed to just specifying
> them in the draft). To me, this seems similar to assigning code points,
> but to my knowledge the registrar doesn't maintain such values for other
> RPCs currently.

the capabilities are in that registry. as a new flag (for a new rpc)
you'd specify the values as you'd introduce the registry. later new
flags would be registered.


from the explanation:
"an AFS-3 Volume Server service" is awkward.

"Another RPC, GetSize,"

A third RPC, ...? That's no good either. I'd say perhaps that "To
allow computation of the size of volumes returned by the Dump RPC, a
GetSize RPC was provided. However,..."

"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....

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.

And since   the GetSize

elide the And.


Does it make sense to increase the size of the date fields now?


>
> 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...




-- 
Derrick