Network Working Group D. Thaler
Request for Comments: 5218 B. Aboba
Category: Informational IAB
July 2008
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
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
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）の目標の一つは成功し、その実装と展開目標を達成するためのプロトコルを定義することです。ケーススタディに基づいて、この文書は、プロトコル設計の成功や失敗に影響を与える要因のいくつかを識別します。この文書は、次の観客に使用されるであろうことが期待されます。
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誰もが、プロトコルの実験の成功を評価します。
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.
助けまたはプロトコルの成功を妨げる要因を議論では、まず私たちが「成功」で何を意味するかを定義する必要があります。それは、元の目標を満たしている場合、プロトコルは、成功したと今でも広く展開されていないことができます。しかし、この文書では、我々は成功したプロトコルの両方がその本来の目的を満たしており、広く展開されている1であると考えています。 「広く展開されている」「ドメイン間」を意味しないことに注意してください。成功したプロトコル（例えば、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]、SIP [RFC3261]。
Intra-domain: ARP [RFC0826], PPP [RFC1661], DHCP [RFC2131], RIP [RFC1058], OSPF [RFC2328], Kerberos [RFC4120], NAT [RFC3022].
イントラドメイン：ARP [RFC0826]、PPP [RFC1661]、DHCP [RFC2131]、[RFC1058]をRIP、OSPF [RFC2328]、ケルベロス[RFC4120]、NAT [RFC3022]。
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は、グラフこれらの概念を示しています。
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".
これらの指標によると、「成功した」プロトコルは、その本来の目的のためにと、本来のスケールで使用されるものです。 「乱暴に成功した」プロトコルがはるかに規模の面で、目的の観点から（遠く初期設計を超えてのシナリオで使用されている）、その本来の目的を超えて、またはその両方（当初想定よりもはるかに大きな規模で展開されています）。つまり、その境界を草に覆われており、「野生に」出てあえてしている、です。
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 (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.
成功したプロトコルの別の例は、ARPです。本来、より一般的な目的のために意図される（すなわち、層アドレスをリンクするネットワーク層アドレスの解決に関係なく、メディアタイプやネットワーク層プロトコルの）、ARPが広く使用の狭い範囲のために配備された（のIPv4の解像度は、イーサネットMACアドレスにアドレス）しかし、そのようなネットワーク接続（IPv4の検出ネットワーク接続（DNAv4）[RFC4436]）を検出するような他の用途のために採用されました。また、当初の予想よりもIPv4のように、ARPは、（マシンの数の点ではなく、同じサブネット上の番号）はるかに大きな規模で展開されています。
Scale ^ +-------------------+
| | Actual Deployment |
| | |
| | | Original Design Space
| | +-------------+--------------+
| | |(IP/Ethernet)|(Non-IP) |
| |(DNA)| | |
| | | |(Non-Ethernet)|
| | | | |
<-----------------------------------------------> Purpose
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実装者は、全体的なプロトコルの動作と不変量への影響を完全に理解することなく、設計上の制限を回避するための機能を追加または変更しようとすることができます。
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.
乱暴に成功したプロトコルは、攻撃やスケーリング制限の結果として崩壊、「成功によって死」することが脆弱です。
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低い導入コストで「キラーアプリ」を提供します。この戦略は、どれも前に存在していない需要を生成するために使用することができます。例えば、付録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既存の変更されていないアプリケーションのために価値を提供します。これは、使用は、すぐプロトコルが展開されているとして存在し、そのため、利益がすぐに実現することができるようにすることによって、鶏と卵の問題を解決します。例えば、付録A.6でのWired Equivalentプライバシー（WEP）ケーススタディを参照してください。
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それは成功するのが最も簡単ですエリアへの目的および/または範囲を狭くすることで、複雑さとコストを削減します。これは、狭い目的のために必要とされていない複雑さを取り除くことが可能になります。複雑さを除去して得られたコストが利益に比べて非常に低くてもよい場合に実装および配備のコストを低減します。例えば、リンクスコープのマルチキャストは、（付録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.
私たちが見るように、彼らは直接トップ成功要因を標的とすることから、このような戦略は、多くの場合、成功しています。
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）のシリーズによって提案されました。
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 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ハードウェアコスト：ハードウェアの変更を必要としないプロトコルが行うものよりも展開が容易です。オーバーレイネットワークは、ハードウェアの変更を必要としないようにする一つの方法です。しかし、多くの場合、ハードウェアの更新も、その機能のみのソフトウェアに提供することができるプロトコルのために必要とされます。ベンダーは、多くの場合のみ、唯一の新しいハードウェア上で実行可能コードツリーの後の枝の中に新しい機能を実装します。その結果、ハードウェアのアップグレードコストを回避するための最も安全な方法は、既存のハードウェアとソフトウェアの両方との後方互換性のために設計することです。
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 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のビジネスの依存関係：ビジネスモデルへの変更を必要としないプロトコル行うものより導入しやすくなります（実装者またはデプロイヤのためかどうか）。そこ課金および会計システムおよび関連要員の再教育を変えることに関連するコストがあり、加えて、以前のビジネスモデルがベースとされた仮定は変更されることがあります。例えば、いくつかの時間前に多くのサービスプロバイダーは、マシンはすべての時間を接続されていなかったと仮定して、ダイヤルアップを中心に構築されたビジネスモデルを持っていました。常に上に所望の接続プロトコルは、ネットワークが常時オンのために最適化されていなかったので、変更するビジネスモデルを必要としていました。同様に、いくつかのサービスプロバイダは、アップストリーム帯域幅が十分に活用されていないことを前提としたビジネスモデルを持っています。ピア・ツー・ピア・プロトコルは、このビジネスモデルを変更する必要があります。最後に、多くのサービスプロバイダは、顧客へのリンクを消費する帯域幅の量のための充電に基づいてビジネスモデルを持っています。彼らは、レプリケーションのコストをカバーするためにいくつかの他の機構を有するせずに、多くのユニキャストストリームを供給するために多くを支払うとは対照的に、顧客は、マルチキャストトラフィックを送信することにより、ソースリンクに少ない帯域幅を消費するための方法を提供するので、マルチキャストプロトコルは、このビジネスモデルに干渉するネットワーク内（例えば、ルータの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 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 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のモデルは、他の人が、プロトコルを展開していない場合は初期デプロイヤは値を失っている、とそう、彼らはプロトコルを展開中、いくつかのリスクを取る必要があることを、初期導入のための危険があります。
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.
自然のインセンティブ構造が導入要件に合わせているときの成功は、最も簡単に来ます。これは、展開、管理、または何かを構成するために必要とされる人たちは、最も利益を得る人たちと同じである、です。変更が必要とされている各組織で有意な正のネット値がある場合に要約すると、それがベストです。
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.
最後に、古い実装との後方互換性のあるプロトコルのアップデートはありませんものよりも成功の大きなチャンスを持っています。
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およびインターネットワークパケット交換（IPX）[IPX]の間に決定するとき、これは多くの点で、IPXは、IPv4に技術的に優れていた、としても、決定要因であったと主張することができます。同様の議論は、TACACS +を超えるRADIUS [RFC2865] [TACACS +]の成功のために作られてきました。さらなる議論については、付録Aを参照してください。
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の中で、この時点では、多くの場合、それに関連する知的財産を知っていたそのうちの一つの技術、間を評価するときにアップします。多くの場合、業界では、それが技術的に劣っていても、いない既知の知的財産権を持つものを選択します。
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.
オープン仕様の可用性は、プロトコル仕様は、それを使用したい誰にでも利用できるようになることを意味します。これは、すべてのインターネットドラフトやRFCの真実であり、それは、プロトコル仕様内で開発または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?
安定○：変化しません仕様の安定版はありますか？
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.
この要因は、プロトコルは、オープンプロセスによって維持されることを意味し、機構は、プロトコル上のパブリックコメントのために存在し、及びプロトコルメンテナンスプロセスは、プロトコルによって影響を受けるすべての選挙の参加を可能にします。
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]に記載されているようなインプリメンテーションと相互運用の容易さをもたらす良好な設計原理を、以下のことを意味します。例えば、障害へのシンプルさ、モジュール性、および堅牢性は、すべての重要な設計要素です。同様に、仕様の明確さは、実装の相互運用性と使いやすさを促進する優れた技術的な設計のもう一つの側面です。しかし、経験は良い技術的なデザインは、他の要因に比べて初期の成功への影響は最小限に抑えられていることを示しています。
The following factors do not seem to significantly affect initial success, but can affect whether a protocol becomes wildly successful.
以下の要因が大幅に初期の成功に影響を与えていないように見えますが、プロトコルは乱暴に成功するかどうかに影響を与えることができます。
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など）すべての目的に適用する予定のプロトコルのために望ましいです。しかし、専門的な目的のために設計されたプロトコルのために、拡張性は慎重にそれを含めて前に検討すべきです。
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がその元々想定される規模の近くには固有制限がありませんでした。それは規模の面ですでに乱暴に成功したまではアドレス空間の制限がヒットしませんでした。固有の限界の別のタイプは、スケーリング限界が渡されるとメルトダウン（例えば、ブロードキャスト・ストーム）を引き起こすパフォーマンス「膝」であろう。
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とセキュアシェルバージョン1（SSHv1）およびIEEE 802.11を含みます。しかし、セキュリティ上の欠陥と限られた拡張性の組み合わせは致命的になる傾向があります。例えば、いくつかの初期のサーバーベースのマルチプレイヤーゲームは最終的に、彼らが最初に成功したにも関わらず、原因不正行為に対する不十分な保護に失敗しました。
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.
付録Aで説明したケーススタディでは、最も重要な初期の成功要因は、実際のニーズを満たし、インクリメンタルに展開されていることを示しています。同等の利益と展開性の競合する提案がある場合は、オープンな仕様とコードが重要な成功要因になります。オープンソースの可用性は、最初はオープン仕様の維持よりも重要です。
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は、プロトコルの展示の重要な初期の成功要因の一つ以上をしていますか？
o Are there implementers who are ready to implement the technology in ways that are likely to be deployed?
O展開される可能性が高い方法で技術を実装する準備ができている実装はありますか？
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 If so, can complexity be removed to reduce cost?
O技術が説得力があるが潜在的なニッチがありますか？ 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、市場が最初に決める必要がありますか？または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、新しいプロトコルの設計）、初期の成功要因を評価することは、成功を促進する上で重要です。同様に、失敗したプロトコルを改訂するための努力は、初期の成功要因（またはそれらの十分な）かどうかを評価する必要があり、むしろ、まだ問題ではありません野生の成功を、に焦点を当てよりも、存在していました。成功したプロトコルの改正については、他の一方で、野生の成功要因に焦点を当てたことは、より適切です。
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]で見つけることができます。
[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規格802.11、2007。
[IMODE] NTT DoCoMo, "i-mode", <http://www.nttdocomo.com/services/imode/index.html>.
[IMODE] NTTドコモ、 "iモード"、<http://www.nttdocomo.com/services/imode/index.html>。
[IPX] Novell, "IPX Router Specification", Novell Part Number 107-000029-001, 1992.
[IPX]ノベル、 "IPXルーター仕様"、Novellの部品番号107-000029-001、1992。
[ISO-8879] ISO, "Information processing -- Text and office systems -- Standard Generalized Markup Language (SGML)", ISO 8879, 1986.
[ISO-8879] ISO、 "情報処理 - テキストとオフィスシステム - 標準一般化マークアップ言語（SGML）"、ISO 8879、1986。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、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ビットに、ネットワーク・プロトコル・アドレス変換」、STD 37、RFC 826、1982年11月。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC0959]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル"、STD 9、RFC 959、1985年10月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988.
[RFC1058]ヘドリック、C.、 "ルーティング情報プロトコル"、RFC 1058、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.アルベルティ、 "インターネットゴーファープロトコル（分散文書検索及び検索プロトコル）"、RFC 1436年、1993年3月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[RFC1866]バーナーズ=リー、T.、およびD.コノリー、 "ハイパーテキストマークアップ言語 - 2.0"、RFC 1866、1995年11月。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]大工、B.、 "インターネットの建築原則"、RFC 1958、1996年6月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[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.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、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.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）"、RFC 3022、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.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、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.コーバー、BCP 72、RFC 3552、2003年7月、 "セキュリティ上の考慮事項の書き方RFCテキストのためのガイドライン"。
[RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[RFC3954] Claise、B.、 "シスコシステムズのNetFlowサービスエクスポートバージョン9"、RFC 3954、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）"、RFC 4120、2005年7月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251] Ylonenと、T.とC. Lonvick、 "セキュアシェル（SSH）プロトコルアーキテクチャ"、RFC 4251、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）"、RFC 4271、2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、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）で検出ネットワーク接続"、RFC 4436、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.、大工、B.、およびE.クライン、 "IPv6のローカルネットワークの保護"、RFC 4864、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月での作業。
[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]オープン・モバイル・アライアンス、 "ワイヤレス・アプリケーション・プロトコルアーキテクチャ仕様"、<のhttp：// www.openmobilealliance.org/tech/affiliates/ LicenseAgreement.asp DOCNAME = / WAP / WAP-210-waparch-20010712-a.pdf >。
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.
この付録では、我々は潜在的な成功要因の重要性を説明するには、いくつかのケーススタディが含まれています。他の多くの同様に良いケーススタディが含まれている可能性があり、しかし、簡潔にするため、唯一のサンプリングは、この文書の本文に結論を正当化するのに十分であることをここに含まれています。
A.1. HTML/HTTP vs. Gopher and FTP
A.1。 HTML / HTTPのGopherおよび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.
正の正味値：HTTP [RFC2616]のGopher [RFC1436]およびFTP [RFC0959]よりも実質的に多くの価値提供HTML [RFC1866]で。とりわけ、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.
インクリメンタル展開性：ブラウザとサーバは、増分展開可能でしたが、初期のブラウザでは、また、FTPやGopherのような既存のプロトコルとの下位互換性がなかったです。
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]の機能が欠けていた、とHTTP 1.0は、輻輳制御およびプロキシサポートの問題を持っていました。問題のこれらの種類は、一般的に、今日IESGの承認を防止するであろう。しかし、彼らは成功になるのプロトコルを防ぐことはできませんでした。
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.
脅威は十分に緩和：いいえあり、最初は機密性（例えば、クレジットカード番号の保護）はサポートしていない、とHTTP 1.0は、基本認証ではクリアテキストのパスワードを持っていました。
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。 IPX対のIPv4
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.
インクリメンタル展開性：フラグの日が一度に管理可能だったいくつかの十分なノードがあるものの（IPv4のを含む）の競合他社はいずれも、増分展開性がありませんでした。
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への改善は、ずっと後に来ました。
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などの他の競争相手、ありました。しかし、高等研究計画庁（ARPA）はBSD上での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]は、競合他社よりも大きな価値を提供します。 Kerberos対応のtelnetはKerberosサーバの導入が必要でした。 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.
インクリメンタル展開性：はい、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.
オープン保守プロセス：で最初が、最終的にはありません。
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のは、man-in-the-middle攻撃に対して脆弱でした。
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.
さらに、コストは必ずしもメリットと整合していません。ドメイン間マルチキャストは、（少なくとも）アプリケーション、ホストおよびルータによって変更を必要とします。しかし、それが主な利点を得るアプリケーションです。アプリケーション層が重なるため、他方で、アプリケーションのみを変更する必要があり、したがってコストが低くなる（したがって、利益がある）、コスト及び利益が整列されています。
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 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.
インクリメンタル展開性：ドメイン間のマルチキャストのための悪い、それはソースとマルチキャストをサポートするために、任意の受信機間のエンドツーエンドのパス内のすべてのルータを必要とするので。これは深刻なネイティブマルチキャストの展開性を制限しました。当初、戦略がこの問題を回避するために、オーバーレイネットワーク（マルチキャストバックボーン（ある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.
アプリケーションのみを変更する必要があるため、増分展開性は、アプリケーション層オーバーレイのためによかったです。しかし、利点は、送信者（S）と受信機がオーバーレイメカニズムをサポートし、両方の場合に存在します。
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.
良い技術設計：これはドメイン間のマルチキャストのための議論の余地があります。多くの点で、技術的な設計は非常に効率的です。その他の点では、それはせいぜい疑問であるすべての中間ルータに接続ごとの状態となります。アプリケーション層オーバーレイは欠点を持っていますが、小さな利益を受信しません。
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.
脅威が十分に緩和：いいえドメイン間マルチキャストのために、信頼できないホストは、パス全体に沿った中間ルータの状態を作成することができるからです。アプリケーション層マルチキャストのためのより良いです。
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。ワイヤレスアプリケーションプロトコル（WAP）
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.
インクリメンタル展開性：悪いです。 WAPは、携帯電話でのサービスプロバイダとWAPのサポートにWAPツーHTTPプロキシが必要。多くの場合、サービスプロバイダによって参加を必要と新しいサイトを追加します。
Open code availability: No.
オープンコードの可用性：いいえ。
Restriction-free: No. WAP has two patents with royalties required.
制限のないA：いいえWAPは、必要な印税を持つ2件の特許を持っています。
Open specification availability: No.
オープン仕様の可用性：いいえ。
Open maintenance process: No, there was a US$27000 entrance fee.
オープン保守プロセス：いいえ、US $ 27000入場料がありました。
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に近い競争相手の数がありました。インクリメンタル展開性は競合他社と簡単だった、とのコードと仕様のアクセスに制限が成功するための能力を妨げ重要な因子でした。
A.6. Wired Equivalent Privacy (WEP)
A.6。有線等価プライバシー（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が広く、その欠点にもかかわらず、展開されていることに成功したIEEE 802.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.
インクリメンタル展開性：はい。 1は、アクセスポイントとステーションの両方を設定する必要が、各無線ネットワークは、独立してWEPを展開することができます。
Open code availability: Essentially no, because of Rivest Cipher 4 (RC4).
オープンコードの可用性：本質的に、リベストための暗号4（RC4）。
Restriction-free: No for RC4, but otherwise yes.
制限のないA：いいえ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.
拡張可能：IEEE 802.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は完全にオープンで制約の自由ではなかった、との良好な技術的なデザインを持っていなかったにもかかわらず、それは漸進的に展開だったので、それはまだ成功となり、何の選択肢がなかったときには、大きな価値を提供します。これは再び値と展開性が全く選択肢が存在しない、特に技術的なデザインやオープン性よりも重要成功要因、であることを示しています。
A.7. RADIUS vs. TACACS+
A.7。 TACACS +対RADIUS
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).
インクリメンタル配布可能：はい両方のために（単にクライアントとサーバを変更します）。
Open code availability: Yes for RADIUS; initially no for TACACS+, but eventually yes.
オープンコードの可用性：RADIUS用はい。最初はTACACS +のため、最終的にはい。
Restriction-free: Yes for RADIUS; unclear for TACACS+.
制限のない：RADIUS用はい。 TACACS +のための不明確。
Open specification availability: Yes for RADIUS; initially no for TACACS+, but eventually yes.
オープン仕様の可用性：RADIUS用はい。最初は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のためのフェアは、（何の機密性のサポート、およびアクセス要求の認証なしありませんでした。それは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).
いいえハードスケーラビリティないバインド：RADIUSのための優れた（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は早くからオープン保守プロセスを持っていただけでなく、オープンに利用可能な仕様とソースコードという事実は決定的な要因でした。これは、再び、より良い技術的な設計を有する他の要因よりも成功を決定する上でそれほど重要であることを示しています。
A.8. Network Address Translators (NATs)
A.8。ネットワークアドレス変換器（NAT）
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を享受するために変更するために単一のエンティティを必要とする多くのメカニズムがあるので、我々は、ケーススタディを含め輻輳制御アルゴリズム）は、このクラスの他の一例であり、それは増分展開性の議論において重要な点を例示するためには、議論におけるメカニズムのこのクラスを含めることが重要です。
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.
正の正味値：はい。 NATはアドレスの限られた数が利用可能であった場合、複数のデバイスを接続する機能を提供し、また、副作用として（限定されるもの）のセキュリティ境界を提供しました。したがって、両方の複数のアドレスを取得するに関与安心痛みだけでなく、有効な新しいシナリオ。最後に、それだけで利益を得たエンティティによって展開が必要。
Incremental deployability: Yes. One could deploy a NAT without coordinating with anyone else, including a service provider.
インクリメンタル展開性：はい。一つは、サービスプロバイダを含め、他の誰との調整なしで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されました。また、NATはアプリケーションの特定のクラスのための問題を引き起こしました。
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.
拡張可能：フェア。 NATは、いくつかのすべてではない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.
脅威は十分に緩和：はい。
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.
確かに、NATは、追加の目的[RFC4864]のために使用されることによって、および場所での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
ロア・アンダーソンレスリーDaigle氏エルウィン・デイビスケビン秋ラスHousleyオラフKolkmanバリー・レイバカーティスLindqvistダニー・マクファーソンデヴィッドオランエリックレスコラデーブターラーLixiaチャン
Authors' Addresses
著者のアドレス
Dave Thaler IAB One Microsoft Way Redmond, WA 98052 USA
デーブターラーIAB 1マイクロソフト道、レッドモンド、ワシントン98052 USA
Phone: +1 425 703 8835 EMail: dthaler@microsoft.com
電話：+1 425 703 8835 Eメール：dthaler@microsoft.com
Bernard Aboba IAB One Microsoft Way Redmond, WA 98052 USA
バーナードAboba IAB 1マイクロソフト道、レッドモンド、ワシントン98052 USA
Phone: +1 425 706 6605 EMail: bernarda@microsoft.com
電話：+1 425 706 6605 Eメール：bernarda@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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に情報を記述してください。