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. Thanks, Matt ----- "Jeffrey Hutzelman" <[email protected]> wrote: > Don't tell us "it should be read to mean foo". Make it actually _say_ > foo. > If it's presently underspecified, that will need to be fixed before it > can > be considered done. > > Of course, that should not cause people to give up on reviewing this > version. > <snipped> > > Not necessarily. For example, someone could reasonably propose that > XCB > should be updated now to use 64-bit FID's, rather than requiring an > update > later. I'm not ready to make such a proposal yet, but I might before > this > is done. That is reasonable. > > -- Jeff -- 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://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
