draft-ietf-nfsv4-versioning-09.txt   draft-ietf-nfsv4-versioning-10.txt 
NFSv4 D. Noveck NFSv4 D. Noveck
Internet-Draft HPE Internet-Draft NetApp
Updates: 5661, 7862 (if approved) December 9, 2016 Updates: 5661, 7862 (if approved) May 25, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: June 12, 2017 Expires: November 26, 2017
Rules for NFSv4 Extensions and Minor Versions Rules for NFSv4 Extensions and Minor Versions
draft-ietf-nfsv4-versioning-09 draft-ietf-nfsv4-versioning-10
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 June 12, 2017. This Internet-Draft will expire on November 26, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
4.4.3. Determining Knowledge of Protocol Elements . . . . . 14 4.4.3. Determining Knowledge of Protocol Elements . . . . . 14
4.5. XDR Overlay . . . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . 17 6. Extending Existing Minor Versions . . . . . . . . . . . . . . 17
7. Minor Versions . . . . . . . . . . . . . . . . . . . . . . . 17 7. Minor Versions . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Creation of New Minor Versions . . . . . . . . . . . . . 17 7.1. Creation of New Minor Versions . . . . . . . . . . . . . 17
8. Minor Version Interaction Rules . . . . . . . . . . . . . . . 18 8. Minor Version Interaction Rules . . . . . . . . . . . . . . . 18
8.1. Minor Version Identifier Transfer Issues . . . . . . . . 18 8.1. Minor Version Identifier Transfer Issues . . . . . . . . 18
8.2. Minor Version Compatibility . . . . . . . . . . . . . . . 18 8.2. Minor Version Compatibility . . . . . . . . . . . . . . . 19
9. Correction of Existing Minor Versions and Features . . . . . 19 9. Correction of Existing Minor Versions and Features . . . . . 20
9.1. XDR Changes to Implement Protocol Corrections . . . . . . 20 9.1. XDR Changes to Implement Protocol Corrections . . . . . . 20
9.2. XDR Corrections to OPTIONAL features . . . . . . . . . . 21 9.2. XDR Corrections to OPTIONAL features . . . . . . . . . . 21
9.3. XDR Corrections to REQUIRED features . . . . . . . . . . 22 9.3. XDR Corrections to REQUIRED features . . . . . . . . . . 22
9.4. Addressing XDR Corrections in Later Minor Versions . . . 23 9.4. Addressing XDR Corrections in Later Minor Versions . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 25 12.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
skipping to change at page 3, line 31 skipping to change at page 3, line 31
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 when needed. of new minor versions remains available when needed.
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 to 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 a subset of available extensions,
available extensions, enabling interoperation to proceed just as if with the client able to use the subset of the extensions that it is
both implementations supported only the parts of the protocol they prepared to use that the server supports as well. Support for this
both support. common subset is not affected by the fact that extensions outside
this common subset may be supported by the server or potentially used
by the client.
The rules in this document supersede previous rules regarding minor
versions. The new rules concerning protocol extension and minor
versions are summarized in Section 3 while rules regarding the
interaction of minor versions appear in Section 8.
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].
In this document, the term "version" is not limited to minor In this document, the term "version" is not limited to minor
versions. When minor versions are meant, the term "minor version" is versions. When minor versions are meant, the term "minor version" is
used explicitly. For more discussion of this and related terms, see used explicitly. For more discussion of this and related terms, see
Section 2.3 Section 2.3
skipping to change at page 5, line 31 skipping to change at page 5, line 35
2.3. NFSv4 Versions 2.3. NFSv4 Versions
The term "version" denotes any valid protocol variant constructed The term "version" denotes any valid protocol variant constructed
according to the rules in this document. It includes minor versions, according to the rules in this document. It includes minor versions,
but there are situations which allow multiple variant versions to be but there are situations which allow multiple variant versions to be
associated with and co-exist within a single minor version: associated with and co-exist within a single minor version:
o When there are feature specification documents published as o When there are feature specification documents published as
Proposed Standards extending a given minor version, then the Proposed Standards extending a given minor version, then the
protocol defined by the minor version specification document, when protocol defined by the minor version specification document, when
combined with any subset (not necessarily proper) of the feature combined with any subset (not necessarily a proper subset) of the
specification documents, is a valid NFSv4 version variant which is feature specification documents, is a valid NFSv4 version variant
part of the minor version in question. which is part of the minor version in question.
o When there are protocol corrections published which update a given o When there are protocol corrections published which update a given
minor version, each set of published updates, up to the date of minor version, each set of published updates, up to the date of
publication of the update, is a valid NFSv4 version variant which publication of the update, is a valid NFSv4 version variant which
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:
skipping to change at page 7, line 18 skipping to change at page 7, line 21
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 the minor versioning rules #11 and #13 that appear in
the interactions between multiple minor versions, the situation is Section 2.7 of [RFC5661] deal with the interactions between
more complicated. See Section 8 for a discussion of these issues, multiple minor versions, the situation is more complicated. See
including how potential conflicts between rules are to be Section 8 below for a discussion of these issues, including how
resolved. potential conflicts between rules are to be 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 inter-
compatibility in situations in which the client and server use version compatibility in situations in which the client and server
different XDR descriptions. For example, the client and server may use different XDR descriptions. For example, the client and server
implement different variants of the same minor version, in that they may implement different variants of the same minor version, in that
each might add different sets of extensions to the base minor they each might add different sets of extensions to the base minor
version. version.
The XDR extension paradigm, discussed in Section 4.1, assures that The XDR extension paradigm, discussed in Section 4.1, assures that
these descriptions are compatible, with clients and servers able to these descriptions are compatible, with clients and servers able to
determine and use those portions of the protocol that they both share determine and use those portions of the protocol that they both share
according to the method described in Section 4.4.2. according to the method described in Section 4.4.2.
4.1. XDR Extension 4.1. XDR Extension
When an NFSv4 version change requires a modification to the protocol When an NFSv4 version change requires a modification to the protocol
skipping to change at page 9, line 37 skipping to change at page 9, line 37
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 procedures, for either the o Addition of previously unspecified RPC procedures, for either the
nfsv4 program or the callback program. nfsv4 program or the callback program.
o Deletion of existing RPC procedures, operation codes, enum values, o Deletion of existing RPC procedures, operation codes, enum values,
flag bit values and switch cases. Note that changes may be made flag bit values and switch cases. Note that changes may be made
to define use of any of these as causing an error, as long as the to define use of any of these as causing an error, as long as the
XDR is unaffected. XDR is unaffected. 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 by Responders 4.3. Handling of Protocol Elements by Responders
Implementations handle protocol elements received in requests and Implementations handle protocol elements received in requests and
callbacks in one of three ways. Which of the following ways are callbacks in one of three ways. Which of the following ways are
valid depends on the status of the protocol element in the variant valid depends on the status of the protocol element in the variant
being implemented: 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
skipping to change at page 13, line 24 skipping to change at page 13, line 21
o The client's minor version is higher than that of the server. In o The client's minor version is higher than that of the server. In
this case the client, in accord with Section 8.2, uses a lower this case the client, in accord with Section 8.2, uses a lower
minor version that the server will accept. In this case, the minor version that the server will accept. In this case, the
server has no knowledge of extensions made in subsequent minor server has no knowledge of extensions made in subsequent minor
versions. versions.
There are a number of cases to consider based on the characteristics There are a number of cases to consider based on the characteristics
of the minor version chosen. of the minor version chosen.
o The minor version consists of only a single variant (no extension o When 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), the client and the server are using the same
same XDR description and have knowledge of the same protocol 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 use the approach described in different set. The client can use the approach described in
Section 4.4.3 to determine which of the extensions it knows about Section 4.4.3 to determine which of the extensions it knows about
are also known by the server. Once this is done, the client and are also known by the server. Once this is done, the client and
server will both be using a common variant. The variants that the server will both be using a common variant. The variants that the
client and the server were built with will both either be client and the server were built with will both either be
skipping to change at page 17, line 13 skipping to change at page 17, line 13
operations and COMPOUNDs consisting only of them became invalid. operations and COMPOUNDs consisting only of them became invalid.
Also, changes were made regarding the required server behavior as to Also, changes were made regarding the required server behavior as to
the interaction of the MODE and ACL attributes. the interaction of the MODE and ACL attributes.
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 use the "Updates" header specifying the RFC
which remains a valid description of the base variant of the minor defining the minor version, which remains a valid description of the
version in question. base variant of the minor version in question.
In addition to following the rules for XDR extensions in Section 4.2, 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 such extensions must also obey the rules listed below in order to
interoperability to be established, as described in Section 4.4: allow interoperability to be established, as described in
Section 4.4:
o Additions to the set of callback requests and extensions to the o Additions to the set of callback requests and extensions to the
XDR for existing callback operations can only be made if the XDR for existing callback operations can only be made if the
server can determine, based on the client's actions, that that server can determine, based on the client's actions, that that
client is aware of the changes. This determination, for any client is aware of the changes. This determination, for any
particular client (as defined by its clientid), is made before particular client (as defined by its clientid), is made before
sending those new or extended callbacks. sending those new or extended callbacks.
o XDR extensions that affect the structures of responses to existing o XDR extensions that affect the structures of responses to existing
operations can only be made if the server can determine, based on operations can only be made if the server can determine, based on
skipping to change at page 21, line 48 skipping to change at page 22, line 4
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: 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 clients implementing the older version. However, clients
that the feature cannot be used on that server. that do not implement the older version of the feature can easily
determine 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.
skipping to change at page 25, line 25 skipping to change at page 25, line 29
getting the effort to revise NFSV4 version management started and for getting the effort to revise NFSV4 version management started and for
his work in co-authoring the first version of this 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.
Author's Address Author's Address
David Noveck David Noveck
Hewlett Packard Enterprise NetApp
165 Dascomb Road 1601 Trapelo Road
Andover, MA 01810 Waltham, MA 02451
US US
Phone: +1 978 474 2011 Phone: +1 781 572 8038
Email: davenoveck@gmail.com Email: davenoveck@gmail.com
 End of changes. 17 change blocks. 
43 lines changed or deleted 50 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/