[AFS3-std] Re: Review/Comments Extended Callback Information Draft

Jeffrey Hutzelman jhutz@cmu.edu
Fri, 09 Oct 2009 19:01:09 -0400


--On Thursday, October 08, 2009 03:39:00 PM -0500 Andrew Deason 
<adeason@sinenomine.net> wrote:

> On Thu, 8 Oct 2009 16:32:57 -0400 (EDT)
> "Matt W. Benjamin" <matt@linuxbox.com> wrote:
>
>> Hi Jeff,
>>
>> What concerns me is the prospect of the XCB draft needing to
>> anticipate design decisions that should be left to their authors, in
>> their good time.  One of the ways we'll measure the success of our
>> process is that it can come to closure efficiently on proposals that
>> come before it.  It won't be efficient if we allow time dilation to
>> create entanglements between proposals that should have been
>> independent.  It makes most sense to me to regard RPC refresh as a
>> transformation on all eligible protocol, including this one.
>>
>> It appears I do need to amend the XCB draft to deal with 64-bit
>> time.  I will do this in whatever way best fits consensus here.  I
>> would request that, as you suggest, we not give up reviewing this
>> version as yet.
>
> Can we just explicitly state that it will be further specified in a
> later revision?

No.  The specification is incomplete in its present form.  It doesn't 
provide enough information to produce interoperable implementations, and we 
should not approve a specification that is known to be incomplete in this 
way.  We can, of course, continue to review the present revision, expecting 
that this particular problem will be fixed before we are finished with the 
document.  To do otherwise would be silly.

> Or state that it is to be specified in the RPC refresh document? Trouble
> is, I'm not sure how to unambiguously refer to the RPC refresh document,
> since it doesn't exist yet...

We could do that, but then this document would have a normative reference 
to the RPC refresh document, which means you'd need to read both to 
successfully implement XCB.  There's nothing wrong with that, but usually 
the way such references are handled is for publication of the present 
document to stall until the reference stabilizes.

-- Jeff