[要約] RFC 3426は、インターネットアーキテクチャとポリシーに関する一般的な考慮事項をまとめたものです。その目的は、インターネットの設計と運用における重要な要素を理解し、効果的なポリシーの策定と実装を支援することです。
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.
Copyright（c）The Internet Society（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."
対照的に、このドキュメントは、対処するための追加のアーキテクチャの質問を提案することにより、わずかに異なる目的を果たします。したがって、このドキュメントで提案されている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に対して堅牢であることを確認する」という線に沿って、まだ明確な建築ガイドラインはありません。
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:
デザインの質問：
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?
* プロトコルは選択用に設計されていますか？さまざまなプレーヤーが必要に応じて好みを表現できるようにしますか？もう1つの極端に、プロトコルは非常に多くの選択肢を提供しているため、相互運用性を脅かしたり、他の重大な問題を導入したりしますか？
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]は、システムの低レベルに配置された関数は、比較すると冗長またはほとんど価値がないことを示唆することにより、モジュール間に機能を配置する場所の議論を開始します。論文で説明されている例には、ビットエラーの回復、暗号化を使用したセキュリティ、複製メッセージの抑制、システムクラッシュからの回復、配信の承認が含まれます。これらの機能をサポートする低レベルのメカニズムは、パフォーマンスとしてのみ正当化されます。強化。」エンドツーエンドの原則は、関数の適切なレイヤーを選択する際に考慮すべき重要なアーキテクチャガイドラインの1つです。
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]。したがって、多重化フローのメカニズムを提供する際の重要な問題の1つは、この機能を提供するのに最も適しているプロトコルスタックのレイヤーまたはレイヤーを決定することです。各研究者の自然な傾向は、一般に、彼らが最もよく知っているレイヤーに機能を追加することです。これは、必ずしも最も適切な全体的なアーキテクチャをもたらすわけではありません。
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への拡張機能の標準化に関与しています。すすり泣くワーキンググループは、さまざまなタスクに適用された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ワーキンググループに要件を提供する上で非常に積極的に積極的に取り組んできました。PacketCable Consortium、3GPP、および3GPP2の分散コールシグナル（DCS）グループはすべて、さまざまなテレフォニー関連アプリケーションにSIPを使用しており、これらのグループのメンバーはSIPの要件の起草に関与しています。さらに、これらの標準化機関で検討中のSIPの拡張があります。IETFの手順は、予備的、プライベート、または独自の拡張のカテゴリを含むSIPの提案された拡張に対処し、SIPネームスペースの安全な管理を提供するために開発されています[MBMWOR02]。
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）を配置することの相対的なコストと利点を考慮します。PEPSの場合、潜在的なコストには、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.
インターネット内のミドルボックスによって提起された問題の1つは、データのエンドツーエンドの整合性です。これは、Open Pluggable Edge Services（OPES）ワーキンググループをチャーターするという最近の質問に示されています。Open Pluggable Edgeサービスは、たとえばOrigin Serverとクライアントの間のWebプロキシキャッシュなど、ネットワーク内のアプリケーションレベルの仲介業者として展開されるサービスです。これらの仲介者は、コンテンツプロバイダーまたはエンドユーザーのいずれかの明示的な同意を得て、コンテンツを変換またはフィルタリングします。
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ワーキンググループをチャーター化する過程で生じたアーキテクチャの問題の1つです。例として、「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.
この議論の1つの結果として、IABは、OPESの潜在的な建築上の利点とコストの両方を考慮して、「OPEのIAB建築と政策の考慮事項」に関する文書を書きました[RFC3238]。このドキュメントは、特定のソリューションを推奨したり、特定の機能要件を義務付けたりするのではなく、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.
堅牢性は、インターネットアーキテクチャの最優先目標の1つとして長い間引用されてきました[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 Flood」攻撃の防止から、リソースの分割（1つのフローまたは集約がすべてのリンク帯域幅を使用するのを防ぐ）までの範囲です。
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「NonCe」に使用するために、IPヘッダーのECNフィールドに追加のコードポイントを指定しました。ECN Nonceの開発は、TCP [SCWA99]の特定の堅牢性の問題に関する以前の研究によって動機付けられました。RFC 3168は、CodePointの追加は「主に、データ送信者がネットワーク要素がCEコードポイントを消去しておらず、データ受信機が送信者にパケットの受領を適切に報告していることを確認するためにデータ送信者にメカニズムを許可したいという欲求によって動機付けられていると説明しています。CE CodePointセット、トランスポートプロトコルの要求。」ECNベースの混雑表示の送達の堅牢性を確保するために、ECN Nonceのサポートメカニズムが輸送プロトコルで必要です。
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ヘッダーのECNフラグに基づいて、TCP Synパケット[RFC3360]のTCPヘッダーのECNフラグに基づいて、ネットワーク内のパケットの微分処理に関するものです。この問題は、「ECN-Setup」Synパケット、つまり、TCPヘッダーに設定されたECNフラグを備えたSynパケットに関係し、2つのTCPエンドホスト間のECNの使用を交渉します。ネットワークには、「ECNセットアップ」Synパケットをドロップするファイアウォールがあり、TCPリセットメッセージを送信する他のファイアウォール、さらにはTCPヘッダーでECNフラグをゼロにする他のものがあります。これは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]フローが高い混雑の時期にエンドツーエンドの輻輳制御を使用していない場合、混雑崩壊の可能性について説明します。たとえば、エンドツーエンドの混雑制御を使用しなかった新しい輸送プロトコルが提案された場合、新しい輸送プロトコルを使用した個々のフローが、競合するすべてのフローが入る限り、非常にうまく機能することを示すのは簡単かもしれません。ネットワークは、エンドツーエンドの混雑制御を使用していました。新しい輸送プロトコルを完全に評価するには、多くのフローが競合しているときにパフォーマンスを調べる必要があります。すべてが新しいトランスポートプロトコルを使用しています。競合するフローのすべてが、高い輻輳の時期により積極的な輸送プロトコルを使用していた場合、結果は高い定常状態のパケットドロップレートになり、全体的なスループットを減らすことができます。これは、コモンズの悲劇の一形態と見なすことができます。たとえば、1人だけが行うと生産的な練習（たとえば、一般的な放牧牧草地にさらにいくつかの羊を追加する）は、すべての人によって行われた場合に代わりに逆効果になります。]。
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は長い間、プロトコルのみを設計できるという立場を取りました。多くの場合、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をポート番号などの他のプロパティに結合するのではなく、IPヘッダーのCodePointsを使用してQoSを選択する決定です。これにより、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プロトコルに不必要な複雑さを追加する長年の個人が、これらのプロトコルの他の実装に対する障壁を増やしているという長年にわたって知覚された問題がありました。明らかに、そのような行動は、オープン競争の利益を保護していません。不足しているプロトコルは、競争を開くための不必要な障壁としても機能します。
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?
プロトコルは選択用に設計されていますか？さまざまなプレーヤーが必要に応じて好みを表現できるようにしますか？もう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サーバーとポップサーバーを選択できます」[CWSB02]。選択に関するより自由な質問は、ユーザーがプロバイダーのレベルでパスを選択できるようにするメカニズムの設計、またはユーザーがWebキャッシュなどのサードパーティの仲介者を選択できるようにすることに関係しています。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]は、過度の選択が、プロトコルの2つの独立した適切な実装間の相互運用性を確保するのが難しいことにつながる可能性があることに注目しています。
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（セッション開始プロトコル）の修正と拡張のための提案の「連続的な洪水」に応答するためのガイドラインを提供します。特に、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へのKludgeなどが含まれます。したがって、進化性を維持するには、インフラストラクチャ自体の透明性の欠如に直面して進化を可能にするためのメカニズムも必要です。
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.
進化性を維持する方法の1つは、新しいメカニズムとプロトコルの設計者が、ネットワークの残りの部分について行われている仮定について可能な限り明確にすることです。ネットワークについて不当な仮定を行う新しいメカニズムは、ネットワークの将来の進化に不合理な制約を置くことになります。
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.
ここ数年、新しい機能を備えたいくつかのデザインを過負荷にするという強い傾向があり、その結果、運用上の複雑さがありました。拡張可能なプロトコルは、進化性を提供するためのツールの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、ビープ音、頂点が含まれます。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]は、「インターネットは今、この複雑さ/堅牢性のスパイラルの加速を経験し始めているだけであり、放置されていない場合、それほどではない堅牢性の堅牢性の問題を経験することが完全に期待される可能性があると推測しています。遠い将来。"引用[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]の使用に関する具体的な推奨事項を作成しました。状況は、テキストの一部が完全にプロトコル要素に隠されており、機械で読むだけであるが、他の用途は完全に人間の消費のために意図されているという事実によって複雑になっています。多くの使用は、これらの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の特定のケースでは、国際化されたドメイン名ワーキンググループがこれらの問題を検討しています。そのワーキンググループの憲章に記載されているように、「この作業の基本的な要件は、ドメイン名システムの現在の使用と動作を妨げず、DNSがドメイン名を解決できるシステムを継続することです。」これにより、既存のASCII-ONLY 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の主要な弱点の1つであることが示唆されています。展開の問題の例として、RFC 2990 [RFC2990]は、サービス品質（QOS）アーキテクチャの展開の困難、MBONE展開ワーキンググループのさまざまなドキュメント、IPマルチキャストの展開問題の展開問題について、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（Internet Key Exchange）のケーススタディを追加するための提案を並べ替えました。決定する市場。他の人に、この文書のいくつかの質問に光を当てる可能性のあるこれらの問題または他の問題のケーススタディを提供することを奨励します。このようなケーススタディには、両側の建築上の推論の慎重な提示が含まれる場合があります。
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.
将来の改訂のために、このドキュメントに関するフィードバックを歓迎します。フィードバックは、編集者のSally Floydに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 RFCSからテキストを自由に借用し、[ASSW02]、[CWSB02]、[M01]などからのアイデアに基づいています。このドキュメントは、IABでの議論から開発されており、IABプレナリーセッションとIETF一般的なディスカッションメーリングリストで行われた提案から引き出されました。SIPのケーススタディは、DNSのストレスに関する初期のケーススタディがKaren Sollinsによって寄稿され、Keith Mooreが文書の多くの場所に組み込まれた提案を提供しました。国際化と過負荷に関する議論は、ブライアン・カーペンターとロブ・アウスタインによる以前の文書に基づいていました。また、Noel Chiappa、Karen Sollins、John Wroclawskiなどとの議論や、IESGのメンバーからの有益なフィードバックからも恩恵を受けました。この文書のさまざまな段階に関するフィードバックについて、Senthilkumar Ayyasamy、John Loughney、Keith Moore、Eric Rosen、Dean Willisなどに特に感謝します。
[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] Harald Alvestrand、「Re：ゼロまたはプロトコルの数...」、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] Loa Andersson、「現在のIPネットワークにおけるMPLSの役割」、MPLS World News、2002年9月16日。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. Anderson、S。Shenker、I。Stoica、およびD. Wetherall、「堅牢なインターネットプロトコルの設計ガイドライン」、Hotnets-I、2002年10月。
[BFM02] Randy Bush, Tim Griffin, and David Meyer, "Some Internet Architectural Guidelines and Philosophy", Work in Progress.
[BFM02] Randy Bush、Tim Griffin、およびDavid Meyer、「いくつかのインターネットアーキテクチャガイドラインと哲学」が進行中です。
[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.
[B02]ハミド・オールド・ブラヒム、ブライアン・グリーソン、ピーター・アシュウッド・スミス、エリック・C・ローゼン、ヤコフ・レクター、ルユアン・ファン、ジェレミー・デ・クレルク、リアド・ハルタニ、およびティッサ・セネヴィラスネ」ベースのVPNS "、進行中の作業。
[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] 2001年8月3日、民主主義技術センターからのIESGへの電子メール、提案されたOPESワーキンググループの努力によって提起された政策の懸念。/msg00828.html "。
[Clark88] David D. Clark, The Design Philosophy of the DARPA Internet Protocols, SIGCOMM 1988.
[Clark88] David D. Clark、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] Clark、D.、Wroslawski、J.、Sollins、K。、およびBraden、R。、「サイバースペースのTussle：明日のインターネットの定義」、Sigcomm 2002. 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".
[進化性]フロイド、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、pp。1243-1248。url "http://dieoff.org/page95.htm"。
[K02] John C. Klensin, "Role of the Domain Name System", Work in Progress.
[K02]ジョンC.クレンシン、「ドメイン名システムの役割」、進行中の作業。
[Layering] Floyd, S., "References on Layering and the Internet Architecture", Web Page, URL "http://www.icir.org/floyd/layers.html".
[階層化] Floyd、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] Mankin、A.、Bradner、S.、Mahy、R.、Willis、D.、Ott、J.およびB. Rosen、「セッション開始プロトコルの変更プロセス（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] Tim 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 Perlman、「Protocol Design Folklore」、Interconnections第2版：ブリッジ、ルーター、スイッチ、およびインターネットワーキングプロトコル、Addison-Wesley、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.、Partridge、C。、およびR. Guerin、「保証されたサービス品質の仕様」、RFC 2212、1997年9月。
[RFC2316] Bellovin, S., "Report of the IAB Security Architecture Workshop", RFC 2316, April 1998.
[RFC2316] Bellovin、S。、「IAB Security Architecture Workshopのレポート」、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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[RFC2543] Handley, M., Schulzrinne, H., Schooler, B. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 25434, March 1999.
[RFC2543] Handley、M.、Schulzrinne、H.、Schooler、B。and J. Rosenberg、「SIP：SESSION INTIATION Protocol」、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.、Baker、F.、Weiss、W。and J. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.
[RFC2990] Huston、G。、「IP QoSアーキテクチャの次のステップ」、RFC 2990、2000年11月。
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.
[RFC3124] Balakrishnan、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] Border、J.、Kojo、M.、Griner、J.、Montenegro、G。、およびZ. Shelby、「リンク関連の分解を緩和することを目的としたプロキシを向上させるパフォーマンス」、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.
[RFC3168] Ramakrishnan、K。K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002.
[RFC3205]ムーア、K。、「基質としてのHTTPの使用について」、BCP 56、RFC 3205、2002年2月。
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[RFC3221] Huston、G。、「インターネット内のドメイン間ルーティングに関する解説」、RFC 3221、2001年12月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B。およびS.ブリム、「ミドルボックス：分類法と問題」、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] Floyd、S。およびL. Daigle、「Open Pluggable Edge Servicesの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] Davie、B.、Charny、A.、Bennet、J。C。R.、Benson、K.、Le Boudec、J。Y.、Courtney、W.、Davari、S.、Firoiu、V。PHB（PER-HOP行動）」、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。、「Dynamic Delogation Discovery System（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] Stefan Savage、Neal Cardwell、David Wetherall、Tom Anderson、「誤動作の受信機を備えたTCP混雑制御」、ACM Computer Communications Review、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。Reed、およびD. D. Clark、「システム設計におけるエンドツーエンドの議論」、コンピューターシステムに関するACMトランザクション、v.2、n.4、p。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] Walter Willinger and John Doyle、「堅牢性とインターネット：デザインと進化」、ドラフト、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
ハラルド・アルベスランド・ラン・アトキンソン・ロブ・オーストイン・フレッド・ベイカー・レスリー・デイグル・ディー・ディアリング・サリー・フロイド・テッド・ハーディ・ジェフ・ヒューリー・カウフマン・ジェームズ・ケンプフ・エリック・レスカルラ・マイク・セント・ジョンズ
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。