On 3/11/2011 6:10 PM, Tom Keiser wrote: > 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!!!):
I agree with Simon that at some point people need to be able to trust that the standard is a standard so that code can be deployed. This process is supposed to permit sites to be able to do so without fear that their deployed clients and servers will suddenly fail to inter-operate with the rest of the community. > 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." This document at the present time says nothing about caching of capabilities data which puts this GetCapabilities RPC in exactly the same situation as that for the other GetCapabilities RPCs that we have in use. The other GetCapabilities RPCS (and I'm include VL_ProbeServer as a pre-GetCaps RPC) is that they are called on a very frequent basis. On the order of every ten minutes or less and immediately when a cache manager receives an RXAFSCB_InitCallBackState() from the server in question (for RXAFS_GetCapabilities). What I think would be appropriate in this instance would be to not modify this standard but instead write a new document that describes proper client use of GetCapabilities RPCs in general since we expect them to be added to each service over time. > 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? There are actually two problems. The first is that as a double check we should have the full mapping specified. The second is that it isn't specified what happens when the last mapping is removed from an id. Does the id at that point become deleted? While I agree with Simon that the principal of standards publication is important. I also believe that it is important to ship code that works properly. Therefore, I believe it should be left up to the implementer to decide whether or not it is acceptable for the standard to be altered once it has been approved by the group. Only the implementer knows what the impact of such a change would be. By that rationale, if Derrick wishes to submit a change I will support him. If Derrick decides that a change at this point is too hard to make, I will support that decision as well. If anyone else is implementing this document, please speak up. Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
