RFC2624 日本語訳
2624 NFS Version 4 Design Considerations. S. Shepler. June 1999. (Format: TXT=52891 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Shepler Request for Comments: 2624 Sun Microsystems, Inc. Category: Informational June 1999
Sheplerがコメントのために要求するワーキンググループS.をネットワークでつないでください: 2624年のサン・マイクロシステムズ・インクカテゴリ: 情報の1999年6月
NFS Version 4 Design Considerations
NFSバージョン4デザイン問題
Status of this Memo
この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)インターネット協会(1999)。 All rights reserved。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
Shepler Informational [Page 1] RFC 2624 NFSv4 Design Considerations June 1999
Sheplerの情報[1ページ]のRFC2624NFSv4は1999年6月に問題を設計します。
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
1. NFSバージョン4は問題. . . . . . . . . . . . . 2 2を設計します。 実装の容易さかプロトコル. . . . . . 3 2.1の複雑さ。 伸展性/レイヤリング. . . . . . . . . . . . . . . . . 3 2.2。 管理された拡大か小さい方のVersioning. . . . . . . . . . 3 2.3。 NFS. . . . . . . . . . 4 3の旧式のバージョンとの関係。 信頼できて利用可能な.5 4。 スケーラブルなパフォーマンス. . . . . . . . . . . . . . . . . . . . 5 4.1。 Network. . . . . . . . . . 6 4.2を通したスループットとLatency。 クライアントキャッシュ. . . . . . . . . . . . . . . . . . . . . . 6 4.3。 クライアント操作. . . . . . . . . . . . . . . 7 5であると切断されます。 相互運用性. . . . . . . . . . . . . . . . . . . . . . 7 5.1。 プラットホーム特異的行動. . . . . . . . . . . . . . . . 8 5.2。 追加しているか拡張している属性. . . . . . . . . . . . . 8 5.3。 アクセスコントロールリスト. . . . . . . . . . . . . . . . . . 9 6。 RPCメカニズムとセキュリティ. . . . . . . . . . . . . . . . 10 6.1。 ユーザ登録名. . . . . . . . . . . . . . . . . . . 10 6.2。 セキュリティ. . . . . . . . . . . . . . . . . . . . . . . . 10 6.2.1。 独立. . . . . . . . . . . . . . . . 11 6.2.2を輸送してください。 認証. . . . . . . . . . . . . . . . . . . . 11 6.2.3。 データの保全. . . . . . . . . . . . . . . . . . . . 11 6.2.4。 データプライバシー. . . . . . . . . . . . . . . . . . . . . 12 6.2.5。 セキュリティ交渉. . . . . . . . . . . . . . . . . 12 6.3。 概要. . . . . . . . . . . . . . . . . . . . . . . . . 12 7。 インターネットのアクセシビリティ. . . . . . . . . . . . . . . . . . 13 7.1。 輻輳制御と輸送選択. . . . . . . 13 7.2。 ファイアウォールとProxyサーバ. . . . . . . . . . . . . . . 14 7.3。 複数のRPCsと潜在. . . . . . . . . . . . . . . . 14 8。 ロック/回復.159をファイルしてください。 国際化. . . . . . . . . . . . . . . . . . . 16 10。 セキュリティ問題. . . . . . . . . . . . . . . . . 17 10.1。 サービス妨害. . . . . . . . . . . . . . . . . . . 17 11。 図書目録. . . . . . . . . . . . . . . . . . . . . . . 18 12。 承認. . . . . . . . . . . . . . . . . . . . . 21 13。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . 21 14。 完全な著作権宣言文. . . . . . . . . . . . . . . . . 22
1. NFS Version 4 Design Considerations
1. NFSバージョン4デザイン問題
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
特許で述べられているように、NFSバージョン4ワーキンググループのための最初の提出物はこのデザイン問題ドキュメントです。 カバーにはこのドキュメントがある、「NFSバージョンの制限と欠乏、3インチ」 また、このドキュメントは、NFSバージョン4の定義が進歩をするとき調査の議論と大通りの焦点を合わせるのにメカニズムとして使用されるでしょう。 したがって、このドキュメントの中身はNFSバージョン4のために予期される一般的な機能的な/特徴領域をカバーしています。 適切であるところ、現在のNFSバージョン2と3の議論
Shepler Informational [Page 2] RFC 2624 NFSv4 Design Considerations June 1999
Sheplerの情報[2ページ]のRFC2624NFSv4は1999年6月に問題を設計します。
practice will be presented along with other appropriate references to current distributed file system practice.
習慣は現在の分散ファイルシステム習慣の他の適切な参照と共に提示されるでしょう。
2. Ease of Implementation or Complexity of Protocol
2. 実装の容易さかプロトコルの複雑さ
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を保つ主な理由は簡単で、共同利用できる実装を促進する簡単な仕様で簡単なプロトコルデザインについて説明できるということです。 本当のネットワークで配布されると、すべてのプロトコルが問題を出くわすことができますが、簡単なプロトコルは、より診断しやすくて正しい問題をもたらします。
2.1. Extensibility / layering
2.1. 伸展性/レイヤリング
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のような特徴の追加であり、クライアントサイドディスクキャッシュと高可用性サーバは例です。 このタイプの伸展性は問題解決がプロトコル改正を必要としない環境で望ましいです。 この伸展性は、また、将来、既存のセットのツールに関するレイヤリングの機能性で予期せぬ問題か機会を解決できるところで役立つか、または議定書を作ることができます。
2.2. Managed Extensions or Minor Versioning
2.2. 管理された拡大か小さい方のVersioning
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があるインスタンスが小さい簡単な機能的な追加がプロトコルの総合的な値を大きく増強したところにありました。 例えば、NFSプロトコルには、山のプロトコルのバージョン2に追加されたPATHCONF手順は、より適切だったでしょう。 NFSバージョン2と3のためのLOOKUP手順の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バージョン番号の変化を使用する知覚されたサイズと負担はいいえか遅い変化につながりました。 RPC改正がRPCバージョン番号の中のプロトコル拡大が最も慎重なコースであり、不要であるか、または非実用的であるだろうところで新しいNFSプロトコルがまれなインスタンスを考慮するかもしれないのは、可能です。
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
NFSプロトコルの明らかに最も不安定な領域は、新しい直交した手順か新しい明確なファイルかディレクトリ属性と潜在的に新しいファイルの種類です。 例、可能性として
Shepler Informational [Page 3] RFC 2624 NFSv4 Design Considerations June 1999
Sheplerの情報[3ページ]のRFC2624NFSv4は1999年6月に問題を設計します。
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.
未来に関するファイルの種類は、命名されたファイルストリームを表す「属性」などのタイプかクライアントからの「質問」手順に対応してダイナミックなデータを生成する「ダイナミックな」ファイルの種類であるかもしれません。
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はサーバのサーバかファイルシステムでサポートすることができない多くのファイル属性について説明するかもしれません。したがって、プロトコルはクライアントがプロトコルのどの特徴がサーバによってサポートされるかを決心できる発見メカニズムをサポートしなければなりません。
2.3. Relationship with Older Versions of NFS
2.3. NFSの旧式のバージョンとの関係
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の旧バージョンに少しの依存も持たないので、NFSバージョン4は自己の含まれたプロトコルになるでしょう。 述べられた別の方法、NFSバージョン4サーバまたはクライアントがNFSへのプレゼントが設計されているように機能するバージョン4であったならNFSv2かNFSv3実装を必要としないでしょう。 また、クライアントかサーバにおける現在のNFSバージョン2か3実装を持っているのがNFSバージョン4実装の機能性を高めないことに注意されるべきです。
Shepler Informational [Page 4] RFC 2624 NFSv4 Design Considerations June 1999
Sheplerの情報[4ページ]のRFC2624NFSv4は1999年6月に問題を設計します。
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クライアントによって使用されます、そして、また、誤りに関連して、クライアントは利用可能なバージョン(最大限にする分)の範囲を取るでしょう。 したがって、クライアントとサーバの両方の作成者は、NFSバージョン4サービスの移行かインストールに備えるのにONCRPCメカニズムを使用できます。
3. Reliable and Available
3. 信頼できて利用可能です。
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は、現在、ファイルかディレクトリのどんなインスタンスにも、filehandlesが変らないのを必要とします。 この要件でクライアントが1つのサーバから別のものに切り替わるのが、より難しくなります、各サーバがfilehandlesを異なって組み立てるかもしれないので。 プロトコルサポートで、クライアントはfilehandle変化を扱うことができました。
4. Scalable Performance
4. スケーラブルなパフォーマンス
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
性能観点からNFSプロトコルを設計して、開発するには、考える数個の異なった意味があります。 それぞれがユーザの見解からの知覚されて本当の性能における重要な役割をプレーできます。 3つの一番関心がある分野は以下の通りです。 そしてスループットと潜在する、ネットワーク、サーバ仕事量またはスケーラビリティを通って。
Shepler Informational [Page 5] RFC 2624 NFSv4 Design Considerations June 1999
Sheplerの情報[5ページ]のRFC2624NFSv4は1999年6月に問題を設計します。
client side caching.
クライアントサイドキャッシュ。
4.1. Throughput and Latency via the Network
4.1. Networkを通したスループットとLatency
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.
しかしながら、高い潜在ネットワーク環境に結合されたいくつかのタスクを達成しなければならなかったRPCsの数はのろいシングルユーザーかただ一つのクライアント応答につながるかもしれません。 プロトコルは、ネットワーク潜在の問題を扱っている間、読まれて、利益を生で提供して、スループットを書き続けるべきです。 インターネットAccessibilityの上のセクションで、より詳しくこの問題について議論します。
4.2. Client Caching
4.2. クライアントキャッシュ
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の場合では、クライアントが完全にクライアントでファイルと次にプロセスファイルロック要求のための便宜主義的な錠を入手するのは、可能です。 ファイルデータ・アクセスのための他のクライアントとの闘争が全くなければ、サーバはユーザアプリケーションで生成されたファイルのロックトラフィックのために決して連絡されません。 この振舞いは、プロトコル要件ではありませんが、実装オプションとしてのプロトコルで性能を向上させることができます。
Shepler Informational [Page 6] RFC 2624 NFSv4 Design Considerations June 1999
Sheplerの情報[6ページ]のRFC2624NFSv4は1999年6月に問題を設計します。
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が配布されるかもしれない最後のユーザと操作環境の必要性とそれぞれの可能なアプローチの複雑さについて比較考量している間、する必要があるでしょう。 これらの問題のいくつかは以下の通りです。 インターネットのアクセシビリティ、ファイアウォール縦断(有用性に電話し直す)、プロキシのキャッシュしているか、低いオーバーヘッドの、または、純真なクライアント。
4.3. Disconnected Client Operation
4.3. クライアント操作であると切断されます。
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、および他のものに役立っているべきです。 (参照を見ます)
5. Interoperability
5. 相互運用性
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のものを超えてプラットホームかファイルシステム機能で、より包括的である必要があります。
Shepler Informational [Page 7] RFC 2624 NFSv4 Design Considerations June 1999
Sheplerの情報[7ページ]のRFC2624NFSv4は1999年6月に問題を設計します。
5.1. Platform Specific Behavior
5.1. プラットホーム特異的行動
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/ヒツジ暈倒病マッピング、ディレクトリ変更時間、正確なファイルサイズ、ファイル/ディレクトリが意味論(SHAREsであり、PCはロックを流行に合わせる)をロックして。 これらのバージョン4、領域、および他のものが考えられるのが必要であると言及しなかったNFSとできればクロスプラットフォームのデザインでは、解決策は見いだされました。
5.2. Additional or Extended Attributes
5.2. 追加しているか拡張している属性
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の次のバージョンには追加属性のための多くの可能性があります。 これらのいくつかは: オブジェクト作成タイムスタンプ、ファイルのクリエイターのユーザ識別子、最後のバックアップか記録保管所のビットのタイムスタンプ、バージョン番号はcontent type(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.
このリストは、可能性を代表して、追加属性の必要性がセットしたのを示すことになっています。 しかしながら、'正しい'セットの属性を列挙するのは難しいです。 これは必要な伸展性を提供する方法として小さい方のversioningメカニズムを面させる理由の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つの苦労が、プロトコルがそれらの属性、タイプまたは構造に名前を指定するべきであるかどうか決定しています。 プロトコルは、どのように、読むことができる属性を決定するか、または考慮するだろうか、しかし、書かれていないのは、別の問題です。 しかし、別のものは、これらの属性がサイズ属性を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
これらの簡潔な例が示すように、このタイプの拡張属性メカニズムはそれと共に総合的を保っている間、プロトコル仕様で扱われる必要がある大きいセットの問題をもたらします。
Shepler Informational [Page 8] RFC 2624 NFSv4 Design Considerations June 1999
Sheplerの情報[8ページ]のRFC2624NFSv4は1999年6月に問題を設計します。
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.
命名されたか拡張している属性メカニズムを提供する操作環境があります。デジタルUnixは何らかの一般化された形式で拡張属性のストレージに備えます。 また[HPFS]とNTFS[ナーガル]が備えるHPFSは伝統的なファイルに関連しているデータを命名しました。 また、SGIのローカルファイルシステム(XFS)はこのタイプの名前/値の拡張属性に備えます。 しかしながら、これらか他の環境から取ることができる明確な方向はあるように思えません。
5.3. Access Control Lists
5.3. アクセスコントロールリスト
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).
ある特定のタイプの拡張属性としてアクセスControl Lists(ACL)を見なすことができます。 この属性はファイルかディレクトリへのユーザアクセスの名称です。 多くのベンダーが、ネットワークの向こう側にサーバのACLメカニズムを広げるために付属のプロトコルをNFSに作成しました。 均質の操作環境のために一般にこれをしました。 サーバは、ファイルシステム対象物へのアクセスの上にまだACLを解釈していて、最終的なコントロールを持っていますが、クライアントはこれらの追加議定書でACLを操作できます。 また、他の分散ファイルシステムはサポート(DFS、AFS、およびCIFS)をACLに供給しました。
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サポートのための要件を追い立てる基礎的要素はユーザ基礎あたりのaにシステムデータをファイルするためにアクセスを承諾して、制限するユーザの願望です。 ユーザと現在の分散ファイルシステムサポートの願望に基づいて、それは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はタイプ分野、アイデンティティ、および許可ビットから成るAccess Control Entriesの配列で類似構造物を持っていますが、類似性はそこで終わります。 各モデルは、それ自身のエントリータイプの異形を定義して、ユーザとグループを異なって特定して、許可ビットの異種を提供して、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サポートの複雑な本質があっても、基本機能をユーザに少なくとも提供できるソリューションをめざして努力するまだ価値があります。
Shepler Informational [Page 9] RFC 2624 NFSv4 Design Considerations June 1999
Sheplerの情報[9ページ]のRFC2624NFSv4は1999年6月に問題を設計します。
6. RPC Mechanism and Security
6. RPCメカニズムとセキュリティ
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 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.
6.1. User identification
6.1. User identification
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 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.
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.
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.
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.
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.
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.
6.2. Security
6.2. Security
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
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
Shepler Informational [Page 10] RFC 2624 NFSv4 Design Considerations June 1999
Shepler Informational [Page 10] RFC 2624 NFSv4 Design Considerations June 1999
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.
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.
6.2.1. Transport Independence
6.2.1. Transport Independence
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.
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.
6.2.2. Authentication
6.2.2. Authentication
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.
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.
6.2.3. Data Integrity
6.2.3. Data Integrity
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.
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.
Shepler Informational [Page 11] RFC 2624 NFSv4 Design Considerations June 1999
Shepler Informational [Page 11] RFC 2624 NFSv4 Design Considerations June 1999
6.2.4. Data Privacy
6.2.4. Data Privacy
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.
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.
6.2.5. Security Negotiation
6.2.5. Security Negotiation
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).
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).
6.3. Summary
6.3. Summary
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.
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.
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 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.
Shepler Informational [Page 12] RFC 2624 NFSv4 Design Considerations June 1999
Shepler Informational [Page 12] RFC 2624 NFSv4 Design Considerations June 1999
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.
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.
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.
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.
7. Internet Accessibility
7. Internet Accessibility
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.
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.
7.1. Congestion Control and Transport Selection
7.1. Congestion Control and Transport Selection
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.
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.
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.
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.
Shepler Informational [Page 13] RFC 2624 NFSv4 Design Considerations June 1999
Shepler Informational [Page 13] RFC 2624 NFSv4 Design Considerations June 1999
7.2. Firewalls and Proxy Servers
7.2. Firewalls and Proxy Servers
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'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.
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.
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.
The problems encountered in making the NFS protocol work through firewalls are described in detail in [RFC2054] and [RFC2055].
The problems encountered in making the NFS protocol work through firewalls are described in detail in [RFC2054] and [RFC2055].
7.3. Multiple RPCs and Latency
7.3. Multiple RPCs and Latency
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.
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.
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.
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.
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.
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.
Shepler Informational [Page 14] RFC 2624 NFSv4 Design Considerations June 1999
Shepler Informational [Page 14] RFC 2624 NFSv4 Design Considerations June 1999
8. File locking / recovery
8. File locking / recovery
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 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.
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.
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.
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):
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):
o Integration with the NFS protocol and ease of implementation.
o Integration with the NFS protocol and ease of implementation.
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 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 Scalable solutions - thousands of clients. The server should
not be required to maintain significant client file locking
state between server instantiations.
o Scalable solutions - thousands of clients. The server should not be required to maintain significant client file locking state between server instantiations.
o Internet capable (firewall traversal, latency sensitive). The
server should not be required to initiate TCP connections to
clients.
o Internet capable (firewall traversal, latency sensitive). The server should not be required to initiate TCP connections to clients.
Shepler Informational [Page 15] RFC 2624 NFSv4 Design Considerations June 1999
Shepler Informational [Page 15] RFC 2624 NFSv4 Design Considerations June 1999
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 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.
9. Internationalization
9. Internationalization
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 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.
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.
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.
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.
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.
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
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
Shepler Informational [Page 16] RFC 2624 NFSv4 Design Considerations June 1999
Shepler Informational [Page 16] RFC 2624 NFSv4 Design Considerations June 1999
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.
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.
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.
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.
10. Security Considerations
10. Security Considerations
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.
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.
10.1. Denial of Service
10.1. Denial of Service
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.
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.
Shepler Informational [Page 17] RFC 2624 NFSv4 Design Considerations June 1999
Shepler Informational [Page 17] RFC 2624 NFSv4 Design Considerations June 1999
11. Bibliography
11. Bibliography
[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: Network File System Protocol Specification", RFC 1094, March 1989. 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. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. 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 Version 3 Protocol Specification", RFC 1813, June 1995. 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] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 1831, August 1995. 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: External Data Representation Standard", RFC 1832, August 1995. 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., "Binding Protocols for ONC RPC Version 2", RFC 1833, August 1995. 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., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996. 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 Client Specification", RFC 2054, October 1996. 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 Specification", RFC 2055, October 1996. http://www.ietf.org/rfc/rfc2055.txt
Shepler Informational [Page 18] RFC 2624 NFSv4 Design Considerations June 1999
Shepler Informational [Page 18] RFC 2624 NFSv4 Design Considerations June 1999
[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., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997. 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 A Mail-Safe Transformation Format of Unicode", RFC 2152, May 1997. 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 Protocol Specification", RFC 2203, August 1995. 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, October 1997. 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, a transformation format of ISO 10646", RFC 2279, January 1998. 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] Dierks, T. and C. Allen, "The TLS Protocols Version 1.0", RFC 2246, Certicom, January 1999. 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] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. 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] 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.
[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., "Disconnected Operation for AFS," June 1993. Proc. USENIX Symp. on Mobile and Location-Independent Computing, Cambridge, August 1993.
Shepler Informational [Page 19] RFC 2624 NFSv4 Design Considerations June 1999
Shepler Informational [Page 19] RFC 2624 NFSv4 Design Considerations June 1999
[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., "Disconnected Operations in the Coda File System," ACM Trans. on Computer Systems, vol. 10, no. 1, pp. 3-25, Feb. 1992.
[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., "Exploiting Weak Connectivity for Mobile File Access," Proc. of the 15th ACM Symp. on Operating Systems Principles Dec. 1995.
[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.
[サンドベルイ]サンドベルイ、R.、D.ゴールドバーグ、S.Kleiman、D.ウォルシュ、B.リヨン、「太陽のデザインと実現はファイルシステムをネットワークでつなぎます」、USENIX会議の議事録、USENIX協会、バークレー(カリフォルニア)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.、エブリングM.R.、クマー、P.、Lu(Q.)は「外されることでモバイル・コンピューティング環境における操作を経験します」、Proc。. USENIX Sympについてモバイルの、そして、Locationから独立しているComputing(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]、「ユニコード規格、バージョン2.1インチ、ユニコードInc.、ユニコード共同体、私書箱700519、カリフォルニア95710-0519サンノゼ(米国)1998年ユニコード技術報告書#8--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] 「サポートされないスクリプト」ユニコードInc.、ユニコード共同体、私書箱700519、カリフォルニア95710-0519サンノゼ(米国)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]TheOpenGroup、開放グループ規格、「システム管理:」 「データ保存管理(XDSM)アピ」、ISBN1-85912-190X、1997年1月。
Shepler Informational [Page 20] RFC 2624 NFSv4 Design Considerations June 1999
Sheplerの情報[20ページ]のRFC2624NFSv4は1999年6月に問題を設計します。
[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]TheOpenGroup、織り込むプロトコル: XNFS、バージョン3W、TheOpenGroup、1010高架鉄道幹線道路スイート380、メンローパーク、カリフォルニア 94025、ISBN1-85912-184-5、1998年2月。 利用可能なHTMLバージョン: http://www.opengroup.org
12. Acknowledgments
12. 承認
o Brent Callaghan for content contributions.
o 満足している貢献のためのブレント・キャラハン。
13. Author's Address
13. 作者のアドレス
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
Driveオースチン、スペンサーSheplerサン・マイクロシステムズ・インク7808Moonflowerテキサス 78750
Phone: (512) 349-9376 EMail: spencer.shepler@eng.sun.com
以下に電話をしてください。 (512) 349-9376 メールしてください: spencer.shepler@eng.sun.com
Shepler Informational [Page 21] RFC 2624 NFSv4 Design Considerations June 1999
Sheplerの情報[21ページ]のRFC2624NFSv4は1999年6月に問題を設計します。
14. Full Copyright Statement
14. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Shepler Informational [Page 22]
Shepler情報です。[22ページ]
一覧
スポンサーリンク
