[要約] 要約：RFC 5218は、成功したプロトコルの要素についてのガイドラインを提供しています。 目的：プロトコルの設計者や開発者に、成功したプロトコルを作成するための指針を提供することです。
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）の目標の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 プロトコル実験の成功を評価する人。
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 [RFC3261]、SIP [RFC3261]。
Intra-domain: ARP [RFC0826], PPP [RFC1661], DHCP [RFC2131], RIP [RFC1058], OSPF [RFC2328], Kerberos [RFC4120], NAT [RFC3022].
ドメイン内：ARP [RFC0826]、PPP [RFC1661]、DHCP [RFC2131]、RIP [RFC1058]、OSPF [RFC2328]、Kerberos [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を超えるすべて」）、元々設計されたものよりもはるかに大きな規模で展開されています。限られたアドレススペースは、すでに元のデザインを大幅に上回っていた後にのみ問題になりました。
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です。もともとより汎用的な目的を目的としていました（つまり、メディアタイプまたはネットワークレイヤープロトコルに関係なく、ネットワークレイヤーアドレスをリンクレイヤーアドレスに解決してレイヤーアドレスをリンクします）。、しかし、ネットワーク添付ファイルの検出などの他の用途に採用されました（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 重要で差し迫った問題に対処します。必要性が十分に深刻な場合、業界は実装が存在するとすぐにそれを採用するように促され、有名なニーズは実装を動機付けるのに十分です。たとえば、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の有線同等のプライバシー（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 ハードウェアコスト：ハードウェアの変更を必要としないプロトコルは、実行するものよりも展開が簡単です。オーバーレイネットワークは、ハードウェアの変更が必要になることを避けるための1つの方法です。ただし、多くの場合、機能性がソフトウェアのみで提供できるプロトコルでも、ハードウェアの更新が必要です。ベンダーは、多くの場合、新しいハードウェアでのみ実行される可能性のあるコードツリーの後のブランチ内でのみ新しい機能を実装します。その結果、ハードウェアのアップグレードコストを回避する最も安全な方法は、既存のハードウェアとソフトウェアの両方との後方互換性のために設計することです。
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 ビジネスの依存関係：ビジネスモデルの変更を必要としないプロトコル（実装者または展開者の場合）は、展開するよりも簡単に展開できます。請求および会計システムの変更、および関連する人員の再訓練に関連するコストがあり、さらに、以前のビジネスモデルの基礎となる仮定が変更される可能性があります。たとえば、多くの場合、多くのサービスプロバイダーには、マシンが常に接続されていないという仮定で、ダイヤルアップの周りにビジネスモデルが構築されていました。ネットワークが常にオンに合わせて最適化されていなかったため、常に常に接続されていたプロトコルでは、ビジネスモデルを変更する必要がありました。同様に、一部のサービスプロバイダーには、上流の帯域幅が十分に活用されていないと仮定するビジネスモデルがあります。ピアツーピアプロトコルでは、このビジネスモデルを変更する必要がある場合があります。最後に、多くのサービスプロバイダーは、顧客へのリンクで消費される帯域幅の量の充電に基づいてビジネスモデルを持っています。マルチキャストプロトコルは、レプリケーションのコストをカバーする他のメカニズムを持たずに、多くのユニキャストストリームをソースに支払うためにより多くの支払いをするのではなく、マルチキャストトラフィックを送信することにより、顧客がマルチキャストトラフィックを送信することにより、顧客がソースリンクの帯域幅を減らす方法を提供するため、このビジネスモデルを妨害するため、このビジネスモデルを妨害します。ネットワークでは（例：ルーター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 痛みを和らげる：プロトコルを展開する前に存在するコスト（金銭的またはその他）が劇的に削減されるプロトコルは、燃焼ニーズに対処するため、直接的な利益を示すのが簡単です。
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.
成功は、自然なインセンティブ構造が展開要件と一致している場合に最も簡単に行われます。つまり、何かを展開、管理、または構成する必要がある人は、最も利益を得る人と同じです。要約すると、変更が必要な各組織に大きな正の正味値がある場合が最適です。
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.
単一のグループまたはチーム（ドメイン内など）が展開できるプロトコルは、組織間で協力を必要とするものよりも成功する可能性が高くなります（または、最悪の場合、誰もが同時に変更する必要がある「フラグの日」が必要です。）。たとえば、インフラストラクチャの変更を必要としないプロトコル（例：ルーターの変更、サービスプロバイダーのサポートなど）は、調整が少ないため、標準的な例であるため、成功する可能性が高くなります。同様に、一方のエンドの変更のみがプロトコルをサポートするために通信の両端を必要とするものよりも大きな成功の可能性がある場合に利益をもたらすプロトコルは成功する可能性があります。
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とInternetWork Packet Exchange（IPX）[IPX]を決定するとき、これは多くの点でIPXが技術的にIPv4よりも優れていたとしても、決定要因であると主張することができます。TACACS [TACACS]を介した半径[RFC2865]の成功について同様の議論がなされています。詳細については、付録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?
o 安定性：変更されない仕様の安定したバージョンはありますか？
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]。たとえば、単純さ、モジュール性、および障害に対する堅牢性はすべて、すべての設計要因です。同様に、仕様の明確性は、相互運用性と実装の容易さを促進する優れた技術設計のもう1つの側面です。ただし、経験によると、優れた技術設計は、他の要因と比較して、初期の成功に最小限の影響を与えることが示されています。
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.
プロトコルが成功すればするほど、ターゲットが魅力的になります。セキュリティの欠陥を備えたプロトコルは、その後の改訂で欠陥に対処できるように十分に拡張できる限り、依然として大成功を収めている可能性があります。例には、Secure Shellバージョン1（SSHV1）およびWEPを使用した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 プロトコルは、重要な初期成功要因の1つ以上を示していますか？
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 STD 802.11、2007。
[IMODE] NTT DoCoMo, "i-mode", <http://www.nttdocomo.com/services/imode/index.html>.
[imode] ntt docomo、 "i-mode"、<http://www.nttdocomo.com/services/imode/index.html>。
[IPX] Novell, "IPX Router Specification", Novell Part Number 107-000029-001, 1992.
[IPX] Novell、「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] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、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] Plummer、D。、「イーサネットアドレス解像度プロトコル：または、ネットワークプロトコルアドレスをイーサネットハードウェア上の送信用のビットイーサネットアドレスに変換する」、STD 37、RFC 826、1982年11月。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC0959] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、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] Hedrick、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.、Lindner、P.、Johnson、D.、Torrey、D.、およびB. Alberti、「インターネットGopherプロトコル（分散ドキュメント検索および検索プロトコル）」、RFC1436、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.
[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] Moy、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] Deering、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]クレンシン、J。、「Simple Mail Transfer Protocol」、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.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、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）」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION Intioniation Protocol」、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] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[RFC3954] Claise、B。、「Cisco Systems Netflow Services Export Version 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] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network認証サービス（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、「The Secure Shell（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.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、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.、Carlson、J。、およびS. Cheshire、「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] van de Velde、G.、Hain、T.、Droms、R.、Carpenter、B。、およびE. Klein、「IPv6のローカルネットワーク保護」、RFC 4864、2007年5月。
[TACACS+] Carrel, D. and L. Grant, "The TACACS+ Protocol, Version 1.78", Work in Progress, January 1997.
[TACACS] Carrel、D。およびL. Grant、「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.pdfdf>。
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.
この付録には、潜在的な成功要因の重要性を説明するために、いくつかのケーススタディが含まれています。他の多くの同様に良いケーススタディが含まれている可能性がありますが、簡潔にするために、この文書の本文の結論を正当化するのに十分なサンプリングのみがここに含まれています。
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]は、Gopher [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.
インクリメンタルデプロイ可能性：ブラウザとサーバーは徐々に展開できましたが、初期ブラウザーは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の承認を妨げます。しかし、彼らはプロトコルが成功するのを妨げませんでした。
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.
ハードスケーラビリティバウンドはありません：優れています。Gopherの場合と同様に、登録プロセスはありませんでした。
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にはBasic Authにクリアテキストパスワードがありました。
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が成功した後にのみ、セキュリティは問題になりました。HTML/ HTTPの最初の成功はIETFの外で発生しましたが、HTTPは後に標準化および洗練されており、制限の一部に対処しました。
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.
オープンコードの可用性：IPv4にはBSDからオープンコードがありましたが、IPXは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の改善はずっと後になりました。
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も十分に緩和されていませんでした。
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が成功しました。IPXは最初は技術的に優れた設計を持っていましたが、IPv4は開放性のために成功しました。
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は、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で対処された多くの技術的な問題がありました。
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は、中間の攻撃に対して脆弱でした。
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は明確な勝者になりました。
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.
長期間が経過した後、成功していない（つまり、元の設計目標を達成していない）プロトコルを調べています。この議論は、ドメイン内またはサブネット内マルチキャストではなく、ドメイン間マルチキャストにのみ適用されることに注意してください。
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.
アプリケーションのみを変更する必要があるため、増分展開性はアプリケーション層オーバーレイに適していました。ただし、利益は、送信者と受信機の両方がオーバーレイメカニズムをサポートしている場合にのみ存在します。
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.
優れた技術設計：これは、ドメイン間マルチキャストにとって議論の余地があります。多くの点で、技術設計は非常に効率的です。他の点では、すべての中間ルーターで接続ごとの状態をもたらします。これはせいぜい疑わしいです。アプリケーション層のオーバーレイには不利な点はありませんが、より少ない利点を受け取ります。
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.
十分に緩和された脅威：ドメイン間マルチャストの場合は、信頼されていないホストはパス全体に沿って中間ルーターに状態を作成できるためです。アプリケーション層マルチキャストの方が適しています。
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.
利益は、エンティティ（サービスプロバイダーとアプリケーション開発者）がそれを使用するコストを上回るのに十分ではなかったため、業界は複製されたユニキャストでアプリケーションオーバーレイを選択する傾向がありました。
The Wireless Application Protocol (WAP) [WAP] is another protocol that has not been successful, but is worth comparing against other protocols.
ワイヤレスアプリケーションプロトコル（WAP）[WAP]は、成功していないが、他のプロトコルと比較する価値がある別のプロトコルです。
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 DocomoのI-Mode [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-to-HTTPプロキシが必要であり、電話でWAPサポートが必要でした。多くの場合、新しいサイトを追加するには、サービスプロバイダーによる参加が必要でした。
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.
オープンメンテナンスプロセス：いいえ、27000米ドルの入場料がありました。
Good technical design: No, a common complaint was that WAP was underspecified and hence interoperability was difficult.
優れた技術設計：いいえ、一般的な不満は、WAPが統一されていたため、相互運用性が困難だったことでした。
Extensible: Unknown.
拡張可能：不明。
No hard scalability bound: Excellent.
ハードスケーラビリティバウンドはありません：優れています。
Threats sufficiently mitigated: Unknown.
脅威は十分に緩和されています：不明。
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には多くの密接な競争相手がいました。競合他社にとっては漸進性の展開が容易であり、コードと仕様のアクセスの制限は、成功する能力を妨げる重要な要因でした。
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]の一部であり、その障害にもかかわらず広く展開されることに成功しました。
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.
インクリメンタル展開可能性：はい。アクセスポイントとステーションの両方を構成する必要がありましたが、各ワイヤレスネットワークは独立してWEPを展開できます。
Open code availability: Essentially no, because of Rivest Cipher 4 (RC4).
オープンコードの可用性：Rivest Cipher 4（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を不適切に使用していました。
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.
十分に緩和された脅威：いいえ
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は完全にオープンではなく、制限がなく、優れた技術設計がありませんでしたが、代替手段がなかった場合に徐々に展開可能であり、重要な価値を提供したため、まだ成功しました。これは、特に代替手段が存在しない場合、価値と展開性が技術設計や開放性よりも重要な成功要因であることを示しています。
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+.
オープンメンテナンスプロセス：最初は半径の場合はノーですが、最終的にははい。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に適しています。
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.
十分に緩和された脅威：半径の場合はありません（機密性のサポートはなく、既存の実装は辞書攻撃に対して脆弱であり、MD5の使用は現在衝突に対して脆弱です）。TACACSは暗号化をサポートしてから優れていました。
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にはオープンメンテナンスプロセスがあり、オープンに利用可能な仕様とソースコードが早い段階であるという事実が決定因子でした。これも、他の要因よりも成功を決定する上で、より良い技術設計を持つことはそれほど重要ではないことを示しています。
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が含まれます。輻輳制御アルゴリズムは、このクラスの別の例です）。また、このクラスのメカニズムを議論に含めることが重要です。なぜなら、インクリメンタルな展開性の議論の重要なポイントを例示しているからです。
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機能は統一されており、一般的に予測不可能な行動につながりました。さらに、NATは特定のクラスのアプリケーションに問題を引き起こしました。
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.
脅威は十分に軽減されました：はい。
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を含む大規模に使用されることで大成功を収めました。
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 Andersson Leslie Daigle Elwyn Davies Kevies Kevins Fall Russ Housley Olaf Kolkman Barry Leiba Kurtis Lindqvist Danny McPherson David Oran Eric Rescorla Dave Thaler Lixia Zhang
Authors' Addresses
著者のアドレス
Dave Thaler IAB One Microsoft Way Redmond, WA 98052 USA
Dave Thaler IAB One Microsoft Way Redmond、WA 98052 USA
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Bernard Aboba IAB One Microsoft Way Redmond, WA 98052 USA
Bernard Aboba IAB One Microsoft Way Redmond、WA 98052 USA
Phone: +1 425 706 6605
EMail: bernarda@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。