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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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」（ファイルセット名）と呼ばれる名前を持ち、各物理ファイルシステムは、ファイルセットの位置（「FSL」）を有します。ファイルセットは、ファイルやディレクトリを含むディレクトリツリーであり、また、他のファイルセットへの参照が含まれていてもよいです。これらの参照は、「ジャンクション」と呼ばれています。場所の独立性を提供するために、接合は、実際のリソース（複数可）の位置に関する情報が含まれているが、代わりに位置情報を検索するために使用することができますFSNが含まれていません。 FSL（S）にFSNからマッピングするために使用することができるサービスは、名前空間データベース（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を持っています。フェデレーションメンバーは、ファイルサーバとNSDBノードの任意の数を含んでいてもよいです。この図では、αおよびβはそれぞれ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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
すべてのクライアントビュー間で名前空間の整合性を保証するためにフェデレーションの意図ではありません。名前空間の異なる部分が異なるエンティティによって投与することができるので、別のエンティティによって管理され、その上に名前空間の一部は、変更されたため、クライアントは、一方のエンティティによって管理名前空間の古い領域にアクセスされる可能性があります。
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.
、ファイルセットのレプリカを加算ジャンクションを解決し、接合部を作成、ファイルセットを作成する：このセクションでは、実施例とフェデレーテッド・ファイル・システム・プロトコルによって促進基本動作の説明を提供します。
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（S）などのファイルセットの実装の位置（複数可）を発現します。
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（単数または複数）および関連情報を追跡しますNSDBノードを選択します。
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.
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.
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.ターゲットFSNを実装FSLsのセットを要求NSDBノードとサーバコンタクト。 NSDBノードはFSLsのセットで応答します。
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.サーバがクライアントによって使用される場所の種類にFSLsの一つ以上を変換（例えば、ネットワークファイルシステム（のNFSv4）fs_location、[RFC3530]に記載されているように）。
6. The server redirects (in whatever manner is appropriate for the client) the client to the location(s).
6.サーバーリダイレクト（どのようにして、クライアントのために適切である）クライアント位置（S）へ。
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.
これらのステップは、クライアントが（ディレクトリとしてクライアントに表示される）オブジェクトを参照しようとして、フェデレーションメンバーALPHAで、サーバXへの要求1を送信し、図2に示されています。サーバXは、参照されるオブジェクトが実際に異なるファイルセット内のディレクトリを指す接合であることを認識する。サーバXは、接合の対象の位置を知るための責任NSDBは、フェデレーションメンバーBETAのNSDBあると、接合部でFSNから見出します。サーバXは、ディレクトリの現在の場所を求めて、BETAのNSDBへの要求2を送信します。 NSDBは、ディレクトリはクライアントが要求を送信し、サーバーY.の「新しい」場所であることを示す、クライアントへの応答4を送り、ディレクトリがサーバーY.サーバーX上に配置されているサーバーを伝える、サーバXへの応答3を送信します図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.
ファイルサーバ：ネットワークファイルシステムへのアクセスプロトコルを介してファイルシステムをエクスポートするサーバー。
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.
ファイルセット内のすべてのファイルが一つのディレクトリの子孫である、とファイルセットは、ファイルシステムにまたがっていないことに注意してください。
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は、（NFSv4のための）fs_locationとしてクライアントが直接アクセスできるリソースのプロトコル固有の記述に変換することができるものであること、または（CIFS）の名称を共有しなければなりません。すべてではないFSLsが明示的に限り、それらはファイルサーバー上のエクスポートされたパス内に含まれているとしてエクスポートする必要があることに注意してください。
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つFSLsは同じ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.
ジャンクション：別のファイルセット内のオブジェクトを、現在のファイルセットにディレクトリ名をリンクするために使用されるファイルシステムオブジェクト。別のファイルセットのルートに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（名前空間データベース）サービス：FSLsへのFSNをマップサービス。 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サービスの一部を実装してのFSNの特定のパーティションを実装FSLs（および関連情報）を追跡するための責任があるサーバーの名前または場所。
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.
レプリカは、可用性やパフォーマンスを向上させるために使用することができます。同じファイルセットの複製の更新は同じ順序で起こるように見える必要があるため、各レプリカは、任意の瞬間に自己整合しています。
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.
シングルトンサーバ：一つだけのサーバーを含むサーバーのコレクションです。スタンドアロンのファイルサーバ。
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：すべての要件は、フェデレーションプロトコルとファイルサーバ（すなわち、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.
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.
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.
第二のプリンシパルが特定の操作を実行することを要求するプリンシパルの権限は、最終的に第二によって決定されます。認可は、サーバーのサーバー収集やセットで同様の操作により分割することができます。ユーザーは、フェデレーション内の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にバインドFSLsについて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：フェデレーション・プロトコルは、クライアント向けのプロトコルのためのファイルサーバで使用中の既存の認証/承認メカニズムへの変更を要求してはなりません。
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.
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.
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.
ファイルサーバは、特定のファイルセットの責任NSDBノードを見つけることができるいくつかの方法があります。一つのアプローチは、DNSインフラストラクチャ所与、NSDBのノードをホストするサーバーの完全修飾ドメイン名（FQDN）によってNSDBノードの位置を指定することです。別のアプローチは、NSDBのノードの位置を解決するために、別のDNSスタイルの階層を使用することです。
The FSN identifier is the index used by the NSDB node to
identify the target fileset.
There are several ways to represent FSN identifiers. One approach could use 128-bit Universally Unique IDentifiers (UUIDs) as described in [RFC4122].
FSN識別子を表現する方法はいくつかあります。 [RFC4122]に記載されているように一つのアプローチは、128ビットの汎用一意識別子（UUIDを）使用することができます。
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のURLによって表すことができる：NSDBスキーム名//nsdb.example.com/UUID、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：（などNSDBsとFSLsなど）フェデレーションサービスの場所は、彼らがそれらを正しくアクセスするフェデレーションのすべてのメンバーが解釈できるように指定することができます。
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.)
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).
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は不変でなければなりません。これらの変換の下でFSL（S）の変化へのFSNからのみのマッピング。
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フォーマットは、可変サイズであってもよいです。フォーマットのサイズが可変である場合には、ファイルサーバの実装は、サポートされる最大FSNのサイズを有することができます。 FSNのサイズをバウンディングことで、いくつかのファイルサーバの実装では、効率的に安定したストレージでの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：FEDERATIONインタフェースを使用して、ファイルセット用の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).
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とのFSNは、ファイルセットの独立して存在することができる必要が割り当てられる前に存在することができる要件は、便利な方法で名前空間の構成を簡素化することを意図しています。例えば、彼らは既存のファイルセットへのFSNを割り当てることにより、名前空間に既存のファイルセットを組み込むための管理を許可します。彼らはまた、名前空間の構造は、従来のコンポーネントファイルセットの作成に定義されることを可能にします。いずれの場合も、名前空間が一貫した方法で構築されていることを確実にするためのFSN及びFSNツーFSLマッピングでNSDBを更新エンティティの責任です。 （これを達成する最も簡単な方法は、FSN及びFSNツーFSLマッピングが常にその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の（NSDBノード位置及び識別子の両方を含む）全体FSNを指定してもよいし、管理者のみ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.
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。 FEDERATIONインタフェースを使用して、特定のローカルボリューム、パス、エクスポートパス、およびエクスポートオプションを指定することで、フェデレーション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：FEDERATIONインターフェースを使用して、ターゲット・ファイルセットの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.
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).
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は：FEDERATIONインタフェースを使用して、FSNを無効にすることも可能でなければなりません。
a. If a junction refers to an FSN that is invalid, attempting
to traverse the junction MUST fail.
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は：FEDERATIONインタフェースを使用して、FSLを無効にすることも可能でなければなりません。
a. An invalid FSL MUST NOT be returned as the result of
resolving a junction.
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のFSLsへのFSNからのマッピングを変更します。
R7: It MUST be possible for the federation of servers to provide multiple namespaces.
R7は：サーバの連携が複数の名前空間を提供することが可能でなければなりません。
R8: USING THE FEDERATION INTERFACES:
R8：FEDERATIONインターフェイスを使用：
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.
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で指定されたファイルサーバーを照会することも可能です。この機能が実装されている場合は、ファイルサーバは、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].
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のためのautofsまたは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：FEDERATIONインターフェースを使用し、それは別のFSLからの移行を反映するようにFSLsのセットにFSNからNSDBマッピングを変更することができなければなりません。
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.
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.
例えば、いくつかのシステムでは、すべてのクライアント可視メタデータ（iノード番号、等）を移行中に保存されるので、最小限のクライアントの影響であるシステムから別のシステムにファイルセットを移行することが可能です。他のシステムでは、移行は非常に破壊的であるかもしれません。
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：FEDERATIONインターフェースを使用して、それが所定のFSLにレプリカの追加/削除を反映するようにFSLsのセットにFSNからNSDBマッピングを変更することができなければなりません。
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.
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.
例えば、いくつかのシステムでは、他のシステムで、任意の読み取り専用レプリカの数が、読み取り/書き込みとして実装することができる唯一のFSLがあってもよいが、読み取り/書き込みFSNのFSLをマウントすることも可能です。
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：FEDERATIONインターフェースを使用して、それは任意の名前/値のペアを持つフェデレーション・プロトコルによって管理されるオブジェクトとの関係に注釈を付けることが可能であるべきです。
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).
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とFSLsは注釈を付けていてもよいです。例えば、FSNプロパティは、「これはジョー・スミスのホームディレクトリである」、とFSLプロパティは「FSNのこのインスタンスは、遠隔バックアップ・サイトである」かもしれないかもしれません。
a. USING THE FEDERATION INTERFACES, it MUST be possible to query the system to find the annotations for a junction.
A。 FEDERATIONインタフェースを使用して、接合のための注釈を見つけるために、システムを照会することも可能でなければなりません。
b. USING THE FEDERATION INTERFACES, it MUST be possible to query the system to find the annotations for an FSN.
B。 FEDERATIONインタフェースを使用して、FSNのための注釈を見つけるために、システムを照会することも可能でなければなりません。
c. USING THE FEDERATION INTERFACES, it MUST be possible to query the system to find the annotations for an FSL.
C。 FEDERATIONインタフェースを使用して、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.)
b. It SHOULD be possible for a fileserver to locate an NSDB that stores the layout of a root fileset.
B。ファイルサーバは、ルートファイルセットのレイアウトを保存するMSDBを検索することが可能なはずです。
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.
電子。ルートファイルセットが定義されている場合は、クライアントアクセス用にそのルートファイルセットをエクスポートするファイルサーバを有効にすることが可能なはずです。
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.
グラム。ルートファイルセットが定義されている場合、それは、異種ファイルサーバの実装と互換性のあるコンパクトな表現を使用して保存されるべきです。ルートファイルセットの内部形式はR9で標準ファイルシステムアクセスプロトコルによって必要と紹介、などの任意の属性を生成するために十分な情報を含むべきです。
N1: It is not necessary for the namespace to be known by any specific fileserver.
N1：これは、任意の特定のファイルサーバによって知られるように名前空間の必要はありません。
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.
ファイルサーバは、他のファイルサーバからの紹介を処理できるようにする必要がありますが、彼らは紹介が生成されたとき、クライアントがアクセスしていたものをパス知る必要はありません。
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.
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.
作成、名前変更、または削除を含む名前空間の観察を含む動作のシーケンスは、（のFSNのセットに対応する場所を見つけることを含む）ことを確実にする方法及びシステムに格納された名前空間または関連データの変更（存在していなければなりません接合部、および作成、変更、または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全体またはサーバー全体の原子性、一貫性、独立性、耐久性（ACID）のセマンティクスとの取引による操作のシーケンスを保護することが可能でなければなりません。
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].
LDAP（Lightweight Directory Access Protocol）がクエリメカニズム[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]を含めることができます。フェデレーション・プロトコルは[TA-MGMT-REQS]ファイルサーバのNSDBのトラストアンカーを管理するためのメカニズムを定義する必要があります。フェデレーションプロトコルはトラストアンカー交換フォーマット[TA-FORMAT]を用いて、例えば、トラストアンカーの管理を容易にすることが望ましいかもしれないものの、汎用トラストアンカー管理プロトコル[TAMP]は、適切であろう。
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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、キャラハン、B.、ロビンソン、D.、Thurlow、R.、Beame、C.、アイスラー、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]レスコラ、E.とB.コーバー、BCP 72、RFC 3552、2003年7月、 "セキュリティ上の考慮事項の書き方RFCテキストのためのガイドライン"。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[RFC4122]リーチ、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.、 "ライトウェイトディレクトリアクセスプロトコル（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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネット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.、アイスラー、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]マイクロソフトコーポレーション、 "共通インターネットファイルシステム（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]マイクロソフトコーポレーション、 "サーバーメッセージブロック（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]マイクロソフトコーポレーション、 "サーバーメッセージブロック（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]キャラハン、B.、ポロウスキー、B.、およびP.ストーバック、 "NFSバージョン3プロトコル仕様"、RFC 1813、1995年6月。
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997.
[RFC2203]アイスラー、M.、チウ、A.、およびL.リン、 "RPCSEC_GSSプロトコル仕様"、RFC 2203、1997年9月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェースバージョン2、アップデート1"、RFC 2743、2000年1月。
[RFC4513] Harrison, R., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[RFC4513]ハリソン、R.、 "ライトウェイトディレクトリアクセスプロトコル（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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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.、アシュモア、S.、およびC.ウォレス、 "トラストアンカーフォーマット"、進歩、2009年10月に作業。
[TA-MGMT-REQS] Reddy, R. and C. Wallace, "Trust Anchor Management Requirements", Work in Progress, September 2009.
[TA-MGMT-REQS]レディ、R.とC.ウォレス、 "トラストアンカーの管理の要件"、進歩、2009年9月での作業。
[TAMP] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Management Protocol (TAMP)", Work in Progress, December 2009.
[TAMP] Housley氏、R.、アシュモア、S.、およびC.ウォレス、 "トラストアンカー管理プロトコル（TAMP）"、進歩、2009年12月の作業。
Appendix A. Acknowledgments
付録A.謝辞
We would like to thank Robert Thurlow of Sun Microsystems for helping to author this document.
私たちは、この文書の作成に助けるためサン・マイクロシステムズのロバート・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
ジェームズ・レンティーニNetAppの1601 Trapelo Rdを、スイート16ウォルサム、MA 02451米国
Phone: +1 781-768-5359 EMail: jlentini@netapp.com
電話：+1 781-768-5359電子メール：jlentini@netapp.com
Craig Everhart NetApp 7301 Kit Creek Rd Research Triangle Park, NC 27709 US
クレイグ・エバハートNetAppの7301キットクリークRdのリサーチトライアングルパーク、ノースカロライナ州27709米国
Phone: +1 919-476-5320 EMail: everhart@netapp.com
電話：+1 919-476-5320電子メール：everhart@netapp.com
Daniel Ellard BBN Technologies 10 Moulton Street Cambridge, MA 02138 US
ダニエルEllard BBNテクノロジーズ10モールトンストリートケンブリッジ、MA 02138米国
Phone: +1 617-873-8000 EMail: dellard@bbn.com
電話：+1 617-873-8000電子メール：dellard@bbn.com
Renu Tewari IBM Almaden 650 Harry Rd San Jose, CA 95120 US
レーヌTewari IBMアルマデン650ハリーRdのサンノゼ、CA 95120米国
EMail: tewarir@us.ibm.com
メールアドレス：tewarir@us.ibm.com
Manoj Naik IBM Almaden 650 Harry Rd San Jose, CA 95120 US
ManojさんナイクIBMアルマデン650ハリーRdのサンノゼ、CA 95120米国
EMail: manoj@almaden.ibm.com
メールアドレス：manoj@almaden.ibm.com