draft-ietf-nfsv4-versioning-06.txt   draft-ietf-nfsv4-versioning-07.txt 
NFSv4 D. Noveck NFSv4 D. Noveck
Internet-Draft HPE Internet-Draft HPE
Updates: 5661 (if approved) September 7, 2016 Updates: 5661, xxxx (if approved) October 22, 2016
Intended status: Standards Track Intended status: Standards Track
Expires: March 11, 2017 Expires: April 25, 2017
Rules for NFSv4 Extensions and Minor Versions. Rules for NFSv4 Extensions and Minor Versions.
draft-ietf-nfsv4-versioning-06 draft-ietf-nfsv4-versioning-07
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. this document supersede the minor versioning rules in RFC5661 and
other RFCs defining minor versions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 11, 2017. This Internet-Draft will expire on April 25, 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 2, line 25 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . 9
4.4. Inter-version Interoperability . . . . . . . . . . . . . 10 4.4. Inter-version Interoperability . . . . . . . . . . . . . 10
4.4.1. Requirements for Knowledge of Protocol Elements . . . 10 4.4.1. Requirements for Knowledge of Protocol Elements . . . 10
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 . . . . . 13
4.5. XDR Overlay . . . . . . . . . . . . . . . . . . . . . . . 14 4.5. XDR Overlay . . . . . . . . . . . . . . . . . . . . . . . 14
5. Other NFSv4 Protocol Changes . . . . . . . . . . . . . . . . 14 5. Other NFSv4 Protocol Changes . . . . . . . . . . . . . . . . 15
5.1. Field Interpretation and Use . . . . . . . . . . . . . . 15 5.1. Field Interpretation and Use . . . . . . . . . . . . . . 15
5.2. Behavioral Changes . . . . . . . . . . . . . . . . . . . 15 5.2. Behavioral Changes . . . . . . . . . . . . . . . . . . . 16
6. Extending Existing Minor Versions . . . . . . . . . . . . . . 16 6. Extending Existing Minor Versions . . . . . . . . . . . . . . 16
7. Minor Versions . . . . . . . . . . . . . . . . . . . . . . . 16 7. Minor Versions . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Creation of New Minor Versions . . . . . . . . . . . . . 16 7.1. Creation of New Minor Versions . . . . . . . . . . . . . 16
8. Minor Version Interaction Rules . . . . . . . . . . . . . . . 17 8. Minor Version Interaction Rules . . . . . . . . . . . . . . . 17
8.1. Minor Version Identifier Transfer Issues . . . . . . . . 17 8.1. Minor Version Identifier Transfer Issues . . . . . . . . 17
8.2. Minor Version Compatibility . . . . . . . . . . . . . . . 17 8.2. Minor Version Compatibility . . . . . . . . . . . . . . . 18
9. Correction of Existing Minor Versions and Features . . . . . 18 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 . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9.2. XDR Corrections to required features . . . . . . . . . . 21
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 23
Appendix B. Instructions for RFC Editor . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
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 5, line 51 skipping to change at page 6, line 5
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 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 subset of the current minor version and a superset of the base minor
version. When the term "minor version" is used without either of version. When the term "minor version" is used without either of
these qualifiers, it should refer to something which is true of all these qualifiers, it should refer to something which is true of all
variants within that minor version. For example, one may refer to variants within that minor version. For example, in the case of a
the set of REQUIRED features in a given minor version since it is the minor version that has not had a protocol correction, one may refer
same for all variants within the minor version. 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 of
these will be a superset of the appropriate base minor version. these will be a superset of the appropriate base 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
skipping to change at page 6, line 45 skipping to change at page 6, line 49
addressed in the rules in Section 4.2. addressed in the rules in Section 4.2.
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]. As minor version specification RFC's, including those in [RFC5661] and
a result, potential conflicts among documents should be addressed as also the modification to those rules mentioned in [RFCv42]. As a
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
skipping to change at page 8, line 49 skipping to change at page 9, line 9
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: However, 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 operation codes, for either
the nfsv4 program or the callback program, is not allowed. the nfsv4 program or the callback program.
o Deletion of existing RPC operations, enum values, flag bit values o Deletion of existing RPC operations, enum values, flag bit values
and switch cases. Note that changes may be made to define use of and switch cases. Note that changes may be made to define use of
any of these as causing an error, as long as the XDR is any of these as causing an error, as long as the XDR is
unaffected. 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
skipping to change at page 9, line 36 skipping to change at page 9, line 42
an error indicative of the element being recognized as one which an error indicative of the element being recognized as one which
is not supported such as NFS4ERR_NOTSUPP, NFS4ERR_UNION_NOTSUPP, is not supported such as NFS4ERR_NOTSUPP, NFS4ERR_UNION_NOTSUPP,
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 are COMPOUND or CB_COMPOUND. The possibilities which can exist when
listed below. 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
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 13, line 15 skipping to change at page 13, line 24
either be identical to this variant or a valid extension of it. either be identical to this variant or a valid extension of it.
Similarly, the variants that the client and the server actually Similarly, the variants that the client and the server actually
use will be a subset of this variant, in that certain OPTIONAL use will be a subset of this variant, in that certain OPTIONAL
features will not be used. features will not 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
support provided by the server before acting on user requests. This
includes the determination of the common protocol variant and the
level of support for OPTIONAL protocol elements.
4.4.3. Determining Knowledge of Protocol Elements 4.4.3. Determining Knowledge of Protocol Elements
A requester may test the responder's knowledge of particular protocol A requester may test the responder's knowledge of particular protocol
elements as defined below, based on the type of protocol element. elements as defined below, based on the type of protocol element.
Note that in the case of attribute or flag bits, use of a request
that refers to 2 or more bits of undetermined status (known versus
unknown) may return results which are not particularly helpful. In
such cases, when the response is NFS4ERR_INVAL, the requester can
only conclude that at least one of the bits is unknown.
o When a GETATTR request is made specifying an attribute bit to be o When a GETATTR request is made specifying an attribute bit to be
tested and that attribute is not a set-only attribute, if the tested and that attribute is not a set-only attribute, if the
GETATTR returns with the error NFS4ERR_INVAL, then it can be GETATTR returns with the error NFS4ERR_INVAL, then it can be
concluded that the responder has no knowledge of the attribute in concluded that the responder has no knowledge of the attribute in
question. Other responses, including NFS4ERR_ATTRNOTSUPP, question. Other responses, including NFS4ERR_ATTRNOTSUPP,
indicate that the responder is aware of the attribute in question. indicate that the responder is aware of the attribute in question.
o When a SETATTR request is made specifying the attribute bit to be o When a SETATTR request is made specifying the attribute bit to be
tested and that attribute is not a get-only attribute, if the tested and that attribute is not a get-only attribute, if the
skipping to change at page 18, line 6 skipping to change at page 18, line 26
o Servers supporting a given minor version should support earlier o Servers supporting a given minor version should support earlier
minor versions within that set and return appropriate errors for minor versions within that set and return appropriate errors for
use of protocol elements that were not a valid part of that use of protocol elements that were not a valid part of that
earlier minor version. For details see below. earlier minor version. For details see below.
o Clients should deal with an NFS4ERR_MINOR_VERS_MISMATCH error by o Clients should deal with an NFS4ERR_MINOR_VERS_MISMATCH error by
searching for a lower minor version number that the server will searching for a lower minor version number that the server will
accept. accept.
Servers supporting a given minor version MUST, in returning errors Servers supporting a given minor version MUST, in returning errors
for operation which were a valid part of the minor version, return for operations which were a valid part of the minor version, return
the errors allowed for the current operation in the minor version the errors allowed for the current operation in the minor version
actually being used. actually being used.
With regard to protocol elements not known in a given minor version, With regard to protocol elements not known in a given minor version,
the appropriate error codes are given below. Essentially, the the appropriate error codes are given below. Essentially, the
server, although it has a more extensive XDR reflective of a newer server, although it has a more extensive XDR reflective of a newer
minor version, must act as a server with a more limited XDR would. minor version, must act as a server with a more limited XDR would.
o When an operation is used which is not known in the specified o When an operation is used which is not known in the specified
minor version, NFS4ERR_OP_ILLEGAL (as opposed to NFS4ERR_NOTSUPP) minor version, NFS4ERR_OP_ILLEGAL (as opposed to NFS4ERR_NOTSUPP)
skipping to change at page 18, line 30 skipping to change at page 18, line 50
minor version, NFS4ERR_INVAL (as opposed to NFS4ERR_ATTRNOTSUPP) minor version, NFS4ERR_INVAL (as opposed to NFS4ERR_ATTRNOTSUPP)
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 indicated non-support 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 or
a minor version containing it, as a Proposed Standard. While the 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
skipping to change at page 19, line 42 skipping to change at page 20, line 13
features. A server may choose to implement either or both. features. A server may choose to implement either or both.
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 neither the old nor the new version of the
feature is required. Instead, it is required that a server feature is required. Instead, it is required that a server
support at least one of the two, while each is individually support at least one of the two, while each is individually
OPTIONAL. Although use of the corrected version is ultimately OPTIONAL. Although use of the corrected version is ultimately
better, and may be recommended, it should not be described as better, and may be recommended, it should not be described as
"RECOMMENDED", since the choice of which version to support if "RECOMMENDED", since the choice of which version to support if
only one is supported will depend on the needs of clients, which only one is supported will depend on the needs of clients, which
may be slow to adopt the updated version. may be slow to adopt the updated version. The nature of such
corrections is such that it may result in situations in which
different variants of the same minor version may not support the
same set of REQUIRED protocol elements. See Section 9.2 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, decide that the working group might, in a later minor version, decide
that the older version is to become mandatory to not implement. that the older version is to become mandatory to not implement.
By doing things this way, the protocol with the XDR modification can By doing things this way, 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.
skipping to change at page 20, line 43 skipping to change at page 21, line 16
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
When protocol corrections are made to REQUIRED features, there can be
situations in which different implementations of the minor version
may implement distinct variants of that minor version. As a result,
they might not support (or have knowledge of) the same set of
REQUIRED protocol elements. In such situations, client and server
implementations might:
o Implement only the earlier uncorrected version of the REQUIRED
feature.
o Implement only the newer, corrected version of the REQUIRED
feature.
o Implement both the uncorrected and corrected versions of the
REQUIRED feature.
In such situations, clients can attempt to use the techniques
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
feature, it can successfully interoperate with servers which
support only the uncorrected version or both the corrected and
uncorrected versions.
o When the client implements only the corrected version of the
feature, it can successfully interoperate with servers which
support only the corrected version or both the corrected and
uncorrected versions.
o When the client is able to use both the uncorrected and corrected
versions of the feature, it can successfully interoperate with
servers which support either version or both versions.
o When the client implements only the uncorrected version of the
feature, it cannot successfully interoperate with servers which
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
feature, it cannot successfully interoperate with servers which
support only the uncorrected 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.
In such situations, clients and servers implemented after the
corrected version is defined are well advised to support both the
corrected and uncorrected versions. Nevertheless, once uncorrected
implementations become uncommon, implementers have the option of only
supporting the corrected version.
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.
12. References 12. References
skipping to change at page 21, line 27 skipping to change at page 23, line 9
[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
2016, <http://www.ietf.org/id/
draft-ietf-nfsv4-minorversion2-41.txt>.
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 this effort started and his work in co-authoring the first
version of the initial working group versioning document. version of the initial working group versioning 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. 21 change blocks. 
27 lines changed or deleted 129 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/