Network Working Group S. Floyd, Editor
Request for Comments: 3426 Internet Architecture Board
Category: Informational November 2002
General Architectural and Policy Considerations
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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コミュニティは新しい規格やプロトコルに作業しているときに対処しなければならないことを、一般的な建築と政策の質問を示唆しています。私たちは、この文書が従うべきガイドラインや建築の原則とは反対に、対処すべき問題が含まれていることに注意してください。
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.
この文書は、全体的なインターネットアーキテクチャにおける一貫性の成長の欠如について懸念によって部分的に動機づけられています。私たちは、広く普及し、異機種環境に対処するために複雑な、複雑な建築の世界に、少人数のグループによって設計された単一、コヒーレント建築の世界から移動してきました。アーキテクチャの個々の部分は、多くの場合、サブコミュニティによって設計されているので、各サブコミュニティは利益の独自のセットを持って、それぞれの作品は、より大きな絵にどのように適合するかにますます注目を払うこと、及び各部分がどのように考慮する必要があります選ばれました。例えば、私たちのそれぞれが、プロトコルスタックのレイヤで問題を解決するために傾斜し、我々は最高のを理解するツールを使用していることは避けられません。それは必ずしも、これは長期的にこの問題を解決するためのツールの最も適切な層またはセットであることを意味するものではありません。
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メンバーによって対処すべき課題で。このドキュメントは、プロトコルおよびアーキテクチャを設計する方法についてのプライマーではなく、何の答えを提供していません。
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."
RFC 1958 [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."
これとは対照的に、本文書に対処するために追加のアーキテクチャ上の質問を示唆することによって、わずかに異なる目的を果たします。したがって、本文書で提案一つの質問は以下の通りです：「もしあれば、この提案は問題に対する最善の長期的な解決策でない場合は、このソリューションの長期的なコストは、将来の発展の制限の面で、何ですか？ ？」次のようにこの質問は、ほぼ同等の建築ガイドラインに変換することができる：「提案されたプロトコルは、長期的な解決策、または短期的な解決策であるかどうかを識別し、そして任意の短期のための長期的なコストと出口戦略を特定しますソリューションを提供します。」
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のに対して堅牢であることを確認してください」の線に沿って明確なアーキテクチャのガイドラインはまだありません
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.
このセクションでは、プロトコルを設計する際に依頼するいくつかの質問をリストアップ。各質問には、この論文の残りの部分でより多くの深さを議論しています。我々は、すべてのプロトコル設計の努力が明示的にこれらの質問のすべてに答えるために必要とされなければならないことを示唆していません。いくつかの質問には、別のよりも一つの文書により適切になります。また、これは、アーキテクチャの問題の完全なリストであることを示唆していません。
DESIGN QUESTIONS:
DESIGN質問：
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?
*これは、適切な機能の正しさの点ではレイヤ、データの整合性、パフォーマンス、導入のしやすさ、故障の診断性、およびその他の問題ですか？
* 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ワーキンググループによって、または他の標準化団体によって提供されている必要があります全体的なソリューションの一部はありますか？
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?
*だけではなく、ノードの障害が発生するだけでなく、などの妥協や誤動作コンポーネント、不完全なまたは欠陥の実装へのプロトコルは、どのように堅牢なのですか？
* 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?
発展性の保持？
* Does the protocol protect the interests of the future, by preserving the evolvability of the Internet? Does the protocol enable future developments?
*プロトコルは、インターネットの発展性を維持することによって、将来の利益を保護していますか？プロトコルは、今後の展開を可能にしていますか？
* 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?
*インターネットアーキテクチャに新しい複雑さを紹介するプロトコルの場合、どのようにプロトコルは、堅牢性を追加し、発展性を維持し、どのようにそれはまた、システムに新しいもろさを導入しないのでしょうか？
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?
プロトコルは、テキスト形式の要素を必要とする場合*、世界的なわかりやすさと適切に相互比較して検討されてローカルのテキストコンテンツを表現する能力の可能性の相反する要件がありますか？
DEPLOYMENT QUESTIONS:
デプロイメント質問：
* Is the protocol deployable?
*プロトコル展開可能ですか？
Each of these questions is discussed in more depth in the rest of this paper.
これらの質問のそれぞれは、この論文の残りの部分で詳しく説明されています。
Question: Why are you proposing this solution, instead of proposing something else, or instead of using existing protocols and procedures?
質問：なぜ、あなたはこのソリューションを提案しているのではなく、何かを提案する、またはその代わりに、既存のプロトコルと手順を使用していますか？
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.
統合されたと差別化されたサービスを開発する作業の良い部分は、解決すべき問題を理解するために、溶液のアーキテクチャフレームワークであり、特定のサービスの性質に合意に達することでした。したがって、統合サービスが開発されていた場合、制御負荷の仕様[RFC2211]保証[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.
「微分されたサービスのためのアーキテクチャ」のRFC 2475が統合されたサービスのために事前に定義されたアーキテクチャとは異なり、スケーラブルなサービスの差別化アーキテクチャを提案したときに、後で、ドキュメントも明確にこの新しいアーキテクチャのための要件を正当化しなければならなかった、と提案を比較します他の可能なアプローチ[RFC2475]のアーキテクチャ。保証転送[RFC2597]と差別化サービスの挙動ホップ当たり速め転送[RFC3246]が提案された場合も同様に、各サービスは、インターネットにそのサービスの必要性を正当化を必要としました。
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?
これは、関数、データの整合性、パフォーマンス、導入のしやすさ、故障の診断性、およびその他の問題の正しさの面で適切な層ですか？
What are the interactions between layers, if any?
もしあれば、層の間の相互作用は何ですか？
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]と比較した場合、システムの低レベルに配置された機能は、冗長または少ない値であってもよい」ことを示唆していることにより、モジュール間の機能を配置する場所についての議論を始めますその低レベルでそれらを提供するコストと紙で議論としては、例えば、ビット誤り回復、セキュリティ使用して暗号化、重複メッセージの抑制、システムクラッシュからの回復、及び送達確認が含まれる。これらの機能をサポートするための低レベルのメカニズムを性能としてのみ正当化されます機能強化。」エンド・ツー・エンド原理は、機能のための適切な層を選択する際に考慮すべき重要なアーキテクチャの指針の一つです。
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].
エンドポイントの輻輳管理における輻輳管理の目標は、輻輳制御状態[RFC3124]を共有するために同じ送信元と宛先アドレスを持つ複数の同時フローを可能にすることです。多重化のための提案の歴史は、プロトコルスタックの異なるレベルで流れがありました。提案は、HTTP（WebMux）とTCP（TCP制御ブロック）層において、ならびにTCP（輻輳マネージャ）[多重化]以下多重化を追加することが含まれています。
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]ことを示唆しています。したがって、流れる多重化するためのメカニズムを提供する上で重要な課題の一つは、この機能を提供するために最も適切である層またはプロトコルスタックの層を決定することです。各研究者の自然な傾向は、彼らが最もよく知っている層で機能を追加することが一般的です。これは必ずしも最も適切なアーキテクチャ全体にはなりません。
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]の上にアプリケーションを階層化にかなりの関心が寄せられています。引用された理由は、広く展開されブラウザとの互換性、クライアントとサーバーのライブラリを再利用する能力、既存のセキュリティ・メカニズムを使用する能力、およびファイアウォールを通過する能力を含みます。 RFC 3205で説明しているように、「HTTP経由で新しいプロトコルを重ねるの最近の関心は、そのような使用が適切である質問の数、およびそれが適切であるところの状況でHTTPを使用するための適切な方法を調達しています。」このように、RFC 3205のアドレスだけでなく、HTTPの上に重ねるアプリケーションのメリットだけでなく、専用のプロトコルを導入するコストと比較して、HTTPの上にアプリケーションを積層する追加の複雑さとオーバーヘッドを評価します。
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].
「階層化とインターネットアーキテクチャ上の参照」上のWebページは、インターネットアーキテクチャ[階層化]で、一般的なレイヤリングの問題を議論する追加の書類へのポインタを持っています。
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?
そうでない場合はいずれかの場合、このソリューションの長期的なコストは、将来の発展の制限の面で、何ですか？より長期的なソリューションの開発のための要件は何ですか？
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中間装置の問題に対処するために、様々な提案は、それが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は、特定の問題、そして慎重にそのような提案を標準化する前に評価されるべき特定の問題のために、これらの提案はせいぜい、考えることができる理由、短期的な修正を概説しました。これらの問題は、固定される制限されたスコープの問題の識別、短期的な解決策のための出口戦略の説明、及び短期的な解決策によって未解決左長期的な問題の記述を含みます。
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ワーキンググループによって、または他の標準化団体によって提供されている必要があります全体的なソリューションの一部はありますか？
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.
セッション開始プロトコル（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.
マルチメディアセッションをセットアップする作業はまた、所望のマルチメディアセッションの記述が必要です。これは、セッション記述プロトコル（SDP）によって提供されます。 SDPは、マルチパーティマルチメディアセッション制御（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ワーキンググループは、異なるタスクに適用され、SIMPLEワーキンググループは、インスタントメッセージングとプレゼンスにSIPの適用を検討している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ワーキンググループを提供する上で非常に活躍されています。分散型コールシグナリング（DCS）グループPacketCableのコンソーシアム、3GPP、および3GPP2からのすべての様々なテレフォニー関連のアプリケーションのためのSIPを使用しており、これらのグループのメンバーは、SIPの要件を起草に携わってきました。また、これらの標準化団体で検討されているSIPの拡張があります。手順は、予備的なプライベート、または独自の拡張機能のカテゴリを含むSIPへの提案の拡張を、対処するための、およびSIP名前空間[MBMWOR02]の安全管理のために提供するために、IETFで開発が進められています。
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?
質問：もしあればどのように提案された新しいプロトコルのアーキテクチャの利点は、建築コストと比較しますか？建築費は慎重に検討されていますか？
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.
RFC 3135 [RFC3135]は、リンク関連の劣化に対処するために、ネットワークの途中でパフォーマンス強化プロキシ（のPEP）を置くの相対的な費用と便益を考慮しています。 PEPの場合には、潜在的なコスト含むIP層セキュリティメカニズムのエンドツーエンドの使用を無効にします。エンドシステムの制御下にない故障の新たな可能点を導入します。診断および障害に対処で増加した困難を加えます。非対称ルーティングまたはモバイルホストとの可能な合併症を導入します。 RFC 3135には、慎重にこれらの可能性、コスト、導入することができる緩和策、およびユーザーへのパフォーマンス強化プロキシの利益がコストを上回る可能性がある場合を考慮しています。
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.
インターネットでミドルボックスによって提起された問題の一つは、データのエンドツーエンドの整合性を必要とします。これは、オープン・プラガブル・エッジ・サービス（OPES）ワーキンググループをチャーターの最近の質問に例示されています。オープンプラグイン可能なエッジサービスは、オリジンサーバとクライアントの間のウェブプロキシキャッシュで、例えば、ネットワーク内のアプリケーション・レベルの仲介として展開されるだろうサービスです。これらの仲介者は、コンテンツプロバイダまたはエンドユーザーのいずれかの明示的な同意を得て、変換またはコンテンツをフィルタリングします。
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].
OPES作業部会をチャーターする過程で生じた建築の問題の一つは、データのエンドツーエンドの整合性を懸念しました。一例として、「OPESは、インターネット上での通信のため、整合性、および完全性の認識の両方を低減するであろう、そしてそれは、ネットワークを介して移動して有意にコンテンツに行われている可能性があるかについての不確実性を増加させる」ことが示唆された、とそのため、OPESのリスクがベネフィット[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.
この議論の一つの結果として、IABは、潜在的な建築のメリットとOPES [RFC3238]のコストの両方を考慮すると、「OPESのためのIAB建築と政策の考慮事項」の文書を書きました。この文書は、特定のソリューションをお勧めしたり、特定の機能要件を義務付けるが、その代わりに、このようなIETFで標準化OPESソリューションが対処する必要する必要があること、データの整合性についての懸念などの問題の勧告を含みませんでした。
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.)?
プロトコルは考慮されてい現在または将来のインターネットの現実的な条件（例えば、パケットのドロップとパケットの破損、パケットの並べ替え、非対称ルーティング、など）？
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]の最優先目標の一つとして引用されています。 【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フラッド」攻撃を防ぐことから、攻撃範囲に対してリソースを保護するための技術。
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.
インターネットは、エンドツーエンドの輻輳制御に基づいており、歴史的にインターネットは、パケットがエンドノードに輻輳を示すためにルータのための唯一の方法として低下使用してきました。 ECN [RFC3168]は、ルータの代わりにパケットを滴下する、輻輳のエンドノードに知らせるために、IPパケットヘッダ内のビットを設定することを可能にするIPアーキテクチャに最近追加されました。
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.
ECN [RFC3168]の第一、実験の仕様は、このようにエンドノードに到達する輻輳の兆候を防止、IPヘッダ内のECNフィールドから情報を「消去」不正または壊れたルータの危険性の広範な議論を含んでいました。堅牢性を追加するには、標準トラック仕様[RFC3168]はECN「ナンス」のために使用する、IPヘッダーのECNフィールドに、追加のコードポイントを指定しました。 ECNのナンスの開発はTCP [SCWA99]内の特定の堅牢性の問題に関する以前の研究によって動機づけられました。 RFC 3168「は、コードポイントの加算は、データ送信側のためのメカニズムは、そのネットワーク要素がCEコードポイントを消去されず、そのデータ受信が正常に送信者に持つパケットの受信を報告されていることを確認することを可能にする欲求によって主に動機付けされていることを説明してCEコードポイントセットは、トランスポートプロトコルによって必要とされます。」 ECNナンスの支持機構がECNベース輻輳表示の送達の堅牢性を保証するために、トランスポート・プロトコルで必要とされます。
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].
対照的に、ECNのためのより困難の少ない明確な堅牢性の問題はTCP SYNパケットにTCPヘッダのECNフラグ[RFC3360]に基づいて、中間装置によって、ネットワーク内のパケットの差動治療に関する。 TCPヘッダに設定ECNフラグの問題の懸念「ECN-セットアップ」SYNパケット、すなわち、SYNパケットは、2つのTCPエンドホスト間のECNの使用を交渉します。 TCPヘッダーのゼロECNフラグという「ECN-セットアップ」SYNパケット、TCPリセットメッセージを送信する他の人と、まだ他の人をドロップし、ネットワーク内のファイアウォールが存在します。これのどれもECNのデザイナーによって予期しなかった、とRFC 3168には、「ECN-セットアップ」SYNパケットをドロップするファイアウォールの存在下でのTCPの堅牢な動作を可能にするために、オプションの仕組みを追加しました。しかし、ECNはまだTCPヘッダにECNフラグをゼロミドルボックスのすべての可能なシナリオに堅牢ではありません。これまで、トランスポートプロトコルは、これらのプロトコルの使用を制御するミドルボックスによって使用されるメカニズムとは独立して標準化されており、中のトランスポートヘッダの不正な変更の存在下でトランスポートプロトコルから必要とされる堅牢性のどの程度、まだ明確ではありませんネットワーク。これらおよび類似の問題は[RFC3360]で詳しく説明されています。
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?
質問：誰もが新しいプロトコルを使用している場合、パフォーマンスはまだ堅牢ですか？考慮する必要がある広範な展開の他の潜在的な影響はありますか？
[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 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].
フローが高い輻輳時にエンドツーエンドの輻輳制御を使用していない場合は[RFC2914]は、輻輳崩壊の可能性を論じています。新しいトランスポートプロトコルは、エンドツーエンドの輻輳制御を使用していないことが提案された場合、新しいトランスポートプロトコルを使用して、個々のフローが競合するフローのすべてのように長いとして非常によく実行することを示すのは容易であるかもしれませんネットワークは、エンドツーエンドの輻輳制御を使用していました。完全に新しいトランスポートプロトコルを評価するために、多くのフローはすべてが新しいトランスポートプロトコルを使用して、競合しているときのパフォーマンスを見てする必要があります。競合するフローのすべてが高い混雑時にはより積極的なトランスポートプロトコルを使用していた場合、その結果は、下流ドロップされるパケットを運ぶ忙しいリンクで、高い定常状態のパケットドロップ率と減少し、全体的なスループットである可能性があります。これは、誰も[H68で行うとき（一般的な放牧牧草地に少数のより多くの羊を追加するなど、）一人だけで行われていれば生産的であるの練習ではなく、非生産的であるとき、コモンズの悲劇の形と見ることができます]。
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は、ルーターベンダー、ソフトウェアベンダー、またはその他の当事者）？
[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は、長い間、それが唯一のプロトコルを設計することができ、位置をとっている、と市場が彼ら[A02]の間で決定する左とその多くの場合、2つの競合するアプローチは、開発されます。 （また、「市場」は、常に最良の意思決定を行い、かつ技術的に最適なソリューションを特定し、採用する作業は、時には役に立つことをしない自分自身に完全に残っていること。このように、市場の役割を無視してはならない一方で示唆されています、市場の決定はまた、神聖なまたは絶対確実として保持されるべきではありません。）
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ヘッダ内のコードポイントを使用するという決定です。これは、プロトコルとポート番号の技術的な問題からの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 action would not be protecting the interests of open competition. Underspecified protocols can also serve as an unnecessary barrier to open competition.
これらのプロトコルの他の実装に障壁を高め、IETFプロトコルに不必要な複雑さを加える個人の年間の認知の問題がありました。明らかに、このような行動は、自由競争の利益を保護することはないだろう。指定不足のプロトコルはまた、競争を開くには、不要なバリアとして機能することができます。
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?
プロトコルは、適切な場合には別のプレイヤーが自分の好みを表現できるようにするために、選択のために設計されていますか？他の極端では、プロトコルは、相互運用性を脅かすまたはその他の重大な問題を引き起こすことに非常に多くの選択肢を提供していますか？
[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.
選択の例として、[CWSB02]「メールシステムの設計には、ユーザーが自分のSMTPサーバと彼のPOPサーバーを選択することができます」。選択肢の懸念プロバイダのレベルでパスを選択するか、ユーザーがそのようなWebキャッシュなどのサードパーティ製の仲介を選択できるようにするユーザーを可能にするメカニズムの設計、またはOpenプラグイン可能なエッジサービスのプロバイダ（詳細については、オープンエンドの質問OPES）。 [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]は、過剰な選択は、プロトコルの二つの独立した、準拠実装間の相互運用性を確保することが困難になることを指摘しています。
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.
過度なオプションの危険性もSIP（セッション開始プロトコル）の変更や拡張のための提案の「連続洪水」への対応のための指針を与える、[MBMWOR02]で議論されています。具体的には、SIP作業部会は、提案された拡張は、一般的な使用を持っている、とシンプルさや堅牢性を犠牲にして効率を提供しないことを懸念しています。 【MBMWOR02] IETFにおいて開発された他の高度に拡張可能なプロトコルはまた、拡張機能のより協調恩恵を受けるかもしれないことを示唆しています。
Does the protocol protect the interests of the future, by preserving the evolvability of the Internet? Does the protocol enable future developments?
プロトコルは、インターネットの発展性を維持することによって、将来の利益を保護していますか？プロトコルは、今後の展開を可能にしていますか？
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?
インターネットアーキテクチャに新しい複雑さを紹介するプロトコルの場合、プロトコルは、堅牢性を追加し、発展性を維持するのですか？それはまた、システムに不要な新しいもろさを紹介していますか？
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.
広範な文献やインターネットインフラストラクチャの継続的な発展性についての議論、あるいは発展性の欠如が、あります。 「インターネットインフラの発展性の論文」上のWebページには、この文献[発展性]の一部へのポインタを持っています。問題は、DNSの発展性とオーバーロードから及びます。マルチキャスト、QoSの、またはIPv6を組み込むために進化する中、インターネットの難しさ。変更の要求を満たすとインターネットの拡大にルーティングすることの難しさ。そして、発展性を制限するファイアウォールやその他のミドルボックスの役割。
[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]発展性の問題、のすべての中で、「新しいアプリケーションのためのオープンで透明性のネットを維持する最も重要な目標である。」ことを示唆しています初めに、インフラの相対的透明度は、他に「透明」ネットワーク進化可能性、一端ノードから単にルートパケットを確実にするのに十分でした。 [RFC3234]でカタログとしてしかし、この透明度は、ミドルボックスは、既存のプロトコルと相互作用して、障害を診断するのに困難を増やす方法について説明され、時間の経過とともにより暗いとなっています。 【CWSB02】現実的に次のガイドラインを提案している：「透明性の障害が発生する - は、何が起こるかをデザイン」透明性の障害の例は、ファイアウォール、アプリケーションフィルタリング、接続リダイレクション、キャッシュ、DNSにクラッジ、等を含む場合。このように、発展性を維持することも、インフラストラクチャ自体の透明性の欠如の顔に進化を可能にするための仕組みが必要となります。
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 mechanisms that make unwarranted assumptions about the network can end up placing unreasonable constraints on the future evolution of the network.
新しいメカニズムとプロトコルの設計者は、ネットワークの残りの部分について行われている仮定についてできるだけ明確にするために発展性を維持するための方法の一つです。ネットワークについて不当な仮定を行う新しいメカニズムは、ネットワークの今後の進化に不当な制約を置いてしまうことができます。
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.
運用の複雑さを結果で、新しい機能を持ついくつかのデザインをオーバーロードする最後の数年間で強い傾向がありました。拡張可能なプロトコルは発展性を提供するためのツールの一つとして見ることができます。プロトコルとシステムは、その合理的な設計パラメータを超えて伸びている場合は、その後、スケーリング、信頼性、またはセキュリティ上の問題を導入することができます。いずれかと見られているプロトコルの例としては、生産拡張、又は危険な過負荷、またはその両方は、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]で起こったように、トロイの木馬にプロトコルを有効にすると、これまで行ってはなりません。
[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]は、インターネットは今だけ、この複雑/堅牢性スパイラルの加速を体験し始めていると、放置すれば、完全ではない-too-で、難解相容れない、と遠大な堅牢性の問題が発生することが予想される」ことを推測します遠い将来。" [WD02]を引用し、[BFM02】複雑さは、キャリアIPネットワークにおける資本及び運用コストを増加させ、効率的なスケーリングを妨げる主要な機構として複雑さを見ていることの方法に焦点を当てています。
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?
プロトコルは、テキスト形式の要素を必要とする場合、グローバルなわかりやすさとローカルのテキストコンテンツを表現する能力の可能性の相反する要件が適切に互いに比較検討してきましたか？
RFC 1958 [RFC1958] included a simple statement of the need for a common language:
RFC 1958 [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は、一般的な[RFC 2130]の文字セットの問題を研究し、標準化されたアプローチ[RFC 2277]の使用のための具体的な提言を行っています。状況は、テキストの一部の使用は、プロトコル要素に完全に隠され、他の用途は、人間の消費のために完全に意図されている一方で、機械で読み取ることのみ必要とされているという事実によって複雑になります。多くの用途が競合実装要件につながる、これらの両極端の間にあります。
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の特定の場合には、国際化ドメイン名ワーキンググループは、これらの問題を検討しています。そのワーキンググループの憲章で述べたように、「この作品での基本的な要件は、ドメイン名システムの現在の使用や操作を妨げないことであり、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できなくなる可能性があります。
Question: Is the protocol deployable?
質問：プロトコル、展開はありますか？
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].
現在の環境で展開性の考慮事項を理解するために失敗はIETFの主要な弱点の一つであることが示唆されています。展開の難しさの例としては、RFC 2990 [RFC2990]は、サービスの品質と展開の難しさ（QoS）のアーキテクチャ、IPマルチキャストとMBONE展開ワーキンググループアドレス展開の問題の様々な文書を議論、およびIPv6ワーキンググループはに関連する問題の富を議論しますIPv6導入。 [CN02]は、統合サービスの展開は、口座管理境界に取るために、障害などの要因によって制限されてきた方法について説明します。インターネットアーキテクチャの進化の難しさについての追加の論文は[発展性]から入手できます。
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.
配備を複雑にする可能性のある問題は、プロトコルは、既存の規格と互換性があるかどうか、およびプロトコルがインストールされたベースと互換性があるかどうかが挙げられます。例えば、トランスポート・プロトコルは、このすべてが現在のインターネットで起こり得るように、それは、ドロップされた、並べ替え、複製、遅延の存在下で正確かつ合理的にロバスト行い、パケットを再ルーティング場合展開である可能性が高いです。
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（インターネット鍵交換）のためのケーススタディを追加するための提案を市場が決定します。私たちは、この文書に記載されているいくつかの質問に光を当てることがあり、これらやその他の問題のケーススタディに貢献するために他の人を励まします。このようなケーススタディは、両側の建築推論の慎重なプレゼンテーションを含めることができます。
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で、編集者、サリーフロイドに送信することができます。
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のRFCから自由にテキストを借りており、および[ASSW02]、[CWSB02]、[M01]と他の場所からのアイデアを集めています。このドキュメントは、IABでの議論から開発している、とIAB本会議でとIETF一般的な議論のメーリングリストで作られた提案から引き出されています。 SIPのケーススタディは、ジェームズ・ケンプ、DNS上の応力に及ぼす初期のケーススタディによって寄贈されましたが、カレンSollinsによって寄贈されました、そしてキース・ムーアは、ドキュメント内の多くの場所に組み込まれた提案を貢献しました。オーバーロード国際化との議論は、ブライアン・カーペンターとロブAusteinとすることにより、以前の文書に基づいていました。また、クリスマスChiappa、カレンSollins、ジョンWroclawski、その他、との議論からとIESGのメンバーから有益なフィードバックの恩恵を受けています。私たちは、特にこの文書の様々な段階でのフィードバックのためSenthilkumar Ayyasamy、ジョンLoughney、キースムーア、エリック・ローゼン、およびディーンウィリスと他人に感謝します。
[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、 "再：どのように多くの規格やプロトコル..."、IETF議論メーリングリストへの電子メール、メッセージID：<598204031.1018942481@localhost>、2002年4月16日。
[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".
[A02a]ロア・アンダーソン、 "現在のIPネットワークでのMPLSの役割"、MPLS世界のニュース、9月16日、2002年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.
[ASSW02] T.アンダーソン、S. Shenker、I.ストイカ、およびD. Wetherall、 "堅牢なインターネットプロトコルのための設計ガイドライン"、HotNets-I、2002年10月。
[BFM02] Randy Bush, Tim Griffin, and David Meyer, "Some Internet Architectural Guidelines and Philosophy", Work in Progress.
[BFM02]ランディブッシュ、ティム・グリフィン、とDavidマイヤー、「一部のインターネットの建築ガイドラインと哲学」、進行中の作業します。
[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.
ネットワーク - のための自動検出メカニズムとしてBGPを使用して、[B02]ハミドウルド - Brahimの、ブライアン・グリーソン、ピーター・アッシュウッド・スミス、エリックC.ローゼン、ヤコフ・レックター、Luyuan牙、ジェレミー・デ・Clercq、リヤドHartani、およびティッサSenevirathne、」ベースのVPN」が進行中で働いています。
[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".
[CDT01]民主主義と技術のためのセンターからの政策提案OPESワーキンググループの取り組みにより懸念、IESGへの電子メール、8月3日、2001年URL「http://www.imc.org/ietf-openproxy/mail-archive /msg00828.html」。
[Clark88] David D. Clark, The Design Philosophy of the DARPA Internet Protocols, SIGCOMM 1988.
[Clark88]デビッド・D.クラーク、DARPAインターネットプロトコルの設計理念、SIGCOMM 1988。
[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]ブライアン・カーペンター、キャスリーン・ニコルズ、 "インターネットとの差別化されたサービス"、技術報告書、2002年2月、URL "http://www.research.ibm.com/resources/ paper_search.shtml"。
[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.、 "サイバースペースでの闘争：明日のインターネットの定義"、SIGCOMM 2002 URL「http://www.acm.org/sigcomm / sigcomm2002 /論文/ tussle.html」。
[Evolvability] Floyd, S., "Papers on the Evolvability of the Internet Infrastructure". Web Page, URL "http://www.icir.org/floyd/evolution.html".
[発展性]フロイド、S.、「インターネットインフラの発展性に論文」。 Webページ、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]ギャレット・ハーディン、 "コモンズの悲劇"、科学、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.、 "階層化とインターネットアーキテクチャ上の参考資料"、Webページ、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：ディスカッションへのポインタ"、Webページ、URL "http://www.icir.org/floyd/tcp_mux.html"。
[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.ローゼン、 "セッション開始プロトコル（SIP）のための変更処理"、BCP 67、RFC 3427 、2002年11月。
[M01] Tim Moors, A Critical Review of End-to-end Arguments in System Design, 2001. URL "http://uluru.poly.edu/~tmoors/".
[M01]ティム・ムーア、システム設計におけるエンドツーエンドの引数の批判的検討、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]相互接続Second Editionの中ラディア・パールマン、「プロトコル設計民俗」、：ブリッジ、ルータ、スイッチ、およびインターネットワーキングプロトコル、アディソン・ウェズリー、1999。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]大工、B.、 "インターネットの建築原則"、RFC 1958、1996年6月。
[RFC2211] Wroclawski, J., "Specification of the Controlled Load Quality of Service", RFC 2211, September 1997.
[RFC2211] Wroclawski、J.、 "サービスの負荷制御品質の仕様"、RFC 2211、1997年9月。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212] Shenker、S.、ヤマウズラ、C.、およびR.ゲラン、 "保証されたサービスの質の仕様"、RFC 2212、1997年9月。
[RFC2316] Bellovin, S., "Report of the IAB Security Architecture Workshop", RFC 2316, April 1998.
[RFC2316] Bellovin氏、S.、 "IABセキュリティアーキテクチャワークショップの報告書"、RFC 2316、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.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、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.ローゼンバーグ、 "SIP：セッション開始プロトコル"、RFC 25434、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グループ"、RFC 2597、1999年6月。
[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.
[RFC2990]ヒューストン、G.、 "IP QoSのアーキテクチャーのための次のステップ"、RFC 2990、2000年11月。
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.
[RFC3124]バラクリシュナン、H.とS. Seshan、 "輻輳管理"、RFC 3124、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.、古城、M.、Griner、J.、モンテネグロ、G.およびZ.シェルビー、 "プロキシのパフォーマンスの向上は、リンク関連の劣化を軽減することを目的"、RFC 3135、2001年6月。
[RFC3168] Ramakrishnan, K. K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K. K.、フロイド、S.及びD.ブラック、RFC 3168、2001年9月。
[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002.
"基板としてのHTTPの使用について" [RFC3205]ムーア、K.、BCP 56、RFC 3205、2002年2月。
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[RFC3221]ヒューストン、G.、 "インターネットにおけるドメイン間ルーティングの解説"、RFC 3221、2001年12月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B.とS.つば、 "のMiddleboxes：分類と課題"、RFC 3234、2002年2月。
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[RFC3238]フロイド、S.とL. Daigle氏、 "オープン・プラグイン可能なエッジサービスのためのIAB建築・ポリシーに関する注意事項"、RFC 3238、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.、Charny、A.、ベネット、JCR、ベンソン、K.、ルBoudec、JY、コートニー、W.、Davari、S.、Firoiu、V.およびD. Stiliadis、「緊急転送PHB（ホップ単位動作）」、RFC 3246、2002年3月。
[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 60, RFC 3360, August 2002.
[RFC3360]フロイド、S.、 "有害考慮不適切なTCPリセット"、BCP 60、RFC 3360、2002年8月。
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[RFC3403] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート3：ドメインネームシステム（DNS）データベース"、RFC 3403、2002年10月。
[RFC3424] Daigle, L., "IAB Considerations for UNilateral Self-Address Fixing (UNSAF)", RFC 3424, November 2002.
[RFC3424] Daigle氏、L.、 "一方的な自己アドレス固定するためのIABの考慮事項（UNSAF）"、RFC 3424、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]ステファン・サヴェージ、ニールカードウェル、デイビット・ウェザーオール、トム・アンダーソン、「ふらちなレシーバーとのTCP輻輳制御」、ACMコンピュータコミュニケーションレビュー、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トランザクション。 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]ウォルターWillingerとジョン・ドイル、「堅牢性とインターネット：設計と進化」、ドラフト、2002年3月、URL「http://netlab.caltech.edu/internet/」。
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.
このドキュメントは、新しいプロトコルを提案していないので、その意味ではどのようなセキュリティ上の考慮を必要としません。しかし、この文書全体プライバシーと整合性の問題と、それらの問題によって作成されたアーキテクチャ要件の議論があります。
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メンバーシップ：
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氏スティーブデアリングサリーフロイドテッドハーディージェフ・ヒューストンチャーリー・カウフマンジェームス・ケンプ、エリックレスコラマイク・セントジョンズ蘭
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。