This is a followup to my talk at IETF 92. The slides are at http://www.ietf.org/proceedings/92/slides/slides-92-nfsv4-9.pdf
Work is now proceeding on draft-ietf-nfsv4-versioning-01. Before that's submitted, I'd like to get people's opinions so that
the draft when produced will not be too far from the general sense of the group on these issues. I don't expect us to be
anywhere near consensus for a while but I want the upcoming version to be close enough to where the group as a whole
is that we will mostly be resolving issues of detail. At least I hope so.
I think there is a genera;l agreement as to two points:
- We want to do a lot of our future work in terms of the addition of individual features, as specified in draft-ietf-nfsv4-versioning-00.
- We don't want any more minor versions as big/disruptive as NFSv4.1 was.
This leaves us with a series of issues that relate to the question of what minor versions are for. Since the versioning RFC is
to define our approach to NFSv4 versioning as a whole, we have to address creation of minor versions as well extensions of
existing minor versions. An important goal for the NFSv4 versioning RFC is to address both of those in a coherent way.
One way to look at the issues is to look at each of the things that were done in NFSv4.1 or could be done in minor versions
according to the minor versioning rules in RFC5661 (or draft-ietf-nfsv4--versioning-00) and see whether we want to allow
such things in minor versions, disallow them, or allow them with restrictions
- Describe the protocol from ground zero, rather than as a series of deltas
I think there is general agreement that we don;t want to do this any more. In a way, this general agreement is beside
the point. There is nobody to do this and the IESG isn't going to let us do it anyway.
One interesting question is whether making this restriction is sufficient to prevent minor versions from becoming too
big/disruptive. If it is, perhaps we might want to be relatively liberal about other sorts of potential restrictions.
- Introduce required new features.
Since this was forbidden by the rules in RFC3530, and only changed for v4.1, we might simply go back to the v4.0 version
On the other hand, it may be that the problem was the size of the feature being introduced, rather than the fact that it
was introduced as required. The whole issue is complicated by the text of rule #12 in RFC5661, which seems to
suggest that you can only introduce a feature as required if it is big/disruptive.
It may be that the ability to refactor any parts of the protocol depends on the ability to make a required changed at some
point, and that the ability to do so at introduction is not the essential issue.
- Change the statuses of existing features, including making features mandatory to not support
If you believe, as I do, that "recommended" feature status should be done away with somehow, then this boils down to
changes in the sets of required or allowed features. This inherently raises interversion compatibility issues and we
need to give some kind of guidance about dealing with this conflict.
- Making non-XDR-based changes in the protocol
The existing minor versioning rules do not mention this possibility, focusing solely on possible XDR changes.
There were a number of Non-XDR-based protocol changes going from 4.0 to 4.1. Examples are the creation of a new
a new special stateid to represent the current stateid, the handling of seqid 0 in stateid's and the semantic changes
eliminating the use of owner seqids and clientids in locking requests.
The basic choice we have is whether to forbid things like this going forward. If they are allowed they should not be allowed
in features done as separate extensions. Interestingly, all the ones done in v4.1 were required at introduction but there's no
good reason not to change that going forward.
- Adding pNFS-like extension mechanisms to the protocol,
This has happened in going from 4.0 to 4.1 since the pNFS extension mechanism has to be a pNFS-like one
. It doesn't seem
like we want to say this is something that must not be repeated.
Since there are no likely candidates for additional mechanisms of this sort on the horizon, we could defer this.
On the other hand, this is a possible means of protocol extension which has been used and we might as well give some
guidance as far as incorporating such alternate means of protocol extension in our version management framework. Although, we
have the option of updating this document later, it would be better if we could avoid the necessity to do so, if we can.
There are also a number of other questions I'd appreciate hearing people's views about:
- What to do about recommended/RECOMMENDED as a feature status?
This is tied to he specification of non-REQUIRED attributes as "RECOMMENDED" in RFC's 5661 and 7530. "recommended" was used in
RFC3530. It doesn't seem that "RECOMMENDED" is in line with RFC 2119.
As RFC7350 now says that "RECOMMENDED" attributes are not RECOMMENDED according to RFC2119, we might well get rid of the
current assumption that that most attributes are recommended/RECOMMENDED at introduction. Unfortunately, RFC5661 still has
"RECOMMENDED" attributes with the implication that this is in line with RFC2119. In any case, as far as version management
goes, I don't see how it makes sense to specify features as "RECOMMENDED". What really makes a difference is whether clients
can assume support or have to deal with the possibility of non-support.
- Upper-case vs. lower-case feature status
The -00 now uses upper-case terms for features statuses including "RECOMMENDED".
If we could ditch RECOMMENDED/recommended as a feature status, REQUIRED and OPTIONAL would work.
If we can't do that, then we could make the relevant feature statuses as required and non-required, treating any potential recommendation
with regard to support as out-of-scope from the viewpoint of version management.
- How to deal with the current assumption that features will normally/naturally progress to being required.
I think this has to change. It is quite possible for a feature to be successful/useful without it becoming essential for use in every NFSv4
In any case, I'd appreciate any comments people have on these or other version management issues. As I indicated, one can't expect anything
like consensus at this point. I anticipate that this Working Group First Call
will be over in about two weeks after which I'd like us to have a
concrete -01 that we can discuss.