Subject: feedback on minor versioning at IETF meeting

From: Mike Eisler <[email-masked]>
Date: Tue, 16 Nov 1999 05:06:14 -0800 (PST)

I presented the minor versioning protocol (that I posted to the WG
alias a couple weeks ago) at D.C. IETF meeting last week.

Minor versioning continues to be a very controversial topic.

The objections can be summarized as:

	- since any minor revision has to go through the full
		IETF process, does it save any overhead versus simply
		increasing the NFS program's version number (i.e. go to
		NFSv5)

		My thinking:

			As soon as you bump up the version number,
			everything is on the table for changes. When I
			co-hosted the BOF in the 1996 San Jose IETF
			meeting, never in my wildest dreams did I think
			that NFSv4 would be this different from NFSv3.

			Bumping the program version number for minor
			changes like a new attributes devalues major
			NFS revisions. The question whether an
			implementation support NFS v2, v3, v4 is a big
			deal. When you add v5, v6, ... v100, which are
			variations on v4, it creates confusion when
			marketing the protocol.

		Ted Ts'o noted that that version negotiation and
		interoperability becomes harder once you use the
		version number of the RPC program to create minor
		versions because there's no requirement that
		implementations support a common version, unlike the
		minor versioning proposal I've made. I'll add that if
		there are gaps  in the range of what the server
		supports, it is harder for the client to figure it
		out.

	- The rule

A client and server that supports minor version X must support minor
versions 0 through X-1 as well.

	can be a problem.

	Suppose in minor version X we introduced a new operation, "find
	recursive" which given a directory file handle, returns the
	directory entries for the directory, and its subdirectories
	recursively. Implementors would quickly find that this
	operation is a bad idea, and the next minor version, X+1 would
	declare it as mandatory to not implement. However, if "find
	recursive" were mandatory to implement in minor version X then
	the above rule would still force servers to implement it.

	The feeling during the WG meeting was that perhaps we shouldn't
	have rules about minor versioning so that we avoid such conundrums.

	After the WG meeting concluded I thought more about it. I
	recalled that lack of well defined rules was what caused minor
	versioning to be so controversial 3 years ago, because people
	seemed unwilling to provide for such a powerful feature without
	some limits on its use.

	So I propose the following.

		- Add a new rule that states that if a feature is new
			to minor version X, then not until X+1 can the
			feature be listed as mandatory. This way, we
			get an opportunity for implementation experience.

		- In draft-ietf-nfsv4-XX.txt, state that as part of the
			process of producing the each minor revision,
			any of the minor versioning rules might be re-visited.

	Also, before the meeting, I realized that deleting enumeration
	values and flag bits in a minor version was a bad idea, for the
	same reason that deleting operations was a bad idea, since it
	is tantamount to changing the value of flag bit or enumeration
	from one value to another. That will simply complicate
	implementation.

I'll follow up this e-mail with the re-worked minor versioning document
that synthesizes all the discussion on the proposal and my proposed
changes to it.

	-mre