RFC 5218

What Makes for a Successful Protocol?

📅 published July 2008, from ietf

RFC 5218 💖✨

What Makes for a Successful Protocol? 🎀

Authors: D. Thaler and B. Aboba (IAB) 🧚 Category: Informational 📚 Date: July 2008 📅 This doc doesn't obsolete or update anything in its header. 🫶

Status of This Memo ✨

Okay bestie, first the boring-but-important bit 💅. This memo just provides information for the Internet community. It is not an Internet standard of any kind, so don't go treating it like one 🙈. Distribution of this memo is unlimited, so share it with everyone you know 🦋.

Abstract 🌸

The Internet community has specified a LOT of protocols so far, and they've had all kinds of success stories 👑. This doc looks at case studies to figure out what helps a protocol succeed and what holds one back 🔥. The hope is that these observations can guide future protocol work, so future us can make better choices 💜.

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

1. Introduction 🧚

One of the goals of the IETF (Internet Engineering Task Force) is to define protocols that actually hit their implementation and deployment goals 🎯. This doc uses case studies to pinpoint the factors that push a protocol toward success or failure 💅. It's meant to be useful for these crews:

  • IESG members deciding whether to charter a Working Group to do work on a specific protocol 👑
  • Working Group participants picking between protocol proposals 🫶
  • Document authors developing a brand new protocol specification ✨
  • Anyone evaluating the success of a protocol experiment 🔬

1.1. What is Success? 🤔

Before we talk about what helps or hurts a protocol, we need to define "success" 💖. A protocol can be successful even if it isn't widely deployed, as long as it meets its original goals 🌸. But in this doc, a successful protocol is one that does both: it meets its original goals and it's widely deployed 🔥. Quick note though: "widely deployed" does not mean "inter-domain" 🙈. Successful protocols like DHCP [RFC2131] can be widely deployed purely for intra-domain use, and that still counts 💅.

Here are some examples of successful protocols:

Inter-domain: 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].

1.2. Success Dimensions 📐

Two big dimensions for judging a protocol are scale and purpose 📈. When a protocol gets designed, it's aimed at a certain range of purposes and built for a particular scale 🎀.

Figure 1 shows this visually, so check it out 👀:

       Scale ^
             |
             |             +------------+
             |             |            |
             |             |  Original  |
             |             |  Protocol  |
             |             |   Design   |
             |             |   Space    |
             |             |            |
          <-----------------------------------------------> Purpose

                              Figure 1

So by these metrics, a "successful" protocol is one used for its original purpose at the originally intended scale 💜. A "wildly successful" protocol goes way past its original goals 🚀. That can be in terms of purpose (used in scenarios far beyond the initial design), in terms of scale (deployed on a much bigger scale than anyone imagined), or both 🌈. Basically it has outgrown its bounds and ventured "into the wild" 🦋.

1.2.1. Examples 🌟

HTTP is the classic "wildly successful" protocol, because it blew past its design in both purpose and scale 😭:

    Scale ^  +---------------------------------------+
          |  | Actual Deployment                     |
          |  |                                       |
          |  |                                       |
          |  |            +------------+             |
          |  |            |  Original  |             |
          |  | (Web       |   Design   | (Firewall   |
          |  |  Services) |   Space    |  Traversal) |
          |  |            |   (Web)    |             |
       <-----------------------------------------------> Purpose

IPv4 is another wildly successful one 💅. It was designed for all purposes ("Everything over IP and IP over Everything") 🤯, and it's been deployed on a way bigger scale than it was originally designed for 🌍. The limited address space only became a problem after IPv4 had already vastly surpassed its original design 😅.

ARP is an example of a successful protocol 🎀. It was originally meant for a more general purpose: resolving network layer addresses to link layer addresses, no matter the media type or network layer protocol 🧠. In practice it was widely deployed for a narrower set of uses (resolving IPv4 addresses to Ethernet MAC addresses) 🔌. Then it got adopted for other uses too, like detecting network attachment (Detecting Network Attachment in IPv4 (DNAv4) [RFC4436]) 🙌. Also, like IPv4, ARP is deployed on a much bigger scale than originally expected, in terms of number of machines (though not number on the same subnet) 💖.

    Scale ^  +-------------------+
          |  | Actual Deployment |
          |  |                   |
          |  |                   |   Original Design Space
          |  |     +-------------+--------------+
          |  |     |(IP/Ethernet)|(Non-IP)      |
          |  |(DNA)|             |              |
          |  |     |             |(Non-Ethernet)|
          |  |     |             |              |
       <-----------------------------------------------> Purpose

1.3. Effects of Wild Success 🌪️

Wild success can be both good and bad 😬. A wildly successful protocol is so useful that it can solve more problems, cover more scenarios, or work on more devices 🙌. That can be a sign that it's time to revise the protocol so it better fits the new design space 🔄.

But if a protocol gets used for a purpose other than the one it was designed for, a few things can go wrong 👀:

  • There may be undesirable side effects, because design decisions that were right for the originally intended purpose may be wrong for the new one 💀.
  • There may be performance problems if the protocol wasn't designed to scale to the extent it was deployed 🐢.
  • Implementers may try to add or change functionality to work around the design limitations, without fully understanding how that affects the overall protocol behavior and invariants 🧩.
  • Wildly successful protocols become high value targets for attackers, because of their popularity and because uses or extensions that are less well understood and tested than the original protocol offer a chance for exploitation 🎯.

So a wildly successful protocol is vulnerable to "death by success", collapsing under attacks or scaling limits 😭🕯️.

1.4. Failure 💀

okay so, failure (aka not being successful yet) can't be called until enough time has passed, like 5-10 years for an average protocol 🕰️ nobody gets to decide a protocol flopped on day one. The failure signs are:

  • No mainstream implementations. Hardly anyone supports it in hosts, routers, or other kinds of relevant devices 🥀
  • No deployment. The devices that support it aren't out there, or they are but the protocol isn't turned on 📵
  • No use. It might be deployed, but no apps or scenarios actually use it 👻

when a protocol is first designed, all three of those are true, which is exactly why you have to give it time before you call it a success or a flop 🫠

the lack of a value chain can make it hard for a new protocol to go from implementation to deployment to use. people love calling this the "chicken-and-egg" problem 🐔🥚, but the lack of implementation, deployment, or use isn't what causes failure. it's just a symptom, bestie 💅

there are lots of strategies people have used to get past that starting lack of implementations, deployment, and use, but none of them guarantee success 🤞 some examples:

  • Address a critical and imminent problem. if the need is severe enough, the industry is motivated to adopt it as soon as implementations exist, and a well-known need is enough to motivate implementations 🔥 NAT is the example here, since it gave the person deploying it an immediate address sharing capability (Appendix A.8) 🙌 so when you're making a protocol, think about whether it can be easily tailored or expanded to directly target a critical problem. if it only solves part of the problem, think about what else would be needed on top ✨
  • Provide a "killer app" with low deployment costs. this one can create demand where none existed before 🎀 check out the HTTP case study in Appendix A.1 for an example 🌸
  • Provide value for existing unmodified applications. this solves the chicken-and-egg problem by making sure there's already use the second the protocol gets deployed, so the benefit can be felt right away 🦋 see the Wired Equivalent Privacy (WEP) case study in Appendix A.6 for an example 🧚
  • Reduce complexity and cost by narrowing the intended purpose and/or scope to an area where it's easiest to succeed. this can let you cut out complexity that isn't needed for the narrow purpose 🍓 cutting complexity lowers the cost of implementation and deployment, so the cost can end up being really low compared to the benefit 💖 for example, link-scoped multicast is way more successful than, say, inter-domain multicast (see Appendix A.4) 👑
  • A government or other entity may provide incentives or disincentives that motivate implementation and deployment. for example, specific cryptographic algorithms may be mandated 🔐 another example: Japan started an economic incentive program to generate IPv6 [RFC2460] implementations and deployment 🇯🇵✨

as we'll see, these strategies often work because they directly target the top success factors 🏆

2. Initial Success Factors ✨

in this section, we figure out the factors that contribute to success and "wild" success 🦋

a successful protocol won't necessarily have all the success factors, and some success factors can show up even in failed designs 🙈 still, experience seems to show that having success factors tends to improve the odds of success 📈

the success factors, and how important each one is, came from a series of case studies (Appendix A) 🔍

2.1. Basic Success Factors 🧃

2.1.1. Positive Net Value (Meet a Real Need) 💸

it's critical to a protocol's success that the benefits of deploying it (monetary or otherwise) outweigh the costs, and the costs include:

  • Hardware cost: protocols that don't need hardware changes are easier to deploy than ones that do 🔧 overlay networks are one way to skip hardware changes 🌐 but hardware updates are often needed even for protocols whose functionality could be provided purely in software 😤 vendors often put new functionality only in later branches of the code tree, which may only run on new hardware 💀 so the safest way to dodge hardware upgrade costs is to design for backward compatibility with both existing hardware and software 🫶
  • 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 matter a lot to operators 👀
  • Retraining: protocols with no configuration, or that are super easy to configure and manage, are cheaper to deploy 🧠
  • Business dependencies: protocols that don't require changes to a business model (for implementers or deployers) are easier to deploy than ones that do 💼 changing billing and accounting systems and retraining the people who run them costs money, and on top of that, the assumptions the old business model was built on may change 😵‍💫 for example, a while ago lots of service providers had business models built around dial-up, assuming machines weren't connected all the time 📞 so protocols that wanted always-on connectivity made the business model change, since the networks weren't optimized for always-on 🔌 similarly, some service providers have business models that assume upstream bandwidth is underutilized, and peer-to-peer protocols may make that business model change 📤 finally, lots of service providers charge based on the amount of bandwidth consumed on the link to a customer 🧾 multicast protocols mess with that, since they give a customer a way to use less bandwidth on the source link by sending multicast traffic, instead of paying more to source lots of unicast streams 😬 unless some other mechanism covers the cost of replication in the network (e.g., router CPU, downstream link bandwidth, extra management) 🧮 multicast protocols also complicate business models that charge 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 arrives 🙃

there are also many types of benefits, including:

  • Relieving pain: protocols that drastically lower costs (monetary or otherwise) that exist before deploying the protocol are easier to show direct benefit from, since they address a burning need 🔥
  • Enabling new scenarios: protocols that enable new capabilities, scenarios, or user experiences can provide significant value 🚀 though the benefit may be harder to realize, since there may be more risk involved 😰
  • Incremental improvements: protocols that provide incremental improvements (e.g., better video quality) generate a small benefit, so they can succeed as long as the cost is small too 🎞️

there are at least two example cases of cost/benefit tradeoffs 🧁 in the first case, the benefit outweighs the cost even upon initial deployment 💅 in the second case, there's an upfront cost that outweighs the initial benefit, but the benefit grows over time (e.g., as more nodes or applications support it) 📈 the first model makes initial deployment way easier 🥳 but over time, both can be successful ✨ the second model has a danger for the early deployments: if others don't deploy the protocol, the early deployers have lost value, so they have to take on some risk by deploying it 😬

success comes most easily when the natural incentive structure lines up with the deployment requirements 💜 that means the people who have to deploy, manage, or configure something are the same people who get the most benefit 🎯 so in summary, it's best if there's significant positive net value at each organization where a change is required 🫶

2.1.2. Incremental Deployability 🌱

a protocol is incrementally deployable if early adopters gain some benefit even though the rest of the Internet doesn't support it yet 🐣 there are a few aspects to this:

protocols that a single group or team can deploy (e.g., intra-domain) have a better shot at success than ones that need cooperation across organizations (or, in the worst case, need a "flag day" where everyone has to change at the same time) 📅😱 for example, protocols that don't need changes to infrastructure (e.g., router changes, service provider support, etc.) have a better shot than ones that do, since less coordination is needed 🤝 NAT is the canonical example 🙌 similarly, protocols that give benefit when only one end changes have a better shot than ones that need both ends of a communication to support the protocol 🫱🫲

finally, protocol updates that are backward compatible with older implementations have a better shot at success than ones that aren't 🔙✨

2.1.3. Open Code Availability 🆓

protocols with freely available implementation code have a better shot at success than protocols without it 💻 honestly, this often matters more than any technical consideration 🤯 for example, it can be argued that when choosing between IPv4 and Internetwork Packet Exchange (IPX) [IPX], this was the deciding 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 more discussion 📚

2.1.4. Freedom from Usage Restrictions 🕊️

freedom from usage restrictions means that anyone who wants to implement or deploy can do so without legal or financial hindrance 🙌 within the IETF, this often comes up when comparing technologies where one has known Intellectual Property attached to it ⚖️ and the industry often picks the one with no known Intellectual Property, even if it's technically inferior 🥲

2.1.5. Open Specification Availability 📖

open specification availability means the protocol specification is made available to anyone who wants to use it 🌍 this is true for all Internet Drafts and RFCs, and it's contributed to the success of protocol specifications developed within or contributed to the IETF 🎀

the various aspects of this factor include:

  • World-wide distribution: is the specification accessible from anywhere in the world? 🗺️
  • Unrestricted distribution: are there no legal restrictions on getting the specification? 📜
  • Permanence: does the specification stick around even after its creator is gone? ⏳
  • Stability: is there a stable version of the specification that doesn't change? 🧊

2.1.6. Open Maintenance Processes 🗳️

this factor means the protocol is maintained through open processes, there are mechanisms for public comment on the protocol, and the maintenance process lets every constituency affected by the protocol take part 🫶 no gatekeeping, we love to see it 👑✨

2.1.7. Good Technical Design 🧠✨

Okay so this factor is about protocols that follow good design principles, which makes them easier to implement and helps them interoperate. The big reference here is "Architectural Principles of the Internet" [RFC1958] 📖. Simplicity, modularity, and robustness to failures are all key design factors 🧩. Clarity in specifications is another part of good design, since it helps with interoperability and makes implementing things way easier 💅. Here's the tea though: experience shows that good technical design has minimal impact on initial success compared with the other factors 🫠.

2.2. Wild Success Factors 🌈

Okay, these factors don't seem to seriously affect initial success, but they can totally decide whether a protocol becomes wildly successful 👑.

2.2.1. Extensible 🧩

Protocols that are extensible are more likely to become wildly successful, because people end up using them for stuff nobody planned for 🦋. An extensible protocol might carry general purpose payloads or options, or it might be easy to add a brand new payload or option type. This is giving main character energy for protocols that are meant to work for every purpose, like IP 🌍. But for protocols built for one specialized job, you should think carefully before adding extensibility 🤔.

2.2.2. No Hard Scalability Bound 📈

Protocols with no inherent limit near the edge of the scale they were originally imagined for are more likely to be wildly successful in terms of scale 🚀. IPv4 is a perfect example. It had no inherent limit near its originally envisioned scale, and its address space limit didn't get hit until it was already wildly successful 😭. Another kind of inherent limit is a performance "knee" that causes a meltdown once a scaling limit is passed, like a broadcast storm 🌪️.

2.2.3. Threats Sufficiently Mitigated 🛡️

The more successful a protocol gets, the more attractive a target it becomes 🎯. Protocols with security flaws can still become wildly successful, as long as they're extensible enough for those flaws to be fixed in later revisions 🔧. Secure SHell version 1 (SSHv1) and IEEE 802.11 with WEP are examples of this. But the combo of security flaws and limited extensibility is literally deadly 💀. Some early server-based multiplayer games ultimately failed due to insufficient protections against cheating, even though they started out successful 🎮.

3. Conclusions 🎀

The case studies in Appendix A show that the most important initial success factors are filling a real need and being incrementally deployable 💖. When there are competing proposals with comparable benefit and deployability, open specifications and code become big success factors 🔑. Open source availability matters more than open specification maintenance at the start 🌸.

Technical quality usually wasn't the main factor in initial success. Honestly, many successful protocols wouldn't pass IESG review today 🙈. Technically inferior proposals can win if they're openly available 🏆. Factors that don't seem to be significant for initial success (but may affect wild success) include good design, security, and having an open specification maintenance process 🧁.

Lots of the case studies are about protocols that were developed outside the IETF, and the IETF only helped improve them after initial success was already certain 🫶. The IETF focuses on design quality, which isn't a factor in determining initial success. Once a protocol succeeds, though, good technical design may be the key to it staying successful or dealing with wild success 👑. Allowing extensibility in an initial design lets initial shortcomings get addressed later ✨.

Security vulnerabilities don't seem to limit initial success, since they often only become interesting to attackers after a protocol is widely deployed enough to be a useful target 🕵️‍♀️. And open specification maintenance isn't important to initial success either, because many successful protocols were first developed outside the IETF or other standards bodies and only got standardized later 📦.

In light of all this, we recommend asking these questions when evaluating protocol designs 📝:

  • Does the protocol exhibit one or more of the critical initial success factors?
  • Are there implementers who are ready to implement the technology in ways that are likely to be deployed?
  • Are there customers (especially high-profile customers) who are ready to deploy the technology?
  • Are there potential niches where the technology is compelling?
  • If so, can complexity be removed to reduce cost?
  • Is there a potential killer app? Or can the technology work underneath existing unmodified applications?
  • Is the protocol sufficiently extensible to allow potential deficiencies to be addressed in the future?
  • 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?

In the early stages (BOFs, designing new protocols), evaluating the initial success factors is important for helping things succeed 🐣. Similarly, efforts to revise unsuccessful protocols should check whether the initial success factors (or enough of them) were present, instead of focusing on wild success, which isn't a problem yet 🥲. For a revision of a successful protocol, focusing on the wild success factors is more appropriate 🚀.

4. Security Considerations 🔐

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] 💜.

5. Informative References 📚

   [IEEE-802.11]  IEEE, "Wireless LAN Medium Access Control (MAC) and
                  Physical Layer (PHY) Specifications", ANSI/IEEE
                  Std 802.11, 2007.

   [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.

   [ISO-8879]     ISO, "Information processing -- Text and office
                  systems -- Standard Generalized Markup Language
                  (SGML)", ISO 8879, 1986.

   [RFC0768]      Postel, J., "User Datagram Protocol", STD 6, RFC 768,
                  August 1980.

   [RFC0791]      Postel, J., "Internet Protocol", STD 5, RFC 791,
                  September 1981.

   [RFC0793]      Postel, J., "Transmission Control Protocol", STD 7,
                  RFC 793, September 1981.

   [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.

   [RFC0959]      Postel, J. and J. Reynolds, "File Transfer Protocol",
                  STD 9, RFC 959, October 1985.

   [RFC1035]      Mockapetris, P., "Domain names - implementation and
                  specification", STD 13, RFC 1035, November 1987.

   [RFC1058]      Hedrick, C., "Routing Information Protocol", RFC 1058,
                  June 1988.

   [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.

   [RFC1661]      Simpson, W., "The Point-to-Point Protocol (PPP)",
                  STD 51, RFC 1661, July 1994.

   [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.

   [RFC2131]      Droms, R., "Dynamic Host Configuration Protocol",
                  RFC 2131, March 1997.

   [RFC2328]      Moy, J., "OSPF Version 2", STD 54, RFC 2328,
                  April 1998.

   [RFC2460]      Deering, S. and R. Hinden, "Internet Protocol, Version
                  6 (IPv6) Specification", RFC 2460, December 1998.

   [RFC2616]      Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                  Masinter, L., Leach, P., and T. Berners-Lee,
                  "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
                  June 1999.

   [RFC2821]      Klensin, J., "Simple Mail Transfer Protocol",
                  RFC 2821, April 2001.

   [RFC2865]      Rigney, C., Willens, S., Rubens, A., and W. Simpson,
                  "Remote Authentication Dial In User Service (RADIUS)",
                  RFC 2865, June 2000.

   [RFC3022]      Srisuresh, P. and K. Egevang, "Traditional IP Network
                  Address Translator (Traditional NAT)", RFC 3022,
                  January 2001.

   [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.

   [RFC3552]      Rescorla, E. and B. Korver, "Guidelines for Writing
                  RFC Text on Security Considerations", BCP 72,
                  RFC 3552, July 2003.

   [RFC3954]      Claise, B., "Cisco Systems NetFlow Services Export
                  Version 9", RFC 3954, October 2004.

   [RFC4120]      Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
                  Kerberos Network Authentication Service (V5)",
                  RFC 4120, July 2005.

   [RFC4251]      Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
                  Protocol Architecture", RFC 4251, January 2006.

   [RFC4271]      Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
                  Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4301]      Kent, S. and K. Seo, "Security Architecture for the
                  Internet Protocol", RFC 4301, December 2005.

   [RFC4436]      Aboba, B., Carlson, J., and S. Cheshire, "Detecting
                  Network Attachment in IPv4 (DNAv4)", RFC 4436,
                  March 2006.

   [RFC4864]      Van de Velde, G., Hain, T., Droms, R., Carpenter, B.,
                  and E. Klein, "Local Network Protection for IPv6",
                  RFC 4864, May 2007.

   [TACACS+]      Carrel, D. and L. Grant, "The TACACS+ Protocol,
                  Version 1.78", Work in Progress, January 1997.

   [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>.

Appendix A. Case Studies 🍓

In this Appendix, we include several case studies to show why these potential success factors matter 🔍. Many other equally good case studies could have been included, but for the sake of brevity, we only picked a sampling that's enough to back up the conclusions in the body of this document 🫶.

A.1. HTML/HTTP vs. Gopher and FTP 🌐

A.1.1. Initial Success Factors ✨

Positive net value: okay so HTTP [RFC2616] with HTML [RFC1866] gave people substantially more value than Gopher [RFC1436] and FTP [RFC0959] 🔥. Among other things, HTML/HTTP supported forms, which opened the door for commercial uses of the technology 💰. So in this sense, it enabled new scenarios 🌈. It also only needed changes from the entities that got the benefits, so the cost and benefits were aligned 🫶.

Incremental deployability: browsers and servers were incrementally deployable 🦋. Initial browsers were also backward compatible with existing protocols like FTP and Gopher, which is so smart 💅.

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 🎀. The HTML encumbrance only showed up later 💀.

Open specification availability: Yes 💖.

Open maintenance process: not at first, but eventually 🌸. This shows that you don't need an open maintenance process at the start to succeed. It only becomes important after the initial success 👑.

Good technical design: fair 🍓. At the beginning 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 🙈. But they did not stop the protocol from becoming successful 🏆.

A.1.2. Wild Success Factors 🦋

Extensible: extensibility was excellent along multiple dimensions, including HTTP, HTML, graphics, forms, Java, JavaScript, etc. 🧚

No hard scalability bound: excellent 🌟. There was no registration process, unlike Gopher, and that let it scale way better 📈.

Threats sufficiently mitigated: no 💀. There was initially no support for confidentiality (for example, protecting credit card numbers), and HTTP 1.0 had cleartext passwords in Basic auth 😭.

A.1.3. Discussion 💅

HTML/HTTP addressed scenarios that no other protocol addressed ✨. Since deployment was easy, it quickly took off 🔥. Security only became an issue after HTML/HTTP was already successful 🙈. HTML/HTTP's early success happened outside the IETF 🌍. HTTP was standardized and refined later, which fixed some of the limitations 🎀.

A.2. IPv4 vs. IPX 🌸

A.2.1. Initial Success Factors

Positive net value: there were lots of competitors at first, including IPX, AppleTalk, NetBEUI, OSI, and DECNet 🫣. All of them had positive net value 💜. But NetBEUI and DECNet weren't designed for internetworking, which limited their scalability and eventually stunted their growth 😬.

Incremental deployability: none of the competitors (including IPv4) had incremental deployability 🙅‍♀️. Still, there were few enough nodes back then that a flag day was manageable 🗓️.

Open code availability: IPv4 had open code from BSD, but IPX didn't 🔓. Many people argue that this was the main reason IPv4 won 👑.

Restriction-free: Yes for IPv4; No for IPX 💖.

Open specification availability: Yes for IPv4; No for IPX 📜.

Open maintenance process: Yes for IPv4; No for IPX 🛠️.

Good technical design: the initial design of IPv4 was fair, but arguably IPX was better at first 🤔. Improvements to IPv4 like DHCP came much later 🕰️.

A.2.2. Wild Success Factors ✨

Extensible: both IPv4 and IPX could be extended to new transports, new link types, and new applications 🧩.

No hard scalability bound: neither had a hard scalability bound close to its design goals 🌍. IPX arguably scaled higher before it hit any bound 📈.

Threats sufficiently mitigated: neither IPv4 nor IPX had threats sufficiently mitigated 💀.

A.2.3. Discussion 💅

At first, it wasn't clear that IPv4 would win 😳. There were other competitors too, like OSI 🙃. But the Advanced Research Projects Agency (ARPA) funded an IPv4 implementation on BSD 🏛️. That open source move led to lots of others picking up IPv4, and that's what made the difference 🔥. Even though IPX initially had a technically superior design, IPv4 succeeded because of its openness 🫶.

A.3. SSH 🔐

A.3.1. Initial Success Factors

Positive net value: SSH [RFC4251] gave way more value than its competitors 💎. Kerberized telnet required deployment of a Kerberos server 🙄. IPsec required a public key infrastructure (PKI) or pre-shared key authentication 😵. The benefits were comparable, but the overall costs of the alternatives were much higher 💸. They also potentially required deployment by entities that didn't directly get the benefit 🙃. So, unlike the alternatives, the cost and benefits of SSH were aligned 💖.

Incremental deployability: yes! SSH needed SSH clients and servers, but it didn't need a key distribution center (KDC) or credential pre-configuration 🙌.

Open code availability: Yes 🔓.

Restriction-free: it's unclear whether SSH was truly restriction-free or not 🤷‍♀️.

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, which were addressed in SSHv2 🛠️.

A.3.2. Wild Success Factors 🦋

Extensibility: good 🧩. SSH allowed adding new authentication mechanisms 🔑.

No hard scalability bound: SSH had excellent scalability properties 🌟.

Threats sufficiently mitigated: no 💀. SSHv1 was vulnerable to man-in-the-middle attacks 😱.

A.3.3. Discussion 💅

The "leap of faith" trust model (accept an untrusted certificate the first time you connect) got roasted by "experts" at first 🙄. But users loved it 🥰. It gave way more functionality and didn't need a KDC, so it was super easy to deploy 🚀. These factors made SSH a clear winner 👑.

A.4. Inter-Domain IP Multicast vs. Application Overlays 🌊

We're looking at a protocol that hasn't been successful yet (meaning it hasn't met its original design goals) even after a long time has passed 🕰️. Just a heads up: this discussion only covers inter-domain multicast, not intra-domain or intra-subnet multicast 📌.

A.4.1. Initial Success Factors

Positive net value: unclear 🤨. When lots of receivers get the same stream, the benefit relieves pain near the sender, and in some cases it enables new scenarios 🌈. But when few receivers exist, the benefits are only incremental improvements compared with multiple streams 📉. There was positive value in bandwidth savings, but that was offset by the lack of viable business models and the lack of tools 🧰. So the costs generally outweighed the benefits 😬.

The costs also aren't necessarily aligned with the benefits 🙃. Inter-domain multicast requires changes by (at least) applications, hosts, and routers 🖥️. But it's the applications that get the main benefit 🎯. For application layer overlaps, on the other hand, only the applications need to change 💅. So the cost is lower (and so are the benefits), and the cost and benefits are aligned 🫶.

Incremental deployability: poor for inter-domain multicast 😩. It required every router in the end-to-end path between a source and any receiver to support multicast, which severely limited how deployable native multicast was 🚧. The strategy at first was an overlay network (the Multicast Backbone (MBone)) to work around this 🧵. But the overlay network eventually had performance problems at high fan-out points 🥵. So adding another node meant more coordination with other organizations, to find someone who wasn't overloaded and agreed to forward traffic for the new node 🤝.

Incremental deployability was good for application-layer overlays, since only the applications need to change ✨. But the 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 aren't standardized, and are left to each application 📜.

Open maintenance process: Yes for inter-domain multicast. Application-layer overlays aren't standardized, and are left to each application 🛠️.

Good technical design: debatable for inter-domain multicast 🤔. In many respects the 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 don't have that disadvantage, but they also get a smaller benefit 🍃.

A.4.2. Wild Success Factors 🦋

Extensible: Yes 🧩.

No hard scalability bound: inter-domain multicast had scalability issues in terms of the number of groups and the number of sources 📉. But it scaled extremely well in terms of the number of receivers 📈. Application-layer overlays scale well in all dimensions, except that they don't scale as well as inter-domain multicast in terms of bandwidth, since they still result in multiple streams over the same link 🌊.

Threats sufficiently mitigated: no for inter-domain multicast, since untrusted hosts can create state in intermediate routers along an entire path 😱. Better for application-layer multicast 🎀.

A.4.3. Discussion 💅

The benefits weren't enough to outweigh the costs for entities (service providers and application developers) to use it 💸. So instead, the industry has tended to choose application overlays with replicated unicast 🌱.

A.5. Wireless Application Protocol (WAP) 📱

The Wireless Application Protocol (WAP) [WAP] is another protocol that hasn't been successful, but it's worth comparing against other protocols 🧐.

A.5.1. Initial Success Factors

Positive net value: compared to competitors like 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 😩.

Incremental deployability: poor 💀. WAP required a WAP-to-HTTP proxy in the service provider, plus WAP support in phones 📱. Adding a new site often required the service provider to participate 🙄.

Open code availability: No 🔒.

Restriction-free: No. WAP has two patents with royalties required 💸.

Open specification availability: No 🔒.

Open maintenance process: No, there was a US$27000 entrance fee 💸.

Good technical design: No. A common complaint was that WAP was underspecified, so interoperability was difficult 😵‍💫.

A.5.2. Wild Success Factors ✨

Extensible: unknown 🤷‍♀️.

No hard scalability bound: excellent 🌟.

Threats sufficiently mitigated: unknown 🤷‍♀️.

A.5.3. Discussion 💅

WAP had a number of close competitors 🥊. Incremental deployability was easier with those competitors 🦋. The restrictions on code and specification access were significant factors that hindered WAP's ability to succeed 🚧.

A.6. Wired Equivalent Privacy (WEP) 📡

WEP is part of the IEEE 802.11 standard [IEEE-802.11], which succeeded in being widely deployed in spite of its faults 🫠.

A.6.1. Initial Success Factors

Positive net value: yes! WEP provided security when there was no alternative, and it only needed changes from entities that got the benefit 💖.

Incremental deployability: yes! Although you needed to configure both the access point and stations, each wireless network could deploy WEP independently 🦋.

Open code availability: essentially no, because of Rivest Cipher 4 (RC4) 🔒.

Restriction-free: No for RC4, but otherwise yes 🎀.

Open specification availability: No for RC4, but otherwise yes 📜.

Open maintenance process: Yes 🛠️.

Good technical design: No. WEP had an inappropriate use of RC4 💀.

A.6.2. Wild Success Factors 🌸

okay so this is where WEP's real life gets messy 👀. Extensible: IEEE 802.11 was extensible enough that people could build replacements for WEP 🧚. WEP itself, though? Not extensible at all 😭.

No hard scalability bound: No.

Threats sufficiently mitigated: No. 💀

A.6.3. Discussion 💅

WEP wasn't completely open or restriction-free, and its technical design was honestly not it 🙈. But it still got super popular! Why? Because it was incrementally deployable and it gave real value when there was literally no alternative 🫶. This again shows that value and deployability are way more important success factors than technical design or openness, especially when no alternatives exist ✨.

A.7. RADIUS vs. TACACS+ 🦋

A.7.1. Initial Success Factors 👑

Positive net value: Yes for both, and it only required changes by the entities that got the benefit 💖.

Incremental deployability: Yes for both (just change clients and servers) 🍓.

Open code availability: Yes for RADIUS; initially no for TACACS+, but eventually yes.

Restriction-free: Yes for RADIUS; unclear for TACACS+.

Open specification availability: Yes for RADIUS; initially no for TACACS+, but eventually yes.

Open maintenance process: Initially no for RADIUS, but eventually yes. No for 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+ 🌈.

A.7.2. Wild Success Factors ✨

Extensible: Yes for both 🫶.

No hard scalability bound: Excellent for RADIUS (UDP-based); good for TACACS+ (TCP-based) 🔥.

Threats sufficiently mitigated: No for RADIUS. It has no support for confidentiality, existing implementations are vulnerable to dictionary attacks, and the use of MD5 is now vulnerable to collisions 😭. TACACS+ was better since it supported encryption 🔐.

A.7.3. Discussion 🎀

Since both provided positive net value and were incrementally deployable, those factors weren't the deciding ones 🙈. TACACS+ had a better technical design in most respects, and it eventually provided openly available specifications and source code. But RADIUS had an open maintenance process, plus openly available specifications and source code early on, and that was the determining factor 👑. This again shows that a better technical design matters less for success than other factors 💅.

A.8. Network Address Translators (NATs) 🧚

Okay, so NAT isn't strictly speaking a "protocol" per se 🤓. It's more of a "mechanism" or "algorithm". But we include a case study anyway, because there are lots of mechanisms that only require a single entity to change to get the benefit (TCP congestion control algorithms are another example in this class) 🍓. It's important to include this class in the discussion because it's a perfect example of a key point about incremental deployability ✨.

A.8.1. Initial Success Factors 🌸

Positive net value: Yes. NATs let multiple devices connect when only a limited number of addresses were available, and they also provided a (limited) security boundary as a side effect 🛡️. So they both relieved the pain of acquiring multiple addresses and enabled new scenarios. Finally, they only required deployment by the entity that got the benefit 💖.

Incremental deployability: Yes. You could deploy a NAT without coordinating with anyone else, including a service provider 🦋.

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, which led to unpredictable behavior in general. On top of that, NATs caused problems for certain classes of applications 🙃.

A.8.2. Wild Success Factors 💫

Extensible: Fair. NATs supported some but not all UDP and TCP applications. Adding application layer gateway functionality was difficult 😩.

No hard scalability bound: Good. There is a scalability bound (the number of ports available), but it's nowhere near the original design goals 🙌.

Threats sufficiently mitigated: Yes ✅.

A.8.3. Discussion 👑

The absence of an unambiguous specification wasn't a hindrance to initial success, since the test cases weren't well defined. So each implementation could decide for itself which 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 🫶.

Indeed, NAT became wildly successful by being used for additional purposes [RFC4864], and it scaled to a large degree, including multiple levels of NATs in places 🚀. It's giving main character energy 💅✨.

Appendix B. IAB Members at the Time of This Writing 🎀

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

Phone: +1 425 703 8835
EMail: dthaler@microsoft.com

Bernard Aboba
IAB
One Microsoft Way
Redmond, WA  98052
USA

Phone: +1 425 706 6605
EMail: bernarda@microsoft.com

Copyright (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.

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.

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 📚.

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.

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 💜.

📦 where this page comes from