On 7 Mar 2011, at 21:33, Andrew Deason wrote:
I've published an I-D defining a couple of types to be used for time
in
future RPCs ("RPC refresh", ubik, and the like):
<http://datatracker.ietf.org/doc/draft-deason-afs3-type-time/>
The 100 ns resolution and epoch I think is basically what's been
discussed before, but the handling of varying time resolution is new.
I'm happy with the 100ns resolution stuff - this is essentially what
we discussed and reached consensus on in Edinburgh. Thanks for finally
getting that published
However, I'm less sure about the time resolution variable. This means
that we are in effect tripling the size of every time payload in AFS.
I'd be interested in a far more detailed discussion of the pros and
cons for including this variable. In particular, will this information
really change sufficiently rapidly that it needs to be included with
every single piece of time data? Does it give us benefits that
specifying a per-service granularity using capability bits won't?
Cheers,
Simon.
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
