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

[Derrick Brashear]

On Tue, Jun 5, 2012 at 11:24 PM, Andrew Deason <adeason@sinenomine.net> wro=
te:
> 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

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 prot=
ected
callback be generated if at least one FetchStatus object was returned for t=
he
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. =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.

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.



--=20
Derrick