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

[Matt W. Benjamin]

Hi Steven,

It seems as if the natural interop scenarios with NFSv4 involve converting from a common (e.g., lfs) time representation.  What am I missing?

Thanks,

Matt

----- "Steven Jenkins" <steven.jenkins@gmail.com> wrote:

> 
> 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.
> 
-- 

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309