Network Working Group S. Shepler
Request for Comments: 2624 Sun Microsystems, Inc.
Category: Informational June 1999
NFS Version 4 Design Considerations
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
The main task of the NFS version 4 working group is to create a protocol definition for a distributed file system that focuses on the following items: improved access and good performance on the Internet, strong security with negotiation built into the protocol, better cross-platform interoperability, and designed for protocol extensions. NFS version 4 will owe its general design to the previous versions of NFS. It is expected, however, that many features will be quite different in NFS version 4 than previous versions to facilitate the goals of the working group and to address areas that NFS version 2 and 3 have not.
NFSバージョン4ワーキンググループの主なタスクは、以下の項目に焦点を当てて分散ファイルシステムのためのプロトコル定義を作成することです：インターネット上のアクセスと優れたパフォーマンスを改善し、プロトコルに組み込まれた交渉で、強力なセキュリティ、より良いクロスプラットフォーム相互運用性、およびプロトコル拡張のために設計されました。 NFSバージョン4は、NFSの以前のバージョンへの一般的な設計を借ります。多くの機能がワーキンググループの目標を容易にし、NFSバージョン2と3を持っていない領域に対処するために、以前のバージョンよりもNFSバージョン4で全く異なるであろうこと、しかし、期待されています。
This design considerations document is meant to present more detail than the working group charter. Specifically, it presents the areas that the working group will investigate and consider while developing a protocol specification for NFS version 4. Based on this investigation the working group will decide the features of the new protocol based on the cost and benefits within the specific feature areas.
この設計上の考慮事項文書はワーキンググループ憲章よりも詳細を提示するためのものです。具体的には、この調査に基づいて、NFSバージョン4のためのプロトコル仕様を開発しながら、ワーキンググループが調査し、検討する分野を提示し、特定の機能エリア内のコストと便益に基づいて新しいプロトコルの機能を決定するワーキンググループ。
Key Words
キーワード
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 RFC 2119.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈されます。
Table of Contents
目次
1. NFS Version 4 Design Considerations . . . . . . . . . . . . . 2
2. Ease of Implementation or Complexity of Protocol . . . . . . 3
2.1. Extensibility / layering . . . . . . . . . . . . . . . . . 3
2.2. Managed Extensions or Minor Versioning . . . . . . . . . . 3
2.3. Relationship with Older Versions of NFS . . . . . . . . . . 4
3. Reliable and Available . . . . . . . . . . . . . . . . . . . 5
4. Scalable Performance . . . . . . . . . . . . . . . . . . . . 5
4.1. Throughput and Latency via the Network . . . . . . . . . . 6
4.2. Client Caching . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Disconnected Client Operation . . . . . . . . . . . . . . . 7
5. Interoperability . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Platform Specific Behavior . . . . . . . . . . . . . . . . 8
5.2. Additional or Extended Attributes . . . . . . . . . . . . . 8
5.3. Access Control Lists . . . . . . . . . . . . . . . . . . 9
6. RPC Mechanism and Security . . . . . . . . . . . . . . . . 10
6.1. User identification . . . . . . . . . . . . . . . . . . . 10
6.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.1. Transport Independence . . . . . . . . . . . . . . . . 11
6.2.2. Authentication . . . . . . . . . . . . . . . . . . . . 11
6.2.3. Data Integrity . . . . . . . . . . . . . . . . . . . . 11
6.2.4. Data Privacy . . . . . . . . . . . . . . . . . . . . . 12
6.2.5. Security Negotiation . . . . . . . . . . . . . . . . . 12
6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Internet Accessibility . . . . . . . . . . . . . . . . . . 13
7.1. Congestion Control and Transport Selection . . . . . . . 13
7.2. Firewalls and Proxy Servers . . . . . . . . . . . . . . . 14
7.3. Multiple RPCs and Latency . . . . . . . . . . . . . . . . 14
8. File locking / recovery . . . . . . . . . . . . . . . . . . 15
9. Internationalization . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . 17
10.1. Denial of Service . . . . . . . . . . . . . . . . . . . 17
11. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 21
13. Author's Address . . . . . . . . . . . . . . . . . . . . . 21
14. Full Copyright Statement . . . . . . . . . . . . . . . . . 22
As stated in the charter, the first deliverable for the NFS version 4 working group is this design considerations document. This document is to cover the "limitations and deficiencies of NFS version 3". This document will also be used as a mechanism to focus discussion and avenues of investigation as the definition of NFS version 4 progresses. Therefore, the contents of this document cover the general functional/feature areas that are anticipated for NFS version 4. Where appropriate, discussion of current NFS version 2 and 3 practice will be presented along with other appropriate references to current distributed file system practice.
憲章で述べたように、NFSバージョン4ワーキンググループの最初の成果は、この設計上の考慮事項文書です。この文書では、「NFSバージョン3の限界や欠陥」をカバーすることです。この文書はまた、議論とNFSバージョン4が進むの定義として、調査の道を集中するメカニズムとして使用されます。したがって、この文書の内容は、NFSバージョン4適切ために予想される一般的な機能/特徴領域をカバーし、現在のNFSバージョン2及び3実際の議論は、現在の分散ファイルシステムの実施に他の適切な参照と一緒に提示されます。
One of the strengths of NFS has been the ability to implement a client or server with relative ease. The eventual size of a basic implementation is relatively small. The main reason for keeping NFS as simple as possible is that a simple protocol design can be described in a simple specification that promotes straightforward, interoperable implementations. All protocols can run into problems when deployed on real networks, but simple protocols yield problems that are easier to diagnose and correct.
NFSの強みの一つは、比較的容易にクライアントやサーバーを実装する機能となっています。基本的な実装の最終的な大きさは比較的小さいです。できるだけ簡単にNFSを維持するための主な理由は単純なプロトコルの設計は簡単、相互運用可能な実装を促進簡単明細書に記載することができることです。実際のネットワーク上に展開すると、すべてのプロトコルが問題に実行することができますが、簡単なプロトコルは診断が容易と正しい問題を生じます。
With NFS' relative simplicity, the addition or layering of functionality has been easy to accomplish. The addition of features like the client automount or autofs, client side disk caching and high availability servers are examples. This type of extensibility is desirable in an environment where problem solutions do not require protocol revision. This extensibility can also be helpful in the future where unforeseen problems or opportunities can be solved by layering functionality on an existing set of tools or protocol.
NFSの相対的なシンプルさと、機能の追加やレイヤーを達成することは容易となっています。クライアントの自動マウントやautofsのような機能の追加、クライアント側のディスクキャッシュと高可用性サーバがその例です。拡張性のこのタイプは、問題の解決策は、プロトコルの改訂を必要としない環境では望ましいです。この拡張はまた、予期せぬ問題や機会がツールやプロトコルの既存のセットに機能を積層することによって解決することができ、今後の参考にすることができます。
For those cases where the NFS protocol is deficient or where a minor modification is the best solution for a problem, a minor version or a managed extension could be helpful. There have been instances with NFS version 2 and 3 where small straightforward functional additions would have increased the overall value of the protocol immensely. For instance, the PATHCONF procedure that was added to version 2 of the MOUNT protocol would have been more appropriate for the NFS protocol. WebNFS [RFC2054][RFC2055] overloading of the LOOKUP procedure for NFS versions 2 and 3 would have been more cleanly implemented in a new LOOKUP procedure.
NFSプロトコルが不足しているかのマイナーな変更が問題の最善の解決策であるもの例について、マイナーバージョンまたは管理対象の拡張子が有用である可能性があります。小さな簡単な機能追加が非常プロトコルの全体的な価値を増加していたであろうNFSバージョン2と3を持つインスタンスがありました。例えば、MOUNTプロトコルのバージョン2に加えPATHCONF手順は、NFSプロトコルのためのより適切であったであろう。 NFSバージョン2および3のルックアップ手順の過負荷WebNFSの[RFC2054]、[RFC2055]は、よりきれい新しいLOOKUP手順で実装されていたであろう。
However, the perceived size and burden of using a change of RPC version number for the introduction of new functionality led to no or slow change. It is possible that a new NFS protocol could allow for the rare instance where protocol extension within the RPC version number is the most prudent course and an RPC revision would be unnecessary or impractical.
しかし、新機能の導入のためのRPCのバージョン番号の変更を使用しての知覚サイズや負担がないか、または遅い変化につながっていません。新しいNFSプロトコルはRPCバージョン番号内のプロトコル拡張が最も賢明なコースですし、RPCのリビジョンが不要または非現実的で希少なインスタンスを可能にする可能性があります。
The areas of an NFS protocol which are most obviously volatile are new orthogonal procedures, new well-defined file or directory attributes and potentially new file types. As an example, potential file types of the future could be a type such as "attribute" that represents a named file stream or a "dynamic" file type that generates dynamic data in response to a "query" procedure from the client.
最も明らかに揮発性であるNFSプロトコルの領域は新しい直交する手順、新しい明確に定義されたファイルまたはディレクトリの属性と潜在的に新しいファイルタイプです。例として、将来の潜在的なファイルの種類は、このような名前のファイルストリームまたはクライアントからの「クエリ」の手順に応じて、動的なデータを生成し、「ダイナミック」ファイルの種類を表し、「属性」とタイプである可能性があります。
It is possible and highly desirable that these types of additions be done without changing the overall design model of NFS without significant effort or delay.
追加のこれらのタイプは、多大な労力や遅延なくNFSの全体的な設計モデルを変更せずに行うことを可能と非常に望ましいです。
A strong consideration should be given to a NFS protocol mechanism for the introduction of this type of new functionality. This is obviously in contrast to using the standard RPC version mechanism to provide minor changes. The process of using RPC version numbers to introduce new functionality brings with it a lot of history which may not technically prevent its use. However, the historical issues involved will need to be addressed as part of the NFS version 4 protocol work; this should increase the ability for current and future success of the protocol.
強力な考慮事項は、新機能のこのタイプの導入のためのNFSプロトコル機構に与えられるべきです。これは、マイナーな変更を提供するために、標準のRPCのバージョンメカニズムを使用してとは対照的に明らかです。新しい機能を導入するRPCのバージョン番号を使用するプロセスは、それを技術的にその使用を防ぐものではありません歴史の多くをもたらします。しかし、関係する歴史問題は、NFSバージョン4プロトコルの作業の一環として対処する必要があります。これは、プロトコルの現在および将来の成功のための能力を高める必要があります。
As background, the RPC protocol described in [RFC1831] uses a version number to describe the set of procedure calls, replies, and their semantics. Any change in this set must be reflected in a new version number for the program. An example of this was the MOUNTPROC_PATHCONF procedure added in version 2 of the MOUNT protocol. Except for the addition of this new procedure, the protocol was unchanged. Many thought this protocol revision was unnecessary, since the RPC protocol already allows certain procedures not be implemented and defines a PROC_UNAVAIL error.
背景として、[RFC1831]に記載のRPCプロトコルは、プロシージャ・コールのセットを記述するためにバージョン番号を使用して応答し、そしてそれらの意味論。このセットでの変更は、プログラムの新しいバージョン番号に反映されなければなりません。この例は、マウントプロトコルのバージョン2で追加さMOUNTPROC_PATHCONF手順でした。この新しい手順の追加を除いて、プロトコルは変わりませんでした。 RPCプロトコルが既に特定の手順が実施されない可能とPROC_UNAVAIL誤差を定義するための多くの思考、このプロトコルリビジョンは、不要でした。
Another historical data-point from NFS version 2 and 3 is the support (or lack) of symbolic links. Servers that cannot support this feature will simply reject calls to the SYMLINK and READLINK procedures. Additionally, NFS version 4 may describe many file attributes which cannot be supported by the server or file systems on the server. Therefore, the protocol must support a discovery mechanism that allows clients to determine which features of the protocol are supported by a server.
NFSバージョン2及び3から別の過去のデータポイントは、シンボリックリンクのサポート（またはその欠如）です。この機能をサポートすることはできませんサーバーは、単にSYMLINKとREADLINK手続きへの呼び出しを拒否します。また、NFSバージョン4は、サーバ上のサーバやファイルシステムでサポートすることができない多くのファイルの属性を記述することができます。したがって、プロトコルは、クライアントがサーバによってサポートされているプロトコルの機能を確認することを可能にする検出メカニズムをサポートしている必要があります。
NFS version 4 will be a self contained protocol in that it will not have any dependencies on the previous versions of NFS. Stated another way, an NFS version 4 server or client will not require a NFSv2 or NFSv3 implementation be present for NFS version 4 to function as designed. It should also be noted that having an NFS version 2 or 3 implementation present at the client or server will not enhance the functionality of an NFS version 4 implementation.
NFSバージョン4は、NFSの以前のバージョンに依存関係を持たないことを自己完結型のプロトコルであろう。別の言い方をすれば、NFSバージョン4サーバーまたはクライアントがのNFSv2またはNFSv3の実装が設計通りに機能するNFSバージョン4のために存在する必要はありません。また、クライアントやサーバーでNFSバージョン2または3の実装の存在を有するNFSバージョン4の実装の機能を強化しないであろうことに留意すべきです。
In the case where an NFS client has a choice of using various NFS protocol versions (i.e. 2, 3 and 4), the underlying ONCRPC mechanisms will allow the client to appropriately choose an available version of the protocol at the NFS server. The ONCRPC protocol contains the semantics and error returns for the case where an RPC server program does not support a particular version. This mechanism is used by the NFS client to receive notification of an unavailable version and in conjunction with the error the client will also receive the range of versions (min to max) that are available. Therefore, the ONCRPC mechanism can be used by implementors of both clients and servers to provide for the transitioning to or installation of NFS version 4 services.
NFSクライアントは、様々なNFSプロトコルバージョンを使用しての選択（すなわち2、3及び4）を有している場合には、下地ONCRPCメカニズムは、クライアントが適切NFSサーバにプロトコルの利用可能なバージョンを選択することを可能にします。 ONCRPCプロトコルは、RPCサーバプログラムは、特定のバージョンをサポートしていない場合のセマンティクスとエラーリターンが含まれています。このメカニズムは利用できないバージョンの通知を受信すると、エラーに関連してクライアントが利用可能であるバージョン（maxまで分）の範囲を受け取るNFSクライアントによって使用されます。したがって、ONCRPCメカニズムは、またはインストールNFSのバージョン4つのサービスへの移行のために提供するために、クライアントとサーバの両方の実装で使用することができます。
Current NFS protocol design, while placing an emphasis on simple server design, has led to timely recovery from server and client failure. This and other aspects to the design have provided a basis for layered technologies like high availability and clustered servers. Providing a protocol design approach that lends itself to these types of reliability and availability features is very desirable.
現在のNFSプロトコルの設計は、単純なサーバーの設計に重点を置きながら、サーバとクライアントの障害からのタイムリーな回復につながっています。これとデザインへの他の態様は、高可用性とクラスタ化されたサーバーのような階層化技術の基礎を提供しています。信頼性と可用性機能のこれらのタイプに適していプロトコル設計アプローチを提供することは非常に望ましいです。
For the next version of NFS, consideration should be given to client side availability schemes such as client switching between or fail-over to available server replicas. NFS currently requires that file handles be immutable; this requirement adds unnecessarily to the complexity of building fail-over configurations. If possible, the protocol should allow for or ease the building of such layered solutions.
NFSの次のバージョンのために、考慮すべきことは、このようなクライアントとの間の切り替えまたはフェイルオーバーの使用可能なサーバーのレプリカに、クライアント側可用性スキームに与えられるべきです。 NFSは現在、ファイルハンドルは不変であることが必要。この要件は、建物フェイルオーバー構成の複雑さを不必要に追加されます。可能な場合、プロトコルはを可能にする、またはそのような層状のソリューションの構築を容易にすべきです。
For the next version of NFS, consideration should be given to schemes that support client switching between server replicas or highly available NFS servers that provide paths to data through multiple servers. For example: NFS currently requires that filehandles be unchanging for any instance of a file or directory. This requirement makes it more difficult for a client to switch from one server to another, since each server may construct filehandles differently. Protocol support could allow the client to handle a filehandle change.
NFSの次のバージョンのために、考慮事項は、サーバ・レプリカまたは複数のサーバを介してデータへのパスを提供し、高可用性NFSサーバとの間のクライアントの切り替えをサポートする方式に与えられるべきです。たとえば：NFSは現在、ファイルハンドルは、ファイルまたはディレクトリの任意のインスタンスに対して不変であることが必要。各サーバーを異なるファイルハンドルを構築することができるので、この要件は、それがより困難にクライアントがサーバーから別のサーバーへ切り替えるようになります。プロトコルのサポートは、クライアントがファイルハンドル変更を処理する可能性があります。
In designing and developing an NFS protocol from a performance viewpoint there are several different points to consider. Each can play a significant role in perceived and real performance from the user's perspective. The three main areas of interest are: throughput and latency via the network, server work load or scalability and client side caching.
性能の観点から、NFSプロトコルを設計し、開発する際に考慮すべきいくつかの相違点があります。それぞれのユーザーの視点から知覚され、実際の性能において重要な役割を再生することができます。関心の3つの主要分野は次のとおりです：スループットとレイテンシのネットワークを経由して、サーバーの作業負荷やスケーラビリティとクライアント側のキャッシュ。
NFS currently has characteristics that provide good throughput for reading and writing file data. This is commonly achieved by the client's use of pipelining or windowing multiple RPC READ/WRITE requests to the server. The flexibility of the NFS and ONCRPC protocols allow for implementations to use this type of adaptation to provide efficient use of the network connection.
NFSは、現在のファイルのデータを読み取り、書き込むための良好なスループットを提供特性を有しています。これは、一般に、パイプラインやサーバへの複数のRPC READ / WRITE要求をウインドウのクライアントの使用によって達成されます。実装は、ネットワーク接続の効率的な利用を提供するために、適応のこのタイプを使用するNFSやONCRPCプロトコルの柔軟性が可能になります。
However, the number of RPCs required to accomplish some tasks combined with high latency network environments may lead to sluggish single user or single client response. The protocol should continue to provide good raw read and write throughput while addressing the issue of network latency. This issue is discussed further in the section on Internet Accessibility.
ただし、高遅延ネットワーク環境と組み合わせて、いくつかのタスクを達成するために必要なRPCの数が低迷し、単一のユーザーまたは単一のクライアントの応答につながる可能性があります。プロトコルは良い生の読み取りを提供し、ネットワーク遅延の問題に対処しながら、スループットを書き続けなければなりません。この問題は、インターネットアクセシビリティ上のセクションで詳しく説明されています。
In an attempt to speed response time and to reduce network and server load, NFS clients have always cached directory and file data.
応答時間を短縮するために、ネットワークとサーバーの負荷を軽減する試みでは、NFSクライアントは常に、ディレクトリとファイルデータをキャッシュしています。
However, this has usually been done as memory cache and in relatively recent history, local disk caching has been added.
しかし、これは通常、メモリキャッシュとして行われており、比較的最近の歴史の中で、ローカルディスクキャッシュが追加されました。
It is very desirable to have the NFS client cache directory and file data. Other distributed file systems have shown that aggressive client side caching can be very visible to the end user in the form of decreasing overall response time. For AFS and DCE/DFS, caching is accomplished by the utilization of server call backs to notify the client of potential cache invalidation. CIFS and its opportunistic locks provide a similar call back mechanism. Clients in both of these environments are able to cache data while avoiding interaction with the network and server.
NFSクライアントのキャッシュディレクトリとファイルデータを持っていることは非常に望ましいです。他の分散ファイルシステムは、積極的なクライアント側のキャッシングが、全体的な応答時間を減少させるの形でエンドユーザーに非常に見えることができることを示しています。 AFSおよびDCE / DFSの場合、キャッシングは潜在的なキャッシュの無効化のクライアントに通知するために、サーバーのコールバックを利用することによって達成されます。 CIFSおよびその便宜的ロックは、同様のコールバックメカニズムを提供します。これらの環境の両方で、クライアントは、ネットワークとサーバとの相互作用を回避しながら、データをキャッシュすることができます。
With these protocols it is also possible to cache or delay certain protocol requests at the client which further reduces the protocol traffic flowing between client and server. In the case of CIFS, it is possible for a client to obtain an opportunistic lock for a file and subsequently process file lock requests completely at the client. If there are no conflicts with other clients for file data access, the server is never contacted for the file locking traffic generated by the user application. This behavior is not a protocol requirement but is allowed by the protocol as an implementation option to improve performance.
これらのプロトコルで、さらに、クライアントとサーバーの間を流れるプロトコルトラフィックが減少し、クライアントで特定のプロトコル要求をキャッシュまたは遅延させることも可能です。クライアントは、ファイルのための日和見ロックを取得し、その後、完全にクライアント側でファイルのロック要求を処理するためにCIFSの場合には、それが可能です。ファイル・データ・アクセスのための他のクライアントとの競合がない場合、サーバーは、ユーザーアプリケーションによって生成されたファイルロックのトラフィックのために連絡されることはありません。この動作は、プロトコルの要件ではなく、パフォーマンスを向上させるための実装オプションとしてプロトコルによって許可されています。
NFS versions 2 and 3 make no caching requirements. Implementations typically implement close-to-open cache consistency which requires clients flush all changes to the server on each file close, and check for file changes on the server on each file open. The consistency check required on each file open can generate a large amount of GETATTR traffic. With this approach, there are windows when the client can still be acting with stale data between the open and close of a file.
NFSバージョン2と3には、キャッシングの要求をしません。実装は通常、フラッシュ各ファイルに近い上のサーバーへのすべての変更をクライアントが必要と近いツーオープンキャッシュの整合性を実装し、開いている各ファイルのサーバ上のファイルの変更を確認してください。各ファイルに対してオープンに必要な整合性チェックは、GETATTRの大量のトラフィックを生成することができます。このアプローチでは、クライアントがまだ開いて、ファイルのクローズ間の古いデータで働くことができる窓があります。
Client caching is increasingly important for Internet environments where throughput can be limited and response time can grow significantly. Therefore the NFS version 4 caching design will need to take into account the full spectrum of caching designs as exemplified by the current technologies of NFS, AFS, DCE/DFS, CIFS, etc. in determining an appropriate design. This will need to be done while weighing the complexity of each possible approach with the need of the eventual users and operating environments into which NFS version 4 may be deployed. Some of these considerations are: Internet accessibility, firewall traversal (call back availability), proxy caching, low-overhead or simple clients.
クライアントのキャッシングは、スループットを制限することができ、応答時間が大幅に成長することができ、インターネット環境のためにますます重要になっています。したがって、NFSバージョン4のキャッシュ設計は、適切な設計を決定する際に等NFS、AFS、DCE / DFS、CIFS、現在の技術によって例示されるように考慮キャッシュ設計の完全なスペクトルを取る必要があります。これは、NFSバージョン4を展開することができる最終的にユーザとオペレーティング環境の必要にそれぞれの可能なアプローチの複雑さを計量しながら行う必要があります。これらの考慮事項は以下のとおりです。インターネットアクセス、ファイアウォールトラバーサル（可用性をコールバック）、プロキシキャッシング、低オーバーヘッドまたは単純なクライアント。
An extension of client caching is the provision for disconnected operation at the client. With the ability to cache directory and file data aggressively, a client could then provide service to the end user while disconnected from the server or network.
クライアントキャッシュの拡張は、クライアントの切断操作のために提供することです。積極的にディレクトリとファイルデータをキャッシュする機能により、クライアントは、サーバやネットワークから切断ながら、エンドユーザーにサービスを提供することができます。
While very desirable, disconnected operation has the potential to inflict itself upon the NFS protocol in an undesirable way as compared to traditional client caching. Given the complexities of disconnected client operation and subsequent resolution of client data modification through various playback or data selection mechanisms, disconnected operation should not be a requirement for the NFS effort. Even so, the NFS protocol should consider the potential layering of disconnected operation solutions on top of the NFS protocol (as with other server and client solutions). The experiences with Coda, disconnected AFS and others should be helpful in this area. (see references)
非常に望ましいが、切断操作は、従来のクライアント・キャッシングに比べて、望ましくない方法で、NFSプロトコルにそれ自体を与える可能性を秘めています。切断されたクライアントの操作や各種再生やデータ選択機構を介してクライアント・データ変更のその後の解像度の複雑さを考えると、切断操作はNFS努力の要求であってはなりません。そうであっても、NFSプロトコルは、（他のサーバやクライアントソリューションのように）NFSプロトコルの上に切断操作ソリューションの潜在的なレイヤーを検討すべきです。コーダ、切断AFSや他の人と経験がこの分野で有用である必要があります。 （参考文献を参照）
The NFS protocols are available for many different operating environments. Even though this shows the protocol's ability to provide distributed file system service for more than a single operating system, the design of NFS is certainly Unix-centric. The next NFS protocol needs to be more inclusive of platform or file system features beyond those of traditional Unix.
NFSプロトコルは、多くの異なる動作環境のために用意されています。これは、単一のオペレーティング・システムよりも多くのための分散ファイルシステムサービスを提供するプロトコルの能力を示しているにもかかわらず、NFSのデザインは確かにUnixの中心です。次のNFSプロトコルは、伝統的なUnixのものを超えプラットフォームやファイルシステム機能のより包括的なする必要があります。
Because of Unix-centric origins, NFS version 2 and 3 protocol requirements have been difficult to implement in some environments. For example, persistent file handles (unique identifiers of file system objects), Unix uid/gid mappings, directory modification time, accurate file sizes, file/directory locking semantics (SHAREs, PC-style locking). In the design of NFS version 4, these areas and others not mentioned will need to be considered and, if possible, cross-platform solutions developed.
なぜならUnixの中心の起源、NFSバージョン2と3プロトコル要件は、一部の環境で実装することが困難でした。例えば、永続的なファイルハンドル（ファイル・システム・オブジェクトの一意の識別子）、UnixのUID / GIDマッピング、ディレクトリの変更時、正確なファイルサイズ、ファイル/ディレクトリロックのセマンティクス（株式、PCスタイルのロック）。 NFSバージョン4の設計では、言及されていないこれらの領域と他の人が可能であれば、クロスプラットフォーム・ソリューションを開発、検討する必要があるとします。
NFS versions 2 and 3 do not provide for file or directory attributes beyond those that are found in the traditional Unix environment. For example the user identifier/owner of the file, a permission or access bitmap, time stamps for modification of the file or directory and file size to name a few. While the current set of attributes has usually been sufficient, the file system's ability to manage additional information associated with a file or directory can be useful.
NFSバージョン2と3は、伝統的なUnix環境で発見されているもの以外のファイルまたはディレクトリの属性を提供しません。たとえば、ファイルの変更またはディレクトリとファイルサイズのファイル、権限やアクセスマップ、タイムスタンプのユーザ識別子/所有者が数名に。属性の現在のセットは、通常は十分であったが、ファイルまたはディレクトリに関連する追加の情報を管理するためのファイルシステムの能力に役立ちます。
There are many possibilities for additional attributes in the next version of NFS. Some of these include: object creation timestamp, user identifier of file's creator, timestamp of last backup or archival bit, version number, file content type (MIME type), existence of data management involvement (i.e. DMAPI [XDSM]).
NFSの次のバージョンで追加属性のための多くの可能性があります。これらのいくつかが含まれます：オブジェクトの作成タイムスタンプ、ファイルの作成者のユーザ識別子、最後のバックアップやアーカイブビット、バージョン番号のタイムスタンプ、ファイルのコンテンツタイプ（MIMEタイプ）、データ管理の関与の有無を（すなわち、DMAPI [XDSM]）。
This list is representative of the possibilities and is meant to show the need for an additional attribute set. Enumerating the 'correct' set of attributes, however, is difficult. This is one of the reasons for looking towards a minor versioning mechanism as a way to provide needed extensibility. Another way to provide some extensibility is to support a generalized named attribute mechanism. This mechanism would allow a client to name, store and retrieve arbitrary data and have it associated as an attribute of a file or directory.
このリストは、可能性の代表であり、追加属性セットの必要性を示すことを意味しています。属性の「正しい」のセットを列挙、しかし、困難です。これは、必要な拡張性を提供する方法として、マイナーバージョン管理メカニズムの方に見ている理由の一つです。いくつかの拡張性を提供するもう一つの方法は、一般化という名前の属性のメカニズムをサポートすることです。このメカニズムは、名前、店舗へのクライアントを許可し、任意のデータを取得し、それはファイルやディレクトリの属性として関連付けられているだろう。
One difficulty in providing named attributes is determining if the protocol should specify the names for the attributes, their type or structure. How will the protocol determine or allow for attributes that can be read but not written is another issue. Yet another could be the side effects that these attributes have on the core set of file properties such as setting a size attribute to 0 and having associated file data deleted.
名前の属性を提供する上で一つの問題は、プロトコルが、その種類や構造を属性の名前を指定する必要がありますかどうかを判断します。どのプロトコルが決定または読み取りが、書き込まれていないことができる属性を可能にする別の問題です。さらに別のは、これらの属性は、0にサイズ属性を設定し、削除された関連するファイルデータを有するようなファイルプロパティのコアセットを持っていることを副作用とすることができます。
As these brief examples show, this type of extended attribute mechanism brings with it a large set of issues that will need to be addressed in the protocol specification while keeping the overall goal of simplicity in mind.
これらの簡単な例が示すように、拡張属性メカニズムのこのタイプは、それを念頭に置いてシンプルさの全体的な目標を維持しながら、プロトコル仕様に対処する必要があります問題の大規模なセットをもたらします。
There are operating environments that provide named or extended attribute mechanisms. Digital Unix provides for the storage of extended attributes with some generalized format. HPFS [HPFS] and NTFS [Nagar] also provide for named data associated with traditional files. SGI's local file system, XFS, also provides for this type of name/value extended attributes. However, there does not seem to be a clear direction that can be taken from these or other environments.
名前付きまたは拡張属性のメカニズムを提供稼働環境があります。 DIGITAL UNIXは、いくつかの一般的な形式の拡張属性を格納するために用意されています。 HPFS [HPFS]とNTFS [ナガル]は、従来のファイルに関連付けられているというデータを提供します。 SGIのローカルファイルシステム、XFSは、また、名前/値の拡張属性のこのタイプのために用意されています。しかし、これらまたは他の環境から撮影することができます明確な方向性があるようには思えません。
Access Control Lists (ACL) can be viewed as one specific type of extended attribute. This attribute is a designation of user access to a file or directory. Many vendors have created ancillary protocols to NFS to extend the server's ACL mechanism across the network. Generally this has been done for homogeneous operating environments. Even though the server still interprets the ACL and has final control over access to a file system object, the client is able to manipulate the ACL via these additional protocols. Other distributed file systems have also provided ACL support (DFS, AFS and CIFS).
アクセス制御リスト（ACL）は、拡張属性の特定の一種類として見ることができます。この属性は、ファイルまたはディレクトリへのユーザーアクセスの指定です。多くのベンダーは、ネットワークを介してサーバのACLメカニズムを拡張するためにNFSに補助的なプロトコルを作成しました。一般に、これは、均一な動作環境のために行われています。サーバはまだACLを解釈し、ファイル・システム・オブジェクトへのアクセスを最終的な制御を持っているにもかかわらず、クライアントは、これらの追加のプロトコルを経由してACLを操作することができます。その他の分散ファイルシステムもACLのサポート（DFS、AFSおよびCIFS）を提供しています。
The basic factor driving the requirement for ACL support in all of these file systems has been the user's desire to grant and restrict access to file system data on a per user basis. Based on the desire of the user and current distributed file system support, it seems to be a requirement that NFS provide this capability as well.
これらのファイルシステムのすべてにACLをサポートするための要件を駆動する基本的な要因は、付与し、ユーザーごとにシステムデータをファイルへのアクセスを制限するユーザの希望となっています。ユーザーの願望と現在の分散ファイルシステムのサポートに基づいて、NFSが同様にこの機能を提供する必要性であるように思われます。
Because many local and distributed file system ACL implementations have been done without a common architecture, the major issue is one of compatibility. Although the POSIX draft, DCE/DFS [DCEACL] and Windows NT ACLs have a similar structure in an array of Access Control Entries consisting of a type field, identity, and permission bits, the similarity ends there. Each model defines its own variants of entry types, identifies users and groups differently, provides different kinds of permission bits, and describes different procedures for ACL creation, defaults, and evaluation.
多くのローカルおよび分散ファイルシステムのACLの実装は、共通のアーキテクチャせずに行われているので、大きな問題は、互換性の一つです。 POSIXドラフトが、DCE / DFS [DCEACL]およびWindows NT ACLは、タイプフィールド、アイデンティティ、及び許可ビットからなるアクセス制御エントリの配列に類似した構造を有し、類似性が終了します。各モデルは、エントリタイプの独自のバリアントを定義する異なるユーザおよびグループを識別し、許可ビットの種類を提供し、ACLの作成、デフォルト値、及び評価のための異なる手順が記載されています。
In the least it will be problematic to create a workable ACL mechanism that will encompass a reasonable set of functionality for all operating environments. Even with the complicated nature of ACL support it is still worthwhile to work towards a solution that can at least provide basic functionality for the user.
少なくとも、すべてのオペレーティング環境のための機能の合理的なセットを包含します実行可能なACLメカニズムを作成するために、問題になる可能性があります。でも、ACLサポートの複雑な自然と、少なくともユーザーのための基本的な機能を提供することができます解決に向けて努力することはまだ価値があります。
NFS relies on the security mechanisms provided by the ONCRPC [RFC1831] protocol. Until the introduction of the ONCRPC RPCSEC_GSS security flavor [RFC2203], NFS security was generally limited to none (AUTH_SYS) or DES (AUTH_DH). The AUTH_DH security flavor was not successful in providing readily available security for NFS because of a lack of widespread implementation which precluded widespread deployment. Also the Diffie-Hellman 192 bit public key modulus used for the AUTH_DH security flavor quickly became too small for reasonable security.
NFSはONCRPC [RFC1831]プロトコルによって提供されるセキュリティメカニズムに依存しています。 ONCRPC RPCSEC_GSSセキュリティ風味[RFC2203]の導入まで、NFSセキュリティは、一般的になし（AUTH_SYS）またはDES（AUTH_DH）に限られていました。 AUTH_DHセキュリティ風味があるため広範囲の展開を妨げ広範な実装の欠如のNFSのために容易に利用可能なセキュリティを提供することに成功しませんでした。また、AUTH_DHセキュリティ風味を使用のDiffie-Hellmanの192ビットの公開鍵モジュラスはすぐに合理的な安全保障のためには小さすぎました。
NFS has been limited to the use of the Unix-centric user identification mechanism of numeric user id based on the available file system attributes and the use of the ONCRPC. However, for NFS to move beyond the limits of large work groups, user identification should be string based and the definition of the user identifier should allow for integration into an external naming service or services.
NFSは、利用可能なファイルシステム属性とONCRPCの使用に基づく数値のユーザIDのUnixの中心のユーザ識別メカニズムの使用に限定されてきました。 NFSは、大きなワークグループの限界を超えて移動するためしかし、ユーザ識別情報は、文字列基づくべきであるとユーザ識別子の定義は、外部ネーミング・サービスまたはサービスへの統合を可能にすべきです。
Internet scaling should also be considered for this as well. The identification mechanism should take into account multiple naming domains and multiple naming mechanisms. Flexibility is the key to a solution that can grow with the needs of the user and administrator.
インターネットのスケーリングも同様に、このために考慮されるべきです。識別メカニズムは、アカウントに複数のネーミングドメインと複数のネーミングメカニズムを取る必要があります。柔軟性は、ユーザーと管理者のニーズに合わせて拡張できるソリューションへの鍵です。
If NFS is to move among various naming and security services, it may be necessary to stay with a string based identification. This would allow for servers and clients to translate between the external string representation to a local or internal numeric (or other identifier) which matches internal implementation needs.
NFSは、さまざまなネーミングおよびセキュリティサービス間を移動する場合は、文字列ベースの識別に滞在する必要があるかもしれません。サーバーとクライアントは、内部実装のニーズに合ったローカルまたは数値の内部（または他の識別子）への外部文字列表現の間で変換するためにこれが可能になります。
As an example, DFS uses a string based naming scheme but translates the name to a UUID (16 byte identifier) that is used for internal protocol representations. The DCE/DFS string name is a combination of cell (administrative domain) and user name. As mentioned, NFS clients and servers map a Unix user name to a 32 bit user identifier that is then used for ONCRPC and NFS protocol fields requiring the user identifier.
一例として、DFSは、文字列ベースの命名スキームを使用するが、内部プロトコルの表現に使用されるUUID（16バイト識別子）に名前を変換します。 DCE / DFSの文字列名は、セル（管理ドメイン）とユーザー名の組み合わせです。上述したように、NFSクライアントとサーバは、ユーザ識別子を必要ONCRPCとNFSプロトコルフィールドのために使用される32ビットのユーザ識別子にUNIXユーザー名をマップします。
Because of the aforementioned problems, user authentication has been a major issue for ONCRPC and hence NFS. To satisfy requirements of the IETF and to address concerns and requirements from users, NFS version 4 must provide for the use of acceptable security mechanisms. The various mechanisms currently available should be explored for their appropriate use with NFS version 4 and ONCRPC. Some of these mechanisms are: TLS [RFC2246], SPKM [RFC2025], KerberbosV5 [RFC1510], IPSEC [RFC2401]. Since ONCRPC is the basis for NFS client and server interaction, the RPCSEC_GSS [RFC2203] framework should be strongly considered since it provides a method to employ mechanisms like SPKM and KerberosV5. Before a security mechanism can be evaluated, the NFS environment and requirements must be discussed.
そのため、前述の問題のため、ユーザー認証はONCRPCので、NFSのための大きな課題となっています。 IETFの要件を満たすために、ユーザーからの懸念と要件に対応するため、NFSバージョン4は、許容可能なセキュリティメカニズムの使用を提供する必要があります。現在利用可能な種々の機構は、NFSバージョン4とONCRPCとの適切な使用のために検討されるべきです。これらのメカニズムのいくつかは：TLS [RFC2246]、SPKM [RFC2025]、KerberbosV5 [RFC1510]、IPSEC [RFC2401]。 ONCRPCは、NFSクライアントとサーバとの対話のための基礎であるので、それはSPKMとKerberosV5のようなメカニズムを使用する方法を提供するので、RPCSEC_GSS [RFC2203]のフレームワークを強く考慮すべきです。セキュリティメカニズムが評価できる前に、NFS環境と要件を検討する必要があります。
As mentioned later in this document in the section "Internet Accessibility", transport independence is an asset for NFS and ONCRPC and is a general requirement. This allows for transport choice based on the target environment and specific application of NFS. The most common transports in use with NFS are UDP and TCP. This ability to choose transport should be maintained in combination with the user's choice of a security mechanism. This implies that "mandatory to implement" security mechanisms for NFS should allow for both connection-less and connection-oriented transports.
セクション「インターネットアクセス」で、このドキュメントで後述するように、トランスポート独立性は、NFSとONCRPCの資産であると一般的な要件です。これは、ターゲット環境やNFSの特定の用途に基づいてトランスポートの選択が可能になります。 NFSで使用されている最も一般的なトランスポートはUDPとTCPです。トランスポートを選択するこの機能は、セキュリティ・メカニズムのユーザーの選択と組み合わせて維持されるべきです。これは、NFSのセキュリティ・メカニズム「を実装するために義務的には、」コネクションレスおよびコネクション型トランスポートの両方を可能にしなければならないことを意味します。
As should be expected, strong authentication is a requirement for NFS version 4. Each operation generated via ONCRPC contains user identification and authentication information. It is common in NFS version 2 and 3 implementations to multiplex various users' requests over a single or few connections to the NFS server. This allows for scalability in the number of clients systems. Security mechanisms or frameworks should allow for this multiplexing of requests to sustain the implementation model that is available today.
予想されるように、強力な認証は、NFSバージョン4 ONCRPCを介して生成された各操作のための要件は、ユーザ識別及び認証情報を含んでいます。これは、NFSサーバへの単一または少数の接続を介して、様々なユーザの要求を多重化するNFSバージョン2と3の実装では一般的です。これは、クライアントシステムの数に拡張することができます。セキュリティ・メカニズムやフレームワークは、現在入手可能である実装モデルを維持する要求のこの多重化を可能にしなければなりません。
Until the introduction of RPCSEC_GSS, the ability to provide data integrity over ONCRPC and to NFS was not available. Since file and directory data is the essence of a distributed file service, the NFS protocol should provide to the users of the file service a reasonable level of data integrity. The security mechanisms chosen must provide for NFS data protection with a cryptographically strong checksum. As with other aspects within NFS version 4, the user or administrator should be able to choose whether data integrity is employed. This will provide needed flexibility for a variety of NFS version 4 solutions.
RPCSEC_GSSの導入までは、ONCRPC上およびNFSへのデータの整合性を提供する能力は利用できませんでした。ファイルやディレクトリのデータが分散ファイル・サービスの本質であるので、NFSプロトコルは、ファイルサービス、データの整合性の合理的なレベルのユーザーに提供する必要があります。選択したセキュリティ・メカニズムは、暗号強度の高いチェックサムとNFSデータ保護を提供しなければなりません。 NFSバージョン4内の他の側面と同様に、ユーザーや管理者は、データの整合性が採用されているかどうかを選択することができるはずです。これは、NFSバージョン4のさまざまなソリューションのために必要な柔軟性を提供します。
Data privacy, while desirable, is not as important in all environments as authentication and integrity. For example, in a LAN environment the performance overhead of data privacy may not be required to meet an organization's data protection policies. It may also be the case that the performance of the distributed file system solution is more important than the data privacy of that solution. Even with these considerations, the user or administrator must have the choice of data privacy and therefore it must be included in NFS version 4.
データのプライバシーは、望ましい一方で、認証および整合性など、すべての環境ではそれほど重要ではありません。例えば、LAN環境でのデータのプライバシーのパフォーマンス・オーバーヘッドは、組織のデータ保護ポリシーを満たすために必要なことはできません。また、分散ファイル・システム・ソリューションのパフォーマンスは、その解決策のデータのプライバシーよりも重要である場合があり得ます。でも、これらを考慮して、ユーザーまたは管理者がデータのプライバシーの選択を持っている必要があり、したがって、それはNFSバージョン4に含まれている必要があります。
With the ability to provide security mechanism choices to the user or administrator, NFS version 4 should offer reasonable flexibility for application of local security policies. However, this presents the problem of negotiating the appropriate security mechanism between client and server. It is unreasonable to require the client know the server's chosen mechanism before initial contact. The issue is further complicated by an administrator who may choose more than one security mechanism for the various file system resources being shared by an NFS server. These types of choices and policies require that NFS version 4 deal with negotiating the appropriate security mechanism based on mechanism availability and policy deployment at client and server. This negotiation will need to take into account the possibility of a change in policy as an NFS client crosses certain file system boundaries at the server. The security mechanisms required may change at these boundaries and therefore the negotiation must be included within the NFS protocol itself to be done properly (i.e. securely).
ユーザーまたは管理者にセキュリティメカニズムの選択肢を提供する能力では、NFSバージョン4は、ローカルセキュリティポリシーの適用のための合理的な柔軟性を提供する必要があります。しかし、これは、クライアントとサーバの間で適切なセキュリティメカニズムを交渉するという問題があります。クライアントが最初に接触する前に、サーバーの選択したメカニズムを知る必要がするのは無理です。問題は、NFSサーバーによって共有されているさまざまなファイル・システム・リソースのための複数のセキュリティ・メカニズムを選択することができ、管理者がさらに複雑になります。選択肢や政策のこれらのタイプは、クライアントとサーバーのメカニズムの可用性およびポリシー展開に基づいて、適切なセキュリティメカニズムを交渉しているNFSバージョン4の契約が必要です。この交渉は、NFSクライアントがサーバに特定のファイルシステムの境界を横断するよう考慮政策の変化の可能性を取る必要があります。必要なセキュリティメカニズムは、これらの境界で変更される可能性があり、したがって、ネゴシエーション（すなわち確実に）適切に行われるNFSプロトコル自体の中に含まれなければなりません。
Other distributed file system solutions such as AFS and DFS provide strong authentication mechanisms. CIFS does provide authentication at initial server contact and a message signing option for subsequent interaction. Recent NFS version 2 and 3 implementations, with the use of RPCSEC_GSS, provide strong authentication, integrity, and privacy.
このようAFSやDFSなどの他の分散ファイルシステムソリューションは、強力な認証メカニズムを提供します。 CIFSサーバの初期接触とその後の相互作用のためのメッセージの署名オプションでの認証を提供します。最近のNFSバージョン2と3の実装、RPCSEC_GSSを使用して、強力な認証、整合性、およびプライバシーを提供。
NFS version 4 must provide for strong authentication, integrity, and privacy. This must be part of the protocol so that users have the choice to use strong security if their environment or policies warrant such use.
NFSバージョン4は、強力な認証、整合性、およびプライバシーのために提供しなければなりません。ユーザーが自分の環境や政策がそのような使用を保証する場合は、強力なセキュリティを使用する選択肢を持っているように、これはプロトコルの一部でなければなりません。
Based on the requirements presented, the ONCRPC RPCSEC_GSS security flavor seems to provide an appropriate framework for satisfying these requirements. RPCSEC_GSS provides for authentication, integrity, and privacy. The RPCSEC_GSS is also extensible in that it provides for both public and private key security mechanisms along with the ability to plug in various mechanisms in such a way that it does not significantly disrupt ONCRPC or NFS implementations.
提示要件に基づいて、ONCRPC RPCSEC_GSSセキュリティ風味は、これらの要件を満たすための適切なフレームワークを提供するようです。 RPCSEC_GSSには、認証、完全性、プライバシーのために用意されています。 RPCSEC_GSSはまた、それが大幅ONCRPCまたはNFS実装を破壊しないように様々なメカニズムをプラグインする能力とともに、公開鍵と秘密鍵のセキュリティメカニズムの両方を提供することで拡張可能です。
With RPCSEC_GSS' ability to support both public and private key mechanisms, NFS version 4 should consider "mandatory to implement" choices from both. The intent is to provide a security solution that will flexibly scale to match the needs of end users. Providing this range of solutions will allow for appropriate usage based on policy and available resources for deployment. Note that, in the end, the user must have a choice and that choice may be to use all of the available mechanisms in NFS version 4 or none of them.
両方の公開鍵と秘密鍵のメカニズムをサポートするRPCSEC_GSSの能力では、NFSバージョン4は、両方の選択肢 『を実装するために義務的』検討すべきです。その意図は、柔軟に、エンドユーザーのニーズに合うようにスケールしますセキュリティソリューションを提供することです。ソリューションのこの範囲を提供することは、展開のためのポリシーと利用可能なリソースに基づいて、適切な使用を可能にします。最後に、ユーザーは選択肢を持っている必要があり、その選択は、NFSバージョン4またはそれらのいずれにも利用可能なメカニズムのすべてを使用することであってもよい、ということに注意してください。
Being a product of an IETF working group, the NFS protocol should not only be built upon IETF technologies where possible but should also work well within the broader Internet environment.
IETFワーキンググループの製品なので、NFSプロトコルは、可能な場合だけでなく、より広範なインターネット環境でうまく動作するはずIETFの技術に基づいて構築すべきではありません。
As with any network protocol, congestion control is a major issue and the transport mechanisms that are chosen for NFS should take this into account. Traditionally, implementations of NFS have been deployed using both UDP and TCP. With the use of UDP, most implementations provide a rudimentary attempt control congestion with simple back-off algorithms and round trip timers. While this may be sufficient in today's NFS deployments, as an Internet protocol NFS will need to ensure sufficient congestion control or management.
任意のネットワークプロトコルと同様に、輻輳制御が主要な問題であり、NFSのために選択されたトランスポート・メカニズムがこれを考慮に入れなければなりません。伝統的に、NFSの実装はUDPとTCPの両方を使用して展開されています。 UDPを使用すると、ほとんどの実装では、単純なバックオフアルゴリズムと往復タイマーと初歩的な試みの制御、輻輳を提供しています。これは今日のNFS展開で十分かもしれないが、インターネットプロトコルとしてNFSは、十分な輻輳制御や管理を確実にする必要があります。
With congestion control in mind, NFS must use TCP as a transport (via ONCRPC). The UDP transport provides its own advantages in certain circumstances. In today's NFS implementations, UDP has been shown to produce greater throughput as compared to similarly configured systems that use TCP. This issue will need to be investigated such that a determination can be made as to whether the differences are within implementation details. If UDP is supplied as an NFS transport mechanism, then the congestion controls issues will need resolution to make its use suitable.
念頭に置いて輻輳制御では、NFSは（ONCRPC経由）トランスポートとしてTCPを使用する必要があります。 UDPトランスポートは、特定の状況では、独自の利点を提供します。今日のNFS実装では、UDPはTCPを使用して同様に構成されたシステムと比較して高いスループットを産生することが示されています。この問題は、決意が違いは実装の詳細内にあるか否かを判定することができるように調査する必要があります。 UDPは、NFSの転送メカニズムとして供給されている場合には、輻輳制御の問題は、その使用が適して作るために解像度が必要になります。
NFS's protocol design should allow its use via Internet firewalls. The protocol should also allow for the use of file system proxy/cache servers. Proxy servers can be very useful for scalability and other reasons. The NFS protocol needs to address the need of proxy servers in a way that will deal with the issues of security, access control, content control, and cache content validation. It is possible that these issues can be addressed by documenting the related issues of proxy server usage. However, it is likely that the NFS protocol will need to support proxy servers directly through the NFS protocol.
NFSのプロトコルの設計は、インターネットファイアウォールを経由してその使用を許可する必要があります。プロトコルは、ファイルシステムのプロキシ/キャッシュ・サーバの使用を許可する必要があります。プロキシサーバーは、スケーラビリティや他の理由のために非常に役立ちます。 NFSプロトコルは、セキュリティ、アクセス制御、コンテンツ管理、およびキャッシュの内容の検証の問題を扱うような方法でのプロキシサーバーの必要性に対処する必要があります。これらの問題は、プロキシサーバーの使用に関連する問題を文書化することによって対処することができる可能性があります。しかし、NFSプロトコルはNFSプロトコルを介して直接、プロキシサーバーをサポートする必要がある可能性が高いです。
The protocol could allow a request to be sent to a proxy that contains the name of the target NFS server to which the request might be forwarded, or from which a response might be cached. In any case, the NFS proxy server should be considered during protocol development.
プロトコルは、要求が転送されるかもしれないし、または応答がキャッシュされるかもしれないから、ターゲットNFSサーバーの名前が含まれているプロキシに送信される要求される可能性があります。いずれにしても、NFSプロキシサーバは、プロトコルの開発時に考慮すべきです。
The problems encountered in making the NFS protocol work through firewalls are described in detail in [RFC2054] and [RFC2055].
ファイアウォールを介してNFSプロトコル作業を行う際に遭遇する問題は、[RFC2054]及び[RFC2055]に詳細に記載されています。
As an application at the NFS client performs simple file system operations, multiple NFS operations or RPCs may be executed to accomplish the work for the application. While the NFS version 3 protocol addressed some of this by returning file and directory attributes for most procedures, hence reducing follow up GETATTR requests, there is still room for improvement. Reducing the number of RPCs will lead to a reduction of processing overhead on the server (transport and security processing) along with reducing the time spent at the client waiting for the server's individual responses. This issue is more prominent in environments with larger degrees of latency.
NFSクライアントでのアプリケーションは、単純なファイルシステム操作を実行するように、複数のNFS操作やRPCは、アプリケーションの作業を達成するために実行されてもよいです。 NFSバージョン3プロトコルは、したがってGETATTR要求をフォロー減少、ほとんどの手続きのために、ファイルやディレクトリの属性を返すことによって、この一部を取り上げながら、まだ改善の余地があります。 RPCの数を減らすと、サーバの個々の応答を待っているクライアントに費やす時間を削減するとともに、サーバ上の処理オーバーヘッドの削減（輸送およびセキュリティ処理）につながります。この問題は、レイテンシの大きな度の環境ではより顕著です。
The CIFS file access protocol supports 'batched requests' that allow multiple requests to be batched, therefore reducing the number of round trip messages between client and server.
CIFSファイルアクセスプロトコルは、複数の要求は、したがって、クライアントとサーバ間の往復メッセージの数を減らし、バッチ処理を可能にする「バッチ処理の要求」をサポートしています。
This same approach can be used by NFS to allow the grouping of multiple procedure calls together in a traditional RPC request. Not only would this reduce protocol imposed latency but it would reduce transport and security processing overhead and could allow a client to complete more complex tasks by combining procedures.
この同じアプローチは、複数の手順のグループ化は、従来のRPC要求に一緒に呼び出し可能にするためにNFSによって使用されることができます。だけでなく、このプロトコル課せられた遅延を低減するであろうが、それは、トランスポートとセキュリティ処理のオーバーヘッドを低減するであろうと、クライアントは手順を組み合わせることで、より複雑なタスクを完了する可能性があります。
NFS provided Unix file locking and DOS SHARE capability with the use of an ancillary protocol (Network Lock Manager / NLM). The DOS SHARE mechanism is the DOS equivalent of file locking in that it provides the basis for sharing or exclusive access to file and directory data without risk of data corruption. The NLM protocol provides file locking and recovery of those locks in the event of client or server failure. The NLM protocol requires that the server make call backs to the client for certain scenarios and therefore is not necessarily well suited for Internet firewall traversal.
NFSは、補助的なプロトコル（ネットワークロックマネージャ/ NLM）を使用してUNIXのファイルロックとDOSのSHARE機能を提供します。 DOS SHAREメカニズムは、それが共有やデータの破損のリスクなしに、ファイルやディレクトリのデータへの排他的アクセスのための基礎を提供することにあるロックファイルのDOSと同等です。 NLMプロトコルは、クライアントまたはサーバの障害発生時にファイルロックおよびそれらのロックの回復を提供します。 NLMプロトコルは、サーバが特定のシナリオのために、クライアントへのコールバックを行うことが必要ですので、必ずしもインターネットファイアウォールトラバーサルには適していません。
Available and correct file locking support for NFS version 2 and 3 clients and servers has historically been problematic. The availability of NLM support has traditionally been a problem and seems to be most related to the fact that NFS and NLM are two separate protocols. It is easy to deliver an NFS client and server implementation and then add NLM support later. This led to a general lack of NLM support early on in NFS' lifetime. One of the reasons that NLM was delivered separately has been its relative complexity which has in turn led to poor implementations and testing difficulties. Even in later implementations where reliability and performance had been increased to acceptable levels for NLM, users still chose to avoid the use of the protocol and its support. The last issue with NLM is the presence of minor protocol design flaws that relate to high network load and recovery.
NFSバージョン2と3のクライアントとサーバーで使用可能な、正しいファイルロックのサポートは、歴史的に問題がありました。 NLMのサポートの利用可能性は、伝統的に問題とされているとNFSとNLM 2つの別々のプロトコルであるという事実に最も関連あると思われています。 NFSクライアントとサーバーの実装を提供し、その後NLMのサポートを追加するのは簡単です。これは、NFS」生涯の早い段階でNLMのサポートの一般的な不足につながりました。 NLMは、別途配信された理由の一つは、今度は貧弱な実装とテストの難しさにつながっているの相対的な複雑されています。でも、信頼性とパフォーマンスがNLMのための許容可能なレベルにまで上昇していた後の実装では、ユーザーがプロトコルとその支援の使用を避けることにしました。 NLMとの最後の問題は、ネットワークの高負荷と回復に関連するマイナーなプロトコルの設計上の欠陥の存在です。
Based on the experiences with NLM, locking support for NFS version 4 should strive to meet or at least consider the following (in order of importance):
NLMの経験に基づいて、NFSバージョン4のためのロックのサポートは、満たすために努力しなければならないか、少なくとも（重要度の順に）次の点を考慮します。
o Integration with the NFS protocol and ease of implementation.
O NFSプロトコルと実装の容易さとの統合。
o Interoperability between operating environments. The protocol should make a reasonable effort to support the locking semantics of both PC and Unix clients and servers. This will allow for greater integration of all environments.
動作環境間の相互運用性O。プロトコルは、PCおよびUNIXのクライアントとサーバの両方のロックセマンティクスをサポートするために合理的な努力をしなければなりません。これは、すべての環境の大きな統合が可能になります。
o Scalable solutions - thousands of clients. The server should not be required to maintain significant client file locking state between server instantiations.
O拡張性の高いソリューション - 数千のクライアント。サーバは、サーバ・インスタンス間の状態をロックする重要なクライアントファイルを維持するために必要とするべきではありません。
o Internet capable (firewall traversal, latency sensitive). The server should not be required to initiate TCP connections to clients.
Oインターネット対応（ファイアウォールトラバーサル、遅延の影響を受けやすいです）。サーバーは、クライアントへのTCP接続を開始するために必要とするべきではありません。
o Timely recovery in the event of client/server or network failure. Server recovery should be rapid. The protocol should allow clients to detect the loss of a lock.
クライアント/サーバやネットワーク障害時のOタイムリーな回復。サーバーの回復が迅速であるべきです。プロトコルは、クライアントがロックの喪失を検出できるようにする必要があります。
NFS version 2 and 3 are currently limited in the character encoding of strings. In the NFS protocols, strings are used for file and directory names, and symbolic link contents. Although the XDR definition [RFC1832] limits strings in the NFS protocol to 7-bit US-ASCII, common usage is to encode filenames in 8-bit ISO-Latin-1. However, there is no mechanism available to tag XDR character strings to indicate the character encoding used by the client or server. Obviously this limits NFS' usefulness in an environment with clients that may operate with various character sets.
NFSバージョン2と3は、現在の文字列の文字エンコーディングに限定されています。 NFSプロトコルでは、文字列はファイル名やディレクトリ名、およびシンボリックリンクの内容に使用されています。 XDR定義[RFC1832]は7ビットUS-ASCIIにNFSプロトコルの文字列を制限しているが、一般的な使用は、8ビットのISO-Latin-1の中でファイル名を符号化することです。ただし、クライアントまたはサーバが使用する文字エンコーディングを示すために、XDR文字列をタグ付けするために利用できるメカニズムはありません。これは明らかに、さまざまな文字セットで動作させることができるクライアントとの環境でのNFS」有用性を制限します。
One approach to address this deficiency is to use the Unicode Standard [Unicode1] as the means to exchange character strings for the NFS version 4 protocol. The Unicode Standard is a 16 bit encoding that supports full multilingual text. The Unicode Standard is code-for-code identical with International Standard ISO/IEC 10646-1:1993. "Information Technology -- Universal Multiple-Octet Coded Character Set (UCS)-Part 1: Architecture and Basic Multilingual Plane." Because Unicode is a 16 bit encoding, it may be more efficient for the NFS version 4 protocol to use an encoding for wire transfer that will be useful for a majority of usage. One possible encoding is the UCS transformation format (UTF). UTF-8 is an encoding method for UCS-4 characters which allows for the direct encoding of US-ASCII characters but expands for the correct encoding of the full UCS-4 31 bit definitions. Currently, the UCS-4 and Unicode standards do not diverge.
この欠陥に対処するための一つのアプローチは、NFSバージョン4プロトコルのための文字列を交換する手段として、Unicode標準[Unicode1]を使用することです。 Unicode標準は、完全な多言語テキストをサポートしている16ビットエンコーディングです。 1993：Unicode標準は、コードのためのコードの国際規格ISO / IEC 10646-1と同一です。 「情報技術 - ユニバーサルマルチオクテット符号化文字集合（UCS） - パート1：アーキテクチャと基本多言語面。」 Unicodeは、16ビットのエンコーディングであるため、NFSバージョン4プロトコルは使用の大半のために有用であろうワイヤー転送のエンコーディングを使用することがより効率的であってもよいです。一つの可能な符号化は、UCS変換フォーマット（UTF）です。 UTF-8は、US-ASCII文字の直接符号化を可能にするが、完全なUCS-4 31ビットの定義の正しい符号化のために拡大UCS-4文字の符号化方法です。現在、UCS-4およびUnicodeの規格が発散しないでください。
This Unicode/UTF-8 encoding can be used for places in the protocol that a traditional string representation is needed. This includes file and directory names along with symlink contents. This should also include other file and directory attributes that are eventually defined as strings.
これはUnicode / UTF-8エンコーディングは、従来の文字列表現が必要とされているプロトコルで場所を使用することができます。これは、シンボリックリンクの内容と一緒にファイル名やディレクトリ名を含んでいます。また、これは最終的には、文字列として定義されている他のファイルやディレクトリの属性を含める必要があります。
The Unicode standard is applicable to the well defined strings within the protocol. Dealing with file content is much more difficult. NFS has traditionally dealt with file data as an opaque byte stream. No other structure or content specification has been levied upon the file content. The main advantage to this approach is its flexibility. This byte stream can contain any data content and may be accessed in any sequential or random fashion. Unfortunately, it is left to the application or user to make the determination of file content and format. It is possible to construct a mechanism in the protocol that specifies file data type while maintaining the byte stream model for data access. However, this approach may be limiting in ways unclear to the designers of the NFS version 4 protocol. An expandable and adaptable approach is to use the previously discussed extended attributes as the mechanism to specify file content and format. The use of extended attributes allows for future definition and growth as various data types are created and allows for maintaining a simple file data model for the NFS protocol.
Unicode標準は、プロトコル内で明確に定義された文字列に適用されます。ファイルの内容に対処するはるかに困難です。 NFSは、伝統的に不透明なバイトストリームとしてファイルのデータを扱っています。他の構造やコンテンツの仕様は、ファイルの内容に課されていません。このアプローチの主な利点は、その柔軟性です。このバイトストリームは、任意のデータコンテンツを含むことができ、任意の順次またはランダムにアクセスすることができます。残念ながら、ファイルの内容と形式の決意をするためにアプリケーションまたはユーザーに任されています。データアクセスのためのバイトストリームモデルを維持しながら、ファイルのデータ型を指定したプロトコルで仕組みを構築することが可能です。しかし、このアプローチは、NFSバージョン4プロトコルの設計者には不明の方法で制限することができます。拡張可能かつ適応可能なアプローチは、ファイルの内容と形式を指定するためのメカニズムとして、先に述べた拡張属性を使用することです。拡張属性を使用すると、さまざまなデータ型が作成される将来の定義と成長を可能にし、NFSプロトコルのための単純なファイル・データ・モデルを維持することができます。
It should be noted that as the Unicode standards are currently defined there is the possibility for minor inconsistencies when converting from local character representations to Unicode and then back again. This should not be a problem with single client and server interaction but may become apparent with the interaction of two or more clients with separate conversion implementations. Therefore, as NFS version 4 progresses in its development, these types of Unicode issues need to be tracked and understood for their potential impact on client/server interaction. In any case, Unicode seems to be the best selection for NFS version 4 based on its standards background and apparent future direction.
Unicode標準は、現在定義されている通り、バック再びUnicodeにローカル文字表現からの変換とマイナー不一致の可能性があることに留意すべきです。これは、単一のクライアントとサーバーの対話と問題になることはありませんが、別の変換の実装を持つ2つの以上のクライアントとの相互作用を明らかになることがあります。 NFSバージョン4は、その開発に進むにつれてそのため、Unicodeの問題のこれらのタイプは、クライアント/サーバの対話の潜在的な影響のために追跡し、理解する必要があります。いずれにせよ、Unicodeは、その基準の背景と見かけの将来の方向性に基づいて、NFSバージョン4のための最良の選択であると思われます。
Two previous sections within this document deal with security issues. The section covering 'Access Control Lists' covers the mechanisms that need to be investigated for file system level control. The section that covers RPC security deals with individual user authentication along with data integrity and privacy issues. This section also covers negotiation of security mechanisms. These sections should be consulted for additional discussion and detail.
セキュリティ上の問題で、この文書の契約内で前の2つのセクション。 「アクセス制御リスト」被覆部は、ファイルシステムレベルの制御のために調査する必要があるメカニズムをカバーしています。データの整合性とプライバシーの問題に加えて、個々のユーザ認証とRPCセキュリティのお得な情報をカバーしてセクション。このセクションでは、セキュリティ・メカニズムの交渉をカバーしています。ここでは、追加的な議論と詳細のために相談する必要があります。
As with all services, the denial of service by either incorrect implementations or malicious agents is always a concern. With the target of providing NFS version 4 for Internet use, it is all the more important that all aspects of the NFS version 4 protocol be reviewed for potential denial of service scenarios. When found these potential problems should be mitigated as much as possible.
すべてのサービスと同様に、間違った実装や悪意のあるエージェントのどちらかによって、サービス拒否が常に懸念されます。インターネット利用のためのNFSバージョン4を提供する目的で、NFSバージョン4プロトコルのすべての側面は、サービスシナリオの可能性否定のために検討することを、すべてのより重要です。見つかった場合はこれらの潜在的な問題を可能な限り軽減する必要があります。
[RFC1094] Sun Microsystems, Inc., "NFS: Network File System Protocol Specification", RFC 1094, March 1989. http://www.ietf.org/rfc/rfc1094.txt
[RFC1094]サン・マイクロシステムズ社は、 "NFS：ネットワークシステムプロトコル仕様書ファイル"、RFC 1094、1989年3月http://www.ietf.org/rfc/rfc1094.txt
[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. http://www.ietf.org/rfc/rfc1510.txt
[RFC1510]コールズ、J.及びC.ノイマン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 1510、1993年9月http://www.ietf.org/rfc/rfc1510.txt
[RFC1813] Callaghan, B., Pawlowski, B. and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, June 1995. http://www.ietf.org/rfc/rfc1813.txt
[RFC1813]キャラハン、B.、ポロウスキー、B.およびP.ストーバック、 "NFSバージョン3プロトコル仕様"、RFC 1813、1995年6月http://www.ietf.org/rfc/rfc1813.txt
[RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 1831, August 1995. http://www.ietf.org/rfc/rfc1831.txt
[RFC1831]スリニバサン、R.、 "RPC：リモートプロシージャコールプロトコル仕様バージョン2"、RFC 1831、1995年8月http://www.ietf.org/rfc/rfc1831.txt
[RFC1832] Srinivasan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995. http://www.ietf.org/rfc/rfc1832.txt
[RFC1832]スリニバサン、R.、 "XDR：外部データ表現標準"、RFC 1832、1995年8月http://www.ietf.org/rfc/rfc1832.txt
[RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC 1833, August 1995. http://www.ietf.org/rfc/rfc1833.txt
[RFC1833]スリニバサン、R.、 "ONC RPCバージョン2のプロトコルのバインド"、RFC 1833、1995年8月http://www.ietf.org/rfc/rfc1833.txt
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996. http://www.ietf.org/rfc/rfc2025.txt
[RFC2025]アダムス、C.、 "単純な公開鍵GSS-APIメカニズム（SPKM）"、RFC 2025、1996年10月http://www.ietf.org/rfc/rfc2025.txt
[RFC2054] Callaghan, B., "WebNFS Client Specification", RFC 2054, October 1996. http://www.ietf.org/rfc/rfc2054.txt
[RFC2054]キャラハン、B.、 "WebNFSのクライアント仕様"、RFC 2054、1996年10月http://www.ietf.org/rfc/rfc2054.txt
[RFC2055] Callaghan, B., "WebNFS Server Specification", RFC 2055, October 1996. http://www.ietf.org/rfc/rfc2055.txt
[RFC2055]キャラハン、B.、 "WebNFSのサーバー仕様"、RFC 2055、1996年10月http://www.ietf.org/rfc/rfc2055.txt
[RFC2078] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997. http://www.ietf.org/rfc/rfc2078.txt
[RFC2078]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェース、バージョン2"、RFC 2078、1997年1月http://www.ietf.org/rfc/rfc2078.txt
[RFC2152] Goldsmith, D., "UTF-7 A Mail-Safe Transformation Format of Unicode", RFC 2152, May 1997. http://www.ietf.org/rfc/rfc2152.txt
[RFC2152]ゴールドスミス、D.、 "ユニコードのUTF-7 Aメールセーフ変換形式"、RFC 2152、1997年5月http://www.ietf.org/rfc/rfc2152.txt
[RFC2203] Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, August 1995. http://www.ietf.org/rfc/rfc2203.txt
[RFC2203]アイスラー、M.、チウ、A.及びL.リン、 "RPCSEC_GSSプロトコル仕様"、RFC 2203、1995年8月http://www.ietf.org/rfc/rfc2203.txt
[RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. http://www.ietf.org/rfc/rfc2222.txt
[RFC2222]マイヤーズ、J.、 "簡易認証セキュリティー層（SASL）"、RFC 2222、1997年10月http://www.ietf.org/rfc/rfc2222.txt
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. http://www.ietf.org/rfc/rfc2279.txt
[RFC2279] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、RFC 2279、1998年1月http://www.ietf.org/rfc/rfc2279.txt
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocols Version 1.0", RFC 2246, Certicom, January 1999. http://www.ietf.org/rfc/rfc2246.txt
[RFC2246]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、Certicomの、1999年1月http://www.ietf.org/rfc/rfc2246.txt
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. http://www.ietf.org/rfc/rfc2401.txt
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月http://www.ietf.org/rfc/rfc2401.txt
[DCEACL] The Open Group, Open Group Technical Standard, "DCE 1.1: Authentication and Security Services," Document Number C311, August 1997. Provides a discussion of DEC ACL structure and semantics.
[DCEACL]オープングループ、Open Groupの技術標準、「DCE 1.1：認証とセキュリティサービス、」文書番号C311、1997年8月には12月ACLの構造と意味論の議論を提供します。
[HPFS] Les Bell and Associates Pty Ltd, "The HPFS FAQ," http://www.lesbell.com.au/hpfsfaq.html
[HPFS]レベルアンドアソシエイツPty Ltdの、 "HPFSよくある質問、" http://www.lesbell.com.au/hpfsfaq.html
[Hutson] Huston, L.B., Honeyman, P., "Disconnected Operation for AFS," June 1993. Proc. USENIX Symp. on Mobile and Location-Independent Computing, Cambridge, August 1993.
[ハトソン]ヒューストン、L.B.、ハニーマン、P.、 "AFSのための切断操作、" 1993年6月PROC。 USENIX SYMP。モバイルや場所に依存しないコンピューティング、ケンブリッジ、1993年8月に。
[Kistler] Kistler, James J., Satyanarayanan, M., "Disconnected Operations in the Coda File System," ACM Trans. on Computer Systems, vol. 10, no. 1, pp. 3-25, Feb. 1992.
【キスラー】キスラー、ジェームスJ.、Satyanarayanan、M.、「切断操作Codaのファイルシステムで、」ACMトランス。コンピュータシステム、巻上。 10、ありません。 1頁3-25、1992年2月。
[Mummert] Mummert, L. B., Ebling, M. R., Satyanarayanan, M., "Exploiting Weak Connectivity for Mobile File Access," Proc. of the 15th ACM Symp. on Operating Systems Principles Dec. 1995.
【Mummert] Mummert、L. B.、Ebling、M. R.、Satyanarayanan、M.、PROC "モバイルファイルアクセスのための弱い接続性を活用"。第15回ACM SYMPの。オペレーティングシステムの原理1995年12月に。
[Nagar] Nagar, R., "Windows NT File System Internals," ISBN 1565922492, O`Reilly & Associates, Inc.
[ナガル]ナガル、R.、 "Windows NTのファイルシステムの内部、" ISBN 1565922492、O`Reilly＆アソシエイツ株式会社
[Sandberg] Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh, B. Lyon, "Design and Implementation of the Sun Network Filesystem," USENIX Conference Proceedings, USENIX Association, Berkeley, CA, Summer 1985. The basic paper describing the SunOS implementation of the NFS version 2 protocol, and discusses the goals, protocol specification and trade-offs.
[サンドバーグ]サンドバーグ、R.、D.ゴールドバーグ、S.クレイマン、D.ウォルシュ、B.リヨン、「日ネットワークファイルシステムの設計と実装、」USENIX会議議事録、USENIX協会、バークレー、CA、夏1985ザ・基本的な紙は、NFSバージョン2プロトコルのSunOSの実装を記述し、目標、プロトコル仕様とトレードオフについて説明します。
[Satyanarayanan1] Satyanarayanan, M., "Fundamental Challenges in Mobile Computing," Proc. of the ACM Principles of Distributed Computing, 1995.
【Satyanarayanan1] Satyanarayanan、M.、 "モバイルコンピューティングにおける基本的課題、" PROC。分散コンピューティング、1995年のACM原則。
[Satyanarayanan2] Satyanarayanan, M., Kistler, J. J., Mummert L. B., Ebling M. R., Kumar, P. , Lu, Q., "Experience with disconnected operation in mobile computing environment," Proc. of the USENIX Symp. on Mobile and Location-Independent Computing, Jun. 1993.
【Satyanarayanan2] Satyanarayanan、M.、キスラー、J. J.、Mummert L. B.、Ebling M. R.、クマー、P.、陸、Q.、 "モバイルコンピューティング環境における切断操作の経験、" PROC。 USENIX SYMPの。モバイルや場所に依存しないコンピューティング、1993年6月に。
[Unicode1] "Unicode Technical Report #8 - The Unicode Standard, Version 2.1", Unicode, Inc., The Unicode Consortium, P.O. Box 700519, San Jose, CA 95710-0519 USA, September 1998 http://www.unicode.org/unicode/reports/tr8.html
[Unicode1] "のUnicodeテクニカルレポート＃8 - Unicode標準、バージョン2.1"、ユニコード社、ユニコードコンソーシアム、P。箱700519、サンノゼ、CA 95710から0519 USA、1998年9月http://www.unicode.org/unicode/reports/tr8.html
[Unicode2] "Unsupported Scripts" Unicode, Inc., The Unicode Consortium, P.O. Box 700519, San Jose, CA 95710-0519 USA, October 1998 http://www.unicode.org/unicode/standard/unsupported.html
[Unicode2] "サポートされていないスクリプト" のUnicode、Inc.の、ユニコードコンソーシアム、P。箱700519、サンノゼ、CA 95710から0519 USA、1998年10月http://www.unicode.org/unicode/standard/unsupported.html
[XDSM] The Open Group, Open Group Technical Standard, "Systems Management: Data Storage Management (XDSM) API," ISBN 1-85912-190-X, January 1997.
[XDSM]オープングループ、Open Groupの技術標準、 "システム管理：データストレージ管理（XDSM）API、" ISBN 1-85912-190-X、1997年1月。
[XNFS] The Open Group, Protocols for Interworking: XNFS, Version 3W, The Open Group, 1010 El Camino Real Suite 380, Menlo Park, CA 94025, ISBN 1-85912-184-5, February 1998. HTML version available: http://www.opengroup.org
[XNFS]オープングループ、インターワーキングのためのプロトコル：XNFS、バージョン3W、オープングループ、1010年エル・カミノレアルスイート380、メンロパーク、CA 94025、ISBN 1-85912-184-5、1998年2月HTMLバージョンが利用可能にします。http ：//www.opengroup.org
o Brent Callaghan for content contributions.
コンテンツの貢献のためブレントキャラハンO。
Address comments related to this memorandum to:
この覚書に関連するコメントを住所：
spencer.shepler@eng.sun.com -or- nfsv4-wg@sunroof.eng.sun.com
spencer.shepler@eng.sun.com - または - nfsv4-wg@sunroof.eng.sun.com
Spencer Shepler Sun Microsystems, Inc. 7808 Moonflower Drive Austin, Texas 78750
スペンサーSheplerサン・マイクロシステムズ株式会社7808ムーンフラワードライブオースティン、テキサス州78750
Phone: (512) 349-9376 EMail: spencer.shepler@eng.sun.com
電話：（512）349-9376 Eメール：spencer.shepler@eng.sun.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。