この文書はRFC3426の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
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.
この文書は新しい標準とプロトコルの仕事をする際にＩＥＴＦ共同体が扱わ
なければならない一般的構築とポリシの問題を示唆します。この文書は、従
うべきガイドラインや構築原則ではなく、取り組むべき問題を含んでいるこ
とを指摘します。
1. Introduction
1. はじめに
This document suggests general architectural and policy questions to
be addressed in our work in the IETF. This document contains
questions to be addressed, as opposed to guidelines or architectural
principles to be followed. These questions are somewhat similar to
the "Security Considerations" currently required in IETF documents
[RFC2316].
この文書はＩＥＴＦにおける仕事で扱われる一般的構築とポリシの質問を示
唆します。この文書は、従うべきガイドラインや構築原則ではなく、取り組
むべき質問を含んでいます。これらの質問は幾分現在のＩＥＴＦ文書で必要
とされる「セキュリティの考察」[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.
我々は、新しい作業グループを認可する際や、作業グループで仕事をする際
や、他の作業グループからのアウトプットを評価する際に、ＩＥＴＦメンバー
が扱うべき問題の示唆として（しかし、チェックリストではない！）、この
文書が使われると仮定しています。この文書は、どのようにプロトコルと体
系を設計するべきかの入門書ではなく、そして何の答えも供給しません。
2. Relationship to "Architectural Principles of the Internet"
2. 「インターネット構築の原則」との関係
RFC 1958 [RFC1958] outlines some architectural principles of the
Internet, as "guidelines that have been found useful in the past, and
that may be useful to those designing new protocols or evaluating
such designs." An example guideline is that "it is also generally
felt that end-to-end functions can best be realized by end-to-end
protocols." Similarly, an example design issue from [RFC1958] is that
"heterogeneity is inevitable and must be supported by design."
ＲＦＣ１９５８[RFC1958]はあるインターネットの、「人たちが新しいプロト
コルを設計するか、あるいはこのような設計を評価する際に、過去に有用で
あると見いだされ、そして有用であるかもしれないガイドライン」としての
構築の原則を概説します。ガイドラインの例は、「エンドエンド機能は、最
も良くエンドエンドプロトコルで実現できすと一般に感じられる」というこ
とです。 同様に[RFC1958]からの設計問題例が「不均質が避けられず、そし
て計画的にサポートしなければならない」ということです。
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."
これと対照的に他の質問は、次の安定性についての質問のように、より制限
がありません：「ノード障害と、汚染や誤作動要素、不完全や欠陥実装から、
プロトコルはどれぐらい強靭ですか？」共同体として、我々はまだ、プロト
コルに作り付けることが可能な強靭性の程度と、この強靭性を保証するため
に利用可能な道具について、研究中です。それで、「ＸとＹとＺに対してプ
ロトコルが強靭であることを保証してください」に対して、まだ明確な構築
ガイドラインがありません。
3. Questions
3. 質問
In this section we list some questions to ask in designing protocols.
Each question is discussed more depth in the rest of this paper. We
aren't suggesting that all protocol design efforts should be required
to explicitly answer all of these questions; some questions will be
more relevant to one document than to another. We also aren't
suggesting that this is a complete list of architectural concerns.
この章で我々はプロトコルを設計することにおいてするべきある質問をリス
トアップします。それぞれの質問がこの文書の残りで論じられたよりさらに
深いです。我々は明示的にこれらすべての質問に答えるためにすべてのプロ
トコル設計で努力が必要であるとは提案していません；ある質問が他の文書
により関係があるでしょう。我々はこれが構築の懸念事項の完全なリストで
あることを示唆していません。
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?
* 他のＩＥＴＦ作業グループで、あるいは他の標準化組織で供給されなけれ
ばならない、全体的な解決策の一部がありますか？
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)?
* プロトコルは競争関係者（例えば、エンドユーザだけではなくＩＳＰ、ルー
タベンダ、ソフトウェアベンダ、あるいは他の者）の権利を保護しますか？
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.
これらの質問のそれぞれがこの文書の残りでより多くの深さで論じられます。
4. Justifying the Solution
4. 解決策の正当化
Question: Why are you proposing this solution, instead of proposing
something else, or instead of using existing protocols and
procedures?
質問：なぜあなたは、他に何かを提案したり、既存のプロトコルと手順を使
う代わりに、この解決策を提案していますか？
4.1. Case study: Integrated and Differentiated Services
4.1. 事例研究：統合と区分サービス
A good part of the work of developing integrated and differentiated
services has been to understand the problem to be solved, and to come
to agreement on the architectural framework of the solution, and on
the nature of specific services. Thus, when integrated services were
being developed, the specification of the Controlled Load [RFC2211]
and Guaranteed [RFC2212] services each required justification of the
need for that particular service, of low loss and bounded delay
respectively.
統合と区分サービスの仕事の良い部分は、解くべき問題を理解し、解決策の
構築のフレームワークと、特定のサービスの性質に関して、合意に到達した
ことでした。それで、統合化サービスが発展した時、制御負荷仕様[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.
後で、「区分サービスの体系」のＲＦＣ２４７５が、前に統合化サービスで
定義された体系と異なる、スケーラブルなサービス区分体系を提案された時、
文書は明確に新しい体系の要求条件の正当化を持ち、提案した体系と他の方
向の比較をしました[RFC2475]。同様に、確実転送[RFC2597]と促進転送
[RFC3246]の区分サービスのホップ毎動作が提案された時、それぞれのサービ
スがインターネットでの必要性の正当化を必要としました。
5. Interactions between Layers
5. 層の間の相互作用
Questions: Why are you proposing a solution at this layer of the
protocol stack, rather than at another layer? Are there solutions at
other layers of the protocol stack as well?
質問：なぜあなたは他の層ではなく、このプロトコルスタックのこの層を提
案しますか？同様にプロトコルスタックの他の層に解決策がありますか？
Is this an appropriate layer in terms of correctness of function,
data integrity, performance, ease of deployment, the diagnosability
of failures, and other concerns?
機能の正当性、データ完全性、性能、配置の容易さ、失敗診断性と他の懸
念点に関してこれは適切な層ですか？
What are the interactions between layers, if any?
もしあれば、層の間の相互作用は何ですか？
5.1. Discussion: The End-to-End Argument
5.1. 議論：エンドエンド議論
The classic 1984 paper on "End-To-End Arguments In System Design"
[SRC84] begins a discussion of where to place functions among modules
by suggesting that "functions placed at low levels of a system may be
redundant or of little value when compared with the cost of providing
them at that low level. Examples discussed in the paper include bit
error recovery, security using encryption, duplicate message
suppression, recovery from system crashes, and delivery
acknowledgement. Low level mechanisms to support these functions are
justified only as performance enhancements." The end-to-end
principle is one of the key architectural guidelines to consider in
choosing the appropriate layer for a function.
「システム設計でのエンドエンド議論」の古典的な１９８４年の文書[SRC84]
はモジュール間のどこに機能をおくかの議論を「システムの低レベルに置か
れた機能は、それを低レベルで供給するコストと比較する時、重複か価値が
ほとんどないかもしれない。文書で論じられた例はビットエラー回復と、暗
号化を使った安全管理と、重複メッセージ抑制と、システムクラッシュから
の回復と、到達確認を含みます。これらの機能を支援する低レベルの機構は
性能拡張でだけ正当です。」と示唆することで始まります。エンドエンド原
則は機能の適切な層を選ぶ際の考慮すべき鍵となる体系ガイドラインの１つ
です。
5.2. Case study: Endpoint Congestion Management
5.2. 事例研究：末端混雑管理
The goal of the Congestion Manager in Endpoint Congestion Management
is to allow multiple concurrent flows with the same source and
destination address to share congestion control state [RFC3124].
There has been a history of proposals for multiplexing flows at
different levels of the protocol stack; proposals have included
adding multiplexing at the HTTP (WebMux) and TCP (TCP Control Blocks)
layers, as well as below TCP (the Congestion Manager) [Multiplexing].
末端混雑管理の混雑管理目的は、同じソースと宛先の複数のフローが同じ混
雑状態を共有する事を許します[RFC3124]。プロトコルスタックの異なるレベ
ルで流れを多重送信する歴史的提案がありました；提案はＴＣＰ（混雑管理）
同様に、ＨＴＴＰ（ウェブ多重）とＴＣＰ（ＴＣＰ制御ブロック）層での多
重送信を含みました[Multiplexing]。
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.
しかしながら、１９８９年の論文「多層多重は有害と思われる」は、「多重
機能の中間と下位層での広範囲な重複は有害で避けるべきです」と示唆しま
す[T89]。それで、フローを多重化する機構を供給する鍵となる問題の１つは
どのプロトコルスタックの層にこの機能性を供給させるのが最も適切か決定
する事です。それぞれの研究者の自然の傾向は、一般に自分が最も良く知っ
ている層に機能を加えることです；これは必ず最も適切な全体的体系をもた
らしません。
5.3. Case study: Layering Applications on Top of HTTP
5.3. 事例研究：ＨＴＴＰ上のアプリケーション層
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.
ＨＴＴＰ上にアプリケーションを重ねることに対しての重要な興味がありま
した[RFC3205]。引用された理由は、広く実装されたブラウザとの互換性と、
クライアントとサーバのライブラリを再利用する能力と、既存のセキュリティ
メカニズムを使う能力と、ファイアウォールを越える能力を含みます。ＲＦ
Ｃ３２０５が論じるように、「ＨＴＴＰ上に新しいプロトコルを重ねること
に対する最近の試みは、いつこのような使用が適切かと、適切な状況でＨＴ
ＴＰを使う適切な方法に関して、多くの問題を投げかけました」。それで、
ＲＦＣ３２０５はただＨＴＴＰ上にアプリケーションを重ねる利益だけでは
なく、ＨＴＴＰ上のアプリケーションの追加の複雑さやオーバヘッドと、特
別な目的のプロトコルを導入するコストを比較します。
The web page on "References on Layering and the Internet
Architecture" has pointers to additional papers discussing general
layering issues in the Internet architecture [Layering].
「レイヤとインターネット体系の参考文献」上のウェブページはインターネッ
ト体系での一般的レイヤ問題を議論する文書へのポインタを持っています。
6. Long-term vs. Short-term Solutions
6. 長期対短期の解決策
Questions: Is this proposal the best long-term solution to the
problem?
質問：この提案は問題に対する最も良い長期の解決策ですか？
If not, what are the long-term costs of this solution, in terms of
restrictions on future development, if any? What are the
requirements for the development of longer-term solutions?
もしそうでなければ、もしあれば、将来の開発に関する制限に関して、こ
の解決策の長期コストは何ですか？より長期の解決策の開発のための必要条
件は何ですか？
6.1. Case study: Traversing NATs
6.1. 事例研究：ＮＡＴ横断
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.
ＮＡＴ中間装置が端末の外部アドレスを変える際の問題を扱うために、ＮＡ
Ｔの他端で知られているアドレス（やポート)を決定する発側処理メカニズ
ム種々な提案がされました。これはプロトコル交換でアドレスデータを使う
ことや、接続を受け取る外部アドレスを広告することが可能な、発側処理を
許すでしょう。
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]でのＩＡＢは、これらの提案が、良くても、特定の問題の短期解
決策と思われ、このような提案を標準化する前に特定の問題を慎重に評価す
るべき理由を概説しました。これらの問題は、直すべき限定範囲の識別、短
期解決策からの脱出戦略と、短期の解決策により未解決にされた長期問題の
記述を含みます。
7. Looking at the whole picture vs. making a building block
7. 全体像対構築ブロック
For a complex protocol which interacts with protocols from other
standards bodies as well as from other IETF working groups, it can be
necessary to keep in mind the overall picture while, at the same
time, breaking out specific parts of the problem to be standardized
in particular working groups.
他の標準化団体や他のＩＥＴＦ作業班からのプロトコルと相互作用する複雑
なプロトコルで、特定の作業班で標準化されている問題の特定の部分を解決
する間に、全体像を念頭におくことは必要です。
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?
質問：他のＩＥＴＦ作業グループで、あるいは他の標準化組織で供給されな
ければならない、全体的な解決策の一部がありますか？
7.1. Case Study: The Session Initiation Protocol (SIP)
7.1. 事例研究：セッション開始プロトコル（ＳＩＰ）
The Session Initiation Protocol (SIP) [RFC2543], for managing
connected, multimedia sessions, is an example of a complex protocol
that has been broken into pieces for standardization in other working
groups. SIP has also involved interaction with other standardization
bodies.
接続されたマルチメディアのセッションを管理するセッション開始プロトコ
ル（ＳＩＰ）[RFC2543]は、細切れにされ他の作業班で標準化された複雑なプ
ロトコルの例です。ＳＩＰは同じく他の標準化団体との相互作用に関係しま
した。
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.
基本的なＳＩＰフレームワークはＳＩＰ作業班で標準化されています。この
作業班はマルチメディアのセッションを開始し管理し終える核心機能を準備
しました。拡張が、もしこれらの核心機能に関係するなら、考慮されます。
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.
マルチメディアセッションを確立する仕事は望ましいマルチメディアセッショ
ンの記述を必要とします。これはセッション記述プロトコル（ＳＤＰ）で供
給されます。ＳＤＰは多数マルチメディアセッション制御（ＭＭＵＳＩＣ）
作業班の供給するビルディング・ブロックです。これはＳＩＰ作業班内で標
準化されていません。
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.
他の作業班が核心機能の外かアプリケーションのＳＩＰ拡張の標準化に関係
します。ＳＩＰＰＩＮＧ作業班は異なる仕事に適用されたＳＩＰの必要条件
を分析し、そしてＳＩＭＰＬＥ作業班はインスタントメッセージとプレゼン
スへのＳＩＰのアプリケーションを調べています。ＩＰＴＥＬ作業班は種々
な方法でＳＩＰと相互作用する電話処理言語（ＣＰＬ）を定義しています。
これらの作業班は時折主ＳＩＰ作業班に必要条件を投げ返します。
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].
最終的に、標準化グループの外のグループが必要条件をＳＩＰワーキンググ
ループに提供する事に従事していました。パケットケーブルコンソーシアム
と３ＧＰＰと３ＧＰＰ２からの分散型電話信号（ＤＣＳ）グループは、種々
な電話通信関連アプリケーションにＳＩＰを使うすべてで、これらのグルー
プのメンバがＳＩＰの必要条件を立案することに関係しました。加えてこれ
らの標準化団体で検討中のＳＩＰの拡張があります。予備や私的や専有の拡
張や、ＳＩＰ名前空間の安全な管理のカテゴリーを含め、ＳＩＰ拡張提案を
ＩＥＴＦで扱う手順は検討中です[MBMWOR02]。
8. Weighing architectural benefits against architectural costs
8. 構築利益と構築費用の重さ
Questions: How do the architectural benefits of a proposed new
protocol compare against the architectural costs, if any? Have the
architectural costs been carefully considered?
質問：提案された新しいプロトコルの構築の利益は、構築の費用と比べてど
うですか？構築の費用は慎重に評価されましたか？
8.1. Case Study: Performance-enhancing proxies (PEPs)
8.1. 事例研究：プロキシ性能拡張（ＰＥＰ）
RFC 3135 [RFC3135] considers the relative costs and benefits of
placing performance-enhancing proxies (PEPs) in the middle of a
network to address link-related degradations. In the case of PEPs,
the potential costs include disabling the end-to-end use of IP layer
security mechanisms; introducing a new possible point of failure that
is not under the control of the end systems; adding increased
difficulty in diagnosing and dealing with failures; and introducing
possible complications with asymmetric routing or mobile hosts. RFC
3135 carefully considers these possible costs, the mitigations that
can be introduced, and the cases when the benefits of
performance-enhancing proxies to the user are likely to outweigh the
costs.
ＲＦＣ３１３５[RFC3135]がネットワークの中にリンク関係の分解を扱うため
にプロキシ性能拡張（ＰＥＰ）を置く関連経費と利益を考えます。ＰＥＰの
場合、可能性がある経費はＩＰレイヤセキュリティメカニズムのエンドエン
ド使用に障害与える；エンドシステムの制御下にない新たな単一故障点の発
生；故障の診断と扱いでの困難の増加；非対称ルーティングと移動ホストで
の混乱の可能性をことを含みます。ＲＦＣ３１３５は、導入を止める経費と、
プロキシ性能拡張の利益が経費よりも重要である可能性を考慮します。
8.2. Case Study: Open Pluggable Edge Services (OPES)
8.2. 事例研究：オープンプラグエッジサービス（ＯＰＥＳ）
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.
インターネットの中間箱によって生じた問題の１つがデータのエンドエンド
完全性です。これはオープンプラグエッジサービス（ＯＰＥＳ）作業班の最
近の問題で例証されます。オープンプラグエッジサービスは、例えば、元の
サーバとクライアントの間のウェブプロキシキャッシュで、ネットワークの
アプリケーションレベル中間者として配置されるサービスです。これらの中
間者は、コンテンツプロバイダあるいはエンドユーザの明白な同意により、
内容を変えるか、あるいはフィルターするでしょう。
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].
ＯＰＥＳ作業班はを認可する手順で起こった体系上の問題の１つがデータの
エンドエンド完全性に関係しました。例えば、「ＯＰＥＳがインターネット
上の通信の完全性と、認識上の完全性の両方を減らすでしょう、そしてコン
テンツがネットワークを通じて動いた時、コンテンツの不確実さが際立って
増加するであろう」と示唆され、そしてそれ故にＯＰＥＳの危険性が利益よ
りも大きいと提案されました[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.
この討論の１つの結果として、ＩＡＢは潜在的な構築の利益とＯＰＥＳのコ
ストを考察した「ＩＡＢ体系とＯＰＥＳに対するポリシの考察」の文書を書
きました[RFC3238]。この文書は特定の解決を勧めるか、あるいは特定の機能
的な必要条件を義務化しませんでしたが、その代わりにＩＥＴＦで標準化さ
れたＯＰＥＳ解決策が扱う際に要求されるべきデータ完全性についての懸念
のような問題の推薦を含みました。
9. General Robustness Questions
9. 一般的安定性問題
Questions: How robust is the protocol, not just to the failure of
nodes, but also to compromised or malfunctioning components,
imperfect or defective implementations, etc?
問題：ノード故障だけではなく、セキュリティ汚染や誤作動の要素、欠陥や
不完全な実装に対して、プロトコルはどれぐらい強靭ですか？
Does the protocol take into account the realistic conditions of the
current or future Internet (e.g., packet drops and packet corruption,
packet reordering, asymmetric routing, etc.)?
プロトコルは現在や将来のインターネットの現実的な条件を考慮に入れま
すか（例えば、パケット破棄とパケット改ざん；パケット順序変更、不均等
ルーティング、など）？
9.1. Discussion: Designing for Robustness
9.1. 論議：強靭性のための設計
Robustness has long been cited as one of the overriding goals of the
Internet architecture [Clark88]. The robustness issues discussed in
[Clark88] largely referred to the robustness of packet delivery even
in the presence of failed routers; today robustness concerns have
widened to include a goal of robust performance in the presence of a
wide range of failures, buggy code, and malicious actions.
強靭性は長い間インターネット体系の最優先の目的の１つとされていました
[Clark88]。[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.
情報を検証する技術は、実際に送ったデータのＴＣＰ応答の検証から、ルー
タがルーティングメッセージの情報を検証するメカニズムまであります。
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).
攻撃に対して資源を守るための技術は、ひとつのＳＹＮパケットに資源を割
り当てないプロトコルの設計による「ＳＹＮ洪水」防止から、資源分割まで
あります（例えば、1つのフローが全ての帯域幅を使用するのを防止する）。
9.2. Case Study: Explicit Congestion Notification (ECN)
9.2. 事例研究：明示的混雑通知（ＥＣＮ）
The Internet is based on end-to-end congestion control, and
historically the Internet has used packet drops as the only method
for routers to indicate congestion to the end nodes. ECN [RFC3168]
is a recent addition to the IP architecture to allow routers to set a
bit in the IP packet header to inform end-nodes of congestion,
instead of dropping the packet.
インターネットはエンドエンド輻輳制御に基づいています、そして歴史的イ
ンターネットはルータがエンドノードに混雑を示す唯一の方法としてパケッ
ト廃棄を使いました。ＥＣＮ[RFC3168]は、パケットを廃棄する代わりにエン
ドノードにパケットを廃棄する代わりにＩＰヘッダのビットを使って輻輳を
通知できるようにした、ＩＰ体系の最近の追加です。
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.
最初、ＥＣＮの実験仕様書[RFC3168]は、大雑把あるいは壊れたルータがＩＰ
ヘッダのＥＣＮの情報を「消去」し、それで混雑情報がエンドノードに到達
しない事の危険についての、大規模な議論を含んでいました。強靭性を追加
するために、標準化仕様書[RFC3168]はＩＰヘッダのＥＣＮフィールドで、
ＥＣＮ「臨時」に使う追加のコードポイントを指定しました。ＥＣＮ臨時の
開発はＴＣＰでの特定の強靭性の前の研究に基づきます[SCWA99]。ＲＦＣ３
１６８がコードポイントの追加を「これは主にトランスポートプロトコルが
要求したように、データ送信者がネットワーク要素がＣＥコードポイントを
消してないのを検証し、データ受信者がＣＥコードポイントが設定されたパ
ケットの受信を送信者に適切に報告できる、のを可能とする願望が動機です。」
と説明します。ＥＣＮ臨時のサポート機構がＥＣＮベースの混雑表示の配達
の強靭性を保証するためにトランスポートプロトコルで必要とされます。
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].
それと対照的に、ＥＣＮのより難しくよりわかりにくい強靭性問題問題が、
中間ボックスでのＴＣＰのＳＹＮパケットのＴＣＰヘッダのＥＣＮフラグに
基づくパケットの区別した扱いに関係します[RFC3360]。問題は「ＥＣＮ開始」
ＳＹＮパケットに関係します、すなわち、ＴＣＰヘッダにＥＣＮフラグを持っ
ているＳＹＮパケットは、２つのＴＣＰエンドホスト間のＥＣＮの使用の交
渉に関係します。ネットワークには「ＥＣＮ 開始」ＳＹＮパケット、他から
のＴＣＰリセットメッセージのパケット、ＴＣＰヘッダのゼロのＥＣＮフラ
グのパケット、を破棄するファイアウォールが存在します。これらはＥＣＮ
設計者が予期していませんでした、そしてＲＦＣ３１６８が「ＥＣＮ設定」
ＳＹＮパケットを廃棄するファイアウォールに対応したＴＣＰの強靭オペレー
ションを可能にするオプションメカニズムを加えました。しかしながら、Ｅ
ＣＮは、ＴＣＰヘッダのＥＣＮフラグをゼロにするすべての中間ボックスに
たいして強靭ではありません。現在までに、トランスポートプロトコルは、
これらのプロトコルの使用を制御する中間ボックスで使われたメカニズムと
独立に標準化されました、そしてネットワークでの無許可のトランスポート
ヘッダへの修正に対してどれほどの強靭性が必要かはまだ明確ではありませ
ん。これらと類似の問題は[RFC3360]でより多く論じられます。
10. Avoiding Tragedy of the Commons
10. 共有地の悲劇の回避
Question: Is performance still robust if everyone is using the new
protocol? Are there other potential impacts of widespread deployment
that need to be considered?
質問：もし全ての人がこのプロトコルを使った場合に、性能は安定していま
すか？可能性のある広範囲にわたる利用に、考慮すべき影響がありますか？
10.1. Case Study: End-to-end Congestion Control
10.1. 事例研究：エンドエンド輻輳制御
[RFC2914] discusses the potential for congestion collapse if flows
are not using end-to-end congestion control in a time of high
congestion. For example, if a new transport protocol was proposed
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]。
11. Balancing Competing Interests
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)?
質問：プロトコルは競争関係者（例えば、エンドユーザだけではなくＩＳＰ、
ルータベンダ、ソフトウェアベンダ、あるいは他の者）の権利を保護しますか？
11.1. Discussion: balancing competing interests
11.1. 論議：競争関係者のバランス
[CWSB02] discusses the role that competition between competing
interests plays in the evolution of the Internet, and takes the
position that the role of Internet protocols is to design the playing
field in this competition, rather than to pick the outcome. The IETF
has long taken the position that it can only design the protocols,
and that often two competing approaches will be developed, with the
marketplace left to decide between them [A02]. (It has also been
suggested that "the marketplace" left entirely to itself does not
always make the best decisions, and that working to identify and
adopt the technically best solution is sometimes helpful. Thus,
while the role of the marketplace should not be ignored, the
decisions of the marketplace should also not be held as sacred or
infallible.)
[CWSB02]が競争関係者間の競合がインターネットの進展を演ずる役割を論じ、
そしてインターネット・プロトコルの役割は結果を選ぶのではなく、この競
合での競技場を設計するという見解をとります。IETFは長い間プロトコルを
設計するだけの立場を取り、しばしば競合する２つの方法を開発し、市場が
選択をする余地を残すという見解を取りました[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]で引合いに出された例は、ＱｏＳをポート
番号のような他の属性と結合するのではなく、ＱｏＳを選択するためにＩＰ
ヘッダのコードポイントを使う決定です。これはＱｏＳと関係がある構造と
経済問題をプロトコルとポート番号の技術的な問題から分離し、そして構造
と価格的に広範囲の解決策を許します。
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.
同じプロトコルの他の実装に対して障壁を増やし、ＩＥＴＦプロトコルに不
必要な複雑さを加えていると、数年間かけての認知された個別の問題があり
ました。明らかにこのような行動はオープン競合の利権を保護していないで
しょう。仕様化されていないプロトコルがオープン競合と同様に不必要な障
壁となりえます。
12. Designing for Choice vs. Avoiding Unnecessary Complexity:
12. 選択と不必要な複雑さの回避の設計
Is the protocol designed for choice, to allow different players to
express their preferences where appropriate? At the other extreme,
does the protocol provide so many choices that it threatens
interoperability or introduces other significant problems?
プロトコルは選択のための設計ですか、異なる人が適切な場合に、彼らの
優先度を表現することを許しますか？反対に、プロトコルは多すぎる選択肢
を用意し、互換性問題を起こすか、他の重要な問題を起こしませんか？
12.1. Discussion: the importance of choice
12.1. 論議：選択の重要性
[CWSB02] suggests that "the fundamental design goal of the Internet
is to hook computers together, and since computers are used for
unpredictable and evolving purposes, making sure that the users are
not constrained in what they can do is doing nothing more than
preserving the core design tenet of the Internet. In this context,
user empowerment is a basic building block, and should be embedded
into all mechanism whenever possible."
[CWSB02]は「インターネットの基本的な設計目的は、コンピュータをつな
ぐことと示唆します、そしてコンピュータの使い方は予期出来ず拡大するの
で、ユーザが出来ることに制限をしないことは、インターネットのコア設計
主義を維持するだけです。ここで、ユーザの向上は基本的なビルディング・
ブロックにより、そして、可能である時はいつでも、すべてのメカニズムの
中に埋め込まれるべきです。」
As an example of choice, "the design of the mail system allows the
user to select his SMTP server and his POP server" [CWSB02]. More
open-ended questions about choice concern the design of mechanisms
that would enable the user to choose the path at the level of
providers, or to allow users to choose third-party intermediaries
such as web caches, or providers for Open Pluggable Edge Services
(OPES). [CWSB02] also notes that the issue of choice itself reflects
competing interests. For example, ISPs would generally like to lock
in customers, while customers would like to preserve their ability to
change among providers.
選択の例は「メールシステムの設計はユーザがＳＭＴＰサーバとＰＯＰサー
バを選ぶことを許す」事です[CWSB02]。選択についてのより制限がない質問
は、ユーザがプロバイダレベルのパスを選択したり、ユーザにウェブキャッ
シュやプロバイダのようなサードパーティ中間者を許すオープンプラグエッ
ジサービス（ＯＰＥＳ）のメカニズムの設計に関係します。[CWSB02]は選択
問題自身が競争関係を反映していることを指摘します。例えば、ＩＳＰは一
般に顧客を閉じ込めることを好むでしょうが、他方顧客はプロバイダ間の移
動能力を維持したいです。
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.
極端なオプション脅威は[MBMWOR02]でも論じられ、そしてこれは修正と拡張
の提案の「絶え間がない洪水」に反応するため、ＳＩＰ（セッション開始プ
ロトコル）のガイドラインを与えます。特に、ＳＩＰ作業班は提案された拡
張が一般的な使用法を持ち、単純性あるいは安定性のコストで効率を悪化し
ないかを心配しています。[MBMWOR02]はＩＥＴＦで開発された他のスケーラ
ブルプロトコルが多くから拡張の調整に役立つかもしれないことを示唆しま
す。
13. Preserving evolvability?
13. 進化可能性維持？
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?
インターネット体系に新しい複雑さを導入するプロトコルで、どのように
プロトコルは安定性と進化可能性の維持を加え、そしてどのようにシステム
に新しい弱さを導入しますか？
13.1. Discussion: evolvability
13.1. 論議：進化可能性
There is an extensive literature and an ongoing discussion about the
evolvability, or lack of evolvability, of the Internet
infrastructure; the web page on "Papers on the Evolvability of the
Internet Infrastructure" has pointers to some of this literature
[Evolvability]. Issues range from the evolvability and overloading
of the DNS; the difficulties of the Internet in evolving to
incorporate multicast, QoS, or IPv6; the difficulties of routing in
meeting the demands of a changing and expanding Internet; and the
role of firewalls and other middleboxes in limiting evolvability.
インターネット基盤の進化可能性あるいは進化否定性について大くの文献と
進行中の議論があります；ウェブページ「インターネット基盤の進化可能性
に関する文書」にこの文献へのポインタがあります[Evolvability]。問題は
ＤＮＳの進化可能性と過負荷の範囲；マルチキャスト・ＱｏＳ・ＩＰｖ６を
含むように変化するインターネットの困難さ；変化と拡張のインターネット
の需要に一致したルーティングの困難さ；進化可能性を制限するファイア
ウォールと他の中間装置の役割、からなります。
[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]が
現実的に次のガイドラインを示唆します：「透過性の障害が起こる−そした
らどんな設計をする」、ここで透過性障害の例はファイアウォール、アプリ
ケーションフィルタ、接続転送、キャッシュ、ＤＮＳクラッジなどを含みま
す。それで、同じく進化可能性を維持するには、インフラ自身の透明度の欠
如でも進化を許すメカニズムを必要とします。
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.
進化可能性を維持するための方法の１つが、新しいメカニズムとプロトコル
の設計で、可能な限りネットワークについての仮定を明確にすることです。
ネットワークについて不当な仮定をする新しいメカニズムは、ネットワーク
の未来の進展に不当な制約を置くことになります。
13.2. Discussion: overloading
13.2. 論議：過負荷
There has been a strong tendency in the last few years to overload
some designs with new functionality, with resulting operational
complexities. Extensible protocols could be seen as one of the tools
for providing evolvability. However, if protocols and systems are
stretched beyond their reasonable design parameters, then scaling,
reliability, or security issues could be introduced. Examples of
protocols that have been seen as either productively extended, or as
dangerously overloaded, or both, include DNS [K02,RFC3403], MPLS
[A02a], and BGP [B02]. In some cases, overloading or extending a
protocol may reduce total complexity and deployment costs by avoiding
the creation of a new protocol; in other cases a new protocol might
be the simpler solution.
新しい機能と、結果的な運用上の複雑がある設計に負担をかけ過ぎる傾向が、
この数年ありました。拡張可能なプロトコルが進化可能性を供給する道具の
１つと見ることができます。しかしながら、もしプロトコルとシステムが合
理的な設計パラメータを越えて拡張されれば、スケールか信頼性かセキュリ
ティ問題が発生しえます。効率的に拡張されてるようにも、危険な過負荷に
も見えるプロトコルの例は、ＤＮＳ[K02,RFC3403]やＭＰＬＳ[A02a]やＢＧＰ
[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].
我々は多くの再利用可能な技術が、構成する技術を含めて、再利用のために
設計されるようにします。例えばＳＡＳＬとＢＥＥＰとＡＰＥＸです。ＴＣ
ＰとＵＤＰは同じく広範囲のアプリケーションによって使われた再利用可能
な輸送プロトコルと見なされることができます。他方、再利用は、ＨＴＴＰ
[RFC3205]で起きたように、プロトコルをトロイの木馬に変えるほど、変貌す
べきではありません。
13.3. Discussion: complexity, robustness, and fragility
13.3. 論議：複雑さと安定性とともろさ
[WD02] gives a historical account of the evolution of the Internet as
a complex system, with particular attention to the tradeoffs between
complexity, robustness, and fragility. [WD02] describes the
robustness that follows from the simplicity of a connectionless,
layered, datagram infrastructure and a universal logical addressing
scheme, and, as case studies, describes the increasing complexity of
TCP and of BGP. The paper describes a complexity/robustness spiral
of an initially robust design and the appearance of fragilities,
followed by modifications for more robustness that themselves
introduce new fragilities. [WD02] conjectures that "the Internet is
only now beginning to experience an acceleration of this
complexity/robustness spiral and, if left unattended, can be fully
expected to experience arcane, irreconcilable, and far-reaching
robustness problems in the not-too-distant future." Citing [WD02],
[BFM02] focuses on the ways that complexity increases capital and
operational expenditures in carrier IP network, and views complexity
as the primary mechanism that impedes efficient scaling.
[WD02]が複雑さと安定性とともろさの間のトレードオフに注目して、複雑な
システムとしてのインターネットの進展の歴史の記述を与えます。[WD02]が
コネクションレスとレイヤとデータグラム基盤と普遍的論理アドレス計画の
単純さから起こる安定性を記述し、そして、事例研究として、ＴＣＰとＢＧ
Ｐの増加する複雑さを記述します。文献は初めに最初の強靭性設計の複雑／
安定性スパイラルと、壊れやすさの出現と、新しい壊れた酸さを導入するよ
り強靭性の修正を記述します。[WD02]が「インターネットは今この複雑／安
定性のスパイラルの加速を経験し始めたとこで、そしてほっておけば、もし
出席者がいないままにしておかれるなら、そう遠くない未来に難解で矛盾し
て広範囲の安定性問題を経験すると予測します」と推測します。[WD02]を引
合いに出して、[BFM02]が複雑さがキャリアの投資コストと運用コストを増
やす方法に焦点を合わせて、そして複雑さが効率的なスケーラビリティを妨
げる主要因と見なします。
14. Internationalization
14. 国際化
Where protocols require elements in text format, have the possibly
conflicting requirements of global comprehensibility and the ability
to represent local text content been properly weighed against each
other?
プロトコルのテキストフォーマットの必要要素で、グローバルなわかりや
すさとローカルテキスト内容表現能力の、多分、矛盾する条件は正確に互い
に比較されましたか？
14.1. Discussion: internationalization
14.1. 論議：国際化
RFC 1958 [RFC1958] included a simple statement of the need for a
common language:
ＲＦＣ１９５８[RFC1958]は言語共通の要求として単純な宣言を含みました：
"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."
「公的（すなわち皆から見える）名前が大文字小文字を区別しないＡＳＣＩ
Ｉであるべきです。特に、これはＤＮＳ名とテキストフォーマットで伝達さ
れるプロトコル要素に関してです」。
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.
ＤＮＳ固有の事例として、国際化ドメイン名作業班はこれらの問題を考慮し
ています。その作業班の憲章で「この仕事での基本的な必要条件は現在のド
メイン名システムの利用と運用を乱さずに、ＤＮＳが任意のドメイン名を任
意のシステムで任意の場所で利用し続けることです。」と述べます。これは
既存のＡＳＣＩＩだけのＤＮＳとの強い後方互換性の要求を導きます。ＤＮ
Ｓがディレクトリサービスのように使われるようになったので、ドメイン名
がローカル文字集合でユーザに提示されることを期待されます。
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.
この文書はこれらの複雑で難しい問題を解決しようと試みませんが、ただこ
れを我々の仕事で扱うべき問題だと述べます。プロトコル要素の中のテキス
トフォーマットでコード化された名前が広く一般に解読できなければならな
いという要求条件は変わらないと思います（すなわちあいまい性がないグロー
バルに標準的なフォーマットでコード化されます）。しかしながら、ある時
点に、このフォーマットが大文字小文字を区別しないＡＳＣＩＩである事は
可能です。
15. Deployability
15. 配置性
Question: Is the protocol deployable?
問題：プロトコルは配置可能ですか？
15.1. Discussion: deployability
15.1. 論議：配置可能性
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].
現在の環境での配置性の理解の失敗の考慮は、ＩＥＴＦの弱さの１つである
と示唆されました。配置困難の例として、ＲＦＣ２９９０[RFC2990]は、サー
ビス品質（ＱｏＳ）体系と、ＩＰマルチキャストにおけるＭＢＯＮＥ配置作
業班のアドレス配置問題と、ＩＰｖ６作業班のＩＰｖ６導入と関係がある利
点問題、を論じます。[CN02]はどのようにインテグレイテドサービスの実装
が管理境界線による障害の要因で制限されたか論じます。インターネット体
系の進展の困難さについての追加の文献は[Evolvability]で利用可能です。
Issues that can complicate deployment include whether the protocol is
compatible with pre-existing standards, and whether the protocol is
compatible with the installed base. For example, a transport
protocol is more likely to be deployable if it performs correctly and
reasonably robustly in the presence of dropped, reordered,
duplicated, delayed, and rerouted packets, as all of this can occur
in the current Internet.
配置を複雑にする問題は、プロトコルが既存の前の標準と互換性があるかど
うかと、そしてプロトコルが実装されているものと互換性があるかを含みま
す。例えば、トランスポートプロトコルが、もしパケットの廃棄と順序逆転
と重複と遅延と経路変更に対して正確に動作し適切に強靭で、これらが減税
のインターネットでかのうなら、であればより配置可能でしょう。
16. Conclusions
16. 結論
This document suggests general architectural and policy questions to
be addressed when working on new protocols and standards in the IETF.
この文書はは、新しいプロトコルに取り組む時に扱うべき、一般的な体系と
ポリシ質問とＩＥＴＦでの基準を示唆します。
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.
we would conjecture that there is a lot to be learned, in terms of
the range of answers to the questions posed in this document, by
studying the successes, failures, and other struggles of the past.
この文書における事例研究は、文書で提案された質問が、過去に作業班で一
般的にどう扱われたかの短い説明です。しかしながら、我々はＩＥＴＦ共同
体の総意ではない一般により物議をかもしている問題の事例研究を避けまし
た。それで、我々は交渉の多すぎるプロトコルの例としてＩＫＥ（インター
ネット鍵交換）の事例を追加する、あるいは市場決定にまかせることのコス
トの事例として管理プロトコルを追加する、のを避けました。我々はこの文
書で質問したこれらや他の問題に事例を提供するを奨励するでしょう；この
ような事例研究は両側の体系論に注意深い貢献を含むことができます。我々
は過去の成功と失敗と争いを調査することで、この文書で出された質問への
答えの限界に関して、学ぶ事が多あると推測するでしょう。
We would welcome feedback on this document for future revisions.
Feedback could be send to the editor, Sally Floyd, at floyd@icir.org.
我々は未来の修正のためにこの文書の上にフィードバックを歓迎するでしょ
う。フィードバックは著者サリー・フロイドfloyd@icir.orgに送ってくださ
い。
17. Acknowledgements
17. 謝辞
This document has borrowed text freely from other IETF RFCs, and has
drawn on ideas from [ASSW02], [CWSB02], [M01] and elsewhere. This
document has developed from discussions in the IAB, and has drawn
from suggestions made at IAB Plenary sessions and on the ietf general
discussion mailing list. The case study on SIP was contributed by
James Kempf, an early case study on Stresses on DNS was contributed
by Karen Sollins, and Keith Moore contributed suggestions that were
incorporated in a number of places in the document. The discussions
on Internationalization and on Overloading were based on an earlier
document by Brian Carpenter and Rob Austein. We have also benefited
from discussions with Noel Chiappa, Karen Sollins, John Wroclawski,
and others, and from helpful feedback from members of the IESG. We
specifically thank Senthilkumar Ayyasamy, John Loughney, Keith Moore,
Eric Rosen, and Dean Willis and others for feedback on various stages
of this document.
この文書は他のＩＥＴＦＲＦＣから自由にテキストを借用して、そして
[ASSW02]や[CWSB02]や[M01]や他から考えを取り入れました。この文書はＩＡ
Ｂでの議論から発展し、そしてＩＡＢ全体セッションとietf一般議論メーリ
ングリスト上にされた提案を取り入れました。ＳＩＰの事例ははJames Kempf
によって提供されました、ＤＮＳのストレスについての初期の事例はKaren
Sollinsによって提供されました、そしてKeith Mooreは多くの場所で文書に
取り入れられた提案を提供しました。国際化と過負荷の論議はBrian
CarpenterとRob Austeinによる以前の文書に基きました。我々はNoel
ChiappaとKaren SollinsとJohn Wroclawskiと他の人たちとの論議と、ＩＥＳ
Ｇのメンバの助けになるフィードバックから利益を得ました。我々はこの文
書の種々の段階でのフィードバックに対して特にSenthilkumar Ayyasamyと
John LoughneyとKeith MooreとEric RosenとDean Willisと他の人たちに感謝
します。
18. Normative References
18. 参照する参考文献
19. Informative References
19. 有益な参考文献
[A02] Harald Alvestrand, "Re: How many standards or
protocols...", email to the ietf discussion mailing
list, Message-id: <598204031.1018942481@localhost>,
April 16, 2002.
[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".
[ASSW02] T. Anderson, S. Shenker, I. Stoica, and D. Wetherall,
"Design Guidelines for Robust Internet Protocols",
HotNets-I, October 2002.
[BFM02] Randy Bush, Tim Griffin, and David Meyer, "Some
Internet Architectural Guidelines and Philosophy",
Work in Progress.
[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.
[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".
[Clark88] David D. Clark, The Design Philosophy of the DARPA
Internet Protocols, 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".
[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".
[Evolvability] Floyd, S., "Papers on the Evolvability of the Internet
Infrastructure". Web Page, 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".
[K02] John C. Klensin, "Role of the Domain Name System",
Work in Progress.
[Layering] Floyd, S., "References on Layering and the Internet
Architecture", Web Page, 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".
[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.
[M01] Tim Moors, A Critical Review of End-to-end Arguments
in System Design, 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.
[RFC1958] Carpenter, B., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[RFC2211] Wroclawski, J., "Specification of the Controlled Load
Quality of Service", RFC 2211, September 1997.
[RFC2212] Shenker, S., Partridge, C., and R. Guerin,
"Specification of Guaranteed Quality of Service", RFC
2212, September 1997.
[RFC2316] Bellovin, S., "Report of the IAB Security Architecture
Workshop", RFC 2316, April 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z. and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2543] Handley, M., Schulzrinne, H., Schooler, B. and J.
Rosenberg, "SIP: Session Initiation Protocol", RFC
25434, March 1999.
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture",
RFC 2990, November 2000.
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion
Manager", RFC 3124, June 2001.
[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.
[RFC3168] Ramakrishnan, K. K., Floyd, S. and D. Black, "The
Addition of Explicit Congestion Notification (ECN) to
IP", RFC 3168, September 2001.
[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP
56, RFC 3205, February 2002.
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the
Internet", RFC 3221, December 2001.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC
3238, January 2002.
[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.
[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered
Harmful", BCP 60, RFC 3360, August 2002.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System
(DDDS) Part Three: The Domain Name System (DNS)
Database", RFC 3403, October 2002.
[RFC3424] Daigle, L., "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF)", RFC 3424, November 2002.
[SCWA99] Stefan Savage, Neal Cardwell, David Wetherall, Tom
Anderson, "TCP Congestion Control with a Misbehaving
Receiver", ACM Computer Communications Review, October
1999.
[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.
[T89] D. Tennenhouse, "Layered Multiplexing Considered
Harmful", Protocols for High-Speed Networks, 1989.
[WD02] Walter Willinger and John Doyle, "Robustness and the
Internet: Design and Evolution", draft, March 2002,
URL "http://netlab.caltech.edu/internet/".
20. Security Considerations
20. セキュリティの考察
This document does not propose any new protocols, and therefore does
not involve any security considerations in that sense. However,
throughout this document there are discussions of the privacy and
integrity issues and the architectural requirements created by those
issues.
この文書は新しいプロトコルを提案せず、従ってセキュリティの考察はその
意味でありません。しかしながら、この文書を通じてプライバシと完全性問
題と、これらの問題から生じる体系の必要条件の論議があります。
21. IANA Considerations
21. ＩＡＮＡの考慮
There are no IANA considerations regarding this document.
この文書に関連するＩＡＮＡの考慮はありません。
Authors' Addresses
著者のアドレス
Internet Architecture Board
EMail: iab@iab.org
IAB Membership at time this document was completed:
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.
著作権（Ｃ）インターネット学会（２００２）。すべての権利は保留される。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。