Subject: RE: [nfsv4] NFS Version 4 Minor Revisions

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 9 May 2003 20:46:00 -0700

Brent Callaghan wrote: 
> Does the WG really need to decide between a "Feature"
> vs "Train" policy ?

It needs to have some approach to the matter.  As Rob 
indicated, a number of possibilities were considered.

> It makes sense to bundle a number of protocol extensions
> into a single minor version.  But I don't see any benefit
> in imposing an arbitrary cutoff for features.  Doing it
> on an annual basis sounds quite exhausting.

If someone has notes from the discussion, they can chime in
on what was said at the meeting, but let me just cite a few
benefits of the fixed cutoff.  Whether they are sufficient 
is a matter for individual judgement.

The first thing is that a fixed predicatble cutoff date 
makes planning easier.  It is hard to line up the resources
to do the work to make these minor versions (and thus the
features in them) a reality, if the dates when these events
will happen is not very predictable.

The other reason is that a fixed cutoff is a way of getting
prospective authors' attention.  If the train can leave without
you, then you have a motivation to do the necessary writing to
get your feature on board.  If the train is going to wait around
then incentive is reduce and even if somebody is industrious,
his feature can get held up indefinitely. 

A combination of these two is when you tell your manager you
need the time to write an i-d for some feature.  If there is
a fixed date, predictable in advance, by which something must
be done, the case for getting the resource (i.e. time) to do
this is stengthened.

As to the one-year schedule being exhausting, I hope so.
Let me explain.  For almost everyone, the work is going to
be proportional to the amount of change/new-features.  So,
I'd much prefer the exhausting case, in which we produce a
lot of interesting/useful protocol extensions to the slow
boring alternative.  The benefit of the one-year schedule
is not for us but for the users who will not have to wait
so long a time for things that they might need.  If you have 
a two-year schedule (or an enough-stuff policy that amounts
to a two-year turnaround), then someone may be waiting 
18 months in addition to the time to specify the feature
and implement the features, waiting for other unrelated
stuff.

If we insist that the feature i-d be thorougly developed 
before acceptance into the minor version (and we should),
then that's where most of the (exhausting) work will be.
The number of minor versions won't matter so much.  Four
features in two minor versions in two years won't be that
much more work than four features in one minor version in
two years.

There's only one person whose work will have a large component
proportional to the number of minor versions, rather than the
number of features.  That is Spencer.  If Spencer finds that
the annual schedule is not working, then there is no question 
but that we'll have to change it.

I hope that if we do the train model, we're not going to go
overboard on it.  If there isn't much worthwhile when
the annual deadline occurs, we shouldn't do a minor version 
that makes no sense.  If something very important looks
like it will be a month late, the working group should be
able to change the schedule, in order to get something 
lots of people need into their heands sooner.  However, 
to get back to motivating the authors, going for a one-
month slip, is not the same as holding the version 
indefinitely for this new feature.  I'm afraid of paralysis
in that case.

> I recommend the NFSv4 WG follow the practice of other
> WGs and have the feature set and schedule determined
> on a case-by-case basis by WG consensus (with AD advice),
> i.e. "Enough Stuff."

I thought we had consensus that we'd try the train approach 
and see how well it works.  Apparently we don't have consensus.
I guess we have another thing to discuss at the Long Interim 
Working Group Meeting.  Sigh.

-----Original Message-----
From: Brent Callaghan [mailto:[email-masked]]
Sent: Friday, May 09, 2003 8:06 PM
To: [email-masked]
Subject: Re: [nfsv4] NFS Version 4 Minor Revisions

Does the WG really need to decide between a "Feature"
vs "Train" policy ?

It makes sense to bundle a number of protocol extensions
into a single minor version.  But I don't see any benefit
in imposing an arbitrary cutoff for features.  Doing it
on an annual basis sounds quite exhausting.

I recommend the NFSv4 WG follow the practice of other
WGs and have the feature set and schedule determined
on a case-by-case basis by WG consensus (with AD advice),
i.e. "Enough Stuff."

	Brent

Robert Thurlow wrote:
> Now that NFSv4 is (finally!) done with, we need to turn our
> attention to minor revisioning.  There have been some off-list
> discussions about this at Connectathon 2003, and I presented
> on this at IETF 56; now I want to get this discussions out on
> the WG alias to get feedback from all.  The proposed timeline
> needs input, especially.
> 
> The basic issue is that RFC3530 lists some, but not all,
> rules necessary to manage content in new minor revisions of NFS
> Version 4.  We need to figure out what's missing and fill in
> the gaps so that people proposing new functionality know what
> to do.
> 
> The NFS Version 4 specification RFC3530 lists the following
> information and rules regarding its extensibility:
> 
> Basics
> 
>    o    Minor revisions are to be described in standards-track documents
>         only.
> 
>    o    Minor revision negotiation is undefined, but COMPOUND operation
>         number 2 is reserved for this purpose.
> 
>    o    COMPOUND RPC requests and responses are to be tagged with the
>         minor revision number being used.
> 
>    o    The error code NFS4ERR_MINOR_VERS_MISMATCH is to be used by the
>         server to indicate non-support of the minor revision number in a
>         COMPOUND RPC.
> 
> Prohibited Changes
> 
>    o    RPC procedures may not be added or removed.  This
>         maintains the normal behaviour with RPC-based applications.
> 
>    o    No changes may be made to the arguments or results of existing
>         operations.  This ensures existing behaviour will be maintained.
> 
>    o    No changes may be made to existing attributes.
> 
>    o    No operations, attributes, flag bits or enumerations may be
>         deleted.
> 
>    o    No new feature can be made mandatory.  This ensures
>         that implementors can get experience with new features before
>         they're widely promulgated.
> 
>    o    Returned objects may not be mixed between compounds with
>         different minor revision numbers.
> 
> Permissible Changes
> 
>    o    New compound operations can be added.  This is the
>         main expansion route for new features.
> 
>    o    New attributes can be added.
> 
>    o    New mode bits can be added.
> 
>    o    A spec can add new enumerations or flag bits.
> 
>    o    A spec can declare that operations or attributes are mandatory
>         to NOT implement.  This is the only way to make an existing
> 	feature go away.
> 
>    o    A spec can downgrade or upgrade features along MUST/SHOULD/MAY
>         axis.  This is a way to deprecate features or make them
> 	mandatory, as required.
> 
> Although there are a number of clear constraints in the above, not
> enough has been unspecified to give clear guidance in how to manage
> the creation of a new minor revision.  For example, how is the
> working group leadership to decide how to define a new minor
> revision?  How many new features or fixes go into a minor revision,
> and how are are to be combined?  How does negotiation of minor
> revisions occur?
> 
> There are several options in how to package minor revisions.  Some
> choices that have been discussed are listed below.
> 
> Enough Stuff: Wait until, in the judgement of the working group chairs,
> there is enough content to make a revision worthwhile.  This is
> flexible, but quite unpredictable.
> 
> Feature Slots: Slot a logical set of changes together and plan to
> deliver them in a particular revision.  For example, revision 1 might
> be simple fixes and extensions, and revision 2 might be replication and
> migration support.  This makes each minor revision stand alone as a
> coherent piece of related work, but it means that a delay in one
> deliverable will delay all other protocol changes; this does not seen
> optimal.
> 
> Train Model: Schedule revisions to occur periodically as long as there
> is unfinished work listed in our charter, and entertain ideas from
> participants for content.  As long as proposed changes are ready by the
> due date, they will become part of the next minor revision.  This is
> predictable, but could impose a delay of one period on a feature which
> isn't quite ready by the cutoff.
> 
> This issue was discussed among members of the NFS community at the
> Connectathon 2003 testing event.  Participants there found the train
> model the most attractive.  One of the key reasons is that the NFS
> community tests new features every year at Connectathon.  This
> suggests an annual cycle and provides a meaningful deadline.
> 
> To be successful with this, the working group chairs must define a
> schedule with milestones to assure that features are known in concept
> early enough, and "fully cooked" by debate and improvement on the
> working group alias in time to be coded and tested at Connectathon.
> These milestones might look like this:
> 
>    o    Initial feature draft (-00) by June 1
> 
>    o    Complete draft reflecting WG consensus by August 15
> 
>    o    The document editor combines by October 1
> 
>    o    Feature is tested at Connectathon (nominally March 1)
> 
> These milestones are somewhat arbitrary; the real goal behind them
> must be to meet goals in our working group charter and make NFS a
> better protocol.  There will sometimes need to be exceptions to the
> above deadlines where it makes sense.  The working group chairs own
> these rules, so they are ultimately responsible for applying them in
> practice.  It is hoped that exceptions will be rare.
> 
> It seems to me that the NFS community will need to change our working
> style to match this new rhythm.  We will need to be focusing on
> brainstorming new specifications in spring, dealing with details and
> prototyping in the summer, and doing serious coding in winter.  This is
> a change to the asynchronous development done currently.  Also, this
> model does not fit for large pieces of work which do not line up with
> the defined milestones.
> 
> One final issue: 
> IETF working groups are supposed to come into existence, produce
> useful work within their charter, and conclude their operation.  This
> proposal on its face may appear to attempt to create a working group
> in perpetuity, which is not consistent with the IETF.  This is not
> the case.  NFS Version 4 is a large and complex protocol which will
> require some time to debug, promulgate and deploy.  There are also
> still have large items of work remaining on our charter.  It is
> incumbent on anyone proposing to change the protocol, in association
> with the working group chairs, to show how their work fits within the
> current charter or to justify a bounded charter extension which will
> cover the work.  The NFS Version 4 working group expects to complete
> its work items and disband as usual.
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4

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

---

From: Robert Thurlow <[email-masked]>
Date: Mon, 12 May 2003 13:40:49 -0600 (MDT)

Dave Noveck wrote:

> lots of people need into their heands sooner.

I believe this is an important job function of the nfsv4
working group co-chairs.

> Working Group Meeting.  Sigh.

Whoa, Dave - remember that even a consensus at a proper
NFSv4 WG meeting is subject to review on the alias, and
that's even more true about this unofficial discussion
at Connectathon.  We're trying to establish consensus
with this discussion, and as such we need folks who were
present to reiterate their agreement or disagreement here.
Could we hear from other V4 folks what they think of this
proposal, please?

Thanks for reiterating the arguments, I think you brought
a good deal of the earlier points into play here.

Rob T