RFC3426 日本語訳
3426 General Architectural and Policy Considerations. S. Floyd. November 2002. (Format: TXT=54868 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Floyd, Editor Request for Comments: 3426 Internet Architecture Board Category: Informational November 2002
ワーキンググループのS.フロイド、コメントを求めるエディタ要求をネットワークでつないでください: 3426年のインターネット・アーキテクチャ委員会カテゴリ: 情報の2002年11月
General Architectural and Policy Considerations
建築するのと方針の一般問題
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 (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document suggests general architectural and policy questions that the IETF community has to address when working on new standards and protocols. We note that this document contains questions to be addressed, as opposed to guidelines or architectural principles to be followed.
このドキュメントは新しい規格とプロトコルに取り組むときIETF共同体が記述しなければならない建築するのと方針の一般的な質問を示します。 私たちは、ガイドラインか建築原則と対照的に続かれるように記述されるためにこのドキュメントが質問を含むことに注意します。
1. Introduction
1. 序論
This document suggests general architectural and policy questions to be addressed in our work in the IETF. This document contains questions to be addressed, as opposed to guidelines or architectural principles to be followed. These questions are somewhat similar to the "Security Considerations" currently required in IETF documents [RFC2316].
このドキュメントは、IETFでの私たちの仕事で記述されるために建築するのと方針の一般的な質問を示します。 このドキュメントはガイドラインか建築原則と対照的に続かれるように記述されるべき質問を含んでいます。 これらの質問は現在IETFドキュメント[RFC2316]で必要である「セキュリティ問題」といくらか同様です。
This document is motivated in part by concerns about a growing lack of coherence in the overall Internet architecture. We have moved from a world of a single, coherent architecture designed by a small group of people, to a world of complex, intricate architecture to address a wide-spread and heterogeneous environment. Because individual pieces of the architecture are often designed by sub-communities, with each sub-community having its own set of interests, it is necessary to pay increasing attention to how each piece fits into the larger picture, and to consider how each piece is chosen. For example, it is unavoidable that each of us is inclined to solve a problem at the layer of the protocol stack and using the tools that we understand the best; that does not necessarily mean that this is the most appropriate layer or set of tools for solving this problem in the long-term.
このドキュメントは総合的なインターネット構造における増加している一貫性の欠如に関する心配によって一部動機づけられています。 私たちは広範囲の状態でaを記述するように人々の小さいグループによって複雑で、複雑な構造の世界に設計されたただ一つの、そして、コヒーレントの構造と異機種混在環境の世界から移りました。 構造の個体がしばしばサブ共同体によって設計されていて、それ自身を持っていると設定されたそれぞれの関心のサブ一致があるので、各断片がどうより大きな構想に収まるかへの高まる注目を支払って、各断片がどのように選ばれているかを考えるのが必要です。 例えば、私たち各人が私たちがベストを理解しているというプロトコル・スタックとツールを使用する層の問題を解決する傾向があるのは、避けられません。 それは、必ずこれが最も適切な層であるか解決のためのツールのセットが長期のこの問題であることを意味するというわけではありません。
Floyd Informational [Page 1] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[1ページ]のRFC3426建築するのと方針問題2002年11月
Our assumption is that this document will be used as suggestions (but not a checklist!) of issues to be addressed by IETF members in chartering new working groups, in working in working groups, and in evaluating the output from other working groups. This document is not a primer on how to design protocols and architectures, and does not provide answers to anything.
私たちの仮定は新しいワーキンググループをチャーターする際にIETFメンバーによって記述されるのにこのドキュメントが問題の提案(しかし、チェックリストでない!)として使用されるということです、ワーキンググループと、他のワーキンググループから出力を評価する際に働く際に。 このドキュメントは、どうプロトコルと構造を設計するかに関する入門書でなく、また何の答えでも提供しません。
2. Relationship to "Architectural Principles of the Internet"
2. 「インターネットの建築プリンシプルズ」との関係
RFC 1958 [RFC1958] outlines some architectural principles of the Internet, as "guidelines that have been found useful in the past, and that may be useful to those designing new protocols or evaluating such designs." An example guideline is that "it is also generally felt that end-to-end functions can best be realized by end-to-end protocols." Similarly, an example design issue from [RFC1958] is that "heterogeneity is inevitable and must be supported by design."
RFC1958[RFC1958]はインターネットのいくつかの建築原則について概説します、「過去、およびそれで役に立つわかったガイドラインは新しいプロトコルを設計するか、またはそのようなデザインを評価するものの役に立つかもしれない」ので。 例のガイドラインは「また、一般に、終わりから終わりへのプロトコルで終わりから終わりへの機能を実現できると最も良い感じられる」ということです。 同様に、[RFC1958]からの例のデザイン問題は「異種性を必然であり、故意に支持しなければならない」ということです。
In contrast, this document serves a slightly different purpose, by suggesting additional architectural questions to be addressed. Thus, one question suggested in this document is the following: "Is this proposal the best long-term solution to the problem? If not, what are the long-term costs of this solution, in terms of restrictions on future development, if any?" This question could be translated to a roughly equivalent architectural guideline, as follows: "Identify whether the proposed protocol is a long-term solution or a short-term solution, and identify the long-term costs and the exit strategy for any short-term solutions."
対照的に、記述されるために追加建築質問を示すことによって、このドキュメントはわずかに異なった目的に役立ちます。 したがって、本書では示された1つの質問が以下です: 「この提案は問題の最も良い長期的な解決法ですか?」 「まして、今後の開発の制限でこの解決策の長期のコストはもしあれば何ですか?」 以下の通りおよそ同等な建築ガイドラインにこの質問を翻訳できました: 「提案されたプロトコルが長期的な解決法かそれとも短期的な解決策であるか特定してください、そして、長期のコストとどんな短期的な解決策のための撤退戦略も特定してください。」
In contrast, other questions are more open-ended, such as the question about robustness: "How robust is the protocol, not just to the failure of nodes, but also to compromised or malfunctioning components, imperfect or defective implementations, etc?" As a community, we are still learning about the degree of robustness that we are able to build into our protocols, as well as the tools that are available to ensure this robustness. Thus, there are not yet clear architectural guidelines along the lines of "Ensure that your protocol is robust against X, Y, and Z."
対照的に、他の質問は丈夫さに関する質問などのように、より制限のないです: 「プロトコルは単にノードの失敗するのに強健であるのではなく、妥協されるか誤動作コンポーネント、不完全であるか欠陥がある実現などにもどれくらい強健ですか?」 共同体として、私たちはまだ、私たちがプロトコルに建てることができるという丈夫さのおよそ度合いを学んでいます、この丈夫さを確実にするために利用可能なツールと同様に。 したがって、まだ、「プロトコルが確実にX、Y、およびZ.に対して強健になるようにしてください」の線に沿って明確な建築ガイドラインがありません。
3. Questions
3. 問題
In this section we list some questions to ask in designing protocols. Each question is discussed more depth in the rest of this paper. We aren't suggesting that all protocol design efforts should be required to explicitly answer all of these questions; some questions will be more relevant to one document than to another. We also aren't suggesting that this is a complete list of architectural concerns.
このセクションで、私たちはプロトコルを設計する招くいくつかの質問を記載します。 この紙の残りにおける、より多くの深さに各問題について議論します。 私たちは、すべてのプロトコルデザインの努力が明らかにこれらの質問のすべてに答えるのに必要であるべきであると示唆していません。 いくつかの質問が別のものより1通のドキュメントにさらに関連するようになるでしょう。 また、私たちは、これが建築関心に関する全リストであると示唆していません。
Floyd Informational [Page 2] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[2ページ]のRFC3426建築するのと方針問題2002年11月
DESIGN QUESTIONS:
質問を設計してください:
Justifying the Solution:
ソリューションを正当化します:
* Why are you proposing this solution, instead of proposing something else, or instead of using existing protocols and procedures?
* 他の何かを提案することの代わりに既存のプロトコルと手順を用いることの代わりにあなたはなぜこの解決策を提案していますか?
Interactions between Layers:
層の間の相互作用:
* Why are you proposing a solution at this layer of the protocol stack, rather than at another layer? Are there solutions at other layers of the protocol stack as well?
* あなたはなぜ別の層でというよりむしろプロトコル・スタックのこの層で解決策を提案していますか? 解決策がまた、プロトコル・スタックの他の層にありますか?
* Is this an appropriate layer in terms of correctness of function, data integrity, performance, ease of deployment, the diagnosability of failures, and other concerns?
* これは機能、データ保全、性能、展開の容易さ、失敗のdiagnosability、および他の関心の正当性に関する適切な層ですか?
* What are the interactions between layers, if any?
* 層の間の相互作用はもしあれば何ですか?
Long-term vs. Short-term Solutions:
短期的なソリューションに対する長期:
* Is this proposal the best long-term solution to the problem?
* この提案は問題の最も良い長期的な解決法ですか?
* If not, what are the long-term costs of this solution, in terms of restrictions on future development, if any? What are the requirements for the development of longer-term solutions?
* まして、今後の開発の制限でこの解決策の長期のコストはもしあれば何ですか? より長い期間ソリューションの開発のための要件は何ですか?
The Whole Picture vs. Building Blocks:
全貌対ブロック:
* Have you considered the larger context, while appropriately restricting your own design efforts to one part of the whole?
* あなたは適切にあなた自身のデザインの努力を全体の一部に制限している間、より大きい文脈を考えていますか?
* Are there parts of the overall solution that will have to be provided by other IETF Working Groups or by other standards bodies?
* 他のIETF Working Groupsか他の標準化団体によって提供されなければならない総合的な解決法の部分がありますか?
EVALUATION QUESTIONS:
評価は質問されます:
Weighing Benefits against Costs:
測定はコストに対して利益を得ます:
* How do the architectural benefits of a proposed new protocol compare against the architectural costs, if any? Have the architectural costs been carefully considered?
* 提案された新しいプロトコルの建築利益はどのようにもしあれば建築コストに対して比較されますか? 建築コストは慎重に考えられましたか?
Robustness:
丈夫さ:
* How robust is the protocol, not just to the failure of nodes, but also to compromised or malfunctioning components, imperfect or defective implementations, etc?
* プロトコルは単にノードの失敗するのに強健であるのではなく、妥協されるか誤動作コンポーネント、不完全であるか欠陥がある実現などにもどれくらい強健ですか?
Floyd Informational [Page 3] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[3ページ]のRFC3426建築するのと方針問題2002年11月
* Does the protocol take into account the realistic conditions of the current or future Internet (e.g., packet drops and packet corruption; packet reordering; asymmetric routing; etc.)?
* プロトコルは現在の、または、将来のインターネット(例えば、パケット滴とパケット不正; パケット再命令; 非対称のルーティング; など)の現実的な状態を考慮に入れますか?
Tragedy of the Commons:
下院の悲劇:
* Is performance still robust if everyone is using this protocol? Are there other potential impacts of widespread deployment that need to be considered?
* 皆がこのプロトコルを使用しているなら、性能はまだ体力を要しますか? 考えられる必要がある広範囲の展開の他の可能性のある衝撃がありますか?
Protecting Competing Interests:
保護競合する利益:
* Does the protocol protect the interests of competing parties (e.g., not only end-users, but also ISPs, router vendors, software vendors, or other parties)?
* プロトコルは競争しているパーティー(例えば、エンドユーザだけではなく、ISP、ルータ業者、ソフトウェア業者、または相手)の関心を保護しますか?
Designing for Choice vs. Avoiding Unnecessary Complexity:
選択のための設計対不要な複雑さを避けます:
* Is the protocol designed for choice, to allow different players to express their preferences where appropriate? At the other extreme, does the protocol provide so many choices that it threatens interoperability or introduces other significant problems?
* 異なったプレーヤーが適切であるところで彼らの好みを言い表すのを許容するためには選択のために設計されたプロトコルである、-- それとは正反対に、プロトコルがとても多くの選択を提供するので、それは、相互運用性を脅かしますか、他の重大な問題を紹介しますか?
Preserving Evolvability?
Evolvabilityを保存しますか?
* Does the protocol protect the interests of the future, by preserving the evolvability of the Internet? Does the protocol enable future developments?
* プロトコルは、インターネットのevolvabilityを保存することによって、未来の関心を保護しますか? プロトコルは未来の発展を可能にしますか?
* If an old protocol is overloaded with new functionality, or reused for new purposes, have the possible complexities introduced been taken carefully into account?
* 古いプロトコルが新しい機能性で積みすぎられるか、または新しい目的のために再利用されるなら、導入された可能な複雑さは慎重に考慮に入れられましたか?
* For a protocol that introduces new complexity to the Internet architecture, how does the protocol add robustness and preserve evolvability, and how does it also introduce new fragilities to the system?
* インターネット構造に新しい複雑さを紹介するプロトコルのために、プロトコルは、どのように丈夫さを加えて、evolvabilityを保存するか、そして、また、それはどのように新しいもろさをシステムに紹介しますか?
Internationalization:
国際化:
* Where protocols require elements in text format, have the possibly conflicting requirements of global comprehensibility and the ability to represent local text content been properly weighed against each other?
* プロトコルがテキスト形式で要素を必要とするところでは、グローバルな分かり易さのことによると闘争している要件とローカルのテキスト内容を表す能力は適切に互いに比較考量されましたか?
Floyd Informational [Page 4] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[4ページ]のRFC3426建築するのと方針問題2002年11月
DEPLOYMENT QUESTIONS:
展開は質問されます:
* Is the protocol deployable?
* プロトコルは配備可能ですか?
Each of these questions is discussed in more depth in the rest of this paper.
この紙の残りにおける、より多くの深さでそれぞれのこれらの問題について議論します。
4. Justifying the Solution
4. ソリューションを正当化します。
Question: Why are you proposing this solution, instead of proposing something else, or instead of using existing protocols and procedures?
以下に質問してください。 他の何かを提案することの代わりに既存のプロトコルと手順を用いることの代わりにあなたはなぜこの解決策を提案していますか?
4.1. Case study: Integrated and Differentiated Services
4.1. ケーススタディ: 統合していて微分されたサービス
A good part of the work of developing integrated and differentiated services has been to understand the problem to be solved, and to come to agreement on the architectural framework of the solution, and on the nature of specific services. Thus, when integrated services were being developed, the specification of the Controlled Load [RFC2211] and Guaranteed [RFC2212] services each required justification of the need for that particular service, of low loss and bounded delay respectively.
展開している統合していて微分されたサービスの仕事の良い部分は、解決すべき課題を理解して、解決策の建築枠組み、および特定にサービスの本質の協定に来ることになっていました。 統合サービスが開発されていたとき、したがって、Controlled Load[RFC2211]とGuaranteed[RFC2212]サービスの仕様はそれぞれそれぞれその特定のサービスの必要性、低い損失と境界がある遅れの正当化を必要としました。
Later, when RFC 2475 on "An Architecture for Differentiated Services" proposed a scalable, service differentiation architecture that differs from the previously-defined architecture for integrated services, the document also had to clearly justify the requirements for this new architecture, and compare the proposed architecture to other possible approaches [RFC2475]. Similarly, when the Assured Forwarding [RFC2597] and Expedited Forwarding [RFC3246] Per-Hop Behaviors of differentiated services were proposed, each service required a justification of the need for that service in the Internet.
「微分されたサービスのための構造」のRFC2475がその後統合サービスのために以前に定義された構造と異なっているスケーラブルなサービス分化構造を提案したとき、ドキュメントも、この新しい構造のために明確に要件を正当化して、他の可能なアプローチ[RFC2475]に提案された構造をたとえなければなりませんでした。 微分されたサービスの1ホップあたりのAssured Forwarding[RFC2597]とExpedited Forwarding[RFC3246]Behaviorsが提案されたとき、同様に、各サービスはインターネットでのそのサービスの必要性の正当化を必要としました。
5. Interactions between Layers
5. 層の間の相互作用
Questions: Why are you proposing a solution at this layer of the protocol stack, rather than at another layer? Are there solutions at other layers of the protocol stack as well?
質問: あなたはなぜ別の層でというよりむしろプロトコル・スタックのこの層で解決策を提案していますか? 解決策がまた、プロトコル・スタックの他の層にありますか?
Is this an appropriate layer in terms of correctness of function, data integrity, performance, ease of deployment, the diagnosability of failures, and other concerns?
これは機能、データ保全、性能、展開の容易さ、失敗のdiagnosability、および他の関心の正当性に関する適切な層ですか?
What are the interactions between layers, if any?
層の間の相互作用はもしあれば何ですか?
Floyd Informational [Page 5] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[5ページ]のRFC3426建築するのと方針問題2002年11月
5.1. Discussion: The End-to-End Argument
5.1. 議論: 終わりから終わりへの議論
The classic 1984 paper on "End-To-End Arguments In System Design" [SRC84] begins a discussion of where to place functions among modules by suggesting that "functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level. Examples discussed in the paper include bit error recovery, security using encryption, duplicate message suppression, recovery from system crashes, and delivery acknowledgement. Low level mechanisms to support these functions are justified only as performance enhancements." The end-to-end principle is one of the key architectural guidelines to consider in choosing the appropriate layer for a function.
古典的な1984年の「システム設計における終わりから終わりへの議論」[SRC84]に関する紙は「その低レベルでそれらを提供する費用と比べると、システムの低レベルに置かれた機能は、余分であるか、または少ない価値についてそうするかもしれません」と示すことによってどこに機能をモジュールに置くかに関する議論を始めます。 紙で議論した例は噛み付いているエラー回復、暗号化を使用するセキュリティ、写しメッセージ抑圧、システムクラッシュからの回復、および配送承認を含んでいます。 「これらの機能をサポートする低い平らなメカニズムは単にパフォーマンス強化として正当化されます。」 終わりから終わりへの原則は機能のために適切な層を選ぶ際に考える主要な建築ガイドラインの1つです。
5.2. Case study: Endpoint Congestion Management
5.2. ケーススタディ: 終点ふくそう管理
The goal of the Congestion Manager in Endpoint Congestion Management is to allow multiple concurrent flows with the same source and destination address to share congestion control state [RFC3124]. There has been a history of proposals for multiplexing flows at different levels of the protocol stack; proposals have included adding multiplexing at the HTTP (WebMux) and TCP (TCP Control Blocks) layers, as well as below TCP (the Congestion Manager) [Multiplexing].
Endpoint Congestion ManagementのCongestionマネージャの目標は同じソースと送付先アドレスがある複数の同時発生の流れが輻輳制御状態[RFC3124]を共有するのを許容することです。 プロトコル・スタックの異なったレベルで流れを多重送信するための提案の歴史がありました。 提案は、HTTP(WebMux)とTCP(TCP Control Blocks)層においてTCP(Congestionマネージャ)[多重送信する]の下に多重送信しながら、加えるのを含んでいました。
However, the 1989 article on "Layered Multiplexing Considered Harmful" suggests that "the extensive duplication of multiplexing functionality across the middle and upper layers is harmful and should be avoided" [T89]. Thus, one of the key issues in providing mechanisms for multiplexing flows is to determine which layer or layers of the protocol stack are most appropriate for providing this functionality. The natural tendency of each researcher is generally to add functionality at the layer that they know the best; this does not necessarily result in the most appropriate overall architecture.
しかしながら、「中央の、そして、上側の層の向こう側に機能性を多重送信する大規模な重複は、有害であり、避けられるべきです。」と、1989年の「有害であると考えられた層にされたマルチプレクシング」に関する記事は示します[T89]。 したがって、流れを多重送信するのにメカニズムを提供することにおける主要な問題の1つはこの機能性を提供するのに、プロトコル・スタックのどの層か層が最も適切であるかを決定することです。 それぞれの研究者の生まれながらの傾向は一般に、彼らが特に知っている層で機能性を加えることです。 これは必ず最も適切な総合的な構造をもたらすというわけではありません。
5.3. Case study: Layering Applications on Top of HTTP
5.3. ケーススタディ: HTTPの上でアプリケーションを層にします。
There has been considerable interest in layering applications on top of HTTP [RFC3205]. Reasons cited include compatibility with widely- deployed browsers, the ability to reuse client and server libraries, the ability to use existing security mechanisms, and the ability to traverse firewalls. As RFC 3205 discusses, "the recent interest in layering new protocols over HTTP has raised a number of questions when such use is appropriate, and the proper way to use HTTP in contexts where it is appropriate." Thus, RFC 3205 addresses not only the benefits of layering applications on top of HTTP, but also evaluates the additional complexity and overhead of layering an application on top of HTTP, compared to the costs of introducing a special-purpose protocol.
HTTP[RFC3205]の上にレイヤリングアプリケーションへの相当な興味がありました。 引用された理由は広く配備されたブラウザ(クライアント、サーバライブラリ、既存のセキュリティー対策を使用する能力、およびファイアウォールを横断する能力を再利用する能力)との互換性を含んでいます。 RFC3205が議論する、「HTTPの上で新しいプロトコルを層にすることへの最近の関心はそのような使用がいつ適切であるかという多くの疑問、およびそれが適切である文脈でHTTPを使用する適切な方法を引き起こしました」。 したがって、RFC3205はHTTPの上にレイヤリングアプリケーションの恩恵だけを記述しませんが、HTTPの上でアプリケーションを層にする追加複雑さとオーバーヘッドをまた評価します、専用プロトコルを紹介するコストと比べて。
Floyd Informational [Page 6] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[6ページ]のRFC3426建築するのと方針問題2002年11月
The web page on "References on Layering and the Internet Architecture" has pointers to additional papers discussing general layering issues in the Internet architecture [Layering].
「レイヤリングに関する参照とインターネット構造」のウェブページはインターネット構造[レイヤリング]の一般的なレイヤリング問題について議論するポインタを追加書類に持っています。
6. Long-term vs. Short-term Solutions
6. 短期的なソリューションに対して長期的です。
Questions: Is this proposal the best long-term solution to the problem?
質問: この提案は問題の最も良い長期的な解決法ですか?
If not, what are the long-term costs of this solution, in terms of restrictions on future development, if any? What are the requirements for the development of longer-term solutions?
まして、今後の開発の制限でこの解決策の長期のコストはもしあれば何ですか? より長い期間ソリューションの開発のための要件は何ですか?
6.1. Case study: Traversing NATs
6.1. ケーススタディ: NATsを横断します。
In order to address problems with NAT middleboxes altering the external address of endpoints, various proposals have been made for mechanisms where an originating process attempts to determine the address (and port) by which it is known on the other side of a NAT. This would allow an originating process to be able to use address data in the protocol exchange, or to advertise an external address from which it will receive connections.
終点の外部アドレスを変更するNAT middleboxesに関するその問題を訴えて、由来している過程がそれがNATの反対側の上で知られているアドレス(そして、ポート)を決定するのを試みるメカニズムのために様々な提案をしました。 これは、由来している過程がプロトコル交換にアドレスデータを使用するか、またはそれが接続を受ける外部アドレスの広告を出すことができるのを許容するでしょう。
The IAB in [RFC3424] has outlined reasons why these proposals can be considered, at best, short-term fixes to specific problems, and the specific issues to be carefully evaluated before standardizing such proposals. These issues include the identification of the limited-scope problem to be fixed, the description of an exit strategy for the short-term solution, and the description of the longer-term problems left unsolved by the short-term solution.
[RFC3424]のIABは短期的であることをこれらの提案をせいぜい検討できる理由が、そのような提案を標準化する前に慎重に評価されるのを特定の問題、および特定の問題に修理する理由について概説しました。 これらの問題は修正される限られた範囲問題の識別、短期的な解決策のための撤退戦略の記述、および短期的な解決策で未解決であることで残っているより長い期間問題の記述を含んでいます。
7. Looking at the whole picture vs. making a building block
7. ブロックを作るように全貌を見せます。
For a complex protocol which interacts with protocols from other standards bodies as well as from other IETF working groups, it can be necessary to keep in mind the overall picture while, at the same time, breaking out specific parts of the problem to be standardized in particular working groups.
他の標準化団体と他のIETFワーキンググループからプロトコルと対話する複雑なプロトコルに、全体像を覚えておくのが同時に特定のワーキンググループで標準化されるために問題の特定の部分を開ける間、必要である場合があります。
Question: Have you considered the larger context, while restricting your own design efforts to one part of the whole?
以下に質問してください。 あなたはあなた自身のデザインの努力を全体の一部に制限している間、より大きい文脈を考えていますか?
Question: Are there parts of the overall solution that will have to be provided by other IETF Working Groups or by other standards bodies?
以下に質問してください。 他のIETF Working Groupsか他の標準化団体によって提供されなければならない総合的な解決法の部分がありますか?
Floyd Informational [Page 7] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[7ページ]のRFC3426建築するのと方針問題2002年11月
7.1. Case Study: The Session Initiation Protocol (SIP)
7.1. ケーススタディ: セッション開始プロトコル(一口)
The Session Initiation Protocol (SIP) [RFC2543], for managing connected, multimedia sessions, is an example of a complex protocol that has been broken into pieces for standardization in other working groups. SIP has also involved interaction with other standardization bodies.
接続マルチメディアセッションを管理するために、Session Initiationプロトコル(SIP)[RFC2543]は標準化において、他のワーキンググループでばらばらに壊れている複雑なプロトコルに関する例です。 また、SIPは他の標準化本体との相互作用にかかわりました。
The basic SIP framework is being standardized by the SIP working group. This working group has focused on the core functional features of setting up, managing, and tearing down multimedia sessions. Extensions are considered if they relate to these core features.
基本的なSIP枠組みはSIPワーキンググループによって標準化されています。 マルチメディアセッションを管理して、取りこわして、このワーキンググループはセットアップするコア機能的特色に焦点を合わせました。 これらのコアの特徴に関連するなら、拡大は考えられます。
The task of setting up a multimedia session also requires a description of the desired multimedia session. This is provided by the Session Description Protocol (SDP). SDP is a building block that is supplied by the Multiparty Multimedia Session Control (MMUSIC) working group. It is not standardized within the SIP working group.
また、マルチメディアセッションをセットアップするタスクは必要なマルチメディアセッションの記述を必要とします。 Session記述プロトコル(SDP)でこれを提供します。 SDPはMultiparty Multimedia Session Control(MMUSIC)ワーキンググループによって供給されるブロックです。 それはSIPワーキンググループの中で標準化されません。
Other working groups are involved in standardizing extensions to SIP that fall outside of core functional features or applications. The SIPPING working group is analyzing the requirements for SIP applied to different tasks, and the SIMPLE working group is examining the application of SIP to instant messaging and presence. The IPTEL working group is defining a call processing language (CPL) that interacts with SIP in various ways. These working groups occasionally feed requirements back into the main SIP working group.
他のワーキンググループはコア機能的特色かアプリケーションの外に落ちるSIPに拡大を標準化するのにかかわります。 SIPPINGワーキンググループは異なったタスクに打ち込まれたSIPのための要件を分析しています、そして、SIMPLEワーキンググループはインスタントメッセージングと存在にSIPのアプリケーションを調べています。 IPTELワーキンググループはいろいろSIPと対話する呼び出し処理言語(CPL)を定義しています。 これらのワーキンググループは時折主なSIPワーキンググループに要件をフィードバックします。
Finally, outside standardization groups have been very active in providing the SIP working group with requirements. The Distributed Call Signaling (DCS) group from the PacketCable Consortium, 3GPP, and 3GPP2 are all using SIP for various telephony-related applications, and members of these groups have been involved in drafting requirements for SIP. In addition, there are extensions of SIP which are under consideration in these standardization bodies. Procedures are under development in the IETF to address proposed extensions to SIP, including a category of preliminary, private, or proprietary extensions, and to provide for the safe management of the SIP namespace [MBMWOR02].
最終的に、外の標準化グループはSIPワーキンググループに要件を提供するのにおいて非常に活動的です。 PacketCable Consortium、3GPP、および3GPP2からのDistributed Call Signaling(DCS)グループは様々な電話関連のアプリケーションにSIPをすべて使用しています、そして、これらのグループのメンバーはSIPのための要件を作成するのにかかわりました。 さらに、これらの標準化本体に考慮中であるSIPは拡大があります。 手順は、予備の、または、個人的であるか、独占である拡大のカテゴリを含むSIPに提案された拡大を記述して、SIP名前空間[MBMWOR02]の安全管理に備えるためにIETFで開発中です。
8. Weighing architectural benefits against architectural costs
8. 建築利益について建築コストに比較考量します。
Questions: How do the architectural benefits of a proposed new protocol compare against the architectural costs, if any? Have the architectural costs been carefully considered?
質問: 提案された新しいプロトコルの建築利益はどのようにもしあれば建築コストに対して比較されますか? 建築コストは慎重に考えられましたか?
Floyd Informational [Page 8] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[8ページ]のRFC3426建築するのと方針問題2002年11月
8.1. Case Study: Performance-enhancing proxies (PEPs)
8.1. ケーススタディ: パフォーマンスを機能アップするプロキシ(元気づけます)
RFC 3135 [RFC3135] considers the relative costs and benefits of placing performance-enhancing proxies (PEPs) in the middle of a network to address link-related degradations. In the case of PEPs, the potential costs include disabling the end-to-end use of IP layer security mechanisms; introducing a new possible point of failure that is not under the control of the end systems; adding increased difficulty in diagnosing and dealing with failures; and introducing possible complications with asymmetric routing or mobile hosts. RFC 3135 carefully considers these possible costs, the mitigations that can be introduced, and the cases when the benefits of performance-enhancing proxies to the user are likely to outweigh the costs.
RFC3135[RFC3135]は、ネットワークの中央の性能を高める置くプロキシ(PEPs)の相対的なコストと利益がリンク関連の転落を記述すると考えます。 PEPsの場合では、潜在的コストは、IP層のセキュリティー対策の終わりから最終用途を無効にするのを含んでいます。 失敗の新しい可能なポイントを紹介して、それがエンドシステムのコントロールの下にいません。 付加は失敗を診断して、対処しながら、困難を増やしました。 そして、非対称のルーティングかモバイルホストと共に可能な複雑さを導入すること。 ユーザの性能を高めるプロキシの利益がコストより重そうなときに、RFC3135は、これらが可能なコストと、紹介できる緩和と、ケースであると慎重に考えます。
8.2. Case Study: Open Pluggable Edge Services (OPES)
8.2. ケーススタディ: 開いているPluggable縁のサービス(作品)
One of the issues raised by middleboxes in the Internet involves the end-to-end integrity of data. This is illustrated in the recent question of chartering the Open Pluggable Edge Services (OPES) Working Group. Open Pluggable Edge Services are services that would be deployed as application-level intermediaries in the network, for example, at a web proxy cache between the origin server and the client. These intermediaries would transform or filter content, with the explicit consent of either the content provider or the end user.
インターネットのmiddleboxesによって提起された問題の1つは終わりから終わりへのデータの完全性にかかわります。 これはオープンPluggable Edge Services(作品)作業部会をチャーターする最近の問題で例証されます。 開いているPluggable Edge Servicesは例えばアプリケーションレベル仲介者として起源サーバとクライアントの間のウェブプロキシキャッシュでネットワークで配備されるサービスです。 これらの仲介者は、コンテンツプロバイダーかエンドユーザのどちらかの明白な同意で内容を変えるか、またはフィルターにかけるでしょう。
One of the architectural issues that arose in the process of chartering the OPES Working Group concerned the end-to-end integrity of data. As an example, it was suggested that "OPES would reduce both the integrity, and the perception of integrity, of communications over the Internet, and would significantly increase uncertainly about what might have been done to content as it moved through the network", and that therefore the risks of OPES outweighed the benefits [CDT01].
作品作業部会をチャーターすることの途中に起こった構造的な問題の1つは終わりから終わりへのデータの完全性に関係がありました。 例として、「作品は、インターネットの上で保全と保全、コミュニケーションの認知の両方を抑えて、ネットワークを通って動いたので内容に何をしたかもしれないかに関して不安にかなり増加し」て、したがって、作品のリスクが利益[CDT01]より重かったと示唆されました。
As one consequence of this debate, the IAB wrote a document on "IAB Architectural and Policy Considerations for OPES", considering both the potential architectural benefits and costs of OPES [RFC3238]. This document did not recommend specific solutions or mandate specific functional requirements, but instead included recommendations of issues such as concerns about data integrity that OPES solutions standardized in the IETF should be required to address.
この討論の1つの結果として、IABは「作品のためのIAB建築するのと方針問題」のドキュメントを書きました、潜在的建築利益と作品[RFC3238]のコストの両方を考える場合。 このドキュメントは特定の解決策を推薦したか、または特定の機能条件書を強制したのではなく、記述するIETFで標準化された作品解決が必要であるべきであるというデータ保全に関する心配などの問題の代わりに含まれている推薦を強制しました。
Floyd Informational [Page 9] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[9ページ]のRFC3426建築するのと方針問題2002年11月
9. General Robustness Questions
9. 一般丈夫さ問題
Questions: How robust is the protocol, not just to the failure of nodes, but also to compromised or malfunctioning components, imperfect or defective implementations, etc?
質問: プロトコルは単にノードの失敗するのに強健であるのではなく、妥協されるか誤動作コンポーネント、不完全であるか欠陥がある実現などにもどれくらい強健ですか?
Does the protocol take into account the realistic conditions of the current or future Internet (e.g., packet drops and packet corruption, packet reordering, asymmetric routing, etc.)?
プロトコルが現在の、または、将来のインターネットの現実的な状態を考慮に入れる、(例えば、パケット滴とパケット不正である、パケットが再命令される非対称のルーティングなど)、--
9.1. Discussion: Designing for Robustness
9.1. 議論: 丈夫さのための設計
Robustness has long been cited as one of the overriding goals of the Internet architecture [Clark88]. The robustness issues discussed in [Clark88] largely referred to the robustness of packet delivery even in the presence of failed routers; today robustness concerns have widened to include a goal of robust performance in the presence of a wide range of failures, buggy code, and malicious actions.
インターネット構造[Clark88]の最優先の目標の1つは長い間、丈夫さに挙げられています。 [Clark88]で議論した丈夫さ問題は失敗したルータがあるときさえパケット配信の丈夫さについて主に言及しました。 今日、丈夫さ関心は、さまざまな失敗、バギーのコード、および悪意がある行為があるときロバスト性能の目標を含むように広くなりました。
As [ASSW02] argues, protocols need to be designed somewhat defensively, to maximize robustness against inconsistencies and errors. [ASSW02] discusses several approaches for increasing robustness in protocols, such as verifying information whenever possible; designing interfaces that are conceptually simple and therefore less conducive to error; protecting resources against attack or overuse; and identifying and exposing errors so that they can be repaired.
[ASSW02]が論争するように、プロトコルは、矛盾と誤りに対して丈夫さを最大にするようにいくらか防御的に設計されている必要があります。 [ASSW02]は可能であるときはいつも、情報について確かめなどなどのプロトコルにおける増加する丈夫さのためのいくつかのアプローチについて議論します。 概念的に簡単でしたがってそれほど誤りに役に立たない設計のインタフェース。 攻撃に対してリソースを保護するか、酷使。 そして、それらを修理できるように誤りを特定して、露出すること。
Techniques for verifying information range from verifying that acknowledgements in TCP acknowledge data that was actually sent, to providing mechanisms for routers to verify information in routing messages.
検証から情報範囲について確かめるためのメッセージを発送するTCPでの承認が、実際にメカニズムをルータに提供するのに送られたデータが情報について確かめると認めるテクニック。
Techniques for protecting resources against attack range from preventing "SYN flood" attacks by designing protocols that don't allocate resources for a single SYN packet, to partitioning resources (e.g., preventing one flow or aggregate from using all of the link bandwidth).
攻撃に対してリソースを保護するためのテクニックは単一のSYNパケットのためのリソースを割り当てないプロトコルを設計することによって「SYNフラッド」攻撃を防ぐので、及びます、仕切りのリソース(例えば、1つの流れか集合がリンク帯域幅のすべてを使用するのを防ぐ)に。
9.2. Case Study: Explicit Congestion Notification (ECN)
9.2. ケーススタディ: 明白な混雑通知(電子証券取引ネットワーク)
The Internet is based on end-to-end congestion control, and historically the Internet has used packet drops as the only method for routers to indicate congestion to the end nodes. ECN [RFC3168] is a recent addition to the IP architecture to allow routers to set a bit in the IP packet header to inform end-nodes of congestion, instead of dropping the packet.
インターネットは終わりからエンドへの輻輳制御に基づいています、そして、歴史的に、インターネットはルータが混雑をエンドノードに示す唯一の方法としてパケット滴を使用しました。 電子証券取引ネットワーク[RFC3168]はルータが、IPパケットのヘッダーに混雑のエンドノードを知らせるように少し設定するのを許容するIP構造への最近の追加です、パケットを落とすことの代わりに。
Floyd Informational [Page 10] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[10ページ]のRFC3426建築するのと方針問題2002年11月
The first, Experimental specification of ECN [RFC3168] contained an extensive discussion of the dangers of a rogue or broken router "erasing" information from the ECN field in the IP header, thus preventing indications of congestion from reaching the end-nodes. To add robustness, the standards-track specification [RFC3168] specified an additional codepoint in the IP header's ECN field, to use for an ECN "nonce". The development of the ECN nonce was motivated by earlier research on specific robustness issues in TCP [SCWA99]. RFC 3168 explains that the addition of the codepoint "is motivated primarily by the desire to allow mechanisms for the data sender to verify that network elements are not erasing the CE codepoint, and that data receivers are properly reporting to the sender the receipt of packets with the CE codepoint set, as required by the transport protocol." Supporting mechanisms for the ECN nonce are needed in the transport protocol to ensure robustness of delivery of the ECN-based congestion indication.
1番目、電子証券取引ネットワーク[RFC3168]のExperimental仕様は凶暴であるか壊れているルータがIPヘッダーの電子証券取引ネットワーク分野からの情報を「消す」であるという危険の大規模な議論を含みました、その結果、混雑のしるしがエンドノードに達するのを防ぎます。 丈夫さを加えるために、標準化過程仕様[RFC3168]はIPヘッダーの電子証券取引ネットワーク分野で追加codepointを指定しました、電子証券取引ネットワーク「一回だけ」の使用に。 電子証券取引ネットワーク一回だけの開発はTCP[SCWA99]の特定の丈夫さ問題の以前の研究で動機づけられました。 codepointの添加の「主としてメカニズムを許容する願望によって動機づけられていて、データ送付者は、ネットワーク要素がCE codepointを消していなくて、データ受信装置が、CE codepointがあるパケットの領収書が必要に応じてトランスポート・プロトコルでセットしたと適切に送付者に報告していることを確かめます。」と、RFC3168は説明します。 トランスポート・プロトコルでは、電子証券取引ネットワーク一回だけのためのサポートメカニズムが電子証券取引ネットワークベースの混雑指示の配送の丈夫さを確実にするのが必要です。
In contrast, a more difficult and less clear-cut robustness issue for ECN concerns the differential treatment of packets in the network by middleboxes, based on the TCP header's ECN flags in a TCP SYN packet [RFC3360]. The issue concerns "ECN-setup" SYN packets, that is, SYN packets with ECN flags set in the TCP header to negotiate the use of ECN between the two TCP end-hosts. There exist firewalls in the network that drop "ECN-setup" SYN packets, others that send TCP Reset messages, and yet others that zero ECN flags in TCP headers. None of this was anticipated by the designers of ECN, and RFC 3168 added optional mechanisms to permit the robust operation of TCP in the presence of firewalls that drop "ECN-setup" SYN packets. However, ECN is still not robust to all possible scenarios of middleboxes zeroing ECN flags in the TCP header. Up until now, transport protocols have been standardized independently from the mechanisms used by middleboxes to control the use of these protocols, and it is still not clear what degree of robustness is required from transport protocols in the presence of the unauthorized modification of transport headers in the network. These and similar issues are discussed in more detail in [RFC3360].
対照的に、より難しくて電子証券取引ネットワークには、それほど明快でない丈夫さ問題はmiddleboxesでネットワークにおける、パケットの差別待遇に関係があります、TCP SYNパケット[RFC3360]のTCPヘッダーの電子証券取引ネットワーク旗に基づいて。 問題は「電子証券取引ネットワーク-セットアップ」SYNパケット(すなわち、TCPヘッダーに2人のTCP終わりホストの間で電子証券取引ネットワークの使用を交渉するように設定された電子証券取引ネットワーク旗があるSYNパケット)に関係があります。 ネットワークにおける「電子証券取引ネットワーク-セットアップ」SYNパケットにもかかわらず、メッセージをTCP Resetに送る他のものにもかかわらず、電子証券取引ネットワークがTCPヘッダーで旗を揚げさせるそのゼロの他のものを落とすファイアウォールが存在しています。 このなにも電子証券取引ネットワークのデザイナーによって予期されませんでした、そして、RFC3168は「電子証券取引ネットワーク-セットアップ」SYNパケットを落とすファイアウォールがあるときTCPの体力を要している操作を可能にするために任意のメカニズムを加えました。 しかしながら、電子証券取引ネットワークはTCPヘッダーでまだmiddleboxesゼロ電子証券取引ネットワーク旗のすべての可能なシナリオに強健ではありません。 現在まで、トランスポート・プロトコルはこれらのプロトコルの使用を制御するのにmiddleboxesによって使用されたメカニズムから独自に標準化されました、そして、どの程度の丈夫さがネットワークにおける、輸送ヘッダーの権限のない変更があるときトランスポート・プロトコルから必要であるかは、まだ明確ではありません。 さらに詳細に[RFC3360]でこれらと同様の問題について議論します。
10. Avoiding Tragedy of the Commons
10. 下院の悲劇を避けます。
Question: Is performance still robust if everyone is using the new protocol? Are there other potential impacts of widespread deployment that need to be considered?
以下に質問してください。 皆が新しいプロトコルを使用しているなら、性能はまだ体力を要しますか? 考えられる必要がある広範囲の展開の他の可能性のある衝撃がありますか?
10.1. Case Study: End-to-end Congestion Control
10.1. ケーススタディ: 終わりからエンドへの輻輳制御
[RFC2914] discusses the potential for congestion collapse if flows are not using end-to-end congestion control in a time of high congestion. For example, if a new transport protocol was proposed
流れが高い混雑の時間終わりからエンドへの輻輳制御を使用していないなら、[RFC2914]は混雑崩壊の可能性について議論します。 例えば、新しい輸送であるなら、プロトコルは提案されました。
Floyd Informational [Page 11] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[11ページ]のRFC3426建築するのと方針問題2002年11月
that did not use end-to-end congestion control, it might be easy to show that an individual flow using the new transport protocol would perform quite well as long as all of the competing flows in the network were using end-to-end congestion control. To fully evaluate the new transport protocol, it is necessary to look at performance when many flows are competing, all using the new transport protocol. If all of the competing flows were using the more aggressive transport protocol in a time of high congestion, the result could be high steady-state packet drop rates and reduced overall throughput, with busy links carrying packets that will only be dropped downstream. This can be viewed as a form of tragedy of the commons, when a practice that is productive if done by only one person (e.g., adding a few more sheep to the common grazing pasture) is instead counter-productive when done by everyone [H68].
それは終わりからエンドへの輻輳制御を使用しないで、ネットワークの競争している流れのすべてが終わりからエンドへの輻輳制御を使用していた限り、新しいトランスポート・プロトコルを使用する個々の流れがかなりよく振る舞うのを示すのは簡単であるかもしれません。 新しいトランスポート・プロトコルを完全に評価するのに、多くの流れが競争しているときの性能を見るのが必要です、新しいトランスポート・プロトコルをすべて使用して。 競争している流れのすべてが高い混雑の時間より攻撃的なトランスポート・プロトコルを使用していたなら、結果は、高い定常状態パケット低下率であるかもしれなく、総合的なスループットを減らしました、忙しいリンクが川下に落とされるだけであるパケットを運んでいて。 コモンの悲劇のフォームとしてこれを見なすことができます、1人の人(例えば、普通の牧草を食う牧草に羊をもう少し加える)だけによって行われるなら生産的な習慣が代わりにカウンタ生産的な皆によってされると[H68]であるときに。
11. Balancing Competing Interests
11. バランスをとることの競合する利益
Question: Does the protocol protect the interests of competing parties (e.g., not only end-users, but also ISPs, router vendors, software vendors, or other parties)?
以下に質問してください。 プロトコルは競争しているパーティー(例えば、エンドユーザだけではなく、ISP、ルータ業者、ソフトウェア業者、または相手)の関心を保護しますか?
11.1. Discussion: balancing competing interests
11.1. 議論: バランスをとることの競合する利益
[CWSB02] discusses the role that competition between competing interests plays in the evolution of the Internet, and takes the position that the role of Internet protocols is to design the playing field in this competition, rather than to pick the outcome. The IETF has long taken the position that it can only design the protocols, and that often two competing approaches will be developed, with the marketplace left to decide between them [A02]. (It has also been suggested that "the marketplace" left entirely to itself does not always make the best decisions, and that working to identify and adopt the technically best solution is sometimes helpful. Thus, while the role of the marketplace should not be ignored, the decisions of the marketplace should also not be held as sacred or infallible.)
[CWSB02]は、競合する利益の間の競争相手がインターネットの発展で果たす役割について議論して、インターネットプロトコルの役割が結果を選ぶというよりむしろこの競争における運動場を設計することであるという立場を取ります。 IETFは長い間、プロトコルを設計するだけである場合があり、しばしば、2つの競争しているアプローチが開発されるという立場がかかっています、それら[A02]についてどちらかに決めるのを残っている市場で。 (また、完全に放っておかれた「市場」がいつも最も良い決定をするというわけではなくて、技術的に最も良い解決策を特定して、採用するために働いているのが時々役立っていると示唆されました。 したがって、また、市場の役割を無視するべきでない間、神聖であるか絶対確実であるとして市場の決定を保持するべきではありません。)
An example cited in [CWSB02] of modularization in support of competing interests is the decision to use codepoints in the IP header to select QoS, rather than binding QoS to other properties such as port numbers. This separates the structural and economic issues related to QoS from technical issues of protocols and port numbers, and allows space for a wide range of structural and pricing solutions to emerge.
変調の[CWSB02]で競合する利益を支持して引用された例はポートナンバーなどの他の特性にQoSを縛るよりむしろQoSを選択するのにIPヘッダーでcodepointsを使用するという決定です。 これは、プロトコルとポートナンバーの専門的な問題とQoSに関連する構造的で経済の問題を切り離して、さまざまな構造的、そして、価格設定対策が現れるように紙面を割きます。
There have been perceived problems over the years of individuals adding unnecessary complexity to IETF protocols, increasing the barrier to other implementations of those protocols. Clearly such
個人が不要な複雑さをIETFプロトコルに追加するという数年間の問題は知覚されました、それらのプロトコルの他の実現にバリアを増加させて。 明確にそのようなもの
Floyd Informational [Page 12] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[12ページ]のRFC3426建築するのと方針問題2002年11月
action would not be protecting the interests of open competition. Underspecified protocols can also serve as an unnecessary barrier to open competition.
動作は公開競争の関心を保護していないでしょう。 また、Underspecifiedプロトコルは不要なバリアとして公開競争に機能できます。
12. Designing for Choice vs. Avoiding Unnecessary Complexity:
12. 選択のための設計対不要な複雑さを避けます:
Is the protocol designed for choice, to allow different players to express their preferences where appropriate? At the other extreme, does the protocol provide so many choices that it threatens interoperability or introduces other significant problems?
異なったプレーヤーが適切であるところで彼らの好みを言い表すのを許容するためには選択のために設計されたプロトコルである、-- それとは正反対に、プロトコルがとても多くの選択を提供するので、それは、相互運用性を脅かしますか、他の重大な問題を紹介しますか?
12.1. Discussion: the importance of choice
12.1. 議論: 選択の重要性
[CWSB02] suggests that "the fundamental design goal of the Internet is to hook computers together, and since computers are used for unpredictable and evolving purposes, making sure that the users are not constrained in what they can do is doing nothing more than preserving the core design tenet of the Internet. In this context, user empowerment is a basic building block, and should be embedded into all mechanism whenever possible."
「インターネットの基本的なデザイン目標がコンピュータを一緒に掛けることであり、コンピュータが予測できないで発展している目的に使用されるので、ユーザが彼らができることが強制的でないことを確実にするのは、インターネットのコアデザイン主義をただ保存するです。」と、[CWSB02]は示します。 「ユーザ権限委譲は、このような関係においては、基本的なブロックであり、可能であるときはいつも、すべてのメカニズムに埋め込まれるべきです。」
As an example of choice, "the design of the mail system allows the user to select his SMTP server and his POP server" [CWSB02]. More open-ended questions about choice concern the design of mechanisms that would enable the user to choose the path at the level of providers, or to allow users to choose third-party intermediaries such as web caches, or providers for Open Pluggable Edge Services (OPES). [CWSB02] also notes that the issue of choice itself reflects competing interests. For example, ISPs would generally like to lock in customers, while customers would like to preserve their ability to change among providers.
選択に関する例として、「メールシステムの設計で、ユーザは彼のSMTPサーバーと彼のPOPサーバを選択できる」[CWSB02]。 選択に関する、より制限のない質問はユーザが、プロバイダーのレベルで経路を選ぶか、またはユーザがウェブキャッシュ、またはオープンPluggable Edge Servicesのためのプロバイダー(作品)などの第三者仲介者を選ぶのを許すのを可能にするメカニズムのデザインに関係があります。 また、[CWSB02]は、選択自体の問題が競合する利益を反映することに注意します。 例えば、ISPは一般に顧客の錠などのようにそうするでしょう、顧客がプロバイダーの中で変化する彼らの能力を保持したがっていますが。
At the same time, we note that excessive choice can lead to "kitchen sink" protocols that are inefficient and hard to understand, have too much negotiation, or have unanticipated interactions between options. For example, [P99] notes that excessive choice can lead to difficulty in ensuring interoperability between two independent, conformant implementations of the protocol.
同時に、私たちは、オプションの間に過度の選択が効率が悪くて、理解しにくい「台所流し台」プロトコルにつながることができることに注意するか、あまりに多くの交渉を持っているか、または思いがけない相互作用を持っています。 例えば、[P99]は、過度の選択が2独立者(プロトコルのconformant実現)の間の相互運用性を確実にすることにおける苦労につながることができることに注意します。
The dangers of excessive options are also discussed in [MBMWOR02], which gives guidelines for responding to the "continuous flood" of suggestions for modifications and extensions to SIP (Session Initiation Protocol). In particular, the SIP Working Group is concerned that proposed extensions have general use, and do not provide efficiency at the expense of simplicity or robustness. [MBMWOR02] suggests that other highly extensible protocols developed in the IETF might also benefit from more coordination of extensions.
また、[MBMWOR02]で過度のオプションという危険について議論します。(それは、変更と拡大のための提案の「連続した洪水」に応じるためのガイドラインをSIP(セッションInitiationプロトコル)に与えます)。 SIP作業部会は提案された拡大が一般的使用を持って、簡単さか丈夫さを犠牲にして効率を提供しないことを特に、心配しています。 [MBMWOR02]は、また、IETFで開発された他の非常に広げることができるプロトコルが拡大の、より多くのコーディネートの利益を得るかもしれないのを示します。
Floyd Informational [Page 13] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[13ページ]のRFC3426建築するのと方針問題2002年11月
13. Preserving evolvability?
13. evolvabilityを保存しますか?
Does the protocol protect the interests of the future, by preserving the evolvability of the Internet? Does the protocol enable future developments?
プロトコルは、インターネットのevolvabilityを保存することによって、未来の関心を保護しますか? プロトコルは未来の発展を可能にしますか?
If an old protocol is overloaded with new functionality, or reused for new purposes, have the possible complexities introduced been taken into account?
古いプロトコルが新しい機能性で積みすぎられるか、または新しい目的のために再利用されるなら、導入された可能な複雑さは考慮に入れられましたか?
For a protocol that introduces new complexity to the Internet architecture, does the protocol add robustness and preserve evolvability? Does it also introduce unwanted new fragilities to the system?
インターネット構造に新しい複雑さを紹介するプロトコルのために、プロトコルは、丈夫さを加えて、evolvabilityを保存しますか? また、それは求められていない新しいもろさをシステムに紹介しますか?
13.1. Discussion: evolvability
13.1. 議論: evolvability
There is an extensive literature and an ongoing discussion about the evolvability, or lack of evolvability, of the Internet infrastructure; the web page on "Papers on the Evolvability of the Internet Infrastructure" has pointers to some of this literature [Evolvability]. Issues range from the evolvability and overloading of the DNS; the difficulties of the Internet in evolving to incorporate multicast, QoS, or IPv6; the difficulties of routing in meeting the demands of a changing and expanding Internet; and the role of firewalls and other middleboxes in limiting evolvability.
大量の文学とevolvabilityの現在行われている議論、またはevolvability、インターネット基盤の不足があります。 「インターネットインフラストラクチャのEvolvabilityの上の書類」のウェブページはこの文学[Evolvability]のいくつかにポインタを持っています。 問題はDNSのevolvabilityと積みすぎから変化します。 マルチキャストを取り入れるために発展することにおける、インターネットの困難、QoS、またはIPv6。 変えていて拡張しているインターネットの需要にこたえることにおける、ルーティングの苦労。 そして、evolvabilityを制限することにおけるファイアウォールと他のmiddleboxesの役割。
[CWSB02] suggests that among all of the issues of evolvability, "keeping the net open and transparent for new applications is the most important goal." In the beginning, the relative transparency of the infrastructure was sufficient to ensure evolvability, where a "transparent" network simply routes packets from one end-node to another. However, this transparency has become more murky over time, as cataloged in [RFC3234], which discusses the ways that middleboxes interact with existing protocols and increase the difficulties in diagnosing failures. [CWSB02] realistically suggests the following guideline: "Failures of transparency will occur - design what happens then," where examples of failures of transparency include firewalls, application filtering, connection redirection, caches, kludges to DNS, and the like. Thus, maintaining evolvability also requires mechanisms for allowing evolution in the face of a lack of transparency of the infrastructure itself.
[CWSB02]は、evolvabilityの問題のすべて中では、「新しいアプリケーションに開いて透明にネットを保つのは、最も重要な目標であること」を示します。 初めに、インフラストラクチャの相対的な透明は、evolvabilityを確実にするために十分でした。(そこでは、「透明な」ネットワークが片端ノードから別のノードまで単にパケットを発送します)。 しかしながら、この透明は時間がたつにつれてより暗くなりました、[RFC3234](middleboxesが既存のプロトコルと対話して、失敗を診断しながら困難を増やす方法について議論する)でカタログに載せられるように。 [CWSB02]は現実的に以下のガイドラインを示します: 透明の失敗に関する例がファイアウォール、アプリケーションフィルタリング、接続リダイレクション、キャッシュ、DNSへのクラッジ、および同様のものを含んでいる「透明の失敗は起こるでしょう--その時起こることを設計してください。」 また、したがって、evolvabilityを維持するのは、インフラストラクチャ自体の透明性の不足に直面して発展を許容するためにメカニズムを必要とします。
One of the ways for maintaining evolvability is for designers of new mechanisms and protocols to be as clear as possible about the assumptions that are being made about the rest of the network. New
evolvabilityを維持するための方法の1つは新しいメカニズムとプロトコルのデザイナーができるだけネットワークの残りに関してされている仮定がわかることです。 新しい
Floyd Informational [Page 14] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[14ページ]のRFC3426建築するのと方針問題2002年11月
mechanisms that make unwarranted assumptions about the network can end up placing unreasonable constraints on the future evolution of the network.
ネットワークに関する根拠のない推定をするメカニズムは結局、ネットワークの今後の発展に無理な規制を置くことができます。
13.2. Discussion: overloading
13.2. 議論: 積みすぎ
There has been a strong tendency in the last few years to overload some designs with new functionality, with resulting operational complexities. Extensible protocols could be seen as one of the tools for providing evolvability. However, if protocols and systems are stretched beyond their reasonable design parameters, then scaling, reliability, or security issues could be introduced. Examples of protocols that have been seen as either productively extended, or as dangerously overloaded, or both, include DNS [K02,RFC3403], MPLS [A02a], and BGP [B02]. In some cases, overloading or extending a protocol may reduce total complexity and deployment costs by avoiding the creation of a new protocol; in other cases a new protocol might be the simpler solution.
新しい機能性でいくつかのデザインを積みすぎるここ数年には強い傾向がありました、結果として起こる操作上の複雑さで。 evolvabilityを提供するためのツールの1つを広げることができるプロトコルを見ることができました。 しかしながら、それらの妥当なデザインパラメタを超えてプロトコルとシステムを伸ばすなら、スケーリング、信頼性、または安全保障問題を導入するかもしれません。 見られた生産的に広げられるか、または危険に積みすぎのどちらかであるのでプロトコルに関する例、または両方がDNS[K02、RFC3403]、MPLS[A02a]、およびBGP[B02]を含んでいます。 いくつかの場合、プロトコルを積みすぎるか、または広げていると、総複雑さと展開コストは新しいプロトコルの創造を避けることによって、削減されるかもしれません。 他の場合では、新しいプロトコルは、より簡単な解決策であるかもしれません。
We have a number of reusable technologies, including component technologies specifically designed for re-use. Examples include SASL, BEEP and APEX. TCP and UDP can also be viewed as reusable transport protocols, used by a range of applications. On the other hand, re-use should not go so far as to turn a protocol into a Trojan Horse, as has happened with HTTP [RFC3205].
私たちには、再使用のために明確に設計されたコンポーネント技術を含む多くの再利用できる技術があります。 例はSASL、BEEP、およびAPEXを含んでいます。 また、さまざまなアプリケーションで使用される再利用できるトランスポート・プロトコルとしてTCPとUDPを見なすことができます。 他方では、再使用はプロトコルをトロイの木馬に変えさえするべきではありません、HTTP[RFC3205]で起こったように。
13.3. Discussion: complexity, robustness, and fragility
13.3. 議論: 複雑さ、丈夫さ、およびもろさ
[WD02] gives a historical account of the evolution of the Internet as a complex system, with particular attention to the tradeoffs between complexity, robustness, and fragility. [WD02] describes the robustness that follows from the simplicity of a connectionless, layered, datagram infrastructure and a universal logical addressing scheme, and, as case studies, describes the increasing complexity of TCP and of BGP. The paper describes a complexity/robustness spiral of an initially robust design and the appearance of fragilities, followed by modifications for more robustness that themselves introduce new fragilities. [WD02] conjectures that "the Internet is only now beginning to experience an acceleration of this complexity/robustness spiral and, if left unattended, can be fully expected to experience arcane, irreconcilable, and far-reaching robustness problems in the not-too-distant future." Citing [WD02], [BFM02] focuses on the ways that complexity increases capital and operational expenditures in carrier IP network, and views complexity as the primary mechanism that impedes efficient scaling.
[WD02]は見返りに関する特別の注意と共に複合システムとして複雑さと、丈夫さと、もろさの間にインターネットの発展の歴史的説明をします。 [WD02]は、コネクションレスで、層にされたデータグラムインフラストラクチャと普遍的な論理的なアドレシング計画の簡単さから続く丈夫さについて説明して、TCPとBGPの増加する複雑さをケーススタディと説明します。 論文は初めは強健なデザインの複雑さ/丈夫さらせんと、より多くの丈夫さのための自分たちで新しいもろさを導入する変更があとに続いたもろさの外観について説明します。 [WD02]は、「インターネットを、現在、この複雑さ/丈夫さらせんの加速を経験するだけであり始めてい、無人で残されるなら、近い将来に秘密の、そして、和解できなくて、遠大な丈夫さ問題を経験すると完全に予想できます。」と推測します。 [WD02]を引用して、[BFM02]は、複雑さがキャリヤーIPネットワークで首都と操作上の費用を上げる方法に焦点を合わせて、効率的なスケーリングを妨害する一次機構であると複雑さをみなします。
Floyd Informational [Page 15] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[15ページ]のRFC3426建築するのと方針問題2002年11月
14. Internationalization
14. 国際化
Where protocols require elements in text format, have the possibly conflicting requirements of global comprehensibility and the ability to represent local text content been properly weighed against each other?
プロトコルがテキスト形式で要素を必要とするところでは、グローバルな分かり易さのことによると闘争している要件とローカルのテキスト内容を表す能力は適切に互いに比較考量されましたか?
14.1. Discussion: internationalization
14.1. 議論: 国際化
RFC 1958 [RFC1958] included a simple statement of the need for a common language:
RFC1958[RFC1958]は共通語の必要性の単純文を含んでいました:
"Public (i.e. widely visible) names should be in case-independent ASCII. Specifically, this refers to DNS names, and to protocol elements that are transmitted in text format."
「ケースから独立しているASCIIには公共(すなわち、広く目に見える)の名前がそうあるべきです。」 「明確に、これはDNS名、およびテキスト形式で伝えられるプロトコル要素を参照します。」
The IETF has studied character set issues in general [RFC 2130] and made specific recommendations for the use of a standardized approach [RFC 2277]. The situation is complicated by the fact that some uses of text are hidden entirely in protocol elements and need only be read by machines, while other uses are intended entirely for human consumption. Many uses lie between these two extremes, which leads to conflicting implementation requirements.
IETFは一般に、文字の組問題[RFC2130]を研究して、標準化されたアプローチの使用のための特定の推薦状を[RFC2277]にしました。 テキストのいくつかの用途が完全にプロトコル要素に隠されて、マシンによって読まれるだけでよいという事実によって状況は複雑にされます、他の用途が完全に人間の消費で意図しますが。 これらの2つの極端の間には、多くの用途があって、闘争することへのどの先導が実現要件であるか。
For the specific case of DNS, the Internationalized Domain Name working group is considering these issues. As stated in the charter of that working group, "A fundamental requirement in this work is to not disturb the current use and operation of the domain name system, and for the DNS to continue to allow any system anywhere to resolve any domain name." This leads to some very strong requirements for backwards compatibility with the existing ASCII-only DNS. Yet since the DNS has come to be used as if it was a directory service, domain names are also expected to be presented to users in local character sets.
DNSの特定のケースのために、Internationalized Domain Nameワーキンググループはこれらの問題を考えています。 そのワーキンググループの特許で述べられているように「この仕事における基本的な要件は、ドメイン名システムの現在の使用と操作を擾乱しないで、DNSが、どこでもどんなシステムもどんなドメイン名も決議するのをずっと許容することです」。 これは後方にように既存のASCIIだけDNSとの互換性をいくつかの非常に強い要件に導きます。 DNSがまるでそれが電話番号案内であるかのようにしかし、使用されるようになったので、また、ドメイン名によってローカルキャラクターセットでユーザに提示されると予想されます。
This document does not attempt to resolve these complex and difficult issues, but simply states this as an issue to be addressed in our work. The requirement that names encoded in a text format within protocol elements be universally decodable (i.e. encoded in a globally standard format with no intrinsic ambiguity) does not seem likely to change. However, at some point, it is possible that this format will no longer be case-independent ASCII.
このドキュメントは、これらの複雑で難しい問題を解決するのを試みませんが、私たちの仕事で記述されるために問題として単にこれを述べます。 プロトコル要素の中のテキスト形式でコード化された名前が一般に解読可能であるという(すなわち、本質的なあいまいさなしでグローバルに標準の形式でコード化されます)要件は変化しそうにはありません。 しかしながら、何らかのポイントでは、この形式がもうケースから独立しているASCIIにならないのは、可能です。
Floyd Informational [Page 16] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[16ページ]のRFC3426建築するのと方針問題2002年11月
15. Deployability
15. Deployability
Question: Is the protocol deployable?
以下に質問してください。 プロトコルは配備可能ですか?
15.1. Discussion: deployability
15.1. 議論: deployability
It has been suggested that the failure to understand deployability considerations in the current environment is one of the major weakness of the IETF. As examples of deployment difficulties, RFC 2990 [RFC2990] discusses deployment difficulties with Quality of Service (QoS) architectures, various documents of the MBONE Deployment Working Group address deployment problems with IP Multicast, and the IPv6 Working Group discusses a wealth of issues related to the deployment of IPv6. [CN02] discusses how the deployment of Integrated Services has been limited by factors such as the failure to take into account administrative boundaries. Additional papers on difficulties in the evolution of the Internet architecture are available from [Evolvability].
現在の環境におけるdeployability問題を理解しないことがIETFの主要な弱点の1つであると示唆されました。 展開困難に関する例として、RFC2990[RFC2990]はService(QoS)構造のQualityにおける展開困難について議論して、MBONE Deployment作業部会の様々なドキュメントはIP Multicastに関するその展開問題を訴えて、IPv6作業部会はIPv6の展開に関連する豊富な問題について議論します。 [CN02]はIntegrated Servicesの展開が管理境界を考慮に入れないことなどの要素によってどう制限されたかについて議論します。 困難のインターネット構造の発展における追加書類は[Evolvability]から利用可能です。
Issues that can complicate deployment include whether the protocol is compatible with pre-existing standards, and whether the protocol is compatible with the installed base. For example, a transport protocol is more likely to be deployable if it performs correctly and reasonably robustly in the presence of dropped, reordered, duplicated, delayed, and rerouted packets, as all of this can occur in the current Internet.
展開を複雑にすることができる問題はプロトコルが規格を先在させるのと互換性があるかどうかと、プロトコルはインストールされたベースと互換性があるかどうかを含んでいます。 例えば、低下して、再命令されて、コピーされて、遅らせられて、別ルートで送られたパケットがあるとき正しく合理的に強壮に働くなら、トランスポート・プロトコルは配備可能であるより傾向があります、このすべてが現在のインターネットに起こることができるとき。
16. Conclusions
16. 結論
This document suggests general architectural and policy questions to be addressed when working on new protocols and standards in the IETF.
このドキュメントは、IETFで新しいプロトコルと規格に取り組むとき、記述されるために建築するのと方針の一般的な質問を示します。
The case studies in this document have generally been short illustrations of how the questions proposed in the document have been addressed in working groups in the past. However, we have generally steered away from case studies of more controversial issues, where there is not yet a consensus in the IETF community. Thus, we side-stepped suggestions for adding a case study for IKE (Internet Key Exchange) as an possible example of a protocol with too much negotiation, or of adding a case study of network management protocols as illustrating the possible costs of leaving things to the marketplace to decide. We would encourage others to contribute case studies of these or any other issues that may shed light on some of the questions in this document; any such case studies could include a careful presentation of the architectural reasoning on both sides.
ケーススタディは本書では一般に過去にワーキンググループでどうドキュメントで提案された質問を記述してあるかに関する短いイラストです。 しかしながら、一般に、私たちはコンセンサスがIETF共同体にまだないより論議を呼んだ問題のケーススタディから遠くで操縦しました。 したがって、私たちは市場へのものが決めるのを残す可能なコストを例証するとしてIKE(インターネット・キー・エクスチェンジ)のためにあまりに多くの交渉があるプロトコル、またはネットワーク管理プロトコルのケーススタディを加える可能な例としてケーススタディを加えるための提案をかわしました。 私たちは、他のものが本書では質問のいくつかを解明するかもしれないこれらのケーススタディかいかなる他の問題も寄付するよう奨励するでしょう。 どんなそのようなケーススタディも両側における建築推理の慎重なプレゼンテーションを含むかもしれません。
Floyd Informational [Page 17] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[17ページ]のRFC3426建築するのと方針問題2002年11月
we would conjecture that there is a lot to be learned, in terms of the range of answers to the questions posed in this document, by studying the successes, failures, and other struggles of the past.
私たちは、学習されるためにいろいろな事があると推測するでしょう、本書では提出された質問の答えの範囲に関して、過去の成功、失敗、および他の戦いを研究することによって。
We would welcome feedback on this document for future revisions. Feedback could be send to the editor, Sally Floyd, at floyd@icir.org.
私たちは今後の改正のためのこのドキュメントのフィードバックを歓迎するでしょう。 フィードバックは floyd@icir.org でエディタ、サリー・フロイドに発信することであるかもしれません。
17. Acknowledgements
17. 承認
This document has borrowed text freely from other IETF RFCs, and has drawn on ideas from [ASSW02], [CWSB02], [M01] and elsewhere. This document has developed from discussions in the IAB, and has drawn from suggestions made at IAB Plenary sessions and on the ietf general discussion mailing list. The case study on SIP was contributed by James Kempf, an early case study on Stresses on DNS was contributed by Karen Sollins, and Keith Moore contributed suggestions that were incorporated in a number of places in the document. The discussions on Internationalization and on Overloading were based on an earlier document by Brian Carpenter and Rob Austein. We have also benefited from discussions with Noel Chiappa, Karen Sollins, John Wroclawski, and others, and from helpful feedback from members of the IESG. We specifically thank Senthilkumar Ayyasamy, John Loughney, Keith Moore, Eric Rosen, and Dean Willis and others for feedback on various stages of this document.
このドキュメントは、他のIETF RFCsからテキストを自由に借りて、[ASSW02]、[CWSB02][M01]からほかの場所に考えを利用しました。 このドキュメントは、IABで議論から発達して、IAB Plenaryセッションのときにされた提案と、そして、ietfの一般的な議論メーリングリストの上で作成されました。 SIPの上のケーススタディはジェームス・ケンフによって寄付されました、そして、DNSの上のStressesの上の早めのケーススタディはカレンSollinsによって寄付されました、そして、キース・ムーアはドキュメントの多くの場所で法人組織である提案を寄付しました。 InternationalizationとOverloadingについての議論はブライアンCarpenterとロブAusteinによる以前のドキュメントに基づきました。 また、私たちはクリスマスChiappa、カレンSollins、ジョンWroclawski、および他のものと、そして、IESGのメンバーからの役立っているフィードバックから議論の利益を得ました。 私たちはこのドキュメントの様々な台のフィードバックについて明確にSenthilkumar Ayyasamy、ジョンLoughney、キース・ムーア、エリック・ローゼン、ディーン・ウィリス、および他のものに感謝します。
18. Normative References
18. 引用規格
19. Informative References
19. 有益な参照
[A02] Harald Alvestrand, "Re: How many standards or
protocols...", email to the ietf discussion mailing
list, Message-id: <598204031.1018942481@localhost>,
April 16, 2002.
[A02]ハラルドAlvestrand、「Re:」 「いくつの規格かプロトコル」…, ietf議論メーリングリストへのメール、Message-イド: 2002年4月16日の<598204031.1018942481@localhost>。
[A02a] Loa Andersson, "The Role of MPLS in Current IP
Network", MPLS World News, September 16, 2002. URL
"http://www.mplsworld.com/archi_drafts/focus/analy-
andersson.htm".
2002年9月16日の[A02a]Loaアンデション、「IPがネットワークでつなぐ電流におけるMPLSの役割」MPLS世界のニュース。 URL「 http://www.mplsworld.com/archi_drafts/focus/analy- andersson.htm。」
[ASSW02] T. Anderson, S. Shenker, I. Stoica, and D. Wetherall,
"Design Guidelines for Robust Internet Protocols",
HotNets-I, October 2002.
2002年10月の[ASSW02]T.アンダーソンとS.Shenker、I.ストイカとD.Wetherall、「強健なインターネットプロトコルのためのデザインガイドライン」HotNets-I。
[BFM02] Randy Bush, Tim Griffin, and David Meyer, "Some
Internet Architectural Guidelines and Philosophy",
Work in Progress.
[BFM02]のランディ・ブッシュ、ティムGriffin、およびデヴィッド・マイヤーと、「何らかのインターネットの建築ガイドラインと哲学」は進行中で働いています。
Floyd Informational [Page 18] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[18ページ]のRFC3426建築するのと方針問題2002年11月
[B02] Hamid Ould-Brahim, Bryan Gleeson, Peter Ashwood-Smith,
Eric C. Rosen, Yakov Rekhter, Luyuan Fang, Jeremy De
Clercq, Riad Hartani, and Tissa Senevirathne, "Using
BGP as an Auto-Discovery Mechanism for Network-based
VPNs", Work in Progress.
「ネットワークベースのVPNsに自動発見メカニズムとしてBGPを使用し」て、[B02]ハミドオールド-Brahim、ブライアン・グリーソン、ピーター・Ashwood-スミス、エリック・C.ローゼン、ヤコフRekhter、Luyuan牙、ジェレミーDe Clercq、Riad Hartani、およびTissa Senevirathneは進行中で動きます。
[CDT01] Policy Concerns Raised by Proposed OPES Working Group
Efforts, email to the IESG, from the Center for
Democracy & Technology, August 3, 2001. URL
"http://www.imc.org/ietf-openproxy/mail-
archive/msg00828.html".
2001年8月3日の民主主義とTechnologyのためのセンターからのProposed作品作業部会Efforts、IESGへのメールによる[CDT01]方針Concerns Raised。 URL「 http://www.imc.org/ietf-openproxy/mail- アーカイブ/msg00828.html。」
[Clark88] David D. Clark, The Design Philosophy of the DARPA
Internet Protocols, SIGCOMM 1988.
[Clark88]デヴィッド・D.クラーク、DARPAインターネットプロトコル、SIGCOMM1988の設計理念。
[CN02] Brian Carpenter, Kathleen Nichols, "Differentiated
Services in the Internet", Technical Report, February
2002, URL "http://www.research.ibm.com/resources/
paper_search.shtml".
[CN02] ブライアンCarpenter、キャサリーン・ニコルズ、「インターネットでの微分されたサービス」、Technical Report、2002年2月、「 http://www.research.ibm.com/resources/ 紙_search.shtml」というURL。
[CWSB02] Clark, D., Wroslawski, J., Sollins, K., and Braden,
R., "Tussle in Cyberspace: Defining Tomorrow's
Internet", SIGCOMM 2002. URL
"http://www.acm.org/sigcomm/sigcomm2002/papers/
tussle.html".
[CWSB02]クラークとD.とWroslawskiとJ.とSollins、K.とブレーデン、R.、「サイバースペースでは、乱闘してください」 「明日のインターネットを定義します」、SIGCOMM2002。 URL「 http://www.acm.org/sigcomm/sigcomm2002/papers/ tussle.html。」
[Evolvability] Floyd, S., "Papers on the Evolvability of the Internet
Infrastructure". Web Page, URL
"http://www.icir.org/floyd/evolution.html".
[Evolvability] フロイド、S.、「インターネットインフラストラクチャのEvolvabilityの上の書類。」 ウェブページ、URL" http://www.icir.org/floyd/evolution.html "。
[H68] Garrett Hardin, "The Tragedy of the Commons", Science,
V. 162, 1968, pp. 1243-1248. URL
"http://dieoff.org/page95.htm".
[H68]ギャレット・ハーディン、「下院の悲劇」、Science、V.162、1968、ページ 1243-1248. URL" http://dieoff.org/page95.htm "。
[K02] John C. Klensin, "Role of the Domain Name System",
Work in Progress.
「ドメインネームシステムの役割」という[K02]ジョンC.Klensinは進行中で働いています。
[Layering] Floyd, S., "References on Layering and the Internet
Architecture", Web Page, URL
"http://www.icir.org/floyd/layers.html".
[層にします] フロイド、S.、ウェブページ、URL" http://www.icir.org/floyd/layers.html "という「レイヤリングとインターネット構造に関する参照。」
[Multiplexing] S. Floyd, "Multiplexing, TCP, and UDP: Pointers to the
Discussion", Web Page, URL
"http://www.icir.org/floyd/tcp_mux.html".
[マルチプレクシング]S.フロイド、「マルチプレクシング、TCP、およびUDP:」 「議論へのポインタ」、ウェブページ、" http://www.icir.org/floyd/tcp_mux.html "というURL。
Floyd Informational [Page 19] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[19ページ]のRFC3426建築するのと方針問題2002年11月
[MBMWOR02] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J.
and B. Rosen, "Change Process for the Session
Initiation Protocol (SIP)", BCP 67, RFC 3427, November
2002.
[MBMWOR02] マンキン、A.、ブラドナー、S.、マーイ、R.、ウィリス、D.、オット、J.、およびB.ローゼンは「セッション開始プロトコル(一口)のために過程を変えます」、BCP67、RFC3427、2002年11月。
[M01] Tim Moors, A Critical Review of End-to-end Arguments
in System Design, 2001. URL
"http://uluru.poly.edu/~tmoors/".
[M01]ティムMoors、システム設計、2001年の終わりから終わりへの議論の批判的なレビュー。 URL" http://uluru.poly.edu/~tmoors/ "。
[P99] Radia Perlman, "Protocol Design Folklore", in
Interconnections Second Edition: Bridges, Routers,
Switches, and Internetworking Protocols, Addison-
Wesley, 1999.
[P99]Radiaパールマン、インタコネクト第2版の「プロトコルデザイン民俗学」: 橋とルータ、スイッチとインターネットワーキングプロトコル、アディソン・ウエスリー、1999
[RFC1958] Carpenter, B., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[RFC1958] 1996年6月の大工、B.、「インターネットの建築プリンシプルズ」RFC1958。
[RFC2211] Wroclawski, J., "Specification of the Controlled Load
Quality of Service", RFC 2211, September 1997.
[RFC2211] Wroclawski、J.、「制御負荷サービスの質の仕様」、RFC2211、1997年9月。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin,
"Specification of Guaranteed Quality of Service", RFC
2212, September 1997.
1997年9月の[RFC2212]ShenkerとS.とヤマウズラ、C.とR.ゲラン、「保証されたサービスの質の仕様」RFC2212。
[RFC2316] Bellovin, S., "Report of the IAB Security Architecture
Workshop", RFC 2316, April 1998.
[RFC2316] Bellovin、S.、「IABセキュリティー体系ワークショップのレポート」、RFC2316、1998年4月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z. and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2475] ブレークとS.と黒とD.とカールソンとM.とデイヴィースとE.とワングとZ.とW.ウィス、「微分されたサービスのための構造」、RFC2475、1998年12月。
[RFC2543] Handley, M., Schulzrinne, H., Schooler, B. and J.
Rosenberg, "SIP: Session Initiation Protocol", RFC
25434, March 1999.
[RFC2543] ハンドレー、M.、Schulzrinne、H.、学生、B.、およびJ.ローゼンバーグは「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC25434、1999年3月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597] HeinanenとJ.とベイカーとF.とウィスとW.とJ.Wroclawski、「相対的優先転送PHBは分類する」RFC2597、1999年6月。
[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture",
RFC 2990, November 2000.
[RFC2990] ヒューストン、G.、「IP QoS構造のための次のステップ」、RFC2990、2000年11月。
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion
Manager", RFC 3124, June 2001.
[RFC3124]BalakrishnanとH.とS.Seshan、「混雑マネージャ」(RFC3124)2001年6月。
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and
Z. Shelby, "Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations", RFC 3135, June
2001.
[RFC3135]は接しています、J.、Kojo、M.、Griner、モンテネグロ、G.、およびZ.シエルビイ、J.、「パフォーマンスはリンク関連の転落を緩和することを意図するプロキシを高め」て、RFC3135、2001年6月。
Floyd Informational [Page 20] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[20ページ]のRFC3426建築するのと方針問題2002年11月
[RFC3168] Ramakrishnan, K. K., Floyd, S. and D. Black, "The
Addition of Explicit Congestion Notification (ECN) to
IP", RFC 3168, September 2001.
[RFC3168]RamakrishnanとK.K.とフロイドとS.とD.黒、「明白な混雑通知(電子証券取引ネットワーク)のIPへの追加」、RFC3168、2001年9月。
[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP
56, RFC 3205, February 2002.
[RFC3205]ムーア、K. 「SubstrateとしてのHTTPの使用」のBCP56、RFC3205、2002年2月。
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the
Internet", RFC 3221, December 2001.
[RFC3221]ヒューストン、G.、「インターネットの相互ドメインルート設定の論評」、RFC3221、2001年12月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.
[RFC3234]大工、B.、およびS.があふれそうになる、「Middleboxes:」 「分類学と問題」、RFC3234、2月2002日
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC
3238, January 2002.
[RFC3238] フロイドとS.とL.Daigle、「開いているPluggable縁のサービスのためのIAB建築するのと方針問題」、RFC3238、2002年1月。
[RFC3246] Davie, B., Charny, A., Bennet, J. C. R., Benson, K.,
Le Boudec, J. Y., Courtney, W., Davari, S., Firoiu, V.
and D. Stiliadis, "An Expedited Forwarding PHB (Per-
Hop Behavior)", RFC 3246, March 2002.
[RFC3246] デイビー、B.、シャルニー、A.、アメリカダイコンソウ、J.C.R.、ベンソン、K.、Le Boudec、J.Y.、コートニー、W.、Davari、S.、Firoiu、V.、およびD.Stiliadis、「完全優先転送PHB、(-、ホップの振舞い)、」、RFC3246(2002年3月)
[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered
Harmful", BCP 60, RFC 3360, August 2002.
[RFC3360] フロイド、S.、「有害であると考えられた不適当なTCPリセット」、BCP60、RFC3360、2002年8月。
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System
(DDDS) Part Three: The Domain Name System (DNS)
Database", RFC 3403, October 2002.
[RFC3403]食事、M.、「ダイナミックな代表団発見システム(DDDS)は3を分けます」。 「ドメインネームシステム(DNS)データベース」、RFC3403、2002年10月。
[RFC3424] Daigle, L., "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF)", RFC 3424, November 2002.
[RFC3424] Daigle、L.、「一方的な自己アドレス修理(UNSAF)のためのIAB問題」、RFC3424、2002年11月。
[SCWA99] Stefan Savage, Neal Cardwell, David Wetherall, Tom
Anderson, "TCP Congestion Control with a Misbehaving
Receiver", ACM Computer Communications Review, October
1999.
[SCWA99]ステファン・サヴェージ、ニール・カードウェル、デヴィッドWetherall、トム・アンダーソン、ACMコンピュータコミュニケーションは「ふらちな事する受信機とのTCP輻輳制御」と見直します、1999年10月。
[SRC84] J. Saltzer, D. Reed, and D. D. Clark, "End-To-End
Arguments In System Design", ACM Transactions on
Computer Systems, V.2, N.4, p. 277-88. 1984.
[SRC84] J.Saltzer、D.リード、およびD.D.クラーク、「システム設計における終わりから終わりへの議論」、コンピュータシステムズ、V.2、N.4(p)の上のACM Transactions。 277-88. 1984.
[T89] D. Tennenhouse, "Layered Multiplexing Considered
Harmful", Protocols for High-Speed Networks, 1989.
[T89]D.Tennenhouse、「有害であると考えられた層にされたマルチプレクシング」、高速ネットワーク、1989年のプロトコル。
[WD02] Walter Willinger and John Doyle, "Robustness and the
Internet: Design and Evolution", draft, March 2002,
URL "http://netlab.caltech.edu/internet/".
[WD02] ウォルター・ウィリンジャーとジョン・ドイル、「丈夫さとインターネット:」 「デザインとEvolution」は2002年3月に" http://netlab.caltech.edu/internet/ "というURLを作成します。
Floyd Informational [Page 21] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[21ページ]のRFC3426建築するのと方針問題2002年11月
20. Security Considerations
20. セキュリティ問題
This document does not propose any new protocols, and therefore does not involve any security considerations in that sense. However, throughout this document there are discussions of the privacy and integrity issues and the architectural requirements created by those issues.
このドキュメントは、どんな新しいプロトコルも提案しないで、またしたがって、その意味で、どんなセキュリティ問題にもかかわりません。 しかしながら、このドキュメント中に、それらの問題によって作成されたプライバシー、保全問題、および建築要件の議論があります。
21. IANA Considerations
21. IANA問題
There are no IANA considerations regarding this document.
このドキュメントに関するIANA問題が全くありません。
Authors' Addresses
作者のアドレス
Internet Architecture Board EMail: iab@iab.org
インターネット・アーキテクチャ委員会メール: iab@iab.org
IAB Membership at time this document was completed:
このドキュメントが完成した時のIAB Membership:
Harald Alvestrand Ran Atkinson Rob Austein Fred Baker Leslie Daigle Steve Deering Sally Floyd Ted Hardie Geoff Huston Charlie Kaufman James Kempf Eric Rescorla Mike St. Johns
ハラルドAlvestrandはアトキンソンロブAusteinフレッドベイカーレスリーDaigleスティーブデアリングSallyフロイドテッドハーディージェフヒューストンチャーリー・カウフマンジェームスケンフエリックレスコラマイク通りジョーンズを車で送りました。
Floyd Informational [Page 22] RFC 3426 Architectural and Policy Considerations November 2002
フロイド情報[22ページ]のRFC3426建築するのと方針問題2002年11月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 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機能のための基金は現在、インターネット協会によって提供されます。
Floyd Informational [Page 23]
フロイドInformationalです。[23ページ]
一覧
スポンサーリンク
