On Mon, Mar 7, 2011 at 6:55 PM, Derrick Brashear <[email protected]> wrote: > -09 in a moment with only that change. >
Hi Derrick, I just re-read, and I have two eleventh-hour nits (given how close this document is to publication, please feel free to tell me to shut up!!!): 1) Section 7.3 (GetCapabilities RPC): imho, we should add a paragraph specifying a cache TTL for the capabilities bit vector, e.g.: "Client implementations MAY cache the returned capability bit vector for up to two hours. If a client needs to invoke any RPC dependent upon knowledge of the server's capabilities, and AFSVolGetCapabilities has not been invoked within the last two hours, then the client MUST re-fetch the capability bit vector using AFSVolGetCapabilities--and verify that the now-present capabilities are consistent with the desired invocation--before invoking the dependent RPC." 2) Section 7.4.6 (RemoveAuthName): this design is racy (since we have no notion of record lock/transactions); is there any chance we could agree to add an "IN afs_int64 id" parameter to the RPC in order to eliminate the race? Regards, -Tom _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
