draft-ietf-nfsv4-versioning-08.txt   draft-ietf-nfsv4-versioning-09.txt 
NFSv4 D. Noveck NFSv4 D. Noveck
Internet-Draft HPE Internet-Draft HPE
Updates: 5661, 7862 (if approved) December 3, 2016 Updates: 5661, 7862 (if approved) December 9, 2016
Intended status: Standards Track Intended status: Standards Track
Expires: June 6, 2017 Expires: June 12, 2017
Rules for NFSv4 Extensions and Minor Versions Rules for NFSv4 Extensions and Minor Versions
draft-ietf-nfsv4-versioning-08 draft-ietf-nfsv4-versioning-09
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 6, 2017. This Internet-Draft will expire on June 12, 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
skipping to change at page 6, line 4 skipping to change at page 6, line 4
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 after that original definition. 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 up
subsequently. to that time.
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 implement some particular variant of that minor version. Each
variant is a subset of the current minor version and a superset of variant is a subset of the current minor version and a superset of
the base minor version. When the term "minor version" is used the base minor version. When the term "minor version" is used
without either of these qualifiers, it should refer to something without either of these qualifiers, it should refer to something
which is true of all variants within that minor version. For 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 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 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 minor version since it is the same for all variants within the minor
skipping to change at page 9, line 43 skipping to change at page 9, line 43
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.
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 by Responders 4.3. Handling of Protocol Elements by Responders
Implementations handle protocol elements in 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
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.
skipping to change at page 12, line 11 skipping to change at page 12, line 11
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. This is the case if there has been no extension protocol elements. This is the case if there has been no extension
for the minor version in question. Extensions can be added to for the minor version in question. Extensions can be added to
extensible minor versions as described in Section 6 and can be used extensible minor versions as described in Section 6 and can be used
to correct protocol flaws as described in Section 9. to correct protocol flaws as 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
skipping to change at page 17, line 23 skipping to change at page 17, line 23
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, 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 following rules in order to allow
interoperability to be established, as described in Section 4.4: 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 client server can determine, based on the client's actions, that that
is aware of the changes, before sending those new or extended client is aware of the changes. This determination, for any
callbacks. particular client (as defined by its clientid), is made before
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
the client's actions, that it is aware of the existence of XDR the client's actions, that it is aware of the existence of XDR
changes, before sending responses containing those extensions. changes, before sending responses containing those extensions.
This determination can be based on the request being responded to, This determination can be based on the request being responded to,
but that is not required. Use of any protocol element defined in but that is not required. Use of any protocol element defined in
the extension can be the basis of the determination, provided that the extension can be the basis of the determination, provided that
the requirements for determining client awareness are clearly the requirements for determining client awareness are clearly
stated. stated.
skipping to change at page 21, line 9 skipping to change at page 21, line 9
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 the old version of the feature remains becomes one in which the old version of the feature remains
REQUIRED while the corrected version, while OPTIONAL, in intended REQUIRED while the corrected version, while OPTIONAL, in intended
to be adopted to provide correct operation. Although use of the to be adopted to provide correct operation. Although use of the
corrected version is ultimately better, and may be recommended, it corrected version is ultimately better, and may be recommended, it
should not be described as "RECOMMENDED", since the choice of should not be described as "RECOMMENDED", since the choice of
versions to support will depend on the needs of clients, which may versions to support will depend on the needs of clients, which may
be slow to adopt the updated version. The nature of such 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 both different variants of the same minor version may not both support
support the corrected version. See Section 9.3 for details. the corrected version. See Section 9.3 for 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, change the that the working group might, in a later minor version, change the
status of the uncorrected version. See Section 9.4 for more status of the uncorrected version. See Section 9.4 for more
detail. detail.
9.2. XDR Corrections to OPTIONAL features 9.2. XDR Corrections to OPTIONAL features
By defining the corrected and uncorrected version as independent By defining the corrected and uncorrected version as independent
skipping to change at page 22, line 22 skipping to change at page 22, line 22
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.3. XDR Corrections to REQUIRED features 9.3. XDR Corrections to REQUIRED features
Interoperability issues are similar to those for the OPTIONAL case Interoperability issues in this case are similar to those for the
described above (in Section 9.2). However, because the use of the OPTIONAL case described above (in Section 9.2). However, because the
uncorrected version is REQUIRED, servers have to support this until use of the uncorrected version is REQUIRED, servers have to support
there is a minor version change. Nevertheless, there is the this until there is a minor version change. Nevertheless, there is
opportunity for clients and servers to implement the corrected the opportunity for clients and servers to implement the corrected
version, while maintaining necessary interoperability with earlier version, while maintaining necessary interoperability with earlier
implementations. implementations.
The following types of servers can exist: The following types of servers can exist:
o Servers only aware of and supporting the uncorrected version, such o Servers only aware of and supporting the uncorrected version, such
as servers developed before the issue requiring correction was as servers developed before the issue requiring correction was
known. known.
o Servers aware of both versions while only supporting the o Servers aware of both versions while only supporting the
skipping to change at page 25, line 15 skipping to change at page 25, line 15
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 the effort to revise NFSV4 version magement 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 Hewlett Packard Enterprise
 End of changes. 11 change blocks. 
19 lines changed or deleted 20 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/