From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 11/08/00-11:19:13 AM Z
Message-ID: <BC0FBE708897D4118C5500902745938E21E43F@black.eng.netapp.com>
From: "Noveck, Dave" <Dave.Noveck@netapp.com>
Subject: RE: NFSv4 at Proposed Standard (was Re: downgrade/upgrade)
Date: Wed, 8 Nov 2000 09:19:13 -0800
> I certainly expect that the current people implementing understand.
> And if any lurkers on the mail list didn't understand the issues,
> I presume they do now.
> Any against this "consensus" on understanding?
> Practically speaking (again) I see the March 2001 timeframe as being
> a forcing function for a next revision - reflecting a roll up
> of changes that may result from the close completion of several
> implementations.
This leads to the question of what we code to for the next bake-off.
There are a number of things that came out of the last bake-off and
the ensuing discussion.
If we believe in testing the protocol by implementing it, we should
include whatever consensus we arive at on those items, by including
it in whatever we all code to for Connectathon. Then we can test
something that is as close as possible to what we hope will be the
eventual Draft Standard. Then we can incorporate the set of things
that come out of Connectathon (we hope it will be small or empty).
There are a lot of minor items that need to be resolved (Those who
have volunteered to produce something on any of these should consider
themselves nagged), but I think is it particularly necessary to decide
on the following (somewhat inter-related) big-ticket items:
1) What is a stateid?
2) How big is a stateid? (Is 64 bits too small?)
3) What to do about the NT server open-upgrade-downgrade issue?
> On a positive note:
>
> GREAT WORK GUYS doing the implementations!
> The IETF process works.
> > In any case, my question is effectively, do people recognize that the
> > Proposed NFSv4 standard is likely to be changed in incompatible ways?
> > If we reach consensus that (a) yes we understand, and (b), we'll do it
> > anyway, fine. Hopefully the to be published nfsv4 proposed standard can
> > have some language indicating that it is effectively DOA, so that the
> > interoperability nightmare I believe will occur, will be minimized.
> >
> > -mre
> >
This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:24 AM Z CST