[AFS3-std] Re: A call for consensus on draft-deason-afs3-type-time-02

[Andrew Deason]

On Fri, 15 Jul 2011 13:11:18 -0500
"Douglas E. Engert" <deengert@anl.gov> wrote:

> http://datatracker.ietf.org/doc/draft-deason-afs3-type-time/

Based on the threads in afs3-stds, and on discussions I've had with
others, I propose the following going forward. This is what I'm working
on for an -03 draft, and it's what will appear unless I hear objections.

The epoch will be changed to the Unix epoch. Absolute time will be
signed so we can still represent the windows stuff. The language will
also be changed a bit according to Russ's suggestions ("number of
seconds since 1970 excluding leap seconds" or whatever it turns out to
be, see this sub-thread:
<http://thread.gmane.org/gmane.comp.file-systems.afs.standardization/1148/focus=1184>).

The granularity in this draft will not be changed. However, additional
types will be proposed to be used for higher efficiency and higher
granularity. That is, the current types will be AFSAbsTime64 which
corresponds to 64-bit 100-ns time, but we will also have types such as
AFSAbsTime32 (32-bit 1-s time) and AFSAbsTime96 (64-bit 1-s time plus
32-bit 1-ns). RPCs for which this matters will use some way of
accomodating and specifying these other types, but how they do so is
outside the scope of this draft (in theory this could be unions,
extended unions, separate RPCs etc; in practice right now we expect
extended unions).

In the interest of getting this i-d done as quickly as we can, the other
time types will not be added to this draft, but will be proposed in
separate i-ds and if we need to we can argue about them then. So, the
only change for draft-deason-afs3-type-time is that the type names will
be changed to AFSAbsTime64 etc, and I will include a paragraph
discussing the rationale and the future use of other time types for
interoperability and efficiency. I feel this will satisfy everyone's
concerns, as this approach should allow us to interoperate well with
other systems, but the common case should be kept nearly as efficient as
the current draft.

-- 
Andrew Deason
adeason@sinenomine.net