| NFSv4 | D. Noveck |
| Internet-Draft | HPE |
| Intended status: Informational | March 10, 2016 |
| Expires: September 11, 2016 |
NFS Protocol Extension: Retrospect and Prospect
draft-dnoveck-nfs-extension-04
This document surveys the processes by which the NFS protocols have been extended in the past, including all of the NFS major and minor versions. It also looks forward to methods of protocol extension that might be used by NFS in the future.
A particular focus is on how the minor versioning model of NFSv4 has worked and what is being done to enhance version management within NFSv4. The work already done in the new NFSv4 version management document is summarized, and there is a discussion of further issues the working group will need to address in moving that work forward.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 11, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document examines the subject of protocol extension within the NFS family of protocols. In order to better understand the issues that exist going forward with NFSv4, we examine the history of protocol extension throughout the development of NFS including
With this history in mind, we discuss the issues that the working group needs to address in order to define and adopt a consistent and comprehensive approach to version management for the NFSv4 protocols.
It is intended that these key words be used in this document in a way that is consistent with their definition in [RFC2119].
However, because of the considerations noted below, there are some issues that readers need to be aware of.
It is not altogether clear whether these keywords are to be limited to requirements regarding protocol implementations, or whether they can reasonably be used in specifying guidance directed at future potential RFCs. In many cases, these terms are defined in ways that strongly suggest that they are meant to apply to implementations and much of the discussion seems to make sense only in that context. On the other hand, there is no explicit statement to that effect.
As an example of the difficulties that can result in trying to resolve this question, consider the statement in [RFC2119] saying that these imperatives "MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)." On the one hand, this is a case in which these terms are directed at a future document, rather than implementations. However, it seems as if this use is itself not consistent with what it requires of others. While the misuse of these terms is undesirable and it is best to avoid such misuse, it is hard to see exactly how that is "actually required for interoperation or to limit behavior which has potential for causing harm."
The nature of this document is such that it does not directly specify implementation requirements. In some cases it discusses potential requirements that an RFC derived from [NFSv4-vers]) might direct to implementations. In other cases, requirements are one step farther removed from protocol implementations. For example, the version management RFC might specify the kinds of requirements that future minor version definition documents and feature definition documents might specify.
The documents that are discussed herein, have at times used these key words in a way that seems to be at variance with the definitions in [RFC2119]. For details, see Sections 6.1 and 9.2.
The reader should be aware of our practices in this document regarding these terms. We only apply these upper-case key words to directions regarding protocol implementations, rather than to guidance intended for those writing RFCs. While it is possible that there could be cases in which directions targeted at future RFC's are necessary to assure interoperation etc., we know of no actual instances.
In this document, these keywords will often appear as quotations from existing documents, either direct or indirect. Readers should be aware that it is possible that some such uses might not be in accord with [RFC2119].
In other cases, these keywords will be in the context of proposals/suggestions of what future RFCs could or might say regarding certain issues.
The use of these terms as part of minor versioning rules poses some troublesome issues in the context of this document. These rules have appeared in [RFC3010], [RFC3530], [RFC5661], and [NFSv42]. They have also appeared in various drafts of [NFSv4-vers], and in various drafts leading up to [RFC7530]. In presenting these rules, there have been multiple switches between the RFC2119 keywords and corresponding lower-case terms.
Use of the terms "OPTIONAL" and "REQUIRED" as feature statuses would conform to our general practice since a feature status is essentially a way in which a minor version specification RFC might REQUIRE (or not) implementations to support a given feature. Unfortunately, "RECOMMENDED" would not fit that model very well. Also, it is difficult to see how the same feature can be "OPTIONAL" in one minor version and "REQUIRED" in another given the meanings that [RFC2119] assigns to these terms.
In this document, in the interests of uniformity, we will use lower-case terms for feature statuses, except when we are referring to what is said in a particular document which used the upper-case keywords.
Protocols often require means by which they can be extended. Such extensions may be needed to meet new requirements, to correct protocol weaknesses exposed by experience, or even to correct protocol bugs (as becomes more probable when protocols are published as RFC's without fully fleshed-out implementations).
We need to distinguish here between protocol "extension" and "versioning". Versioning is a form of protocol extension but not every form of protocol extension can be accommodated within a versioning paradigm.
When a versioning paradigm is in place, groups of extensions are conceived of as ordered, allowing extensions in subsequent versions to build upon those in previous versions. When multiple extensions are combined into a single version, each of the extensions may be built assuming that the others will be present as well. In such cases, there can be the opportunity to make design changes in the protocol, allowing elements of the protocol to be restructured, sometimes in major ways.
When a versioning paradigm is in effect and extensions are optional, extensions cannot build upon one another, since the presence of any particular extension cannot be assumed. In such cases, the ability to restructure the protocol is reduced, but smaller changes may be introduced more easily.
In this latter case, it is not clear that the word "versioning" is appropriate. Nevertheless, in this document, we will, as in the phrase "NFSv4 minor versioning," use the existing terminology without necessarily subscribing to the view that "versioning" is the appropriate description.
Some factors that are often relevant in deciding on the means by which a protocol will be extended:
Because NFS is layered on RPC and is described using an XDR description, the presentation of extension mechanisms below reflects those facts. Although XDR is mentioned in Sections 3.2 and 3.3 the reader should not assume that particular aspects of XDR itself are critical to the discussion. Similar extension approaches and analogous considerations would apply to other similar methods of protocol description.
Often, protocols will be designed with specific mechanisms, designed to allow protocol extension. An example is the provision for TCP options (see [RFC0793] and [RFC2780].) Most often, such mechanisms are designed to allow individual extensions to be designed and implemented independently, with any dependency relations between extensions specified separately and not enforced by the extension mechanism itself.
RPC-based protocols may, and often do, provide for protocol extension by replacing the XDR for one version with that for another. In this case the new protocol version could be represented by a new RPC protocol number but the more common pattern is to use the RPC versioning mechanism to manage selection of the proper protocol variant. The use of the RPC versioning mechanism enforces a versioning paradigm of this sort on protocols using this extension mechanism.
This extension mechanism allows very extensive protocol changes, up to and including the replacement of one protocol by an entirely different one. For some kinds of protocol extensions, this seems the only way to effect the change.
This approach was used to effect a transition between NFSv2 and NFSv3 (See Section 4.2) and between NFSv3 and NFSv4.0 (See Section 5.1).
It is possible to replace an XDR definition by one which is an extension in the sense that,
Within an XDR/RPC framework, extensions can be arrived at by:
Such an extension relation between XDR descriptions is reflexive, antisymmetric, and transitive and thus defines a partial order. In practice, provisions have to be made to make sure that two extensions of the same description are compatible (i.e. either one is an extension of the other, or there is a another description that is a valid extension of both).
To put things in concrete terms, such compatibility can be assured if measures are taken to ensure:
In contrast to XDR replacement discussed in Section 3.2, use of XDR extension remains atypical and is not supported by the XDR/RPC infrastructure. It is important to keep this fact in mind, as we discuss the use of XDR extension by NFSv4 in Section 5.2 and beyond.
It is possible to use multiple such means of protocol extension simultaneously. When this is done, the result is a composite extension mechanism. For example, if the XDR replacement or XDR extension mechanism is adopted, a protocol-specific mechanism can be added to it, if the protocol-specific mechanism is built on objects whose XDR definition is sufficiently generic. (e.g. opaque arrays or feature bitmasks).
It can be argued that the NFSv4 attribute model provides such an embedded protocol-specific extension mechanism, since sets of attribute values are specified as XDR opaque arrays and attribute sets are specified as variable-length arrays of 32-bit integers allowing new attribute bits to be defined outside of the XDR definition framework.
Note that there exists specification text that suggests that attributes are part of the XDR specification, making it hard to reach a firm conclusion on the matter. However, the resolution of this question does not affect the other matters discussed below, since, in either case, we have an extension mechanism that allows optional extensions.
While it is possible to choose multiple extension mechanisms for different sorts of extensions, based on their characteristics, protocols typically do not take advantage of that flexibility.
On the other hand, protocols do, as NFS has done, change their preferred extension mechanisms in response to long-term changes in requirements. However, once having done so, they rarely switch back. Changing extension mechanisms is a big step, both conceptually and in implementation terms, and is not commonly repeated.
In the case of NFS, the possibility of returning to an XDR replacement model (as a major version change) has always been available, but there has never been any significant interest in taking this step. It remains unlikely, although not impossible, that this could happen in the future.
NFSv2 and NFSv3 were described by the informational RFC's [RFC1094] and [RFC1813]. These documents each described existing interoperating client and server implementations. Thus they started with running code. If there was a rough consensus in effect, it was that these were useful protocols to use and thus that someone building a client or server had to interoperate with the existing implementations.
The following characteristics of protocol development during that period are noteworthy.
As a result of these commonalities, specifications tended to avoid a lot of detail that would have been required in a more diverse environment. New protocol features were thought of in terms of generally understood client and server implementation frameworks and it was generally clear which of those could be implemented without markedly changing that framework.
During this period, there was little perceived need for optional protocol features within NFS, in part because of the commonalities noted above. In some cases in which additional functionality was desired, the facility was added via an optional sideband protocol (e.g. NLM).
There were a number of significant changes involved, but only the first two were of major importance.
Of these only the first actually needed something as drastic as the XDR replacement model. The others could have been handled simply by adding new RPC requests and an enum value to an existing NFSv2 XDR. Since NFS's extension mechanism was then XDR replacement, such choices were not available.
Control of the development of NFS was transferred to the IETF in connection with the development of NFSv4. In what follows, we will be distinguishing between "NFSv4" as a family of protocols and "NFSv4.0", the first minor version of NFSv4, also sometimes referred to as "NFSv4".
NFSv4.0 was the first NFS version published as a Standards track document. Although an initial [RFC3010], entitled "NFS version 4 protocol" was published as a Proposed Standard, it was never implemented due to issues with the design of locking.
Subsequently, [RFC3530], entitled "Network File System (NFS) version 4 Protocol" was published as a Proposed Standard, obsoleting [RFC3010]. Later, the bis document [RFC7530] along with the XDR definition [RFC7531] were published as Proposed Standards.
The set of changes made to create NFSv4.0 was larger by far than that for NFSv3. A partial list follows.
These features/extensions were implemented via the XDR replacement model. This was the only realistic alternative, not only because of the size of the list, but also because some of the changes undercut some of the central design elements of the pre-IETF NFS protocol.
Note that minor versioning, an important element of NFSv4, is not discussed above. This is partly because minor versioning was not part of NFSv4.0, even though it was discussed in [RFC3530]. Minor versioning only became an NFSv4 feature during the development of NFSv4.1, as discussed in Section 6.1. We will discuss initial plans for minor versioning in Sections 5.3 and 5.4.
Two of the elements within NFSv4.0 have had an important role in allowing NFSv4 to be modified using an XDR extension approach, which was initially used to implement minor versioning.
A number of other elements of the protocol were subject to extension:
Issues regarding additional callback operations are similar to those for request operations. CB_COMPOUND takes the place of COMPOUND and the client and server switch roles. The server is the requester and the client is the responder
In this document, we refer to the individual extensions listed above as "feature elements". For some previous documents defining minor versioning rules (e.g. [RFC5661] and [NFSv42]), it is unclear whether the rules are referring to individual feature elements or a set of such elements. Our use of the term "feature elements" is desirable for clarity because of the uncertainty just mentioned and because ([NFSv4-vers]) uses the word "feature" in a different sense (i.e. to denote a set of feature elements which are documented together).
The minor versioning approach for NFSv4 uses an XDR extension model. It was presented within a versioning paradigm but the fact that all the added features were to be (at least initially) optional indicated that features were intended to be built independently, and that clients were expected to deal with their presence or absence. Note that the term "features" is not explicitly defined. We assume that the definition includes operations within COMPOUND or CB_COMPOUND, attributes, added flag bits and enum values, and new cases of XDR switch definitions. As noted above, we refer to such items as "feature elements", even though the rules we are discussing may be using the term "features", and there has been a lack of clarity as to what precisely is meant (See Section 6.1.)
Now let's look at some specifics of the minor version rules established for NFSv4 in [RFC3530]. Note that some of these were significantly modified by [RFC5661] and [NFSv42], as discussed in Section 6.4.
This model was subsequently modified in [RFC5661] and in [NFSv42]. See Sections 6.1 and 6.2 for details.
Many of the events anticipated in the model presented above have never been realized and it is likely that they never will be realized. See Section 6.3 for some details. Examples are:
If we try to understand why the minor versioning model was adopted we can first look at [RFC3530], which has a number of relevant statements.
Protocol extensibility (as opposed to versioning) is mentioned early in the RFC. In a short bulleted list of protocol goals, "Designed for protocol extensions" appears together with the following text:
Later, the following text appears at the start of the section "Minor Versioning".
The document does not explain why the goal of extensibility was constrained by the subsequent establishment of a strict versioning model. It is probably the case that the implications of this constraint were not really examined, and that the shift from major to minor versioning seemed to the working group like a sufficiently radical change to address foreseeable change management issues. It may also be the case that the fact that NFSv4 was moving outside the existing framework for RRC/XDR versioning made additional conceptual change difficult to consider.
Together with the rules that follow, which define an XDR extension model, we can draw the following conclusions.
If we look at how the various feature statuses are used, we have a basis to understand how the model was intended to work
Given the above it is hard to escape the conclusion that the ability to fix protocol bugs, in addition to the adding of entirely new features was intended, at least implicitly, to be part of the NFSv4 minor versioning model. Given that the lines between fixing bugs, correcting feature deficiencies, enhancing features, and providing new features are hard to draw in a precise way, there would have been no way to proceed on any other basis.
Despite the above, as things developed, issues explicitly involving protocol bug correction were not discussed during the period in which minor versions were being constructed. The issue of using NFSv4's extension model to correct protocol bugs was next addressed by [NFSv4-vers] as discussed in Section 9.
NFSv4.1 was described in [RFC5661] and [RFC5662], each of which was published as a Proposed Standard.
NFSv4.1 made a major change to NFSv4.0. It was able to do so primarily using an XDR extension model although it did not follow the rules laid out in Section 5.3. Instead, [RFC5661] presented its own set of minor versioning rules.
The following major changes in the rules were made.
NFSv4.1 also made a change that affected the interpretation of the minor versioning rules, apart from any text changes to those rules. In [RFC3530], the term "feature" is not defined, leading one to conclude that it denotes what we have called "feature elements." By publishing a table showing the status of various operations and callbacks and their relationship to various specific features, [RFC5661] opened the way to a different interpretation. However, this shift was incomplete, leaving room for continued ambiguity since:
NFSv4.1 also bypassed the versioning rules by making non-XDR-based protocol changes. See Section 7.1 for a discussion of the logic behind such changes.
A large set of changes was associated with the following two structural modifications in the protocol. Each of these involved multiple XDR-based feature elements and some non-XDR-based semantic change.
The session model involved the following set of protocol changes:
As a result of these changes, no COMPOUND request that contains any operation which is valid in NFSv4.0 is also valid in NFSv4.1. Either it contains an operation which has become mandatory to not implement, or it contains an operation which requires a preceding SEQUENCE operation, which did not exist in NFSv4.0. The only COMPOUND valid in both protocols is one which consists a zero-length operation array.
As mentioned previously, the sequence of operations by which clients and servers connected to one another was expanded and reorganized. This had a major role in enabling a number of functional enhancements to the protocol.
The above set of changes involved multiple operations.
The following additional feature elements were added as required at initial introduction:
Given the above list, one is forced to the conclusion that these feature elements were not included as required at initial introduction because there was anything particularly "infrastructural" about them. Rather, there were various feature elements within NFSv4.1 that it was convenient to make required at initial introduction. As a result, their presumed infrastructural character arises from their inclusion as required protocol elements. See Section 9.4 for a discussion of how such feature elements might relate to the proposed reformulation of NFSv4 version management.
The addition of such feature elements did not give rise to any difficulties despite the fact that the rules makes their inclusion problematic. Rather, as discussed below, the problems that NFSv4.1 created for the NFSv4 versioning model arose from the features that were most clearly of an infrastructural character.
In addition to these required feature elements, there were a number of non-XDR-based changes made in NFSv4.1. Although not thought of as "features" at the time, they are described in [RFC5661], which gives no indication that support is optional. These include:
There also a number of non-required feature elements. While such feature elements are optional in the sense that a server may or may not support them, it is not clear that all are optional in terms of the existing minor versioning rules. Given that all attributes are specified as REQUIRED OR RECOMMENDED, it may be that attributes that may or may not be supported are considered recommended from the viewpoint of the minor versioning rules. Here and in the future we will use "non-required" instead of "optional or recommended".
The following non-required feature elements were added.
Note that there has been little implementation work so far on the last three of these items.
Parallel NFS created an alternate protocol extension mechanism for NFS. New pNFS mapping types could be added, without any change to the existing XDR or change in the minor version number. Existing mapping types might have their own extension mechanisms. There also exists the possibility that features might be added within the NFSv4 protocol proper, designed to, or capable of, interacting with particular mapping types. This document will not these issues but they will have to be addressed by the NFSv4 Versioning RFC.
The set of changes introduced by NFSv4.1 was very large, and essentially made NFSv4.1 a different protocol from NFSV4.0, albeit one accomplished using the XDR extension model, and following the modified minor versioning rules in [RFC5661]
As a result of this bifurcation, the incremental enhancement provided by minor versioning became unavailable to NFSv4.0, while it still was available to NFSv4.1. While there was some discussion in the working group regarding the use of "micro-versioning" to address this gap, it was not followed up on and work to reform NFSv4 version management followed a different path.
While there was a general sense within the working group that versions as large as NFSv4.1 should be avoided in the future, there was no effort to modify the versioning rules to make this less likely.
While NFSv4.2 has not been defined in an RFC, the associated specifications have been approved by the IESG and are being prepared for publication. It is thus highly unlikely to experience additions to or deletions from its feature set before publication as a Proposed Standard. [NFSv42] and [NFSv42-dotx] can serve as useful references for this analysis.
Because of the lengthy process involved in producing NFSv4.1, the working group decided that NFSv4.2 was to be a relatively small minor version consisting only of optional features which would be documented by specifying changes from NFSv4.1.
The following features (all optional) are provided for in NFSv4.2:
Note that there are two pieces of infrastructure that are used by multiple features above. These are not "infrastructural" in the sense mentioned in Section 6.1 (i.e. they are not required), but they do serve an infrastructural role in that are required to be present if one of the optional features that use them are supported.
As noted above, there have been changes made by [RFC5661] and [NFSv42] in the NFSV4 minor versioning model.
Taking note of these changes, we can classify potential minor versions, starting with those that currently exist, based on how they affect inter-version compatibility.
To summarize protocol extension as it has been applied to the NFSv4 protocols:
It is important to note that NFSv4.0 (in [RFC3530] and [RFC7530]), both about 300 pages and NFSV4.1 (in [RFC5661]), about 600 pages documented the entire minor version. On the other hand, the NFSv4.2 specification document (in [NFSv42]) simply specified the changes from the previous minor version, in about 100 pages.
Given the difficulties of writing very large specifications, it has to be considered extremely unlikely that any future minor versions will be documented other than as a set of changes from the previous minor version.
Although not recognized at the time, the existence of non-XDR-based protocol changes is part of the existing NFSv4 versioning approach and must be addressed in any revision of NFSv4 version management.
Such changes have been of two types:
All such changes have been implemented as required with implementations using the minor version field of the COMPOUND to determine whether the change applies to a particular request.
Minor versions which may affect inter-version compatibility form an ascending sequence in which we also have a versioning paradigm, implemented principally using XDR extension.
Optional-feature-only minor versions are fundamentally different. Each NFSv4.2 server implements the same protocol as NFSv4.1 with a particular set of optional or recommended feature elements beyond those that are required. This set may range from the null set all the way to all of the non-required feature elements. Here, it appears that the versioning paradigm is not appropriate to the reality of the extension mechanism.
As a way of illustrating the basic point , let us consider two servers each of which only supports operations within NFSv4.1:
Although this obeys the rules as they stand, there is no obvious value for the client, the server, or the protocol in making these artificial distinctions. Optional-feature-only minor versions such as NFSv4.2 are not minor versions in the same sense that NFSv4.0 and NFSv4.1 are. In this case the minorversion field is not providing much useful information, while the set of operations supported is the important thing that the server implementer chooses and that the client needs to know.
The role of the minorversion field needs to be better understood. This is particularly so in light of the fact that it appears to be that the original intention was that all or most minor versions would be optional-feature-only minor versions, where, as we have seen, it has no useful role.
While this field is useful in distinguishing NFsv4.0 from NFSv4.1, such transitions were never anticipated when the NFSv4 minor versioning model was first created. A plausible hypothesis is that the switch from "extension" to "versioning" led to a perceived requirement for a version number without much thought about whether it was needed and for what purpose.
Nevertheless this field has proved useful despite the weaknesses noted above. It appears that we have the following ironic situation:
The following pattern was followed for NFSv4.2, and, unless a new version management approach is adopted, seems likely to persist.
This pattern of development is not a good fit for the kind of minor version that NFSv4.2 is and many future such minor versions will be. Such versions consist of a set of mostly unrelated features, each individually selectable or not by implementers, artificially yoked together. In essence, we have a "feature batch" rather than a minor version.
A number of issues have been noted with the existing process for NFSv4.2, leading to the conclusion that the process needs to be revised in some way, for future minor versions, of the same sort.
Some instances of problems/issues ascribable to a lack of searching document review at an early stage are described below. Rather than requiring the necessary review prior to feature acceptance, a common pattern has been that important issues are only discovered on those occasions in which it appears that work on the minor version is coming to a close and that there are issues that have to be addressed before they create difficulties for prospective implementers.
If we look at the problems above, we can understand better how such problems can arise. In short, the decision as to what features to include within a minor version was not a good use of the rough consensus model. In proceeding on that basis, the group created a set of perverse incentives that undercut the process. Also, as the process goes on for a long time, as is likely, these perverse incentives are intensified. Consider the following points:
The following issues led the working group to consider formulation of a new approach to NFSv4 versioning:
The working group is now working on a standards-track document ([NFSv4-vers]) defining an approach to version management that is intended to apply to NFSv4 as a whole. The major advances that formed the basis for that new document include
During this period, changes were made to some related documents, as they moved toward publication.
Some of these changes were made to simplify handling of the transition in versioning models that would occur upon publication of [NFSv4-vers] as an RFC.
As a result of these changes, upon publication of an NFSv4 version management RFC, it will only need to be marked as updating [RFC5661].
Another relevant change concerned the use of the term "RECOMMENDED" regarding attributes which are not REQUIRED. As it appeared that this usage is inconsistent with [RFC2119], the draft of [RFC7530] was modified and [RFC7530] was published including the following statement:
A reasonable conclusion to draw from this is that while certain attributes are indeed REQUIRED, the other ones cannot be designated as "RECOMMENDED" as that term is defined in [RFC2119].
Work still needs to be done to deal with the analogous issue in [RFC5661].
This change relates to the NFSv4 feature status model. Although there has been discussion of feature elements moving within a status hierarchy including OPTIONAL, RECOMMENDED, and REQUIRED statuses, with the exception of attributes, "RECOMMENDED" has never been used. Given that all feature elements are, in RFC2219 terms, either OPTIONAL or REQUIRED opens the way to a simpler feature status model.
Previously the versioning document incorporated two conceptual models which needed to be better integrated to give us a more coherent treatment of version management within NFSv4.
Recent work has restructured the treatment of NFSv4 version management into a layered structure.
One way of dealing with the issues surrounding the minor versioning rules is to re-organize them so as to move away from a single set of minor versioning rules, while adapting them to the evolving version management model in [NFSv4-vers].
Although the result may not have the format of a numbered list of rules, there will be sets of guidelines that serve the needed functions. One possible organization is the following:
While there has been general acceptance of the idea that version management needs to become more flexible and incremental, the details need to be more fully discussed.
One particular area of discussion is to get more clarity on the role of minor versions within the new version management approach. It appears that there is a range of opinions about how often minor versions will be needed. Some people are of the opinion that all required protocol change can be done using the extension model, making an provisions for additional minor versions redundant. Others feel that there may well be situations in which changes which cannot be performed using the existing model will be required.
Fortunately, it is not necessary to get agreement on this issue to proceed with this document. As long as people are in agreement as to the situations that would require a new minor version, the fact that they have different expectations as to whether and when those will occur is not relevant at this point. Those are matters best left for discussion when the relevant situations might arise.
Currently [NFSv4-vers] defines the following events as requiring a minor version to effect. These need to be discussed to make sure the group has a general understanding of our versioning options going forward.
It might also be useful for the working group to have a discussion of situations in which it might choose to create a new minor version, even if not obliged to do so.
Another issue that the working group might profitably discuss is the question of versions that make larger sets of protocol changes, on the order of NFSv4.0 or NFSv4.1. While most people feel that such changes are quite unlikely in the foreseeable future, there is likely to be a range of opinions about how a version management RFC should deal with the matter.
We can summarize the history of protocol extension within the NFS family as protocols as follows:
A question that has been asked is why NFSv4 has had such difficulty arriving at a workable approach to protocol extension, compared to other protocols, that have embraced incremental extension without difficulty. This is a question for which a definitive answer is not possible. Nevertheless, it is a reasonable question, and the author has attempted to answer it.
In part, the problem stems from an early confusion of extensibility and versioning, as we have seen in Section 5.4. While this sheds light on the origin of the problem, in a way it compounds our difficulties. Given that this same confusion first appeared in [RFC3010], it appears that it has taken around fifteen years to provide a version management framework appropriate to the initial goals for NFSv4.
In part, this extended hiatus derives from the history cited above.
Despite the plausibility of the above, the author feels that it doesn't fully explain the length of the gap and thinks that looking for a more systemic explanation is worthwhile. The following suggestions are worth considering as an explanation for NFSv4's difficulties compared to other protocols:
In part, these are problems which derive from the identification of a protocol with the contents of an XDR file. This has had two unfortunate consequences.
The fact that some of the necessary extensions did affect the code generated by XDR led to further difficulties. While it might seem straightforward to design a mechanism to allow extensions, and NFSv4 in [RFC3530] defined such a mechanism, the information hiding that is part of the XDR interface could have caused the details of the compatibility issues to be obscured. Instead, the natural tendency was only to see that the XDR's were different, and thus presumably incompatible. As a result, the virtues of the NFSv4 extensibility infrastructure were difficult to see, and so we were unable to take full advantage of them.
Once this document gets through working group last call, there are a number of events that must occur before implementation of a new version management approach can begin.
Another possible extension involves the mode_umask attribute described in [mode-umask], which is currently an individual draft. This attribute allows ACL inheritance to avoid problems that have arisen in adapting to the POSIX-based umask concept. This extension's purpose is to address an oversight in the design of NFSv4's access control attributes, present in all existing minor versions, including NFSv4.0. Because of that fact, it is likely to be turned into a working group item and it might be considered as a protocol correction, possibly updating [RFC7530], after [NFSv4-vers] is published as a Proposed Standard.
Once [xattr] and [NFSv4-vers] are published, the extended attributes feature would become a valid optional extension to NFSv4.2 and clients and server would be able to support it. If [mode-umask] and [NFSv4-vers] are published the same thing would happen with the mode_umask attribute.
Given that a dramatic change will be involved, it seems that a discussion of risk mitigation is in order. The most important component of addressing the risks associated with a new process is active concern about problems that arise. This needs to be combined with a willingness to make appropriate adjustments if problems arise. Clearly, we need to avoid a situation in which an extension model is not working and the problems go on for years without being addressed.
The principal means by which the risk of change may be mitigated would involve care in approving extensions. Both the working group and the IESG should exercise the requisite care, to make sure that the extensions are clearly documented, have an appropriate scope, and address real problems, Further, having a clear requirement for interoperable prototype implementations should have the effect of limiting excessive feature creation activity.
Since no substantive protocol changes are proposed here, no security considerations apply.
As features and minor versions designed and specified in standards-track documents, their security issues will be addressed and each RFC candidate will receive the appropriate security review from the NFSv4 working group and IESG.
The current document does not require any actions by IANA.
Depending on decisions that the working group makes about how to address the issues raised in this document, future documents may require actions by IANA.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
The author wishes to thank Chuck Lever of Oracle for his comprehensive document review and his many important suggestions, which helped to significantly improve this document.