Re: [nfsv4] NFS Version 4 Minor Revisions

brent@eng.sun.com

Message-ID: <3EBC427C.6030804@eng.sun.com>
From: Brent Callaghan <brent@eng.sun.com>
Subject: Re: [nfsv4] NFS Version 4 Minor Revisions
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

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
> nfsv4@ietf.org
> https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4