[要約] RFC 5716は、フェデレーテッドファイルシステムの要件を定義するものであり、異なるファイルシステム間の統合を可能にすることを目的としています。
Internet Engineering Task Force (IETF) J. Lentini
Request for Comments: 5716 C. Everhart
Category: Informational NetApp
ISSN: 2070-1721 D. Ellard
BBN Technologies
R. Tewari
M. Naik
IBM Almaden
January 2010
Requirements for Federated File Systems
フェデレーションファイルシステムの要件
Abstract
概要
This document describes and lists the functional requirements of a federated file system and defines related terms.
このドキュメントは、フェデレートファイルシステムの機能要件を説明およびリストし、関連する用語を定義します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション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/rfc5716.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5716で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Overview ........................................................3
1.1. Requirements Language ......................................4
2. Purpose .........................................................5
3. Examples and Discussion .........................................5
3.1. Create a Fileset and Its FSL(s) ............................5
3.1.1. Creating a Fileset and an FSN .......................6
3.1.2. Adding a Replica of a Fileset .......................6
3.2. Junction Resolution ........................................7
3.3. Junction Creation ..........................................9
4. Glossary ........................................................9
5. Proposed Requirements ..........................................11
5.1. Basic Assumptions .........................................11
5.2. Requirements ..............................................14
6. Non-Requirements ...............................................20
7. Security Considerations ........................................21
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................23
Appendix A. Acknowledgments ......................................25
This document describes and lists the functional requirements of a federated file system and defines related terms.
このドキュメントは、フェデレートファイルシステムの機能要件を説明およびリストし、関連する用語を定義します。
We do not describe the mechanisms that might be used to implement this functionality except in cases where specific mechanisms, in our opinion, follow inevitably from the requirements. Our focus is on the interfaces between the entities of the system, not on the protocols or their implementations.
私たちの意見では、特定のメカニズムが要件から必然的に従う場合を除き、この機能を実装するために使用される可能性のあるメカニズムを説明しません。私たちの焦点は、プロトコルやその実装ではなく、システムのエンティティ間のインターフェイスにあります。
Today, there are collections of fileservers that inter-operate to provide a single namespace comprised of filesystem resources provided by different members of the collection, joined together with inter-filesystem references. The namespace can either be assembled at the fileservers, the clients, or by an external namespace service, and is often not easy or uniform to manage. The requirements in this document are meant to lead to a uniform server-based namespace that is capable of spanning a whole enterprise and that is easy to manage.
今日、コレクションのさまざまなメンバーが提供するファイルシステムリソースで構成される単一の名前空間を提供するために、操作するファイルアーバーのコレクションがあります。名前空間は、ファイルサーバー、クライアント、または外部の名前空間サービスで組み立てることができ、多くの場合、管理するのが簡単で均一ではありません。このドキュメントの要件は、エンタープライズ全体にまたがる可能性のある均一なサーバーベースの名前空間につながることを目的としています。
We define some terms to better describe the solution space. A "fileset" is the abstract view of a filesystem in a uniform namespace, and may be implemented behind that abstraction by one or more physical filesystems at any given time. Each fileset has a name called an "FSN" (fileset name), and each physical filesystem has a fileset location ("FSL"). A fileset is a directory tree containing files and directories, and it may also contain references to other filesets. These references are called "junctions". To provide location independence, a junction does not contain information about the location of the real resource(s), but instead contains an FSN that can be used to look up the location information. The service that can be used to map from the FSN to the FSL(s) is called a namespace database (NSDB) service. The NSDB provides a level of indirection from the virtual paths in the uniform namespace to the actual locations of files. By design, the NSDB does not store the junctions. This allows junction administration and NSDB administration to be separate roles.
ソリューション空間をよりよく説明するために、いくつかの用語を定義します。「ファイルセット」は、均一な名前空間にあるファイルシステムの抽象的なビューであり、いつでも1つ以上の物理ファイルシステムによってその抽象化の背後に実装される場合があります。各ファイルセットには「fsn」（filesset name）と呼ばれる名前があり、各物理ファイルシステムにはファイルセットの場所（ "fsl"）があります。ファイルセットは、ファイルとディレクトリを含むディレクトリツリーであり、他のファイルセットへの参照も含まれている場合があります。これらの参照は「ジャンクション」と呼ばれます。場所の独立性を提供するために、ジャンクションには実際のリソースの場所に関する情報は含まれていませんが、代わりに位置情報を検索するために使用できるFSNが含まれています。FSNからFSLにマッピングするために使用できるサービスは、名前空間データベース（NSDB）サービスと呼ばれます。NSDBは、均一な名前空間の仮想パスからファイルの実際の場所までの間接的なレベルを提供します。設計上、NSDBはジャンクションを保存しません。これにより、ジャンクションの投与とNSDBの投与が別々の役割になることができます。
The servers direct clients to the proper locations by existing mechanisms (e.g., the referrals mechanism within [RFC3530] and [RFC5661]). Updates to the locations make it possible to support migration and replication of physical filesystems that comprise the namespace, in a way that is transparent to filesystem applications.
サーバーは、既存のメカニズムによってクライアントを適切な場所に向けます（例：[RFC3530]および[RFC5661]内の紹介メカニズム）。場所を更新すると、ファイルシステムアプリケーションに透明な方法で、名前空間を構成する物理ファイルシステムの移行と複製をサポートできます。
Figure 1 shows an example of a federation. This federation has two members, named ALPHA and BETA. Federation members may contain an arbitrary number of fileservers and NSDB nodes; in this illustration, ALPHA and BETA each have three servers, one NSDB node, and are administered separately.
図1は、連邦の例を示しています。この連合には、AlphaとBetaという名前の2人のメンバーがいます。フェデレーションメンバーには、任意の数のファイルアーバーとNSDBノードが含まれる場合があります。この図では、AlphaとBetaにはそれぞれ3つのサーバー、1つのNSDBノードがあり、個別に管理されています。
+----------------------+ +----------------------+
| Federation Member | | Federation Member |
| ALPHA | | BETA |
| | | |
| | | |
| +------------+ | | +------------+ |
| | NSDB | | | | NSDB | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
| | | |
| | | |
| +----------+ | | +----------+ |
| | | | | | | |
| +-- | Servers | | | +-- | Servers | |
| | | | | | | | | |
| +-- | | | | | +-- | | | |
| | | +----------+ | | | | +----------+ |
| | | | | | | | | |
| | +----------+ | | | +----------+ |
| | | | | | | |
| +----------+ | | +----------+ |
+----------------------+ +----------------------+
Figure 1
図1
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Note that this is a requirements document, and in many instances where these words are used in this document they refer to qualities of a specification for a system that satisfies the document, or requirements of a system that matches that specification. These cases are distinguished when there is potential for ambiguity.
これは要件ドキュメントであり、これらの単語がこのドキュメントで使用されている場合、ドキュメントを満たすシステムの仕様の品質、またはその仕様に一致するシステムの要件を指します。これらのケースは、あいまいさの可能性がある場合に区別されます。
Our objective is to specify a set of protocols by which fileservers or collections of fileservers, with different administrators, can form a federation of fileservers and NSDB nodes that provides a namespace composed of the filesets hosted on the different fileservers and fileserver collections.
私たちの目的は、異なる管理者を持つファイルサーバーまたはファイルアーバーのコレクションが、異なるファイルサーバーとファイルサーバーコレクションでホストされているファイルセットで構成される名前空間を提供するファイルアーバーとNSDBノードの連合を形成できるプロトコルのセットを指定することです。
It should be possible, using a system that implements the protocols, to share a common namespace across all the fileservers in the federation. It should also be possible for different fileservers in the federation to project different namespaces and enable clients to traverse them.
プロトコルを実装するシステムを使用して、連邦内のすべてのファイルアーバーで共通の名前空間を共有することが可能です。また、フェデレーション内のさまざまなファイルサーバーが異なる名前空間を投影し、クライアントがそれらを通過できるようにすることも可能です。
Such a federation may contain an arbitrary number of NSDB nodes, each belonging to a different administrative entity, and each providing the mappings that define a part of a namespace. Such a federation may also have an arbitrary number of administrative entities, each responsible for administering a subset of the fileservers and NSDB nodes. Acting in concert, the administrators should be able to build and administer this multi-fileserver, multi-collection namespace.
このような連邦には、それぞれが異なる管理エンティティに属し、それぞれが名前空間の一部を定義するマッピングを提供する任意の数のNSDBノードが含まれる場合があります。このような連邦は、それぞれがファイルアーバーとNSDBノードのサブセットを管理する責任を負う任意の数の管理エンティティを持っている場合があります。コンサートで行動すると、管理者は、このマルチファイルサーバーのマルチコレクション名空間を構築および管理できる必要があります。
It is not the intent of the federation to guarantee namespace consistency across all client views. Since different parts of the namespace may be administered by different entities, it is possible that a client could be accessing a stale area of the namespace managed by one entity because a part of the namespace above it, managed by another entity, has changed.
すべてのクライアントビューで名前空間の一貫性を保証することは、連邦の意図ではありません。名前空間のさまざまな部分はさまざまなエンティティによって管理される可能性があるため、別のエンティティによって管理されたその上の名前空間の一部が変更されたため、クライアントが1つのエンティティによって管理される名前空間の古い領域にアクセスできる可能性があります。
In this section we provide examples and discussion of the basic operations facilitated by the federated file system protocol: creating a fileset, adding a replica of a fileset, resolving a junction, and creating a junction.
このセクションでは、Federated File System Protocolによって促進された基本操作の例と説明を示します。ファイルセットの作成、ファイルセットのレプリカの追加、ジャンクションの解決、ジャンクションの作成です。
A fileset is the abstraction of a set of files and the directory tree that contains them. The fileset abstraction is the fundamental unit of data management in the federation. This abstraction is implemented by an actual directory tree whose root location is specified by a fileset location (FSL).
ファイルセットは、ファイルのセットとそれらを含むディレクトリツリーの抽象化です。ファイルセットの抽象化は、フェデレーションのデータ管理の基本単位です。この抽象化は、ルートの場所がファイルセットの場所（FSL）で指定されている実際のディレクトリツリーによって実装されます。
In this section, we describe the basic requirements for starting with a directory tree and creating a fileset that can be used in the federation protocols. Note that we do not assume that the process of creating a fileset requires any transformation of the files or the directory hierarchy. The only thing that is required by this process is assigning the fileset a fileset name (FSN) and expressing the location(s) of the implementation of the fileset as FSL(s).
このセクションでは、ディレクトリツリーから開始し、フェデレーションプロトコルで使用できるファイルセットを作成するための基本的な要件について説明します。ファイルセットを作成するプロセスには、ファイルまたはディレクトリ階層の変換が必要であるとは想定していないことに注意してください。このプロセスで必要な唯一のものは、ファイルセットのファイルセット名（FSN）を割り当て、FSLとしてファイルセットの実装の場所を表現することです。
There are many possible variations to this procedure, depending on how the FSN that binds the FSL is created, and whether other replicas of the fileset exist, are known to the federation, and need to be bound to the same FSN.
この手順には、FSLに結合するFSNがどのように作成されるか、およびファイルセットの他のレプリカが存在するかどうかに応じて、同じFSNに拘束される必要があるかどうかに応じて、この手順には多くのバリエーションがあります。
It is easiest to describe this in terms of how to create the initial implementation of the fileset, and then describe how to add replicas.
ファイルセットの初期実装を作成する方法という観点からこれを説明し、レプリカを追加する方法を説明するのが最も簡単です。
1. Choose the NSDB node that will keep track of the FSL(s) and related information for the fileset.
1. FSL（S）とファイルセットの関連情報を追跡するNSDBノードを選択します。
2. Request that the NSDB node register a new FSN for the fileset.
2. NSDBノードがファイルセットの新しいFSNを登録することをリクエストします。
The FSN may either be chosen by the NSDB node or by the server. The latter case is used if the fileset is being restored, perhaps as part of disaster recovery, and the server wishes to specify the FSN in order to permit existing junctions that reference that FSN to work again.
FSNは、NSDBノードまたはサーバーによって選択される場合があります。後者のケースは、おそらく災害復旧の一環としてファイルセットが復元されている場合に使用され、サーバーはFSNが再び動作することを参照する既存のジャンクションを許可するためにFSNを指定したいと考えています。
At this point, the FSN exists, but its location is unspecified.
この時点で、FSNは存在しますが、その場所は特定されていません。
3. Send the FSN, the local volume path, the export path, and the export options for the local implementation of the fileset to the NSDB node. Annotations about the FSN or the location may also be sent.
3. FSN、ローカルボリュームパス、エクスポートパス、およびNSDBノードにファイルセットのローカル実装のためのエクスポートオプションを送信します。FSNまたは場所に関する注釈も送信できます。
The NSDB node records this information and creates the initial FSL for the fileset.
NSDBノードはこの情報を記録し、ファイルセットの初期FSLを作成します。
Adding a replica is straightforward: the NSDB node and the FSN are already known. The only remaining step is to add another FSL.
レプリカの追加は簡単です。NSDBノードとFSNはすでに既知です。残りの唯一のステップは、別のFSLを追加することです。
Note that the federation protocols do not include methods for creating or managing replicas: this is assumed to be a platform-dependent operation (at least at this time). The only requirement is that these fileset replicas be registered and unregistered with the NSDB.
フェデレーションプロトコルには、レプリカの作成または管理方法が含まれていないことに注意してください。これは、プラットフォーム依存操作であると想定されています（少なくとも現時点では）。唯一の要件は、これらのファイルセットレプリカが登録され、NSDBに登録されていないことです。
A fileset may contain references to other filesets. These references are represented by junctions. If a client requests access to a fileset object that is a junction, the server resolves the junction to discover the FSL(s) that implements the referenced fileset.
ファイルセットには、他のファイルセットへの参照が含まれている場合があります。これらの参照はジャンクションで表されます。クライアントがジャンクションであるファイルセットオブジェクトへのアクセスを要求した場合、サーバーはジャンクションを解決して、参照されたファイルセットを実装するFSLを発見します。
There are many possible variations to this procedure, depending on how the junctions are represented and how the information necessary to perform resolution is represented by the server.
この手順には、ジャンクションの表現方法と解像度の実行に必要な情報がサーバーによって表される方法に応じて、多くのバリエーションがあります。
Step 4 is the only step that interacts directly with the federation protocols. The rest of the steps may use platform-specific interfaces.
ステップ4は、フェデレーションプロトコルと直接相互作用する唯一のステップです。残りのステップでは、プラットフォーム固有のインターフェイスを使用する場合があります。
1. The server determines that the object being accessed is a junction.
1. サーバーは、アクセスするオブジェクトがジャンクションであると判断します。
2. Using the junction, the server does a local lookup to find the FSN of the target fileset.
2. ジャンクションを使用して、サーバーはローカルルックアップを行い、ターゲットファイルセットのFSNを見つけます。
3. Using the FSN, the server finds the NSDB node responsible for the target object.
3. FSNを使用して、サーバーはターゲットオブジェクトに責任を負うNSDBノードを見つけます。
4. The server contacts that NSDB node and asks for the set of FSLs that implement the target FSN. The NSDB node responds with a set of FSLs.
4. サーバーは、NSDBノードを接触し、ターゲットFSNを実装するFSLのセットを要求します。NSDBノードは、FSLのセットで応答します。
5. The server converts one or more of the FSLs to the location type used by the client (e.g., a Network File System (NFSv4) fs_location, as described in [RFC3530]).
5. サーバーは、FSLの1つ以上をクライアントが使用する位置タイプに変換します（たとえば、[RFC3530]で説明されているように、ネットワークファイルシステム（NFSV4）FS_Location）。
6. The server redirects (in whatever manner is appropriate for the client) the client to the location(s).
6. サーバーは（クライアントに適した方法で）クライアントを場所にリダイレクトします。
These steps are illustrated in Figure 2. The client sends request 1 to server X, in federation member ALPHA, in an attempt to reference an object (which appears to the client as a directory). Server X recognizes that the referenced object is actually a junction that refers to a directory in a different fileset. Server X finds, from the FSN in the junction, that the NSDB responsible for knowing the location of the target of the junction is the NSDB of federation member BETA. Server X sends request 2 to the NSDB of BETA, asking for the current location of the directory. The NSDB sends response 3 to server X, telling the server that the directory is located on server Y. Server X sends response 4 to the client, indicating that the directory is in a "new" location on server Y. The client then sends request 5 to server Y, repeating the initial request.
これらの手順を図2に示します。クライアントは、オブジェクト（クライアントに表示されるディレクトリとして表示される）を参照するために、フェデレーションメンバーのアルファで、リクエスト1をサーバーXに送信します。サーバーXは、参照されるオブジェクトが実際には別のファイルセット内のディレクトリを参照するジャンクションであることを認識しています。サーバーXは、ジャンクションのFSNから、ジャンクションのターゲットの位置を知る責任を負うNSDBがフェデレーションメンバーベータのNSDBであることを発見します。サーバーXは、リクエスト2をベータのNSDBに送信し、ディレクトリの現在の場所を要求します。NSDBは応答3をサーバーXに送信し、ディレクトリがサーバーYにあることをサーバーに伝えます。サーバーXはクライアントに応答4を送信し、ディレクトリがサーバーYの「新しい」場所にあることを示します。クライアントはリクエストを送信します5つのサーバーYに、最初のリクエストを繰り返します。
Given the current requirements and definitions, this resolution method MUST work. However, there is no requirement that this is the only resolution method that can be used. This method may be used as the fallback when all else fails (or, for a simple implementation, it could be the only method). This is a degenerate implementation of the NSDB service as a simple composition of NSDB nodes; we expect that large federations will use more sophisticated methods to share the FSN and FSL information among multiple NSDB nodes.
現在の要件と定義を考えると、この解決方法は機能する必要があります。ただし、これが使用できる唯一の解像度方法であるという要件はありません。この方法は、他のすべてが失敗したときにフォールバックとして使用できます（または、単純な実装では、唯一の方法である可能性があります）。これは、NSDBノードの単純な構成としてのNSDBサービスの退化した実装です。大規模な連合は、より洗練された方法を使用して、複数のNSDBノード間でFSNおよびFSL情報を共有することを期待しています。
+---------------+
| |
| Client | >--------------------------+
| | |
+---------------+ |
v ^ |
+-----+---+-------------+ +-----------------+-----+
| | | Federation| |Federation | |
| | | member | |member | |
| | | ALPHA | |BETA | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | +---------+ | |
| | | +---------+------+-> | | | |
| | | | | | | NSDB Y | | |
| | | | +-----+------+-< | | | |
| | | | | | | +---------+ | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| 1| 4| 2| 3| | | 5| |
| v ^ ^ v | | v |
| +---------------+ | | +---------------+ |
| | | | | | | |
| | Server X | | | | Server Y | |
| | | | | | | |
| +---------------+ | | +---------------+ |
| | | |
+-----------------------+ +-----------------------+
Figure 2
図2
Given a local path and the FSN of a remote fileset, an administrator can create a junction from the local path to the remote fileset.
ローカルパスとリモートファイルセットのFSNが与えられた場合、管理者はローカルパスからリモートファイルセットへのジャンクションを作成できます。
There are many possible variations to this procedure, depending on how the junctions are represented and how the information necessary to perform resolution is represented by the server.
この手順には、ジャンクションの表現方法と解像度の実行に必要な情報がサーバーによって表される方法に応じて、多くのバリエーションがあります。
Step 1 is the only step that uses the federation interfaces. The remaining step may use platform-specific interfaces.
ステップ1は、フェデレーションインターフェイスを使用する唯一のステップです。残りのステップでは、プラットフォーム固有のインターフェイスを使用する場合があります。
1. The administrator requests the server create a junction to the FSN of the remote fileset at the given path.
1. 管理者は、サーバーが指定されたパスでリモートファイルセットのFSNへのジャンクションを作成します。
2. The server inserts the junction to the FSN, at the given path, into the local filesystem.
2. サーバーは、指定されたパスのFSNにジャンクションをローカルファイルシステムに挿入します。
Administrator: user with the necessary authority to initiate administrative tasks on one or more servers.
管理者：1つ以上のサーバーで管理タスクを開始するために必要な権限を持つユーザー。
Admin Entity: A server or agent that administers a collection of fileservers and persistently stores the namespace information.
管理者エンティティ：ファイルサーバーのコレクションを管理し、名前空間情報を永続的に保存するサーバーまたはエージェント。
Client: Any client that accesses the fileserver data using a supported filesystem access protocol.
クライアント：サポートされているファイルシステムアクセスプロトコルを使用してファイルサーバーデータにアクセスするクライアント。
Federation: A set of server collections and singleton servers that use a common set of interfaces and protocols in order to provide to their clients a federated namespace accessible through a filesystem access protocol.
フェデレーション：ファイルシステムアクセスプロトコルを介してアクセス可能なフェデレートネームスペースをクライアントに提供するために、インターフェイスとプロトコルの共通セットを使用するサーバーコレクションとシングルトンサーバーのセット。
Fileserver: A server exporting a filesystem via a network filesystem access protocol.
Fileserver：ネットワークファイルシステムアクセスプロトコルを介してファイルシステムをエクスポートするサーバー。
Fileset: The abstraction of a set of files and the directory tree that contains them. A fileset is the fundamental unit of data management in the federation.
ファイルセット：ファイルのセットとそれらを含むディレクトリツリーの抽象化。ファイルセットは、フェデレーションのデータ管理の基本単位です。
Note that all files within a fileset are descendants of one directory, and that filesets do not span filesystems.
ファイルセット内のすべてのファイルは1つのディレクトリの子孫であり、ファイルセットがファイルシステムに及ばないことに注意してください。
Filesystem: A self-contained unit of export for a fileserver, and the mechanism used to implement filesets. The fileset does not need to be rooted at the root of the filesystem, nor at the export point for the filesystem.
ファイルシステム：ファイルサーバーのエクスポートの自己完結型ユニット、およびファイルセットの実装に使用されるメカニズム。ファイルセットは、ファイルシステムのルートやファイルシステムのエクスポートポイントにルート化する必要はありません。
A single filesystem MAY implement more than one fileset, if the client protocol and the fileserver permit this.
クライアントプロトコルとファイルサーバーがこれを許可する場合、単一のファイルシステムは複数のファイルセットを実装できます。
Filesystem Access Protocol: A network filesystem access protocol such as NFSv2 [RFC1094], NFSv3 [RFC1813], NFSv4 [RFC3530], or CIFS (Common Internet File System) [MS-SMB] [MS-SMB2] [MS-CIFS].
ファイルシステムアクセスプロトコル：NFSV2 [RFC1094]、NFSV3 [RFC1813]、NFSV4 [RFC3530]、またはCIFS（共通インターネットファイルシステム）[MS-SMB] [MS-SMB2] [MS-CIFS]などのネットワークファイルシステムアクセスプロトコル。
FSL (Fileset Location): The location of the implementation of a fileset at a particular moment in time. An FSL MUST be something that can be translated into a protocol-specific description of a resource that a client can access directly, such as an fs_location (for NFSv4), or share name (for CIFS). Note that not all FSLs need to be explicitly exported as long as they are contained within an exported path on the fileserver.
FSL（ファイルセットの場所）：特定の瞬間にファイルセットの実装の場所。FSLは、FS_Location（NFSV4の場合）または共有名（CIFS）など、クライアントが直接アクセスできるリソースのプロトコル固有の説明に変換できるものでなければなりません。すべてのFSLが、ファイルサーバーのエクスポートパス内に含まれている限り、明示的にエクスポートする必要はないことに注意してください。
FSN (Fileset Name): A platform-independent and globally unique name for a fileset. Two FSLs that implement replicas of the same fileset MUST have the same FSN, and if a fileset is migrated from one location to another, the FSN of that fileset MUST remain the same.
FSN（ファイルセット名）：ファイルセットのプラットフォームに依存しないグローバルに一意の名前。同じファイルセットのレプリカを実装する2つのFSLは同じFSNを持つ必要があり、ファイルセットがある場所から別の場所に移行された場合、そのファイルセットのFSNは同じままでなければなりません。
Junction: A filesystem object used to link a directory name in the current fileset with an object within another fileset. The server-side "link" from a leaf node in one fileset to the root of another fileset.
Junction：現在のファイルセットのディレクトリ名を別のファイルセット内のオブジェクトにリンクするために使用されるファイルシステムオブジェクト。1つのファイルセットのリーフノードから別のファイルセットのルートへのサーバー側の「リンク」。
Namespace: A filename/directory tree that a sufficiently authorized client can observe.
名前空間：十分に承認されたクライアントが観察できるファイル名/ディレクトリツリー。
NSDB (Namespace Database) Service: A service that maps FSNs to FSLs. The NSDB may also be used to store other information, such as annotations for these mappings and their components.
NSDB（名前空間データベース）サービス：FSNをFSLSにマッピングするサービス。NSDBは、これらのマッピングやそのコンポーネントの注釈など、他の情報を保存するためにも使用できます。
NSDB Node: The name or location of a server that implements part of the NSDB service and is responsible for keeping track of the FSLs (and related info) that implement a given partition of the FSNs.
NSDBノード：NSDBサービスの一部を実装し、FSNSの特定のパーティションを実装するFSL（および関連情報）を追跡する責任を負うサーバーの名前または場所。
Referral: A server response to a client access that directs the client to evaluate the current object as a reference to an object at a different location (specified by an FSL) in another fileset, and possibly hosted on another fileserver. The client re-attempts the access to the object at the new location.
紹介：クライアントに別のファイルセットの別の場所（FSLで指定）のオブジェクトへの参照として現在のオブジェクトを評価するように指示するクライアントアクセスへのサーバー応答。クライアントは、新しい場所のオブジェクトへのアクセスを再触っています。
Replica: A replica is a redundant implementation of a fileset. Each replica shares the same FSN, but has a different FSL.
レプリカ：レプリカは、ファイルセットの冗長実装です。各レプリカは同じFSNを共有していますが、FSLは異なります。
Replicas may be used to increase availability or performance. Updates to replicas of the same fileset MUST appear to occur in the same order, and therefore each replica is self-consistent at any moment.
レプリカは、可用性やパフォーマンスを向上させるために使用できます。同じファイルセットのReplicasの更新は、同じ順序で発生するように見える必要があるため、各レプリカはいつでも自己矛盾しています。
We do not assume that updates to each replica occur simultaneously. If a replica is offline or unreachable, the other replicas may be updated.
各レプリカの更新が同時に発生するとは想定していません。レプリカがオフラインまたは到達不可能な場合、他のレプリカが更新される場合があります。
Server Collection: A set of fileservers administered as a unit. A server collection may be administered with vendor-specific software.
サーバーコレクション：ユニットとして管理されているファイルサーバーのセット。サーバーコレクションは、ベンダー固有のソフトウェアで管理される場合があります。
The namespace provided by a server collection could be part of the federated namespace.
サーバーコレクションによって提供される名前空間は、フェデレーションネームスペースの一部である可能性があります。
Singleton Server: A server collection containing only one server; a stand-alone fileserver.
Singleton Server：1つのサーバーのみを含むサーバーコレクション。スタンドアロンファイルサーバー。
The phrase "USING THE FEDERATION INTERFACES" implies that the subsequent requirement must be satisfied, in its entirety, via the federation interfaces.
「フェデレーションインターフェイスの使用」というフレーズは、連邦インターフェイスを介して、その後の要件が完全に満たされなければならないことを意味します。
Note that the requirements are described in terms of correct behavior by all entities. We do not address the requirements of the system in the presence of faults.
要件は、すべてのエンティティによる正しい動作の観点から説明されていることに注意してください。障害の存在下でシステムの要件に対処しません。
Several of the requirements are so fundamental that we treat them as basic assumptions; if any of these assumptions are violated, the rest of the requirements must be reviewed in their entirety.
いくつかの要件は非常に基本的であるため、それらを基本的な仮定として扱います。これらの仮定のいずれかが違反されている場合、残りの要件を完全にレビューする必要があります。
A1: The federation protocols do not require any changes to existing client-facing protocols, and MAY be extended to incorporate new client-facing protocols.
A1：フェデレーションプロトコルは、既存のクライアント向けプロトコルの変更を必要とせず、新しいクライアント向けのプロトコルを組み込むために拡張される場合があります。
A2: A client SHOULD NOT require any a priori knowledge of the general structure or composition of the federation.
A2：クライアントは、連邦の一般的な構造または構成に関する先験的な知識を必要としないでください。
The client may require some specific knowledge in order to find and access an instance of the fileset that defines the root of its view of the namespace. As the client traverses the namespace, the client discovers the information it needs in order to locate the filesets it accesses.
クライアントは、名前空間のビューのルートを定義するファイルセットのインスタンスを見つけてアクセスするために、特定の知識を必要とする場合があります。クライアントが名前空間を横断すると、クライアントがアクセスするファイルセットを見つけるために必要な情報を発見します。
A3: All requirements MUST be satisfiable via the federation protocols and the standard protocols used by the fileservers (i.e., NFS, CIFS, DNS, etc.).
A3：すべての要件は、Fileservers（つまり、NFS、CIFS、DNSなど）が使用する連邦プロトコルと標準プロトコルを介して満たす必要があります。
USING THE FEDERATION INTERFACES, a federation operation that requires an interaction between two (or more) entities that are members of the federation MUST be possible without requiring any proprietary protocols.
フェデレーションインターフェイスを使用すると、連邦のメンバーである2つ（またはそれ以上）のエンティティ間の相互作用を必要とする連邦操作は、独自のプロトコルを必要とせずに可能でなければなりません。
A4: All the entities participating in a federation operation MUST be able to authenticate each other.
A4：連邦運営に参加しているすべてのエンティティは、お互いを認証できる必要があります。
All principals (clients, users, administrator of a singleton or server collection, hosts, NSDB nodes, etc.) that can assume a role defined by the federation protocol can identify themselves to each other via an authentication mechanism. This mechanism is not defined or further described in this document.
連邦プロトコルによって定義された役割を想定できるすべてのプリンシパル（クライアント、ユーザー、シングルトンまたはサーバーコレクションの管理者、ホスト、NSDBノードなど）は、認証メカニズムを介して互いに識別できます。このメカニズムは、このドキュメントで定義されていないか、さらに説明されていません。
The authority of a principal to request that a second principal perform a specific operation is ultimately determined by the second. Authorization may be partitioned by server collection or set of servers as well as by operation. For example, if a user has administrative privileges on one server in the federation, this does not imply that they have administrative privileges (or, for that matter, any privileges whatsoever) on any other server in the federation.
2番目のプリンシパルが特定の操作を実行することを要求する校長の権限は、最終的に2番目の操作によって決定されます。許可は、サーバーコレクションまたはサーバーのセット、および操作によって分割される場合があります。たとえば、ユーザーがフェデレーションの1つのサーバーに管理特権を持っている場合、これは、連邦の他のサーバーに管理特権（または、あらゆる特権）があることを意味するものではありません。
In order to access the functionality provided by the federation interfaces, it may be necessary to have elevated privileges or authorization. The authority required by different operations may be different. For example, the authority required to query the NSDB about the FSLs bound to an FSN may be different than the authority required to change the bindings of that FSN.
フェデレーションインターフェイスによって提供される機能にアクセスするには、特権または承認を高める必要がある場合があります。異なる業務に必要な当局は異なる場合があります。たとえば、FSNにバインドされたFSLについてNSDBを照会するために必要な当局は、そのFSNのバインディングを変更するために必要な当局とは異なる場合があります。
An operation attempted by an unauthorized entity MUST fail in a manner that indicates that the failure was due to insufficient authorization.
許可されていないエンティティによって試みられた操作は、失敗が許可不足によるものであることを示す方法で失敗する必要があります。
This document does not enumerate the authorization necessary for any operation.
このドキュメントは、操作に必要な承認を列挙していません。
A5: The federation protocols MUST NOT require changes to existing authentication/authorization mechanisms in use at the fileservers for client-facing protocols.
A5：フェデレーションプロトコルは、クライアント向けプロトコルにFileserversで使用されている既存の認証/認証メカニズムの変更を必要としない必要があります。
A user's view of the namespace may be limited by the authentication and authorization privileges it has on the different fileservers in the federation. As such, users may only be able to traverse the parts of the namespace to which they have access.
ネームスペースのユーザーのビューは、フェデレーションのさまざまなファイルアーバーにある認証および承認の特権によって制限される場合があります。そのため、ユーザーは、アクセスできる名前空間の部分のみを通過できる場合があります。
The federation protocols do not impose any restrictions on how users are represented within the federation. For example, a single enterprise could employ a common identity for users across the federation. A grid environment could utilize user mapping or translations across different administrative domains.
連邦プロトコルは、連邦内でユーザーがどのように代表されるかに制限を課しません。たとえば、単一の企業は、連邦全体のユーザーに共通のアイデンティティを採用できます。グリッド環境は、さまざまな管理ドメインにわたってユーザーマッピングまたは翻訳を利用できます。
A6: In a federated system, we assume that an FSN MUST express, or can be used to discover, the following two pieces of information:
A6：フェデレートシステムでは、FSNが次の2つの情報を発見するか、発見するために使用できるか、使用できると仮定します。
1. The location of the NSDB node that is responsible for knowing the filesystem location(s) (FSLs) of the named fileset.
1. 指定されたファイルセットのファイルシステムの位置（s）（fsls）を知ることを担当するNSDBノードの場所。
The NSDB node must be specified because there may be many NSDB nodes in a federation. We do not assume that any single entity knows the location of all of the NSDB nodes, and therefore exhaustive search is not an option.
連邦には多くのNSDBノードがある可能性があるため、NSDBノードを指定する必要があります。単一のエンティティがすべてのNSDBノードの位置を知っているとは想定していないため、徹底的な検索はオプションではありません。
There are several ways in which a fileserver can locate the NSDB node responsible for a given fileset. One approach, given a DNS infrastructure, is to specify the location of the NSDB node by the Fully-Qualified Domain Name (FQDN) of the server hosting the NSDB node. Another approach is to use a separate DNS-style hierarchy to resolve the location of the NSDB node.
Fileserverが特定のファイルセットを担当するNSDBノードを見つけることができるいくつかの方法があります。DNSインフラストラクチャが与えられた1つのアプローチは、NSDBノードをホストするサーバーの完全に適格なドメイン名（FQDN）によってNSDBノードの位置を指定することです。別のアプローチは、個別のDNSスタイルの階層を使用して、NSDBノードの位置を解決することです。
2. The FSN identifier.
2. FSN識別子。
The FSN identifier is the index used by the NSDB node to identify the target fileset.
FSN識別子は、ターゲットファイルセットを識別するためにNSDBノードで使用されるインデックスです。
There are several ways to represent FSN identifiers. One approach could use 128-bit Universally Unique IDentifiers (UUIDs) as described in [RFC4122].
FSN識別子を表す方法はいくつかあります。[RFC4122]で説明されているように、1つのアプローチが128ビットの普遍的に一意の識別子（UUIDS）を使用できます。
As an example, an FSN could be represented by a URL of the form nsdb://nsdb.example.com/UUID where nsdb is the scheme name, nsdb.example.com is the FQDN of the server hosting the NSDB node, and UUID is the string representation of the identifier.
例として、FSNはnsdb：//nsdb.example.com/uuidのフォームのURLで表現できます。ここで、nsdbはスキーム名です。NSDB.example.comはnsdbノードをホストするサーバーのfqdnです。UUIDは、識別子の文字列表現です。
Note that it is not assumed that it is always required for a server to contact the NSDB node specified by the FSN in order to find the FSLs. The relevant information stored in that NSDB node may also be cached local to the server or on a proxy NSDB node "near" the server.
サーバーがFSLSを見つけるためにFSNによって指定されたNSDBノードに連絡することが常に必要であるとは想定されていないことに注意してください。そのNSDBノードに保存されている関連情報は、サーバーにローカルまたはサーバーの近くのプロキシNSDBノードにローカルになっている場合があります。
A7: All federation servers and NSDB nodes are assumed to execute the federation protocols correctly. The behavior of the federation is undefined in the case of Byzantine behavior by any federation server or NSDB node.
A7：すべてのフェデレーションサーバーとNSDBノードは、フェデレーションプロトコルを正しく実行すると想定されています。フェデレーションの動作は、フェデレーションサーバーまたはNSDBノードによってビザンチンの動作の場合に定義されていません。
A8: The locations of federation services (such as NSDBs and FSLs) can be specified in a manner such that they can be correctly interpreted by all members of the federation that will access them.
A8：連邦サービスの場所（NSDBやFSLなど）は、それらにアクセスする連邦のすべてのメンバーが正しく解釈できるように、方法で指定できます。
For example, if an NSDB node is specified by an FQDN, then this implies that every member of the federation that needs to access this NSDB node can resolve this FQDN to an IP address for that NSDB node. (It is not necessary that the FQDN always resolve to the same address; the same service may appear at different addresses on different networks.)
たとえば、NSDBノードがFQDNによって指定されている場合、これは、このNSDBノードにアクセスする必要がある連邦のすべてのメンバーが、このNSDBノードのIPアドレスにこのFQDNを解決できることを意味します。（FQDNが常に同じアドレスに解決する必要はありません。同じサービスが異なるネットワーク上の異なるアドレスに表示される場合があります。）
It is the responsibility of each federation member to ensure that the resources it wishes to expose have accessible network locations and that the necessary resolution mechanisms (i.e., DNS) are given the necessary data to perform the resolution correctly.
公開したいリソースにアクセス可能なネットワークの場所があり、必要な解像度メカニズム（つまり、DNS）が解像度を正しく実行するために必要なデータが与えられることを保証することは、各連邦メンバーの責任です。
R1: Requirements of each FSN:
R1：各FSNの要件：
a. Each FSN MUST be unique within the scope of its NSDB (so that the FSN is globally unique).
a. 各FSNは、NSDBの範囲内で一意でなければなりません（FSNがグローバルに一意になるように）。
b. The FSN MUST be sufficiently descriptive to locate an instance of the fileset it names within the federation at any time.
b. FSNは、いつでも連邦内で名前が付けられたファイルセットのインスタンスを見つけるのに十分な記述でなければなりません。
c. All FSNs MUST be invariant when their underlying filesystems move or are replicated; only mappings from FSN to FSL(s) change under these transformations.
c. 基礎となるファイルシステムが移動または複製されている場合、すべてのFSNは不変でなければなりません。FSNからFSLへのマッピングのみがこれらの変換の下で変化します。
d. All files accessible from the global namespace MUST be part of a fileset that has an assigned FSN.
d. グローバルネームスペースからアクセス可能なすべてのファイルは、FSNが割り当てられたファイルセットの一部である必要があります。
Not all filesets in the federation are required to have an FSN or be reachable by an FSL. Only those filesets that are the target of a junction (as described in R3) are required to have an FSN.
フェデレーション内のすべてのファイルセットがFSNを持っているか、FSLが到達できるようにする必要があるわけではありません。（R3で説明されている）ジャンクションのターゲットであるファイルセットのみがFSNを持つ必要があります。
The FSN format MAY be of variable size. If the format is variable in size, fileserver implementations MAY have a maximum supported FSN size. By bounding the FSN size, some fileserver implementations might be able to efficiently organize FSNs in stable storage. For interoperability, the federation protocols SHOULD define an FSN size that all fileservers support.
FSN形式のサイズは可変です。フォーマットのサイズが変動する場合、Fileserverの実装は最大サポートされているFSNサイズになる場合があります。FSNサイズを制限することにより、一部のFileserver実装は、安定したストレージでFSNを効率的に整理できる場合があります。相互運用性のために、フェデレーションプロトコルは、すべてのファイルサーバーがサポートするFSNサイズを定義する必要があります。
R2: USING THE FEDERATION INTERFACES, it MUST be possible to create an FSN for a fileset, and it must be possible to bind an FSL to that FSN. These operations are NSDB operations and do not require any action on the part of a file server.
R2：フェデレーションインターフェイスを使用すると、ファイルセット用のFSNを作成することが可能である必要があり、そのFSNにFSLをバインドすることが可能である必要があります。これらの操作はNSDB操作であり、ファイルサーバーの側でのアクションは必要ありません。
It is possible to create an FSN for a fileset that has not actually been created. It is also possible to bind a nonexistent FSL to an FSN. It is also possible to create a fileset without assigning it an FSN. The binding between an FSN and an FSL is defined entirely within the context of the NSDB; the servers do not "know" whether the filesets they host have been assigned FSNs (or, if so, what those FSNs are).
実際に作成されていないファイルセット用のFSNを作成することができます。存在しないFSLをFSNに結合することも可能です。FSNを割り当てずにファイルセットを作成することもできます。FSNとFSLの間の結合は、NSDBのコンテキスト内で完全に定義されます。サーバーは、ホストするファイルセットにFSNSが割り当てられているかどうか（または、その場合、それらのFSNが何であるか）かどうかを「知りません」。
The requirement that filesets can exist prior to being assigned an FSN and the requirement that FSNs can exist independent of filesets are intended to simplify the construction of the namespace in a convenient manner. For example, they permit an admin to assign FSNs to existing filesets and thereby incorporate existing filesets into the namespace. They also permit the structure of the namespace to be defined prior to creation of the component filesets. In either case, it is the responsibility of the entity updating the NSDB with FSNs and FSN-to-FSL mappings to ensure that the namespace is constructed in a consistent manner. (The simplest way to accomplish this is to ensure that the FSN and FSN-to-FSL mappings are always recorded in the NSDB prior to the creation of any junctions that refer to that FSN.)
FSNを割り当てる前にファイルセットが存在できるという要件と、FSNSがファイルセットから独立して存在するという要件は、便利な方法で名前空間の構築を簡素化することを目的としています。たとえば、管理者が既存のファイルセットにFSNを割り当てることを許可し、既存のファイルセットを名前空間に組み込みます。また、コンポーネントファイルセットを作成する前に、名前空間の構造を定義することも許可しています。どちらの場合でも、NSDBをFSNSおよびFSN-To-FSLマッピングでNSDBを更新して、名前空間が一貫した方法で構築されるようにする責任です。（これを達成する最も簡単な方法は、FSNとFSNからFSNへのマッピングが、そのFSNを参照するジャンクションが作成される前に常にNSDBに記録されることを保証することです。）
a. An administrator MAY specify the entire FSN (including both the NSDB node location and the identifier) of the newly created FSL, or the administrator MAY specify only the NSDB node and have the system choose the identifier.
a. 管理者は、新しく作成されたFSLのFSN全体（NSDBノードの位置と識別子の両方を含む）を指定するか、管理者がNSDBノードのみを指定し、システムに識別子を選択することができます。
The admin can choose to specify the FSN explicitly in order to recreate a lost fileset with a given FSN (for example, as part of disaster recovery). It is an error to assign an FSN that is already in use by an active fileset.
管理者は、特定のFSNを使用して失われたファイルセットを再現するために、FSNを明示的に指定することを選択できます（たとえば、災害復旧の一部として）。Active Filessetが既に使用しているFSNを割り当てるのはエラーです。
Note that creating a replica of an existing filesystem is NOT accomplished by assigning the FSN of the filesystem you wish to replicate to a new filesystem.
既存のファイルシステムのレプリカの作成は、新しいファイルシステムに複製するファイルシステムのFSNを割り当てることによって達成されないことに注意してください。
b. USING THE FEDERATION INTERFACES, it MUST be possible to create a federation FSL by specifying a specific local volume, path, export path, and export options.
b. フェデレーションインターフェイスを使用して、特定のローカルボリューム、パス、エクスポートパス、およびエクスポートオプションを指定することにより、フェデレーションFSLを作成することが可能である必要があります。
R3: USING THE FEDERATION INTERFACES, and given the FSN of a target fileset, it MUST be possible to create a junction to that fileset at a named place in another fileset.
R3：フェデレーションインターフェイスを使用し、ターゲットファイルセットのFSNが与えられた場合、別のファイルセットの名前付き場所でそのファイルセットにジャンクションを作成することが可能である必要があります。
After a junction has been created, clients that access the junction transparently interpret it as a reference to the FSL(s) that implement the FSN associated with the junction.
ジャンクションが作成された後、ジャンクションにアクセスするクライアントは、ジャンクションに関連付けられたFSNを実装するFSLへの参照として透過的に解釈します。
a. It SHOULD be possible to have more than one junction whose target is a given fileset. In other words, it SHOULD be possible to mount a fileset at multiple named places.
a. ターゲットが指定されたファイルセットである複数のジャンクションを持つことができるはずです。言い換えれば、複数の名前の場所にファイルセットをマウントすることができるはずです。
b. If the fileset in which the junction is created is replicated, then the junction MUST eventually appear in all of its replicas.
b. ジャンクションが作成されるファイルセットが複製されている場合、最終的にそのすべてのレプリカに接合部が表示されなければなりません。
The operation of creating a junction within a fileset is treated as an update to the fileset, and therefore obeys the general rules about updates to replicated filesets.
ファイルセット内でジャンクションを作成する操作は、ファイルセットの更新として扱われるため、複製されたファイルセットの更新に関する一般的なルールに従います。
R4: USING THE FEDERATION INTERFACES, it MUST be possible to delete a specific junction from a fileset.
R4：フェデレーションインターフェイスを使用して、ファイルセットから特定のジャンクションを削除することができる必要があります。
If a junction is deleted, clients who are already viewing the fileset referred to by the junction after traversing the junction MAY continue to view the old namespace. They might not discover that the junction no longer exists (or has been deleted and replaced with a new junction, possibly referring to a different FSN).
ジャンクションが削除されている場合、ジャンクションを移動した後にジャンクションが参照されているファイルセットをすでに表示しているクライアントは、古い名前空間を引き続き表示できます。彼らは、ジャンクションがもはや存在しないことを発見しないかもしれません（または、削除されて新しいジャンクションに置き換えられ、おそらく別のFSNを参照しています）。
After a junction is deleted, another object with the same name (another junction, or an ordinary filesystem object) may be created.
ジャンクションが削除された後、同じ名前（別のジャンクション、または通常のファイルシステムオブジェクト）を持つ別のオブジェクトが作成される場合があります。
The operation of deleting a junction within a fileset is treated as an update to the fileset, and therefore obeys the general rules about updates to replicated filesets.
ファイルセット内のジャンクションの削除の操作は、ファイルセットの更新として扱われるため、複製されたファイルセットの更新に関する一般的なルールに従います。
R5: USING THE FEDERATION INTERFACES, it MUST be possible to invalidate an FSN.
R5：フェデレーションインターフェイスを使用すると、FSNを無効にすることが可能である必要があります。
a. If a junction refers to an FSN that is invalid, attempting to traverse the junction MUST fail.
a. ジャンクションが無効なFSNを指す場合、接合部を横断しようとすると失敗する必要があります。
An FSN that has been invalidated MAY become valid again if the FSN is recreated (i.e., as part of a disaster recovery process).
無効化されたFSNは、FSNが再現されると再び有効になる場合があります（つまり、災害復旧プロセスの一部として）。
If an FSN is invalidated, clients who are already viewing the fileset named by the FSN MAY continue to view the old namespace. They might not discover that the FSN is no longer valid until they try to traverse a junction that refers to it.
FSNが無効になっている場合、FSNによって名前が付けられたファイルセットを既に表示しているクライアントは、古い名前空間を引き続き表示する場合があります。彼らは、FSNがそれを指すジャンクションを横断しようとするまで、もはや有効でないことを発見しないかもしれません。
R6: USING THE FEDERATION INTERFACES, it MUST be possible to invalidate an FSL.
R6：フェデレーションインターフェイスを使用して、FSLを無効にすることが可能である必要があります。
a. An invalid FSL MUST NOT be returned as the result of resolving a junction.
a. 無効なFSLは、ジャンクションの解決の結果として返されてはなりません。
An FSL that has been invalidated MAY become valid again if the FSL is recreated (i.e., as part of a disaster recovery process).
無効化されたFSLは、FSLが再現された場合（つまり、災害復旧プロセスの一部として）再び有効になる場合があります。
If an FSL is invalidated, clients who are already viewing the fileset implemented by the FSL MAY continue to use that FSL. They might not discover that the FSL is no longer valid until they try to traverse a junction that refers to the fileset implemented by the FSL.
FSLが無効になっている場合、FSLによって実装されたファイルセットをすでに表示しているクライアントは、そのFSLを使用し続けることができます。FSLによって実装されたファイルセットを参照するジャンクションを通過しようとするまで、FSLがもはや有効でないことを発見しないかもしれません。
Note that invalidating an FSL does not imply that the underlying export or share (depending on the file access protocol in use) is changed in any way -- it only changes the mappings from FSNs to FSLs on the NSDB.
FSLの無効化は、基礎となるエクスポートまたは共有（使用中のファイルアクセスプロトコルに応じて）が何らかの方法で変更されることを意味するものではないことに注意してください。NSDBのFSNからFSLにマッピングを変更するだけです。
R7: It MUST be possible for the federation of servers to provide multiple namespaces.
R7：サーバー連合が複数の名前空間を提供することが可能である必要があります。
R8: USING THE FEDERATION INTERFACES:
R8：フェデレーションインターフェイスの使用：
a. It MUST be possible to query the fileserver named in an FSL to discover whether a junction exists at a given path within that FSL.
a. FSLに名前が付けられたファイルサーバーを照会して、そのFSL内の特定のパスに接合部が存在するかどうかを発見することが可能である必要があります。
b. It MAY be possible to query the fileserver named in an FSL to discover the junctions, if any, in that FSL. If this feature is implemented, the fileserver SHOULD report each junction's path within the FSL and the targeted FSN.
b. FSLに名前が付けられたファイルサーバーを照会して、そのFSLでジャンクションを発見することが可能かもしれません。この機能が実装されている場合、FileserverはFSL内の各ジャンクションのパスとターゲットFSNを報告する必要があります。
R9: The projected namespace (and the objects named by the namespace) MUST be accessible to clients via at least one of the following standard filesystem access protocols:
R9：投影された名前空間（および名前空間で名前が付けられたオブジェクト）は、次の標準ファイルシステムアクセスプロトコルの少なくとも1つを介してクライアントがアクセスできる必要があります。
a. The namespace SHOULD be accessible to clients via versions of the CIFS (Common Internet File System) protocol as described in [MS-SMB] [MS-SMB2] [MS-CIFS].
a. [MS-SMB] [MS-SMB2] [MS-CIFS]で説明されているように、CIFS（Common Internet File System）プロトコルのバージョン（Common Internet File System）プロトコルのバージョンを介して、名前空間にアクセスできる必要があります。
b. The namespace SHOULD be accessible to clients via the NFSv4 protocol as described in [RFC3530].
b. [RFC3530]で説明されているように、NFSV4プロトコルを介してクライアントが名前空間にアクセスできるようにする必要があります。
c. The namespace SHOULD be accessible to clients via the NFSv3 protocol as described in [RFC1813].
c. [RFC1813]で説明されているように、NFSV3プロトコルを介してクライアントが名前空間にアクセスできるようにする必要があります。
d. The namespace SHOULD be accessible to clients via the NFSv2 protocol as described in [RFC1094].
d. [RFC1094]で説明されているように、NFSV2プロトコルを介してクライアントが名前空間にアクセスできるようにする必要があります。
It must be understood that some of these protocols, such as NFSv3 and NFSv2, have no innate ability to access a namespace of this kind. Where such protocols have been augmented with other protocols and mechanisms (such as autofs or amd for NFSv3) to provide an extended namespace, we propose that these protocols and mechanisms may be used, or extended, in order to satisfy the requirements given in this document, and different clients may use different mechanisms.
NFSV3やNFSV2などのこれらのプロトコルの一部には、この種の名前空間にアクセスする生来の能力がないことを理解する必要があります。このようなプロトコルが他のプロトコルとメカニズム（NFSV3のAUTOFやAMDなど）で拡張された名前空間を提供している場合、このドキュメントに与えられた要件を満たすために、これらのプロトコルとメカニズムを使用または拡張することができることを提案します。、および異なるクライアントは、異なるメカニズムを使用する場合があります。
R10: USING THE FEDERATION INTERFACES, it MUST be possible to modify the NSDB mapping from an FSN to a set of FSLs to reflect the migration from one FSL to another.
R10：フェデレーションインターフェイスを使用して、FSNからFSLのセットへのNSDBマッピングを変更して、あるFSLから別のFSLへの移行を反映することができる必要があります。
R11: FSL migration SHOULD have little or no impact on the clients, but this is not guaranteed across all federation members.
R11：FSLの移行は、クライアントにほとんどまたはまったく影響を与えないはずですが、これはすべてのフェデレーションメンバーで保証されていません。
Whether FSL migration is performed transparently depends on whether the source and destination servers are able to do so. It is the responsibility of the administrator to recognize whether or not the migration will be transparent, and advise the system accordingly. The federation, in turn, MUST advise the servers to notify their clients, if necessary.
FSL移行が透過的に実行されるかどうかは、ソースサーバーと宛先サーバーがそうすることができるかどうかに依存します。移行が透明であるかどうかを認識し、それに応じてシステムにアドバイスすることは、管理者の責任です。連邦は、必要に応じて、クライアントに通知するようサーバーに助言する必要があります。
For example, on some systems, it may be possible to migrate a fileset from one system to another with minimal client impact because all client-visible metadata (inode numbers, etc.) are preserved during migration. On other systems, migration might be quite disruptive.
たとえば、一部のシステムでは、すべてのクライアントに可視されるメタデータ（イノード数など）が移行中に保存されるため、クライアントへの影響を最小限に抑えて、あるシステムから別のシステムにファイルセットを移行することが可能になる場合があります。他のシステムでは、移行は非常に破壊的かもしれません。
R12: USING THE FEDERATION INTERFACES, it MUST be possible to modify the NSDB mapping from an FSN to a set of FSLs to reflect the addition/removal of a replica at a given FSL.
R12：フェデレーションインターフェイスを使用して、FSNからFSLのセットへのNSDBマッピングを変更して、特定のFSLでのレプリカの追加/除去を反映することができる必要があります。
R13: Replication SHOULD have little or no negative impact on the clients.
R13：複製は、クライアントにマイナスの影響をほとんどまたはまったく持たないはずです。
Whether FSL replication is performed transparently depends on whether the source and destination servers are able to do so. It is the responsibility of the administrator initiating the replication to recognize whether or not the replication will be transparent, and advise the federation accordingly. The federation MUST advise the servers to notify their clients, if necessary.
FSLレプリケーションが透過的に実行されるかどうかは、ソースサーバーと宛先サーバーがそうすることができるかどうかに依存します。それは、複製が透明であるかどうかを認識するために複製を開始する管理者の責任であり、それに応じて連邦に助言することです。連邦は、必要に応じて、クライアントに通知するようサーバーに助言する必要があります。
For example, on some systems, it may be possible to mount any FSL of an FSN read/write, while on other systems, there may be any number of read-only replicas but only one FSL that can be mounted as read/write.
たとえば、一部のシステムでは、FSNの読み取り/書き込みのFSLをマウントすることが可能になる場合がありますが、他のシステムでは、読み取り/書き込みとして取り付けることができるFSLは1つだけです。
R14: USING THE FEDERATION INTERFACES, it SHOULD be possible to annotate the objects and relations managed by the federation protocol with arbitrary name/value pairs.
R14：フェデレーションインターフェイスを使用して、フェデレーションプロトコルによって管理されたオブジェクトと関係に任意の名前/値ペアを注釈することができるはずです。
These annotations are not used by the federation protocols -- they are intended for use by higher-level protocols. For example, an annotation that might be useful for a system administrator browsing the federation would be the "owner" of each FSN (i.e., "this FSN is for the home directory of Joe Smith"). As another example, the annotations may express hints used by the clients (such as priority information for NFSv4.1).
これらの注釈は、フェデレーションプロトコルでは使用されません。高レベルのプロトコルで使用することを目的としています。たとえば、連邦を閲覧するシステム管理者に役立つ可能性のある注釈は、各FSNの「所有者」になります（つまり、「このFSNはJoe Smithのホームディレクトリ向けです」）。別の例として、注釈はクライアントが使用するヒントを表現する場合があります（NFSV4.1の優先情報など）。
Both FSNs and FSLs may be annotated. For example, an FSN property might be "This is Joe Smith's home directory", and an FSL property might be "This instance of the FSN is at the remote backup site".
FSNとFSLの両方に注釈が付いている場合があります。たとえば、FSNプロパティは「これはジョースミスのホームディレクトリ」であり、FSLプロパティは「FSNのこのインスタンスがリモートバックアップサイトにある」かもしれません。
a. USING THE FEDERATION INTERFACES, it MUST be possible to query the system to find the annotations for a junction.
a. フェデレーションインターフェイスを使用すると、システムを照会してジャンクションの注釈を見つけることができる必要があります。
b. USING THE FEDERATION INTERFACES, it MUST be possible to query the system to find the annotations for an FSN.
b. フェデレーションインターフェイスを使用すると、FSNの注釈を見つけるためにシステムを照会することができる必要があります。
c. USING THE FEDERATION INTERFACES, it MUST be possible to query the system to find the annotations for an FSL.
c. フェデレーションインターフェイスを使用すると、FSLの注釈を見つけるためにシステムを照会することができる必要があります。
R15: It MUST be possible for the federation to project a namespace with a common root.
R15：連邦が共通のルートで名前空間を投影することが可能である必要があります。
a. It SHOULD be possible to define a root fileset that is exported by one or more fileservers in the federation as the top level of a namespace. (Corollary: There is one root fileset per namespace and it is possible to support multiple namespaces per federation.)
a. フェデレーション内の1つ以上のファイルアーバーによってエクスポートされるルートファイルセットを、名前空間のトップレベルとして定義することができるはずです。（結果：名前空間ごとに1つのルートファイルセットがあり、フェデレーションごとに複数の名前空間をサポートすることができます。）
b. It SHOULD be possible for a fileserver to locate an NSDB that stores the layout of a root fileset.
b. ファイルサーバーがルートファイルセットのレイアウトを保存するNSDBを見つけることができるはずです。
c. It SHOULD be possible to access, store, and update information related to a root fileset using the federation protocols.
c. フェデレーションプロトコルを使用して、ルートファイルセットに関連する情報にアクセス、保存、および更新できるはずです。
d. It SHOULD be possible to replicate root fileset information across multiple repositories.
d. 複数のリポジトリでルートファイルセット情報を複製することが可能です。
e. If a root fileset is defined, it SHOULD be possible to enable a fileserver to export that root fileset for client access.
e. ルートファイルセットが定義されている場合、ファイルサーバーがクライアントアクセスのためにそのルートファイルセットをエクスポートできるようにすることができるはずです。
f. If a root fileset is defined, it SHOULD be possible for multiple fileservers to project a common root with defined consistency semantics.
f. ルートファイルセットが定義されている場合、複数のファイルサーバーが定義された一貫性セマンティクスを備えた共通ルートを投影することができるはずです。
g. If a root fileset is defined, it SHOULD be stored using a compact representation that is compatible with heterogeneous fileserver implementations. The root fileset's internal format SHOULD contain enough information to generate any attributes, including referrals, required by the standard filesystem access protocols in R9.
g. ルートファイルセットが定義されている場合、異種のファイルサーバーの実装と互換性のあるコンパクトな表現を使用して保存する必要があります。root Filesetの内部形式には、R9の標準ファイルシステムアクセスプロトコルが必要とする紹介を含む属性を生成するのに十分な情報を含める必要があります。
N1: It is not necessary for the namespace to be known by any specific fileserver.
N1：名前空間が特定のfileserverで既知を使用する必要はありません。
In the same manner that clients do not need to have a priori knowledge of the structure of the namespace or its mapping onto federation members, the projected namespace can exist without individual fileservers knowing the entire organizational structure, or, indeed, without knowing exactly where in the projected namespace the filesets they host exist.
クライアントが名前空間の構造やフェデレーションメンバーへのマッピングに関する先験的な知識を持っている必要がないのと同じように、個々のファイルアーバーが組織構造全体を知ることなく、あるいは実際には正確な場所を知らずに、投影された名前空間が存在する可能性があります投影された名前空間ホストするファイルセットが存在します。
Fileservers do need to be able to handle referrals from other fileservers, but they do not need to know what path the client was accessing when the referral was generated.
fileserversは、他のFileserversからの紹介を処理できる必要がありますが、紹介が生成されたときにクライアントがどのパスにアクセスしているかを知る必要はありません。
N2: It is not necessary for updates and accesses to the NSDB data to occur in transaction or transaction-like contexts.
N2：NSDBデータへの更新とアクセスがトランザクションまたはトランザクションのようなコンテキストで発生する必要はありません。
One possible requirement that is omitted from our current list is that updates and accesses to the data stored in the NSDB (or individual NSDB nodes) occur within a transaction context. We were not able to agree whether the benefits of transactions are worth the complexity they add (both to the specification and its eventual implementation), but this topic is open for discussion.
現在のリストから省略されている要件の1つは、NSDB（または個々のNSDBノード）に保存されているデータの更新とアクセスがトランザクションコンテキスト内で発生することです。トランザクションの利点が彼らが追加する複雑さの価値があるかどうか（仕様とその最終的な実装の両方）かどうかに同意することはできませんでしたが、このトピックは議論のために開かれています。
Below is the draft of a proposed requirement that provides transactional semantics:
以下は、トランザクションセマンティクスを提供する提案された要件のドラフトです。
There MUST be a way to ensure that sequences of operations, including observations of the namespace (including finding the locations corresponding to a set of FSNs) and changes to the namespace or related data stored in the system (including the creation, renaming, or deletion of junctions, and the creation, altering, or deletion of mappings between FSN and filesystem locations), can be performed in a manner that provides predictable semantics for the relationship between the observed values and the effect of the changes.
名前空間の観測（FSNSのセットに対応する場所を見つけることを含む）や、システムに保存されている名前空間または関連データの変更（作成、名前変更、削除を含む、一連の操作が確実に行われる必要があります。Junction、およびFSNとファイルシステムの場所間のマッピングの作成、変更、または削除）は、観測された値と変化の効果との関係の予測可能なセマンティクスを提供する方法で実行できます。
It MUST be possible to protect sequences of operations by transactions with NSDB-wide or server-wide Atomicity, Consistency, Isolation, and Durability (ACID) semantics.
NSDB全体またはサーバー全体の原子性、一貫性、分離、耐久性（酸）セマンティクスを使用したトランザクションにより、一連の操作を保護することが可能である必要があります。
Assuming the Internet threat model, the federated resolution mechanism described in this document MUST be implemented in such a way to prevent loss of CONFIDENTIALITY, DATA INTEGRITY, and PEER ENTITY AUTHENTICATION, as described in [RFC3552].
インターネットの脅威モデルを仮定すると、[RFC3552]で説明されているように、このドキュメントで説明されているフェデレーション解像度メカニズムは、機密性、データの完全性、およびピアエンティティ認証の損失を防ぐために実装する必要があります。
CONFIDENTIALITY may be violated if an unauthorized party is able to eavesdrop on the communication between authorized servers and NSDB nodes and thereby learn the locations or other information about FSNs that they would not be authorized to discover via direct queries. DATA INTEGRITY may be compromised if a third party is able to undetectably alter the contents of the communication between servers and NSDB nodes. PEER ENTITY AUTHENTICATION is defeated if one server can masquerade as another server without proper authority, or if an arbitrary host can masquerade as a NSDB node.
許可されていない当事者が認可されたサーバーとNSDBノード間の通信を盗聴し、それにより、直接クエリを介して発見する権限がないFSNに関する場所またはその他の情報を学習できる場合、機密性に違反する可能性があります。サードパーティがサーバーとNSDBノード間の通信の内容を検出可能に変更できる場合、データの整合性が損なわれる可能性があります。1つのサーバーが適切な権限なしで別のサーバーを装っていれば、任意のホストがNSDBノードを装備できる場合、ピアエンティティ認証は敗北します。
Well-established techniques for providing authenticated channels may be used to defeat these attacks, and the protocol MUST support at least one of them.
認証されたチャネルを提供するための十分に確立された手法を使用して、これらの攻撃を打ち負かすことができ、プロトコルは少なくとも1つをサポートする必要があります。
For example, if Lightweight Directory Access Protocol (LDAP) is used to implement the query mechanism [RFC4510], then Transport Layer Security (TLS) may be used to provide both authentication and integrity [RFC5246] [RFC4513]. If the query protocol is implemented on top of Open Network Computing / Remote Procedure Call (ONC/RPC), then RPCSEC_GSS may be used to fill the same role [RFC2203] [RFC2743].
たとえば、Lightweight Directory Access Protocol（LDAP）を使用してクエリメカニズム[RFC4510]を実装する場合、輸送層セキュリティ（TLS）を使用して、認証と整合性の両方を提供できます[RFC5246] [RFC4513]。クエリプロトコルがオープンネットワークコンピューティング /リモートプロシージャコール（ONC / RPC）の上に実装されている場合、RPCSEC_GSSを使用して同じ役割を果たすことができます[RFC2203] [RFC2743]。
A federation could contain multiple Public Key Infrastructure (PKI) trust anchors [RFC5280]. The federation protocols SHOULD define a mechanism for managing a fileserver's NSDB trust anchors [TA-MGMT-REQS]. A general purpose trust anchor management protocol [TAMP] would be appropriate, though it might be desirable for the federation protocols to facilitate trust anchor management by, for example, using trust anchor interchange formats [TA-FORMAT].
連邦には、複数の公開キーインフラストラクチャ（PKI）トラストアンカー[RFC5280]を含めることができます。フェデレーションプロトコルは、FileserverのNSDB Trust Anchors [Ta-Mgmt-Reqs]を管理するためのメカニズムを定義する必要があります。一般的な目的トラストアンカー管理プロトコル[TAMP]が適切ですが、たとえば、信頼アンカーインターチェンジ形式[TA-Format]を使用することにより、信頼アンカー管理を促進することが望ましい場合があります。
It is useful to note that the requirements described in this document lead naturally to a system with distributed authorization, which has scalability and manageability benefits.
このドキュメントで説明されている要件は、スケーラビリティと管理性の利点を持つ分散承認を備えたシステムに自然につながることに注意することが有用です。
FSNs are likely to be long-lived resources. Therefore, the privilege to create FSNs SHOULD be carefully controlled. To assist in determining if an FSN is referenced by a junction somewhere in the federation, the NSDB records SHOULD include non-authoritative informational annotations recording the locations of any such junctions. These annotations are non-authoritative because a junction might be created, deleted, or modified by an individual that does not have permission to modify the NSDB records.
FSNは、長命のリソースである可能性があります。したがって、FSNを作成する特権は慎重に制御する必要があります。FSNが連邦のどこかでジャンクションによって参照されるかどうかを判断するのを支援するために、NSDBレコードには、そのような接合部の場所を記録する非認証情報注釈を含める必要があります。これらの注釈は、NSDBレコードを変更する許可を持たない個人によって接合部が作成、削除、または変更される可能性があるため、非認証です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC3530] Shepler、S.、Callaghan、B.、Robinson、D.、Thurlow、R.、Beame、C.、Eisler、M。、およびD. Noveck、「ネットワークファイルシステム（NFS）バージョン4プロトコル」、RFC 3530、2003年4月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[RFC4122] Leach、P.、Mealling、M。、およびR. Salz、「普遍的にユニークな識別子（UUID）URNネームスペース」、RFC 4122、2005年7月。
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）：技術仕様ロードマップ」、RFC 4510、2006年6月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File System Version 4 Minor Version 1", RFC 5661, January 2010.
[RFC5661] Shepler、S.、Eisler、M。、およびD. Noveck、「ネットワークファイルシステムバージョン4マイナーバージョン1」、RFC 5661、2010年1月。
[MS-CIFS] Microsoft Corporation, "Common Internet File System (CIFS) Protocol Specification", MS-CIFS 2.0, November 2009.
[MS-CIFS] Microsoft Corporation、「一般的なインターネットファイルシステム（CIFS）プロトコル仕様」、MS-CIFS 2.0、2009年11月。
[MS-SMB] Microsoft Corporation, "Server Message Block (SMB) Protocol Specification", MS-SMB 17.0, November 2009.
[MS-SMB] Microsoft Corporation、「サーバーメッセージブロック（SMB）プロトコル仕様」、MS-SMB 17.0、2009年11月。
[MS-SMB2] Microsoft Corporation, "Server Message Block (SMB) Version 2 Protocol Specification", MS-SMB2 19.0, November 2009.
[MS-SMB2] Microsoft Corporation、「サーバーメッセージブロック（SMB）バージョン2プロトコル仕様」、MS-SMB2 19.0、2009年11月。
[RFC1094] Nowicki, B., "NFS: Network File System Protocol specification", RFC 1094, March 1989.
[RFC1094] Nowicki、B。、「NFS：ネットワークファイルシステムプロトコル仕様」、RFC 1094、1989年3月。
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, June 1995.
[RFC1813] Callaghan、B.、Pawlowski、B。、およびP. Staubach、「NFSバージョン3プロトコル仕様」、RFC 1813、1995年6月。
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997.
[RFC2203] Eisler、M.、Chiu、A。、およびL. Ling、「RPCSEC_GSSプロトコル仕様」、RFC 2203、1997年9月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743] Linn、J。、「Generic Security Service Application Program Interfaceバージョン2、Update 1」、RFC 2743、2000年1月。
[RFC4513] Harrison, R., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[RFC4513] Harrison、R。、「Lightweight Directory Access Protocol（LDAP）：認証方法とセキュリティメカニズム」、RFC 4513、2006年6月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[TA-FORMAT] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Format", Work in Progress, October 2009.
[Ta-format] Housley、R.、Ashmore、S。、およびC. Wallace、「Trust Anchor Format」、2009年10月の作業。
[TA-MGMT-REQS] Reddy, R. and C. Wallace, "Trust Anchor Management Requirements", Work in Progress, September 2009.
[Ta-Mgmt-reqs] Reddy、R。およびC. Wallace、「信頼アンカー管理要件」、2009年9月、進行中の作業。
[TAMP] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Management Protocol (TAMP)", Work in Progress, December 2009.
[TAMP] Housley、R.、Ashmore、S。、およびC. Wallace、「Trust Anchor Management Protocol（TAMP）」、2009年12月の作業。
We would like to thank Robert Thurlow of Sun Microsystems for helping to author this document.
この文書の執筆を支援してくれたSun MicrosystemsのRobert Thurlowに感謝します。
We would also like to thank Peter McCann and Nicolas Williams for their comments and suggestions.
また、ピーターマッキャンとニコラスウィリアムズのコメントと提案に感謝します。
Authors' Addresses
著者のアドレス
James Lentini NetApp 1601 Trapelo Rd, Suite 16 Waltham, MA 02451 US
James Lentini NetApp 1601 Trapelo Rd、Suite 16 Waltham、MA 02451 US
Phone: +1 781-768-5359
EMail: jlentini@netapp.com
Craig Everhart NetApp 7301 Kit Creek Rd Research Triangle Park, NC 27709 US
Craig Everhart NetApp 7301 Kit Creek Rd Research Triangle Park、NC 27709 US
Phone: +1 919-476-5320
EMail: everhart@netapp.com
Daniel Ellard BBN Technologies 10 Moulton Street Cambridge, MA 02138 US
ダニエルエラードBBNテクノロジーズ10モールトンストリートケンブリッジ、マサチューセッツ州02138 US
Phone: +1 617-873-8000
EMail: dellard@bbn.com
Renu Tewari IBM Almaden 650 Harry Rd San Jose, CA 95120 US
Renu Tewari Ibm Almaden 650 Harry Rd San Jose、CA 95120 US
EMail: tewarir@us.ibm.com
Manoj Naik
IBM Almaden
650 Harry Rd
San Jose, CA 95120
US
EMail: manoj@almaden.ibm.com