[要約] RFC 8587は、NFSバージョン4.0のトランキングのアップデートに関するものであり、NFSv4.0のトランキングの問題を解決するための新しい機能を提案しています。目的は、NFSv4.0のパフォーマンスと信頼性を向上させることです。
Internet Engineering Task Force (IETF) C. Lever, Ed.
Request for Comments: 8587 Oracle
Updates: 7530 D. Noveck
Category: Standards Track NetApp
ISSN: 2070-1721 May 2019
NFS Version 4.0 Trunking Update
NFSバージョン4.0トランキング更新
Abstract
概要
In NFS version 4.0, the fs_locations attribute informs clients about alternate locations of file systems. An NFS version 4.0 client can use this information to handle migration and replication of server file systems. This document describes how an NFS version 4.0 client can also use this information to discover an NFS version 4.0 server's trunking capabilities. This document updates RFC 7530.
NFSバージョン4.0では、fs_locations属性はクライアントにファイルシステムの代替の場所を通知します。 NFSバージョン4.0クライアントは、この情報を使用して、サーバーファイルシステムの移行と複製を処理できます。このドキュメントでは、NFSバージョン4.0クライアントがこの情報を使用してNFSバージョン4.0サーバーのトランキング機能を検出する方法について説明します。このドキュメントはRFC 7530を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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 https://www.rfc-editor.org/info/rfc8587.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8587で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Document Organization . . . . . . . . . . . . . . . . . . . . 6
5. Changes within Section 8 of RFC 7530 . . . . . . . . . . . . 7
5.1. Updated Section "Location Attributes"
(Currently Section 8.1) . . . . . . . . . . . . . . . . . 8
5.2. Updates to "Uses of Location Information"
(Currently Section 8.4) . . . . . . . . . . . . . . . . . 9
5.2.1. Updates to the Introductory Text of the Current
Section 8.4 . . . . . . . . . . . . . . . . . . . . . 9
5.2.2. New Subsection Titled "Trunking Discovery and
Detection" (Becomes Section 8.4.1) . . . . . . . . . 11
5.2.3. New Subsection Titled "Location Attributes and
Selection of Connection Type" (Becomes Section 8.4.2) 12
5.2.4. Updated Section "File System Replication" (Becomes
Section 8.4.3 Retitled "File System Replication and
Trunking" . . . . . . . . . . . . . . . . . . . . . . 12
5.2.5. Updated Section "File System Migration" (Becomes
Section 8.4.4) . . . . . . . . . . . . . . . . . . . 13
5.2.6. New Subsection Titled "Interaction of Trunking,
Migration, and Replication" (Becomes Section 8.4.5) . 14
5.3. Updated Section "Location Entries and Server Identity"
(Section 8.5) . . . . . . . . . . . . . . . . . . . . . . 16
6. Updates to RFC 7530 outside Section 8 . . . . . . . . . . . . 16
7. Updates to the Security Considerations Section of RFC 7530 . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Updates to the References Section in RFC 7530 . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Section Classification . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
The NFS version 4.0 specification [RFC7530] defines a migration feature that enables the transfer of a file system from one server to another without disruption of client activity. There were a number of issues with the original definition of this feature, now resolved with the publication of [RFC7931].
NFSバージョン4.0仕様[RFC7530]は、クライアントのアクティビティを中断することなく、あるサーバーから別のサーバーにファイルシステムを転送できる移行機能を定義しています。この機能の元の定義には多くの問題がありましたが、[RFC7931]の公開で解決されました。
After a migration event, a client must determine whether state recovery is necessary. To do this, it needs to determine whether 1) the source and destination server addresses represent the same server instance, 2) if the client has already established a lease on the destination server for other file systems, and 3) if the destination server instance has lock state for the migrated file system.
移行イベントの後、クライアントは状態の回復が必要かどうかを判断する必要があります。これを行うには、1）送信元サーバーと宛先サーバーのアドレスが同じサーバーインスタンスを表すか、2）クライアントが宛先サーバーで他のファイルシステムのリースを既に確立しているか、および3）宛先サーバーインスタンスかどうかを判別する必要があります。移行されたファイルシステムのロック状態があります。
As part of addressing this need, [RFC7931] introduces trunking into NFS version 4.0 along with a trunking detection mechanism. A trunking detection mechanism enables a client to determine whether two distinct network addresses are connected to the same NFS version 4.0 server instance. Without this knowledge, a client unaware of a trunking relationship between paths it is using simultaneously is likely to become confused in ways described in [RFC7530].
この必要性に対処する一環として、[RFC7931]はトランキング検出メカニズムとともにNFSバージョン4.0へのトランキングを導入します。トランキング検出メカニズムにより、クライアントは、2つの異なるネットワークアドレスが同じNFSバージョン4.0サーバーインスタンスに接続されているかどうかを判別できます。この知識がないと、クライアントが同時に使用しているパス間のトランキング関係を認識していないクライアントは、[RFC7530]で説明されている方法で混乱する可能性があります。
NFSv4.1 was defined with an integral means of trunking detection, which is described in [RFC5661]. NFSv4.0 initially did not have trunking detection; it was added by [RFC7931]. Nevertheless, the use of the concept of server-trunkability is the same in both protocol versions.
NFSv4.1は、[RFC5661]で説明されているトランキング検出の統合手段で定義されました。 NFSv4.0には、最初はトランキング検出がありませんでした。 [RFC7931]によって追加されました。それにもかかわらず、サーバーのトランク能力の概念の使用は、両方のプロトコルバージョンで同じです。
File system migration, replication, and referrals are distinct protocol features. However, it is not appropriate to treat each of these features in isolation. For example, recovery processing of client migration needs to deal with the possibility of multiple server addresses in a returned fs_locations attribute. In addition, the content of the fs_locations attribute, which provides both trunking-related and replication information, may change over repeated retrievals, requiring an integrated description of how clients are to deal with such changes. The issues discussed in the current document relate to the interpretation of the fs_locations attribute and to the proper client and server handling of changes in fs_locations attribute values.
ファイルシステムの移行、レプリケーション、および参照は、個別のプロトコル機能です。ただし、これらの機能を個別に扱うことは適切ではありません。たとえば、クライアント移行の回復処理では、返されたfs_locations属性に複数のサーバーアドレスが含まれる可能性に対処する必要があります。さらに、トランキング関連情報とレプリケーション情報の両方を提供するfs_locations属性の内容は、繰り返し取得されると変わる可能性があり、クライアントがそのような変更に対処する方法の統合された説明が必要になります。現在のドキュメントで説明されている問題は、fs_locations属性の解釈と、fs_locations属性値の変更の適切なクライアントおよびサーバー処理に関連しています。
Therefore, the goals of the current document are as follows:
したがって、現在のドキュメントの目標は次のとおりです。
o To provide NFS version 4.0 with a means of finding addresses that are trunkable with a given address, i.e., trunking discovery, compatible with the means of trunking detection introduced by [RFC7931]. For an explanation of trunking detection and discovery, see Section 3.
o [RFC7931]で導入されたトランキング検出の手段と互換性のある、特定のアドレスでトランキング可能なアドレスを見つける手段、つまりトランキングディスカバリをNFSバージョン4.0に提供すること。トランキングの検出と検出の説明については、セクション3を参照してください。
o To describe how NFS version 4.0 clients are to handle the presence of multiple network addresses associated with the same server when recovering from a replication and migration event.
o 複製および移行イベントからの回復時に、NFSバージョン4.0クライアントが同じサーバーに関連付けられた複数のネットワークアドレスの存在をどのように処理するかを説明します。
o To describe how NFS version 4.0 clients are to handle changes in the contents of returned fs_locations attributes, including those that indicate changes in the responding NFS version 4.0 server's trunking configuration.
o NFSバージョン4.0クライアントが、返されたfs_locations属性の内容の変更（応答するNFSバージョン4.0サーバーのトランキング構成の変更を示すものを含む）をどのように処理するかを説明します。
The current document pursues these goals by presenting a set of updates to [RFC7530], as summarized in Sections 5 and 6.
現在の文書は、セクション5と6に要約されているように、[RFC7530]の一連の更新を提示することにより、これらの目標を追求しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Most of the terms related to handling the fs_locations attribute are appropriately defined in Section 5.1. However, there are a few terminological issues regarding the use of terms outside the context of text updating [RFC7530] that are explained in this section. Note that the definitions of trunking-related terms in Section 5.1 apply throughout this document, including in explanatory sections that will not replace any text in [RFC7530].
fs_locations属性の処理に関連する用語のほとんどは、セクション5.1で適切に定義されています。ただし、このセクションで説明するテキスト更新[RFC7530]のコンテキスト外での用語の使用に関して、いくつかの用語の問題があります。セクション5.1のトランキング関連用語の定義は、[RFC7530]のテキストを置き換えない説明セクションを含め、このドキュメント全体に適用されることに注意してください。
Regarding network addresses and the handling of trunking, we use the following terminology:
ネットワークアドレスとトランキングの処理については、次の用語を使用します。
o Each NFSv4 server is assumed to have a set of IP addresses to which NFSv4 requests may be sent by clients. These are referred to as the server's "network addresses". Access to a specific server network address might involve the use of multiple network ports, since the ports to be used for particular types of connections might be required to be different.
o 各NFSv4サーバーには、クライアントがNFSv4要求を送信できるIPアドレスのセットがあると想定されています。これらは、サーバーの「ネットワークアドレス」と呼ばれます。特定の種類の接続に使用されるポートは異なる必要があるため、特定のサーバーネットワークアドレスへのアクセスには、複数のネットワークポートの使用が含まれる場合があります。
o Clients may establish connections to NFSv4 servers via one of several connection types, supporting the NFSv4 protocol layered on top of an RPC stream transport, as described in [RFC5531], or on top of RPC-over-RDMA, as described in [RFC8166]. The combination of a server network address and a particular connection type is referred to as a "server endpoint".
o クライアントは、いくつかの接続タイプの1つを介してNFSv4サーバーへの接続を確立し、[RFC5531]で説明されているようにRPCストリームトランスポートの上に階層化されたNFSv4プロトコルをサポートするか、[RFC8166]で説明されているようにRPC-over-RDMAの上でサポートします。 。サーバーネットワークアドレスと特定の接続タイプの組み合わせは、「サーバーエンドポイント」と呼ばれます。
o Each network address, when combined with a pathname providing the location of a file system root directory relative to the associated server root filehandle, defines a file system network access path.
o 各ネットワークアドレスは、関連するサーバールートファイルハンドルを基準としたファイルシステムルートディレクトリの場所を提供するパス名と組み合わせると、ファイルシステムネットワークアクセスパスを定義します。
o Two network addresses connected to the same server are said to be server-trunkable. Unlike subsequent NFSv4 minor versions, NFSv4.0 recognizes only a single type of trunking relationship between addresses.
o 同じサーバーに接続されている2つのネットワークアドレスは、サーバートランキング可能であるといいます。後続のNFSv4マイナーバージョンとは異なり、NFSv4.0はアドレス間の単一タイプのトランキング関係のみを認識します。
Discussion of the term "replica" is complicated for a number of reasons. Even though the term is used in explaining the issues in [RFC7530] that need to be addressed in the current document, a full explanation of this term requires explanation of related terms connected to the fs_locations attribute, which is provided in Section 5.1 of the current document.
「レプリカ」という用語の説明は、いくつかの理由で複雑です。この用語は、現在のドキュメントで対処する必要がある[RFC7530]の問題の説明に使用されていますが、この用語の完全な説明には、現在のセクション5.1で提供されているfs_locations属性に関連する関連用語の説明が必要です。資料。
The term is also used in previous documents about NFSv4.0 (i.e., [RFC7530] and [RFC7931]) with a meaning different from that in the current document. In these documents, each replica is identified by a single network access path. However, in the current document, a set of network access paths that have server-trunkable network addresses and the same root-relative file system pathname is considered to be a single replica with multiple network access paths. Although [RFC7931] enables an NFSv4.0 client to determine whether two network addresses are server-trunkable, it never describes the addresses as connected to a single replica, in effect leaving the approach established in [RFC7530].
この用語は、NFSv4.0に関する以前のドキュメント（つまり、[RFC7530]および[RFC7931]）でも使用されており、現在のドキュメントとは意味が異なります。これらのドキュメントでは、各レプリカは単一のネットワークアクセスパスによって識別されます。ただし、現在のドキュメントでは、サーバートランキング可能なネットワークアドレスと同じルート相対ファイルシステムパス名を持つ一連のネットワークアクセスパスは、複数のネットワークアクセスパスを持つ単一のレプリカと見なされます。 [RFC7931]は、NFSv4.0クライアントが2つのネットワークアドレスがサーバートランキング可能かどうかを判断できるようにしますが、単一のレプリカに接続されているとアドレスを記述しないため、事実上[RFC7530]で確立されたアプローチが残されます。
Note that this document, except when explaining problems in [RFC7530], always uses the new definition, including in text intended to replace existing sections of [RFC7530].
このドキュメントは、[RFC7530]で問題を説明する場合を除き、[RFC7530]の既存のセクションを置き換えることを意図したテキストを含め、常に新しい定義を使用することに注意してください。
The sections of the current document are divided into four types based on how they relate to the eventual updating of the NFS version 4.0 specification. Once this update is published, NFS version 4.0 will be specified by multiple documents that need to be read together until such time as a consolidated replacement specification is produced.
現在のドキュメントのセクションは、NFSバージョン4.0仕様の最終的な更新との関係に基づいて、4つのタイプに分かれています。この更新が公開されると、NFSバージョン4.0は、統合された代替仕様が作成されるまで一緒に読む必要がある複数のドキュメントによって指定されます。
o The base specification [RFC7530]
o 基本仕様[RFC7530]
o The migration-related update [RFC7931]
o 移行関連の更新[RFC7931]
o This document [RFC8587]
o このドキュメント[RFC8587]
The section types are as follows. See Appendix A for a classification of each section of the current document.
セクションの種類は次のとおりです。現在のドキュメントの各セクションの分類については、付録Aを参照してください。
o An explanatory section does not contain any material that is meant to update the specification of NFS version 4.0. Such sections may contain an explanation about why and how changes are to be made, but they do not include any text that is to update [RFC7530] or appear in an eventual consolidated document.
o 説明セクションには、NFSバージョン4.0の仕様を更新するための資料は含まれていません。そのようなセクションには、変更が行われる理由と方法についての説明が含まれる場合がありますが、[RFC7530]を更新するテキストや最終的な統合ドキュメントに表示されるテキストは含まれていません。
o A replacement section contains text that is to replace and thus supersede text within [RFC7530] and then appear in an eventual consolidated document. The titles of the replacement sections indicate what section of [RFC7530] is to be replaced.
o 置換セクションには、[RFC7530]内のテキストに置き換わるテキストが含まれるため、最終的に統合されたドキュメントに表示されます。置換セクションのタイトルは、[RFC7530]のどのセクションを置換するかを示しています。
o An additional section contains text that, although not replacing anything in [RFC7530], will be part of the specification of NFS version 4.0 and will be expected to be part of an eventual consolidated document. The titles of the additional sections provide an indication of where the new section would appear when consolidated with [RFC7530].
o 追加のセクションには、[RFC7530]の何も置き換えられないが、NFSバージョン4.0の仕様の一部となり、最終的に統合されるドキュメントの一部となることが期待されるテキストが含まれます。追加セクションのタイトルは、[RFC7530]と統合されたときに新しいセクションが表示される場所を示しています。
o An editing section contains some text that replaces text within [RFC7530], although the entire section will not consist of such text and will include other text as well. Such sections make relatively minor adjustments in the existing NFS version 4.0 specification, which are expected to be reflected in an eventual consolidated document. Generally, such replacement text appears as a quotation, possibly taking the form of an indented set of paragraphs.
o 編集セクションには、[RFC7530]内のテキストを置き換えるテキストが含まれていますが、セクション全体がそのようなテキストで構成されるわけではなく、他のテキストも含まれます。そのようなセクションは、既存のNFSバージョン4.0仕様で比較的マイナーな調整を行います。これは、最終的な統合ドキュメントに反映されることが期待されています。通常、このような置換テキストは引用として表示され、インデントされた一連の段落の形式をとる可能性があります。
Additional and replacement sections sometimes contain references to the "current document" by which RFC 8587 is meant. When those sections are incorporated in a consolidated document, those references will need to be updated to refer to the appropriate sections in that new document.
追加セクションと置換セクションには、RFC 8587が意味する「現在のドキュメント」への参照が含まれている場合があります。これらのセクションが統合ドキュメントに組み込まれている場合、それらの参照は、その新しいドキュメントの適切なセクションを参照するように更新する必要があります。
Most of the updates to [RFC7530] that provide support for trunking using the fs_locations attribute apply to Section 8 ("Multi-Server Namespace") of that document. In the following list, the replacing section refers to its numbering in this document.
fs_locations属性を使用したトランキングのサポートを提供する[RFC7530]の更新のほとんどは、そのドキュメントのセクション8（「マルチサーバー名前空間」）に適用されます。次のリストで、置換セクションは、このドキュメントの番号を参照しています。
o Section 5.1 replaces Section 8.1 ("Location Attributes") of [RFC7530]. The text in the original section has been reorganized and extended to explicitly allow the use of fs_locations to provide trunking-related information that appropriately interacts with the migration, replication, and referral features of fs_locations. Terminology used to describe the interactions is added.
o セクション5.1は、[RFC7530]のセクション8.1（「場所の属性」）を置き換えます。元のセクションのテキストは、fs_locationsの移行、レプリケーション、および参照機能と適切に相互作用するトランキング関連情報を提供するためにfs_locationsの使用を明示的に許可するように再編成および拡張されました。相互作用の説明に使用される用語が追加されています。
o Section 5.2 updates Section 8.4 ("Uses of Location Information") of [RFC7530]. This section comprises the bulk of the updates. Each paragraph of Section 8.4 and its subsections have been reviewed to clarify the provision of trunking-related information using the fs_locations attribute.
o セクション5.2は、[RFC7530]のセクション8.4（「位置情報の使用」）を更新します。このセクションは、更新の大部分で構成されています。セクション8.4およびそのサブセクションの各段落は、fs_locations属性を使用したトランキング関連情報の提供を明確にするために見直されました。
* Section 5.2.1 replaces the introductory material within Section 8.4 of [RFC7530], i.e., the material within Section 8.4 exclusive of subsections.
* セクション5.2.1は、[RFC7530]のセクション8.4内の紹介資料、つまりサブセクションを除いたセクション8.4内の資料を置き換えます。
* Section 5.2.2 is to be added as a new subsection of Section 8.4 before the updated Section 8.4.1 of [RFC7530]. In a consolidated document, it would appear as Section 8.4.1.
* セクション5.2.2は、[RFC7530]のセクション8.4.1の更新前に、セクション8.4の新しいサブセクションとして追加される予定です。統合ドキュメントでは、セクション8.4.1として表示されます。
* Section 5.2.3 is to be added as a new subsection of Section 8.4 before the updated Section 8.4.1 of [RFC7530]. In a consolidated document, it would appear as Section 8.4.2.
* セクション5.2.3は、[RFC7530]のセクション8.4.1の更新前に、セクション8.4の新しいサブセクションとして追加される予定です。統合ドキュメントでは、セクション8.4.2として表示されます。
* Section 5.2.4 replaces Section 8.4.1 ("File System Replication") of [RFC7530]. In a consolidated document, it would appear as Section 8.4.3.
* セクション5.2.4は、[RFC7530]のセクション8.4.1（「ファイルシステムレプリケーション」）を置き換えます。統合ドキュメントでは、セクション8.4.3として表示されます。
* Section 5.2.5 replaces Section 8.4.2 ("File System Migration") of [RFC7530]. In a consolidated document, it would appear as Section 8.4.4.
* セクション5.2.5は、[RFC7530]のセクション8.4.2（「ファイルシステムの移行」）を置き換えます。統合ドキュメントでは、セクション8.4.4として表示されます。
* Section 5.2.6 is to be added as a new subsection of Section 8.4 before Section 8.4.3 of [RFC7530]. In a consolidated document, it would appear as Section 8.4.5, while the existing Section 8.3 would appear as Section 8.4.6.
* [RFC7530]のセクション8.4.3の前に、セクション5.2.6がセクション8.4の新しいサブセクションとして追加されます。統合ドキュメントでは、セクション8.4.5として表示されますが、既存のセクション8.3はセクション8.4.6として表示されます。
o Section 5.3 replaces Section 8.5 ("Location Entries and Server Identity") of [RFC7530]. The last paragraph of the existing section has been removed.
o セクション5.3は、[RFC7530]のセクション8.5（「ロケーションエントリとサーバーID」）を置き換えます。既存のセクションの最後の段落は削除されました。
The fs_locations attribute allows specification of file system locations where the data corresponding to a given file system may be accessed. This attribute represents such file system instances as a server address target (as either a DNS hostname representing one or more network addresses or as a single literal network address) together with the path of that file system within the associated single-server namespace. Individual fs_locations entries can express trunkable addresses, locations of file system replicas on other servers, migration targets, or pure referrals.
fs_locations属性を使用すると、特定のファイルシステムに対応するデータにアクセスできるファイルシステムの場所を指定できます。この属性は、ファイルシステムインスタンスをサーバーアドレスターゲットとして（1つ以上のネットワークアドレスを表すDNSホスト名として、または単一のリテラルネットワークアドレスとして）、関連する単一サーバー名前空間内のファイルシステムのパスと共に表します。個々のfs_locationsエントリは、トランク可能なアドレス、他のサーバー上のファイルシステムレプリカの場所、移行ターゲット、または純粋な参照を表すことができます。
We introduce the following terminology:
以下の用語を紹介します。
o "Trunking" is a situation in which multiple network addresses are connected to the same NFS server. Network addresses connected to the same NFS server instance are said to be "server-trunkable".
o 「トランキング」は、複数のネットワークアドレスが同じNFSサーバーに接続されている状況です。同じNFSサーバーインスタンスに接続されているネットワークアドレスは、「サーバートランキング可能」と呼ばれます。
o "Trunking detection" refers to ways of confirming that two distinct network addresses are connected to the same NFSv4 server instance.
o 「トランキング検出」とは、2つの異なるネットワークアドレスが同じNFSv4サーバーインスタンスに接続されていることを確認する方法を指します。
o Trunking discovery is a process by which a client using one network address can obtain other candidate addresses that are server-trunkable with it.
o トランキングディスカバリは、1つのネットワークアドレスを使用するクライアントが、それによってサーバートランキング可能な他の候補アドレスを取得できるプロセスです。
Regarding terminology relating to GETATTR attributes used in trunking discovery and other multi-server namespace features:
トランキングディスカバリおよびその他のマルチサーバー名前空間機能で使用されるGETATTR属性に関連する用語について：
o Location attributes include only the fs_locations GETATTR attribute.
o ロケーション属性には、fs_locations GETATTR属性のみが含まれます。
o Location entries (fs_location4, defined in [RFC7530], Section 2.2.6) are the individual file system locations in the fs_locations attribute (defined in [RFC7530], Section 2.2.7). A file system location entry designates a set of network addresses to which clients may establish connections. The entry may designate multiple such addresses because the server hostname may map to multiple network addresses and because multiple connection types may be used to communicate with each specified network address. Such addresses provide multiple ways of connecting to a single server.
o場所のエントリ（fs_location4、[RFC7530]、セクション2.2.6で定義）は、fs_locations属性（[RFC7530]、セクション2.2.7で定義）内の個々のファイルシステムの場所です。ファイルシステムの場所のエントリは、クライアントが接続を確立できるネットワークアドレスのセットを指定します。サーバーのホスト名が複数のネットワークアドレスにマップされ、複数の接続タイプを使用して指定された各ネットワークアドレスと通信できるため、エントリはそのような複数のアドレスを指定できます。このようなアドレスは、単一のサーバーに接続する複数の方法を提供します。
Clients use the NFSv4.0 trunking detection mechanism [RFC7931] to confirm that such addresses are connected to the same server. The client can ignore non-confirmed trunking relationships and treat the corresponding addresses as connected to different servers.
クライアントは、NFSv4.0トランキング検出メカニズム[RFC7931]を使用して、そのようなアドレスが同じサーバーに接続されていることを確認します。クライアントは、確認されていないトランキング関係を無視して、対応するアドレスを別のサーバーに接続されているものとして扱うことができます。
o File system location elements are derived from file system location entries. If a file system location entry specifies a network address, there is only a single corresponding location element. When a file system location entry contains a hostname, the client resolves the hostname, producing one file system location element for each of the resulting network addresses. Issues regarding the trustworthiness of hostname resolutions are further discussed in Section 7 of the current document.
o ファイルシステムの場所の要素は、ファイルシステムの場所のエントリから取得されます。ファイルシステムの場所エントリがネットワークアドレスを指定する場合、対応する場所要素は1つだけです。ファイルシステムの場所のエントリにホスト名が含まれている場合、クライアントはホスト名を解決し、結果のネットワークアドレスごとに1つのファイルシステムの場所要素を生成します。ホスト名解決の信頼性に関する問題は、現在のドキュメントのセクション7でさらに説明されています。
o All file system location elements consist of a file system location address, which is the network address of an interface to a server, and an fs_name, which is the location of the file system within the server's pseudo-fs.
o すべてのファイルシステムロケーション要素は、サーバーへのインターフェースのネットワークアドレスであるファイルシステムロケーションアドレスと、サーバーの疑似fs内のファイルシステムのロケーションであるfs_nameで構成されます。
o If the server has no pseudo-fs and only has a single exported file system at the root filehandle, the fs_name may be empty.
o サーバーに疑似fsがなく、ルートファイルハンドルにエクスポートされたファイルシステムが1つしかない場合、fs_nameは空である可能性があります。
The subsections below provide replacement sections for existing sections within Section 8.4 of [RFC7530] or new subsections to be added to that section.
以下のサブセクションは、[RFC7530]のセクション8.4内の既存のセクションの代替セクション、またはそのセクションに追加される新しいサブセクションを提供します。
Together with the possibility of absent file systems, the fs_locations attribute bears file system locations and a number of important facilities that enable reliable, manageable, and scalable data access.
fs_locations属性は、ファイルシステムが存在しない可能性とともに、ファイルシステムの場所と、信頼性が高く、管理しやすく、スケーラブルなデータアクセスを可能にするいくつかの重要な機能を備えています。
When a file system is present on the queried server, this attribute can provide a set of alternate locations that clients may use to access the file system, when necessary. Provision of such alternate file system locations is referred to as "replication" and is further described in Section 5.2.4 of the current document.
照会されたサーバーにファイルシステムが存在する場合、この属性は、必要に応じて、クライアントがファイルシステムへのアクセスに使用できる一連の代替場所を提供できます。このような代替ファイルシステムの場所の提供は「レプリケーション」と呼ばれ、現在のドキュメントのセクション5.2.4でさらに説明されています。
When alternative file system locations are provided, they may represent distinct physical copies of the same file system data or separate NFS server instances that provide access to the same physical file system. Another possible use of the provision of multiple file system location entries is trunking, wherein the file system location entries do not, in fact, represent different servers but rather are distinct network paths to the same server.
別のファイルシステムの場所が提供される場合、それらは同じファイルシステムデータの異なる物理コピー、または同じ物理ファイルシステムへのアクセスを提供する個別のNFSサーバーインスタンスを表す場合があります。複数のファイルシステムロケーションエントリのプロビジョニングの別の可能な使用法はトランキングです。この場合、ファイルシステムロケーションエントリは実際には異なるサーバーを表すのではなく、同じサーバーへの個別のネットワークパスです。
A client may use file system location elements simultaneously to provide higher-performance access to the target file system. This can be done using trunking, although the use of multiple replicas simultaneously is possible. To enable simultaneous access, the client utilizes trunking detection and/or discovery, further described in Section 5.2.2 of the current document, to determine a set of network paths that are server-trunkable with the path currently being used to access the file system. Once this determination is made, requests may be routed across multiple paths using the existing state management mechanism.
クライアントは、ファイルシステムロケーション要素を同時に使用して、ターゲットファイルシステムへのより高性能なアクセスを提供できます。これはトランキングを使用して実行できますが、複数のレプリカを同時に使用することも可能です。同時アクセスを可能にするために、クライアントは、現在のドキュメントのセクション5.2.2でさらに説明されているトランキングの検出や検出を利用して、ファイルシステムへのアクセスに現在使用されているパスでサーバートランキング可能なネットワークパスのセットを決定します。この決定が行われると、既存の状態管理メカニズムを使用して、要求を複数のパスにルーティングできます。
Multiple replicas may also be used simultaneously, typically when accessing read-only datasets. In this case, each replica requires its own state management. The client performs multiple file opens to read the same file content from multiple replicas.
複数のレプリカを同時に使用することもできます。通常、読み取り専用のデータセットにアクセスする場合です。この場合、各レプリカには独自の状態管理が必要です。クライアントは複数のファイルを開いて、複数のレプリカから同じファイルの内容を読み取ります。
When a file system is present and subsequently becomes absent, clients can be given the opportunity to have continued access to their data at an alternative file system location. Transfer of the file system contents to the new file system location is referred to as "migration". The client's responsibilities in dealing with this transition depend on the specific nature of the new access path as well as how and whether data was, in fact, migrated. See Sections 5.2.5 and 5.2.6 of the current document for details.
ファイルシステムが存在し、その後不在になった場合、クライアントには、代替のファイルシステムの場所にあるデータへのアクセスを継続する機会を与えることができます。ファイルシステムのコンテンツを新しいファイルシステムの場所に転送することを「移行」と呼びます。この移行への対処におけるクライアントの責任は、新しいアクセスパスの特定の性質、および実際にデータが移行された方法と方法によって異なります。詳細については、現在のドキュメントのセクション5.2.5および5.2.6を参照してください。
The fs_locations attribute can designate one or more remote file system locations in place of an absent file system. This is known as a "referral". A particularly important case is that of a "pure referral", in which the absent file system has never been present on the NFS server. Such a referral is a means by which a file system located on one server can redirect clients to file systems located on other servers, thus enabling the creation of a multi-server namespace.
fs_locations属性は、存在しないファイルシステムの代わりに1つ以上のリモートファイルシステムの場所を指定できます。これは「参照」と呼ばれます。特に重要なケースは、「純粋な参照」の場合で、存在しないファイルシステムがNFSサーバーに存在したことはありません。このような参照は、1つのサーバーにあるファイルシステムがクライアントを他のサーバーにあるファイルシステムにリダイレクトし、マルチサーバーの名前空間を作成できるようにする手段です。
Because client support for the fs_locations attribute is OPTIONAL, a server may (but is not required to) take action to hide migration and referral events from such clients by acting as a proxy, for example.
fs_locations属性のクライアントサポートは省略可能であるため、サーバーは、たとえばプロキシとして機能することにより、そのようなクライアントからの移行イベントと参照イベントを非表示にするアクションを実行できます（必須ではありません）。
5.2.2. New Subsection Titled "Trunking Discovery and Detection" (Becomes Section 8.4.1)
5.2.2. 「トランキングの検出と検出」というタイトルの新しいサブセクション（セクション8.4.1になります）
"Trunking" is a situation in which multiple distinct network addresses are associated with the same NFS server instance. As a matter of convenience, we say that two network addresses connected to the same NFS server instance are server-trunkable. Section 5.4 of [RFC7931] explains why NFSv4 clients need to be aware of the NFS server identity to manage lease and lock states effectively when multiple connections to the same server exist.
「トランキング」は、複数の異なるネットワークアドレスが同じNFSサーバーインスタンスに関連付けられている状況です。便宜上、同じNFSサーバーインスタンスに接続された2つのネットワークアドレスはサーバートランキング可能であると言います。 [RFC7931]のセクション5.4では、同じサーバーへの複数の接続が存在する場合にリースとロックの状態を効果的に管理するために、NFSv4クライアントがNFSサーバーIDを認識する必要がある理由を説明しています。
"Trunking detection" refers to a way for an NFSv4 client to confirm that two independently acquired network addresses are connected to the same NFSv4 server. Section 5.8 of [RFC7931] describes an OPTIONAL means by which it can be determined whether two network addresses correspond to the same NFSv4.0 server instance. Without trunking detection, an NFSv4.0 client has no other way to confirm that two network addresses are server-trunkable.
「トランキング検出」とは、NFSv4クライアントが2つの個別に取得したネットワークアドレスが同じNFSv4サーバーに接続されていることを確認する方法を指します。 [RFC7931]のセクション5.8は、2つのネットワークアドレスが同じNFSv4.0サーバーインスタンスに対応しているかどうかを判断できるオプションの方法を説明しています。トランキング検出がなければ、NFSv4.0クライアントは2つのネットワークアドレスがサーバートランキング可能であることを確認する他の方法がありません。
In the particular context of NFS version 4.0, trunking detection requires that the client support the uniform client ID string (UCS) approach, described in Section 5.6 of [RFC7931]. Any NFSv4.0 client that supports migration or trunking detection needs to present a uniform client ID string to all NFSv4.0 servers. If it does not do so, it will be unable to perform trunking detection.
NFSバージョン4.0の特定のコンテキストでは、[RFC7931]のセクション5.6で説明されているように、トランキング検出では、クライアントが統一クライアントID文字列（UCS）アプローチをサポートする必要があります。移行またはトランキング検出をサポートするすべてのNFSv4.0クライアントは、すべてのNFSv4.0サーバーに統一されたクライアントID文字列を提示する必要があります。そうしないと、トランキング検出を実行できなくなります。
"Trunking discovery" is the process by which an NFSv4 client, using a hostname or one of an NFSv4 server's network addresses, can obtain other candidate network addresses that are trunkable with the NFSv4 server's network address, i.e., a set of addresses that might be connected to the same NFSv4 server instance. An NFSv4.0 client can discover server-trunkable network addresses in a number of ways:
「トランキングディスカバリ」は、NFSv4クライアントが、ホスト名またはNFSv4サーバーのネットワークアドレスの1つを使用して、NFSv4サーバーのネットワークアドレスでトランク可能な他の候補ネットワークアドレス、つまり、同じNFSv4サーバーインスタンスに接続されている。 NFSv4.0クライアントは、いくつかの方法でサーバートランキング可能なネットワークアドレスを検出できます。
o An NFS server's hostname is provided either at mount time or in a returned file system location entry. A DNS query of this hostname can return more than one network address. The returned network addresses are candidates for trunking.
o NFSサーバーのホスト名は、マウント時に、または返されたファイルシステムの場所のエントリで提供されます。このホスト名のDNSクエリは、複数のネットワークアドレスを返す可能性があります。返されたネットワークアドレスはトランキングの候補です。
o Location entries returned in an fs_locations attribute can specify network addresses. These network addresses are candidates for trunking.
o fs_locations属性で返される場所エントリは、ネットワークアドレスを指定できます。これらのネットワークアドレスはトランキングの候補です。
When there is a means of trunking detection available, an NFSv4.0 client can confirm that a set of network addresses corresponds to the same NFSv4.0 server instance; thus, any of them can be used to access that server.
トランキング検出の手段が利用可能な場合、NFSv4.0クライアントは、ネットワークアドレスのセットが同じNFSv4.0サーバーインスタンスに対応していることを確認できます。したがって、それらのいずれもそのサーバーへのアクセスに使用できます。
5.2.3. New Subsection Titled "Location Attributes and Selection of Connection Type" (Becomes Section 8.4.2)
5.2.3. 「場所の属性と接続タイプの選択」というタイトルの新しいサブセクション（セクション8.4.2になります）
NFS version 4.0 may be implemented using a number of different types of connections:
NFSバージョン4.0は、さまざまなタイプの接続を使用して実装できます。
Stream connections may be used to provide RPC service, as described in [RFC5531].
[RFC5531]で説明されているように、ストリーム接続を使用してRPCサービスを提供できます。
RDMA-capable connections may be used to provide RPC service, as described in [RFC8166].
[RFC8166]で説明されているように、RDMA対応の接続を使用してRPCサービスを提供できます。
Because of the need to support multiple connection types, clients face the issue of determining the proper connection type to use when establishing a connection to a server network address. The fs_locations attribute provides no information to support selection of the connection type. As a result, clients supporting multiple connection types need to attempt to establish a connection on various connection types, allowing it to determine, via a trial-and-error approach, which connection types are supported.
複数の接続タイプをサポートする必要があるため、クライアントは、サーバーネットワークアドレスへの接続を確立するときに使用する適切な接続タイプを決定するという問題に直面します。 fs_locations属性は、接続タイプの選択をサポートする情報を提供しません。その結果、複数の接続タイプをサポートするクライアントは、さまざまな接続タイプで接続を確立しようとする必要があり、試行錯誤のアプローチにより、サポートされている接続タイプを判別できます。
If a client strongly prefers one connection type, it can perform these attempts serially in order of declining preference. Once there is a successful attempt, the established connection can be used. Note that with this approach, network partitions can result in a sequence of long waits for a successful connection.
クライアントが1つの接続タイプを強く希望する場合、クライアントはこれらの試行を優先度の高い順にシリアルに実行できます。成功した場合、確立された接続を使用できます。このアプローチでは、ネットワークパーティションが原因で、接続が成功するまで長時間待機する場合があることに注意してください。
To avoid waiting when there is at least one viable network path available, simultaneous attempts to establish multiple connection types are possible. Once a viable connection is established, the client discards less-preferred connections.
使用可能なネットワークパスが少なくとも1つあるときに待機しないように、複数の接続タイプを同時に確立する試みが可能です。実行可能な接続が確立されると、クライアントは優先度の低い接続を破棄します。
5.2.4. Updated Section "File System Replication" (Becomes Section 8.4.3 Retitled "File System Replication and Trunking"
5.2.4. セクション「ファイルシステムレプリケーション」を更新しました（セクション8.4.3に「ファイルシステムレプリケーションとトランキング」というタイトルに変更されました）
On first access to a file system, the client should obtain the value of the set of alternative file system locations by interrogating the fs_locations attribute. Trunking discovery and/or detection can then be applied to the file system location entries to separate the candidate server-trunkable addresses from the replica addresses that provide alternative locations of the file system. Server-trunkable addresses may be used simultaneously to provide higher performance through the exploitation of multiple paths between the client and target file system.
ファイルシステムへの最初のアクセス時に、クライアントは、fs_locations属性を調べることにより、一連の代替ファイルシステムの場所の値を取得する必要があります。次に、トランキング検出および/または検出をファイルシステムロケーションエントリに適用して、候補のサーバートランキング可能なアドレスを、ファイルシステムの代替ロケーションを提供するレプリカアドレスから分離できます。サーバートランキング可能なアドレスを同時に使用して、クライアントとターゲットファイルシステム間の複数のパスを活用することにより、より高いパフォーマンスを提供できます。
In the event that server failure, communication problems, or other difficulties make continued access to the current file system impossible or otherwise impractical, the client can use the alternative file system locations as a way to maintain continued access to the file system. See Section 5.2.6 of the current document for more detail.
サーバーの障害、通信の問題、またはその他の問題により、現在のファイルシステムへの継続的なアクセスが不可能または実用的でない場合、クライアントは代替のファイルシステムの場所を使用して、ファイルシステムへの継続的なアクセスを維持できます。詳細については、現在のドキュメントのセクション5.2.6を参照してください。
When a file system is present and becomes absent, clients can be given the opportunity to have continued access to their data at an alternative file system location specified by the fs_locations attribute. Typically, a client will be accessing the file system in question, get an NFS4ERR_MOVED error, and then use the fs_locations attribute to determine the new location of the data. See Section 5.2.6 of the current document for more detail.
ファイルシステムが存在しなくなった場合、クライアントは、fs_locations属性で指定された代替ファイルシステムの場所にあるデータに引き続きアクセスする機会を与えられます。通常、クライアントは問題のファイルシステムにアクセスし、NFS4ERR_MOVEDエラーを取得してから、fs_locations属性を使用してデータの新しい場所を特定します。詳細については、現在のドキュメントのセクション5.2.6を参照してください。
Such migration can help provide load balancing or general resource reallocation. The protocol does not specify how the file system will be moved between servers. It is anticipated that a number of different server-to-server transfer mechanisms might be used, with the choice left to the server implementer. The NFSv4 protocol specifies the method used to communicate the migration event between the client and server.
このような移行は、負荷分散または一般的なリソースの再割り当てを提供するのに役立ちます。プロトコルは、サーバー間でのファイルシステムの移動方法を指定しません。多数の異なるサーバー間転送メカニズムが使用される可能性があり、その選択はサーバー実装者に任されると予想されます。 NFSv4プロトコルは、クライアントとサーバー間の移行イベントの通信に使用される方法を指定します。
When the client receives indication of a migration event via an NFS4ERR_MOVED error, data propagation to the destination server must have already occurred. Once the client proceeds to access the alternate file system location, it must see the same data. Where file systems are writable, a change made on the original file system must be visible on all migration targets. Where a file system is not writable but represents a read-only copy (possibly periodically updated) of a writable file system, similar requirements apply to the propagation of updates. Any change visible in the original file system must already be effected on all migration targets to avoid any possibility that a client, in effecting a transition to the migration target, will see any reversion in the file system state.
クライアントがNFS4ERR_MOVEDエラーを介して移行イベントの指示を受け取った場合、宛先サーバーへのデータの伝播はすでに発生している必要があります。クライアントが代替ファイルシステムの場所へのアクセスを続行すると、クライアントは同じデータを参照する必要があります。ファイルシステムが書き込み可能である場合、元のファイルシステムで行われた変更は、すべての移行ターゲットで可視である必要があります。ファイルシステムが書き込み可能ではないが、書き込み可能なファイルシステムの読み取り専用コピー（おそらく定期的に更新される）を表す場合、同様の要件が更新の伝達に適用されます。元のファイルシステムに表示される変更はすべて、すべての移行ターゲットで有効になっている必要があります。これにより、クライアントが移行ターゲットに移行するときに、ファイルシステムの状態が元に戻る可能性がなくなります。
5.2.6. New Subsection Titled "Interaction of Trunking, Migration, and Replication" (Becomes Section 8.4.5)
5.2.6. 「トランキング、移行、レプリケーションの相互作用」というタイトルの新しいサブセクション（セクション8.4.5になります）
When the set of network addresses on a server changes in a way that would affect a file system location attribute, there are several possible outcomes for clients currently accessing that file system. NFS4ERR_MOVED is returned only when the server cannot satisfy a request from the client, whether because the file system has been migrated to a different server or is only accessible at a different trunked address on the same server, or for some other reason. In cases 1 and 2 below, NFS4ERR_MOVED is not returned.
サーバー上のネットワークアドレスのセットが、ファイルシステムの場所の属性に影響を与えるような方法で変更された場合、そのファイルシステムに現在アクセスしているクライアントには、いくつかの結果が考えられます。 NFS4ERR_MOVEDが返されるのは、ファイルシステムが別のサーバーに移行されたか、同じサーバー上の別のトランクアドレスでしかアクセスできないため、またはその他の理由で、サーバーがクライアントからの要求を満たせない場合のみです。以下のケース1および2では、NFS4ERR_MOVEDは返されません。
1. When the list of network addresses is a superset of that previously in effect, there is no need for migration or any other sort of client adjustment. Nevertheless, the client is free to use an additional address in the replacement list if that address provides another path to the same server. Alternatively, the client may treat that address as it does a replica -- to be used if the current server addresses become unavailable.
1. ネットワークアドレスのリストが以前有効だったもののスーパーセットである場合、移行やその他のクライアントの調整は必要ありません。それでも、アドレスが同じサーバーへの別のパスを提供する場合、クライアントは置換リストで追加のアドレスを自由に使用できます。または、クライアントはそのアドレスをレプリカと同じように扱い、現在のサーバーアドレスが使用できなくなった場合に使用します。
2. When the list of network addresses is a subset of that previously in effect, immediate action is not needed if an address missing in the replacement list is not currently in use by the client. The client should avoid using that address to access that file system in the future, whether the address is for a replica or an additional path to the server being used.
2. ネットワークアドレスのリストが以前に有効だったもののサブセットである場合、置換リストにないアドレスが現在クライアントによって使用されていない場合は、すぐに対処する必要はありません。クライアントは、アドレスがレプリカ用か使用中のサーバーへの追加パス用かを問わず、将来そのファイルシステムにアクセスするためにそのアドレスを使用することは避けてください。
3. When an address being removed is one of a number of paths to the current server, the client may continue to use it until NFS4ERR_MOVED is received. This is not considered a migration event unless the last available path to the server has become unusable.
3. 削除されるアドレスが現在のサーバーへの多数のパスの1つである場合、クライアントはNFS4ERR_MOVEDを受信するまでそのアドレスを使用し続ける場合があります。これは、サーバーへの最後の使用可能なパスが使用不可にならない限り、移行イベントとは見なされません。
When migration does occur, multiple addresses may be in use on the server prior to migration, and multiple addresses may be available for use on the destination server.
移行が行われると、移行前にサーバーで複数のアドレスが使用されていたり、移行先サーバーで複数のアドレスを使用できる場合があります。
With regard to the server in use, a return of NFS4ERR_MOVED may indicate that a particular network address is no longer to be used, without implying that migration of the file system to a different server is needed. Clients should not conclude that migration has occurred until confirming that all network addresses known to be associated with that server are not usable.
使用中のサーバーに関しては、NFS4ERR_MOVEDが返された場合、ファイルシステムを別のサーバーに移行する必要があることを暗示することなく、特定のネットワークアドレスが使用されなくなったことを示している可能性があります。クライアントは、そのサーバーに関連付けられていることがわかっているすべてのネットワークアドレスが使用できないことを確認するまで、移行が発生したと結論するべきではありません。
It should be noted that the need to defer this determination is not absolute. If a client is not aware of all network addresses for any reason, it may conclude that migration has occurred when it has not and treat a switch to a different server address as if it were a migration event. This is harmless since the use of the same server via a new address will appear as a successful instance of transparent state migration.
この決定を先送りする必要性は絶対的なものではないことに注意すべきです。クライアントが何らかの理由ですべてのネットワークアドレスを認識していない場合、クライアントが認識していないときに移行が発生したと判断し、別のサーバーアドレスへの切り替えを移行イベントであるかのように処理します。新しいアドレスを介した同じサーバーの使用は、透過的な状態移行の正常なインスタンスとして表示されるため、これは無害です。
Although significant harm cannot arise from this misapprehension, it can give rise to disconcerting situations. For example, if a lock has been revoked during the address shift, it will appear to the client as if the lock has been lost during migration. When such a lock is lost, it is the responsibility of the destination server to provide for its recovery via the use of an fs-specific grace period.
この誤解から重大な危害が生じることはありませんが、当惑する状況を引き起こす可能性があります。たとえば、アドレスのシフト中にロックが取り消された場合、クライアントには、移行中にロックが失われたように見えます。このようなロックが失われた場合、fs固有の猶予期間を使用して回復を提供するのは、宛先サーバーの責任です。
With regard to the destination server, it is desirable for the client to be aware of all valid network addresses that can be used to access the destination server. However, there is no need for this to be done immediately. Implementations can process the additional file system location elements in parallel with normal use of the first valid file system location entry found to access the destination.
宛先サーバーに関しては、宛先サーバーへのアクセスに使用できるすべての有効なネットワークアドレスをクライアントが認識することが望ましいです。ただし、これをすぐに実行する必要はありません。実装は、宛先にアクセスするために見つかった最初の有効なファイルシステムロケーションエントリの通常の使用と並行して、追加のファイルシステムロケーションエレメントを処理できます。
Because a file system location attribute may include entries relating to the current server, the migration destination, and possible replicas to use, scanning for available network addresses that might be trunkable with addresses the client has already seen could potentially be a long process. To keep this process as short as possible, servers that provide information about trunkable network paths are REQUIRED to place file system location entries that represent addresses usable with the current server or a migration target before those associated with replicas.
ファイルシステムの場所属性には、現在のサーバー、移行先、および使用可能なレプリカに関連するエントリが含まれる可能性があるため、クライアントがすでに認識しているアドレスとトランク可能である可能性のある利用可能なネットワークアドレスをスキャンすると、長いプロセスになる可能性があります。このプロセスをできるだけ短くするために、トランク可能なネットワークパスに関する情報を提供するサーバーは、現在のサーバーまたは移行ターゲットで使用可能なアドレスを表すファイルシステムロケーションエントリを、レプリカに関連付けられたアドレスシステムの前に配置する必要があります。
This ordering allows a client to cease scanning for trunkable file system location entries once it encounters a file system location element whose fs_name differs from the current fs_name or whose address is not server-trunkable with the address it is currently using. Although the possibility exists that a client might prematurely cease scanning for trunkable addresses when receiving a location attribute from an older server that does not follow the ordering constraint above, the harm is expected to be limited since such servers would not be expected to present information about trunkable server access paths.
この順序付けにより、クライアントは、fs_nameが現在のfs_nameと異なるか、または現在使用しているアドレスでサーバートランキングできないファイルシステムロケーション要素に遭遇すると、トランキング可能なファイルシステムロケーションエントリのスキャンを中止できます。上記の順序の制約に従わない古いサーバーからロケーション属性を受信すると、クライアントがトランク可能なアドレスのスキャンを途中で停止する可能性がありますが、そのようなサーバーは、トランク可能なサーバーアクセスパス。
5.3. Updated Section "Location Entries and Server Identity" (Section 8.5)
5.3. セクション「ロケーションエントリとサーバーID」（セクション8.5）を更新
As mentioned above, a single file system location entry may have a server address target in the form of a DNS hostname that resolves to multiple network addresses; it is also possible for multiple file system location entries to have their own server address targets that reference the same server.
上記のように、単一のファイルシステムロケーションエントリには、複数のネットワークアドレスに解決されるDNSホスト名の形式のサーバーアドレスターゲットが含まれる場合があります。複数のファイルシステムの場所のエントリが、同じサーバーを参照する独自のサーバーアドレスターゲットを持つことも可能です。
When server-trunkable addresses for a server exist, the client may assume that for each file system in the namespace of a given server network address, file systems at corresponding namespace locations exist for each of the other server-trunkable network addresses. It may do this even in the absence of explicit listing in fs_locations. Such corresponding file system locations can be used as alternative locations, just as those explicitly specified via the fs_locations attribute.
サーバーのサーバートランキング可能なアドレスが存在する場合、クライアントは、特定のサーバーネットワークアドレスのネームスペース内のファイルシステムごとに、対応するネームスペースの場所にあるファイルシステムが他のサーバートランキング可能なネットワークアドレスごとに存在すると想定できます。 fs_locationsに明示的なリストがない場合でも、これを行うことがあります。このような対応するファイルシステムの場所は、fs_locations属性で明示的に指定されている場所と同じように、代替場所として使用できます。
If a single file system location entry designates multiple server IP addresses, the client should choose a single one to use. When two server addresses are designated by a single file system location entry and they correspond to different servers, this normally indicates some sort of misconfiguration. The client should avoid using such file system location entries when alternatives are available. When they are not, the client should pick one of the IP addresses and use it without using others that are not directed to the same server.
単一のファイルシステムの場所エントリが複数のサーバーIPアドレスを指定している場合、クライアントは使用する単一のIPアドレスを選択する必要があります。 2つのサーバーアドレスが単一のファイルシステムの場所のエントリによって指定され、それらが異なるサーバーに対応している場合、これは通常、ある種の構成ミスを示しています。代替が利用可能な場合、クライアントはそのようなファイルシステムの場所のエントリを使用しないようにする必要があります。そうでない場合、クライアントはIPアドレスの1つを選択し、同じサーバーに向けられていない他のIPアドレスを使用せずにそれを使用する必要があります。
Since the existing description of NFS4ERR_MOVED in Section 13.1.2.4 of [RFC7530] does not take proper account of trunking, it needs to be modified by replacing the first two sentences of the description with the following material:
[RFC7530]のセクション13.1.2.4にあるNFS4ERR_MOVEDの既存の説明では、トランキングが適切に考慮されていないため、説明の最初の2つの文を次の内容に置き換えることにより、変更する必要があります。
The file system that contains the current filehandle object cannot be accessed using the current network address. It may be accessible using other network addresses connected to the same server, it may have been relocated to another server, or it may never have been present.
現在のファイルハンドルオブジェクトを含むファイルシステムは、現在のネットワークアドレスを使用してアクセスできません。同じサーバーに接続されている他のネットワークアドレスを使用してアクセスできる、別のサーバーに再配置されている、または存在していない可能性があります。
The Security Considerations section of [RFC7530] needs the additions below to properly address some aspects of trunking discovery, referral, migration, and replication.
[RFC7530]のセキュリティに関する考慮事項セクションでは、トランキングディスカバリ、参照、移行、レプリケーションのいくつかの側面に適切に対処するために、以下の追加が必要です。
The possibility that requests to determine the set of network addresses corresponding to a given server might be interfered with or have their responses corrupted needs to be taken into account.
特定のサーバーに対応するネットワークアドレスのセットを決定する要求が妨害される可能性、または応答が破損する可能性を考慮する必要があります。
o When DNS is used to convert NFS server hostnames to network addresses and DNSSEC [RFC4033] is not available, the validity of the network addresses returned cannot be relied upon. However, when the client uses RPCSEC_GSS [RFC7861] to access NFS servers, it is possible for mutual authentication to detect invalid server addresses. Other forms of transport layer security (e.g., [RFC8446]) can also offer strong authentication of NFS servers.
o DNSを使用してNFSサーバーのホスト名をネットワークアドレスに変換し、DNSSEC [RFC4033]を使用できない場合、返されるネットワークアドレスの有効性は信頼できません。ただし、クライアントがRPCSEC_GSS [RFC7861]を使用してNFSサーバーにアクセスする場合、相互認証が無効なサーバーアドレスを検出する可能性があります。その他の形式のトランスポート層セキュリティ（[RFC8446]など）も、NFSサーバーの強力な認証を提供できます。
o Fetching file system location information SHOULD be performed using RPCSEC_GSS with integrity protection, as previously explained in the Security Considerations section of [RFC7530]. Making a request of this sort without using strong integrity protection permits corruption during the transit of returned file system location information. The client implementer needs to recognize that using such information to access an NFS server without use of RPCSEC_GSS (e.g., by using AUTH_SYS as defined in [RFC5531]) can result in the client interacting with an unverified network address that is posing as an NFSv4 server.
o [RFC7530]のセキュリティに関する考慮事項セクションで前述したように、ファイルシステムの場所情報のフェッチは、整合性保護を備えたRPCSEC_GSSを使用して実行する必要があります（SHOULD）。強力な整合性保護を使用せずにこの種の要求を行うと、返されたファイルシステムの場所情報の転送中に破損が許可されます。クライアント実装者は、RPCSEC_GSSを使用せずに（たとえば、[RFC5531]で定義されているAUTH_SYSを使用して）そのような情報を使用してNFSサーバーにアクセスすると、クライアントがNFSv4サーバーを装った検証されていないネットワークアドレスと対話する可能性があることを認識する必要があります。 。
o Despite the fact that [RFC7530] REQUIRES "implementations" to provide "support" for the use of RPCSEC_GSS, it cannot be assumed that use of RPCSEC_GSS is always possible between any particular client-server pair.
o [RFC7530]がRPCSEC_GSSの使用に対する「サポート」を提供するには「実装」が必要であるという事実にもかかわらず、RPCSEC_GSSの使用が特定のクライアント/サーバーペア間で常に可能であるとは想定できません。
o Returning only network addresses to a client that has no trusted DNS resolution service can hamper its ability to use RPCSEC_GSS.
o 信頼できるDNS解決サービスを持たないクライアントにネットワークアドレスのみを返すと、RPCSEC_GSSの使用が妨げられる可能性があります。
Therefore, an NFSv4 server SHOULD present file system location entries that correspond to file systems on other servers using only hostnames. This enables the client to interrogate the fs_locations on the destination server to obtain trunking information (as well as replica information) using RPCSEC_GSS with integrity, validating the hostname provided while ensuring that the response has not been corrupted.
したがって、NFSv4サーバーは、ホスト名のみを使用して他のサーバー上のファイルシステムに対応するファイルシステムの場所エントリを提示する必要があります（SHOULD）。これにより、クライアントはRPCSEC_GSSを使用して完全性を備えたトランキング情報（およびレプリカ情報）を取得するために宛先サーバーのfs_locationsに問い合わせ、提供されたホスト名を検証しながら、応答が破損していないことを確認できます。
When RPCSEC_GSS is not available on an NFS server, returned file system location information is subject to corruption during transit and cannot be relied upon. In the case of a client being directed to another server after NFS4ERR_MOVED, this could vitiate the authentication provided by the use of RPCSEC_GSS on the destination. Even when RPCSEC_GSS authentication is available on the destination, this server might validly represent itself as the server to which the client was erroneously directed. Without a way to decide whether the server is a valid one, the client can only determine, using RPCSEC_GSS, that the server corresponds to the hostname provided, with no basis for trusting that server. The client should not use such unverified file system location entries as a basis for migration, even though RPCSEC_GSS might be available on the destination server.
RPCSEC_GSSがNFSサーバーで使用できない場合、返されるファイルシステムの場所情報は転送中に破損する可能性があり、信頼できません。 NFS4ERR_MOVEDの後でクライアントが別のサーバーに転送される場合、これは宛先でのRPCSEC_GSSの使用によって提供される認証を無効にする可能性があります。宛先でRPCSEC_GSS認証が使用可能な場合でも、このサーバーは、クライアントが誤って向けられたサーバーとして、サーバー自体を有効に表す場合があります。サーバーが有効なサーバーであるかどうかを判断する方法がない場合、クライアントは、RPCSEC_GSSを使用して、サーバーが提供されたホスト名に対応していることのみを判別できます。そのサーバーを信頼する根拠はありません。 RPCSEC_GSSが宛先サーバーで使用できる場合でも、クライアントは、このような未検証のファイルシステムの場所のエントリを移行の基礎として使用しないでください。
When a file system location attribute is fetched upon connecting with an NFSv4 server, it SHOULD, as stated above, be done using RPCSEC_GSS with integrity protection.
NFSv4サーバーとの接続時にファイルシステムの場所属性を取得する場合、前述のように、整合性保護を備えたRPCSEC_GSSを使用して行う必要があります（SHOULD）。
When file system location information cannot be protected in transit, the client can subject it to additional filtering to prevent the client from being inappropriately directed. For example, if a range of network addresses can be determined that ensure that the servers and clients using AUTH_SYS are subject to appropriate constraints (such as physical network isolation and the use of administrative controls within the operating systems), then network addresses in this range can be used, with others discarded or restricted in their use of AUTH_SYS.
ファイルシステムの場所情報を転送中に保護できない場合、クライアントはそれを追加のフィルタリングの対象にして、クライアントが不適切に送信されるのを防ぐことができます。たとえば、AUTH_SYSを使用するサーバーとクライアントが適切な制約（物理的なネットワークの分離やオペレーティングシステム内での管理制御の使用など）の対象となることを保証するネットワークアドレスの範囲を決定できる場合、この範囲のネットワークアドレスAUTH_SYSの使用が制限されている他のものを破棄または使用して使用できます。
When neither integrity protection nor filtering is possible, it is best for the client to ignore trunking and replica information or simply not fetch the file system location information for these purposes.
整合性保護もフィルタリングも不可能である場合、クライアントがトランキングおよびレプリカ情報を無視するか、これらの目的でファイルシステムの場所情報をフェッチしないことが最善です。
To summarize considerations regarding the use of RPCSEC_GSS in fetching file system location information, consider the following recommendations for requests to interrogate location information, with interrogation approaches on the referring and destination servers arrived at separately:
ファイルシステムの場所情報を取得する際のRPCSEC_GSSの使用に関する考慮事項を要約するには、場所情報を問い合わせる要求に関する次の推奨事項を考慮してください。参照サーバーと宛先サーバーへの問い合わせ方法は別々に到着します。
o The use of RPCSEC_GSS with integrity protection is RECOMMENDED in all cases, since the absence of integrity protection exposes the client to the possibility of the results being modified in transit.
o 整合性保護がないとRPCSEC_GSSを使用することをお勧めします。整合性保護がないと、クライアントは転送中に結果が変更される可能性があるためです。
o The use of requests issued without RPCSEC_GSS (e.g., using AUTH_SYS), while undesirable, might be unavoidable in some cases. Where the use of returned file system location information cannot be avoided, it should be subject to filtering to eliminate untrusted network addresses. The specifics will vary depending on the degree of network isolation and whether the request is to the referring or destination servers.
o RPCSEC_GSSなしで発行された要求の使用（AUTH_SYSの使用など）は、望ましくない場合もありますが、場合によっては避けられないことがあります。返されたファイルシステムの場所情報の使用を回避できない場合は、信頼できないネットワークアドレスを排除するためにフィルタリングを行う必要があります。詳細は、ネットワークの分離の程度と、要求が参照サーバーに対するものか宛先サーバーに対するものかによって異なります。
Privacy considerations relating to uniform client strings (UCS) versus non-uniform client strings (non-UCS), discussed in Section 5.6 of [RFC7931], are also applicable to their usage for trunking detection in NFS version 4.0.
[RFC7931]のセクション5.6で説明されている、均一クライアント文字列（UCS）と非均一クライアント文字列（非UCS）に関連するプライバシーの考慮事項は、NFSバージョン4.0でのトランキング検出の使用にも適用されます。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
The following references should be added to the Normative References section of [RFC7530]:
[RFC7530]の標準参照セクションに次の参照を追加する必要があります。
[RFC7931] Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker, "NFSv4.0 Migration: Specification Update", RFC 7931, DOI 10.17487/RFC7931, July 2016, <https://www.rfc-editor.org/info/rfc7931>.
[RFC7931] Noveck、D.、Ed。、Shivam、P.、Lever、C。、およびB. Baker、「NFSv4.0 Migration：Specification Update」、RFC 7931、DOI 10.17487 / RFC7931、2016年7月、<https： //www.rfc-editor.org/info/rfc7931>。
[RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct Memory Access Transport for Remote Procedure Call Version 1", RFC 8166, DOI 10.17487/RFC8166, June 2017, <https://www.rfc-editor.org/info/rfc8166>.
[RFC8166] Lever、C.、Ed。、Simpson、W。、およびT. Talpey、「リモートプロシージャコールバージョン1のリモートダイレクトメモリアクセストランスポート」、RFC 8166、DOI 10.17487 / RFC8166、2017年6月、<https：/ /www.rfc-editor.org/info/rfc8166>。
The following references should be added to the Informative References section of [RFC7530]:
[RFC7530]の参考情報セクションに、次の参照を追加する必要があります。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<https： //www.rfc-editor.org/info/rfc4033>。
[RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) Security Version 3", RFC 7861, DOI 10.17487/RFC7861, November 2016, <https://www.rfc-editor.org/info/rfc7861>.
[RFC7861] Adamson、A。およびN. Williams、「Remote Procedure Call（RPC）Security Version 3」、RFC 7861、DOI 10.17487 / RFC7861、2016年11月、<https://www.rfc-editor.org/info/ rfc7861>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, May 2009, <https://www.rfc-editor.org/info/rfc5531>.
[RFC5531] Thurlow、R。、「RPC：Remote Procedure Call Protocol Specification Version 2」、RFC 5531、DOI 10.17487 / RFC5531、2009年5月、<https://www.rfc-editor.org/info/rfc5531>。
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, March 2015, <https://www.rfc-editor.org/info/rfc7530>.
[RFC7530]ヘインズ、T。、エド。およびD. Noveck、編、「ネットワークファイルシステム（NFS）バージョン4プロトコル」、RFC 7530、DOI 10.17487 / RFC7530、2015年3月、<https://www.rfc-editor.org/info/rfc7530>。
[RFC7931] Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker, "NFSv4.0 Migration: Specification Update", RFC 7931, DOI 10.17487/RFC7931, July 2016, <https://www.rfc-editor.org/info/rfc7931>.
[RFC7931] Noveck、D.、Ed。、Shivam、P.、Lever、C。、およびB. Baker、「NFSv4.0 Migration：Specification Update」、RFC 7931、DOI 10.17487 / RFC7931、2016年7月、<https： //www.rfc-editor.org/info/rfc7931>。
[RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct Memory Access Transport for Remote Procedure Call Version 1", RFC 8166, DOI 10.17487/RFC8166, June 2017, <https://www.rfc-editor.org/info/rfc8166>.
[RFC8166] Lever、C.、Ed。、Simpson、W。、およびT. Talpey、「リモートプロシージャコールバージョン1のリモートダイレクトメモリアクセストランスポート」、RFC 8166、DOI 10.17487 / RFC8166、2017年6月、<https：/ /www.rfc-editor.org/info/rfc8166>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<https： //www.rfc-editor.org/info/rfc4033>。
[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, <https://www.rfc-editor.org/info/rfc5661>.
[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、 2010年1月、<https://www.rfc-editor.org/info/rfc5661>。
[RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) Security Version 3", RFC 7861, DOI 10.17487/RFC7861, November 2016, <https://www.rfc-editor.org/info/rfc7861>.
[RFC7861] Adamson、A。およびN. Williams、「Remote Procedure Call（RPC）Security Version 3」、RFC 7861、DOI 10.17487 / RFC7861、2016年11月、<https://www.rfc-editor.org/info/ rfc7861>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。
All sections of the current document are considered explanatory with the following exceptions.
現在のドキュメントのすべてのセクションは、以下の例外を除いて説明と見なされます。
o Sections 5.1, 5.2.4, 5.2.5, and 5.3 are replacement sections.
o セクション5.1、5.2.4、5.2.5、および5.3は置換セクションです。
o Sections 5.2.2, 5.2.3, and 5.2.6 are additional sections.
o セクション5.2.2、5.2.3、および5.2.6は追加のセクションです。
o Sections 5.2.1, 6, 7, and Section 9 are editing sections.
o セクション5.2.1、6、7、および9は編集セクションです。
Acknowledgments
謝辞
The authors wish to thank Andy Adamson, who wrote the original version of this document. All the innovation in this document is the result of Andy's work, while mistakes are best ascribed to the current authors.
このドキュメントのオリジナルバージョンを作成したAndy Adamsonに感謝します。このドキュメントのすべての革新は、Andyの成果によるものですが、間違いは現在の作者に起因するものです。
The editor wishes to thank Greg Marsden for his support of this work and Robert Thurlow for his review and suggestions.
編集者は、この作業に対する彼のサポートと、彼のレビューと提案に対するRobert Thurlowに対するGreg Marsdenに感謝します。
Special thanks go to Transport Area Director Spencer Dawkins, NFSV4 Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes for their ongoing support. We are also grateful for the thorough review of this document by Benjamin Kaduk and Ben Campbell.
トランスポートエリアディレクターのスペンサードーキンス氏、NFSV4ワーキンググループの議長であるスペンサーシェプラー氏とブライアンポーロウスキー氏、およびNFSV4ワーキンググループ長官のトーマスヘインズ氏の継続的なサポートに感謝します。また、Benjamin KadukとBen Campbellによるこのドキュメントの徹底的なレビューにも感謝しています。
Authors' Addresses
著者のアドレス
Charles Lever (editor) Oracle Corporation United States of America
Charles Lever（編集者）Oracle Corporationアメリカ合衆国
Email: chuck.lever@oracle.com
David Noveck NetApp United States of America
David Noveck NetAppアメリカ合衆国
Email: davenoveck@gmail.com