Subject: [nfsv4] NFS Version 4 Minor Revisions

From: Robert Thurlow <[email-masked]>
Date: Wed, 7 May 2003 14:48:45 -0600 (MDT)

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

---

From: Brent Callaghan <[email-masked]>
Date: Fri, 09 May 2003 17:06:20 -0700

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

---

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

> Does the WG really need to decide between a "Feature"

I think we should, and should choose the 'train' model
because of the predictability and to provide a deadline
to make us get stuff done.  The WG chairs are free to
cancel trains that aren't full enough.

Rob T