Internet Engineering Task Force (IETF) W. Adamson
Request for Comments: 8000 NetApp
Category: Standards Track N. Williams
ISSN: 2070-1721 Cryptonector
November 2016
Internet Engineering Task Force (IETF) W. Adamson
Request for Comments: 8000 NetApp
Category: Standards Track N. Williams
ISSN: 2070-1721 Cryptonector
November 2016
Requirements for NFSv4 Multi-Domain Namespace Deployment
NFSv4多域命名空间部署的要求
Abstract
摘要
This document presents requirements for the deployment of the NFSv4 protocols for the construction of an NFSv4 file namespace in environments with multiple NFSv4 Domains. To participate in an NFSv4 multi-domain file namespace, the server must offer a multi-domain-capable file system and support RPCSEC_GSS for user authentication. In most instances, the server must also support identity-mapping services.
本文档介绍了在具有多个NFSv4域的环境中构建NFSv4文件命名空间的NFSv4协议的部署要求。要参与NFSv4多域文件命名空间，服务器必须提供支持多域的文件系统，并支持RPCSEC_GSS进行用户身份验证。在大多数情况下，服务器还必须支持身份映射服务。
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/rfc8000.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8000.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Federated File System . . . . . . . . . . . . . . . . . . . . 5
4. Identity Mapping . . . . . . . . . . . . . . . . . . . . . . 6
4.1. NFSv4 Server Identity Mapping . . . . . . . . . . . . . . 6
4.2. NFSv4 Client Identity Mapping . . . . . . . . . . . . . . 7
5. Stand-Alone NFSv4 Domain Deployment Examples . . . . . . . . 7
5.1. AUTH_SYS with Stringified UID/GID . . . . . . . . . . . . 7
5.2. AUTH_SYS with Name@domain . . . . . . . . . . . . . . . . 8
5.3. RPCSEC_GSS with Name@domain . . . . . . . . . . . . . . . 8
6. Multi-Domain Constraints to the NFSv4 Protocol . . . . . . . 9
6.1. Name@domain Constraints . . . . . . . . . . . . . . . . . 9
6.1.1. NFSv4 Domain and DNS Services . . . . . . . . . . . . 9
6.1.2. NFSv4 Domain and Name Services . . . . . . . . . . . 10
6.2. RPC Security Constraints . . . . . . . . . . . . . . . . 10
6.2.1. NFSv4 Domain and Security Services . . . . . . . . . 11
7. Stand-Alone Examples in an NFSv4 Multi-Domain Deployment . . 11
8. Resolving Multi-Domain Authorization Information . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Federated File System . . . . . . . . . . . . . . . . . . . . 5
4. Identity Mapping . . . . . . . . . . . . . . . . . . . . . . 6
4.1. NFSv4 Server Identity Mapping . . . . . . . . . . . . . . 6
4.2. NFSv4 Client Identity Mapping . . . . . . . . . . . . . . 7
5. Stand-Alone NFSv4 Domain Deployment Examples . . . . . . . . 7
5.1. AUTH_SYS with Stringified UID/GID . . . . . . . . . . . . 7
5.2. AUTH_SYS with Name@domain . . . . . . . . . . . . . . . . 8
5.3. RPCSEC_GSS with Name@domain . . . . . . . . . . . . . . . 8
6. Multi-Domain Constraints to the NFSv4 Protocol . . . . . . . 9
6.1. Name@domain Constraints . . . . . . . . . . . . . . . . . 9
6.1.1. NFSv4 Domain and DNS Services . . . . . . . . . . . . 9
6.1.2. NFSv4 Domain and Name Services . . . . . . . . . . . 10
6.2. RPC Security Constraints . . . . . . . . . . . . . . . . 10
6.2.1. NFSv4 Domain and Security Services . . . . . . . . . 11
7. Stand-Alone Examples in an NFSv4 Multi-Domain Deployment . . 11
8. Resolving Multi-Domain Authorization Information . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
The NFSv4 protocols NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], and NFSv4.2 [RFC7862] introduce the concept of an NFS Domain. An NFSv4 Domain is defined as a set of users and groups using the NFSv4 name@domain user and group identification syntax with the same specified @domain.
NFSv4协议NFSv4.0[RFC7530]、NFSv4.1[RFC5661]和NFSv4.2[RFC7862]引入了NFS域的概念。NFSv4域定义为使用NFSv4的一组用户和组name@domain具有相同指定@domain的用户和组标识语法。
Previous versions of the NFS protocol, such as NFSv3 [RFC1813], use the UNIX-centric user identification mechanism of numeric user and group ID for the uid3 and gid3 [RFC1813] file attributes and for identity in the authsys_parms AUTH_SYS credential defined in the Open Network Computing (ONC) Remote Procedure Call (RPC) protocol [RFC5531]. Section 6.1 of [RFC2624] notes that the use of UNIX-centric numeric IDs limits the scale of NFS to large local work groups. UNIX-centric numeric IDs are not unique across NFSv3 deployments and so are not designed for Internet scaling achieved by taking into account multiple naming domains and multiple naming mechanisms (see Section 6.2). The NFSv4 Domain's use of the name@domain syntax provides this Internet scaling by allowing servers
NFS协议的早期版本，如NFSv3[RFC1813]，对uid3和gid3[RFC1813]文件属性以及开放网络计算（ONC）远程过程调用（RPC）协议[RFC5531]中定义的authsys_parms AUTH_SYS凭据中的标识，使用以UNIX为中心的数字用户和组ID的用户标识机制。[RFC2624]的第6.1节指出，以UNIX为中心的数字ID的使用限制了大型本地工作组的NFS规模。以UNIX为中心的数字ID在NFSv3部署中不是唯一的，因此不适合通过考虑多个命名域和多个命名机制实现的Internet扩展（请参见第6.2节）。NFSv4域对name@domain语法通过允许服务器来提供这种Internet扩展
and clients to translate between the external name@domain string representation to a local or internal numeric (or other identifier) representation, which matches internal implementation needs.
和客户之间的外部翻译name@domain将字符串表示形式转换为本地或内部数字（或其他标识符）表示形式，这与内部实现需要相匹配。
Multi-domain deployments require support for unique identities across the deployment's name services and security services, as well as the use of multi-domain file systems capable of the on-disk representation of identities belonging to multiple NFSv4 Domains. The name@domain syntax can provide unique identities and thus enables the NFSv4 multi-domain file namespace.
多域部署需要跨部署的名称服务和安全服务支持唯一标识，以及使用能够在磁盘上表示属于多个NFSv4域的标识的多域文件系统。这个name@domain语法可以提供唯一标识，从而启用NFSv4多域文件命名空间。
Unlike previous versions of NFS, the NFSv4 protocols define a referral mechanism (Section 8.4.3 of [RFC7530]) that allows a single server or a set of servers to present a multi-server namespace that encompasses file systems located on multiple servers. This enables the establishment of site-wide, organization-wide, or even a truly global file namespace.
与以前版本的NFS不同，NFSv4协议定义了一种引用机制（参见[RFC7530]第8.4.3节），该机制允许单个服务器或一组服务器呈现包含位于多个服务器上的文件系统的多服务器命名空间。这样就可以建立站点范围、组织范围甚至真正的全局文件命名空间。
The NFSv4 protocols' name@domain syntax and referral mechanism along with the use of RPCSEC_GSS security mechanisms enables the construction of an NFSv4 multi-domain file namespace.
NFSv4协议name@domain语法和引用机制以及RPCSEC_GSS安全机制的使用支持NFSv4多域文件命名空间的构建。
This document presents requirements on the deployment of the NFSv4 protocols for the construction of an NFSv4 file namespace in environments with multiple NFSv4 Domains. To participate in an NFSv4 multi-domain file namespace, the server must offer a multi-domain-capable file system and support RPCSEC_GSS [RFC2203] for user authentication. In most instances, the server must also support identity-mapping services.
本文档介绍了在具有多个NFSv4域的环境中构建NFSv4文件命名空间的NFSv4协议的部署要求。要参与NFSv4多域文件命名空间，服务器必须提供支持多域的文件系统，并支持RPCSEC_GSS[RFC2203]进行用户身份验证。在大多数情况下，服务器还必须支持身份映射服务。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
NFSv4 Domain: A set of users and groups using the NFSv4 name@domain user and group identification syntax with the same specified @domain.
NFSv4域：使用NFSv4的一组用户和组name@domain具有相同指定@domain的用户和组标识语法。
Stand-alone NFSv4 Domain: A deployment of the NFSv4 protocols and NFSv4 file namespace in an environment with a single NFSv4 Domain.
独立NFSv4域：在具有单个NFSv4域的环境中部署NFSv4协议和NFSv4文件命名空间。
Local representation of identity: A representation of a user or a group of users capable of being stored persistently within a file system. Typically, such representations are identical to the form in which users and groups are represented within internal server APIs. Examples are numeric IDs such as a uidNumber (UID), gidNumber (GID) [RFC2307], or a Windows Security Identifier (SID) [CIFS]. In some cases, the identifier space for user and groups overlap, requiring anyone using such an ID to know a priori whether the identifier is for a user or a group.
标识的本地表示：能够在文件系统中持久存储的用户或用户组的表示。通常，这种表示形式与内部服务器API中表示用户和组的形式相同。例如，uidNumber（UID）、gidNumber（GID）[RFC2307]或Windows安全标识符（SID）[CIFS]等数字ID。在某些情况下，用户和组的标识符空间重叠，这要求使用此类ID的任何人事先知道标识符是用于用户还是用于组。
Unique identity: An on-the-wire form of identity that is unique across an NFSv4 multi-domain namespace that can be mapped to a local representation. For example, the NFSv4 name@domain or the Kerberos principal [RFC4120].
唯一标识：在NFSv4多域命名空间中唯一的在线标识形式，可映射到本地表示。例如，NFSv4name@domain或Kerberos主体[RFC4120]。
Multi-domain: In this document, the term "multi-domain" always refers to multiple NFSv4 Domains.
多域：在本文档中，术语“多域”总是指多个NFSv4域。
Multi-domain-capable file system: A local file system that uses a local ID form that can represent NFSv4 identities from multiple domains.
支持多域的文件系统：使用本地ID表单的本地文件系统，可以表示来自多个域的NFSv4标识。
Principal: An RPCSEC_GSS [RFC2203] authentication identity. It is usually, but not always, a user; rarely, if ever, a group; and sometimes a host or server.
主体：RPCSEC_GSS[RFC2203]身份验证标识。它通常是用户，但并不总是用户；很少，如果有的话，是一个群体；有时是主机或服务器。
Authorization Context: A collection of information about a principal such as user name, userID, group membership, etc., used in authorization decisions.
授权上下文：关于主体的信息的集合，如用户名、用户ID、组成员身份等，用于授权决策。
Stringified UID or GID: NFSv4 owner and group strings that consist of decimal numeric values with no leading zeros and that do not contain an '@' sign. See Section 5.9 of [RFC5661].
字符串化UID或GID:NFSv4所有者和组字符串，由无前导零的十进制数值组成，并且不包含“@”符号。见[RFC5661]第5.9节。
Name Service: Facilities that provide the mapping between {NFSv4 Domain, group, or user name} and the appropriate local representation of identity. Also includes facilities providing mapping between a security principal and local representation of identity. Can be applied to unique identities or principals from within local and remote domains. Often provided by a Directory Service such as the Lightweight Directory Access Protocol (LDAP) [RFC4511].
名称服务：提供{NFSv4域、组或用户名}与适当的本地标识表示之间映射的设施。还包括提供安全主体和本地身份表示之间映射的设施。可以应用于本地域和远程域中的唯一标识或主体。通常由轻量级目录访问协议（LDAP）[RFC4511]等目录服务提供。
Name Service Switch (nsswitch): A facility that provides a variety of sources for common configuration databases and name resolution mechanisms.
名称服务交换机（nsswitch）：为通用配置数据库和名称解析机制提供各种源的工具。
FedFS: The Federated File System (FedFS) [RFC5716] describes the requirements and administrative tools to construct a uniform NFSv4 file-server-based namespace that is capable of spanning a whole enterprise and that is easy to manage.
FedFS：联邦文件系统（FedFS）[RFC5716]描述了构建统一的基于NFSv4文件服务器的命名空间的需求和管理工具，该命名空间能够跨越整个企业，并且易于管理。
Domain: This term is used in multiple contexts where it has different meanings. "NFSv4 Domain" and "multi-domain" are defined above.
领域：这个术语在多个上下文中有不同的含义。上文定义了“NFSv4域”和“多域”。
DNS domain: A set of computers, services, or any Internet resource identified by a DNS domain name [RFC1034].
DNS域：由DNS域名[RFC1034]标识的一组计算机、服务或任何Internet资源。
Security realm or domain: A set of configured security providers, users, groups, security roles, and security policies running a single security protocol and administered by a single entity, for example, a Kerberos realm.
安全领域或域：一组配置的安全提供程序、用户、组、安全角色和安全策略，运行单个安全协议，并由单个实体（例如Kerberos领域）管理。
FedFS domain: A file namespace that can cross multiple shares on multiple file servers using file-access protocols such as NFSv4. A FedFS domain is typically a single administrative entity and has a name that is similar to a DNS domain name. Also known as a "Federation".
FedFS域：一个文件命名空间，可以使用文件访问协议（如NFSv4）在多个文件服务器上跨多个共享。FedFS域通常是单个管理实体，其名称与DNS域名类似。也被称为“联邦”。
Administrative domain: A set of users, groups, computers, and services administered by a single entity. Can include multiple DNS domains, NFSv4 Domains, security domains, and FedFS domains.
管理域：由单个实体管理的一组用户、组、计算机和服务。可以包括多个DNS域、NFSv4域、安全域和FedFS域。
The FedFS is the standardized method of constructing and administrating an enterprise-wide NFSv4 file system and is thus referenced in this document. The requirements for multi-domain deployments described in this document apply to all NFSv4 multi-domain deployments, whether or not they are run as a FedFS.
FedFS是构建和管理企业范围的NFSv4文件系统的标准化方法，因此在本文档中引用。本文档中描述的多域部署要求适用于所有NFSv4多域部署，无论它们是否作为FedFS运行。
Stand-alone NFSv4 Domain deployments can be run in many ways. While a FedFS can be run within all stand-alone NFSv4 Domain configurations, some of these configurations (Section 5) are not compatible with joining a multi-domain FedFS namespace.
独立NFSv4域部署可以以多种方式运行。虽然FedFS可以在所有独立NFSv4域配置中运行，但其中一些配置（第5节）与加入多域FedFS命名空间不兼容。
NFSv4 servers deal with two kinds of identities: authentication identities (referred to here as "principals") and authorization identities ("users" and "groups" of users). NFSv4 supports multiple authentication methods, each authenticating an "initiator principal" (typically representing a user) to an "acceptor principal" (always corresponding to the NFSv4 server). NFSv4 does not prescribe how to represent authorization identities on file systems. All file access decisions constitute "authorization" and are made by NFSv4 servers using authorization context information and file metadata related to authorization, such as a file's access control list (ACL).
NFSv4服务器处理两种身份：身份验证身份（此处称为“主体”）和授权身份（“用户”和“用户组”）。NFSv4支持多种身份验证方法，每种方法都将“发起方主体”（通常代表用户）身份验证为“接受方主体”（始终对应于NFSv4服务器）。NFSv4没有规定如何在文件系统上表示授权标识。所有文件访问决策都构成“授权”，由NFSv4服务器使用授权上下文信息和与授权相关的文件元数据（如文件的访问控制列表（ACL））做出。
NFSv4 servers may be required to perform two kinds of mappings depending upon what authentication and authorization information is sent on the wire and what is stored in the exported file system. For example, if an authentication identity such as a Kerberos principal is sent with authorization information such as a "privilege attribute certificate" (PAC) [PAC], then mapping is not required (see Section 8).
NFSv4服务器可能需要执行两种映射，具体取决于在线路上发送的身份验证和授权信息以及在导出的文件系统中存储的信息。例如，如果使用诸如“特权属性证书”（PAC）[PAC]之类的授权信息发送诸如Kerberos主体之类的身份验证标识，则不需要映射（参见第8节）。
1. Auth-to-authz: A mapping between the authentication identity and the authorization context information.
1. Auth to authz：身份验证标识和授权上下文信息之间的映射。
2. Wire-to-disk: A mapping between the on-the-wire authorization identity representation and the on-disk authorization identity representation.
2. 线到磁盘：在线授权标识表示与在线授权标识表示之间的映射。
A name service such as LDAP often provides these mappings.
LDAP等名称服务通常提供这些映射。
Many aspects of these mappings are entirely implementation specific, but some require multi-domain-capable name resolution and security services in order to interoperate in a multi-domain environment.
这些映射的许多方面是完全特定于实现的，但有些方面需要具有多域功能的名称解析和安全服务，以便在多域环境中进行互操作。
NFSv4 servers use these mappings for:
NFSv4服务器将这些映射用于：
1. File access: Both the auth-to-authz and the wire-to-disk mappings may be required for file access decisions.
1. 文件访问：文件访问决策可能需要auth-to-authz和wire-to-disk映射。
2. Metadata setting and listing: The auth-to-authz mapping is usually required to service file metadata setting or listing requests such as ACL or UNIX permission setting or listing. This mapping is needed because NFSv4 messages use identity representations of the form name@domain, which normally differs from the server's local representation of identity.
2. 元数据设置和列表：通常需要auth到authz映射来服务文件元数据设置或列表请求，例如ACL或UNIX权限设置或列表。需要此映射，因为NFSv4消息使用表单的标识表示name@domain，这通常不同于服务器的本地标识表示。
A client setting the owner or group attribute will often need access to identity-mapping services. This is because APIs within the client will specify the identity in a local form (e.g., UNIX using a UID/ GID) so that when stringified id's cannot be used, the ID must be converted to a unique identity form.
设置所有者或组属性的客户端通常需要访问标识映射服务。这是因为客户端中的API将以本地形式指定标识（例如，UNIX使用UID/GID），因此当无法使用字符串化id时，必须将id转换为唯一的标识形式。
A client obtaining values for the owner or group attributes will similarly need access to identity-mapping services. This is because the client API will need these attributes in a local form, as above. As a result, name services need to be available to convert the unique identity to a local form.
获取所有者或组属性值的客户端同样需要访问身份映射服务。这是因为客户端API将需要这些本地形式的属性，如上所述。因此，需要提供名称服务来将唯一标识转换为本地表单。
Note that each of these situations arises because client-side APIs require a particular local identity representation. The need for mapping services would not arise if the clients could use the unique representation of identity directly.
请注意，出现这些情况的原因是客户端API需要特定的本地标识表示。如果客户可以直接使用身份的唯一表示，那么就不需要映射服务。
The purpose of this section is to list some typical stand-alone deployment examples to highlight the need for the required restraints to the NFSv4 protocol, name service configuration, and security service choices in an NFSv4 multi-domain environment described in Section 6.
本节的目的是列出一些典型的独立部署示例，以强调在第6节所述的NFSv4多域环境中对NFSv4协议、名称服务配置和安全服务选择的必要限制。
Section 7 notes how these stand-alone deployment examples would need to change to participate in an NFSv4 multi-domain deployment.
第7节说明了这些独立部署示例需要如何更改以参与NFSv4多域部署。
In order to service as many environments as possible, the NFSv4 protocol is designed to allow administrators freedom to configure their NFSv4 Domains as they please. Stand-alone NFSv4 Domains can be run in many ways.
为了为尽可能多的环境提供服务，NFSv4协议旨在允许管理员自由地配置其NFSv4域。独立NFSv4域可以以多种方式运行。
These examples are for an NFSv4 server exporting a POSIX UID/GID-based file system, a typical deployment. These examples are listed in the order of increasing NFSv4 administrative complexity.
这些示例适用于导出基于POSIX UID/GID的文件系统的NFSv4服务器，这是一种典型的部署。这些示例按NFSv4管理复杂性增加的顺序列出。
This example is the closest NFSv4 gets to being run as NFSv3 as there is no need for a name service for file metadata listing.
这个例子是NFSv4最接近作为NFSv3运行的例子，因为文件元数据列表不需要名称服务。
File access: The AUTH_SYS RPC credential [RFC5531] provides a UID as the authentication identity, and a list of GIDs as authorization context information. File access decisions require no name service interaction as the on-the-wire and on-disk representation are the
文件访问：AUTH_SYS RPC凭证[RFC5531]提供一个UID作为身份验证标识，以及一个GID列表作为授权上下文信息。文件访问决策不需要名称服务交互，因为在线和磁盘表示是
same and the auth-to-authz UID and GID authorization context information is provided in the RPC credential.
RPC凭据中提供了相同的身份验证到身份验证UID和GID授权上下文信息。
Metadata setting and listing: When the NFSv4 clients and servers implement a stringified UID/GID scheme, where a stringified UID or GID is used for the NFSv4 name@domain on-the-wire identity, then a name service is not required for file metadata listing as the UID, or GID can be constructed from the stringified form on the fly by the server.
元数据设置和列表：当NFSv4客户端和服务器实现字符串化UID/GID方案时，其中字符串化UID或GID用于NFSv4name@domain在wire identity上，则文件元数据列表不需要名称服务作为UID，或者服务器可以动态地从字符串化表单构造GID。
Another possibility is to express identity using the form 'name@domain', rather than using a stringified UID/GID scheme for file metadata setting and listing.
另一种可能是使用表单的name@domain，而不是使用字符串化的UID/GID方案来设置和列出文件元数据。
File access: This is the same as in Section 5.1.
文件访问：这与第5.1节相同。
Metadata setting and listing: The NFSv4 server will need to use a name service for the wire-to-disk mappings to map between the on-the-wire name@domain syntax and the on-disk UID/GID representation. Often, the NFSv4 server will use the nsswitch interface for these mappings. A typical use of the nsswitch name service interface uses no domain component, just the UID attribute [RFC2307] (or login name) as the name component. This is not an issue in a stand-alone NFSv4 Domain deployment as the NFSv4 Domain is known to the NFSv4 server and can be combined with the login name to form the name@domain syntax after the return of the name service call.
元数据设置和列表：NFSv4服务器将需要使用线到磁盘映射的名称服务来映射线上的name@domain语法和磁盘上的UID/GID表示形式。通常，NFSv4服务器将使用nsswitch接口进行这些映射。nsswitch名称服务接口的典型用法是不使用域组件，只使用UID属性[RFC2307]（或登录名）作为名称组件。这在独立的NFSv4域部署中不是问题，因为NFSv4域是NFSv4服务器已知的，并且可以与登录名组合以形成name@domain返回名称服务调用后的语法。
RPCSEC_GSS uses Generic Security Service Application Program Interface (GSS-API) [RFC2743] security mechanisms to securely authenticate users to servers. The most common mechanism is Kerberos [RFC4121].
RPCSEC_GSS使用通用安全服务应用程序接口（GSS-API）[RFC2743]安全机制来安全地向服务器验证用户。最常见的机制是Kerberos[RFC4121]。
This final example adds the use of RPCSEC_GSS with the Kerberos 5 GSS security mechanism.
最后一个示例添加了RPCSEC_GSS与Kerberos 5 GSS安全机制的使用。
File Access: The forms of GSS principal names are mechanism specific. For Kerberos, these are of the form principal@REALM. Sometimes authorization context information is delivered with authentication, but this cannot be counted on. Authorization context information not delivered with authentication has timely update considerations (i.e., generally it's not possible to get a timely update). File access decisions therefore require a wire-to-disk mapping of the GSS principal to a UID and an auth-to-authz mapping to obtain the list of GIDs as the authorization context.
文件访问：GSS主体名称的形式是特定于机制的。对于Kerberos，它们的形式如下principal@REALM. 有时，授权上下文信息是通过身份验证传递的，但这是不能指望的。未随身份验证一起提供的授权上下文信息具有及时更新的考虑因素（即，通常不可能获得及时更新）。因此，文件访问决策需要GSS主体到UID的线到磁盘映射和auth到authz映射，以获得GID列表作为授权上下文。
Metadata setting and listing: This is the same as in Section 5.2.
元数据设置和列表：这与第5.2节相同。
Joining NFSv4 Domains under a single file namespace imposes slightly on the NFSv4 administrative freedom. In this section, we describe the required constraints.
在单个文件命名空间下加入NFSv4域对NFSv4的管理自由有轻微的影响。在本节中，我们将描述所需的约束。
NFSv4 uses a syntax of the form "name@domain" (see Section 5.9 of [RFC7530]) as the on-the-wire representation of the "who" field of an NFSv4 access control entry (ACE) for users and groups. This design provides a level of indirection that allows NFSv4 clients and servers with different internal representations of authorization identity to interoperate even when referring to authorization identities from different NFSv4 Domains.
NFSv4使用的语法形式为“name@domain“（参见[RFC7530]第5.9节）作为NFSv4用户和组访问控制条目（ACE）的“谁”字段的在线表示。此设计提供了一种间接级别，允许具有不同内部授权标识表示的NFSv4客户端和服务器进行互操作，即使在引用来自不同NFSv4域的授权标识时也是如此。
Multi-domain-capable sites need to meet the following requirements in order to ensure that NFSv4 clients and servers can map between name@domain and internal representations reliably. While some of these constraints are basic assumptions in NFSv4.0 [RFC7530] and NFSv4.1 [RFC5661], they need to be clearly stated for the multi-domain case.
支持多域的站点需要满足以下要求，以确保NFSv4客户端和服务器可以在name@domain以及可靠的内部表示。虽然其中一些约束是NFSv4.0[RFC7530]和NFSv4.1[RFC5661]中的基本假设，但对于多域情况，需要明确说明。
o The NFSv4 Domain portion of name@domain MUST be unique within the multi-domain namespace. See [RFC5661], Section 5.9 ("Interpreting owner and owner_group") for a discussion on NFSv4 Domain configuration.
o 的NFSv4域部分name@domain在多域命名空间中必须是唯一的。有关NFSv4域配置的讨论，请参见[RFC5661]，第5.9节（“解释所有者和所有者组”）。
o The name portion of name@domain MUST be unique within the specified NFSv4 Domain.
o 名称部分name@domain在指定的NFSv4域中必须是唯一的。
Due to UID and GID collisions, stringified UID/GIDs MUST NOT be used in a multi-domain deployment. This means that multi-domain-capable servers MUST reject requests that use stringified UID/GIDs.
由于UID和GID冲突，在多域部署中不得使用字符串化UID/GID。这意味着支持多域的服务器必须拒绝使用字符串化UID/GID的请求。
Here we address the relationship between NFSv4 Domain name and DNS domain name in a multi-domain deployment.
在这里，我们讨论多域部署中NFSv4域名和DNS域名之间的关系。
The definition of an NFSv4 Domain name, the @domain portion of the name@domain syntax, needs clarification to work in a multi-domain file system namespace. [RFC5661], Section 5.9 loosely defines the NFSv4 Domain name as a DNS domain name. This loose definition for the NFSv4 Domain name is a good one, as DNS domain names are globally unique. As noted in Section 6.1, any choice of NFSv4 Domain name can
NFSv4域名的定义，即name@domain语法，需要澄清才能在多域文件系统命名空间中工作。[RFC5661]，第5.9节将NFSv4域名松散地定义为DNS域名。NFSv4域名的这种松散定义是一个很好的定义，因为DNS域名是全局唯一的。如第6.1节所述，NFSv4域名的任何选择都可以
work within a stand-alone NFSv4 Domain deployment whereas the NFSv4 Domain name is required to be unique across a multi-domain deployment.
在独立的NFSv4域部署中工作，而NFSv4域名在多域部署中必须是唯一的。
A typical configuration is that there is a single NFSv4 Domain that is served by a single DNS domain. In this case, the NFSv4 Domain name can be the same as the DNS domain name.
一个典型的配置是，存在一个由单个DNS域提供服务的单个NFSv4域。在这种情况下，NFSv4域名可以与DNS域名相同。
An NFSv4 Domain can span multiple DNS domains. In this case, one of the DNS domain names can be chosen as the NFSv4 Domain name.
NFSv4域可以跨越多个DNS域。在这种情况下，可以选择其中一个DNS域名作为NFSv4域名。
Multiple NFSv4 Domains can also share a DNS domain. In this case, only one of the NFSv4 Domains can use the DNS domain name, the other NFSv4 Domains must choose another unique NFSv4 Domain name.
多个NFSv4域也可以共享一个DNS域。在这种情况下，只有一个NFSv4域可以使用DNS域名，其他NFSv4域必须选择另一个唯一的NFSv4域名。
As noted in Section 6.1, each name@domain is unique across the multi-domain namespace and maps, on each NFSv4 server, to the local representation of identity used by that server. Typically, this representation consists of an indication of the particular domain combined with the UID/GID corresponding to the name component. To support such an arrangement, each NFSv4 Domain needs to have a single name resolution service capable of converting the names defined within the domain to the corresponding local representation.
如第6.1节所述，每个name@domain在多域命名空间中是唯一的，并在每个NFSv4服务器上映射到该服务器使用的标识的本地表示形式。通常，此表示由特定域的指示和与名称组件对应的UID/GID组成。为了支持这种安排，每个NFSv4域需要有一个能够将域内定义的名称转换为相应本地表示的名称解析服务。
As described in [RFC5661], Section 2.2.1.1 ("RPC Security Flavors"):
如[RFC5661]第2.2.1.1节（“RPC安全特性”）所述：
NFSv4.1 clients and servers MUST implement RPCSEC_GSS. (This requirement to implement is not a requirement to use.) Other flavors, such as AUTH_NONE and AUTH_SYS, MAY be implemented as well.
NFSv4.1客户端和服务器必须实现RPCSEC_GSS。（要实现的要求不是使用的要求。）也可以实现其他风格，如AUTH_NONE和AUTH_SYS。
The underlying RPCSEC_GSS GSS-API [RFC2203] security mechanism used in a multi-domain namespace is REQUIRED to employ a method of cross NFSv4 Domain trust so that a principal from a security service in one NFSv4 Domain can be authenticated in another NFSv4 Domain that uses a security service with the same security mechanism. Kerberos is an example of such a security service.
多域命名空间中使用的底层RPCSEC_GSS GSS-API[RFC2203]安全机制需要采用跨NFSv4域信任的方法，以便一个NFSv4域中的安全服务的主体可以在使用具有相同安全机制的安全服务的另一个NFSv4域中进行身份验证。Kerberos就是这种安全服务的一个例子。
The AUTH_NONE [RFC5531] security flavor can be useful in a multi-domain deployment to grant universal read-only access to public data without any credentials.
AUTH_NONE[RFC5531]安全特性在多域部署中非常有用，可以授予对公共数据的通用只读访问，而无需任何凭据。
The AUTH_SYS security flavor [RFC5531] uses a host-based authentication model where the weakly authenticated host (the NFSv4 client) asserts the user's authorization identities using small integers, uidNumber, and gidNumber [RFC2307] as user and group identity representations. Because this authorization ID representation has no domain component, AUTH_SYS can only be used in a namespace where all NFSv4 clients and servers share a name service as described in [RFC2307]. A shared name service is required because uidNumbers and gidNumbers are passed in the RPC credential; there is no negotiation of namespace in AUTH_SYS. Collisions can occur if multiple name services are used, so AUTH_SYS MUST NOT be used in a multi-domain file system deployment.
AUTH_SYS security flavor[RFC5531]使用基于主机的身份验证模型，其中弱身份验证主机（NFSv4客户端）使用小整数、uidNumber和gidNumber[RFC2307]作为用户和组身份表示来断言用户的授权身份。由于此授权ID表示没有域组件，因此AUTH_SYS只能在所有NFSv4客户端和服务器共享名称服务的命名空间中使用，如[RFC2307]中所述。需要共享名称服务，因为uidNumbers和gidNumbers在RPC凭据中传递；AUTH_SYS中没有名称空间协商。如果使用多个名称服务，可能会发生冲突，因此在多域文件系统部署中不能使用AUTH_SYS。
As noted in Section 6.2 regarding AUTH_NONE, multiple NFSv4 Domain security services are RPCSEC_GSS based with the Kerberos 5 security mechanism being the most commonly (and as of this writing, the only) deployed service.
如第6.2节中关于AUTH_NONE的内容所述，多个NFSv4域安全服务是基于RPCSEC_GSS的，Kerberos 5安全机制是最常见（并且在撰写本文时是唯一）部署的服务。
A single Kerberos 5 security service per NFSv4 Domain with the upper case NFSv4 Domain name as the Kerberos 5 REALM name is a common deployment.
每个NFSv4域使用大写NFSv4域名作为Kerberos 5领域名称的单个Kerberos 5安全服务是一种常见部署。
Multiple security services per NFSv4 Domain is allowed and brings the need of mapping multiple Kerberos 5 principal@REALMs to the same local ID. Methods of achieving this are beyond the scope of this document.
每个NFSv4域允许多个安全服务，因此需要映射多个Kerberos 5principal@REALMs到相同的本地ID。实现此目的的方法超出了本文档的范围。
In this section, we revisit the stand-alone NFSv4 Domain deployment examples in Section 5 and note what is prohibiting them from participating in an NFSv4 multi-domain deployment.
在本节中，我们将回顾第5节中的独立NFSv4域部署示例，并注意禁止他们参与NFSv4多域部署的原因。
Note that because all on-disk identities participating in a stand-alone NFSv4 Domain belong to the same NFSv4 Domain, stand-alone NFSv4 Domain deployments have no requirement for exporting multi-domain-capable file systems. To participate in an NFSv4 multi-domain deployment, all three examples in Section 5 would need to export multi-domain-capable file systems.
请注意，由于参与独立NFSv4域的所有磁盘标识都属于同一个NFSv4域，因此独立NFSv4域部署不需要导出支持多域的文件系统。要参与NFSv4多域部署，第5节中的所有三个示例都需要导出支持多域的文件系统。
Due to the use of AUTH_SYS and stringified UID/GIDs, the first stand-alone deployment example (described in Section 5.1) is not suitable for participation in an NFSv4 multi-domain deployment.
由于使用了AUTH_SYS和字符串化UID/GID，第一个独立部署示例（如第5.1节所述）不适合参与NFSv4多域部署。
The second example (described in Section 5.2) does use the name@domain syntax, but the use of AUTH_SYS prohibits its participation in an NFSv4 multi-domain deployment.
第二个示例（如第5.2节所述）使用name@domain语法，但使用AUTH_SYS禁止其参与NFSv4多域部署。
The third example (described in Section 5.3) can participate in a multi-domain namespace deployment if:
第三个示例（如第5.3节所述）可以参与多域命名空间部署，前提是：
o The NFSv4 Domain name is unique across the namespace.
o NFSv4域名在整个命名空间中是唯一的。
o All exported file systems are multi-domain capable.
o 所有导出的文件系统都支持多域。
o A secure method is used to resolve the remote NFSv4 Domain principal's authorization information from an authoritative source.
o 使用安全方法从权威来源解析远程NFSv4域主体的授权信息。
When an RPCSEC_GSS principal is seeking access to files on an NFSv4 server, after authenticating the principal, the server SHOULD obtain in a secure manner the principal's authorization context information from an authoritative source such as the name service in the principal's NFSv4 Domain.
当RPCSEC_GSS主体寻求访问NFSv4服务器上的文件时，在对主体进行身份验证后，服务器应以安全的方式从权威来源（如主体的NFSv4域中的名称服务）获取主体的授权上下文信息。
In the stand-alone NFSv4 Domain case where the principal is seeking access to files on an NFSv4 server in the principal's home NFSv4 Domain, the server administrator has knowledge of the local policies and methods for obtaining the principal's authorization information and the mappings to local representation of identity from an authoritative source. For example, the administrator can configure secure access to the local NFSv4 Domain name service.
在独立NFSv4域的情况下，主体正在寻求访问主体的主NFSv4域中的NFSv4服务器上的文件，服务器管理员了解用于获取主体授权信息的本地策略和方法，以及从权威来源到本地身份表示的映射。例如，管理员可以配置对本地NFSv4域名服务的安全访问。
In the multi-domain case where a principal is seeking access to files on an NFSv4 server not in the principal's home NFSv4 Domain, the NFSv4 server may be required to contact the remote name service in the principal's NFSv4 Domain. In this case, there is no assumption of:
在多域情况下，主体正在寻求访问不在主体的主NFSv4域中的NFSv4服务器上的文件，NFSv4服务器可能需要联系主体的NFSv4域中的远程名称服务。在这种情况下，不存在以下假设：
o Remote name service configuration knowledge.
o 远程名称服务配置知识。
o The syntax of the remote authorization context information presented to the NFSv4 server by the remote name service for mapping to a local representation.
o 远程名称服务提供给NFSv4服务器的远程授权上下文信息的语法，用于映射到本地表示。
There are several methods the NFSv4 server can use to obtain the NFSv4 Domain authoritative authorization information for a remote principal from an authoritative source. While detailing these methods is beyond the scope of this document, some general methods are listed here.
NFSv4服务器可以使用多种方法从权威源获取远程主体的NFSv4域权威授权信息。虽然详细说明这些方法超出了本文档的范围，但此处列出了一些通用方法。
1. A mechanism-specific GSS-API authorization payload containing credential authorization data such as a "privilege attribute certificate" (PAC) [PAC] or a "principal authorization data" (PAD) [GEN-PAC]. This is the preferred method as the payload is delivered as part of GSS-API authentication, avoids requiring any knowledge of the remote authoritative service configuration, and has a well-known syntax.
1. 特定于机制的GSS-API授权有效负载，包含凭证授权数据，如“特权属性证书”（PAC）[PAC]或“主体授权数据”（PAD）[GEN-PAC]。这是首选方法，因为有效负载是作为GSS-API身份验证的一部分交付的，不需要任何关于远程权威服务配置的知识，并且具有众所周知的语法。
2. When there is a security agreement between the local and remote NFSv4 Domain name services plus regular update data feeds, the NFSv4 server local NFSv4 Domain name service can be authoritative for principals in the remote NFSv4 Domain. In this case, the NFSv4 server makes a query to its local NFSv4 Domain name service just as it does when servicing a local domain principal. While this requires detailed knowledge of the remote NFSv4 Domain name service for the update data feeds, the authorization context information presented to the NFSv4 server is in the same form as a query for a local principal.
2. 当本地和远程NFSv4域名服务以及定期更新数据源之间存在安全协议时，NFSv4服务器本地NFSv4域名服务可以对远程NFSv4域中的主体具有权威性。在这种情况下，NFSv4服务器对其本地NFSv4域名服务进行查询，就像为本地域主体提供服务一样。虽然这需要详细了解更新数据源的远程NFSv4域名服务，但呈现给NFSv4服务器的授权上下文信息的形式与本地主体的查询相同。
3. An authenticated direct query from the NFSv4 server to the principal's NFSv4 Domain authoritative name service. This requires the NFSv4 server to have detailed knowledge of the remote NFSv4 Domain's authoritative name service and detailed knowledge of the syntax of the resultant authorization context information.
3. 从NFSv4服务器到主体的NFSv4域权威名称服务的经过身份验证的直接查询。这要求NFSv4服务器详细了解远程NFSv4域的权威名称服务，并详细了解生成的授权上下文信息的语法。
This RFC discusses security throughout. All the security considerations of the relevant protocols, such as NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], RPCSEC_GSS [RFC2203], GSS-API [RFC4121], LDAP [RFC4511], Requirements for Federated FS [RFC5716], FedFS Namespace Database Protocol [RFC7532], FedFS Administration Protocol [RFC7533], and FedFS Security Addendum [SEC-ADD] apply.
本RFC讨论了整个系统的安全性。相关协议的所有安全注意事项，如NFSv4.0[RFC7530]、NFSv4.1[RFC5661]、RPCSEC_GSS[RFC2203]、GSS-API[RFC4121]、LDAP[RFC4511]、联邦FS要求[RFC5716]、FedFS命名空间数据库协议[RFC7532]、FedFS管理协议[RFC7533]和FedFS安全附录[SEC-ADD]均适用。
Authentication and authorization across administrative domains present security considerations, most of which are treated elsewhere, but we repeat some of them here:
跨管理域的身份验证和授权提供了安全注意事项，其中大部分在别处处理，但我们在此重复其中一些注意事项：
o latency in propagation of revocation of authentication credentials
o 身份验证凭据吊销的传播延迟
o latency in propagation of revocation of authorizations
o 授权撤销的传播延迟
o latency in propagation of granting of authorizations
o 授权授予传播中的延迟
o complications in establishing a complete authorization context for users of a foreign domain (only parts may be available to servers)
o 为外部域的用户建立完整授权上下文的复杂性（服务器只能使用部分）
o privacy considerations in a federated environment
o 联邦环境中的隐私注意事项
Most of these are security considerations of the mechanisms used to authenticate users to servers and servers to users and of the mechanisms used to evaluate a user's authorization context.
其中大多数是用于向服务器验证用户和向用户验证服务器的机制以及用于评估用户授权上下文的机制的安全考虑。
Implementors may be tempted to assume that "realm" (or "issuer") and "NFSv4 Domain" are roughly the same thing, but they are not. Configuration and/or lookup protocols (such as LDAP) and associated schemas are generally required in order to evaluate a user principal's authorization context (see Section 8). In the simplest scheme, a server has access to a database mapping all known principal names to user names whose authorization context can be evaluated using operating system interfaces that deal in user names rather than principal names.
实现者可能会认为“领域”（或“颁发者”）和“NFSv4域”大致相同，但事实并非如此。为了评估用户主体的授权上下文，通常需要配置和/或查找协议（如LDAP）以及相关模式（见第8节）。在最简单的方案中，服务器可以访问将所有已知主体名称映射到用户名的数据库，可以使用处理用户名而不是主体名称的操作系统接口来评估用户名的授权上下文。
Note that clients may also need to evaluate a server's authorization context when using labeled security [RFC7862] (e.g., is the server authorized to handle content at a given security level for the given client process subject label).
请注意，当使用带标签的安全[RFC7862]时，客户端可能还需要评估服务器的授权上下文（例如，服务器是否被授权以给定的客户端进程主题标签的给定安全级别处理内容）。
When the server accepts user credentials from more than one realm, it is important to remember that the server must verify that the client it is talking to has a credential for the name the client has presented the server and that the credential's issuer (i.e., its realm) is allowed to issue it. Usually, the service principal realm authorization function is implemented by the security mechanism, but the implementor should check this.
当服务器接受来自多个领域的用户凭据时，重要的是要记住，服务器必须验证与其对话的客户端是否具有客户端向服务器提供的名称的凭据，以及是否允许凭据的颁发者（即其领域）颁发该凭据。通常，服务主体领域授权功能是通过安全机制实现的，但实现者应该对此进行检查。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，DOI 10.17487/RFC1034，1987年11月<http://www.rfc-editor.org/info/rfc1034>.
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, DOI 10.17487/RFC1813, June 1995, <http://www.rfc-editor.org/info/rfc1813>.
[RFC1813]Callaghan，B.，Pawlowski，B.，和P.Staubach，“NFS版本3协议规范”，RFC 1813，DOI 10.17487/RFC1813，1995年6月<http://www.rfc-editor.org/info/rfc1813>.
[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>.
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, DOI 10.17487/RFC2203, September 1997, <http://www.rfc-editor.org/info/rfc2203>.
[RFC2203]Eisler，M.，Chiu，A.，和L.Ling，“RPCSEC_GSS协议规范”，RFC 2203，DOI 10.17487/RFC2203，1997年9月<http://www.rfc-editor.org/info/rfc2203>.
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, DOI 10.17487/RFC2743, January 2000, <http://www.rfc-editor.org/info/rfc2743>.
[RFC2743]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，DOI 10.17487/RFC2743，2000年1月<http://www.rfc-editor.org/info/rfc2743>.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, DOI 10.17487/RFC4121, July 2005, <http://www.rfc-editor.org/info/rfc4121>.
[RFC4121]Zhu，L.，Jaganathan，K.，和S.Hartman，“Kerberos版本5通用安全服务应用程序接口（GSS-API）机制：版本2”，RFC 4121，DOI 10.17487/RFC4121，2005年7月<http://www.rfc-editor.org/info/rfc4121>.
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, DOI 10.17487/RFC4511, June 2006, <http://www.rfc-editor.org/info/rfc4511>.
[RFC4511]Sermersheim，J.，Ed.，“轻量级目录访问协议（LDAP）：协议”，RFC 4511，DOI 10.17487/RFC45112006年6月<http://www.rfc-editor.org/info/rfc4511>.
[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>.
[CIFS] Microsoft Corporation, "[MS-CIFS]: Common Internet File System (CIFS) Protocol", MS-CIFS v20160714 (Rev 26.0), July 2016.
[CIFS]微软公司，[MS-CIFS]：通用互联网文件系统（CIFS）协议，MS-CIFS v20160714（版本26.0），2016年7月。
[GEN-PAC] Sorce, S., Ed., Yu, T., Ed., and T. Hardjono, Ed., "A Generalized PAC for Kerberos V5", Work in Progress, draft-ietf-krb-wg-general-pac-01, October 2011.
[GEN-PAC]Sorce，S.，Ed.，Yu，T.，Ed.，和T.Hardjono，Ed.，“Kerberos V5的通用PAC”，正在进行的工作，草稿-ietf-krb-wg-general-PAC-01，2011年10月。
[PAC] Brezak, J., "Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for Access Control to Resources", February 2002.
[PAC]Brezak，J.“利用Kerberos票据中的Windows 2000授权数据进行资源访问控制”，2002年2月。
[RFC2307] Howard, L., "An Approach for Using LDAP as a Network Information Service", RFC 2307, DOI 10.17487/RFC2307, March 1998, <http://www.rfc-editor.org/info/rfc2307>.
[RFC2307]Howard，L.，“使用LDAP作为网络信息服务的方法”，RFC 2307，DOI 10.17487/RFC2307，1998年3月<http://www.rfc-editor.org/info/rfc2307>.
[RFC2624] Shepler, S., "NFS Version 4 Design Considerations", RFC 2624, DOI 10.17487/RFC2624, June 1999, <http://www.rfc-editor.org/info/rfc2624>.
[RFC2624]Shepler，S.，“NFS版本4设计注意事项”，RFC 2624，DOI 10.17487/RFC2624，1999年6月<http://www.rfc-editor.org/info/rfc2624>.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, July 2005, <http://www.rfc-editor.org/info/rfc4120>.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC 4120，DOI 10.17487/RFC4120，2005年7月<http://www.rfc-editor.org/info/rfc4120>.
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, May 2009, <http://www.rfc-editor.org/info/rfc5531>.
[RFC5531]Thurlow，R.，“RPC：远程过程调用协议规范版本2”，RFC 5531，DOI 10.17487/RFC5531，2009年5月<http://www.rfc-editor.org/info/rfc5531>.
[RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. Naik, "Requirements for Federated File Systems", RFC 5716, DOI 10.17487/RFC5716, January 2010, <http://www.rfc-editor.org/info/rfc5716>.
[RFC5716]Lentini，J.，Everhart，C.，Ellard，D.，Tewari，R.，和M.Naik，“联邦文件系统的要求”，RFC 5716，DOI 10.17487/RFC5716，2010年1月<http://www.rfc-editor.org/info/rfc5716>.
[RFC7532] Lentini, J., Tewari, R., and C. Lever, Ed., "Namespace Database (NSDB) Protocol for Federated File Systems", RFC 7532, DOI 10.17487/RFC7532, March 2015, <http://www.rfc-editor.org/info/rfc7532>.
[RFC7532]Lentini，J.，Tewari，R.，和C.Lever，编辑，“用于联邦文件系统的命名空间数据库（NSDB）协议”，RFC 7532，DOI 10.17487/RFC7532，2015年3月<http://www.rfc-editor.org/info/rfc7532>.
[RFC7533] Lentini, J., Tewari, R., and C. Lever, Ed., "Administration Protocol for Federated File Systems", RFC 7533, DOI 10.17487/RFC7533, March 2015, <http://www.rfc-editor.org/info/rfc7533>.
[RFC7533]Lentini，J.，Tewari，R.，和C.Lever，编辑，“联邦文件系统的管理协议”，RFC 7533，DOI 10.17487/RFC7533，2015年3月<http://www.rfc-editor.org/info/rfc7533>.
[SEC-ADD] Lever, C., "Federated Filesystem Security Addendum", Work in Progress, draft-cel-nfsv4-federated-fs-security-addendum-06, October 2016.
[SEC-ADD]Lever，C.，“联邦文件系统安全补遗”，正在进行的工作，草稿-cel-nfsv4-Federated-fs-Security-ADPENDATION-062016年10月。
Acknowledgments
致谢
Andy Adamson would like to thank NetApp, Inc., for its funding of his time on this project.
Andy Adamson感谢NetApp，Inc.为他在该项目上花费的时间提供资金。
We thank Chuck Lever, Tom Haynes, Brian Reitz, Bruce Fields, and David Noveck for their review.
我们感谢Chuck Lever、Tom Haynes、Brian Reitz、Bruce Fields和David Noveck的评论。
Authors' Addresses
作者地址
William A. (Andy) Adamson NetApp
威廉A.（安迪）亚当森·内塔普
Email: andros@netapp.com
Email: andros@netapp.com
Nicolas Williams Cryptonector
尼古拉斯·威廉姆斯密码接受器
Email: nico@cryptonector.com
Email: nico@cryptonector.com