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. 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 _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
