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

[Derrick Brashear]

On Wed, Jul 27, 2011 at 5:10 PM, Steven Jenkins
<steven.jenkins@gmail.com> wrote:
> On Tue, Jul 26, 2011 at 9:25 AM, Douglas E. Engert <deengert@anl.gov> wro=
te:
>> 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. =A0Both
> could be addressed by choosing a different solution than what is
> proposed. =A0I =A0have 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). =A0In particular, NFSv4 supports
> timestamps at the nanosecond level of granularity. =A0The 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
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct nfstime4 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int64_t seconds;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint32_t nseconds;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>
>
> with an additional enum (time_how4) to designate whether client =A0or
> 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. =A0If the
> proposed draft is accepted, when converting to proposed AFS timestamps
> from NFSv4 timestamps, information would be lost.

I disagree that we should devote the extra bits on the wire to
preserve this extra
information in the many cases a timestamp will appear on the wire
given how few will
have this extra information to "lose".

> The proposed RFC also does name the existing AFS time structure or

"does not"?

> provide information about beyond a description that it only supports a
> level of granularity down to a second. =A0Neither the actual data type,
> nor the definition of epoch used in AFS-3 is provided. =A0That should be
> remedied.

afs_int32, afs_uint32 are used sometimes interchangeably and sometimes
incorrectly, so, what, you're like the draft to say that none was
previously defined?
because anything else would be untruth.

>
> 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. =A0At 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? =A0I 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;

typically uses, but does not explicitly define.

>thus, by adopting this
> RFC, AFS would have two different definitions for epoch depending on
> the time resolution used. =A0Given 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.

i am on the fence about this, and truthfully was from the beginning. i
can support
either position.

> Another issue is that the proposed AFSAbsTime and AFSRelTime data
> types are not both necessary. =A0Absolute 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').

disagree, and we beat this point seemingly to death a while ago.
a relative time doesn't necessarily have anything whatever to do with
the epoch, so once you've
proposed going down the road of defining the epoch, now attempting to
backfit a differential onto it by cheating the epoch to be the start point
seems wrongheaded at best.

> 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). =A0Microsoft 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.



--=20
Derrick