Hi, I had assumed it would be permitted, if not recommended, for the fileserver to use the strongest channel protection it has available for whatever it's sending on the backchannel. In particular, the fileserver wouldn't be sending notifications it did not believe were valid, so their validity per se does not appear to depend on the forward channel protection that might have been in use when some notification was provoked. That is, if a directory -really is- invalidated at the fileserver, or if file 'F' is created in some volume, aren't those just facts? Meanwhile, if rxgk channel protection was required to effect whatever the change we're discussing is, then the point is moot. (Sorry if I'm missing the obvious.)
Matt ----- "Derrick Brashear" <[email protected]> wrote: > 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 -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
