Network Working Group D. Thaler
Request for Comments: 5218 B. Aboba
Category: Informational IAB
July 2008
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
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
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:
Internet工程任务组（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.
在讨论有助于或阻碍协议成功的因素时，我们需要首先定义“成功”的含义。如果协议满足其最初的目标，那么它可能会成功，并且仍然不会被广泛部署。然而，在这份文件中，我们认为一个成功的协议是一个既满足其最初的目标，并被广泛部署。注意，“广泛部署”并不意味着“域间”；成功的协议（例如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]、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.
评估协议的两个主要维度是规模和目的。在设计时，协议旨在用于某些范围的目的，并设计用于特定规模。
Figure 1 graphically depicts these concepts.
图1以图形方式描述了这些概念。
Scale ^
|
| +------------+
| | |
| | Original |
| | Protocol |
| | Design |
| | Space |
| | |
<-----------------------------------------------> Purpose
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
Scale ^ +---------------------------------------+
| | Actual Deployment |
| | |
| | |
| | +------------+ |
| | | Original | |
| | (Web | Design | (Firewall |
| | Services) | Space | Traversal) |
| | | (Web) | |
<-----------------------------------------------> Purpose
Another example of a wildly successful protocol is IPv4. Although it was designed for all purposes ("Everything over IP and IP over Everything"), it has been deployed on a far greater scale than that for which it was originally designed; the limited address space only became an issue after it had already vastly surpassed its original design.
另一个非常成功的协议是IPv4。尽管它是为所有目的而设计的（“IP上的一切和IP上的一切”），但它的部署规模远远大于最初设计的规模；有限的地址空间只是在它已经大大超过其原始设计之后才成为一个问题。
Another example of a successful protocol is ARP. Originally intended for a more general purpose (namely, resolving network layer addresses to link layer addresses, regardless of the media type or network layer protocol), ARP was widely deployed for a narrower scope of uses
另一个成功协议的例子是ARP。ARP最初用于更一般的用途（即，将网络层地址解析为链路层地址，而不管媒体类型或网络层协议如何），但被广泛部署用于更窄的使用范围
(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.
（将IPv4地址解析为以太网MAC地址），但随后被用于其他用途，如检测网络连接（检测IPv4（DNAv4）[RFC4436]中的网络连接）。此外，与IPv4一样，ARP的部署规模（就机器数量而言，而不是同一子网上的机器数量而言）比最初预期的要大得多。
Scale ^ +-------------------+
| | Actual Deployment |
| | |
| | | Original Design Space
| | +-------------+--------------+
| | |(IP/Ethernet)|(Non-IP) |
| |(DNA)| | |
| | | |(Non-Ethernet)|
| | | | |
<-----------------------------------------------> Purpose
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.
在首次设计协议时，上述三个条件成立，这就是为什么在评估协议的成功或失败之前留出足够的时间是很重要的。
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
o 硬件成本：不需要硬件更改的协议比需要硬件更改的协议更易于部署。覆盖网络是避免硬件更改的一种方法。然而，经常需要硬件更新，即使对于功能可以仅在软件中提供的协议也是如此。供应商通常实施新的
functionality only within later branches of the code tree, which may only run on new hardware. As a result, the safest way to avoid hardware upgrade cost is to design for backward compatibility with both existing hardware and software.
仅在代码树的后续分支中提供功能，这些分支只能在新硬件上运行。因此，避免硬件升级成本的最安全方法是设计与现有硬件和软件的向后兼容性。
o Operational interference: Protocols that don't require changes to other operational processes and tools are easier to deploy than ones that do. For example, IPsec [RFC4301] interferes with NetFlow [RFC3954] deep packet inspection, which can be important to operators.
o 操作干扰：不需要更改其他操作流程和工具的协议比需要更改的协议更易于部署。例如，IPsec[RFC4301]会干扰NetFlow[RFC3954]深度数据包检查，这对运营商可能很重要。
o Retraining: Protocols that have no configuration, or are very easy to configure/manage, are cheaper to deploy.
o 再培训：没有配置或非常容易配置/管理的协议部署成本较低。
o Business dependencies: Protocols that don't require changes to a business model (whether for implementers or deployers) are easier to deploy than ones that do. There are costs associated with changing billing and accounting systems and retraining of associated personnel, and in addition, the assumptions on which the previous business model was based may change. For example, some time ago many service providers had business models built around dial-up with an assumption that machines were not connected all the time; protocols that desired always-on connectivity required the business model to change since the networks were not optimized for always-on. Similarly, some service providers have business models that assume that upstream bandwidth is underutilized; peer-to-peer protocols may require this business model to change. Finally, many service providers have business models based on charging for the amount of bandwidth consumed on the link to a customer; multicast protocols interfere with this business model since they provide a way for a customer to consume less bandwidth on the source link by sending multicast traffic, as opposed to paying more to source many unicast streams, without having some other mechanism to cover the cost of replication in the network (e.g., router CPU, downstream link bandwidth, extra management). Multicast protocols also complicate business models based on charging the source of traffic based on the amount of multicast replication, since the source may not be able to predict the cost until a bill is received.
o 业务依赖关系：不需要更改业务模型的协议（无论是对于实现者还是部署者）比需要更改的协议更易于部署。改变账单和会计系统以及相关人员的再培训会产生相关成本，此外，先前商业模式所依据的假设可能会改变。例如，前一段时间，许多服务提供商在拨号上网的基础上建立了业务模型，并假设机器并非一直连接在一起；需要常开连接的协议需要改变业务模型，因为网络没有针对常开进行优化。类似地，一些服务提供商的商业模式假设上游带宽未得到充分利用；对等协议可能需要更改此业务模型。最后，许多服务提供商的商业模式基于对客户链路上消耗的带宽量收费；多播协议会干扰此业务模型，因为它们为客户提供了一种通过发送多播流量来消耗源链路上较少带宽的方法，而不是向多个单播流源支付更多的费用，而没有其他机制来支付网络中复制的成本（例如，路由器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.
至少有两个成本/收益权衡的例子。在第一种情况下，即使在初始部署时，收益也大于成本。在第二种情况下，前期成本超过了最初的收益，但收益会随着时间的推移而增长（例如，随着更多节点或应用程序的支持）。前一种模型更容易获得初始部署，但随着时间的推移，两者都可以成功。第二个模型对于初始部署有一个危险，即如果其他人没有部署协议，那么初始部署者就失去了价值，因此他们必须在部署协议时承担一些风险。
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。对于RADIUS[RFC2865]在TACACS+[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内制定或为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]中所述。例如，简单性、模块性和对故障的鲁棒性都是关键的设计因素。同样，规范的清晰性是良好技术设计的另一个方面，有助于实现互操作性和易于实现。然而，经验表明，与其他因素相比，良好的技术设计对初始成功的影响最小。
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.
协议越成功，目标就越有吸引力。具有安全缺陷的协议仍然可能获得广泛的成功，只要它们具有足够的可扩展性，允许在后续修订中解决这些缺陷。示例包括安全外壳版本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 协议是否显示了一个或多个关键的初始成功因素？
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 这项技术有吸引力的潜在领域吗？
o If so, can complexity be removed to reduce cost?
o 如果是这样，是否可以消除复杂性以降低成本？
o Is there a potential killer app? Or can the technology work underneath existing unmodified applications?
o 有没有潜在的杀手级应用？或者该技术可以在现有未修改的应用程序下工作？
o Is the protocol sufficiently extensible to allow potential deficiencies to be addressed in the future?
o 该协议是否具有足够的可扩展性，以允许将来解决潜在的缺陷？
o If it is not known whether the protocol will be successful, should the market decide first? Or should the IETF work on multiple alternatives and let the market decide among them? Are there factors listed in this document that may predict which is more likely to succeed?
o 如果不知道协议是否会成功，市场是否应该首先决定？或者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.
在早期阶段（例如，BOF、新协议的设计），评估初始成功因素对于促进成功非常重要。同样，修订不成功方案的努力应该评估是否存在最初的成功因素（或其中足够的因素），而不是关注尚未成为问题的野性成功。另一方面，对于成功方案的修订，关注野生成功因素更合适。
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，“无线局域网介质访问控制（MAC）和物理层（PHY）规范”，ANSI/IEEE标准802.112007。
[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 88791986。
[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 7911981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准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.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，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，“文件传输协议”，标准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.，“路由信息协议”，RFC10581988年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，“互联网地鼠协议（分布式文档搜索和检索协议）”，RFC 1436，1993年3月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[RFC1866]Berners Lee，T.和D.Connolly，“超文本标记语言-2.0”，RFC 18661995年11月。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，“互联网的建筑原理”，RFC19581996年6月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年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]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，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 28212001年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 28652000年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：会话启动协议”，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服务导出版本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，“Kerberos网络身份验证服务（V5）”，RFC41202005年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.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年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 44362006年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.pdf>。
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.
正净值：HTTP[RFC2616]和HTML[RFC1866]提供的价值远远超过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在基本身份验证中有明文密码。
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没有。许多人认为这是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最初更好。IPv4的改进（如DHCP）来得晚得多。
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。然而，高级研究计划署（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.
威胁得到充分缓解：第1号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，因此易于部署。这些因素使宋承宪成为了一个明显的赢家。
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有两项专利，需要支付版税。
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密码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+.
无限制：半径为是；对于TACACS+不清楚。
Open specification availability: Yes for RADIUS; initially no for TACACS+, but eventually yes.
开放规格可用性：半径为是；TACACS+最初为否，但最终为是。
Open maintenance process: Initially no for RADIUS, but eventually yes. No for TACACS+.
开放式维护流程：最初半径为否，但最终为是。不适用于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).
无硬性可伸缩性限制：适用于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+更好，因为它支持加密。
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.
B:公平。NATs支持一些但不是所有的UDP和TCP应用程序。添加应用层网关功能很困难。
No hard scalability bound: Good. There is a scalability bound (number of ports available), but none near the original design goals.
没有硬性限制：好。有一个可伸缩性界限（可用端口数），但没有一个接近原始设计目标。
Threats sufficiently mitigated: Yes.
威胁得到充分缓解：是的。
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 Kevin 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美国华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
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美国
Phone: +1 425 706 6605
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
EMail: 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.