--On Thursday, October 08, 2009 03:39:00 PM -0500 Andrew Deason
<[email protected]> wrote:
On Thu, 8 Oct 2009 16:32:57 -0400 (EDT)
"Matt W. Benjamin" <[email protected]> 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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
