RFC5218 日本語訳
5218 What Makes For a Successful Protocol?. D. Thaler, B. Aboba. July 2008. (Format: TXT=58409 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Thaler
Request for Comments: 5218 B. Aboba
Category: Informational IAB
July 2008
ターレルがコメントのために要求するワーキンググループD.をネットワークでつないでください: 5218年のB.Abobaカテゴリ: 情報のIAB2008年7月
What Makes for a Successful Protocol?
何がうまくいっているプロトコルになりますか?
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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success. Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success. It is hoped that these observations can serve as guidance for future protocol work.
インターネットコミュニティはこれまでの多くのプロトコルを指定しました、そして、これらのプロトコルは異なった度の成功を遂げました。 ケーススタディに基づいて、このドキュメントは、プロトコルの成功を貢献するか、または妨げる要素を確かめるのを試みます。 これらの観測が今後のプロトコル仕事のための指導として機能できることが望まれています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. What is Success? . . . . . . . . . . . . . . . . . . . . . 3
1.2. Success Dimensions . . . . . . . . . . . . . . . . . . . . 3
1.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Effects of Wild Success . . . . . . . . . . . . . . . . . 5
1.4. Failure . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Initial Success Factors . . . . . . . . . . . . . . . . . . . 7
2.1. Basic Success Factors . . . . . . . . . . . . . . . . . . 7
2.1.1. Positive Net Value (Meet a Real Need) . . . . . . . . 7
2.1.2. Incremental Deployability . . . . . . . . . . . . . . 9
2.1.3. Open Code Availability . . . . . . . . . . . . . . . . 10
2.1.4. Freedom from Usage Restrictions . . . . . . . . . . . 10
2.1.5. Open Specification Availability . . . . . . . . . . . 10
2.1.6. Open Maintenance Processes . . . . . . . . . . . . . . 10
2.1.7. Good Technical Design . . . . . . . . . . . . . . . . 11
2.2. Wild Success Factors . . . . . . . . . . . . . . . . . . . 11
2.2.1. Extensible . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2. No Hard Scalability Bound . . . . . . . . . . . . . . 11
2.2.3. Threats Sufficiently Mitigated . . . . . . . . . . . . 11
3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. Informative References . . . . . . . . . . . . . . . . . . . . 13
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 Successは何ですか? . . . . . . . . . . . . . . . . . . . . . 3 1.2. 成功寸法. . . . . . . . . . . . . . . . . . . . 3 1.2.1。 例. . . . . . . . . . . . . . . . . . . . . . . 4 1.3。 ワイルドな成功. . . . . . . . . . . . . . . . . 5 1.4の効果。 失敗. . . . . . . . . . . . . . . . . . . . . . . . . 6 2。 成功要素. . . . . . . . . . . . . . . . . . . 7 2.1に頭文字をつけてください。 基本の成功要素. . . . . . . . . . . . . . . . . . 7 2.1.1。 上向きの正味価格(本当の需要を満たします).72.1.2。 増加のDeployability. . . . . . . . . . . . . . 9 2.1.3。 オープンコードの有用性. . . . . . . . . . . . . . . . 10 2.1.4。 使用制限. . . . . . . . . . . 10 2.1.5から自由。 仕様の有用性. . . . . . . . . . . 10 2.1.6を開いてください。 .7に維持の過程. . . . . . . . . . . . . . 10 2.1を開いてください。 良いテクニカル・デザイン. . . . . . . . . . . . . . . . 11 2.2。 ワイルドな成功要素. . . . . . . . . . . . . . . . . . . 11 2.2.1。 広げることができる、.112.2 .2。 困難なスケーラビリティバウンド. . . . . . . . . . . . . . 11 2.2.3がありません。 脅威は.113を十分緩和しました。 結論. . . . . . . . . . . . . . . . . . . . . . . . . 12 4。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 13 5。 有益な参照. . . . . . . . . . . . . . . . . . . . 13
Thaler & Aboba Informational [Page 1] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[1ページ]のRFC5218プロトコル成功2008年7月
Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 17
A.1. HTML/HTTP vs. Gopher and FTP . . . . . . . . . . . . . . . 17
A.1.1. Initial Success Factors . . . . . . . . . . . . . . . 17
A.1.2. Wild Success Factors . . . . . . . . . . . . . . . . . 18
A.1.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 18
A.2. IPv4 vs. IPX . . . . . . . . . . . . . . . . . . . . . . . 18
A.2.1. Initial Success Factors . . . . . . . . . . . . . . . 18
A.2.2. Wild Success Factors . . . . . . . . . . . . . . . . . 19
A.2.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 19
A.3. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
A.3.1. Initial Success Factors . . . . . . . . . . . . . . . 19
A.3.2. Wild Success Factors . . . . . . . . . . . . . . . . . 20
A.3.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 20
A.4. Inter-Domain IP Multicast vs. Application Overlays . . . 20
A.4.1. Initial Success Factors . . . . . . . . . . . . . . . 20
A.4.2. Wild Success Factors . . . . . . . . . . . . . . . . . 21
A.4.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 22
A.5. Wireless Application Protocol (WAP) . . . . . . . . . . . 22
A.5.1. Initial Success Factors . . . . . . . . . . . . . . . 22
A.5.2. Wild Success Factors . . . . . . . . . . . . . . . . . 22
A.5.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 22
A.6. Wired Equivalent Privacy (WEP) . . . . . . . . . . . . . . 23
A.6.1. Initial Success Factors . . . . . . . . . . . . . . . 23
A.6.2. Wild Success Factors . . . . . . . . . . . . . . . . . 23
A.6.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 23
A.7. RADIUS vs. TACACS+ . . . . . . . . . . . . . . . . . . . . 24
A.7.1. Initial Success Factors . . . . . . . . . . . . . . . 24
A.7.2. Wild Success Factors . . . . . . . . . . . . . . . . . 24
A.7.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 24
A.8. Network Address Translators (NATs) . . . . . . . . . . . . 25
A.8.1. Initial Success Factors . . . . . . . . . . . . . . . 25
A.8.2. Wild Success Factors . . . . . . . . . . . . . . . . . 25
A.8.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 26
Appendix B. IAB Members at the Time of This Writing . . . . . . . 26
付録A.ケーススタディ. . . . . . . . . . . . . . . . . . . . 17A.1。 HTML/HTTP対ゴーファーとFTP. . . . . . . . . . . . . . . 17A.1.1。 成功要素. . . . . . . . . . . . . . . 17A.1.2に頭文字をつけてください。 ワイルドな成功は.18A.1.3を因数分解します。 議論. . . . . . . . . . . . . . . . . . . . . . 18A.2。 IPv4対IPX. . . . . . . . . . . . . . . . . . . . . . . 18A.2.1 成功要素. . . . . . . . . . . . . . . 18A.2.2に頭文字をつけてください。 ワイルドな成功は.19A.2.3を因数分解します。 議論. . . . . . . . . . . . . . . . . . . . . . 19A.3。 セキュアシェル (SSH). . . . . . . . . . . . . . . . . . . . . . . . . . . 19A.3.1。 成功要素. . . . . . . . . . . . . . . 19A.3.2に頭文字をつけてください。 ワイルドな成功は.20A.3.3を因数分解します。 議論. . . . . . . . . . . . . . . . . . . . . . 20A.4。 相互ドメインIPマルチキャスト対アプリケーションは.20A.4.1をかぶせます。 成功要素. . . . . . . . . . . . . . . 20A.4.2に頭文字をつけてください。 ワイルドな成功は.21A.4.3を因数分解します。 議論. . . . . . . . . . . . . . . . . . . . . . 22A.5。 ワイヤレス・アプリケーション・プロトコル(WAP). . . . . . . . . . . 22A.5.1。 成功要素. . . . . . . . . . . . . . . 22A.5.2に頭文字をつけてください。 ワイルドな成功は.22A.5.3を因数分解します。 議論. . . . . . . . . . . . . . . . . . . . . . 22A.6。 WEP(WEP). . . . . . . . . . . . . . 23A.6.1。 成功要素. . . . . . . . . . . . . . . 23A.6.2に頭文字をつけてください。 ワイルドな成功は.23A.6.3を因数分解します。 議論. . . . . . . . . . . . . . . . . . . . . . 23A.7。 半径対TACACS+.24A.7.1 成功要素. . . . . . . . . . . . . . . 24A.7.2に頭文字をつけてください。 ワイルドな成功は.24A.7.3を因数分解します。 議論. . . . . . . . . . . . . . . . . . . . . . 24A.8。 アドレス変換機構(NATs).25A.8.1をネットワークでつないでください。 成功要素. . . . . . . . . . . . . . . 25A.8.2に頭文字をつけてください。 ワイルドな成功は.25A.8.3を因数分解します。 この書くこと. . . . . . . 26時点の議論. . . . . . . . . . . . . . . . . . . . . . 26付録B.IABメンバー
Thaler & Aboba Informational [Page 2] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[2ページ]のRFC5218プロトコル成功2008年7月
1. Introduction
1. 序論
One of the goals of the Internet Engineering Task Force (IETF) is to define protocols that successfully meet their implementation and deployment goals. Based on case studies, this document identifies some of the factors influencing success and failure of protocol designs. It is hoped that this document will be of use to the following audiences:
インターネット・エンジニアリング・タスク・フォース(IETF)の目標の1つは首尾よく彼らの実現と展開目標を達成するプロトコルを定義することです。 ケーススタディに基づいて、このドキュメントはプロトコルデザインの成功と失敗に影響を及ぼす要素のいくつかを特定します。 このドキュメントが以下の聴衆の役に立つことが望まれています:
o IESG members deciding whether to charter a Working Group to do
work on a specific protocol;
o 特定のプロトコルに取り組むために作業部会をチャーターするかどうか決めるIESGメンバー。
o Working Group participants selecting among protocol proposals;
o プロトコルの中で提案を選択する作業部会の関係者。
o Document authors developing a new protocol specification;
o 新しいプロトコル仕様を開発する作者を記録してください。
o Anyone evaluating the success of a protocol experiment.
o プロトコル実験の成功を評価するだれも。
1.1. What is Success?
1.1. Successは何ですか?
In discussing the factors that help or hinder the success of a protocol, we need to first define what we mean by "success". A protocol can be successful and still not be widely deployed, if it meets its original goals. However, in this document, we consider a successful protocol to be one that both meets its original goals and is widely deployed. Note that "widely deployed" does not mean "inter-domain"; successful protocols (e.g., DHCP [RFC2131]) may be widely deployed solely for intra-domain use.
プロトコルの成功を助けるか、または妨げる要素について議論する際に、私たちは、最初に私たちが「成功」で言っていることを定義する必要があります。 元の目標を達成するなら、プロトコルは、うまくいって、まだ広く配備できません。 しかしながら、本書では、私たちは、うまくいっているプロトコルが元の目標を達成して、広く配備されるものであると考えます。 「広く配備された」それが「相互ドメイン」を意味しないことに注意してください。 うまくいっているプロトコル(例えば、DHCP[RFC2131])は唯一イントラドメイン使用のために広く配備されるかもしれません。
The following are examples of successful protocols:
↓これはうまくいっているプロトコルに関する例です:
Inter-domain: IPv4 [RFC0791], TCP [RFC0793], HTTP [RFC2616], DNS
[RFC1035], BGP [RFC4271], UDP [RFC0768], SMTP [RFC2821], SIP
[RFC3261].
相互ドメイン: IPv4[RFC0791](TCP[RFC0793]、HTTP[RFC2616]、DNS[RFC1035]、BGP[RFC4271]、UDP[RFC0768]、SMTP[RFC2821])は[RFC3261]をちびちび飲みます。
Intra-domain: ARP [RFC0826], PPP [RFC1661], DHCP [RFC2131], RIP
[RFC1058], OSPF [RFC2328], Kerberos [RFC4120], NAT [RFC3022].
イントラドメイン: アルプ[RFC0826](ppp[RFC1661]、DHCP[RFC2131])は[RFC1058]、OSPF[RFC2328]、ケルベロス[RFC4120]、NAT[RFC3022]を裂きます。
1.2. Success Dimensions
1.2. 成功寸法
Two major dimensions on which a protocol can be evaluated are scale and purpose. When designed, a protocol is intended for some range of purposes and was designed for use on a particular scale.
プロトコルを評価できる2つの主要な寸法が、スケールと目的です。 いつが設計されていて、プロトコルは、何らかの範囲の目的のために意図して、特定のスケールにおける使用のために設計されました。
Figure 1 graphically depicts these concepts.
図1はグラフィカルにこれらの概念について表現します。
Thaler & Aboba Informational [Page 3] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[3ページ]のRFC5218プロトコル成功2008年7月
Scale ^
|
| +------------+
| | |
| | Original |
| | Protocol |
| | Design |
| | Space |
| | |
<-----------------------------------------------> Purpose
スケール^| | +------------+ | | | | | オリジナル| | | プロトコル| | | デザイン| | | スペース| | | | <----------------------------------------------->目的
Figure 1
図1
According to these metrics, a "successful" protocol is one that is used for its original purpose and at the originally intended scale. A "wildly successful" protocol far exceeds its original goals, in terms of purpose (being used in scenarios far beyond the initial design), in terms of scale (being deployed on a scale much greater than originally envisaged), or both. That is, it has overgrown its bounds and has ventured out "into the wild".
これらの測定基準によると、「うまくいっている」プロトコルは初心と元々意図したスケールで使用されるものです。 遠くに議定書を作ってください。「むやみやたらにうまくいく」、目的(シナリオでは、遠くに初期のデザインを超えて使用される)に関してスケール(元々考えられるよりはるかに大きいスケールでは、配備される)、または両方に関して元の目標を超えています。 はびこるのに持っている、それは、バウンドしていて、「荒野」にあえて出かけました。
1.2.1. Examples
1.2.1. 例
HTTP is an example of a "wildly successful" protocol that exceeded its design in both purpose and scale:
HTTPは目的とスケールの両方でデザインを超えていた「むやみやたらにうまくいっている」プロトコルに関する例です:
Scale ^ +---------------------------------------+
| | Actual Deployment |
| | |
| | |
| | +------------+ |
| | | Original | |
| | (Web | Design | (Firewall |
| | Services) | Space | Traversal) |
| | | (Web) | |
<-----------------------------------------------> Purpose
スケール^ +---------------------------------------+ | | 実際の展開| | | | | | | | | +------------+ | | | | オリジナル| | | | (ウェブ| |設計してください(ファイアウォール| | | サービス)| スペース| 縦断) | | | | (ウェブ) | | <----------------------------------------------->目的
Another example of a wildly successful protocol is IPv4. Although it
was designed for all purposes ("Everything over IP and IP over
Everything"), it has been deployed on a far greater scale than that
for which it was originally designed; the limited address space only
became an issue after it had already vastly surpassed its original
design.
むやみやたらにうまくいっているプロトコルに関する別の例はIPv4です。 すべての目的(「すべて上のIPとIPの上のすべて」)のために設計されましたが、それはそれが元々設計されたそれよりはるかに大きいスケールで配備されました。 既に広大に当初の設計を凌いだ後に限られたアドレス空間は問題になっただけです。
Another example of a successful protocol is ARP. Originally intended for a more general purpose (namely, resolving network layer addresses to link layer addresses, regardless of the media type or network layer protocol), ARP was widely deployed for a narrower scope of uses
うまくいっているプロトコルに関する別の例はARPです。 元々より一般的な目的(すなわち、メディアタイプかネットワーク層プロトコルにかかわらず層のアドレスをリンクするためにネットワーク層アドレスを決議する)のために意図していて、ARPは広く用途の、より狭い範囲に配備されました。
Thaler & Aboba Informational [Page 4] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[4ページ]のRFC5218プロトコル成功2008年7月
(resolution of IPv4 addresses to Ethernet MAC addresses), but then was adopted for other uses such as detecting network attachment (Detecting Network Attachment in IPv4 (DNAv4) [RFC4436]). Also, like IPv4, ARP is deployed on a much greater scale (in terms of number of machines, but not number on the same subnet) than originally expected.
(イーサネットMACアドレスへのIPv4アドレスの解決)、ネットワーク付属を見つけなどなどの(IPv4(DNAv4)[RFC4436]にNetwork Attachmentを検出します)他の用途のためにその時だけは採用されました。 また、IPv4のように、ARPは元々予想されるよりはるかに大きいスケール(同じサブネットの数ではなく、マシンの数に関する)で配備されます。
Scale ^ +-------------------+
| | Actual Deployment |
| | |
| | | Original Design Space
| | +-------------+--------------+
| | |(IP/Ethernet)|(Non-IP) |
| |(DNA)| | |
| | | |(Non-Ethernet)|
| | | | |
<-----------------------------------------------> Purpose
スケール^ +-------------------+ | | 実際の展開| | | | | | | 当初の設計スペース| | +-------------+--------------+ | | |(IP/イーサネット)|(非IP) | | |(DNA)| | | | | | |(非イーサネット)| | | | | | <----------------------------------------------->目的
1.3. Effects of Wild Success
1.3. ワイルドな成功の効果
Wild success can be both good and bad. A wildly successful protocol is so useful that it can solve more problems or address more scenarios or devices. This may indicate that it is time to revise the protocol to better accommodate the new design space.
ワイルドな成功は、良くて、かつ悪い場合があります。 むやみやたらにうまくいっているプロトコルが非常に役に立つので、それは、より多くの問題を解決するか、または、より多くのシナリオか装置を記述できます。 これは、新案スペースをよりよく収容するためにもうプロトコルを改訂するべき時間であることを示すかもしれません。
However, if a protocol is used for a purpose other than what it was designed for:
しかしながら、何を除いて、プロトコルが目的に使用されるかなら、それは以下のために設計されました。
o There may be undesirable side effects because of design decisions
that are appropriate for the originally intended purpose, but
inappropriate for the new purpose.
o 望ましくない副作用が元々意図した目的のために適切な、しかし、新しい目的のために不適当なデザイン決定のためにあるかもしれません。
o There may be performance problems if the protocol was not designed
to scale to the extent to which it was deployed.
o プロトコルがそれが配備された範囲に比例するように設計されなかったなら、性能問題があるかもしれません。
o Implementers may attempt to add or change functionality to work
around the design limitations without complete understanding of
their effect on the overall protocol behavior and invariants.
o Implementersは、設計上の制限の周りで総合的なプロトコルの振舞いと不変式におけるそれらの効果の完全な理解なしで働くために機能性を加えるか、または変えるのを試みるかもしれません。
o Wildly successful protocols become high value targets for
attackers because of their popularity and the potential for
exploitation of uses or extensions that are less well understood
and tested than the original protocol.
o むやみやたらにうまくいっているプロトコルはそれほどよくない理解されないで、テストされる用途か拡大の開発の彼らの人気と可能性でオリジナルのプロトコルより攻撃者にとって、高い値の目標になります。
A wildly successful protocol is therefore vulnerable to "death by success", collapsing as a result of attacks or scaling limitations.
「成功による死」に、したがって、攻撃かスケーリング制限の結果、崩れて、むやみやたらにうまくいっているプロトコルは傷つきやすいです。
Thaler & Aboba Informational [Page 5] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[5ページ]のRFC5218プロトコル成功2008年7月
1.4. Failure
1.4. 失敗
Failure, or the lack of success, cannot be determined before allowing sufficient time to pass (e.g., 5-10 years for an average protocol). Failure criteria include:
通ることができるくらいの時間(例えば、平均したプロトコルのための5-10年)を許容する前に、失敗、または成功の不足が決定できません。 失敗評価基準は:
o No mainstream implementations. There is little or no support in
hosts, routers, or other classes of relevant devices.
o 主流の実現がありません。 サポートがホスト、ルータ、または他のクラスの関連装置にまずありません。
o No deployment. Devices that support the protocol are not
deployed, or if they are, then the protocol is not enabled.
o 展開がありません。 プロトコルをサポートする装置が配備されないか、またはそれらがあるなら、プロトコルは可能にされません。
o No use. While the protocol may be deployed, there are no
applications or scenarios that actually use the protocol.
o 無駄。 プロトコルは配備されるかもしれませんが、実際にプロトコルを使用するどんな利用もシナリオもありません。
At the time a protocol is first designed, the three above conditions hold, which is why it is important to allow sufficient time to pass before evaluating the success or failure of a protocol.
状態を超えた3は、プロトコルが最初に設計される時代にそれが十分な時間プロトコルの成否を評価する前に通るのを許容するために重要である理由がどれであるかを保持します。
The lack of a value chain can make it difficult for a new protocol to progress from implementation to deployment to use. While the term "chicken-and-egg" problem is sometimes used to describe the lack of a value chain, the lack of implementation, deployment, or use is not the cause of failure, it is merely a symptom.
価値連鎖の不足で、新しいプロトコルが実現から使用する展開まで進歩をするのが難しくなる場合があります。 用語「鶏肉と卵」問題が価値連鎖の不足について説明するのに時々使用されますが、実現、展開、または使用の不足が失敗の原因でない、それは単に兆候です。
There are many strategies that have been used in the past for overcoming the initial lack of implementations, deployment, and use, although none of these guarantee success. For example:
過去に実現、展開、および使用の初期の不足を克服するのに使用された多くの戦略があります、これらのいずれも成功を保証しませんが。 例えば:
o Address a critical and imminent problem. If the need is severe
enough, the industry is incented to adopt it as soon as
implementations exist, and well-known need is sufficient to
motivate implementations. For example, NAT provided an immediate
address sharing capability to the individual deploying it
(Appendix A.8). Thus, when creating a protocol, consider whether
it can be easily tailored or expanded to directly target a
critical problem; if it only solves part of the problem, consider
what would be needed in addition.
o その批判的で差し迫っている問題を訴えてください。 必要性が十分厳しいなら、産業は、実現が存在していて、周知の必要性が実現を動機づけるために十分であるとすぐに、それを採用するためにincentedされます。 例えば、NATはそれ(付録A.8)を配備している個人に即値アドレス共有能力を提供しました。 したがって、プロトコルを作成するときには、直接重大問題を狙うためにそれを容易に仕立てるか、または広げることができるか考えてください。 問題の一部を解決するだけであるなら、何がさらに、必要であるか考えてください。
o Provide a "killer app" with low deployment costs. This strategy
can be used to generate demand where none existed before. See the
HTTP case study in Appendix A.1 for an example.
o 低い展開コストを「キラー・アプリケーション」に提供してください。 なにも以前存在しなかったところで要求を発生させるのにこの戦略を使用できます。 例に関してAppendix A.1のHTTPケーススタディを見てください。
o Provide value for existing unmodified applications. This solves
the chicken-and-egg problem by ensuring that use exists as soon as
the protocol is deployed, and therefore, the benefit can be
realized immediately. See the Wired Equivalent Privacy (WEP) case
study in Appendix A.6 for an example.
o 変更されていない利用を存在するための値に提供してください。 プロトコルを配備して、したがって、すぐに利益を実現できるとすぐに、使用が存在するのを確実にすることによって、これは因果関係の分からない問題を解決します。 例に関してAppendix A.6のWEP(WEP)ケーススタディを見てください。
Thaler & Aboba Informational [Page 6] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[6ページ]のRFC5218プロトコル成功2008年7月
o Reduce complexity and cost by narrowing the intended purpose
and/or scope to an area where it is easiest to succeed. This may
allow removing complexity that is not required for the narrow
purpose. Removing complexity reduces the cost of implementation
and deployment to where the resulting cost may be very low
compared to the benefit. For example, link-scoped multicast is
far more successful than, say, inter-domain multicast (see
Appendix A.4).
o 成功するのが最も簡単である領域に本来の目的、そして/または、範囲を狭くすることによって、複雑さとコストを削減してください。 これで、狭い目的に必要でない複雑さを取り除くかもしれません。 複雑さを取り除くと、利益と比べて、実現と展開のコストは結果として起こる費用が非常に低いかもしれないところに削減されます。 例えば、リンクで見られたマルチキャストはたとえば、相互ドメインマルチキャストよりはるかにうまくいっています(Appendix A.4を見てください)。
o A government or other entity may provide incentives or
disincentives that motivate implementation and deployment. For
example, specific cryptographic algorithms may be mandated. As
another example, Japan started an economic incentive program to
generate IPv6 [RFC2460] implementations and deployment.
o 政府か他の実体が実現と展開を動機づける誘因か行動を妨げるものを提供するかもしれません。 例えば、特定の暗号アルゴリズムは強制されるかもしれません。 別の例として、日本は、IPv6[RFC2460]実現と展開を発生させるように経済刺激プログラムを始動しました。
As we will see, such strategies are often successful because they directly target the top success factors.
私たちが見るように、直接最高成功要素を狙うので、そのような戦略はしばしばうまくいっています。
2. Initial Success Factors
2. 初期の成功要素
In this section, we identify factors that contribute to success and "wild" success.
このセクションで、私たちは成功に貢献する要素と「ワイルドな」成功を特定します。
Note that a successful protocol will not necessarily include all the success factors, and some success factors may be present even in failed designs. Nevertheless, experience appears to indicate that the presence of success factors seems to improve the probability of success.
うまくいっているプロトコルが必ずすべての成功要素を含むというわけではないことに注意してください。そうすれば、いくつかの成功要素が失敗したデザインでさえ存在していてもよいです。 それにもかかわらず、経験は成功要素の存在が、成功の確率を改良するように思えるのを示すように見えます。
The success factors, and their relative importance, were suggested by a series of case studies (Appendix A).
一連のケーススタディ(付録A)によって成功要素、およびそれらの相対的な重要性は示されました。
2.1. Basic Success Factors
2.1. 基本の成功要素
2.1.1. Positive Net Value (Meet a Real Need)
2.1.1. 上向きの正味価格(本当の需要を満たします)
It is critical to the success of a protocol that the benefits of deploying the protocol (monetary or otherwise) outweigh the costs, which include:
それは、プロトコル(通貨の、または、そうでない)を配備する利益がコストより重いのがプロトコルの成功に重要です。(コストは以下の通りです)。
o Hardware cost: Protocols that don't require hardware changes are
easier to deploy than those that do. Overlay networks are one way
to avoid requiring hardware changes. However, often hardware
updates are required even for protocols whose functionality could
be provided solely in software. Vendors often implement new
o ハードウェア費用: ハードウェアの変更を必要としないプロトコルはそうするそれらより配備しやすいです。 ハードウェアの変更を必要とするのを避けることにおいてオーバレイネットワークは一方通行です。 しかしながら、しばしば、ハードウェア最新版が機能性を唯一ソフトウェアに提供できたプロトコルにさえ必要です。 業者はしばしば新しく実行します。
Thaler & Aboba Informational [Page 7] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[7ページ]のRFC5218プロトコル成功2008年7月
functionality only within later branches of the code tree, which
may only run on new hardware. As a result, the safest way to
avoid hardware upgrade cost is to design for backward
compatibility with both existing hardware and software.
符号樹の後の枝だけの中の機能性。枝は新しいハードウェアで動くだけであるかもしれません。 その結果、ハードウェアアップグレード費用を避ける最も安全な方法は後方のために既存のハードウェアとソフトウェアの両方との互換性を設計することです。
o Operational interference: Protocols that don't require changes to
other operational processes and tools are easier to deploy than
ones that do. For example, IPsec [RFC4301] interferes with
NetFlow [RFC3954] deep packet inspection, which can be important
to operators.
o 操作上の干渉: 他の操作上の過程への変化を必要としないプロトコルとツールはそうするものより配備しやすいです。 例えば、IPsec[RFC4301]はNetFlow[RFC3954]の深いパケット点検を妨げます。(オペレータにとって、それは、重要である場合があります)。
o Retraining: Protocols that have no configuration, or are very easy
to configure/manage, are cheaper to deploy.
o 再教育します: 構成を全く持っていないか、構成するか、または非常に管理しやすいプロトコルは、展開するのにより安いです。
o Business dependencies: Protocols that don't require changes to a
business model (whether for implementers or deployers) are easier
to deploy than ones that do. There are costs associated with
changing billing and accounting systems and retraining of
associated personnel, and in addition, the assumptions on which
the previous business model was based may change. For example,
some time ago many service providers had business models built
around dial-up with an assumption that machines were not connected
all the time; protocols that desired always-on connectivity
required the business model to change since the networks were not
optimized for always-on. Similarly, some service providers have
business models that assume that upstream bandwidth is
underutilized; peer-to-peer protocols may require this business
model to change. Finally, many service providers have business
models based on charging for the amount of bandwidth consumed on
the link to a customer; multicast protocols interfere with this
business model since they provide a way for a customer to consume
less bandwidth on the source link by sending multicast traffic, as
opposed to paying more to source many unicast streams, without
having some other mechanism to cover the cost of replication in
the network (e.g., router CPU, downstream link bandwidth, extra
management). Multicast protocols also complicate business models
based on charging the source of traffic based on the amount of
multicast replication, since the source may not be able to predict
the cost until a bill is received.
o ビジネスの依存: ビジネスモデル(implementersかデプロイヤにかかわらず)への変化を必要としないプロトコルはそうするものより配備しやすいです。 関連人員に請求して、システムを説明して、再教育される変化に関連しているコストがあります、そして、さらに、前のビジネスモデルが基づいた仮定は変化するかもしれません。 例えば、先頃、多くのサービスプロバイダーがダイヤルアップの周りにマシンが絶えず接続されなかったという仮定でビジネスモデルを造らせました。 必要ないつもオンな接続性が、ネットワーク以来ビジネスモデルが変えるのを必要としたプロトコルのために最適化されませんでした。いつもオンです。 同様に、いくつかのサービスプロバイダーには、上流の帯域幅がunderutilizedされると仮定するビジネスモデルがあります。 ピアツーピアプロトコルは、このビジネスモデルが変化するのを必要とするかもしれません。 最終的に、顧客へのリンクで消費された帯域幅の量に課金することに基づいて多くのサービスプロバイダーがビジネスモデルを持っています。 顧客がマルチキャスト交通を送ることによってソースのリンクにおけるより少ない帯域幅を消費する方法を提供するので、マルチキャストプロトコルはこのビジネスモデルを妨げます、ある他のメカニズムを持っていることのない多くのユニキャストの流れがネットワークにおける、模写の費用をまかなうのをソースにさらに支払うことと対照的に(例えば、ルータCPU、川下では、帯域幅、余分な管理がリンクされます)。 また、マルチキャスト模写の量に基づく交通の源を請求することに基づいてマルチキャストプロトコルはビジネスモデルを複雑にします、請求書が受け取られているまでソースが費用を予測できないかもしれないので。
Similarly, there are many types of benefits, including:
である:同様に、多くのタイプの利益があります。
o Relieving pain: Protocols that drastically lower costs (monetary
or otherwise) that exist prior to deploying the protocol are
easier to show direct benefit from, since they address a burning
need.
o 痛みを消します: プロトコルを配備する前に存在するコスト(通貨の、または、そうでない)を抜本的に下げるプロトコルは直接利益をより示しやすいです、激しい必要性を記述するので。
Thaler & Aboba Informational [Page 8] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[8ページ]のRFC5218プロトコル成功2008年7月
o Enabling new scenarios: Protocols that enable new capabilities,
scenarios, or user experiences can provide significant value,
although the benefit may be harder to realize, as there may be
more risk involved.
o 新しいシナリオを可能にします: 新しい能力、シナリオ、またはユーザー・エクスペリエンスを可能にするプロトコルは重要な値を提供できます、利益はわかるのが、より困難であるかもしれませんが、かかわったより多くのリスクがあるかもしれないので。
o Incremental improvements: Protocols that provide incremental
improvements (e.g., better video quality) generate a small
benefit, and hence can be successful as long as the cost is small.
o 増加の改良: 増加の改良(例えば、より良いビデオ画質)を提供するプロトコルは、わずかな利益を発生させて、費用がわずかである限り、したがって、うまくいっている場合があります。
There are at least two example cases of cost/benefits tradeoffs. In the first case, even upon initial deployment, the benefit outweighs the cost. In the second case, there is an upfront cost that outweighs the initial benefit, but the benefit grows over time (e.g., as more nodes or applications support it). The former model is much easier to get initial deployment, but over time both can be successful. The second model has a danger for the initial deployments, that if others don't deploy the protocol then the initial deployers have lost value, and so they must take on some risk in deploying the protocol.
費用/利益見返りに関する少なくとも2つの例のケースがあります。 初期の展開のときにさえ、利益は費用より重いです。 2番目の場合には、初期の利益を重い最新のコストがありますが、利益は時間がたつにつれて、伸びます(例えば、より多くのノードかアプリケーションがそれを支えるとき)。 元モデルは、初期の展開を得るのがはるかに簡単ですが、時間がたつにつれて、ともにうまくいっている場合があります。 第2代モデルには、初期の展開のための他のものがプロトコルを配備しないなら初期のデプロイヤが価値を失ったので、プロトコルを配備する際にいくつかのリスクを抱えなければならないという危険があります。
Success most easily comes when the natural incentive structure is aligned with the deployment requirements. That is, those who are required to deploy, manage, or configure something are the same as those who gain the most benefit. In summary, it is best if there is significant positive net value at each organization where a change is required.
自然な刺激的な構造が展開要件に並べられるとき、成功は最も容易に来ます。 すなわち、何かを配備するか、管理するか、または構成するのに必要である人は最も多くの利益を獲得する人と同じです。 概要では、重要な上向きの正味価格が変化が必要である各組織にあれば、最も良いです。
2.1.2. Incremental Deployability
2.1.2. 増加のDeployability
A protocol is incrementally deployable if early adopters gain some benefit even though the rest of the Internet does not support the protocol. There are several aspects to this.
プロトコルはインターネットの残りがプロトコルをサポートしませんが、初期採用者が何らかの利益を獲得するなら増加して配備可能することです。 これへのいくつかの局面があります。
Protocols that can be deployed by a single group or team (e.g., intra-domain) have a greater chance of success than those that require cooperation across organizations (or, in the worst case require a "flag day" where everyone has to change simultaneously). For example, protocols that don't require changes to infrastructure (e.g., router changes, service provider support, etc.) have a greater chance of success than ones that do, since less coordination is needed, NAT being a canonical example. Similarly, protocols that provide benefit when only one end changes have a greater chance of success than ones that require both ends of communication to support the protocol.
ただ一つのグループかチーム(例えば、イントラドメイン)が配備できるプロトコルは組織の向こう側に協力を必要とするものよりすばらしい勝算を持っています(最悪の場合には、皆が同時に変化しなければならない「旗の日」を必要としてください)。 例えば、インフラストラクチャ(例えば、ルータ変化、サービスプロバイダーサポートなど)への変化を必要としないプロトコルがするより少ないコーディネートが必要である時から正準な例であるNAT人がすばらしい勝算を持っています。 片端変化だけにプロトコルをサポートするためにコミュニケーションの両端を必要とするものよりすばらしい勝算があるとき、同様に、提供されるプロトコルは利益を得ます。
Finally, protocol updates that are backward compatible with older implementations have a greater chance of success than ones that aren't.
最終的に、より古い実現と互換性があった状態で後方であることのプロトコルアップデートには、ものよりすばらしい勝算があります。
Thaler & Aboba Informational [Page 9] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[9ページ]のRFC5218プロトコル成功2008年7月
2.1.3. Open Code Availability
2.1.3. オープンコードの有用性
Protocols with freely available implementation code have a greater chance of success than protocols without. Often, this is more important than any technical consideration. For example, it can be argued that when deciding between IPv4 and Internetwork Packet Exchange (IPX) [IPX], this was the determining factor, even though, in many ways, IPX was technically superior to IPv4. Similar arguments have been made for the success of RADIUS [RFC2865] over TACACS+ [TACACS+]. See Appendix A for further discussion.
自由に利用可能な実現があるコードにはプロトコルよりすばらしい勝算があるプロトコル。 しばしば、これはどんな技術的問題点よりも重要です。 例えば、IPv4とInternetwork Packet Exchange(IPX)[IPX]についてどちらかに決めるとき、これが決定的要因であったと主張できます、IPXは様々な意味でIPv4より技術的に優れていましたが。 RADIUS[RFC2865]の成功のためにTACACS+[TACACS+]の上で同様の議論をしました。 さらなる議論に関してAppendix Aを見てください。
2.1.4. Freedom from Usage Restrictions
2.1.4. 使用制限から自由
Freedom from usage restrictions means that anyone who wishes to implement or deploy can do so without legal or financial hindrance. Within the IETF, this point often comes up when evaluating between technologies, one of which has known Intellectual Property associated with it. Often the industry chooses the one with no known Intellectual Property, even if it is technically inferior.
使用制限から自由は、実行するか、または配備する願望がそうすることができる人はだれでも法的であるか財政的な妨害なしでそうすることを意味します。 技術の間で評価するとき、IETFの中では、このポイントはしばしば上って来ます。それのひとりは技術のためにそれに関連しているIntellectual Propertyを知っていました。 それが技術的に劣っても、しばしば、産業は知られているIntellectual Propertyなしでものを選びます。
2.1.5. Open Specification Availability
2.1.5. 開いている仕様の有用性
Open specification availability means the protocol specification is made available to anyone who wishes to use it. This is true for all Internet Drafts and RFCs, and it has contributed to the success of protocol specifications developed within or contributed to the IETF.
開いている仕様の有用性は、プロトコル仕様をそれを使用したがっているだれにとっても利用可能にすることを意味します。 すべてのインターネットのDraftsとRFCsに、これは誠実です、そして、それは中で開発されたかIETFに寄付されたプロトコル仕様の成功に貢献しました。
The various aspects of this factor include:
この要素の種々相は:
o World-wide distribution: Is the specification accessible from
anywhere in the world?
o 世界的な分配: どこでも、からアクセス可能な仕様が世界にありますか?
o Unrestricted distribution: Are there no legal restrictions on
getting the specification?
o 無制限な分配: 仕様を得るときの法的規制が全くありませんか?
o Permanence: Does the specification remain even after the creator
is gone?
o 恒久的: 創造者がいなくなった後にさえ仕様は残っていますか?
o Stability: Is there a stable version of the specification that
does not change?
o 安定性: 変化しない仕様の安定したバージョンがありますか?
2.1.6. Open Maintenance Processes
2.1.6. 開いている維持の過程
This factor means that the protocol is maintained by open processes, mechanisms exist for public comment on the protocol, and the protocol maintenance process allows the participation of all constituencies that are affected by the protocol.
この要素は、プロトコルが開いている過程によって維持されることを意味します、そして、メカニズムはプロトコルのパブリックコメントのために存在しています、そして、プロトコル維持の過程はプロトコルで影響を受けるすべての選挙民の参加を許します。
Thaler & Aboba Informational [Page 10] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[10ページ]のRFC5218プロトコル成功2008年7月
2.1.7. Good Technical Design
2.1.7. 良いテクニカル・デザイン
This factor means that the protocol follows good design principles that lead to ease of implementation and interoperability, such as those described in "Architectural Principles of the Internet" [RFC1958]. For example, simplicity, modularity, and robustness to failures are all key design factors. Similarly, clarity in specifications is another aspect of good technical design that facilitates interoperability and ease of implementation. However, experience shows that good technical design has minimal impact on initial success compared with other factors.
この要素は、プロトコルが実装の容易さと「インターネットの建築プリンシプルズ」[RFC1958]で説明されたものなどの相互運用性につながる良い設計原理に従うことを意味します。 例えば、失敗への簡単さ、モジュール方式、および丈夫さはすべて主要な設計要素です。 同様に、仕様に基づく明快は、相互運用性を容易にする良いテクニカル・デザインのもう一つの側面と実装の容易さです。 しかしながら、経験は、良いテクニカル・デザインが初期の成功に他の要素と比べて最小量の影響力を持っているのを示します。
2.2. Wild Success Factors
2.2. ワイルドな成功要素
The following factors do not seem to significantly affect initial success, but can affect whether a protocol becomes wildly successful.
以下の要素は、初期の成功にかなり影響するように思えませんが、プロトコルがむやみやたらに成功しているかどうか影響できます。
2.2.1. Extensible
2.2.1. 広げることができる
Protocols that are extensible are more likely to be wildly successful in terms of being used for purposes outside their original design. An extensible protocol may carry general purpose payloads/options, or may be easy to add a new payload/option type. Such extensibility is desirable for protocols that intend to apply to all purposes (like IP). However, for protocols designed for a specialized purpose, extensibility should be carefully considered before including it.
広げることができるプロトコルは目的にそれらの当初の設計の外に使用されるのにおいてむやみやたらにうまくいくより傾向があります。 広げることができるプロトコルは、汎用のペイロード/オプションを運ぶかもしれないか、または新しいペイロード/オプションタイプを加えるのが簡単であるかもしれません。 すべての目的(IPのような)に適用するつもりであるプロトコルに、そのような伸展性は望ましいです。 しかしながら、専門化している目的のために設計されたプロトコルにおいて、それを含む前に、伸展性は慎重に考えられるべきです。
2.2.2. No Hard Scalability Bound
2.2.2. どんな困難なスケーラビリティも付きませんでした。
Protocols that have no inherent limit near the edge of the originally envisioned scale are more likely to be wildly successful in terms of scale. For example, IPv4 had no inherent limit near its originally envisioned scale; the address space limit was not hit until it was already wildly successful in terms of scale. Another type of inherent limit would be a performance "knee" that causes a meltdown (e.g., a broadcast storm) once a scaling limit is passed.
元々思い描かれたスケールの縁の近くにどんな固有の限界も持っていないプロトコルはスケールでむやみやたらにうまくいくより傾向があります。 例えば、IPv4は元々思い描かれたスケールの近くにどんな固有の限界も持っていませんでした。 それがスケールで既にむやみやたらにうまくいったとき、アドレス空間限界は初めて、打たれました。 別のタイプの固有の限界はスケーリング限界がいったん通過されると炉心溶解(例えば、ブロードキャスト・ストーム)を引き起こす性能「ひざ」でしょう。
2.2.3. Threats Sufficiently Mitigated
2.2.3. 十分緩和された脅威
The more successful a protocol becomes, the more attractive a target it will be. Protocols with security flaws may still become wildly successful provided that they are extensible enough to allow the flaws to be addressed in subsequent revisions. Examples include Secure SHell version 1 (SSHv1) and IEEE 802.11 with WEP. However, the combination of security flaws and limited extensibility tends to be deadly. For example, some early server-based multiplayer games ultimately failed due to insufficient protections against cheating, even though they were initially successful.
プロトコルがうまくいけばうまくいくほど、それが目標であることは、より魅力的です。 それらが欠点がその後の改正で扱われるのを許容するほど広げることができれば、セキュリティー・フローがあるプロトコルはまだむやみやたらに成功しているかもしれません。 例はWEPとSecure SHellバージョン1(SSHv1)とIEEE802.11を含んでいます。 しかしながら、セキュリティー・フローと限られた伸展性の組み合わせは、致命的である傾向があります。 例えば、早めのサーバベースの多人数プレイゲームは結局不正行為することに対する不十分な保護のため失敗しました、それらは初めは、うまくいきましたが。
Thaler & Aboba Informational [Page 11] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[11ページ]のRFC5218プロトコル成功2008年7月
3. Conclusions
3. 結論
The case studies described in Appendix A indicate that the most important initial success factors are filling a real need and being incrementally deployable. When there are competing proposals of comparable benefit and deployability, open specifications and code become significant success factors. Open source availability is initially more important than open specification maintenance.
Appendix Aで説明されたケーススタディは最も重要な初期の成功要素が本当の必要性をいっぱいにして、増加して配布可能することであることを示します。 匹敵する利益とdeployabilityの競争している提案があるとき、開いている仕様とコードは意義深い成功要素になります。 オープンソースの有用性は初めは、開いている仕様メインテナンスより重要です。
In most cases, technical quality was not a primary factor in initial success. Indeed, many successful protocols would not pass IESG review today. Technically inferior proposals can win if they are openly available. Factors that do not seem to be significant in determining initial success (but may affect wild success) include good design, security, and having an open specification maintenance process.
多くの場合、技術的品質は初期の成功の主要な要素ではありませんでした。 本当に、多くのうまくいっているプロトコルは今日、レビューにIESGに合格しないでしょう。 それらがオープンに利用可能であるなら、技術的に劣った提案は得られることができます。 初期の成功(しかし、ワイルドな成功に影響するかもしれない)を決定するのにおいて重要であるように思えない要素は、良いデザインと、セキュリティと、開いている仕様メインテナンスプロセスを持っているのを含んでいます。
Many of the case studies concern protocols originally developed outside the IETF, which the IETF played a role in improving only after initial success was certain. While the IETF focuses on design quality, which is not a factor in determining initial protocol success, once a protocol succeeds, a good technical design may be key to it staying successful, or in dealing with wild success. Allowing extensibility in an initial design enables initial shortcomings to be addressed.
ケーススタディの多くが元々IETFが初期の成功が確かになった後にだけ向上しながら役割を果たしたIETFの外で開発されたプロトコルに関係があります。 IETFがデザイン品質(プロトコルがいったん成功すると初期のプロトコル成功を決定する要素でない)に焦点を合わせる間、うまくいくままである、またはワイルドな成功に対処するのにおいて主要であることで、良いテクニカル・デザインはそれに主要であるかもしれません。 初期のデザインにおける伸展性を許容するのは、初期の短所が扱われるのを可能にします。
Security vulnerabilities do not seem to limit initial success, since vulnerabilities often become interesting to attackers only after the protocol becomes widely deployed enough to become a useful target. Finally, open specification maintenance is not important to initial success since many successful protocols were initially developed outside the IETF or other standards bodies, and were only standardized later.
セキュリティの脆弱性は初期の成功を制限するように思えません、プロトコルが広く役に立つ目標になることができるくらい配布されるようになった後にだけ脆弱性がしばしば攻撃者にとっておもしろくなるので。 最終的に、多くのうまくいっているプロトコルが初めはIETFか他の標準化団体の外で開発されて、後で標準化されただけであるので、開いている仕様メインテナンスは成功に頭文字をつけるために重要ではありません。
In light of our conclusions, we recommend that the following questions be asked when evaluating protocol designs:
私たちの結論の観点から、私たちは、プロトコルデザインを評価するとき、以下の質問が行われることを勧めます:
o Does the protocol exhibit one or more of the critical initial
success factors?
o プロトコルはきわどい初期の成功要素の1つ以上を示しますか?
o Are there implementers who are ready to implement the technology
in ways that are likely to be deployed?
o 配布しそうな方法で技術を実装する準備ができているimplementersがありますか?
o Are there customers (especially high-profile customers) who are
ready to deploy the technology?
o 技術を配布する準備ができている顧客(特に高姿勢の顧客)はいますか?
o Are there potential niches where the technology is compelling?
o 潜在的適所が技術が無視できないところにありますか?
Thaler & Aboba Informational [Page 12] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[12ページ]のRFC5218プロトコル成功2008年7月
o If so, can complexity be removed to reduce cost?
o そうだとすれば、コストを削減するために複雑さを取り除くことができますか?
o Is there a potential killer app? Or can the technology work
underneath existing unmodified applications?
o 潜在的キラー・アプリケーションがありますか? または、技術は下部の存在の変更されていないアプリケーションを扱うことができますか?
o Is the protocol sufficiently extensible to allow potential
deficiencies to be addressed in the future?
o 潜在的欠乏が将来扱われるのを許容するのにおいてプロトコルは十分広げることができますか?
o If it is not known whether the protocol will be successful, should
the market decide first? Or should the IETF work on multiple
alternatives and let the market decide among them? Are there
factors listed in this document that may predict which is more
likely to succeed?
o プロトコルがうまくいくかどうかは知られていないなら、市場が1番目について決めるべきですか? または、IETFは複数の選択肢に取り組んで、それらの中で市場について決めさせるはずですか? どちらが、より成功しそうであるかを予測するかもしれない本書ではリストアップされた要素がありますか?
In the early stages (e.g., BOFs, design of new protocols), evaluating the initial success factors is important in facilitating success. Similarly, efforts to revise unsuccessful protocols should evaluate whether the initial success factors (or enough of them) were present, rather than focusing on wild success, which is not yet a problem. For a revision of a successful protocol, on the other hand, focusing on the wild success factors is more appropriate.
初期段階(例えば、BOFs、新しいプロトコルのデザイン)に、初期の成功要素を評価するのは成功を容易にするのにおいて重要です。 同様に、失敗のプロトコルを改訂する取り組みは、初期の成功要素(または、それらの十分)がしかし、問題でないワイルドな成功に焦点を合わせるよりむしろ存在していたかどうか評価するべきです。 他方では、うまくいっているプロトコルの改正において、ワイルドな成功要素に焦点を合わせるのは、より適切です。
4. Security Considerations
4. セキュリティ問題
This document discusses attributes that affect the success of protocols. It has no specific security implications. Recommendations on security in protocol design can be found in [RFC3552].
このドキュメントはプロトコルの成功に影響する属性について議論します。 それには、どんな特定のセキュリティ意味もありません。 [RFC3552]でプロトコルデザインにおけるセキュリティにおける推薦を見つけることができます。
5. Informative References
5. 有益な参照
[IEEE-802.11] IEEE, "Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications", ANSI/IEEE
Std 802.11, 2007.
[IEEE-802.11]IEEE、「ワイヤレスのLAN媒体アクセス制御(MAC)と物理的な層(PHY)の仕様。」ANSI/IEEE Std802.11、2007
[IMODE] NTT DoCoMo, "i-mode",
<http://www.nttdocomo.com/services/imode/index.html>.
[IMODE]NTTドコモ、「iモード」、<http://www.nttdocomo.com/サービス/imode/index.html>。
[IPX] Novell, "IPX Router Specification", Novell Part
Number 107-000029-001, 1992.
[IPX]ノベル、「IPXルータ仕様」、ノベル部品番号107-000029-001、1992。
[ISO-8879] ISO, "Information processing -- Text and office
systems -- Standard Generalized Markup Language
(SGML)", ISO 8879, 1986.
[ISO-8879]ISO、「情報処理--テキストとオフィス・システム--標準のGeneralized Markup Language(SGML)」ISO8879、1986。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
Thaler & Aboba Informational [Page 13] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[13ページ]のRFC5218プロトコル成功2008年7月
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC0793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit
Ethernet address for transmission on Ethernet
hardware", STD 37, RFC 826, November 1982.
[RFC0826] プラマー、D.、「イーサネットアドレス決議は以下について議定書の中で述べます」。 「または、ネットワーク・プロトコルを変換するのは、イーサネットハードウェアの上でイーサネットがトランスミッションのためのアドレスであると48.bitに扱う」STD37、RFC826、1982年11月。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985.
[RFC0959] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、1985年10月。
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,
June 1988.
[RFC1058] ヘドリック、C.、「ルーティング情報プロトコル」、RFC1058、1988年6月。
[RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson,
D., Torrey, D., and B. Alberti, "The Internet Gopher
Protocol (a distributed document search and retrieval
protocol)", RFC 1436, March 1993.
[RFC1436] Anklesaria、F.、McCahill、M.、リントナー、P.、ジョンソン、D.、トーリー、D.、およびB.アルベルティ、「インターネットゴーファープロトコル(分配されたドキュメント検索と検索プロトコル)」、RFC1436(1993年3月)。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[RFC1661] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup
Language - 2.0", RFC 1866, November 1995.
そして、[RFC1866]バーナーズ・リー、T.、D.コノリー、「2インチ、RFC1866、1995年ハイパーテキストマークアップランゲージ--11月。」
[RFC1958] Carpenter, B., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[RFC1958] 1996年6月の大工、B.、「インターネットの建築プリンシプルズ」RFC1958。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
April 1998.
[RFC2328]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
June 1999.
[RFC2616] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
Thaler & Aboba Informational [Page 14] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[14ページ]のRFC5218プロトコル成功2008年7月
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
[RFC2821] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC3022] SrisureshとP.とK.Egevang、「伝統的なIPネットワークアドレス変換機構(伝統的なNAT)」、RFC3022、2001年1月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing
RFC Text on Security Considerations", BCP 72,
RFC 3552, July 2003.
[RFC3552]レスコラ、E.とB.Korver、「セキュリティ問題に関するテキストをRFCに書くためのガイドライン」BCP72、2003年7月のRFC3552。
[RFC3954] Claise, B., "Cisco Systems NetFlow Services Export
Version 9", RFC 3954, October 2004.
[RFC3954]Claise、B.、「シスコシステムズのNetFlowサービスはバージョン9インチ、RFC3954に2004年10月をエクスポートします」。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)",
RFC 4120, July 2005.
[RFC4120]ヌーマン、C.、ユー、T.、ハートマン、S.、およびK.レイバーン、「ケルベロスネットワーク認証サービス(V5)」、RFC4120 2005年7月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
[RFC4251] YlonenとT.とC.Lonvick、「セキュア・シェル(セキュアシェル (SSH))プロトコルアーキテクチャ」、RFC4251、2006年1月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter、Y.、李、T.、およびS.野兎、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC4271 2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436,
March 2006.
[RFC4436] Aboba、B.、カールソン、J.、およびS.チェーシャー州、「IPv4(DNAv4)でネットワーク付属を見つけます」、RFC4436、2006年3月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B.,
and E. Klein, "Local Network Protection for IPv6",
RFC 4864, May 2007.
[RFC4864] バン・デ・ベルデとG.とハインとT.とDromsとR.とCarpenter、B.とE.クライン、「IPv6"、RFC4864、2007年5月のための企業内情報通信網保護。」
[TACACS+] Carrel, D. and L. Grant, "The TACACS+ Protocol,
Version 1.78", Work in Progress, January 1997.
[TACACS+] 個人閲覧室、D.、およびL.は、「TACACS+プロトコル(バージョン1.78インチ)は進歩、1997年1月に働いています。」と与えます。
Thaler & Aboba Informational [Page 15] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[15ページ]のRFC5218プロトコル成功2008年7月
[WAP] Open Mobile Alliance, "Wireless Application Protocol
Architecture Specification", <http://
www.openmobilealliance.org/tech/affiliates/
LicenseAgreement.asp?DocName=/wap/
wap-210-waparch-20010712-a.pdf>.
[WAP]開いているモバイルAlliance、「ワイヤレス・アプリケーション・プロトコルアーキテクチャ仕様」、<http://www.openmobilealliance.org/技術者/系列/LicenseAgreement.asp--DocNameは/wap/ wap-210-waparch-20010712a.のpdf>と等しいです。
Thaler & Aboba Informational [Page 16] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[16ページ]のRFC5218プロトコル成功2008年7月
Appendix A. Case Studies
付録A.ケーススタディ
In this Appendix, we include several case studies to illustrate the importance of potential success factors. Many other equally good case studies could have been included, but, in the interests of brevity, only a sampling is included here that is sufficient to justify the conclusions in the body of this document.
このAppendixでは、私たちは、潜在的成功要素の重要性を例証するためにいくつかのケーススタディを入れます。 しかし、等しく良いケーススタディが持つことができた多くのもう一方が簡潔さのために含まれていて、このドキュメントのボディーで結論を正当化するために十分な標本抽出だけがここに含まれています。
A.1. HTML/HTTP vs. Gopher and FTP
A.1。 ゴーファーとHTML/HTTP対FTP
A.1.1. Initial Success Factors
A.1.1。 初期の成功要素
Positive net value: HTTP [RFC2616] with HTML [RFC1866] provided substantially more value than Gopher [RFC1436] and FTP [RFC0959]. Among other things, HTML/HTTP provided support for forms, which opened the door for commercial uses of the technology. In this sense, it enabled new scenarios. Furthermore, it only required changes by entities that received benefits; hence, the cost and benefits were aligned.
上向きの正味価格: HTML[RFC1866]があるHTTP[RFC2616]はゴーファー[RFC1436]とFTP[RFC0959]より実質的に多くの価値を提供しました。 特に、HTML/HTTPは形式のサポートを提供しました。(形式は技術の商業用途のためにドアを開けました)。 この意味で、それは新しいシナリオを可能にしました。 その上、利益を受け取った実体で、釣り銭がいました。 したがって、費用と利益は並べられました。
Incremental deployability: Browsers and servers were incrementally deployable, but initial browsers were also backward compatible with existing protocols such as FTP and Gopher.
増加のdeployability: ブラウザとサーバはまた、増加して、配布可能な、しかし、初期のブラウザもFTPやゴーファーなどの既存のプロトコルと互換性があった状態で遅れていたということでした。
Open code availability: Server code was open. Client source code was initially open to academic use only.
オープンコードの有用性: サーバコードは開いていました。 クライアントソースコードは初めは、アカデミックな使用だけに開かれていました。
Restriction-free: Academic use licenses were freely available. HTML encumbrance only surfaced later.
制限なし: 使用が認可するアカデミー会員は自由に手があいています。 HTML障害は後で浮上しただけです。
Open specification availability: Yes.
仕様の有用性を開いてください: はい。
Open maintenance process: Not at first, but eventually. This illustrates that it is not necessary to have an open maintenance process at first to achieve success. The maintenance process becomes important after initial success.
メインテナンスプロセスを開いてください: 結局初めではなく。 これは、初めに成功を収めるために開いているメインテナンスプロセスを持つのが必要でないことを例証します。 メインテナンスプロセスは初期の成功の後に重要になります。
Good technical design: Fair. Initially, there was no support for graphics, HTML was missing many SGML [ISO-8879] features, and HTTP 1.0 had issues with congestion control and proxy support. These sorts of issues would typically prevent IESG approval today. However, they did not prevent the protocol from becoming successful.
良いテクニカル・デザイン: 公正。 初めは、グラフィックスのサポートが全くありませんでした、そして、HTMLは多くのSGML[ISO-8879]機能を逃していました、そして、HTTP1.0には、輻輳制御とプロキシサポートの問題がありました。 これらの種類の問題は今日、IESG承認を通常防ぐでしょう。 しかしながら、彼らは、プロトコルが成功しているのを防ぎませんでした。
Thaler & Aboba Informational [Page 17] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[17ページ]のRFC5218プロトコル成功2008年7月
A.1.2. Wild Success Factors
A.1.2。 ワイルドな成功要素
Extensible: Extensibility was excellent along multiple dimensions, including HTTP, HTML, graphics, forms, Java, JavaScript, etc.
広げることができる: 伸展性はHTTP、HTML、グラフィックス、フォーム、Java、JavaScriptなどを含む複数の寸法に沿って素晴らしかったです。
No hard scalability bound: Excellent. There was no registration process, as there was with Gopher, which allowed it to scale much better.
どんな困難なスケーラビリティも付きませんでした: 素晴らしい。 より良い多くがゴーファー(それを比例させた)と共にあったとき、登録手続が全くありませんでした。
Threats sufficiently mitigated: No. There was initially no support for confidentiality (e.g., protection of credit card numbers), and HTTP 1.0 had cleartext passwords in Basic auth.
脅威は十分緩和しました: いいえ 初めは、秘密性(例えば、クレジットカード番号の保護)のサポートが全くありませんでした、そして、HTTP1.0はBasic authにcleartextパスワードを持っていました。
A.1.3. Discussion
A.1.3。 議論
HTML/HTTP addressed scenarios that no other protocol addressed. Since deployment was easy, the protocol quickly took off. Only after HTML/HTTP became successful did security become an issue. HTML/ HTTP's initial success occurred outside the IETF, although HTTP was later standardized and refined, addressing some of the limitations.
HTML/HTTPは他のどんなプロトコルも扱わなかったシナリオを扱いました。 展開が簡単であったので、プロトコルはすばやく急増しました。 HTML/HTTPが成功していた後にだけセキュリティは問題になりました。 制限のいくつかを扱って、HTTPは、後で標準化されて、洗練されましたが、HTML/HTTPの初期の成功はIETFの外に起こりました。
A.2. IPv4 vs. IPX
A.2。 IPv4対IPX
A.2.1. Initial Success Factors
A.2.1。 初期の成功要素
Positive net value: There were initially many competitors, including IPX, AppleTalk, NetBEUI, OSI, and DECNet. All of them had positive net value. However, NetBEUI and DECNet were not designed for internetworking, which limited scalability and eventually stunted their growth.
上向きの正味価格: IPX、AppleTalk、NetBEUI、OSI、およびDECNetを含んでいて、初めは多くの競争相手がいました。 彼ら皆、には上向きの正味価格がありました。 しかしながら、NetBEUIとDECNetはインターネットワーキングのために設計されませんでした。(それは、スケーラビリティを制限して、結局、それらの成長を妨げました)。
Incremental deployability: None of the competitors (including IPv4) had incremental deployability, although there were few enough nodes that a flag day was manageable at the time.
増加のdeployability: 競争相手(IPv4を含んでいます)のだれも増加のdeployabilityを持っていませんでした、旗の日がそうであったわずかな十分なノードが当時、処理しやすい状態でありましたが。
Open code availability: IPv4 had open code from BSD, whereas IPX did not. Many argue that this was the primary reason for IPv4's success.
オープンコードの有用性: IPXは持っていませんでしたが、IPv4にはBSDからのオープンコードがありました。 多くが、これがIPv4の成功のプライマリ理由であったと主張します。
Restriction-free: Yes for IPv4; No for IPX.
制限なし: IPv4のためにはい。 IPXのためにいいえ。
Open specification availability: Yes for IPv4; No for IPX.
仕様の有用性を開いてください: IPv4のためにはい。 IPXのためにいいえ。
Open maintenance process: Yes for IPv4; No for IPX.
メインテナンスプロセスを開いてください: IPv4のためにはい。 IPXのためにいいえ。
Good technical design: The initial design of IPv4 was fair, but arguably IPX was initially better. Improvements to IPv4 such as DHCP came much later.
良いテクニカル・デザイン: IPv4の初期のデザインは公正でしたが、論証上、IPXは初めは、より良かったです。 DHCPなどのIPv4への改良は後でたくさん来ました。
Thaler & Aboba Informational [Page 18] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[18ページ]のRFC5218プロトコル成功2008年7月
A.2.2. Wild Success Factors
A.2.2。 ワイルドな成功要素
Extensible: Both IPv4 and IPX were extensible to new transports, new link types, and new applications.
広げることができる: IPv4とIPXの両方が新しい輸送、新しいリンク型、および新しいアプリケーションに広げることができました。
No hard scalability bound: Neither had a hard scalability bound close to the design goals. IPX arguably scaled higher before hitting any bound.
どんな困難なスケーラビリティも付きませんでした: どちらも、困難なスケーラビリティはデザイン目標の近くで付いていませんでした。 IPXは論証上どんなバウンドも打つ前より高く比例しました。
Threats sufficiently mitigated: Neither IPv4 nor IPX had threats sufficiently mitigated.
脅威は十分緩和しました: IPv4もIPXも脅威を十分緩和させませんでした。
A.2.3. Discussion
A.2.3。 議論
Initially, it wasn't clear that IPv4 would win. There were also other competitors, such as OSI. However, the Advanced Research Projects Agency (ARPA) funded IPv4 implementation on BSD and this open source initiative led to many others picking up IPv4, which ultimately made a difference in IPv4 succeeding rather than its competitors. Even though IPX initially had a technically superior design, IPv4 succeeded because of its openness.
初めは、IPv4が勝つのは、明確ではありませんでした。 また、OSIなどの他の競争相手がいました。 しかしながら、Advanced Research Projects Agency(ARPA)はBSDでIPv4実装に資金を供給しました、そして、このオープンソースイニシアチブはIPv4を拾っている多くの他のものにつながりました。IPv4は、結局、競争相手よりむしろ成功しながら、IPv4で区別しました。 IPXには、初めは、技術的に優れたデザインがありましたが、IPv4は風通しの良さので成功しました。
A.3. SSH
A.3。 セキュアシェル (SSH)
A.3.1. Initial Success Factors
A.3.1。 初期の成功要素
Positive net value: SSH [RFC4251] provided greater value than competitors. Kerberized telnet required deployment of a Kerberos server. IPsec required a public key infrastructure (PKI) or pre- shared key authentication. While the benefits were comparable, the overall costs of the alternatives were much higher, and they potentially required deployment by entities that did not directly receive benefit. Hence, unlike the alternatives, the cost and benefits of SSH were aligned.
上向きの正味価格: SSH[RFC4251]は競争相手より大きい値を提供しました。 Kerberized telnetはケルベロスサーバの展開を必要としました。IPsecは公開鍵認証基盤(PKI)かあらかじめ共有された主要な認証を必要としました。 利益は匹敵していましたが、代替手段の総合的なコストははるかに高かったです、そして、彼らは直接利益を受け取らなかった実体で潜在的に展開を必要としました。 したがって、代替手段と異なって、SSHの費用と利益は並べられました。
Incremental deployability: Yes, SSH required SSH clients and servers, but did not require a key distribution center (KDC) or credential pre-configuration.
増加のdeployability: はい、SSHはSSHクライアントとサーバを必要としましたが、主要な配送センター(KDC)か資格証明プレ構成は必要としませんでした。
Open code availability: Yes
オープンコードの有用性: はい
Restriction-free: It is unclear whether SSH was truly restriction- free or not.
制限なし: 本当に、SSHには制限がなかったかどうかが、不明瞭です。
Open specification availability: Not at first, but eventually.
仕様の有用性を開いてください: 結局初めではなく。
Open maintenance process: Not at first, but eventually.
メインテナンスプロセスを開いてください: 結局初めではなく。
Thaler & Aboba Informational [Page 19] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[19ページ]のRFC5218プロトコル成功2008年7月
Good technical design: SSHv1 was fair. It had a number of technical issues that were addressed in SSHv2.
良いテクニカル・デザイン: SSHv1は公正でした。 それには、SSHv2で扱われた多くの専門的な問題がありました。
A.3.2. Wild Success Factors
A.3.2。 ワイルドな成功要素
Extensibility: Good. SSH allowed adding new authentication mechanisms.
伸展性: いいぞ。 SSHは新しい認証機構を加えさせました。
No hard scalability bound: SSH had excellent scalability properties.
どんな困難なスケーラビリティも付きませんでした: SSHには、素晴らしいスケーラビリティの特性がありました。
Threats sufficiently mitigated: No. SSHv1 was vulnerable to man-in- the-middle attacks.
脅威は十分緩和しました: いいえ 中の男性にとって、SSHv1が被害を受け易かった、-、-、中央、攻撃。
A.3.3. Discussion
A.3.3。 議論
The "leap of faith" trust model (accept an untrusted certificate the first time you connect) was initially criticized by "experts", but was popular with users. It provided vastly more functionality and didn't require a KDC and so was easy to deploy. These factors made SSH a clear winner.
「盲信」信頼モデル(あなたが初めて接続するとき、信頼されていない証明書を受け入れる)は、初めは「専門家」によって批評されましたが、ユーザにポピュラーでした。 展開するのは、広大により多くの機能性を提供して、KDCを必要としなかったので、簡単でした。 これらの要素は完勝者にSSHを作りました。
A.4. Inter-Domain IP Multicast vs. Application Overlays
A.4。 相互ドメインIPマルチキャスト対アプリケーションオーバレイ
We now look at a protocol that has not been successful (i.e., has not met its original design goals) after a long period of time has passed. Note that this discussion applies only to inter-domain multicast, not intra-domain or intra-subnet multicast.
私たちは今、長日月が経過した後にうまくいっていない(すなわち、当初の設計目標を達成していません)プロトコルを見ます。 この議論がイントラドメインかイントラサブネットマルチキャストではなく、相互ドメインマルチキャストだけに適用されることに注意してください。
A.4.1. Initial Success Factors
A.4.1。 初期の成功要素
Positive net value: Unclear. When many receivers of the same stream exist, the benefit relieves pain near the sender, and in some cases enables new scenarios. However, when few receivers exist, the benefits are only incremental improvements when compared with multiple streams. While there was positive value in bandwidth savings, this was offset by the lack of viable business models, and lack of tools. Hence, the costs generally outweighed the benefits.
上向きの正味価格: 不明瞭。 同じストリームの多くの受信機が存在していると、利益は、送付者の近くで痛みを消して、いくつかの場合、新しいシナリオを可能にします。 しかしながら、わずかな受信機しか存在しないときだけ、複数のストリームと比べると、利益は増加の改良です。帯域幅貯蓄には正の数があった間、これは実行可能なビジネスモデルの不足、およびツールの不足によって相殺されました。 したがって、一般に、コストは利益より重かったです。
Furthermore, the costs are not necessarily aligned with the benefits. Inter-domain Multicast requires changes by (at least) applications, hosts, and routers. However, it is the applications that get the primary benefit. For application layer overlaps, on the other hand, only the applications need to change, and hence the cost is lower (and so are the benefits), and cost and benefits are aligned.
その上、コストは必ず利益に並べられるというわけではありません。 相互ドメインMulticastは(少なくとも)アプリケーション、ホスト、およびルータで釣り銭がいます。 しかしながら、それは主要便益を得るアプリケーションです。 応用層オーバラップのために、他方では、アプリケーションだけが、変化する必要があります、そして、したがって、費用は低いです、そして、(利益もそうです)費用と利益は並べられます。
Incremental deployability: Poor for inter-domain multicast, since it required every router in the end-to-end path between a source and any receiver to support multicast. This severely limited the
増加のdeployability: 相互ドメインマルチキャストのためのマルチキャストをサポートするのがソースとどんな受信機の間の終わらせる終わりのあらゆるルータ経路を必要として以来の貧乏人。 これは厳しく制限しました。
Thaler & Aboba Informational [Page 20] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[20ページ]のRFC5218プロトコル成功2008年7月
deployability of native multicast. Initially, the strategy was to use an overlay network (the Multicast Backbone (MBone)) to work around this. However, the overlay network eventually suffered from performance problems at high fan-out points, and so adding another node required more coordination with other organizations to find someone that was not overloaded and agreed to forward traffic on behalf of the new node.
ネイティブのマルチキャストのdeployability。 初めは、戦略はこれの周りで働くのに、オーバレイネットワーク(Multicast Backbone(MBone))を使用することでした。 しかしながら、オーバレイネットワークは結局、別のノードが、積みすぎられなかっただれかを見つけるために他の組織による、より多くのコーディネートを必要として、新しいノードを代表してトラフィックを進めるのに同意したようにポイントを四方八方に広げるので加えている高値で性能問題が欠点でした。
Incremental deployability was good for application-layer overlays, since only the applications need to change. However, benefit only exists when the sender(s) and receivers both support the overlay mechanism.
アプリケーションだけが、変化する必要があるので、応用層オーバレイに、増加のdeployabilityは良かったです。 しかしながら、送付者と受信機がともにオーバレイメカニズムをサポートするときだけ、利益は存在しています。
Open code availability: Yes.
オープンコードの有用性: はい。
Restriction-free: Yes.
制限なし: はい。
Open specification availability: Yes for inter-domain multicast. Application-layer overlays are not standardized, but left to each application.
仕様の有用性を開いてください: 相互ドメインマルチキャストのためにはい。 応用層オーバレイは、標準化されませんが、各アプリケーションに残されます。
Open maintenance process: Yes for inter-domain multicast. Application-layer overlays are not standardized, but left to each application.
メインテナンスプロセスを開いてください: 相互ドメインマルチキャストのためにはい。 応用層オーバレイは、標準化されませんが、各アプリケーションに残されます。
Good technical design: This is debatable for inter-domain multicast. In many respects, the technical design is very efficient. In other respects, it results in per-connection state in all intermediate routers, which is questionable at best. Application-layer overlays do not have the disadvantage, but receive a smaller benefit.
良いテクニカル・デザイン: 相互ドメインマルチキャストにおいて、これは論争の余地があります。 あらゆる点で、テクニカル・デザインは非常に効率的です。 その他の点では、それはすべての中間的ルータにおける1接続あたりの状態をもたらします。(それは、せいぜい疑わしいです)。 応用層オーバレイには、不都合がありませんが、よりわずかな利益を受け取ってください。
A.4.2. Wild Success Factors
A.4.2。 ワイルドな成功要素
Extensible: Yes.
広げることができる: はい。
No hard scalability bound: Inter-domain multicast had scalability issues in terms of number of groups, and in terms of number of sources. It scaled extremely well in terms of number of receivers. Application-layer overlays scale well in all dimensions, except that they do not scale as well as inter-domain multicast in terms of bandwidth since they still result in multiple streams over the same link.
どんな困難なスケーラビリティも付きませんでした: 相互ドメインマルチキャストには、グループの数、およびソースの数に関してスケーラビリティ問題がありました。 それは受信機の数に関して非常によく比例しました。 応用層オーバレイは上手にすべての寸法を計量します、同じリンクの上にまだ複数のストリームをもたらしているので帯域幅に関する相互ドメインマルチキャストと同様に比例しないのを除いて。
Threats sufficiently mitigated: No for inter-domain-multicast, since untrusted hosts can create state in intermediate routers along an entire path. Better for application-layer multicast.
脅威は十分緩和しました: 信頼されていないホストが全体の経路に沿って中間的ルータで状態を創設できるので、相互ドメインマルチキャストのためにいいえ。 応用層マルチキャストにおいて、より良いです。
Thaler & Aboba Informational [Page 21] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[21ページ]のRFC5218プロトコル成功2008年7月
A.4.3. Discussion
A.4.3。 議論
Because the benefits weren't enough to outweigh the costs for entities (service providers and application developers) to use it, instead the industry has tended to choose application overlays with replicated unicast.
利益が実体(サービスプロバイダーとアプリケーション開発者)がそれを使用するコストを重いように十分でなかったので、代わりに、産業は、模写されたユニキャストがあるアプリケーションオーバレイを選ぶ傾向がありました。
A.5. Wireless Application Protocol (WAP)
A.5。 ワイヤレス・アプリケーション・プロトコル(ワップ)
The Wireless Application Protocol (WAP) [WAP] is another protocol that has not been successful, but is worth comparing against other protocols.
ワイヤレス・アプリケーション・プロトコル(WAP)[WAP]は、別のうまくいっていないプロトコルですが、比較する他のプロトコルに対して価値があります。
A.5.1. Initial Success Factors
A.5.1。 初期の成功要素
Positive net value: Compared to competitors such as HTTP/TCP/IP, and NTT DoCoMo's i-mode [IMODE], the relative value of WAP is unclear. It suffered from a poor experience, and a lack of tools.
上向きの正味価格: HTTP/TCP/IP、およびNTTドコモのiモード[IMODE]などの競争相手と比べて、WAPの相対的価値は不明瞭です。 それは不十分な経験、およびツールの不足に苦しみました。
Incremental deployability: Poor. WAP required a WAP-to-HTTP proxy in the service provider and WAP support in phones; adding a new site often required participation by the service provider.
増加のdeployability: 貧しい。 WAPは電話でのサービスプロバイダーとWAPサポートでWAPからHTTPへのプロキシを必要としました。 新しいサイトを加えるのはしばしばサービスプロバイダーによる参加を必要としました。
Open code availability: No.
オープンコードの有用性: いいえ
Restriction-free: No. WAP has two patents with royalties required.
制限なし: いいえ WAPには、ロイヤリティが必要であることの2つの特許があります。
Open specification availability: No.
仕様の有用性を開いてください: いいえ
Open maintenance process: No, there was a US$27000 entrance fee.
メインテナンスプロセスを開いてください: いいえ、27000USドルの入学金がありました。
Good technical design: No, a common complaint was that WAP was underspecified and hence interoperability was difficult.
良いテクニカル・デザイン: いいえ、一般的な苦情はWAPがunderspecifiedされたということでした、そして、したがって、相互運用性は難しかったです。
A.5.2. Wild Success Factors
A.5.2。 ワイルドな成功要素
Extensible: Unknown.
広げることができる: 未知。
No hard scalability bound: Excellent.
どんな困難なスケーラビリティも付きませんでした: 素晴らしい。
Threats sufficiently mitigated: Unknown.
脅威は十分緩和しました: 未知。
A.5.3. Discussion
A.5.3。 議論
There were a number of close competitors to WAP. Incremental deployability was easier with the competitors, and the restrictions on code and specification access were significant factors that hindered its ability to succeed.
WAPへの多くの近い競争相手がいました。 競争相手では増加のdeployabilityは、より簡単でした、そして、コードと仕様アクセスの制限は成功する性能を妨げた特筆すべき要因でした。
Thaler & Aboba Informational [Page 22] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[22ページ]のRFC5218プロトコル成功2008年7月
A.6. Wired Equivalent Privacy (WEP)
A.6。 WEP(WEP)
WEP is a part of the IEEE 802.11 standard [IEEE-802.11], which succeeded in being widely deployed in spite of its faults.
WEPはIEEE802.11規格[IEEE-802.11]の一部です。(それは、せいにもかかわらず、広く配布されるのに成功しました)。
A.6.1. Initial Success Factors
A.6.1。 初期の成功要素
Positive net value: Yes. WEP provided security when there was no alternative, and it only required changes by entities that got benefit.
上向きの正味価格: はい。 代替手段が全くなかったとき、WEPはセキュリティを提供しました、そして、それだけが利益を得た実体で釣り銭がいました。
Incremental deployability: Yes. Although one needed to configure both the access point and stations, each wireless network could independently deploy WEP.
増加のdeployability: はい。 ものは、アクセスポイントとステーションの両方を構成する必要がありましたが、各ワイヤレス・ネットワークは独自にWEPを配布することができました。
Open code availability: Essentially no, because of Rivest Cipher 4 (RC4).
オープンコードの有用性: Rivest Cipher4のために本質的にはいいえ(RC4)。
Restriction-free: No for RC4, but otherwise yes.
制限なし: いいえが、RC4のためにさもなければ、はい。
Open specification availability: No for RC4, but otherwise yes.
仕様の有用性を開いてください: いいえが、RC4のためにさもなければ、はい。
Open maintenance process: Yes.
メインテナンスプロセスを開いてください: はい。
Good technical design: No, WEP had an inappropriate use of RC4.
良いテクニカル・デザイン: いいえ、WEPには、RC4の誤用がありました。
A.6.2. Wild Success Factors
A.6.2。 ワイルドな成功要素
Extensible: IEEE 802.11 was extensible enough to enable development of replacements for WEP. However, WEP itself was not extensible.
広げることができる: IEEE802.11はWEPとの交換の開発を可能にするほど広げることができました。 しかしながら、WEP自身は広げることができませんでした。
No hard scalability bound: No.
どんな困難なスケーラビリティも付きませんでした: いいえ
Threats sufficiently mitigated: No.
脅威は十分緩和しました: いいえ
A.6.3. Discussion
A.6.3。 議論
Even though WEP was not completely open and restriction free, and did not have a good technical design, it still became successful because it was incrementally deployable and it provided significant value when there was no alternative. This again shows that value and deployability are more significant success factors than technical design or openness, particularly when no alternatives exist.
WEPが完全に開いたというわけではなくて、制限は、良いテクニカル・デザインを解放して、持っていませんが、増加して配布可能することであったのでまだ成功していました、そして、代替手段が全くなかったとき、重要な値を提供しました。 これは、値とdeployabilityがテクニカル・デザインか風通しの良いより重要な成功要素であることを再び示します、特に代替手段が全く存在していないと。
Thaler & Aboba Informational [Page 23] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[23ページ]のRFC5218プロトコル成功2008年7月
A.7. RADIUS vs. TACACS+
A.7。 半径対TACACS+
A.7.1. Initial Success Factors
A.7.1。 初期の成功要素
Positive net value: Yes for both, and it only required changes by entities that got benefit.
上向きの正味価格: 両方のためにはい、それだけが利益を得た実体で釣り銭がいました。
Incremental deployability: Yes for both (just change clients and servers).
増加のdeployability: 両方(まさしく変化クライアントとサーバ)のためにはい。
Open code availability: Yes for RADIUS; initially no for TACACS+, but eventually yes.
オープンコードの有用性: 半径のためにはい。 初めは、はいようにしかし、TACACS+、結局、いいえ。
Restriction-free: Yes for RADIUS; unclear for TACACS+.
制限なし: 半径のためにはい。 TACACS+において、不明瞭です。
Open specification availability: Yes for RADIUS; initially no for TACACS+, but eventually yes.
仕様の有用性を開いてください: 半径のためにはい。 初めは、はいようにしかし、TACACS+、結局、いいえ。
Open maintenance process: Initially no for RADIUS, but eventually yes. No for TACACS+.
メインテナンスプロセスを開いてください: 初めは、はいようにしかし、RADIUS、結局、いいえ。 TACACS+のためにいいえ。
Good technical design: Fair for RADIUS (there was no confidentiality support, and no authentication of Access Requests; it had home grown ciphersuites based on MD5). Good for TACACS+.
良いテクニカル・デザイン: RADIUS(秘密性サポートがなく、およびAccess Requestsの認証が全くありませんでした; それで、ホームの成長しているciphersuitesはMD5に基づいていた)において、公正です。 TACACS+がいいぞ。
A.7.2. Wild Success Factors
A.7.2。 ワイルドな成功要素
Extensible: Yes for both.
広げることができる: 両方のためにはい。
No hard scalability bound: Excellent for RADIUS (UDP-based); good for TACACS+ (TCP-based).
どんな困難なスケーラビリティも付きませんでした: 半径における素晴らしさ(UDPベースの)。 TACACS+(TCPベースの)がいいぞ。
Threats sufficiently mitigated: No for RADIUS (no support for confidentiality, existing implementations are vulnerable to dictionary attacks, use of MD5 now vulnerable to collisions). TACACS+ was better since it supported encryption.
脅威は十分緩和しました: RADIUS(秘密性のどんなサポート、既存の実装は辞書攻撃に被害を受け易くはありません、現在衝突に被害を受け易いMD5の使用)のためにいいえ。 暗号化をサポートしたので、TACACS+は、より良かったです。
A.7.3. Discussion
A.7.3。 議論
Since both provided positive net value and were incrementally deployable, those factors were not significant. Even though TACACS+ had a better technical design in most respects, and eventually provided openly available specifications and source code, the fact that RADIUS had an open maintenance process as well as openly available specifications and source code early on was the determining factor. This again shows that having a better technical design is less important in determining success than other factors.
配布可能、両方が上向きの正味価格を提供して、増加して提供したので、それらの要素は重要ではありませんでした。 TACACSですが、+はほとんどの結局提供されたあいさつ、オープンに利用可能な仕様、およびソースコードで、より良いテクニカル・デザインを持って、早くから、RADIUSにはオープンに利用可能な仕様とソースコードと同様に開いているメインテナンスプロセスがあったという事実は決定的要因でした。 これは、より良いテクニカル・デザインを持っているのが他の要素ほど成功を決定するのにおいて重要でないことを再び示します。
Thaler & Aboba Informational [Page 24] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[24ページ]のRFC5218プロトコル成功2008年7月
A.8. Network Address Translators (NATs)
A.8。 ネットワーク・アドレス翻訳者(NATs)
Although NAT is not, strictly speaking, a "protocol" per se, but rather a "mechanism" or "algorithm", we include a case study since there are many mechanisms that only require a single entity to change to reap the benefit (TCP congestion control algorithms are another example in this class), and it is important to include this class of mechanisms in the discussion since it exemplifies a key point in the discussion of incremental deployability.
NATは、厳密に言うとむしろそういうものの「プロトコル」、「メカニズム」または「アルゴリズム」であるだけではありませんが、単一体が成果を得るために変化するのを必要とするだけである多くのメカニズムがあるので(TCP輻輳制御アルゴリズムはこのクラスで別の例です)、私たちはケーススタディを入れます、そして、増加のdeployabilityの議論における要点を例示するので、議論にこのクラスのメカニズムを含んでいるのは重要です。
A.8.1. Initial Success Factors
A.8.1。 初期の成功要素
Positive net value: Yes. NATs provided the ability to connect multiple devices when only a limited number of addresses were available, and also provided a (limited) security boundary as a side effect. Hence, it both relieved pain involved with acquiring multiple addresses, as well as enabled new scenarios. Finally, it only required deployment by the entity that got the benefit.
上向きの正味価格: はい。 NATsは限られた数のアドレスだけが利用可能であったときに複数のデバイスを接続する能力を提供して、また、副作用として(制限される)のセキュリティ境界を提供しました。 したがって、それは、複数のアドレスを習得するのにかかわる痛みを救って、新しいシナリオを可能にしました。 最終的に、それは利益を得た実体で展開を必要としただけです。
Incremental deployability: Yes. One could deploy a NAT without coordinating with anyone else, including a service provider.
増加のdeployability: はい。 サービスプロバイダーを含んでいて、ほかにだれと共にも調整しないで、1つはNATを配布するかもしれません。
Open code availability: Yes.
オープンコードの有用性: はい。
Restriction-free: Yes at first (patents subsequently surfaced).
制限なし: 初めに(次に表面を仕上げられた特許)、はい。
Open specification availability: Yes.
仕様の有用性を開いてください: はい。
Open maintenance process: Yes.
メインテナンスプロセスを開いてください: はい。
Good technical design: Fair. NAT functionality was underspecified, leading to unpredictable behavior in general. In addition, NATs caused problems for certain classes of applications.
良いテクニカル・デザイン: 公正。 一般に、予測できない振舞いに通じて、NATの機能性はunderspecifiedされました。 さらに、NATsはあるクラスのアプリケーションのために問題を起こしました。
A.8.2. Wild Success Factors
A.8.2。 ワイルドな成功要素
Extensible: Fair. NATs supported some but not all UDP and TCP applications. Adding application layer gateway functionality was difficult.
広げることができる: 公正。 NATsはすべてのUDPとTCPではなく、いくつかにアプリケーションをサポートしました。 応用層ゲートウェイの機能性を加えるのは難しかったです。
No hard scalability bound: Good. There is a scalability bound (number of ports available), but none near the original design goals.
どんな困難なスケーラビリティも付きませんでした: いいぞ。 制限された(有効なポートの数)スケーラビリティがありますが、オリジナルにおけるなにも目標を設計しません。
Threats sufficiently mitigated: Yes.
脅威は十分緩和しました: はい。
Thaler & Aboba Informational [Page 25] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[25ページ]のRFC5218プロトコル成功2008年7月
A.8.3. Discussion
A.8.3。 議論
The absence of an unambiguous specification was not a hindrance to initial success since the test cases weren't well defined; therefore, each implementation could decide for itself what scenarios it would handle correctly.
明白な仕様の欠如はテストケースがよく定義されなかったので成功に頭文字をつける妨害ではありませんでした。 したがって、各実装は、それ自体のためにそれが正しくどんなシナリオを扱うかを決めるかもしれません。
Even with its technical problems, NAT succeeded because of the value it provided. Again, this shows that the industry is willing to accept technically problematic solutions when there is no alternative and the technology is easy to deploy.
技術的問題があっても、NATはそれが提供した値で成功しました。 一方、これは、産業が、代替手段が全くなくて、技術は配布しやすいとき、技術的に問題の多いソリューションを受け入れても構わないと思っているのを示します。
Indeed, NAT became wildly successful by being used for additional purposes [RFC4864], and to a large scale including multiple levels of NATs in places.
本当に、追加目的[RFC4864]と、そして、場所のNATsの複数のレベルを含む大規模に使用されることによって、NATはむやみやたらに成功していました。
Appendix B. IAB Members at the Time of This Writing
この書くこと時点の付録B.IABメンバー
Loa Andersson Leslie Daigle Elwyn Davies Kevin Fall Russ Housley Olaf Kolkman Barry Leiba Kurtis Lindqvist Danny McPherson David Oran Eric Rescorla Dave Thaler Lixia Zhang
LoaアンデションレスリーDaigle ElwynデイヴィースケビンFallラス・Housleyオラフ・Kolkman Barry Leibaカーティス・リンクヴィスト・ダニー・マクファーソンデヴィッド・オラン・エリック・レスコラ・デーヴ・ターレルLixiaチャン
Thaler & Aboba Informational [Page 26] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[26ページ]のRFC5218プロトコル成功2008年7月
Authors' Addresses
作者のアドレス
Dave Thaler IAB One Microsoft Way Redmond, WA 98052 USA
デーヴターレルIAB1マイクロソフト、道のワシントン98052レッドモンド(米国)
Phone: +1 425 703 8835 EMail: dthaler@microsoft.com
以下に電話をしてください。 +1 8835年の425 703メール: dthaler@microsoft.com
Bernard Aboba IAB One Microsoft Way Redmond, WA 98052 USA
バーナードAboba IAB1マイクロソフト、道のワシントン98052レッドモンド(米国)
Phone: +1 425 706 6605 EMail: bernarda@microsoft.com
以下に電話をしてください。 +1 6605年の425 706メール: bernarda@microsoft.com
Thaler & Aboba Informational [Page 27] RFC 5218 Protocol Success July 2008
ターレルとAbobaの情報[27ページ]のRFC5218プロトコル成功2008年7月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Thaler & Aboba Informational [Page 28]
ターレルでAboba情報です。[28ページ]
一覧
スポンサーリンク
