[AFS3-std] Re: draft-wilkinson-afs3-rxgk-afs-01 comments

[Matt W. Benjamin]

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 sen=
ding 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 som=
e volume, aren't those just facts?  Meanwhile, if rxgk channel protection w=
as required to effect whatever the change we're discussing is, then the poi=
nt is moot.  (Sorry if I'm missing the obvious.)

Matt

----- "Derrick Brashear" <shadow@gmail.com> wrote:

> On Tue, Jun 5, 2012 at 11:24 PM, Andrew Deason
> <adeason@sinenomine.net> wrote:
> > On Sun, 3 Jun 2012 19:44:44 -0500
> > Andrew Deason <adeason@sinenomine.net> 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
>=20
> i would agree with all of the above
>=20
> > 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.
>=20
> as an implementor i would certainly prefer to simply use the new key
> exclusively.
> i don't know that i would require it.
>=20
> > 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.
>=20
> 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.
>=20
> > 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.
>=20
> 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.
>=20
> > 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?
>=20
> given my interpretation, rxgk.
>=20
> > What I was thinking is that fileservers need to track callback
> promises
> > generated from rxgk-protected RPCs separately from other callback
> > promises. =C2=A0If 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.
>=20
> 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.
>=20
> > 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.
>=20
>=20
>=20
> --=20
> Derrick
> _______________________________________________
> AFS3-standardization mailing list
> AFS3-standardization@openafs.org
> http://lists.openafs.org/mailman/listinfo/afs3-standardization

--=20
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