On Wed, Jul 27, 2011 at 5:10 PM, Steven Jenkins <[email protected]> wrote: > On Tue, Jul 26, 2011 at 9:25 AM, Douglas E. Engert <[email protected]> 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.
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. Neither the actual data type, > nor the definition of epoch used in AFS-3 is provided. That 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. 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; 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. 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. 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. 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'). 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). 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. -- Derrick _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
