[AFS3-std] Re: AFSVol tag-length-value extensions draft (second call for comments)

[Andrew Deason]

Apologies for not commenting sooner. I believe I had conversations with
Tom about at least some of this awhile ago, but I don't remember the
outcome of them. It's possible you already had good answers for me,
then, but I just don't remember them.

>> 2.  GetCapabilities RPC

Is this really the intended title? 3.1 seems to be the section on
GetCapabilities.

>> 3.1.  GetCapabilities
>>
>>   All AFS-3 Rx services with Tag-Length-Value RPCs MUST implement a
>>   GetCapabilities RPC analogous to that done for the FS-CM interface.

...but RXAFS tends to have long-lived, persistent connections to
fileservers, so the capability bits can be cached until
initcallbackstate or whatnot. Are we going to be querying cap bits for
every vol operation?

We also are not guaranteed that the results of a GetCapabilities
represent the volserver capabilities when we actually call more
meaningful RPCs on the volserver. I.e., by the time we actually call
e.g. GetOneVolumeTLV the volserver could have restarted with a new set
of capabilities. Or do we just rely on the RX layer to detect that, and
re-query capabilities if we think the server could have restarted?

I'm not saying that it causes any real problems, but is it worth
mentioning?

>> 3.1.2.  Capability Bit Allocations
>> 
>>    Three new capability bit allocations will need to be processed by
>>    the Grand Central Registrar:
>> 
>>    VICED_CAPABILITY_DAFS  Announce that this file server supports the
>>        OpenAFS Demand Attach File Server version 1 semantics
>> 
>>    AFSVOL_CAPABILITY_DAFS  Announce that this volume server supports
>>        the OpenAFS Demand Attach File Server version 1 semantics

I'm not sure I see what these cap bits actually do. What would DAFS-ness
change about wire protocol behavior? The only other reference I even see
to the DAFS cap bit in this is AFSVOL_TLV_TAG_VOL_STATE_DAFS_RAW and
AFSVOL_TLV_TAG_VOL_OWNING_PROCESS, which could be found by just querying
those tags.

If the capabilities are just to represent supported tags, does it just
exist to reduce the amount of advertised data? (Since 1 cap bit can
represent many tags)

>> 4.2.2.  Tag Introspection
>> 
>>    The Rx procedure specification for the tag support RPC will be as
>>    follows:
>> 
>>              proc GetVolumeTLVTags(
>>                  IN AFSVol_TLV_tag offset,
>>                  OUT AFSVol_TLV_tag * tags<AFSINT_TLV_TAG_MAX>
>>              ) = XXX;

Again, this isn't very useful if the server restarts between calls (the
offset could mean something entirely different). Do we depend on RX
detecting that and start over if it happens?

-- 
Andrew Deason
adeason@sinenomine.net