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

[Steven Jenkins]

On Tue, Jul 26, 2011 at 9:25 AM, Douglas E. Engert <deengert@anl.gov> wrote:
> This call for consensus was to extend to 7/25 yesterday.
> So far I have only seen 2 "OK" responses from Derrick Brashear
> and David Boyes, and a "why are we doing this" from an outsider.
>
> In the view of this chair, that does not constitute a consensus,
> and I will extend the call till Friday 7/29.
>

I have read the draft, and I do not support it in its current form.

I have several concerns: one around interoperability with other
filesystems and the second around the proposed interface itself.  Both
could be addressed by choosing a different solution than what is
proposed.  I  have some additional, more minor, concerns as well,
which I detail below.

The RFC covers how AFS can be extended to provide for better
interoperability with Microsoft systems, but it does not discuss
interoperability with another key platform, NFSv4
(http://www.ietf.org/rfc/rfc3530.txt).  In particular, NFSv4 supports
timestamps at the nanosecond level of granularity.  The difference
between the NFSv4 specification and the proposed RFC might cause
issues down the road and thus require this RFC to be revised; I would
prefer to see that revision done before the RFC is passed and language
added to clarify how that interoperability might function.

The core data type for NFSv4 time is as follows:

nfstime4
                  struct nfstime4 {
                          int64_t seconds;
                          uint32_t nseconds;
                  }


with an additional enum (time_how4) to designate whether client  or
server time is being referenced.

The seconds are the usual number of seconds since epoch, and the
nseconds is the offset based on the seconds in nanoseconds.  If the
proposed draft is accepted, when converting to proposed AFS timestamps
from NFSv4 timestamps, information would be lost.

The proposed RFC also does name the existing AFS time structure or
provide information about beyond a description that it only supports a
level of granularity down to a second.  Neither the actual data type,
nor the definition of epoch used in AFS-3 is provided.  That should be
remedied.

The third (and most significant) concern is that the proposed draft
proposes that the epoch be defined as January 1, 1601, rather than the
traditional Unix epoch of January 1, 1970.  At a minimum, the
rationale behind that choice should be explained in the RFC beyond the
one sentence stating that the epoch definition comes from the
Microsoft Windows FILETIME structure (also, should there be a
cross-reference here to a Microsoft specification document?  I am
concerned that we assert that definition to be true yet do not provide
a normative reference for this.).

I may be speaking incorrectly here (I apologize for not having
researched this more thoroughly beforehand, but I wanted to get this
feedback out before the Call completes), but my recollection is that
AFS time defines epoch to be January 1, 1970; thus, by adopting this
RFC, AFS would have two different definitions for epoch depending on
the time resolution used.  Given the confusion this might engender,
and the change from the current AFS-3 and Unix definition of epoch, I
suggest the definition of epoch not be changed.

Another issue is that the proposed AFSAbsTime and AFSRelTime data
types are not both necessary.  Absolute time can be represented as the
relative time since the epoch (and that would let us simplify the
names of the datatypes to something simpler such as 'afstime').

My suggestion is that it would be better to have the new AFS data
types mirror those of NFSv4 but also include the AFSAbsTimeRes
datatype (renamed to AFSTimeRes).  Microsoft Windows implementations
(or implementations with other time resolutions and definitions for
epoch), could then build on top of that and provide a more natural (to
that platform) interface.

Thank you,
Steven