draft-ietf-nfsv4-versioning-07.txt   draft-ietf-nfsv4-versioning-08.txt 
NFSv4 D. Noveck NFSv4 D. Noveck
Internet-Draft HPE Internet-Draft HPE
Updates: 5661, xxxx (if approved) October 22, 2016 Updates: 5661, 7862 (if approved) December 3, 2016
Intended status: Standards Track Intended status: Standards Track
Expires: April 25, 2017 Expires: June 6, 2017
Rules for NFSv4 Extensions and Minor Versions. Rules for NFSv4 Extensions and Minor Versions
draft-ietf-nfsv4-versioning-07 draft-ietf-nfsv4-versioning-08
Abstract Abstract
This document describes the rules relating to the extension of the This document describes the rules relating to the extension of the
NFSv4 family of protocols. It covers the creation of minor versions, NFSv4 family of protocols. It covers the creation of minor versions,
the addition of optional features to existing minor versions, and the the addition of optional features to existing minor versions, and the
correction of flaws in features already published as Proposed correction of flaws in features already published as Proposed
Standards. The rules relating to the construction of minor versions Standards. The rules relating to the construction of minor versions
and the interaction of minor version implementations that appear in and the interaction of minor version implementations that appear in
this document supersede the minor versioning rules in RFC5661 and this document supersede the minor versioning rules in RFC5661 and
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2017. This Internet-Draft will expire on June 6, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Use of Keywords Defined in RFC2119 . . . . . . . . . . . 3 2.1. Use of Keywords Defined in RFC2119 . . . . . . . . . . . 4
2.2. Use of Feature Statuses . . . . . . . . . . . . . . . . . 4 2.2. Use of Feature Statuses . . . . . . . . . . . . . . . . . 4
2.3. NFSv4 Versions . . . . . . . . . . . . . . . . . . . . . 5 2.3. NFSv4 Versions . . . . . . . . . . . . . . . . . . . . . 5
3. Consolidation of Extension Rules . . . . . . . . . . . . . . 6 3. Consolidation of Extension Rules . . . . . . . . . . . . . . 6
4. XDR Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. XDR Considerations . . . . . . . . . . . . . . . . . . . . . 7
4.1. XDR Extension . . . . . . . . . . . . . . . . . . . . . . 7 4.1. XDR Extension . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Rules for XDR Extension within NFSv4 . . . . . . . . . . 8 4.2. Rules for XDR Extension within NFSv4 . . . . . . . . . . 8
4.3. Handling of Protocol Elements . . . . . . . . . . . . . . 9 4.3. Handling of Protocol Elements by Responders . . . . . . . 9
4.4. Inter-version Interoperability . . . . . . . . . . . . . 10 4.4. Inter-version Interoperability . . . . . . . . . . . . . 11
4.4.1. Requirements for Knowledge of Protocol Elements . . . 10 4.4.1. Requirements for Knowledge of Protocol Elements . . . 11
4.4.2. Establishing Interoperability . . . . . . . . . . . . 12 4.4.2. Establishing Interoperability . . . . . . . . . . . . 12
4.4.3. Determining Knowledge of Protocol Elements . . . . . 13 4.4.3. Determining Knowledge of Protocol Elements . . . . . 14
4.5. XDR Overlay . . . . . . . . . . . . . . . . . . . . . . . 14 4.5. XDR Overlay . . . . . . . . . . . . . . . . . . . . . . . 15
5. Other NFSv4 Protocol Changes . . . . . . . . . . . . . . . . 15 5. Other NFSv4 Protocol Changes . . . . . . . . . . . . . . . . 15
5.1. Field Interpretation and Use . . . . . . . . . . . . . . 15 5.1. Field Interpretation and Use . . . . . . . . . . . . . . 15
5.2. Behavioral Changes . . . . . . . . . . . . . . . . . . . 16 5.2. Behavioral Changes . . . . . . . . . . . . . . . . . . . 16
6. Extending Existing Minor Versions . . . . . . . . . . . . . . 16 6. Extending Existing Minor Versions . . . . . . . . . . . . . . 17
7. Minor Versions . . . . . . . . . . . . . . . . . . . . . . . 16 7. Minor Versions . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Creation of New Minor Versions . . . . . . . . . . . . . 16 7.1. Creation of New Minor Versions . . . . . . . . . . . . . 17
8. Minor Version Interaction Rules . . . . . . . . . . . . . . . 17 8. Minor Version Interaction Rules . . . . . . . . . . . . . . . 18
8.1. Minor Version Identifier Transfer Issues . . . . . . . . 17 8.1. Minor Version Identifier Transfer Issues . . . . . . . . 18
8.2. Minor Version Compatibility . . . . . . . . . . . . . . . 18 8.2. Minor Version Compatibility . . . . . . . . . . . . . . . 18
9. Correction of Existing Minor Versions and Features . . . . . 19 9. Correction of Existing Minor Versions and Features . . . . . 19
9.1. XDR Changes to Implement Protocol Corrections . . . . . . 19 9.1. XDR Changes to Implement Protocol Corrections . . . . . . 20
9.2. XDR Corrections to required features . . . . . . . . . . 21 9.2. XDR Corrections to OPTIONAL features . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9.3. XDR Corrections to REQUIRED features . . . . . . . . . . 22
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9.4. Addressing XDR Corrections in Later Minor Versions . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 22 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . 24
Appendix B. Instructions for RFC Editor . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
To address the requirement for an NFS protocol that can evolve as the To address the requirement for an NFS protocol that can evolve as the
need arises, the Network File System (NFS) version 4 (NFSv4) protocol need arises, the Network File System (NFS) version 4 (NFSv4) protocol
provides a framework to allow for future changes via the creation of provides a framework to allow for future changes via the creation of
new protocol versions including minor versions and certain forms of new protocol versions including minor versions and certain forms of
modification of existing minor versions. The extension rules modification of existing minor versions. The extension rules
contained in this document allow extensions and other changes to be contained in this document allow extensions and other changes to be
implemented in a way that maintains compatibility with existing implemented in a way that maintains compatibility with existing
skipping to change at page 3, line 20 skipping to change at page 3, line 26
Previously, all protocol changes had been part of new minor versions. Previously, all protocol changes had been part of new minor versions.
The COMPOUND procedure (see Section 14.2 of [RFC7530]) specifies the The COMPOUND procedure (see Section 14.2 of [RFC7530]) specifies the
minor version being used by the client in making requests. The minor version being used by the client in making requests. The
CB_COMPOUND procedure (see Section 15.2 of [RFC7530]) specifies the CB_COMPOUND procedure (see Section 15.2 of [RFC7530]) specifies the
minor version being used by the server on callback requests. minor version being used by the server on callback requests.
Creation of a new minor version is no longer the only way in which Creation of a new minor version is no longer the only way in which
protocol changes may be made. Optional features may be added as protocol changes may be made. Optional features may be added as
extensions and protocol corrections can be proposed, specified and extensions and protocol corrections can be proposed, specified and
implemented within the context of a single minor version. Creation implemented within the context of a single minor version. Creation
of new minor versions remains available to make other sorts of of new minor versions remains available when needed.
changes.
The goal of allowing extensions within the context of a minor version The goal of allowing extensions within the context of a minor version
is provide more implementation flexibility while preserving is to provide more implementation flexibility while preserving
interoperability on protocol upgrade. As described in Section 4.4, interoperability on protocol upgrade. As described in Section 4.4,
two implementations can each choose to implement a subset of two implementations can each choose to implement a subset of
available extensions, enabling interoperation to proceed just as if available extensions, enabling interoperation to proceed just as if
both implementations supported only the parts of the protocol they both implementations supported only the parts of the protocol they
both support. both support.
2. Terminology 2. Terminology
A basic familiarity with NFSv4 terminology is assumed in this A basic familiarity with NFSv4 terminology is assumed in this
document and the reader is pointed to [RFC7530]. document and the reader is pointed to [RFC7530].
skipping to change at page 5, line 43 skipping to change at page 5, line 48
is part of the minor version in question. is part of the minor version in question.
Because of the above, there can be multiple version variants that are Because of the above, there can be multiple version variants that are
part of a given minor version. Two of these are worthy of special part of a given minor version. Two of these are worthy of special
terms: terms:
o The term "base minor version" denotes the version variant that o The term "base minor version" denotes the version variant that
corresponds to the minor version as originally defined, including corresponds to the minor version as originally defined, including
all protocol elements specified in the minor version definition all protocol elements specified in the minor version definition
document but not incorporating any extensions or protocol document but not incorporating any extensions or protocol
corrections published subsequently. corrections published after that original definition.
o At any given time, the term "current minor version" denotes the o At any given time, the term "current minor version" denotes the
minor version variant including all extensions of and corrections minor version variant including all extensions of and corrections
to the minor version made by standard-track documents published to the minor version made by standard-track documents published
subsequently. subsequently.
Each version variant which is part of a given minor version is a
subset of the current minor version and a superset of the base minor
version. When the term "minor version" is used without either of
these qualifiers, it should refer to something which is true of all
variants within that minor version. For example, in the case of a
minor version that has not had a protocol correction, one may refer
to the set of REQUIRED features for that minor version since it is
the set is the same for all variants within the minor version. See
Section 9 for a discussion of correcting an existing minor version.
Each client and server which implements a specific minor version will Each client and server which implements a specific minor version will
implement some particular variant of that minor version. Each of implement some particular variant of that minor version. Each
these will be a superset of the appropriate base minor version. variant is a subset of the current minor version and a superset of
the base minor version. When the term "minor version" is used
without either of these qualifiers, it should refer to something
which is true of all variants within that minor version. For
example, in the case of a minor version that has not had a protocol
correction, one may refer to the set of REQUIRED features for that
minor version since it is the same for all variants within the minor
version. See Section 9 for a discussion of correcting an existing
minor version.
3. Consolidation of Extension Rules 3. Consolidation of Extension Rules
In the past, the only existing extension rules were the minor In the past, the only existing extension rules were the minor
versioning rules that were being maintained and specified in the versioning rules that were being maintained and specified in the
Standards Track RFCs which defined the individual minor versions. In Standards Track RFCs which defined the individual minor versions. In
the past, these minor versioning rules were modified on an ad hoc the past, these minor versioning rules were modified on an ad hoc
basis for each new minor version. basis for each new minor version.
More recently, minor versioning rules were specified in [RFC5661] More recently, minor versioning rules were specified in [RFC5661]
skipping to change at page 6, line 50 skipping to change at page 7, line 7
o Minor version construction, including rules applicable to changes o Minor version construction, including rules applicable to changes
which cannot be made in extensions to existing minor versions are which cannot be made in extensions to existing minor versions are
addressed in Section 7.1 addressed in Section 7.1
o Minor version interaction rules are discussed in Sections 8.1 and o Minor version interaction rules are discussed in Sections 8.1 and
8.2. 8.2.
This document supersedes minor versioning rules appearing in the This document supersedes minor versioning rules appearing in the
minor version specification RFC's, including those in [RFC5661] and minor version specification RFC's, including those in [RFC5661] and
also the modification to those rules mentioned in [RFCv42]. As a also the modification to those rules mentioned in [RFC7862]. As a
result, potential conflicts among documents should be addressed as result, potential conflicts among documents should be addressed as
follows: follows:
o The specification of the actual protocols for minor versions o The specification of the actual protocols for minor versions
previously published as Proposed Standards take precedence over previously published as Proposed Standards take precedence over
minor versioning rules in either this document or in the minor minor versioning rules in either this document or in the minor
version specification RFC's. In other words, if the transition version specification RFC's. In other words, if the transition
from version A to version B violates a minor versioning rule, the from version A to version B violates a minor versioning rule, the
version B protocol stays as it is. version B protocol stays as it is.
o Since minor versioning rules #11 and #13 from [RFC5661] deal with o Since minor versioning rules #11 and #13 from [RFC5661] deal with
the interactions between multiple minor versions, the situation is the interactions between multiple minor versions, the situation is
more complicated. See Section 8 for a discussion of these issues, more complicated. See Section 8 for a discussion of these issues,
including how potential conflicts between rules are to be including how potential conflicts between rules are to be
resolved. resolved.
o Otherwise, any conflict between the extension rules in this o Otherwise, any conflict between the extension rules in this
document and those in minor version specification RFC's are to be document and those in minor version specification RFC's are to be
resolved based on the treatment in this document. In particular, resolved based on the treatment in this document. In particular,
corrections may be made as specified in Section 9 for all corrections may be made as specified in Section 9 for all
previously specified minor versions and the extensibility of previously specified minor versions, and the extensibility of
previously specified minor versions is to be handled in accord previously specified minor versions is to be handled in accord
with Section 6. with Section 6.
Future minor version specification documents should avoid specifying Future minor version specification documents should avoid specifying
rules relating to minor versioning and reference this document in rules relating to minor versioning and reference this document in
connection with rules for NFSv4 extension. connection with rules for NFSv4 extension.
4. XDR Considerations 4. XDR Considerations
As an extensible XDR-based protocol, NFSv4 has to ensure interversion As an extensible XDR-based protocol, NFSv4 has to ensure interversion
skipping to change at page 8, line 28 skipping to change at page 8, line 34
structure/interpretation using the extended definition. structure/interpretation using the extended definition.
o Each message within the set of messages described as valid by the o Each message within the set of messages described as valid by the
extended definition but not the base definition must be extended definition but not the base definition must be
recognized, using the base definition, as part of an extension not recognized, using the base definition, as part of an extension not
provided for. provided for.
The use of XDR extension can facilitate compatibility between The use of XDR extension can facilitate compatibility between
different versions of the NFSv4 protocol. When XDR extension is used different versions of the NFSv4 protocol. When XDR extension is used
to implement OPTIONAL features, the greatest degree of inter-version to implement OPTIONAL features, the greatest degree of inter-version
compatibility is obtained. In this case, no change in minor version compatibility is obtained. In this case, as long as the rules in
number is needed and the extension may be effected in the context of Section 6 are followed, no change in minor version number is needed
a single minor version. and the extension may be effected in the context of a single minor
version.
4.2. Rules for XDR Extension within NFSv4 4.2. Rules for XDR Extension within NFSv4
In the context of NFSv4, an extension of a given XDR description In the context of NFSv4, given the central role of COMPOUND and
consists of one or more of the following: CB_COMPOUND, addition of new RPC procedures is not allowed and the
enumeration of operations and callback operations have a special
role.
The following XDR extensions, by their nature, affect both messages
sent by requesters (i.e. requests, callbacks), and responders (i.e.
replies, callback replies).
o Addition of previously unspecified operation codes, within the o Addition of previously unspecified operation codes, within the
framework established by COMPOUND and CB_COMPOUND. framework established by COMPOUND and CB_COMPOUND. These extend
the appropriate enumeration and the corresponding switches devoted
to requests and responses for the associated direction of
operation.
o Addition of previously unspecified attributes. o Addition of previously unspecified attributes. These add
additional numeric constants that define each attribute's bit
position within the attribute bit map, together with XDR typedefs
that specify the attributes' format within the nominally opaque
arrays specifying sets of attributes.
Other sorts of changes will generally affect one of requests,
replies, callback, or callback replies. Although all are valid XDR
extensions, the messages that are affected may determine whether the
extension requires a new minor version (see Section 7) or can be made
as an extension within an existing minor version (see Section 6).
o Addition of new, previously unused, values to existing enums. o Addition of new, previously unused, values to existing enums.
o Addition of previously unassigned bit values to a flag word. o Addition of previously unassigned bit values to a flag word.
o Addition of new cases to existing switches, provided that the o Addition of new cases to existing switches, provided that the
existing switch did not contain a default case. existing switch did not contain a default case.
However, none of the following is allowed to happen: None of the following is allowed to happen:
o Any change to the structure of existing requests or replies other o Any change to the structure of existing requests or replies other
than those listed above. than those listed above.
o Addition of previously unspecified RPC operation codes, for either o Addition of previously unspecified RPC procedures, for either the
the nfsv4 program or the callback program. nfsv4 program or the callback program.
o Deletion of existing RPC operations, enum values, flag bit values o Deletion of existing RPC procedures, operation codes, enum values,
and switch cases. Note that changes may be made to define use of flag bit values and switch cases. Note that changes may be made
any of these as causing an error, as long as the XDR is to define use of any of these as causing an error, as long as the
unaffected. XDR is unaffected.
o Similarly, none of these items may be reused for a new purpose. o Similarly, none of these items may be reused for a new purpose.
4.3. Handling of Protocol Elements 4.3. Handling of Protocol Elements by Responders
Implementations handle protocol elements in one of three ways. Which Implementations handle protocol elements in received in requests and
of the following ways are valid depends on the status of the protocol callbacks in one of three ways. Which of the following ways are
element in the variant being implemented: valid depends on the status of the protocol element in the variant
being implemented:
o The protocol element is not a part of definition of the variant in o The protocol element is not a part of definition of the variant in
question and so is "unknown". The responder, when it does not question and so is "unknown". The responder, when it does not
report an RPC XDR decode error, reports an error indicative of the report an RPC XDR decode error, reports an error indicative of the
element not being defined in the XDR such as NFS4ERR_OP_ILLEGAL, element not being defined in the XDR such as NFS4ERR_OP_ILLEGAL,
NFS4ERR_BADXDR, or NFS4ERR_INVAL. See Section 4.4.3 for details. NFS4ERR_BADXDR, or NFS4ERR_INVAL. See Section 4.4.3 for details.
o The protocol element is a known part of the variant but is not o The protocol element is a known part of the variant but is not
supported by the particular implementation. The responder reports supported by the particular implementation. The responder reports
an error indicative of the element being recognized as one which an error indicative of the element being recognized as one which
skipping to change at page 9, line 44 skipping to change at page 10, line 21
or NFS4ERR_ATTRNOTSUPP. or NFS4ERR_ATTRNOTSUPP.
o The protocol element is a known part of the variant which is o The protocol element is a known part of the variant which is
supported by the particular implementation. The responder reports supported by the particular implementation. The responder reports
success or an error other than the special ones discussed above. success or an error other than the special ones discussed above.
Which of these are validly returned by the responder depends on the Which of these are validly returned by the responder depends on the
status of the protocol element in the minor version specified in the status of the protocol element in the minor version specified in the
COMPOUND or CB_COMPOUND. The possibilities which can exist when COMPOUND or CB_COMPOUND. The possibilities which can exist when
dealing with minor versions that have not been subject to corrections dealing with minor versions that have not been subject to corrections
are listed below. See Sections 9.1 and 9.2 for a discussion of the are listed below. See Sections 9.1 and 9.3 for a discussion of the
effects of protocol correction. effects of protocol correction.
o The protocol element is not known in the minor version. In this o The protocol element is not known in the minor version. In this
case all implementations of the minor version MUST indicate that case all implementations of the minor version MUST indicate that
the protocol element is not known. the protocol element is not known.
o The protocol element is part of a feature specified mandatory to o The protocol element is part of a feature specified mandatory to
not implement in the minor version. In this case as well, all not implement in the minor version. In this case as well, all
implementations of the minor version MUST indicate that the implementations of the minor version MUST indicate that the
protocol element is not known. protocol element is not known.
skipping to change at page 10, line 27 skipping to change at page 11, line 5
is supported or is not supported. is supported or is not supported.
o The protocol element is defined as a REQUIRED part of the base o The protocol element is defined as a REQUIRED part of the base
minor version. In this case, the requester can expect the minor version. In this case, the requester can expect the
protocol element to be both known and supported by the responder. protocol element to be both known and supported by the responder.
The listing of possibilities above does not mean that a requester The listing of possibilities above does not mean that a requester
always needs to be prepared for all such possibilities. Often, always needs to be prepared for all such possibilities. Often,
depending on the scope of the feature of which the protocol element depending on the scope of the feature of which the protocol element
is a part, handling of a previous request using the same or related is a part, handling of a previous request using the same or related
protocol elements, will allow the requester to be sure that certain protocol elements will allow the requester to be sure that certain of
of these possibilities cannot occur. these possibilities cannot occur.
Requesters, typically clients, may test for knowledge of or support Requesters, typically clients, may test for knowledge of or support
for protocol elements as part of connection establishment. This may for protocol elements as part of connection establishment. This may
allow the requester to be aware of responder lack of knowledge of or allow the requester to be aware of a responder's lack of knowledge of
support for problematic requests before they are actually used to or support for problematic requests before they are actually used to
effect user requests. effect user requests.
4.4. Inter-version Interoperability 4.4. Inter-version Interoperability
Because of NFSv4's use of XDR extension, any communicating client and Because of NFSv4's use of XDR extension, any communicating client and
server versions have XDR definitions that are each valid extensions server versions have XDR definitions such that each is a valid
of a third version. Once that version is determined, it may be used extension of a third version. Once that version is determined, it
by both client and server to communicate. Each party can may be used by both client and server to communicate. Each party can
successfully use a subset of protocol elements that are both known successfully use a subset of protocol elements that are both known to
and supported by both parties. and supported by both parties.
4.4.1. Requirements for Knowledge of Protocol Elements 4.4.1. Requirements for Knowledge of Protocol Elements
With regard to requirements for knowledge of protocol elements, the With regard to requirements for knowledge of protocol elements, the
following rules apply. These rules are the result of the use of the following rules apply. These rules are the result of the use of the
XDR extension paradigm combined with the way in which extensions are XDR extension paradigm combined with the way in which extensions are
incorporated in existing minor versions (for details of which see incorporated in existing minor versions (for details of which see
Section 6). Section 6).
o Any protocol element defined as part of the base variant of o Any protocol element defined as part of the base variant of
particular minor version is required to be known by that minor particular minor version is required to be known by that minor
version. This occurs whether the specification happens in the version. This occurs whether the specification happens in the
body of the minor definition document or is in a feature body of the minor definition document or is in a feature
definition document that is made part of the minor version by definition document that is made part of the minor version by
being normatively referenced by the minor version definition being normatively referenced by the minor version definition
document. document.
o Any protocol element required to be known in a given minor version o Any protocol element required to be known in a given minor version
is required to be known in subsequent minor version, unless and is required to be known in subsequent minor versions, unless and
until a minor version has made that protocol element as mandatory until a minor version has made that protocol element as mandatory
to not implement. to not implement.
o When a protocol element is defined as part of an extension to an o When a protocol element is defined as part of an extension to an
extensible minor version, it is not required to be known in that extensible minor version, it is not required to be known in that
minor version but is required to be known by the next minor minor version but is required to be known by the next minor
version. In the earlier minor version, it might not be defined in version. In the earlier minor version, it might not be defined in
the XDR definition document, while in the later version it needs the XDR definition document, while in the later version it needs
to be defined in the XDR definition document. In either case, if to be defined in the XDR definition document. In either case, if
it is defined, it might or might not be supported. it is defined, it might or might not be supported.
o When knowledge of protocol elements is optional in a given minor o When knowledge of protocol elements is optional in a given minor
version, the responder's knowledge of such optional elements must version, the responder's knowledge of such optional elements must
obey the rule that if one such element is known, then all the obey the rule that if one such element is known, then all the
protocol elements defined in the same minor version definition protocol elements defined in the same minor version definition
document must be known as well. document must be known as well.
For many minor versions, all existing protocol elements, are required For many minor versions, all existing protocol elements, are required
to be known by both the client and the server, and so requesters do to be known by both the client and the server, and so requesters do
not have to test for the presence or absence of knowledge regarding not have to test for the presence or absence of knowledge regarding
protocol elements for which knowledge might be optional. This is the protocol elements. This is the case if there has been no extension
case if there has been no extension for the minor version in for the minor version in question. Extensions can be added to
question. Extensions can be added to extensible minor versions as extensible minor versions as described in Section 6 and can be used
described in Section 6 and can be used to correct protocol flaws as to correct protocol flaws as described in Section 9.
described in Section 9.
Requesters can ascertain the knowledge of the responder in two ways: Requesters can ascertain the knowledge of the responder in two ways:
o By issuing a request using the protocol element and looking at the o By issuing a request using the protocol element and looking at the
response. Note that, even if the protocol element used is not response. Note that, even if the protocol element used is not
supported by the responder, the requester can still determine if supported by the responder, the requester can still determine if
the element is known by the responder. the element is known by the responder.
o By receiving a request from the responder, acting in the role of o By receiving a request from the responder, acting in the role of
requester. For example, a client may issue a request enabling the requester. For example, a client may issue a request enabling the
skipping to change at page 13, line 9 skipping to change at page 13, line 33
o The minor version consists of only a single variant (no extension o The minor version consists of only a single variant (no extension
or XDR corrections), so the client and the server are using the or XDR corrections), so the client and the server are using the
same XDR description and have knowledge of the same protocol same XDR description and have knowledge of the same protocol
elements. elements.
o When the minor version consists of multiple variants (i.e. there o When the minor version consists of multiple variants (i.e. there
are one or more XDR extensions or XDR corrections), the client and are one or more XDR extensions or XDR corrections), the client and
the server are using compatible XDR descriptions. The client is the server are using compatible XDR descriptions. The client is
aware of some set of extensions while the server may be aware of a aware of some set of extensions while the server may be aware of a
different set. The client can determine which of the extensions different set. The client can use the approach described in
that he is aware of, are also known to the server by using the Section 4.4.3 to determine which of the extensions it knows about
approach described in Section 4.4.3. Once this is done, the are also known by the server. Once this is done, the client and
client and server will both be using a common variant. The server will both be using a common variant. The variants that the
variants that the client and the server were built with will both client and the server were built with will both either be
either be identical to this variant or a valid extension of it. identical to this variant or a valid extension of it. Similarly,
Similarly, the variants that the client and the server actually the variants that the client and the server actually use will be a
use will be a subset of this variant, in that certain OPTIONAL subset of this variant, in that certain OPTIONAL features will not
features will not be used. be used.
In either case, the client must determine which of the OPTIONAL In either case, the client must determine which of the OPTIONAL
protocol elements within the common version are supported by the protocol elements within the common version are supported by the
server, just as it does for OPTIONAL features introduced as part of a server, just as it does for OPTIONAL features introduced as part of a
minor version. minor version.
It is best if client implementations make the determination as to the It is best if client implementations make the determination as to the
support provided by the server before acting on user requests. This support provided by the server before acting on user requests. This
includes the determination of the common protocol variant and the includes the determination of the common protocol variant and the
level of support for OPTIONAL protocol elements. level of support for OPTIONAL protocol elements.
skipping to change at page 14, line 40 skipping to change at page 15, line 16
protocol element is expected to remain valid as long as the clientid protocol element is expected to remain valid as long as the clientid
associated with the request remains valid. associated with the request remains valid.
The above assumes, as should be the case, that the server will accept The above assumes, as should be the case, that the server will accept
the minor version used by the client. For more detail regarding this the minor version used by the client. For more detail regarding this
issue, see Section 8.2. issue, see Section 8.2.
4.5. XDR Overlay 4.5. XDR Overlay
XDR additions may also be made by defining XDR structures that XDR additions may also be made by defining XDR structures that
overlay nominally opaque fields. defined to allow such incremental overlay nominally opaque fields that are defined to allow such
extensions. incremental extensions.
For example, each pNFS mapping type provides its own XDR definition For example, each pNFS mapping type provides its own XDR definition
for various pNFS-related fields defined in [RFC5661] as opaque for various pNFS-related fields defined in [RFC5661] as opaque
arrays. arrays.
Because such additions provide new interpretations of existing Because such additions provide new interpretations of existing
fields, they may be made outside of the extension framework as long fields, they may be made outside of the extension framework as long
as they obey the rules previously established when the nominally as they obey the rules previously established when the nominally
opaque protocol elements were added to the protocol. opaque protocol elements were added to the protocol.
5. Other NFSv4 Protocol Changes 5. Other NFSv4 Protocol Changes
There are a number of types of protocol changes that are outside the There are a number of types of protocol changes that are outside the
XDR extension framework discussed in Section 4. These changes are XDR extension framework discussed in Section 4. These changes are
also managed within the NFSv4 versioning framework and may be of a also managed within the NFSv4 versioning framework and may be of a
number of types, which are discussed in the sections below number of types, which are discussed in the sections below.
Despite the previous emphasis on XDR changes, additions and changes Despite the previous emphasis on XDR changes, additions and changes
to the NFSv4 protocols have not been limited to those that involve to the NFSv4 protocols have not been limited to those that involve
changes (in the form of extensions) to the protocol XDR. Examples of changes (in the form of extensions) to the protocol XDR. Examples of
other sorts of changes have been taken from NFSv4.1. other sorts of changes have been taken from NFSv4.1.
All such changes that have been made in the past have been made as All such changes that have been made in the past have been made as
part of new minor version. Future change of these sorts may not be part of new minor version. Future change of these sorts may not be
done in an extension but can only be made in a new minor version. done in an extension but can only be made in a new minor version.
skipping to change at page 16, line 40 skipping to change at page 17, line 17
6. Extending Existing Minor Versions 6. Extending Existing Minor Versions
Extensions to the most recently published NFSv4 minor version may be Extensions to the most recently published NFSv4 minor version may be
made by publishing the extension as a Proposed Standard, unless the made by publishing the extension as a Proposed Standard, unless the
minor version in question has been defined as non-extensible. A minor version in question has been defined as non-extensible. A
document need not update the document defining the minor version, document need not update the document defining the minor version,
which remains a valid description of the base variant of the minor which remains a valid description of the base variant of the minor
version in question. version in question.
In addition to following the rules for XDR extensions in Section 4.2,
such extensions must also obey the following rules in order to allow
interoperability to be established, as described in Section 4.4:
o Additions to the set of callback requests and extensions to the
XDR for existing callback operations can only be made if the
server can determine, based on the client's actions, that client
is aware of the changes, before sending those new or extended
callbacks.
o XDR extensions that affect the structures of responses to existing
operations can only be made if the server can determine, based on
the client's actions, that it is aware of the existence of XDR
changes, before sending responses containing those extensions.
This determination can be based on the request being responded to,
but that is not required. Use of any protocol element defined in
the extension can be the basis of the determination, provided that
the requirements for determining client awareness are clearly
stated.
Corrections to protocol errors (see Section 9) may be accomplished by Corrections to protocol errors (see Section 9) may be accomplished by
publishing an extension, including a compatible XDR change. Such publishing an extension, including a compatible XDR change which
documents will update the defining documents for the corrected minor follows the rules above. Such documents will update the defining
version. documents for the minor version to be corrected.
7. Minor Versions 7. Minor Versions
7.1. Creation of New Minor Versions 7.1. Creation of New Minor Versions
It is important to note that this section, in describing situations It is important to note that this section, in describing situations
that would require new minor versions to be created, does not thereby that would require new minor versions to be created, does not thereby
imply that situations will exist in the future. Judgments regarding imply that situations will exist in the future. Judgments regarding
desirability of future changes will be made by the working group or desirability of future changes will be made by the working group or
its successors and any guidance that can be offered at this point is its successors and any guidance that can be offered at this point is
skipping to change at page 17, line 18 skipping to change at page 18, line 15
Creation of a new minor version is an option that the working group Creation of a new minor version is an option that the working group
retains. The listing of situations below that would prompt such retains. The listing of situations below that would prompt such
actions is not meant to be exhaustive. actions is not meant to be exhaustive.
The following sorts of features are not allowed as extensions and The following sorts of features are not allowed as extensions and
would require creation of a new minor version: would require creation of a new minor version:
o Features that incorporate any of the non-XDR-based changes o Features that incorporate any of the non-XDR-based changes
discussed in Sections 5.1 and 5.2. discussed in Sections 5.1 and 5.2.
o Features whose XDR changes do not follow the rules in Section 6.
o Addition of REQUIRED new features. o Addition of REQUIRED new features.
o Changes to the status of existing features including converting o Changes to the status of existing features including converting
features to be mandatory to not implement. features to be mandatory to not implement.
8. Minor Version Interaction Rules 8. Minor Version Interaction Rules
This section addresses issues related to rules #11 and #13 in the This section addresses issues related to rules #11 and #13 in the
minor versioning rules in [RFC5661]. With regard to the supersession minor versioning rules in [RFC5661]. With regard to the supersession
of minor versioning rules, the treatment here overrides that in of minor versioning rules, the treatment here overrides that in
skipping to change at page 17, line 44 skipping to change at page 18, line 43
8.1. Minor Version Identifier Transfer Issues 8.1. Minor Version Identifier Transfer Issues
Each relationship between a client instance and a server instance, as Each relationship between a client instance and a server instance, as
represented by a clientid, is to be devoted to a single minor represented by a clientid, is to be devoted to a single minor
version. If a server detects that a COMPOUND with an inappropriate version. If a server detects that a COMPOUND with an inappropriate
minor version is being used, it MUST reject the request. In doing minor version is being used, it MUST reject the request. In doing
so, it may return either NFS4ERR_BAD_CLIENTID or so, it may return either NFS4ERR_BAD_CLIENTID or
NFS4RR_MINOR_VERS_MISMATCH. NFS4RR_MINOR_VERS_MISMATCH.
As a result of the above, the client has the assurance that the set As a result of the above, the client has the assurance that the set
of REQUIRED and OPTONAL features will not change within the context of REQUIRED and OPTIONAL features will not change within the context
of a single clientid. Server implementations MUST ensure that the of a single clientid. Server implementations MUST ensure that the
set of supported features and protocol elements does not change set of supported features and protocol elements does not change
within such a context. within such a context.
8.2. Minor Version Compatibility 8.2. Minor Version Compatibility
The goal of the NFSv4 extension model is to enable compatibility The goal of the NFSv4 extension model is to enable compatibility
including compatibility between clients and servers implementing including compatibility between clients and servers implementing
different minor versions. different minor versions.
skipping to change at page 18, line 51 skipping to change at page 19, line 45
should be returned. should be returned.
o When a switch case is used which is not known in the specified o When a switch case is used which is not known in the specified
minor version, NFS4ERR_BADXDR (as opposed to minor version, NFS4ERR_BADXDR (as opposed to
NFS4ERR_UNION_NOTSUPP) should be returned. Even though the NFS4ERR_UNION_NOTSUPP) should be returned. Even though the
message may be XDR-decodable by the server's current XDR, it is message may be XDR-decodable by the server's current XDR, it is
not so according to the minor version being used. not so according to the minor version being used.
o When a flag bit is used which is not known in the specified minor o When a flag bit is used which is not known in the specified minor
version, NFS4ERR_INVAL (as opposed to NFS4ERR_NOTSUPP or any other version, NFS4ERR_INVAL (as opposed to NFS4ERR_NOTSUPP or any other
error defined as indicated non-support a flag bit) should be error defined as indicating non-support of a flag bit) should be
returned. returned.
9. Correction of Existing Minor Versions and Features 9. Correction of Existing Minor Versions and Features
The possibility always exists that there will be a need to correct an The possibility always exists that there will be a need to correct an
existing feature in some way, after the acceptance of that feature or existing feature in some way, after the acceptance of that feature,
a minor version containing it, as a Proposed Standard. While the or a minor version containing it, as a Proposed Standard. While the
working group can reduce the probability of such situations arising working group can reduce the probability of such situations arising
by waiting for running code before considering a feature as done, it by waiting for running code before considering a feature as done, it
cannot reduce the probability to zero. As features are used more cannot reduce the probability to zero. As features are used more
extensively and interact with other features, previously unseen flaws extensively and interact with other features, previously unseen flaws
may be discovered and will need to be corrected. may be discovered and will need to be corrected.
Such corrections are best done in a document obsoleting or updating Such corrections are best done in a document obsoleting or updating
the RFC defining the relevant feature definition document or minor the RFC defining the relevant feature or minor version. In making
version specification. In making such corrections, the working group such corrections, the working group will have to carefully consider
will have to carefully consider how to assure interoperability with how to assure interoperability with older clients and servers.
older clients and servers.
Often, corrections can be done without changing the protocol XDR. In Often, corrections can be done without changing the protocol XDR. In
many cases, a change in client and server behavior can be implemented many cases, a change in client and server behavior can be implemented
without taking special provision with regard to interoperability with without taking special provision with regard to interoperability with
earlier implementations. In those case, and in cases in which a earlier implementations. In those cases, and in cases in which a
revision merely clarifies an earlier protocol definition document, a revision merely clarifies an earlier protocol definition document, a
new document can be published which simply updates the earlier new document can be published which simply updates the earlier
protocol definition document. protocol definition document.
In other cases, it is best if client or server behavior needs to In other cases, it is best if client or server behavior needs to
change in a way which raises interoperability concerns. In such change in a way which raises interoperability concerns. In such
cases, incompatible changes in server or client behavior should not cases, incompatible changes in server or client behavior should not
be mandated in order to avoid XDR changes. be mandated in order to avoid XDR changes.
9.1. XDR Changes to Implement Protocol Corrections 9.1. XDR Changes to Implement Protocol Corrections
skipping to change at page 19, line 47 skipping to change at page 20, line 40
When XDR changes are necessary as part of correcting a flaw, these When XDR changes are necessary as part of correcting a flaw, these
should be done in a manner similar to that used when implementing new should be done in a manner similar to that used when implementing new
minor versions or features within them. In particular, minor versions or features within them. In particular,
o Existing XDR structures may not be modified or deleted. o Existing XDR structures may not be modified or deleted.
o XDR extensions may be used to correct existing protocol facilities o XDR extensions may be used to correct existing protocol facilities
in a manner similar to those used to add additional optional in a manner similar to those used to add additional optional
features. Such corrections may be done in a minor version for features. Such corrections may be done in a minor version for
which optional features may no longer be added, if the working which optional features may no longer be added, if the working
group decides that it is an appropriate to compatibly effect a group decides that it is an appropriate way to compatibly effect a
correction. correction.
o When a correction is made to an OPTIONAL feature, the result is o When a correction is made to an OPTIONAL feature, the result is
similar to a situation in which there are two independent OPTIONAL similar to a situation in which there are two independent OPTIONAL
features. A server may choose to implement either or both. features. A server may choose to implement either or both. See
Section 9.2 for a detailed discussion of interoperability issues.
o When a correction is made to a required feature, the situation o When a correction is made to a REQUIRED feature, the situation
becomes one in which neither the old nor the new version of the becomes one in which the old version of the feature remains
feature is required. Instead, it is required that a server REQUIRED while the corrected version, while OPTIONAL, in intended
support at least one of the two, while each is individually to be adopted to provide correct operation. Although use of the
OPTIONAL. Although use of the corrected version is ultimately corrected version is ultimately better, and may be recommended, it
better, and may be recommended, it should not be described as should not be described as "RECOMMENDED", since the choice of
"RECOMMENDED", since the choice of which version to support if versions to support will depend on the needs of clients, which may
only one is supported will depend on the needs of clients, which be slow to adopt the updated version. The nature of such
may be slow to adopt the updated version. The nature of such
corrections is such that it may result in situations in which corrections is such that it may result in situations in which
different variants of the same minor version may not support the different variants of the same minor version may not support both
same set of REQUIRED protocol elements. See Section 9.2 for support the corrected version. See Section 9.3 for details.
details.
o In all of the cases above, it is appropriate that the old version o In all of the cases above, it is appropriate that the old version
of the feature, be considered obsolescent, with the expectation of the feature be considered obsolescent, with the expectation
that the working group might, in a later minor version, decide that the working group might, in a later minor version, change the
that the older version is to become mandatory to not implement. status of the uncorrected version. See Section 9.4 for more
detail.
By doing things this way, the protocol with the XDR modification can 9.2. XDR Corrections to OPTIONAL features
By defining the corrected and uncorrected version as independent
OPTIONAL features, the protocol with the XDR modification can
accommodate clients and servers that support either the corrected or accommodate clients and servers that support either the corrected or
the uncorrected version of the protocol and also clients and servers the uncorrected version of the protocol and also clients and servers
aware of and capable of supporting both alternatives. aware of and capable of supporting both alternatives.
o A client that supports only the earlier version of the feature Based on the type of client:
(i.e., an older unfixed client) can determine whether the server
it is connecting to supports the older version of feature. It is o A client that uses only the earlier version of the feature (i.e.,
an older unfixed client) can determine whether the server it is
connecting to supports the older version of feature. It is
capable of interoperating with older servers that support only the capable of interoperating with older servers that support only the
unfixed protocol as well as ones that support both versions. unfixed protocol as well as ones that support both versions.
o A client that supports only the corrected version of the feature o A client that supports only the corrected version of the feature
(i.e., a new or updated client) can determine whether the server (i.e., a new or updated client) can determine whether the server
it is connecting to supports the newer version of the feature. It it is connecting to supports the newer version of the feature. It
is capable of interoperating with newer servers that support only is capable of interoperating with newer servers that support only
the updated feature as well as ones that support both versions. the updated feature as well as ones that support both versions.
o A client that supports both the older and newer version of the o A client that supports both the older and newer version of the
feature can determine which version of the particular feature is feature can determine which version of the particular feature is
supported by the server it is working with. supported by the server it is working with.
Based on the type of server:
o A server that supports only the earlier version of the feature o A server that supports only the earlier version of the feature
(i.e., an older unfixed server) can only successfully interoperate (i.e., an older unfixed server) can only successfully interoperate
with older clients. However newer clients can easily determine with older clients. However newer clients can easily determine
that the feature cannot be used on that server. that the feature cannot be used on that server.
o A server that supports only the newer version of the feature o A server that supports only the newer version of the feature
(i.e., a new or updated server) can only successfully interoperate (i.e., a new or updated server) can only successfully interoperate
with newer clients. However, older clients can easily determine with newer clients. However, older clients can easily determine
that the feature cannot be used on that server. In the case of that the feature cannot be used on that server. In the case of
OPTIONAL features, clients can be expected to deal with non- OPTIONAL features, clients can be expected to deal with non-
support of that particular feature. support of that particular feature.
o A server that supports both the older and newer versions of the o A server that supports both the older and newer versions of the
feature can interoperate with all client variants. feature can interoperate with all client variants.
By using extensions in this manner, the protocol creates a clear path By using extensions in this manner, the protocol creates a clear path
which preserves the functioning of existing clients and servers and which preserves the functioning of existing clients and servers and
allows client and server implementers to adopt the new version of the allows client and server implementers to adopt the new version of the
feature at a reasonable pace. feature at a reasonable pace.
9.2. XDR Corrections to required features 9.3. XDR Corrections to REQUIRED features
When protocol corrections are made to REQUIRED features, there can be Interoperability issues are similar to those for the OPTIONAL case
situations in which different implementations of the minor version described above (in Section 9.2). However, because the use of the
may implement distinct variants of that minor version. As a result, uncorrected version is REQUIRED, servers have to support this until
they might not support (or have knowledge of) the same set of there is a minor version change. Nevertheless, there is the
REQUIRED protocol elements. In such situations, client and server opportunity for clients and servers to implement the corrected
implementations might: version, while maintaining necessary interoperability with earlier
implementations.
o Implement only the earlier uncorrected version of the REQUIRED The following types of servers can exist:
feature.
o Implement only the newer, corrected version of the REQUIRED o Servers only aware of and supporting the uncorrected version, such
feature. as servers developed before the issue requiring correction was
known.
o Implement both the uncorrected and corrected versions of the o Servers aware of both versions while only supporting the
REQUIRED feature. uncorrected version.
In such situations, clients can attempt to use the techniques o Servers aware of and supporting both versions.
described in Sections 4.4.2 and 4.4.3 to arrive at a common protocol
variant to serve as a basis for interoperation. The fact that the
set of REQUIRED protocol elements might not be the same gives rise to
additional issues, since there might be cases in which the client and
server do not share a common version of the REQUIRED feature being
corrected.
o When the client implements only the uncorrected version of the With the exception of clients which do not use the feature in
feature, it can successfully interoperate with servers which question, the following sorts of clients may exist:
support only the uncorrected version or both the corrected and
uncorrected versions.
o When the client implements only the corrected version of the o Clients only aware of and prepared to use the uncorrected version,
feature, it can successfully interoperate with servers which such as those developed before the issue requiring correction was
support only the corrected version or both the corrected and known.
uncorrected versions.
o When the client is able to use both the uncorrected and corrected Clients developed before the correction was defined would be of
versions of the feature, it can successfully interoperate with this type. They would be capable of interoperating with all of
servers which support either version or both versions. the types of servers listed above, but could not use the corrected
version.
o When the client implements only the uncorrected version of the o Clients aware of both versions while only prepared to use the
feature, it cannot successfully interoperate with servers which uncorrected version.
support only the corrected version. In this situation, it can
determine that the implementations are incompatible just as it
would have done if the server did not support the minor version in
question.
o When the client implements only the uncorrected version of the Some clients developed or modified after the correction was
feature, it cannot successfully interoperate with servers which defined would be of this type, until they were modified to support
support only the uncorrected version. In this situation, it can the corrected version. They would also be capable of
determine that the implementations are incompatible just as it interoperating with all of the types of servers listed above, but
would have done if the server did not support the minor version in could not use the corrected version.
question.
In such situations, clients and servers implemented after the o Clients aware of and prepared to use either version.
corrected version is defined are well advised to support both the
corrected and uncorrected versions. Nevertheless, once uncorrected Such clients would be capable of interoperating with all of the
implementations become uncommon, implementers have the option of only types of servers listed above, and could use the corrected version
supporting the corrected version. with servers that supported it.
o Clients aware of both versions while only prepared to use the
newer, corrected, version.
Such clients would only be capable of interoperating with servers
that supported the correct version. With other types of server,
they could determine the absence of appropriate support at an
early stage and treat the minor version in question as unsupported
by the server. Such clients are only likely to be deployed when
the majority of servers support the corrected version.
9.4. Addressing XDR Corrections in Later Minor Versions
As described in Sections 9.2 and 9.3, a corrected XDR can be
incorporated in an existing minor version and be used, while an
existing uncorrected version is still supported. Nevertheless, the
uncorrected version will remain part of the protocol until its status
is changed in a later minor version.
One possible change that could be made in a later minor version is to
define the uncorrected version as mandatory to not implement.
Because of the difficulty of determining that no clients depend on
support for the uncorrected version, it is unlikely that this step
would be appropriate for a considerable time.
In the case of a correction to a REQUIRED feature, there are a number
of less disruptive changes that could be made earlier:
o Changing the uncorrected version from REQUIRED to OPTIONAL while
REQUIRING that servers support at least one of the two versions.
This would allow new server implementations to avoid support for
the uncorrected version.
o Changing the corrected version from OPTIONAL to REQUIRED, making
both versions REQUIRED.
This would allow new clients to depend on support for the
corrected version being present.
o Changing the uncorrected version from REQUIRED to OPTIONAL while
changing the corrected version from OPTIONAL to REQUIRED.
This would complete the shift to the corrected version once
clients are prepared to use the corrected version.
In making such changes, interoperability issues would need to be
carefully considered.
10. Security Considerations 10. Security Considerations
Since no substantive protocol changes are proposed here, no security Since no substantive protocol changes are proposed here, no security
considerations apply. considerations apply.
11. IANA Considerations 11. IANA Considerations
The current document does not require any actions by IANA. The current document does not require any actions by IANA.
skipping to change at page 23, line 9 skipping to change at page 24, line 47
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1 "Network File System (NFS) Version 4 Minor Version 1
Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
<http://www.rfc-editor.org/info/rfc5661>. <http://www.rfc-editor.org/info/rfc5661>.
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
March 2015, <http://www.rfc-editor.org/info/rfc7530>. March 2015, <http://www.rfc-editor.org/info/rfc7530>.
[RFCv42] Haynes, T., Ed., "NFS Version 4 Minor Version 2", January [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor
2016, <http://www.ietf.org/id/ Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862,
draft-ietf-nfsv4-minorversion2-41.txt>. November 2016, <http://www.rfc-editor.org/info/rfc7862>.
12.2. Informative References 12.2. Informative References
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, DOI 10.17487/RFC3530, (NFS) version 4 Protocol", RFC 3530, DOI 10.17487/RFC3530,
April 2003, <http://www.rfc-editor.org/info/rfc3530>. April 2003, <http://www.rfc-editor.org/info/rfc3530>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The author wishes to thank Tom Haynes of Primary Data for his role in The author wishes to thank Tom Haynes of Primary Data for his role in
getting this effort started and his work in co-authoring the first getting the effort to revise NFSV4 version magement started and for
version of the initial working group versioning document. his work in co-authoring the first version of this document.
The author also wishes to thank Chuck Lever and Mike Kupfer of Oracle The author also wishes to thank Chuck Lever and Mike Kupfer of Oracle
and Bruce Fields of Red Hat for their helpful reviews of this and and Bruce Fields of Red Hat for their helpful reviews of this and
other versioning-related documents. other versioning-related documents.
Appendix B. Instructions for RFC Editor
In a number of places, this document needs to refer to the RFC for
NFSv4.2, which is in the process of being published as a Proposed
Standard. Because this process is not yet complete, the following
changes need to be made to adapt to the eventual assignment of an RFC
number for that document.
o Replacement of the string "xxxx" by the RFC number assigned, in
the list of RFC's to be updated
o Replacement of the reference anchor "RFCv42" by a string which
reflects the RFC number assigned. Also, the bibliographic
information associated with that reference will need to reflect
the RFC publication.
Author's Address Author's Address
David Noveck David Noveck
Hewlett Packard Enterprise Hewlett Packard Enterprise
165 Dascomb Road 165 Dascomb Road
Andover, MA 01810 Andover, MA 01810
US US
Phone: +1 978 474 2011 Phone: +1 978 474 2011
Email: davenoveck@gmail.com Email: davenoveck@gmail.com
 End of changes. 68 change blocks. 
193 lines changed or deleted 260 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/