[要約] RFC 2624は、NFSバージョン4の設計に関する考慮事項をまとめたものです。このRFCの目的は、NFSv4の設計者や実装者に対して、プロトコルの設計上の問題や選択肢についての情報を提供することです。
Network Working Group S. Shepler
Request for Comments: 2624 Sun Microsystems, Inc.
Category: Informational June 1999
NFS Version 4 Design Considerations
NFSバージョン4の設計上の考慮事項
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.
Copyright（c）The Internet Society（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.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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の強みの1つは、比較的簡単にクライアントまたはサーバーを実装する能力です。基本的な実装の最終的なサイズは比較的小さいです。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の相対的なシンプルさにより、機能の追加または階層化は簡単に達成できます。クライアントの自動化やオートフ、クライアントサイドディスクキャッシュ、高可用性サーバーなどの機能の追加が例です。このタイプの拡張性は、問題解決がプロトコルの改訂を必要としない環境で望ましいです。この拡張性は、既存のツールまたはプロトコルの機能を階層化することで予期せぬ問題や機会を解決できる将来にも役立ちます。
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には、小さな単純な機能的追加がプロトコルの全体的な価値を大幅に増加させるインスタンスがありました。たとえば、マウントプロトコルのバージョン2に追加されたPathConf手順は、NFSプロトコルにより適していたでしょう。Webnfs [RFC2054] [RFC2055] NFSバージョン2および3のルックアップ手順の過負荷は、新しいルックアップ手順でよりきれいに実装されていたでしょう。
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プロトコルは、バージョン番号を使用して、一連の手順呼び出し、返信、およびそれらのセマンティクスを説明します。このセットの変更は、プログラムの新しいバージョン番号に反映される必要があります。この例は、Mount Protocolのバージョン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のもう1つの歴史的データポイントは、シンボリックリンクのサポート（または欠如）です。この機能をサポートできないサーバーは、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サーバーまたはクライアントは、NFSバージョン4が設計どおりに機能するためにNFSV2またはNFSV3の実装を存在させる必要はありません。また、クライアントまたはサーバーに存在する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サーバープログラムが特定のバージョンをサポートしていない場合のセマンティクスとエラーリターンが含まれています。このメカニズムは、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は現在、ファイルハンドルがファイルまたはディレクトリの任意のインスタンスに対して変更されないことを要求しています。この要件により、クライアントが1つのサーバーから別のサーバーに切り替えることがより困難になります。各サーバーはファイルハンドルを異なる方法で構築する可能性があるためです。プロトコルサポートにより、クライアントはファイルハンドルの変更を処理できるようになります。
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読み取り/書き込み要求をサーバーに使用することによって達成されます。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の数は、単一のユーザーまたは単一のクライアントの応答が遅くなる可能性があります。プロトコルは、ネットワークレイテンシの問題に対処しながら、優れたRaw Read and Writeスループットを引き続き提供する必要があります。この問題については、インターネットアクセシビリティに関するセクションでさらに説明します。
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プロトコルの上にある切断された操作ソリューションの潜在的なレイヤー化を検討する必要があります（他のサーバーおよびクライアントソリューションと同様）。CODA、切断された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.
このリストは可能性を表しており、追加の属性セットの必要性を示すことを目的としています。ただし、「正しい」属性セットを列挙することは困難です。これは、必要な拡張性を提供する方法として、マイナーバージョン化メカニズムに目を向ける理由の1つです。いくつかの拡張性を提供する別の方法は、一般化された名前の属性メカニズムをサポートすることです。このメカニズムにより、クライアントは任意のデータに名前、保存、取得し、ファイルまたはディレクトリの属性として関連付けられるようになります。
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.
名前の属性を提供することの難しさの1つは、プロトコルが属性、そのタイプ、または構造の名前を指定するかどうかを決定することです。プロトコルは、読み取ることができるが書かれていない属性をどのように決定または許可しますかは別の問題です。さらにもう1つは、これらの属性が、サイズ属性を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 [Nagar]も、従来のファイルに関連付けられた名前のデータを提供します。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）は、特定のタイプの拡張属性と見なすことができます。この属性は、ファイルまたはディレクトリへのユーザーアクセスの指定です。多くのベンダーがNFSに補助的なプロトコルを作成して、サーバーのACLメカニズムをネットワーク全体に拡張しています。一般的に、これは均質な動作環境のために行われています。サーバーは依然として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の実装は共通のアーキテクチャなしで行われているため、主要な問題は互換性の1つです。POSIXドラフト、DCE/DFS [DCEACL]およびWindows NT ACLSは、タイプフィールド、アイデンティティ、および許可ビットからなるアクセス制御エントリの配列に同様の構造を持っていますが、類似性はそこで終わります。各モデルは、エントリタイプの独自のバリエーションを定義し、ユーザーとグループを異なる方法で識別し、さまざまな種類の許可ビットを提供し、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セキュリティは一般にNONE（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クライアントとサーバーは、UNIXユーザー名を32ビットユーザー識別子にマッピングし、ユーザー識別子を必要とするONCRPCおよびNFSプロトコルフィールドに使用します。
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クライアントとサーバーの相互作用の基礎であるため、RPCSEC_GSS [RFC2203]フレームワークは、SPKMやkerberosv5などのメカニズムを使用する方法を提供するため、強く考慮する必要があります。セキュリティメカニズムを評価する前に、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.
「インターネットアクセシビリティ」セクションのこのドキュメントで後で述べたように、Transport Independenceは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バージョン2および3の実装では、NFSサーバーへの単一または少数の接続でさまざまなユーザーの要求をマルチプレックスすることが一般的です。これにより、クライアントシステムの数のスケーラビリティが可能になります。セキュリティメカニズムまたはフレームワークは、今日利用可能な実装モデルを維持するために、リクエストのこの多重化を可能にする必要があります。
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は、初期サーバーの連絡先で認証を提供し、その後の相互作用のためのメッセージ署名オプションを提供します。RPCSEC_GSSを使用した最近のNFSバージョン2および3の実装は、強力な認証、整合性、プライバシーを提供します。
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.
NFSバージョン4は、パブリックメカニズムと秘密鍵メカニズムの両方をサポートするRPCSEC_GSSの能力により、両方からの「実装に必須」を検討する必要があります。目的は、エンドユーザーのニーズに合わせて柔軟に拡張するセキュリティソリューションを提供することです。この範囲のソリューションを提供すると、ポリシーと展開のための利用可能なリソースに基づいて適切な使用が可能になります。最終的には、ユーザーには選択肢が必要であり、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はTCPを輸送として（ONCRPC経由）使用する必要があります。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.
この同じアプローチをNFSで使用して、従来のRPCリクエストで複数の手順呼び出しをグループ化できるようにすることができます。これにより、プロトコルがレイテンシを削減するだけでなく、輸送とセキュリティ処理のオーバーヘッドを削減し、手順を組み合わせることでクライアントがより複雑なタスクを完了することができます。
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共有機能を提供しました。DOS共有メカニズムは、データ腐敗のリスクなしにファイルおよびディレクトリデータへの共有または排他的アクセスの基礎を提供するという点で、ファイルロックに相当する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が個別に配信された理由の1つは、その相対的な複雑さであり、その結果、実装とテストの困難が不十分になりました。信頼性とパフォーマンスが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]はNFSプロトコルの文字列を7ビットUS-ASCIIに制限していますが、一般的な使用法は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.
この欠陥に対処するための1つのアプローチは、NFSバージョン4プロトコルの文字文字列を交換する手段として、Unicode標準[Unicode1]を使用することです。Unicode標準は、完全な多言語テキストをサポートする16ビットエンコードです。Unicode標準は、国際標準ISO/IEC 10646-1：1993と同一のコードコードです。「情報技術 - ユニバーサルマルチオクテットコード化された文字セット（UCS） - パート1：アーキテクチャと基本的な多言語平面。」Unicodeは16ビットエンコードであるため、NFSバージョン4プロトコルが使用するワイヤー転送にエンコードを使用する方が効率的である可能性があります。可能なエンコードの1つは、UCS変換形式（UTF）です。UTF-8は、US-ASCII文字の直接エンコードを可能にするUCS-4文字のエンコーディング方法ですが、完全なUCS-4 31ビット定義の正しいエンコードのために拡張されます。現在、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エンコーディングは、従来の文字列表現が必要なプロトコル内の場所に使用できます。これには、Symlinkコンテンツとともにファイル名とディレクトリ名が含まれます。これには、最終的に文字列として定義される他のファイルおよびディレクトリ属性も含める必要があります。
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に変換してから再び戻る際に、わずかな矛盾の可能性があることに注意する必要があります。これは、単一のクライアントとサーバーの相互作用に問題ではないはずですが、個別の変換実装を備えた2つ以上のクライアントの相互作用で明らかになる可能性があります。したがって、NFSバージョン4の開発が進行するにつれて、これらのタイプのユニコードの問題を追跡し、クライアント/サーバーの相互作用に潜在的な影響を理解する必要があります。いずれにせよ、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] Sun Microsystems、Inc。、「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] Kohl、J。およびC. Neuman、「The Kerberos Network Authentication Service（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] Callaghan、B.、Pawlowski、B。and P. Staubach、「NFSバージョン3プロトコル仕様」、RFC 1813、1995年6月。http：//www.ietf.org/rfc/rfc1813.txtxt
[RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 1831, August 1995. http://www.ietf.org/rfc/rfc1831.txt
[RFC1831] Srinivasan、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] Srinivasan、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] Srinivasan、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] Adams、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] Callaghan、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] Callaghan、B。、「Webnfs Server仕様」、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] Linn、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] Goldsmith、D。、「UTF-7 Unicodeのメールセーフ変換形式」、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] Eisler、M.、Chiu、A。and L. Ling、「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] Myers、J。、「Simple Authentication and Security Layer（SASL）」、RFC 2222、1997年10月。http：//www.ietf.org/rfc/rfc222.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/rfc22279.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] Dierks、T。およびC. Allen、「TLS Protocolsバージョン1.0」、RFC 2246、Certicom、1999年1月。http：//www.ietf.org/rfc/rfc2246.txtxt
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. http://www.ietf.org/rfc/rfc2401.txt
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、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、Open Group Technical Standard、「DCE 1.1：認証およびセキュリティサービス」、ドキュメント番号C311、1997年8月。DECACL構造とセマンティクスの議論を提供します。
[HPFS] Les Bell and Associates Pty Ltd, "The HPFS FAQ," http://www.lesbell.com.au/hpfsfaq.html
[HPFS] Les Bell and Associates Pty Ltd、 "The HPFS FAQ、" 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.
[Hutson] Huston、L.B.、Honeyman、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.
[Kistler] Kistler、James J.、Satyanarayanan、M。、「CODAファイルシステムでの切断された操作」、ACM Trans。コンピューターシステム、Vol。10、いいえ。1、pp。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.
[Nagar] Nagar、R。、「Windows NT File System Internals」、ISBN 1565922492、O`Reilly＆Associates、Inc。
[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.
[Sandberg] Sandberg、R.、D。Goldberg、S。Kleiman、D。Walsh、B。Lyon、「サンネットワークファイルシステムの設計と実装」、Usenix Conference Proceedings、Usenix Association、Berkeley、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。分散コンピューティングのACM原理の、1995年。
[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.、Kistler、J.J.、Mummert L. B.、Ebling M. R.、Kumar、P.、Lu、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 Technical Report＃8 -Unicode Standard、バージョン2.1"、Unicode、Inc。、Unicode Consortium、P.O。Box 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.、The Unicode Consortium、P.O。Box 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]オープングループ、オープングループの技術標準、「システム管理：データストレージ管理（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 El Camino Real Suite 380、CA 94025、ISBN 1-85912-184-5、1998年2月。：//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 Sun Microsystems, Inc. 7808 Moonflower Drive Austin, Texas 78750
Spencer Shepler Sun Systems、Inc。7808 Moonflower Drive Austin、Texas 78750
Phone: (512) 349-9376 EMail: spencer.shepler@eng.sun.com
電話：（512）349-9376メール：spencer.shepler@eng.sun.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。