Subject: RE: [nfsv4] Proposed agenda items for next (6/27) conference call

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 20 Jun 2006 22:08:43 -0400

The minor version model allows small minor versions and it allows 
more substantial minor versions.  I don't think that there is any
particular mandate for either approach. 

The advantages you cite do clearly exist but there are also 
disadvantages to small minor versions.  The sum of the work to
do N minor versions is more than (we can argue about how much
more) the work to do one minor version with N items.

The working group did consider a number of options for v4.1 and
arrived at a consensus.  I don't think RECLAIM_COMPLETE-only
was ever considered but we did consider a v4.1 that only had the
SECINFO changes and some cleanup.  We also considered pushing 
pnfs off to v4.2, which would have made v4.1 smaller and decided
against it.

Whether that was the right decision or not is something we may
never really know but it is the decision we made and I don't
see any need for a radical change of direction.  The working
group is free to re-open this, but we are not going to make
progress if we keep changing directions, absent some strong
evidence that we made a bad decision or that circumstances
have changed.  If there were some absolutely critical feature
that we thought justified a special quick (relatively) v4.1,
the group could decide to do that but I haven't seen anything
like that.

> And releasing a RECLAIM_COMPLETE-only v4.1 wouldn't have to slow
> down other ongoing minor-version work.

In the universe in which a RECLAIM_COMPLETE-only v4.1 did not 
slow down v4.2 ne v4.1, we would have been ready for working
group last call for the the current v4.1 by the Montreal
IETF.  I'd like to live in that universe but I live in this one.

In real life, if you decide on a small V4.1, people will spend 
time deciding what should go in it.  You know exactly what 
should be in it, but everybody else does too, which means you
have to spend time reaching consensus.  Someone has to write the
spec for what we decide has to be in it and edit it.  I don't
see any superabundance of spec editing time available.  It is
hard enough to make progress on one minor version.  The burden
of proof should be on those who believe that we can do two 
simultaneously.

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]]
Sent: Tuesday, June 20, 2006 5:20 PM
To: Noveck, Dave
Cc: [email-masked]
Subject: Re: [nfsv4] Proposed agenda items for next (6/27) conference
call

On Mon, Jun 19, 2006 at 09:21:41AM -0400, Noveck, Dave wrote:
> The second item is that I'd like us to begin consideration of a schedule
> for the v4.1 spec.

The minor version process seems to have been designed to allow small,
incremental improvements.  Such improvements would have a clear advantage over
a single monolithic 4.1--we could get them to users and get implementation
experience earlier.

To give a concrete (somewhat arbitrary) example: the RECLAIM_COMPLETE proposal
adds a single new operation and a few pages of text.  We could easily package
it up in a 4.1 draft and implement it before our next testing event.  Users
would see a clear improvement in reboot recovery times (and possibly in
reliability).  And releasing a RECLAIM_COMPLETE-only v4.1 wouldn't have to slow
down other ongoing minor-version work.

If we tie together sessions, pnfs, directory delegations, etc., etc., we commit
ourselves to a process that may not produce user-visible changes for years.

--b.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4