[AFS3-std] Standardization of GetCapabilties RPCs for AFS3 client and services

[Jeffrey Hutzelman]

On Friday, February 24, 2006 06:28:28 PM -0500 Chaskiel M Grundman 
<cg2v@andrew.cmu.edu> wrote:

>> (5) In addition to advertising new functionality, the Capabilities flags
>>     can be used to provide hints to the caller of behavior the server
>>     may desire.  For example, a file server may prefer that client not
>>     request make SetLock requests even though the functionality is
>>     supported.  These hints would not be mandatory and would simply be
>>     a method by which desired policy can be distributed from server to
>>     client.
>
> Why is it a good idea to put client policy configuration in the server?

In general, it's not.  However, it is appropriate for a fileserver to 
provide hints about what functionality it will support, or what access 
control policies it will apply, particularly in cases where that helps the 
client to provide a better user experience.  For example, it may be helpful 
to a client to know whether the fileserver supports mandatory locking, and 
under what circumstances it will grant such locks, in advance of actually 
trying one.


In general, capability bits should be used to describe how the entity 
advertising the capability will behave; they should not be used to tell the 
querying entity how to behave.  If you want all the clients you manage to 
have a particular policy, then distribute policy configuration to them via 
a suitable mechanism, not by overloading server capapbility negotiation.


Incidentally, while it is desirable to extend existing RPC's in 
backward-compatible ways, and appropriate to use capability bits to 
advertise support for such an extension, we must be careful not to use 
capabilities as an excuse to make backward-incompatible changes to existing 
RPC's.  The procedure number space is quite large; we can afford to burn a 
few numbers.

I'm not sure I like the implication that every new RPC should have an 
associated capability bit, either.  I see a potential here for a lot of 
bloat with relatively little benefit.  If it costs a client an extra round 
trip to discover that a server doesn't support the new way of doing things, 
sometimes that's OK -- especially if the client can cache that information. 
On the other hand, there certainly are cases where it makes sense to do 
this, particularly if it is advantageous to the client to know whether an 
operation is supported well before it tries it, or if the burden of the 
extra round trip is particularly heavy.


Finally, I think we should be clear that even when a capability bit 
indicates support for a particular feature, clients should be prepared to 
deal with servers which return errors (particularly, RXGEN_OPCODE or access 
control errors) when the feature is used.  This is especially important 
with respect to cache manager capabilities, since the transport address 
used by one cache manager may somewhat unexpectedly be reassigned to 
another.



More on this thread later, probably; for now I should go to dinner.

--  Jeff