draft-ietf-nfsv4-versioning-03.txt   draft-ietf-nfsv4-versioning-04.txt 
NFSv4 D. Noveck NFSv4 D. Noveck
Internet-Draft HPE Internet-Draft HPE
Updates: 5661 (if approved) January 15, 2016 Updates: 5661 (if approved) June 2, 2016
Intended status: Standards Track Intended status: Standards Track
Expires: July 18, 2016 Expires: December 4, 2016
NFSv4 Version Management NFSv4 Version Management
draft-ietf-nfsv4-versioning-03 draft-ietf-nfsv4-versioning-04
Abstract Abstract
This document describes the management of versioning within the NFSv4 This document describes the management of versioning within the NFSv4
family of protocols. It covers the creation of minor versions, the family of protocols. It covers the creation of minor versions, the
addition of optional features to existing minor versions, and 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.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 July 18, 2016. This Internet-Draft will expire on December 4, 2016.
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 36 skipping to change at page 2, line 36
4.4.1. Requirements for Knowledge of Protocol Elements . . . 15 4.4.1. Requirements for Knowledge of Protocol Elements . . . 15
4.4.2. Establishing Interoperability . . . . . . . . . . . . 16 4.4.2. Establishing Interoperability . . . . . . . . . . . . 16
4.4.3. Determining Knowledge of Protocol Elements . . . . . 18 4.4.3. Determining Knowledge of Protocol Elements . . . . . 18
4.4.4. Interoperability Between Version Groups . . . . . . . 19 4.4.4. Interoperability Between Version Groups . . . . . . . 19
5. Other NFSv4 Protocol Changes . . . . . . . . . . . . . . . . 19 5. Other NFSv4 Protocol Changes . . . . . . . . . . . . . . . . 19
5.1. Non-XDR Protocol Changes . . . . . . . . . . . . . . . . 19 5.1. Non-XDR Protocol Changes . . . . . . . . . . . . . . . . 19
5.1.1. Field Interpretation and Use . . . . . . . . . . . . 20 5.1.1. Field Interpretation and Use . . . . . . . . . . . . 20
5.1.2. Behavioral Changes . . . . . . . . . . . . . . . . . 21 5.1.2. Behavioral Changes . . . . . . . . . . . . . . . . . 21
5.1.3. Rules for non-XDR changes . . . . . . . . . . . . . . 21 5.1.3. Rules for non-XDR changes . . . . . . . . . . . . . . 21
5.2. Specification of Associated Protocols . . . . . . . . . . 22 5.2. Specification of Associated Protocols . . . . . . . . . . 22
5.2.1. Associated Protocols via pNFS Mapping Types . . . . . 22 5.2.1. Associated Protocols via pNFS Mapping Types . . . . . 23
5.2.2. Additional Forms of Associated Protocols . . . . . . 23 5.2.2. Additional Forms of Associated Protocols . . . . . . 23
6. NFSv4 Protocol Features . . . . . . . . . . . . . . . . . . . 24 6. NFSv4 Protocol Features . . . . . . . . . . . . . . . . . . . 24
6.1. Previous Uses of the Feature Concept . . . . . . . . . . 25 6.1. Previous Uses of the Feature Concept . . . . . . . . . . 25
6.2. Rules for Protocol Feature Construction . . . . . . . . . 25 6.2. Rules for Protocol Feature Construction . . . . . . . . . 26
6.3. Statuses of Features . . . . . . . . . . . . . . . . . . 26 6.3. Statuses of Features . . . . . . . . . . . . . . . . . . 26
6.4. Statuses of Protocol Elements Within Features . . . . . . 27 6.4. Statuses of Protocol Elements Within Features . . . . . . 27
6.5. Determining Protocol Element Support . . . . . . . . . . 29 6.5. Determining Protocol Element Support . . . . . . . . . . 29
6.6. Feature Discovery . . . . . . . . . . . . . . . . . . . . 30 6.6. Feature Discovery . . . . . . . . . . . . . . . . . . . . 30
6.7. Feature Incorporation . . . . . . . . . . . . . . . . . . 31 6.7. Feature Incorporation . . . . . . . . . . . . . . . . . . 32
7. Extensions within Minor Versions . . . . . . . . . . . . . . 32 7. Extensions within Minor Versions . . . . . . . . . . . . . . 32
7.1. Adding Features to Extensible Minor Versions . . . . . . 32 7.1. Adding Features to Extensible Minor Versions . . . . . . 32
7.2. Use of Feature Specification Documents . . . . . . . . . 32 7.2. Use of Feature Specification Documents . . . . . . . . . 33
7.3. Compatibility Issues . . . . . . . . . . . . . . . . . . 33 7.3. Compatibility Issues . . . . . . . . . . . . . . . . . . 34
7.3.1. Compatibility Issues for Messages Sent to Servers . . 34 7.3.1. Compatibility Issues for Messages Sent to Servers . . 34
7.3.2. Compatibility Issues for Messages Sent to Clients . . 35 7.3.2. Compatibility Issues for Messages Sent to Clients . . 35
7.4. Relationship Between Minor Versioning and Extensions 7.4. Relationship Between Minor Versioning and Extensions
within a Minor Version . . . . . . . . . . . . . . . . . 36 within a Minor Version . . . . . . . . . . . . . . . . . 36
8. Minor Versions . . . . . . . . . . . . . . . . . . . . . . . 36 8. Minor Versions . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. Creation of New Minor Versions . . . . . . . . . . . . . 36 8.1. Creation of New Minor Versions . . . . . . . . . . . . . 37
8.1.1. New Minor Versions within an Existing Group . . . . . 37 8.1.1. New Minor Versions within an Existing Group . . . . . 37
8.1.2. New Minor Version Groups . . . . . . . . . . . . . . 37 8.1.2. New Minor Version Groups . . . . . . . . . . . . . . 37
8.1.3. Limits on Minor Version Groups . . . . . . . . . . . 40 8.1.3. Limits on Minor Version Groups . . . . . . . . . . . 40
8.2. Role of Minor Versions . . . . . . . . . . . . . . . . . 41 8.2. Role of Minor Versions . . . . . . . . . . . . . . . . . 41
8.3. Minor Version Interaction Rules . . . . . . . . . . . . . 41 8.3. Minor Version Interaction Rules . . . . . . . . . . . . . 41
8.3.1. Minor Version Identifier Transfer Issues . . . . . . 42 8.3.1. Minor Version Identifier Transfer Issues . . . . . . 42
8.3.2. Minor Version Intra-Group Compatibility . . . . . . . 42 8.3.2. Minor Version Intra-Group Compatibility . . . . . . . 42
8.3.3. Minor Version Inter-Group Compatibility . . . . . . . 43 8.3.3. Minor Version Inter-Group Compatibility . . . . . . . 43
9. Correction of Existing Minor Versions and Features . . . . . 44 9. Correction of Existing Minor Versions and Features . . . . . 44
9.1. XDR Changes to Implement Protocol Corrections . . . . . . 45 9.1. XDR Changes to Implement Protocol Corrections . . . . . . 45
10. Documentation of Features, Extensions, Minor Versions, and 10. Documentation of Features, Extensions, Minor Versions, and
Protocol Corrections . . . . . . . . . . . . . . . . . . . . 46 Protocol Corrections . . . . . . . . . . . . . . . . . . . . 47
10.1. Documentation Approach . . . . . . . . . . . . . . . . . 47 10.1. Documentation Approach . . . . . . . . . . . . . . . . . 47
10.2. Indexing material . . . . . . . . . . . . . . . . . . . 47 10.2. Indexing material . . . . . . . . . . . . . . . . . . . 47
10.3. Feature Specification Documents . . . . . . . . . . . . 48 10.3. Feature Specification Documents . . . . . . . . . . . . 48
10.4. XDR File Considerations . . . . . . . . . . . . . . . . 50 10.4. XDR File Considerations . . . . . . . . . . . . . . . . 50
10.5. Additional Documents to Support Protocol Extension . . . 51 10.5. Additional Documents to Support Protocol Extension . . . 51
10.5.1. Minor Version Indexing Document . . . . . . . . . . 51 10.5.1. Minor Version Indexing Document . . . . . . . . . . 51
10.5.2. Consolidated XDR Document . . . . . . . . . . . . . 52 10.5.2. Consolidated XDR Document . . . . . . . . . . . . . 52
10.5.3. XDR Assignment Document . . . . . . . . . . . . . . 52 10.5.3. XDR Assignment Document . . . . . . . . . . . . . . 52
10.5.4. Transition of Documents to RFC's . . . . . . . . . . 53 10.5.4. Transition of Documents to RFC's . . . . . . . . . . 53
10.6. Documentation of New Minor Versions . . . . . . . . . . 54 10.6. Documentation of New Minor Versions . . . . . . . . . . 54
10.7. Documentation of XDR Changes for Corrections . . . . . . 54 10.7. Documentation of XDR Changes for Corrections . . . . . . 54
11. Security Considerations . . . . . . . . . . . . . . . . . . . 55 11. Security Considerations . . . . . . . . . . . . . . . . . . . 55
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
13.1. Normative References . . . . . . . . . . . . . . . . . . 55 13.1. Normative References . . . . . . . . . . . . . . . . . . 55
13.2. Informative References . . . . . . . . . . . . . . . . . 55 13.2. Informative References . . . . . . . . . . . . . . . . . 56
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 57 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 57
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 57
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 version management modification of existing minor versions. The version management
skipping to change at page 9, line 25 skipping to change at page 9, line 25
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 the variants within that minor version. For example, one may refer the
set of REQUIRED features in a given minor version since it is the set of REQUIRED features in a given minor version since it is the
same for all variants within the minor version. same for all variants within the 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.
A minor version group is defined as a set of minor versions having A minor version group is defined as a successive set of minor
exactly the same set of REQUIRED and mandatory to not implement versions having exactly the same set of REQUIRED and mandatory to not
protocol elements. The union of the sets of variants for all these implement protocol elements. The union of the sets of variants for
minor versions provides a high degree of inter-variant compatibility. all these minor versions provides a high degree of inter-variant
Clients and servers which implement variants within this group should compatibility. Clients and servers which implement variants within
be compatible as long as each takes proper care, as it should, to this group should be compatible as long as each takes proper care, as
properly deal with the case in which the other party does not know of it should, to properly deal with the case in which the other party
or has no support for OPTIONAL protocol elements. does not know of or has no support for OPTIONAL protocol elements.
3. Consolidation of Version Management Rules 3. Consolidation of Version Management Rules
In the past, the only existing version management rules were the In the past, the only existing version management rules were the
minor versioning rules that had been being maintained and specified minor versioning rules that had been being maintained and specified
in the Standards Track RFCs which defined the individual minor in the Standards Track RFCs which defined the individual minor
versions. In the past, these minor versioning rules were modified on versions. In the past, these minor versioning rules were modified on
an ad hoc basis for each new minor version. an ad hoc 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 18, line 30 skipping to change at page 18, line 30
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
SETATTR returns with the error NFS4ERR_INVAL, then it can be SETATTR 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 request is made including an operation with a new flag bit, o When a request is made including an operation with a new flag bit,
if the operation returns with the error NFS4ERR_INVAL, then it can if the operation returns with the error NFS4ERR_INVAL, then it can
be concluded that the responder has no knowledge of the flag bit generally be concluded that the responder has no knowledge of the
in question. Other responses indicate that the responder is aware flag bit in question, as long as the requester is careful to avoid
of the flag bit in question. other error situations in which the operation in question is
defined as returning NFS4ERR_INVAL. Other responses indicate that
the responder is aware of the flag bit in question.
o When a request is made including the operation to be tested, if o When a request is made including the operation to be tested, if
the responder returns an RPC XDR decode error, or a response the responder returns an RPC XDR decode error, or a response
indicating that the operation in question resulted in indicating that the operation in question resulted in
NFS4ERR_OP_ILLEGAL or NFS4ERR_BADXDR, then it can be concluded NFS4ERR_OP_ILLEGAL or NFS4ERR_BADXDR, then it can be concluded
that the responder has no knowledge of the operation in question. that the responder has no knowledge of the operation in question.
Other responses, including NFS4ERR_NOTSUPP, indicate that the Other responses, including NFS4ERR_NOTSUPP, indicate that the
responder is aware of the operation in question. responder is aware of the operation in question.
o When a request is made including the switch arm to be tested, if o When a request is made including the switch arm to be tested, if
skipping to change at page 20, line 5 skipping to change at page 20, line 7
on a number of factors, including the types of changes included in on a number of factors, including the types of changes included in
the feature. This subject is discussed in Sections 6.7 and 7. the feature. This subject is discussed in Sections 6.7 and 7.
5.1. Non-XDR Protocol Changes 5.1. Non-XDR Protocol Changes
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.
Because these sorts of changes do not involve XDR extensions, it is
not possible to use the techniques discussed in Section 4.4.3 to
distinguish responders which have the change those which do not. To
avoid this situation resulting in implementation incompatibility, all
such changes need to be made in a minor version, rather than in an
extension with to an existing minor version.
5.1.1. Field Interpretation and Use 5.1.1. Field Interpretation and Use
The XDR description of a protocol does not constitute a complete The XDR description of a protocol does not constitute a complete
description of the protocol. Therefore, versioning needs to consider description of the protocol. Therefore, versioning needs to consider
the role of changes in the use of fields, even when there is no the role of changes in the use of fields, even when there is no
change to the underlying XDR. change to the underlying XDR.
Although any XDR element is potentially subject to a change in its Although any XDR element is potentially subject to a change in its
interpretation and use, the likelihood of such change will vary with interpretation and use, the likelihood of such change will vary with
the XDR-specified type of the element, as discussed below: the XDR-specified type of the element, as discussed below:
skipping to change at page 22, line 4 skipping to change at page 22, line 17
o The correction of a protocol mistake, best handled as described in o The correction of a protocol mistake, best handled as described in
Section 9. Section 9.
o A protocol improvement relevant to a new minor version or feature, o A protocol improvement relevant to a new minor version or feature,
to be documented as described in Section 10.3. to be documented as described in Section 10.3.
In order to avoid such situations, all such changes will be In order to avoid such situations, all such changes will be
documented as part of a feature, specifying the specific changes documented as part of a feature, specifying the specific changes
relative to protocol versions that do not incorporate that new relative to protocol versions that do not incorporate that new
feature. Also, to provide greater clarity about such changes, the feature. As specified in Section 5.1, such changes may not be made
following sets of rules apply. in an extension.
The following rules apply to "substantive behavior changes", i.e.
all changes in which there is a substantive change to non-error
behavior. In other words, the change is not one which only changes
the set of valid error codes or prescribes that different error codes
are to be returned in particular situations.
o Any substantive behavior change must be part of a feature in which
there is also an XDR extension present, to enable testing for
presence of the feature.
o No feature including a substantive behavior change can be made Also, to provide greater clarity about such changes, the following
REQUIRED at initial introduction. rules apply to features which include the sort non-XDR changes
described in Sections 5.1.1 and 5.1.2.
The following rules apply to all behavioral changes. o Except for features that only change the set of valid error codes
or prescribe that different error codes are to be returned in
particular situations, feature that include such non-XDR changes
cannot be made REQUIRED at initial introduction.
o No feature including such a change can be introduced as an Since such features are to be OPTIONAL, there needs to be some way
extension. While the feature may be documented in a separate that requester can determine whether the feature is supported by
feature definition document in such cases, that document should be the responder. This normally take the form of an associated XDR
referenced normatively by the minor version specification. change, such as an attribute which can be interrogated to
determine if support is present.
o While it is allowed to include multiple such changes in the same o While it is allowed to include multiple such changes in the same
feature this should only be done if there is a good reason for all feature this should only be done if there is a good reason for all
of these to be included or not included together. Such changes of these to be included or not included together. Such changes
should not be included in the same feature simply because all such should not be included in the same feature simply because all such
changes were introduced in the same minor version. changes were introduced in the same minor version.
5.2. Specification of Associated Protocols 5.2. Specification of Associated Protocols
The definition of ancillary protocols is a form of protocol extension The definition of ancillary protocols is a form of protocol extension
skipping to change at page 27, line 7 skipping to change at page 27, line 15
details. details.
In addition to feature status, there may be other constraints that In addition to feature status, there may be other constraints that
define when an implementation must or may support a feature. In define when an implementation must or may support a feature. In
particular, support for one feature may require support for another, particular, support for one feature may require support for another,
or the presence of one feature may require that another feature not or the presence of one feature may require that another feature not
be supported. be supported.
6.4. Statuses of Protocol Elements Within Features 6.4. Statuses of Protocol Elements Within Features
The status of a protocol element within its containing feature This section discusses three classes of information that a requester
reflects two pieces of information that are used in determining might use in order to allow it to avoid individually testing the
support for feature and associated protocol elements. responder's knowledge of and support for each possible protocol
element. This information includes:
o A status value that allows support for the feature to be inferred o The grouping of feature elements within features and features
based on support for the protocol element. This is referred to as within feature packages. If two feature elements are part of the
the protocol element's E-to-F status. same feature or of features within the same feature package, then
each responder which is aware of one must be aware of the other,
o A status value that allows support for the feature element to be o The assignment of status values that allow support for the feature
inferred based on support for the feature. This is referred to as in which the feature element is defined to be inferred based on
the protocol element's F-to-E status with regard to the feature. support for the protocol element. This is referred to as the
protocol element's E-to-F status.
The purpose of defining these status values is to allow the support o The assignment of status values that allows support for a feature
or non-support for one protocol elements to be determined based on element to be inferred based on support for the feature. This is
referred to as the protocol element's F-to-E status with regard to
the feature.
The purpose of specifying this information is to allow the knowledge
of and support for one protocol element to be determined based on
responses for others, avoiding the complexity that a client would responses for others, avoiding the complexity that a client would
have to deal with if each such support decision were independent. A have to deal with if each such support decision were independent. A
simpler model would have been to simply assign protocol elements to simpler model would have been to simply assign protocol elements to
feature-based support equivalence classes and require all protocol feature-based support equivalence classes and require all protocol
elements in a feature to be supported or not supported together. elements in a feature to be supported or not supported together.
This approach was not adopted because it is not compatible with many This approach was not adopted because it is not compatible with many
current and expected feature patterns: current and expected feature patterns:
o Many existing protocol features contain protocol elements that are o Many existing protocol features contain protocol elements that are
optional in the context of the feature. optional in the context of the feature.
o Some existing protocol elements are used by more than one feature. o Some existing protocol elements are used by more than one feature.
o Boolean attributes that indicate the presence of support for a o Boolean attributes that indicate the presence of support for a
given feature are tied to that feature, even though the attribute given feature are tied to that feature, even though the attribute
can be supported when the feature is not, in which case the can be supported when the feature is not, in which case the
attribute is supported and has the value FALSE. attribute is supported and has the value FALSE.
The following are possible E-to-F statuses. The following are noteworthy E-to-F statuses.
o Support or non-support for the feature is always the same as that o Support or non-support for the feature is always the same as that
for the protocol element. This is represented as an "IFF" value. for the protocol element. This is represented as an "IFF" value.
o Support for the feature can be inferred from support for the
protocol element but not necessarily the reverse. This is
represented as an "SINF" value.
o Lack of support for the feature can be inferred from lack of
support for the protocol element but not necessarily the reverse.
This is represented as an "NSINF" value.
o Lack of support for the feature can be inferred from lack of o Lack of support for the feature can be inferred from lack of
support for the protocol element but the reverse can be determined support for the protocol element but the reverse can be determined
by using the protocol element to determine whether support for the by using the protocol element to determine whether support for the
feature is present. An example would be a Boolean attribute feature is present. An example would be a Boolean attribute
indicating whether support for the feature is present. This is indicating whether support for the feature is present. This is
represented as an "SVAL" value. represented as an "SVAL" value.
Generally, it will be clear how a client may determine whether any It needs to be clear how a client may determine whether any
particular OPTIONAL feature is supported. Typically there will be particular OPTIONAL feature is supported. Typically there will be
one or more protocol elements belonging to the feature whose E-F one or more protocol elements belonging to the feature whose E-F
status is "IFF" or "SVAL". In these cases, support for the protocol status is "IFF" or "SVAL". In these cases, support for the protocol
elements in question can be determined as described in Section 6.4 elements in question can be determined as described in Section 6.5
In more complicated cases, the feature specification should clearly In more complicated cases, the feature specification should clearly
specify how to determine whether support is present. specify how to determine whether support is present.
The following are possible F-to-E statuses. The following are possible F-to-E statuses.
o Support for the protocol element is REQUIRED when support for the o Support for the protocol element is REQUIRED when support for the
feature is present. feature is present.
o Support for the protocol element is OPTIONAL when support for the o Support for the protocol element is OPTIONAL when support for the
feature is present. feature is present.
o Support for the protocol element unaffected by the presence of o Support for the protocol element is unaffected by the presence of
support for the feature. support for the feature.
The overall status of a feature element within a minor version is The overall status of a feature element within a minor version is
generally determined as follows: generally determined as follows:
o If there are one or more REQUIRED features which give the protocol o If there are one or more REQUIRED features which give the protocol
element an F-to-E status of REQUIRED, then the overall status of element an F-to-E status of REQUIRED, then the overall status of
the protocol element within the minor version is REQUIRED. the protocol element within the minor version is REQUIRED.
o Otherwise, if there are one or more REQUIRED or OPTIONAL features o Otherwise, if there are one or more REQUIRED or OPTIONAL features
skipping to change at page 39, line 30 skipping to change at page 39, line 43
the feature. the feature.
The degree of such difficulties and the readiness of clients to The degree of such difficulties and the readiness of clients to
make such changes should be key considerations in making such a make such changes should be key considerations in making such a
state transition. state transition.
o Converting an OPTIONAL feature to be REQUIRED poses no difficulty o Converting an OPTIONAL feature to be REQUIRED poses no difficulty
for existing client implementations. The difficulties for for existing client implementations. The difficulties for
existing server implementations depend on the scope of the feature existing server implementations depend on the scope of the feature
involved and the set of implementations without support for the involved and the set of implementations without support for the
feature in question. feature in question. The degree of such difficulties and the
readiness of servers to make such changes should be key
The degree of such difficulties and the readiness of servers to considerations in making such a state transition. Nevertheless,
make such changes should be key considerations in making such a it should not be the only consideration. If all existing servers
state transition. Nevertheless, it should not be the only support the feature, it does not thereby follow that the
consideration. If all existing servers support the feature, it transition should be made. The possible effect of making server
does not thereby follow that the transition should be made. The development more complicated should also be considered.
possible effect of making server development more complicated
should also be considered.
A number of other changes allowed only in a new minor version group, A number of other changes allowed only in a new minor version group,
raise analogous issues. raise analogous issues.
o In the case of inter-feature constraints or similar o In the case of inter-feature constraints or similar
reorganizations, the basic issue is whether the client has to deal reorganizations, the basic issue is whether the client has to deal
with the absence of a protocol element when it previously had not with the absence of a protocol element when it previously had not
had to deal with that or the server has to provide support for a had to deal with that or the server has to provide support for a
protocol element in situations in which it previously had not had protocol element in situations in which it previously had not had
to. When a set of changes cause both sorts of issues, the to. When a set of changes cause both sorts of issues, the
skipping to change at page 42, line 26 skipping to change at page 42, line 29
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.3.2. Minor Version Intra-Group Compatibility 8.3.2. Minor Version Intra-Group Compatibility
Within a set of minor versions that belong to the same minor version Within a set of minor versions that belong to the same minor version
group, it is relatively easy for clients and servers to provides the group, it is relatively easy for clients and servers to provides the
needed compatibility by following the following rules. needed compatibility by following the following rules.
o Servers supporting a given minor version MUST support any earlier o Servers supporting a given minor version SHOULD support any
minor version in the same minor version group and return earlier minor version in the same minor version group. If a
appropriate errors for use of protocol elements that were not a server does not do so it will be unable to interoperate with
valid part of that earlier minor version. For details see below. clients built to interoperate with servers supporting earlier
minor versions, despite the fact that all features expected by the
client are still required of the server and the client is unaware
of added OPTIONAL server added since then.
Servers that do so MUST return appropriate errors for use of
protocol elements that were not a valid part of that earlier minor
version. For details see below.
o Servers supporting a given minor version MUST, in returning errors o Servers supporting a given minor version MUST, in returning errors
for operation which were a valid part of the minor version, return for operation 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.
o Clients MUST deal with an NFS4ERR_MINOR_VERS_MISMATCH error by a o Clients MUST deal with an NFS4ERR_MINOR_VERS_MISMATCH error by a
searching for a lower minor version number in the same minor searching for a lower minor version number in the same minor
version group that the server will accept. version group that the server will accept.
skipping to change at page 55, line 51 skipping to change at page 56, line 9
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
13.2. Informative References 13.2. Informative References
[NFSv42] Haynes, T., Ed., "NFS Version 4 Minor Version 2", January [NFSv42] Haynes, T., Ed., "NFS Version 4 Minor Version 2", January
2016, <http://www.ietf.org/id/ 2016, <http://www.ietf.org/id/
draft-ietf-nfsv4-minorversion2-40.txt>. draft-ietf-nfsv4-minorversion2-41.txt>.
Work in progress. Work in progress.
[NFSv42-dot-x] [NFSv42-dot-x]
Haynes, T., Ed., "NFS Version 4 Minor Version 2 Protocol Haynes, T., Ed., "NFS Version 4 Minor Version 2 Protocol
External Data Representation Standard (XDR) Description", External Data Representation Standard (XDR) Description",
January 2016, <http://www.ietf.org/id/ January 2016, <http://www.ietf.org/id/
draft-ietf-nfsv4-minorversion2-dot-x-40.txt>. draft-ietf-nfsv4-minorversion2-dot-x-41.txt>.
Work in progress. Work in progress.
[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>.
[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
 End of changes. 31 change blocks. 
81 lines changed or deleted 90 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/