On Tue, Jun 5, 2012 at 11:24 PM, Andrew Deason <[email protected]> wrote: > 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
i would agree with all of the above > 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. as an implementor i would certainly prefer to simply use the new key exclusively. i don't know that i would require it. > 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. i suppose phrasing it as "Only RPCs issued over an rxgk protected connection should cause rxgk callbacks to be received" would be how i would phrase it. > 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. Why? Given CombineTokens cannot be solely controlled by a single user, by design, I would instead say that it is entirely reasonable that a rxgk protected callback be generated if at least one FetchStatus object was returned for the current promise was protected by rxgk. > 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? given my interpretation, rxgk. > 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. alternately, changing UUID on rxgk clients would mean this is not true, since it's then not the same client across up/downgrade. but this should be explicitly addressed. > 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. -- Derrick _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
