Internet Engineering Task Force (IETF) D. Noveck
Request for Comments: 8178 NetApp
Updates: 5661, 7862 July 2017
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) D. Noveck
Request for Comments: 8178 NetApp
Updates: 5661, 7862 July 2017
Category: Standards Track
ISSN: 2070-1721
Rules for NFSv4 Extensions and Minor Versions
NFSv4扩展和次要版本的规则
Abstract
摘要
This document describes the rules relating to the extension of the NFSv4 family of protocols. It covers the creation of minor versions, the addition of optional features to existing minor versions, and the correction of flaws in features already published as Proposed Standards. The rules relating to the construction of minor versions and the interaction of minor version implementations that appear in this document supersede the minor versioning rules in RFC 5661 and other RFCs defining minor versions.
本文档描述了与NFSv4协议系列扩展相关的规则。它包括创建次要版本、在现有次要版本中添加可选功能以及纠正已作为拟议标准发布的功能中的缺陷。本文档中出现的与次要版本构造和次要版本实现交互相关的规则取代RFC 5661和其他定义次要版本的RFC中的次要版本控制规则。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8178.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8178.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Use of Keywords Defined in RFCs 2119 and 8174 . . . . . . 4
2.2. Use of Feature Statuses . . . . . . . . . . . . . . . . . 4
2.3. NFSv4 Versions . . . . . . . . . . . . . . . . . . . . . 5
3. Consolidation of Extension Rules . . . . . . . . . . . . . . 6
4. XDR Considerations . . . . . . . . . . . . . . . . . . . . . 7
4.1. XDR Extension . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Rules for XDR Extension within NFSv4 . . . . . . . . . . 8
4.3. Handling of Protocol Elements by Responders . . . . . . . 9
4.4. Inter-version Interoperability . . . . . . . . . . . . . 11
4.4.1. Requirements for Knowledge of Protocol Elements . . . 11
4.4.2. Establishing Interoperability . . . . . . . . . . . . 12
4.4.3. Determining Knowledge of Protocol Elements . . . . . 14
4.5. XDR Overlay . . . . . . . . . . . . . . . . . . . . . . . 15
5. Other NFSv4 Protocol Changes . . . . . . . . . . . . . . . . 15
5.1. Field Interpretation and Use . . . . . . . . . . . . . . 15
5.2. Behavioral Changes . . . . . . . . . . . . . . . . . . . 16
6. Extending Existing Minor Versions . . . . . . . . . . . . . . 17
7. Minor Versions . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Creation of New Minor Versions . . . . . . . . . . . . . 18
8. Minor Version Interaction Rules . . . . . . . . . . . . . . . 18
8.1. Minor Version Identifier Transfer Issues . . . . . . . . 19
8.2. Minor Version Compatibility . . . . . . . . . . . . . . . 19
9. Correction of Existing Minor Versions and Features . . . . . 20
9.1. XDR Changes to Implement Protocol Corrections . . . . . . 21
9.2. XDR Corrections to OPTIONAL Features . . . . . . . . . . 21
9.3. XDR Corrections to REQUIRED Features . . . . . . . . . . 22
9.4. Addressing XDR Corrections in Later Minor Versions . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . 25
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Use of Keywords Defined in RFCs 2119 and 8174 . . . . . . 4
2.2. Use of Feature Statuses . . . . . . . . . . . . . . . . . 4
2.3. NFSv4 Versions . . . . . . . . . . . . . . . . . . . . . 5
3. Consolidation of Extension Rules . . . . . . . . . . . . . . 6
4. XDR Considerations . . . . . . . . . . . . . . . . . . . . . 7
4.1. XDR Extension . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Rules for XDR Extension within NFSv4 . . . . . . . . . . 8
4.3. Handling of Protocol Elements by Responders . . . . . . . 9
4.4. Inter-version Interoperability . . . . . . . . . . . . . 11
4.4.1. Requirements for Knowledge of Protocol Elements . . . 11
4.4.2. Establishing Interoperability . . . . . . . . . . . . 12
4.4.3. Determining Knowledge of Protocol Elements . . . . . 14
4.5. XDR Overlay . . . . . . . . . . . . . . . . . . . . . . . 15
5. Other NFSv4 Protocol Changes . . . . . . . . . . . . . . . . 15
5.1. Field Interpretation and Use . . . . . . . . . . . . . . 15
5.2. Behavioral Changes . . . . . . . . . . . . . . . . . . . 16
6. Extending Existing Minor Versions . . . . . . . . . . . . . . 17
7. Minor Versions . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Creation of New Minor Versions . . . . . . . . . . . . . 18
8. Minor Version Interaction Rules . . . . . . . . . . . . . . . 18
8.1. Minor Version Identifier Transfer Issues . . . . . . . . 19
8.2. Minor Version Compatibility . . . . . . . . . . . . . . . 19
9. Correction of Existing Minor Versions and Features . . . . . 20
9.1. XDR Changes to Implement Protocol Corrections . . . . . . 21
9.2. XDR Corrections to OPTIONAL Features . . . . . . . . . . 21
9.3. XDR Corrections to REQUIRED Features . . . . . . . . . . 22
9.4. Addressing XDR Corrections in Later Minor Versions . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . 25
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
To address the requirement for an NFS protocol that can evolve as the need arises, the Network File System (NFS) version 4 (NFSv4) protocol provides a framework to allow for future changes via the creation of new protocol versions, including minor versions and certain forms of modification of existing minor versions. The extension rules contained in this document allow extensions and other changes to be implemented in a way that maintains compatibility with existing clients and servers.
为了满足对NFS协议的需求，该协议可以随着需要而发展，网络文件系统（NFS）版本4（NFSv4）协议提供了一个框架，允许通过创建新的协议版本（包括次要版本和现有次要版本的某些形式的修改）进行未来更改。本文档中包含的扩展规则允许以保持与现有客户端和服务器兼容性的方式实现扩展和其他更改。
Previously, all protocol changes had been part of new minor versions. The COMPOUND procedure (see Section 14.2 of [RFC7530]) specifies the minor version being used by the client in making requests. The CB_COMPOUND procedure (see Section 15.2 of [RFC7530]) specifies the minor version being used by the server on callback requests.
以前，所有协议更改都是新的次要版本的一部分。复合程序（见[RFC7530]第14.2节）规定了客户在提出请求时使用的次要版本。CB_复合过程（参见[RFC7530]第15.2节）指定服务器在回调请求时使用的次要版本。
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 extensions and protocol corrections can be proposed, specified, and implemented within the context of a single minor version. Creation of new minor versions remains available when needed.
创建新的次要版本不再是进行协议更改的唯一方式。可选特性可以添加为扩展，协议修正可以在单个次要版本的上下文中提出、指定和实现。如果需要，可以创建新的次要版本。
The goal of allowing extensions within the context of a minor version is to provide more implementation flexibility while preserving interoperability on protocol upgrade. As described in Section 4.4, a client and server may each choose a subset of available extensions. Each party can successfully use a subset of protocol elements that are known to and supported by both the client and server. Support for this 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.
允许在次要版本的上下文中进行扩展的目标是提供更大的实现灵活性，同时保持协议升级的互操作性。如第4.4节所述，客户机和服务器可以各自选择可用扩展的子集。每一方都可以成功地使用客户端和服务器都知道并支持的协议元素子集。对该公共子集的支持不受以下事实的影响：服务器可能支持该公共子集之外的扩展，或者客户端可能使用该扩展。
A basic familiarity with NFSv4 terminology is assumed in this document and the reader is pointed to [RFC7530].
本文件假设读者对NFSv4术语基本熟悉，请参考[RFC7530]。
In this document, the term "version" is not limited to minor versions. When minor versions are meant, the term "minor version" is used explicitly. For more discussion of this and related terms, see Section 2.3.
在本文件中，术语“版本”不限于次要版本。当表示次要版本时，明确使用术语“次要版本”。有关此术语和相关术语的更多讨论，请参见第2.3节。
A "feature package" is a set of features that are defined together, either as part of a minor version or as part of the same protocol extension.
“功能包”是一起定义的一组功能，可以是次要版本的一部分，也可以是同一协议扩展的一部分。
The keywords defined by [RFC2119] [RFC8174] have special meanings that this document intends to adhere to. However, due to the nature of this document and some special circumstances, there are some complexities to take note of:
[RFC2119][RFC8174]定义的关键词具有本文件拟遵循的特殊含义。但是，由于本文件的性质和一些特殊情况，需要注意一些复杂性：
o Where this document does not directly specify implementation requirements, use of these capitalized terms is often not appropriate since the guidance given in this document does not directly affect interoperability.
o 如果本文件未直接规定实施要求，则使用这些大写术语通常不合适，因为本文件中给出的指南不会直接影响互操作性。
o In this document, what authors of RFCs defining features and minor versions need to do is stated without these specialized terms. Although it is necessary to follow this guidance to provide successful NFSv4 protocol extension, that sort of necessity is not of the sort defined as applicable to the use of the keywords defined in [RFC2119] [RFC8174].
o 在本文档中，定义特性和次要版本的RFC的作者需要做什么，没有这些专门术语。尽管有必要遵循本指南以提供成功的NFSv4协议扩展，但这种必要性并不适用于[RFC2119][RFC8174]中定义的关键字的使用。
The fact that these capitalized terms are not used should not be interpreted as indicating that this guidance does not need to be followed or is somehow not important.
不使用这些大写术语的事实不应被解释为表明不需要遵循本指南，或者不重要。
o In speaking of the possible statuses of features and feature elements, the terms "OPTIONAL" and "REQUIRED" are used. For further discussion, see Section 2.2.
o 在谈到特征和特征元素的可能状态时，使用了术语“可选”和“必需”。有关进一步讨论，请参见第2.2节。
o When one of these upper-case keywords defined in [RFC2119] [RFC8174] is used in this document, it is in the context of a rule directed to an implementer of NFSv4 minor versions, the status of a feature or protocol element, or in a quotation, sometimes indirect, from another document.
o 当在本文档中使用[RFC2119][RFC8174]中定义的其中一个大写关键字时，它是在指向NFSv4次要版本的实现者的规则上下文中、功能或协议元素的状态中，或者在另一文档的引用（有时是间接引用）中。
There has been some confusion during the history of NFSv4 about the correct use of these terms, and instances in which the keywords defined in [RFC2119] [RFC8174] were used in ways that appear to be at variance with the definitions in that document.
在NFSv4的历史中，关于这些术语的正确使用存在一些混乱，并且[RFC2119][RFC8174]中定义的关键字的使用方式似乎与该文件中的定义不一致。
o In [RFC3530], the lower-case terms "optional", "recommended", and "required" were used as feature statuses, Later, in [RFC5661] and [RFC7530], the corresponding upper-case keywords were used. It is not clear why this change was made.
o 在[RFC3530]中，小写术语“可选”、“推荐”和“必需”用作功能状态，随后在[RFC5661]和[RFC7530]中，使用了相应的大写关键字。目前尚不清楚为什么会做出这种改变。
o In the case of "RECOMMENDED", its use as a feature status is inconsistent with [RFC2119] [RFC8174] and it will not be used for this purpose in this document.
o 在“推荐”的情况下，其作为功能状态的使用与[RFC2119][RFC8174]不一致，本文件中不会将其用于此目的。
o The word "RECOMMENDED" to denote the status of attributes in [RFC7530] and [RFC5661] raises similar issues. This has been recognized in [RFC7530] with regard to NFSV4.0, although the situation with regard to NFSv4.1 remains unresolved.
o [RFC7530]和[RFC5661]中表示属性状态的“建议”一词引发了类似的问题。这已在[RFC7530]中就NFSV4.0进行了确认，尽管关于NFSV4.1的情况仍未解决。
In this document, the keywords "OPTIONAL" and "REQUIRED" and the phrase "mandatory to not implement" are used to denote the status of features within a given minor version. In using these terms, RFCs that specify the status of features inform:
在本文档中，关键字“可选”和“必需”以及短语“强制不实施”用于表示给定次要版本中的功能状态。在使用这些术语时，指定特征状态的RFC通知：
o client implementations whether they need to deal with the absence of support for these features.
o 客户机实现是否需要处理这些功能缺乏支持的问题。
o server implementations whether they need to provide support for these features.
o 服务器实现是否需要为这些功能提供支持。
The term "version" denotes any valid protocol variant constructed according to the rules in this document. It includes minor versions, but there are situations that allow multiple variant versions to be associated with and coexist within a single minor version:
术语“版本”表示根据本文件中的规则构造的任何有效协议变体。它包括次要版本，但在某些情况下允许多个变体版本与单个次要版本关联并共存：
o When there are feature specification documents published as Proposed Standards extending a given minor version, then the protocol defined by the minor version specification document, when combined with any subset (not necessarily a proper subset) of the feature specification documents, is a valid NFSv4 version variant that is part of the minor version in question.
o 当存在作为扩展给定次要版本的拟定标准发布的特性规范文件时，则次要版本规范文件定义的协议，当与特性规范文件的任何子集（不一定是适当子集）组合时，是一个有效的NFSv4版本变体，它是所讨论的次要版本的一部分。
o When there are protocol corrections published that update a given minor version, each set of published updates, up to the date of publication of the update, is a valid NFSv4 version variant that is part of the minor version in question.
o 当发布了更新给定次要版本的协议更正时，截至更新发布日期，每一组已发布的更新都是有效的NFSv4版本变体，是相关次要版本的一部分。
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 terms:
由于上述原因，可以有多个版本变体作为给定次要版本的一部分。其中有两个值得使用特殊条款：
o The term "base minor version" denotes the version variant that corresponds to the minor version as originally defined, including all protocol elements specified in the minor version definition document but not incorporating any extensions or protocol corrections published after that original definition.
o 术语“基本次要版本”表示与最初定义的次要版本相对应的版本变体，包括次要版本定义文件中指定的所有协议元素，但不包括在原始定义之后发布的任何扩展或协议更正。
o At any given time, the term "current minor version" denotes the minor version variant including all extensions of and corrections to the minor version made by Standards Track documents published up to that time.
o 在任何给定时间，术语“当前次要版本”表示次要版本变体，包括在此之前发布的标准跟踪文件对次要版本的所有扩展和更正。
Each client and server that implements a specific minor version will implement some particular variant of that minor version. Each variant is a subset of the current minor version and a superset of the base minor version. When the term "minor version" is used without either of these qualifiers, it should refer to something that is true of all variants within that minor version. For example, in the case of a minor version that has not had a protocol correction, one may refer to the set of REQUIRED features for that minor version since it is the same for all variants within the minor version. See Section 9 for a discussion of correcting an existing minor version.
实现特定次要版本的每个客户端和服务器将实现该次要版本的某些特定变体。每个变体都是当前次要版本的子集和基本次要版本的超集。当使用术语“次要版本”时，不带任何一个限定符，它应该指的是该次要版本中所有变体的真实情况。例如，在未进行协议修正的次要版本的情况下，可以参考该次要版本的所需特性集，因为它对于次要版本内的所有变体都是相同的。关于纠正现有次要版本的讨论，请参见第9节。
In the past, the only existing extension rules were the minor versioning rules that were being maintained and specified in the Standards Track RFCs, which defined the individual minor versions. In the past, these minor versioning rules were modified on an ad hoc basis for each new minor version.
在过去，仅有的现有扩展规则是在标准跟踪RFC中维护和指定的次要版本控制规则，后者定义了各个次要版本。在过去，对于每个新的次要版本，这些次要版本控制规则都是临时修改的。
More recently, minor versioning rules were specified in [RFC5661] while modifications to those rules were allowed in subsequent minor versions.
最近，在[RFC5661]中指定了次要版本控制规则，而在随后的次要版本中允许对这些规则进行修改。
This document defines a set of extension rules, including rules for minor version construction. These rules apply to all future changes to the NFSv4 protocol. The rules are subject to change but any such change should be part of a Standards Track RFC obsoleting or updating this document.
本文档定义了一组扩展规则，包括次要版本构造规则。这些规则适用于NFSv4协议的所有未来更改。这些规则可能会发生更改，但任何此类更改都应成为标准跟踪RFC淘汰或更新本文件的一部分。
Rather than a single list of extension rules, as was done in the minor versioning rules in [RFC5661], this document defines multiple sets of rules that deal with the various forms of protocol change provided for in the NFSv4 extension framework.
与[RFC5661]中的次要版本控制规则不同，本文档定义了多组规则，这些规则处理NFSv4扩展框架中提供的各种形式的协议更改。
o The kinds of changes in External Data Representation (XDR) definitions that may be made to extend NFSv4 are addressed in the rules in Section 4.2.
o 第4.2节中的规则介绍了为扩展NFSv4而可能对外部数据表示（XDR）定义进行的各种更改。
o Minor version construction, including rules applicable to changes that cannot be made in extensions to existing minor versions are addressed in Section 7.1.
o 第7.1节介绍了次要版本构造，包括适用于现有次要版本扩展中无法进行的更改的规则。
o Minor version interaction rules are discussed in Sections 8.1 and 8.2.
o 第8.1节和第8.2节讨论了次要版本交互规则。
This document supersedes minor versioning rules appearing in the minor version specification RFCs, including those in [RFC5661] and also the modification to those rules mentioned in [RFC7862]. As a result, potential conflicts among documents should be addressed as follows:
本文件取代次要版本规范RFCs中出现的次要版本控制规则，包括[RFC5661]中的规则以及[RFC7862]中提到的对这些规则的修改。因此，文件之间的潜在冲突应按以下方式解决：
o The specification of the actual protocols for minor versions previously published as Proposed Standards take precedence over minor versioning rules in either this document or in the minor version specification RFCs. In other words, if the transition from version A to version B violates a minor versioning rule, the version B protocol stays as it is.
o 先前作为建议标准发布的次要版本的实际协议规范优先于本文件或次要版本规范RFCs中的次要版本控制规则。换句话说，如果从版本A到版本B的转换违反了次要的版本控制规则，那么版本B协议将保持原样。
o Since minor versioning rules #11 and #13 from [RFC5661] deal with the interactions between multiple minor versions, the situation is more complicated. See Section 8 for a discussion of these issues, including how potential conflicts between rules are to be resolved.
o 由于[RFC5661]中的次要版本控制规则#11和#13处理多个次要版本之间的交互，因此情况更加复杂。有关这些问题的讨论，包括如何解决规则之间的潜在冲突，请参见第8节。
o Otherwise, any conflict between the extension rules in this document and those in minor version specification RFCs are to be resolved based on the treatment in this document. In particular, corrections may be made as specified in Section 9 for all previously specified minor versions, and the extensibility of previously specified minor versions is to be handled in accord with Section 6.
o 否则，本文件中的扩展规则与次要版本规范RFCs中的扩展规则之间的任何冲突将根据本文件中的处理方法解决。特别是，可以按照第9节的规定对所有先前指定的次要版本进行更正，并且应按照第6节的规定处理先前指定次要版本的扩展性。
Future minor version specification documents should avoid specifying rules relating to minor versioning and reference this document in connection with rules for NFSv4 extension.
未来的次要版本规范文档应避免指定与次要版本控制相关的规则，并在NFSv4扩展规则中参考本文档。
As an extensible XDR-based protocol, NFSv4 has to ensure inter-version compatibility in situations in which the client and server use different XDR descriptions. For example, the client and server may implement different variants of the same minor version, in that they each might add different sets of extensions to the base minor version.
作为基于XDR的可扩展协议，NFSv4必须确保在客户端和服务器使用不同XDR描述的情况下版本间的兼容性。例如，客户机和服务器可以实现相同次要版本的不同变体，因为它们各自可以向基本次要版本添加不同的扩展集。
The XDR extension paradigm, discussed in Section 4.1, assures that these descriptions are compatible, with clients and servers able to determine and use those portions of the protocol that they both share according to the method described in Section 4.4.2.
第4.1节中讨论的XDR扩展范例确保这些描述是兼容的，客户机和服务器能够根据第4.4.2节中描述的方法确定和使用它们共享的协议部分。
When an NFSv4 version change requires a modification to the protocol XDR, this is effected within a framework based on the idea of XDR extension. This is in contrast to transitions between major NFS versions (including that between NFSv3 and NFSv4.0) in which the XDR for one version was replaced by a different XDR for a newer version.
当NFSv4版本更改需要修改协议XDR时，这将在基于XDR扩展思想的框架内实现。这与主要NFS版本之间的转换（包括NFSv3和NFSv4.0之间的转换）形成对比，在这种转换中，一个版本的XDR被另一个新版本的XDR所取代。
The XDR extension approach allows an XDR description to be extended in a way that retains the structure of all previously valid messages. If a base XDR description is extended to create a second XDR description, the following will be true for the second description to be a valid extension of the first:
XDR扩展方法允许以保留所有以前有效消息的结构的方式扩展XDR描述。如果扩展基本XDR描述以创建第二个XDR描述，则第二个描述为第一个描述的有效扩展时，将出现以下情况：
o The set of valid messages described by the extended definition is a superset of that described by the first.
o 扩展定义描述的有效消息集是第一个定义描述的有效消息集的超集。
o Each message within the set of valid messages described by the base definition is recognized as having exactly the same structure/interpretation using the extended definition.
o 使用扩展定义，基本定义所描述的有效消息集中的每个消息被识别为具有完全相同的结构/解释。
o Each message within the set of messages described as valid by the extended definition but not the base definition must be recognized, using the base definition, as part of an unknown extension.
o 必须使用基本定义将扩展定义中描述为有效但不是基本定义的消息集中的每条消息识别为未知扩展的一部分。
The use of XDR extension can facilitate compatibility between different versions of the NFSv4 protocol. When XDR extension is used to implement OPTIONAL features, the greatest degree of inter-version compatibility is obtained. In this case, as long as the rules in Section 6 are followed, no change in minor version number is needed and the extension may be effected in the context of a single minor version.
使用XDR扩展可以促进NFSv4协议不同版本之间的兼容性。当XDR扩展用于实现可选功能时，可以获得最大程度的版本间兼容性。在这种情况下，只要遵循第6节中的规则，就不需要更改次要版本号，并且可以在单个次要版本的上下文中进行扩展。
In the context of NFSv4, given the central role of COMPOUND and CB_COMPOUND, addition of new RPC procedures is not allowed and the enumeration of operations and callback operations have a special role.
在NFSv4的上下文中，考虑到component和CB_component的中心作用，不允许添加新的RPC过程，操作枚举和回调操作具有特殊作用。
The following XDR extensions, by their nature, affect both messages sent by requesters (i.e., requests and callbacks), and responders (i.e., replies and callback replies).
以下XDR扩展从本质上影响请求者（即请求和回调）和响应者（即回复和回调回复）发送的消息。
o Addition of previously unspecified operation codes, within the framework established by COMPOUND and CB_COMPOUND. These extend the appropriate enumeration and the corresponding switches devoted
o 在化合物和CB_化合物建立的框架内，添加先前未指定的操作代码。这些扩展了适当的枚举和相应的开关
to requests and responses for the associated direction of operation.
对相关操作方向的请求和响应。
o Addition of previously unspecified attributes. These add additional numeric constants that define each attribute's bit position within the attribute bitmap, together with XDR typedefs that specify the attributes' format within the nominally opaque arrays specifying sets of attributes.
o 添加以前未指定的属性。这些添加了额外的数值常量，用于定义属性位图中每个属性的位位置，以及XDR TYPEDEF，用于在指定属性集的名义不透明数组中指定属性的格式。
Other sorts of changes will generally affect one of requests, replies, callback, or callback replies. Although all are valid XDR extensions, the messages that are affected may determine whether the extension requires a new minor version (see Section 7) or can be made as an extension within an existing minor version (see Section 6).
其他类型的更改通常会影响请求、答复、回调或回调答复之一。尽管所有扩展都是有效的XDR扩展，但受影响的消息可能会确定扩展是否需要新的次要版本（请参见第7节）或是否可以在现有次要版本中作为扩展（请参见第6节）。
o Addition of new, previously unused, values to existing enums.
o 向现有枚举中添加以前未使用的新值。
o Addition of previously unassigned bit values to a flag word.
o 将以前未分配的位值添加到标志字。
o Addition of new cases to existing switches, provided that the existing switch did not contain a default case.
o 向现有交换机添加新案例，前提是现有交换机不包含默认案例。
None of the following is allowed to happen:
不允许发生以下任何情况：
o Any change to the structure of existing requests or replies other than those listed above.
o 对现有请求或答复结构的任何更改（上文所列内容除外）。
o Addition of previously unspecified RPC procedures for either the NFSv4 program or the callback program.
o 为NFSv4程序或回调程序添加以前未指定的RPC过程。
o Deletion of existing RPC procedures, operation codes, enum values, 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 XDR is unaffected. Similarly, none of these items may be reused for a new purpose.
o 删除现有RPC过程、操作代码、枚举值、标志位值和开关情况。请注意，只要XDR不受影响，可以更改以定义使用其中任何一个都会导致错误。类似地，这些项目中的任何一个都不能用于新的目的。
Implementations handle protocol elements received in requests and callbacks in one of three ways. Which of the following ways are valid depends on the status of the protocol element in the variant being implemented:
实现通过以下三种方式之一处理请求和回调中接收的协议元素。以下哪种方法有效取决于正在实施的变量中协议元素的状态：
o The protocol element is not a part of definition of the variant in question and so is "unknown". The responder, when it does not report an RPC XDR decode error, reports an error indicative of the element not being defined in the XDR such as NFS4ERR_OP_ILLEGAL, NFS4ERR_BADXDR, or NFS4ERR_INVAL. See Section 4.4.3 for details.
o 协议元素不是相关变体定义的一部分，因此“未知”。响应程序在未报告RPC XDR解码错误时，报告指示XDR中未定义元素的错误，例如NFS4ERR_OP_非法、NFS4ERR_BADXDR或NFS4ERR_INVAL。详见第4.4.3节。
o The protocol element is a known part of the variant but is not supported by the particular implementation. The responder reports an error indicative of the element being recognized as one which is not supported such as NFS4ERR_NOTSUPP, NFS4ERR_UNION_NOTSUPP, or NFS4ERR_ATTRNOTSUPP.
o 协议元素是变体的已知部分，但不受特定实现的支持。响应程序报告一个错误，指示被识别为不受支持的元素，例如NFS4ERR_NOTSUPP、NFS4ERR_UNION_NOTSUPP或NFS4ERR_ATTRNOTSUPP。
o The protocol element is a known part of the variant that is supported by the particular implementation. The responder reports success or an error other than the special ones discussed above.
o 协议元素是特定实现支持的变量的已知部分。响应者报告除上述特殊情况外的成功或错误。
Which of these are validly returned by the responder depends on the status of the protocol element in the minor version specified in the COMPOUND or CB_COMPOUND. The possibilities that can exist when dealing with minor versions that have not been subject to corrections are listed below. See Sections 9.1 and 9.3 for a discussion of the effects of protocol correction.
响应者有效返回哪一个取决于复合物或CB_复合物中指定的次要版本中协议元素的状态。下面列出了处理未经更正的次要版本时可能存在的可能性。参见第9.1节和第9.3节，了解协议修正的影响。
o The protocol element is not known in the minor version. In this case, all implementations of the minor version MUST indicate that the protocol element is not known.
o 次要版本中不知道协议元素。在这种情况下，次要版本的所有实现都必须表明协议元素未知。
o The protocol element is part of a feature specified as mandatory to not implement in the minor version. In this case as well, all implementations of the minor version MUST indicate that the protocol element is not known.
o 协议元素是指定为不在次要版本中实现的强制功能的一部分。在这种情况下，次要版本的所有实现都必须表明协议元素未知。
o The protocol element is defined as part of the current variant of the minor version but is not part of the corresponding base variant. In this case, the requester can encounter situations in which the protocol element is either not known to the responder, is known to but not supported by the responder, or is both known to and supported by the responder.
o 协议元素定义为次要版本的当前变体的一部分，但不是相应基本变体的一部分。在这种情况下，请求者可能会遇到这样的情况：响应者不知道协议元素，响应者知道但不支持协议元素，或者响应者既知道又支持协议元素。
o The protocol element is defined as an OPTIONAL part of the base minor version. In this case, the requester can expect the protocol element to be known but must deal with cases in which it is supported or is not supported.
o 协议元素被定义为基本次要版本的可选部分。在这种情况下，请求者可以期望协议元素是已知的，但必须处理支持或不支持它的情况。
o The protocol element is defined as a REQUIRED part of the base minor version. In this case, the requester can expect the protocol element to be both known and supported by the responder.
o 协议元素被定义为基本次要版本的必需部分。在这种情况下，请求者可以期望响应者知道并支持协议元素。
The listing of possibilities above does not mean that a requester always needs to be prepared for all such possibilities. Often, depending on the scope of the feature of which the protocol element is a part, handling of a previous request using the same or related protocol elements will allow the requester to be sure that certain of these possibilities cannot occur.
上面列出的可能性并不意味着请求者总是需要为所有这些可能性做好准备。通常，根据协议元素所属功能的范围，使用相同或相关的协议元素处理以前的请求将允许请求者确保某些可能性不会发生。
Requesters, typically clients, may test for knowledge of, or support for, protocol elements as part of connection establishment. This may allow the requester to be aware of a responder's lack of knowledge of or support for problematic requests before they are actually used to affect user requests.
作为连接建立的一部分，请求者（通常是客户端）可以测试协议元素的知识或支持。这可能允许请求者在实际使用问题请求影响用户请求之前，意识到响应者对问题请求缺乏了解或支持。
Because of NFSv4's use of XDR extension, any communicating client and server versions have XDR definitions such that each is a valid extension of a third version. Once that version is determined, it may be used by both client and server to communicate. Each party can successfully use a subset of protocol elements that are both known to and supported by both parties.
由于NFSv4使用XDR扩展，任何通信的客户端和服务器版本都有XDR定义，因此每个版本都是第三个版本的有效扩展。一旦确定了该版本，客户端和服务器都可以使用它进行通信。每一方都可以成功地使用双方都知道并支持的协议元素子集。
With regard to requirements for knowledge of protocol elements, the following rules apply. These rules are the result of the use of the XDR extension paradigm combined with the way in which extensions are incorporated in existing minor versions (for details, see Section 6).
关于协议要素的知识要求，以下规则适用。这些规则是使用XDR扩展范例以及将扩展合并到现有次要版本中的方式的结果（有关详细信息，请参阅第6节）。
o Any protocol element defined as part of the base variant of a particular minor version is required to be known by that minor version. This occurs whether the specification happens in the body of the minor definition document or is in a feature definition document that is made part of the minor version by being normatively referenced by the minor version definition document.
o 任何被定义为特定次要版本的基本变体的一部分的协议元素都需要被该次要版本所知道。无论规范发生在次要版本定义文档的正文中，还是在通过次要版本定义文档的规范引用而成为次要版本一部分的特征定义文档中，都会发生这种情况。
o Any protocol element required to be known in a given minor version is required to be known in subsequent minor versions, unless and until a minor version has made that protocol element as mandatory to not implement.
o 在给定的次要版本中需要知道的任何协议元素都需要在后续次要版本中知道，除非次要版本强制该协议元素不实施。
o When a protocol element is defined as part of an extension to an extensible minor version, it is not required to be known in that minor version but is required to be known by the next minor version. In the earlier minor version, it might not be defined in the XDR definition document, while in the later version it needs to be defined in the XDR definition document. In either case, if it is defined, it might or might not be supported.
o 当协议元素被定义为可扩展次要版本的扩展的一部分时，它不需要在该次要版本中已知，但需要在下一次要版本中已知。在早期的次要版本中，它可能未在XDR定义文档中定义，而在更高版本中，它需要在XDR定义文档中定义。在任何一种情况下，如果定义了它，它都可能被支持，也可能不被支持。
o When knowledge of protocol elements is optional in a given minor version, the responder's knowledge of such optional elements must obey the rule that if one such element is known, then all the protocol elements defined in the same minor version definition document must be known as well.
o 当协议元素的知识在给定的次要版本中是可选的时，响应者对此类可选元素的知识必须遵守以下规则：如果已知一个此类元素，则同一次要版本定义文档中定义的所有协议元素也必须已知。
For many minor versions, all existing protocol elements are required 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 protocol elements. This is the case if there has been no extension for the minor version in question. Extensions can be added to extensible minor versions as described in Section 6 and can be used to correct protocol flaws as described in Section 9.
对于许多小版本，客户端和服务器都需要知道所有现有的协议元素，因此请求者不必测试是否有关于协议元素的知识。如果所讨论的次要版本没有扩展，则会出现这种情况。如第6节所述，可将扩展添加到可扩展的次要版本中，并可用于纠正第9节所述的协议缺陷。
Requesters can ascertain the knowledge of the responder in two ways:
请求者可以通过两种方式确定响应者的知识：
o By issuing a request using the protocol element and looking at the response. Note that, even if the protocol element used is not supported by the responder, the requester can still determine if the element is known by the responder.
o 通过使用协议元素发出请求并查看响应。注意，即使响应者不支持所使用的协议元素，请求者仍然可以确定响应者是否知道该元素。
o By receiving a request from the responder, acting in the role of requester. For example, a client may issue a request enabling the server to infer that it is aware of a corresponding callback.
o 以请求者的身份接收响应者的请求。例如，客户机可能发出一个请求，使服务器能够推断它知道相应的回调。
In making this determination, the requester can rely on two basic facts:
在作出这一决定时，请求者可以依据两个基本事实：
o If the responder is aware of a single protocol element within a feature package, it must be aware of all protocol elements within that feature package.
o 如果响应者知道功能包中的单个协议元素，那么它必须知道该功能包中的所有协议元素。
o If a protocol element is one defined by the minor version specified by a request (and not in an extension), or in a previous minor version, the responder must be aware of it.
o 如果协议元素是由请求指定的次要版本（不在扩展中）或以前的次要版本定义的，则响应者必须知道它。
When a client and a server interact, they need to able to take advantage of the compatibility provided by NFSv4's use of XDR extension.
当客户端和服务器交互时，它们需要能够利用NFSv4使用XDR扩展提供的兼容性。
In this context, the client and server would arrive at a common variant, which the client uses to send requests that the server would then accept. The server would use that variant to send callbacks that the client would then accept. This state of affairs could arise in a number of ways:
在此上下文中，客户机和服务器将达成一个通用变量，客户机使用该变量发送请求，然后服务器将接受该请求。服务器将使用该变量发送回调，然后客户端将接受该回调。这种情况可能以多种方式出现：
o Client and server have been built using XDR variants that belong to the same minor version.
o 客户机和服务器是使用属于同一次要版本的XDR变体构建的。
o The client's minor version is lower than that of the server. In this case the server, in accord with Section 8.2, accepts the client's minor version, and acts as if it has no knowledge of extensions made in subsequent minor versions. It has knowledge of protocol elements within the current (i.e., effectively final) variant of the lower minor version.
o 客户端的次要版本低于服务器的次要版本。在这种情况下，根据第8.2节，服务器接受客户机的次要版本，其行为就好像它不知道在后续次要版本中进行的扩展一样。它了解下级版本的当前（即有效的最终）变体中的协议元素。
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 minor version that the server will accept. In this case, the server has no knowledge of extensions made in subsequent minor versions.
o 客户端的次要版本高于服务器的次要版本。在这种情况下，根据第8.2节，客户机使用服务器将接受的较低版本。在这种情况下，服务器不知道后续次要版本中的扩展。
There are a number of cases to consider based on the characteristics of the minor version chosen.
根据所选择的次要版本的特点，有许多情况需要考虑。
o When the minor version consists of only a single variant (no extension or XDR corrections), the client and the server are using the same XDR description and have knowledge of the same protocol elements.
o 当次要版本仅包含一个变体（无扩展或XDR更正）时，客户端和服务器使用相同的XDR描述，并且了解相同的协议元素。
o When the minor version consists of multiple variants (i.e., there are one or more XDR extensions or XDR corrections), the client and the server are using compatible XDR descriptions. The client is aware of some set of extensions while the server may be aware of a different set. The client can use the approach described in 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 server will both be using a common variant. The variants that the client and the server were built with will both either be identical to this variant or a valid extension of it. Similarly, the variants that the client and the server actually use will be a subset of this variant, in that certain OPTIONAL features will not be used.
o 当次要版本包含多个变体（即有一个或多个XDR扩展或XDR更正）时，客户端和服务器使用兼容的XDR描述。客户端知道一些扩展集，而服务器可能知道另一个扩展集。客户端可以使用第4.4.3节中描述的方法来确定它知道的哪些扩展也是服务器知道的。完成此操作后，客户端和服务器都将使用一个通用变量。构建客户机和服务器时使用的变量要么与此变量相同，要么是其有效扩展。类似地，客户机和服务器实际使用的变体将是该变体的子集，因为某些可选特性将不被使用。
In either case, the client must determine which of the OPTIONAL protocol elements within the common version are supported by the server, just as it does for OPTIONAL features introduced as part of a 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.
最好是客户机实现在处理用户请求之前确定服务器提供的支持。这包括确定共同协议变量和对任择议定书要素的支持程度。
A requester may test the responder's knowledge of particular protocol 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 that 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.
请求者可以基于协议元素的类型，测试响应者对如下定义的特定协议元素的知识。请注意，在属性或标志位的情况下，使用引用2个或更多未确定状态位（“已知”与“未知”）的请求可能会返回没有特别帮助的结果。在这种情况下，当响应为NFS4ERR_INVAL时，请求者只能得出至少一个比特未知的结论。
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 GETATTR returns with the error NFS4ERR_INVAL, then it can be concluded that the responder has no knowledge of the attribute in question. Other responses, including NFS4ERR_ATTRNOTSUPP, indicate that the responder is aware of the attribute in question.
o 当发出GETATTR请求，指定要测试的属性位，并且该属性不是仅设置的属性时，如果GETATTR返回错误NFS4ERR_INVAL，则可以得出结论，响应者不知道所讨论的属性。其他响应，包括NFS4ERR_ATTRNOTSUPP，表明响应者知道有问题的属性。
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 SETATTR returns with the error NFS4ERR_INVAL, then it can be concluded that the responder has no knowledge of the attribute in question. Other responses, including NFS4ERR_ATTRNOTSUPP, indicate that the responder is aware of the attribute in question.
o 当发出SETATTR请求，指定要测试的属性位，并且该属性不是get only属性时，如果SETATTR返回错误NFS4ERR_INVAL，则可以断定响应者不知道该属性。其他响应，包括NFS4ERR_ATTRNOTSUPP，表明响应者知道有问题的属性。
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 generally be concluded that the responder has no knowledge of the flag bit in question, as long as the requester is careful to avoid 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 当发出包括具有新标志位的操作的请求时，如果该操作返回错误NFS4ERR_INVAL，则通常可以得出响应者不知道所述标志位的结论，只要请求者小心避免其他错误情况，在这些情况下，相关操作被定义为返回NFS4ERR_INVAL。其他响应表明响应者知道有问题的标志位。
o When a request is made including the operation to be tested, if the responder returns an RPC XDR decode error, or a response indicating that the operation in question resulted in NFS4ERR_OP_ILLEGAL or NFS4ERR_BADXDR, then it can be concluded that the responder has no knowledge of the operation in question. Other responses, including NFS4ERR_NOTSUPP, indicate that the responder is aware of the operation in question.
o 当发出包括要测试的操作的请求时，如果响应者返回RPC XDR解码错误，或指示所述操作导致NFS4ERR_OP_非法或NFS4ERR_BADXDR的响应，则可以得出结论，响应者不知道所述操作。其他响应，包括NFS4ERR_NOTSUPP，表明响应者知道有问题的操作。
o When a request is made including the switch arm to be tested, if the responder returns an RPC XDR decode error, or a response indicating that the operation in question resulted in NFS4ERR_BADXDR, then it can be concluded that the responder has no knowledge of the operation in question. Other responses, including NFS4ERR_UNION_NOTSUPP, indicate that the responder is aware of the protocol element in question.
o 当发出包括要测试的开关臂在内的请求时，如果响应者返回RPC XDR解码错误，或指示所述操作导致NFS4ERR_BADXDR的响应，则可以断定响应者不知道所述操作。其他响应，包括NFS4ERR_UNION_NOTSUPP，表明响应者知道有问题的协议元素。
A determination of the knowledge or lack of knowledge of a particular protocol element is expected to remain valid as long as the clientid associated with the request remains valid.
只要与请求相关联的clientid保持有效，对特定协议元素的知识或缺乏知识的确定就有望保持有效。
The above assumes, as should be the case, that the server will accept the minor version used by the client. For more detail regarding this issue, see Section 8.2.
上述假设（应该是这样的）服务器将接受客户端使用的次要版本。有关此问题的更多详细信息，请参见第8.2节。
XDR additions may also be made by defining XDR structures that overlay nominally opaque fields that are defined to allow such incremental extensions.
XDR的添加也可以通过定义XDR结构来实现，该结构覆盖了名义上不透明的字段，这些字段被定义为允许这种增量扩展。
For example, each parallel NFS (pNFS) mapping type provides its own XDR definition for various pNFS-related fields defined in [RFC5661] as opaque arrays.
例如，每种并行NFS（pNFS）映射类型都为[RFC5661]中定义为不透明数组的各种pNFS相关字段提供自己的XDR定义。
Because such additions provide new interpretations of existing fields, they may be made outside of the extension framework as long as they obey the rules previously established when the nominally opaque protocol elements were added to the protocol.
由于此类添加提供了对现有字段的新解释，因此只要它们遵守先前在将名义上不透明的协议元素添加到协议中时建立的规则，就可以在扩展框架之外进行添加。
There are a number of types of protocol changes that are outside the XDR extension framework discussed in Section 4. These changes are also managed within the NFSv4 versioning framework and may be of a number of types, which are discussed in the sections below.
在第4节讨论的XDR扩展框架之外，有许多类型的协议更改。这些更改也在NFSv4版本控制框架内进行管理，可能有多种类型，将在以下各节中讨论。
Despite the previous emphasis on XDR changes, additions and changes to the NFSv4 protocols have not been limited to those that involve changes (in the form of extensions) to the protocol XDR. Examples of other sorts of changes have been taken from NFSv4.1.
尽管先前强调XDR变更，但NFSv4协议的添加和变更并不限于涉及XDR协议变更（以扩展形式）的内容。NFSv4.1中提供了其他类型更改的示例。
All such changes that have been made in the past have been made as part of new minor version. Future change of these sorts may not be done in an extension but can only be made in a new minor version.
过去所做的所有这些更改都是作为新的次要版本的一部分进行的。这些类型的未来更改可能不会在扩展中完成，但只能在新的次要版本中进行。
The XDR description of a protocol does not constitute a complete description of the protocol. Therefore, versioning needs to consider the role of changes in the use of fields, even when there is no change to the underlying XDR.
协议的XDR描述并不构成协议的完整描述。因此，版本控制需要考虑字段使用中的更改的作用，即使对底层XDR没有更改。
Although any XDR element is potentially subject to a change in its interpretation and use, the likelihood of such change will vary with the XDR-specified type of the element, as discussed below:
尽管任何XDR元件的解释和使用可能会发生变化，但这种变化的可能性将因XDR指定的元件类型而异，如下所述：
o When XDR elements are defined as strings, rules regarding the appropriate string values are specified in protocol specification text with changes in such rules documented in minor version definition documents. Some types of strings within NFS4 are used in server names (in location-related attributes), user and group names, and in the names of file objects within directories. Rules regarding what strings are acceptable appear in [RFC7530] and [RFC5661] with the role of the XDR limited to hints regarding UTF-8 and capitalization issues via XDR typedefs.
o 当XDR元素定义为字符串时，在协议规范文本中指定关于适当字符串值的规则，并在次要版本定义文档中记录此类规则的更改。NFS4中的某些类型的字符串用于服务器名称（位置相关属性）、用户名和组名以及目录中文件对象的名称。[RFC7530]和[RFC5661]中出现了关于哪些字符串是可接受的规则，XDR的角色仅限于通过XDR typedefs提示UTF-8和大写问题。
o Fields that are XDR-defined as opaque elements and that are truly opaque, do not raise versioning issues, except as regards inter-version use, which is effectively foreclosed by the rules in Section 8.1.
o XDR定义为不透明元素且真正不透明的字段不会引起版本控制问题，但版本间使用除外，第8.1节中的规则实际上阻止了这一点。
Note that sometimes a field will seem to be opaque but not actually be fully opaque when considered carefully. For example, the "other" field of stateids is defined as an opaque array, while the specification text specially defines appropriate treatment when the "other" field within it is either all zeros or all ones. Given this context, creation or deletion of reserved values for "special" stateids will be a protocol change that versioning rules need to deal with.
请注意，当仔细考虑时，有时字段看起来是不透明的，但实际上并非完全不透明。例如，stateID的“other”字段定义为不透明数组，而规范文本特别定义了当其中的“other”字段为全零或全1时的适当处理。在这种情况下，创建或删除“特殊”StateID的保留值将是版本控制规则需要处理的协议更改。
o Some nominally opaque elements have external XDR definitions that overlay the nominally opaque arrays. Such cases are discussed in Section 4.5.
o 一些名义上不透明的元素具有覆盖名义上不透明数组的外部XDR定义。第4.5节讨论了此类情况。
Changes in the behavior of NFSv4 operations are possible, even if there is no change in the underlying XDR or change to field interpretation and use.
NFSv4操作行为的改变是可能的，即使底层XDR或字段解释和使用没有改变。
One class of behavioral change involves changes in the set of errors to be returned when various failure conditions occur. When the set of valid requests remain the same, and the behavior for each of them remains the same, such changes can be implemented with only limited disruption to existing clients.
一类行为变化涉及在各种故障条件发生时返回的错误集的变化。当有效请求集保持不变，并且每个请求的行为保持不变时，可以在对现有客户机进行有限中断的情况下实现此类更改。
Many more substantial behavioral changes have occurred in connection with the addition of the session concept in NFSv4.1. Even though there was no change to the XDR for existing operations, many existing operations and COMPOUNDs consisting only of them became invalid.
在NFSv4.1中添加会话概念后，发生了更多实质性的行为变化。尽管对现有操作的XDR没有任何更改，但许多现有操作和仅由它们组成的复合操作都变得无效。
Also, changes were made regarding the required server behavior as to the interaction of the MODE and Access Control List (ACL) attributes.
此外，还对模式和访问控制列表（ACL）属性的交互所需的服务器行为进行了更改。
Extensions to the most recently published NFSv4 minor version may be made by publishing the extension as a Proposed Standard, unless the minor version in question has been defined as non-extensible. A document need not use the "Updates" header specifying the RFC that defines the minor version, which remains a valid description of the base variant of the minor version in question.
对最近发布的NFSv4次要版本的扩展可通过将该扩展发布为建议的标准来实现，除非相关次要版本被定义为不可扩展。文档无需使用“更新”标题来指定定义次要版本的RFC，该RFC仍然是相关次要版本的基本变量的有效描述。
In addition to following the rules for XDR extensions in Section 4.2, such extensions must also obey the rules listed below in order to allow interoperability to be established, as described in Section 4.4:
除了遵守第4.2节中的XDR扩展规则外，此类扩展还必须遵守以下规则，以便建立互操作性，如第4.4节所述：
o Additions to the set of callback requests and extensions to the XDR for existing callback operations can only be made if the server can determine, based on the client's actions, that the client is aware of the changes. This determination, for any particular client (as defined by its clientid), is made before sending those new or extended callbacks.
o 只有在服务器能够根据客户机的操作确定客户机知道这些更改的情况下，才能为现有回调操作向XDR添加回调请求集和扩展。对于任何特定的客户端（由其clientid定义），在发送这些新的或扩展的回调之前进行此确定。
o XDR extensions that affect the structures of responses to existing operations can only be made if the server can determine, based on the client's actions, that it is aware of the existence of XDR changes, before sending responses containing those extensions. This determination can be based on the request being responded to, but that is not required. Use of any protocol element defined in the extension can be the basis of the determination, provided that the requirements for determining client awareness are clearly stated.
o 只有在服务器能够根据客户端的操作确定它在发送包含这些扩展的响应之前知道存在XDR更改的情况下，才能进行影响对现有操作的响应结构的XDR扩展。此确定可以基于响应的请求，但这不是必需的。使用扩展中定义的任何协议元素可以作为确定的基础，前提是明确说明确定客户意识的要求。
Corrections to protocol errors (see Section 9) may be accomplished by publishing an extension, including a compatible XDR change that follows the rules above. Such documents will update the defining documents for the minor version to be corrected.
协议错误的更正（见第9节）可以通过发布扩展来完成，包括遵循上述规则的兼容XDR更改。此类文件将更新待纠正次要版本的定义文件。
In some cases, extensions will contain elements such as new operations or previously invalid switch cases. Although it is possible to determine whether these OPTIONAL elements are supported using the rules described above, those defining an extension that contains such elements have the choice of defining a new attribute that indicates whether the feature is present and supported. Since it is easy to determine whether a new attribute is supported using
在某些情况下，扩展将包含诸如新操作或以前无效的开关情况之类的元素。尽管可以使用上述规则确定是否支持这些可选元素，但是那些定义包含这些元素的扩展的人可以选择定义一个新属性，该属性指示是否存在和支持该功能。因为使用
the supported_attrs attribute, this can make it simple and convenient for clients to determine whether support is present, particularly when a feature involves support for multiple such elements.
通过supported_attrs属性，客户端可以简单方便地确定是否存在支持，特别是当一个功能涉及对多个此类元素的支持时。
It is important to note that this section, in describing situations that would require new minor versions to be created, does not thereby imply that situations will exist in the future. Judgments regarding desirability of future changes will be made by the working group or its successors and any guidance that can be offered at this point is necessarily quite limited.
需要注意的是，本节在描述需要创建新的次要版本的情况时，并不意味着将来会存在这种情况。工作组或其继任者将对未来变更的可取性作出判断，此时可提供的任何指导必然十分有限。
Creation of a new minor version is an option that the working group retains. The listing of situations below that would prompt such actions is not meant to be exhaustive.
创建新的次要版本是工作组保留的一种选择。下面列出的可能促使采取此类行动的情况并非详尽无遗。
The following sorts of features are not allowed as extensions and would require creation of a new minor version:
以下种类的功能不允许作为扩展，需要创建新的次要版本：
o Features that incorporate any of the non-XDR-based changes discussed in Sections 5.1 and 5.2.
o 包含第5.1节和第5.2节中讨论的任何非XDR变更的功能。
o Features whose XDR changes do not follow the rules in Section 6.
o XDR更改不符合第6节规则的功能。
o Addition of REQUIRED new features.
o 添加所需的新功能。
o Changes to the status of existing features including converting features to be mandatory to not implement.
o 对现有功能状态的更改，包括将功能转换为强制不实施。
This section addresses issues related to rules #11 and #13 in the minor versioning rules in [RFC5661]. With regard to the supersession of minor versioning rules, the treatment here overrides that in [RFC5661] when either of the potentially interacting minor versions has not yet been published as a Proposed Standard.
本节讨论与[RFC5661]中次要版本控制规则中的规则#11和#13相关的问题。关于次要版本控制规则的替代，当潜在交互次要版本中的任何一个尚未作为提议的标准发布时，此处的处理方法优先于[RFC5661]中的处理方法。
Note that these rules are the only ones directed to minor version implementers, rather than to those specifying new minor versions.
请注意，这些规则是唯一针对次要版本实现者的规则，而不是针对那些指定新次要版本的规则。
Each relationship between a client instance and a server instance, as represented by a clientid, is to be devoted to a single minor version. If a server detects that a COMPOUND with an inappropriate minor version is being used, it MUST reject the request. In doing so, it may return either NFS4ERR_BAD_CLIENTID or NFS4RR_MINOR_VERS_MISMATCH.
客户端实例和服务器实例之间的每个关系（由clientid表示）都将专用于一个次要版本。如果服务器检测到正在使用具有不适当次要版本的化合物，则必须拒绝该请求。这样做时，它可能返回NFS4ERR_BAD_CLIENTID或NFS4RR_MINOR_VERS_不匹配。
As a result of the above, the client has the assurance that the set of REQUIRED and OPTIONAL features will not change within the context of a single clientid. Server implementations MUST ensure that the set of supported features and protocol elements does not change within such a context.
由于上述原因，客户可以保证所需和可选功能集不会在单个clientid的上下文中更改。服务器实现必须确保受支持的功能和协议元素集在这样的上下文中不会更改。
The goal of the NFSv4 extension model is to enable compatibility including compatibility between clients and servers implementing different minor versions.
NFSv4扩展模型的目标是实现兼容性，包括实现不同次要版本的客户端和服务器之间的兼容性。
Within a set of minor versions that define the same set of features as REQUIRED and mandatory to not implement, it is relatively easy for clients and servers to provide the needed compatibility by adhering to the following practices:
在一组次要版本中，通过遵循以下实践，客户机和服务器可以相对容易地提供所需的兼容性，这些次要版本定义了所需且强制不实施的同一组功能：
o Servers supporting a given minor version should support earlier minor versions within that set and return appropriate errors for use of protocol elements that were not a valid part of that earlier minor version. For details, see below.
o 支持给定次要版本的服务器应支持该集合中的早期次要版本，并为使用不属于该早期次要版本有效部分的协议元素返回适当的错误。有关详细信息，请参见下文。
o Clients should deal with an NFS4ERR_MINOR_VERS_MISMATCH error by searching for a lower minor version number that the server will accept.
o 客户端应通过搜索服务器将接受的较低次要版本号来处理NFS4ERR_MINOR_VERS_不匹配错误。
Servers supporting a given minor version MUST, in returning errors for operations that were a valid part of the minor version, return the errors allowed for the current operation in the minor version actually being used.
支持给定次要版本的服务器在为作为次要版本有效部分的操作返回错误时，必须返回实际使用的次要版本中当前操作允许的错误。
With regard to protocol elements not known in a given minor version, the appropriate error codes are given below. Essentially, the 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.
对于给定次要版本中未知的协议元素，下面给出了相应的错误代码。从本质上讲，服务器虽然有一个更广泛的XDR来反映较新的次要版本，但它必须充当一个XDR更有限的服务器。
o When an operation is used that is not known in the specified minor version, NFS4ERR_OP_ILLEGAL (as opposed to NFS4ERR_NOTSUPP) should be returned.
o 当使用指定次要版本中未知的操作时，应返回NFS4ERR_OP_非法（与NFS4ERR_NOTSUPP相反）。
o When an attribute is used that is not known in the specified minor version, NFS4ERR_INVAL (as opposed to NFS4ERR_ATTRNOTSUPP) should be returned.
o 当使用指定次要版本中未知的属性时，应返回NFS4ERR_INVAL（与NFS4ERR_ATTRNOTSUPP相反）。
o When a switch case is used that is not known in the specified minor version, NFS4ERR_BADXDR (as opposed to NFS4ERR_UNION_NOTSUPP) should be returned. Even though the message may be XDR-decodable by the server's current XDR, it is not so according to the minor version being used.
o 当使用指定次要版本中未知的开关情况时，应返回NFS4ERR_BADXDR（与NFS4ERR_UNION_NOTSUPP相反）。即使消息可以由服务器的当前XDR进行XDR解码，但根据所使用的次要版本，情况并非如此。
o When a flag bit is used that is not known in the specified minor version, NFS4ERR_INVAL (as opposed to NFS4ERR_NOTSUPP or any other error defined as indicating non-support of a flag bit) should be returned.
o 当使用指定次要版本中未知的标志位时，应返回NFS4ERR_INVAL（与NFS4ERR_NOTSUPP或定义为不支持标志位的任何其他错误相反）。
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 a minor version containing it, as a Proposed Standard. While the working group can reduce the probability of such situations arising by waiting for running code before considering a feature as done, it cannot reduce the probability to zero. As features are used more extensively and interact with other features, previously unseen flaws may be discovered and will need to be corrected.
在接受现有特征或包含该特征的次要版本作为建议标准后，可能始终存在需要以某种方式纠正现有特征的可能性。虽然工作组可以通过在考虑某个特性之前等待运行代码来降低出现这种情况的概率，但它不能将概率降低到零。随着功能的广泛使用以及与其他功能的交互，可能会发现以前未发现的缺陷，需要进行纠正。
Such corrections are best done in a document obsoleting or updating the RFC defining the relevant feature or minor version. In making such corrections, the working group will have to carefully consider how to assure interoperability with older clients and servers.
此类更正最好在淘汰或更新RFC（定义相关功能或次要版本）的文件中完成。在进行此类更正时，工作组将不得不仔细考虑如何确保与较老的客户端和服务器的互操作性。
Often, corrections can be done without changing the protocol XDR. In many cases, a change in client and server behavior can be implemented without taking special provision with regard to interoperability with earlier implementations. In those cases, and in cases in which a revision merely clarifies an earlier protocol definition document, a new document can be published that simply updates the earlier protocol definition document.
通常，可以在不更改协议XDR的情况下进行更正。在许多情况下，可以实现客户机和服务器行为的更改，而无需对与早期实现的互操作性作出特殊规定。在这些情况下，以及在修订仅澄清早期协议定义文件的情况下，可以发布一份新文件，仅更新早期协议定义文件。
In other cases, it is best if client or server behavior needs to change in a way that raises interoperability concerns. In such cases, incompatible changes in server or client behavior should not be mandated in order to avoid XDR changes.
在其他情况下，最好是客户机或服务器的行为需要以引起互操作性问题的方式进行更改。在这种情况下，不应强制执行服务器或客户端行为中的不兼容更改，以避免XDR更改。
When XDR changes are necessary as part of correcting a flaw, these should be done in a manner similar to that used when implementing new minor versions or features within them. In particular:
当XDR更改作为纠正缺陷的一部分是必要的时，这些更改应以类似于在其中实现新的次要版本或功能时使用的方式进行。特别地：
o Existing XDR structures may not be modified or deleted.
o 不能修改或删除现有XDR结构。
o XDR extensions may be used to correct existing protocol facilities in a manner similar to those used to add additional optional features. Such corrections may be done in a minor version for which optional features may no longer be added, if the working group decides that it is an appropriate way to compatibly effect a correction.
o XDR扩展可用于纠正现有协议设施，其方式与用于添加附加可选功能的方式类似。如果工作组认为这是一种适当的方式，可以兼容地进行更正，则可以在次要版本中进行此类更正，不再添加可选功能。
o When a correction is made to an OPTIONAL feature, the result is similar to a situation in which there are two independent OPTIONAL features. A server may choose to implement either or both. See Section 9.2 for a detailed discussion of interoperability issues.
o 对可选特征进行校正时，结果类似于存在两个独立可选特征的情况。服务器可以选择实现其中一个或两个。有关互操作性问题的详细讨论，请参见第9.2节。
o When a correction is made to a REQUIRED feature, the situation becomes one in which the old version of the feature remains REQUIRED while the corrected version, while OPTIONAL, is intended to be adopted to provide correct operation. Although use of the corrected version is ultimately better and may be recommended, it should not be described as "RECOMMENDED" since the choice of versions to support will depend on the needs of clients, which 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 both support the corrected version. See Section 9.3 for details.
o 当对所需特性进行修正时，情况变为仍需要旧版本的特性，而修正版本（可选）旨在提供正确的操作。虽然使用更正版本最终会更好，并且可能会被推荐，但不应将其描述为“推荐”，因为选择支持的版本将取决于客户的需求，而客户的需求可能会缓慢地采用更新版本。此类更正的性质是，可能导致相同次要版本的不同变体可能不同时支持更正版本的情况。详见第9.3节。
o In all of the cases above, it is appropriate that the old version of the feature be considered obsolescent, with the expectation that the working group might, in a later minor version, change the status of the uncorrected version. See Section 9.4 for more detail.
o 在上述所有情况下，适当的做法是将该特征的旧版本视为已过时，并期望工作组可以在以后的次要版本中更改未修正版本的状态。详见第9.4节。
By defining the corrected and uncorrected version as independent OPTIONAL features, the protocol with the XDR modification can accommodate clients and servers that support either the corrected or the uncorrected version of the protocol, and also clients and servers aware of and capable of supporting both alternatives.
通过将校正版本和未校正版本定义为独立的可选功能，经过XDR修改的协议可以容纳支持校正版本或未校正版本协议的客户端和服务器，以及知道并能够支持这两种备选方案的客户端和服务器。
Based on the type of client:
根据客户端的类型：
o A client that uses only the earlier version of the feature (i.e., an older unfixed client) can determine whether the server it is connecting to supports the older version of feature. It is capable of interoperating with older servers that support only the unfixed protocol as well as ones that support both versions.
o 仅使用早期版本的功能的客户端（即，较旧的未固定客户端）可以确定其连接的服务器是否支持早期版本的功能。它能够与仅支持非固定协议的旧服务器以及同时支持两个版本的服务器进行互操作。
o A client that supports only the corrected version of the feature (i.e., a new or updated client) can determine whether the server it is connecting to supports the newer version of the feature. It is capable of interoperating with newer servers that support only the updated feature as well as ones that support both versions.
o 仅支持功能的更正版本的客户端（即新的或更新的客户端）可以确定其连接的服务器是否支持功能的更新版本。它能够与仅支持更新功能的较新服务器以及同时支持两个版本的服务器进行互操作。
o A client that supports both the older and newer version of the feature can determine which version of the particular feature is supported by the server it is working with.
o 同时支持旧版本和新版本功能的客户端可以确定其所使用的服务器支持特定功能的哪个版本。
Based on the type of server:
根据服务器的类型：
o A server that supports only the earlier version of the feature (i.e., an older unfixed server) can only successfully interoperate with clients implementing the older version. However, clients that do not implement the older version of the feature can easily determine that the feature cannot be used on that server.
o 仅支持该功能的早期版本的服务器（即，较旧的未固定服务器）只能成功地与实现较旧版本的客户端进行互操作。但是，未实现旧版本功能的客户端可以轻松确定该功能无法在该服务器上使用。
o A server that supports only the newer version of the feature (i.e., a new or updated server) can only successfully interoperate with newer clients. However, older clients can easily determine that the feature cannot be used on that server. In the case of OPTIONAL features, clients can be expected to deal with non-support of that particular feature.
o 仅支持较新版本的功能的服务器（即，新的或更新的服务器）只能成功地与较新的客户端进行互操作。但是，较旧的客户端可以轻松确定该功能无法在该服务器上使用。在可选功能的情况下，可以期望客户端处理不支持该特定功能的情况。
o A server that supports both the older and newer versions of the feature can interoperate with all client variants.
o 支持该功能的旧版本和新版本的服务器可以与所有客户端变体进行互操作。
By using extensions in this manner, the protocol creates a clear path that preserves the functioning of existing clients and servers and allows client and server implementers to adopt the new version of the feature at a reasonable pace.
通过以这种方式使用扩展，协议创建了一条清晰的路径，该路径保留了现有客户机和服务器的功能，并允许客户机和服务器实现者以合理的速度采用新版本的功能。
Interoperability issues in this case are similar to those for the OPTIONAL case described above (in Section 9.2). However, because the use of the uncorrected version is REQUIRED, servers have to support this until there is a minor version change. Nevertheless, there is the opportunity for clients and servers to implement the corrected
这种情况下的互操作性问题类似于上述可选情况下的互操作性问题（见第9.2节）。但是，由于需要使用未更正的版本，服务器必须支持此操作，直到出现较小的版本更改。尽管如此，客户机和服务器仍有机会实现正确的
version, while maintaining necessary interoperability with earlier implementations.
版本，同时与早期实现保持必要的互操作性。
The following types of servers can exist:
可以存在以下类型的服务器：
o Servers only aware of and supporting the uncorrected version, such as servers developed before the issue requiring correction was known.
o 服务器只知道并支持未更正的版本，例如在知道需要更正的问题之前开发的服务器。
o Servers aware of both versions while only supporting the uncorrected version.
o 服务器知道这两个版本，但只支持未更正的版本。
o Servers aware of and supporting both versions.
o 服务器知道并支持这两个版本。
With the exception of clients that do not use the feature in question, the following sorts of clients may exist:
除不使用相关功能的客户端外，可能存在以下类型的客户端：
o Clients only aware of and prepared to use the uncorrected version, such as those developed before the issue requiring correction was known.
o 客户只知道并准备使用未更正的版本，例如在需要更正的问题已知之前开发的版本。
Clients developed before the correction was defined would be of this type. They would be capable of interoperating with all of the types of servers listed above, but could not use the corrected version.
在定义更正之前开发的客户将属于这种类型。他们将能够与上面列出的所有类型的服务器进行互操作，但无法使用正确的版本。
o Clients aware of both versions while only prepared to use the uncorrected version.
o 客户端知道这两个版本，但只准备使用未更正的版本。
Some clients developed or modified after the correction was defined would be of this type, until they were modified to support the corrected version. They would also be capable of interoperating with all of the types of servers listed above, but could not use the corrected version.
定义更正后开发或修改的某些客户端将属于此类型，直到它们被修改以支持更正版本。他们还可以与上面列出的所有类型的服务器进行互操作，但不能使用正确的版本。
o Clients aware of and prepared to use either version.
o 客户了解并准备使用任一版本。
Such clients would be capable of interoperating with all of the types of servers listed above, and could use the corrected version with servers that supported it.
这样的客户端将能够与上面列出的所有类型的服务器进行互操作，并且可以将正确的版本与支持它的服务器一起使用。
o Clients aware of both versions while only prepared to use the newer, corrected version.
o 客户端知道这两个版本，但只准备使用更新的、已更正的版本。
Such clients would only be capable of interoperating with servers that supported the corrected version. With other types of servers, they could determine the absence of appropriate support at an early stage and treat the minor version in question as
这样的客户端只能与支持正确版本的服务器进行互操作。对于其他类型的服务器，他们可以在早期确定是否缺少适当的支持，并将有问题的次要版本视为
unsupported by the server. Such clients are only likely to be deployed when the majority of servers support the corrected version.
服务器不支持。只有在大多数服务器支持正确版本时，才可能部署此类客户端。
As described in Sections 9.2 and 9.3, a corrected XDR can be incorporated in an existing minor version and be used, while an existing uncorrected version is still supported. Nevertheless, the uncorrected version will remain part of the protocol until its status is changed in a later minor version.
如第9.2节和第9.3节所述，修正后的XDR可并入现有次要版本并使用，而现有未修正版本仍受支持。尽管如此，未修正版本仍将是协议的一部分，直到其状态在以后的次要版本中更改。
One possible change that could be made in a later minor version is to define the uncorrected version as mandatory to not implement. Because of the difficulty of determining that no clients depend on support for the uncorrected version, it is unlikely that this step would be appropriate for a considerable time.
在以后的次要版本中可能进行的一个更改是将未修改的版本定义为强制不执行。由于很难确定没有客户依赖于对未更正版本的支持，因此在相当长的一段时间内，此步骤不太可能是合适的。
In the case of a correction to a REQUIRED feature, there are a number of less disruptive changes that could be made earlier:
在对所需功能进行修正的情况下，可以提前进行一些破坏性较小的更改：
o Changing the uncorrected version from REQUIRED to OPTIONAL while REQUIRING that servers support at least one of the two versions.
o 将未更正的版本从必需更改为可选，同时要求服务器至少支持两个版本中的一个。
This would allow new server implementations to avoid support for the uncorrected version.
这将允许新的服务器实现避免对未更正版本的支持。
o Changing the corrected version from OPTIONAL to REQUIRED, making both versions REQUIRED.
o 将更正版本从可选更改为必需，使两个版本都必需。
This would allow new clients to depend on support for the corrected version being present.
这将允许新客户机依赖于对当前已更正版本的支持。
o Changing the uncorrected version from REQUIRED to OPTIONAL while changing the corrected version from OPTIONAL to REQUIRED.
o 将未更正版本从必需更改为可选，同时将更正版本从可选更改为必需。
This would complete the shift to the corrected version once clients are prepared to use the corrected version.
一旦客户准备好使用更正版本，这将完成到更正版本的转换。
In making such changes, interoperability issues would need to be carefully considered.
在进行此类更改时，需要仔细考虑互操作性问题。
Since no substantive protocol changes are proposed here, no security considerations apply.
由于此处未提出任何实质性协议更改，因此不适用任何安全考虑。
The current document does not require any IANA actions.
当前文档不需要任何IANA操作。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, <http://www.rfc-editor.org/info/rfc5661>.
[RFC5661]Shepler，S.，Ed.，Eisler，M.，Ed.，和D.Noveck，Ed.，“网络文件系统（NFS）版本4次要版本1协议”，RFC 5661，DOI 10.17487/RFC5661，2010年1月<http://www.rfc-editor.org/info/rfc5661>.
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, March 2015, <http://www.rfc-editor.org/info/rfc7530>.
[RFC7530]Haynes，T.，Ed.和D.Noveck，Ed.，“网络文件系统（NFS）第4版协议”，RFC 7530，DOI 10.17487/RFC7530，2015年3月<http://www.rfc-editor.org/info/rfc7530>.
[RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, November 2016, <http://www.rfc-editor.org/info/rfc7862>.
[RFC7862]Haynes，T.，“网络文件系统（NFS）版本4次要版本2协议”，RFC 7862，DOI 10.17487/RFC7862，2016年11月<http://www.rfc-editor.org/info/rfc7862>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<http://www.rfc-editor.org/info/rfc8174>.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, DOI 10.17487/RFC3530, April 2003, <http://www.rfc-editor.org/info/rfc3530>.
[RFC3530]Shepler，S.，Callaghan，B.，Robinson，D.，Thurlow，R.，Beame，C.，Eisler，M.，和D.Noveck，“网络文件系统（NFS）版本4协议”，RFC 3530，DOI 10.17487/RFC3530，2003年4月<http://www.rfc-editor.org/info/rfc3530>.
Acknowledgements
致谢
The author wishes to thank Tom Haynes of Primary Data for his role in getting the effort to revise NFSV4 version management started and for his work in coauthoring the first draft version of this document.
作者希望感谢Primary Data的Tom Haynes，感谢他在开始修订NFSV4版本管理方面所起的作用，感谢他在共同编写本文档初稿方面所做的工作。
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 other versioning-related documents.
作者还想感谢Oracle的Chuck Lever和Mike Kupfer，以及Red Hat的Bruce Fields，感谢他们对本文档和其他版本控制相关文档的有益评论。
Author's Address
作者地址
David Noveck NetApp 1601 Trapelo Road Waltham, MA 02451 United States of America
David Noveck NetApp美国马萨诸塞州沃尔瑟姆特拉佩罗路1601号，邮编02451
Phone: +1 781 572 8038
Email: davenoveck@gmail.com
Phone: +1 781 572 8038
Email: davenoveck@gmail.com