On Sun, 3 Jun 2012 19:44:44 -0500 Andrew Deason <[email protected]> wrote:
> This email contains the trivial and less trivial; nontrivial > discussion on section 10 will follow in a separate email, because I > think there's a lot to talk about wrt it. Here are those comments. paragraph 1: The reference to XCB seems vague. This could either use a reference to the XCB draft, or it could just say in general that future enhancements will add file- related data over the callback channel. paragraph 2: "part of the RXAFS_ family" should read "part of the AFSINT protocol", I think? minor point: To be consistent with other RPC names, this should be SetCallBackKey, not SetCallbackKey 2nd paragraph after SetCallbackKey: Breaking all callbacks on a SetCallbackKey invocation seems heavy-handed; is this necessary? Should instead this call just be a barrier between the old and new key? That is, all callback promises generated before issuing SCBK will be broken using the old key, and all callback promises generated afterwards use the new key. 3rd paragraph after SetCallbackKey: "Only RPCs issued over an rxgk protected connection should receive rxgk protected callbacks" This paragraph doesn't make any sense, since RPCs do not receive callbacks; clients receive callbacks. What I believe this is trying to say is that only callback promises generated by RPCs issued over an rxgk protected connection should be broken via rxgk-protected callback breaks. So, I would think this should be phrased more like, fileservers MUST NOT issue rxgk-protected callbacks for breaking callbacks generated by non-rxgk-protected RPCs. However, this still does not seem like an adequate specification, since a callback promise can be generated/shared by several different RPCs. That is, if a client issues an rxgk-protected FetchData, then an rxnull FetchData for a different chunk on the same file 5 seconds later, which do we send? What I was thinking is that fileservers need to track callback promises generated from rxgk-protected RPCs separately from other callback promises. If a fileserver needs to send callback breaks over the callback channel, it will send rxgk-protected calls until all rxgk-protected callback promises have expired or been broken. This allows the callback channel protected-ness to be downgraded somewhat automatically, without allowing for downgrade attacks. The current language does not really address downgrades, so, depending on the interpretation, a client could break itself ~forever by just upgrading to rxgk once (unless you have administrator intervention, which for clients seems in general less practical). With the above suggestion, a client can automatically downgrade after all of the rxgk-protected callbacks have expired. As a general note, at least some of the protocol specifications here seem like they may belong in a document defining XCB (or whatever specification for callback improvements). Or, some of the complexities here may warrant an entire separate document explaining the interaction between callbacks and XCB. This section also seems a little unclear on when this mechanism should be utilized; that is, we specify when the fileserver may use the protected callback channel, and when it must not, but does not provide recommendations for when the whole system should be used (do we always use this for XCB and nothing else? or do we use it for all callbacks whenever possible?). This should perhaps be specified by the document defining a new callback protocol, but if so, the lack of it here should be explicitly stated. -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
