Re: [nfsv4] draft haynes-nfsv4-versioning: Issues relating to opcode assignments etc.

[David Noveck <[e-mail]>]

I've prepared some changes to go into draft-haynes-nfsv4-versioning-02 (or
draft-ietf-nfsv4-versioning-00, if that happens first), that include
Benny's suggestion.   They are listed below under the heading ''*Changes
Proposed*:". In addition to material following up on Benny's suggestion,
there are a few other changes/corrections that I noticed going through the
-01.

To follow up on Tom's original thought, I don't see that there is much
regarding this draft that you can call a "controversy".  It may be that my
idea of what constitutes a "controversy" is conditioned by the political
ads I've seen recently,  However, even by the politer standards of the
IETF, I haven't seen much disagreement about major points.  The changes
below, and the changes already sent out address minor issues with the
current draft.  I'm sure that other such issues will come up and be
addressed, as we go forward on moving this through the process toward an
eventual WGLC.

As far as I'm concerned, with these changes and the ones I sent out Oct 24,
the document is ready to go forward with as a working-group group
document.  I'd like to hear other people's opinions on this question.


*              Changes Proposed:              *


*The following changes are to section 4:*

*Prefix the following material to rule #15 (*Needed to be compatible with
*draft-ietf-nfsv4-minorversion2**) :*

Other than where explicitly documented in a minor version's

specification document,


*The following changes are to Section 5.2, currently entitled **Additional
Informational Documents*


*The existing title and first two paragraphs of the section will
be replaced** by the following*:

*  5.2  Additional Documents to be Produced*.


Additional documents will be required from time to time.  These

documents will eventually become RFC's (informational or standards

track) as described below), but the work of the working group and of

implementers developing features will be facilitated by a progression

of document drafts that incorporate information about new features

that are being developed or have been approved as Proposed Standards.


*5.2.1. Minor Version Indexing Document *


One document will organize existing material for a minor version

undergoing extension so that implementers will not have to scan a

large set of feature definition documents or minor version

specifications to find information being sought. Successive drafts

of this document will serve as an index to the current state of

the extensible minor version. Some desirable elements of this

indexing document would include:


*The first two bulleted items in the bulleted list in this sections are to
be deleted.*

*The following material should replace the existing last paragraph of the
section.*


The frequency of updates for this document will be affected by

implementer needs and the ability to easily generate document

drafts, preferably by automated means.  The most desirable situation

is one in which a new draft is available soon after each feature

reaches the status of a Proposed Standard.


* 5.2.2. Consolidated XDR Document*


This document will consist of an updated XDR for the protocol as

a whole including feature elements from all features and minor

versions accepted as Proposed Standards.


A new draft should be prepared whenever a new feature within an

extensible minor version is accepted as a Proposed Standard. In

most cases, feature developers will be using a suitable XDR which

can then be reviewed and published.  In cases in which multiple

features reach Proposed Standard status at approximately the same

time, a merge of the XDR changes made by each feature may be

necessary.


* 5.2.3. XDR Assignment Document*

This document will contain consolidated lists of XDR value

assignments that are relevant to the protocol extension process.

It should contain lists of assignments for:


o  operation codes (separate lists for forward operations and for

   callbacks)


o  attribute numbers


o  error codes


o  bits within flag words that have been extended since they were

   first introduced.


o  enumeration values for enumerations which have been extended

   since they were first introduced.


For each set of assignments, the individual assignments may be of

three types:


o  permanent assignments associated with a minor version or a

   feature extension that has achieved Proposed Standard status.


   These assignments are permanent in that the assigned value will

   never be re-used.  However, a subsequent minor version may

   define some or all feature elements associated with a feature

   to be Mandatory to NOT support.


o  provisional assignments associated with a feature under

   development (i.e. one which has been approved as a working-

   group document but has not been approved as a Proposed Standard)


   Provisional assignments are not are not permanent and the values

   assigned can be re-used in certain circumstances.  In

   particular, when a feature with provisional assignments is not

   progressing toward the goal of eventual Proposed Standard

   status, the working group can judge the feature effort to have

   been abandoned, allowing the codes formerly provisionally

   allocated to be reclaimed and reassigned.


o  definition of individual assignments or ranges reserved for

   experimental use.

A new draft of this document should be produced, whenever:


o  A minor version or feature specification is accepted as a

   Proposed Standard.


o  A new feature is accepted for development and a draft of the

   corresponding working-group standards-track document is produced

 o  A feature previously accepted for development is abandoned.


o  The working group decides to make some change in assignments

   for experimental use.


* 5.2.4. Transition of Documents to RFC's*


Each of these documents should be published as an RFC soon after

the minor version in question ceases to be considered extensible.

Typically this will happen when the working group makes the

specification for the subsequent minor version into a working

group document.  Some specifics about the individual documents

are listed below:


o The most current draft of the indexing document for the minor

  version would be published as an informational RFC.


o The most current draft of the consolidated XDR document should

  be published as a standards-track RFC.  It would update the

  initial specification of the minor version.


o The most recent draft of the XDR assignment document should be

  published as an informational RFC.


Handling of these documents in the event of a post-approval XDR correction is
discussed in section 6.1.

*The following changes are to Section 6:*


*In the second bulleted item, change "to may be used' to "may be used".*

*After the first list of bulletted items, add the following new paragraph:*

Issued related to the effect of XDR corrections on existing

documents, including co-ordination with other minor versions, are

discussed in section 6.1.


*The following new material goes at the end of the existing section 6:*

*   6.1.   Documentation of XDR changes*

In the event of an XDR correction, as discussed above, some document
updates will be required.  For the purposes of this discussion we
call the minor version for which XDR correction is required minor
version X and the minor version on which development is ocurring

minor version Y.


The following discusses the specific updated documents which could

be required.


o  The specification of the feature in question will have to be
 updated to explain the issue, how it was fixed, and the
   compatibility and upgrade strategy.  Normally this will require

   an RFC updating the associated feature specification document.

   However, in the case of a correction to a feature documented in

   in a minor version definition document, the RFC will update that

   document instead.

o  An updated XDR for minor version X will be produced.

o  An updated minor version indexing document for minor version X

   is desirable but not absolutely necessary.

o  An updated XDR assignment document will be required.  It should
   be based

*______________________________**___**__________________________*
*______________*