idnits 2.17.1 draft-iab-protocol-success-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1190. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1201. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1208. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1214. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 24, 2008) is 5815 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1866 (Obsoleted by RFC 2854) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Thaler 3 Internet-Draft B. Aboba 4 Intended status: Informational IAB 5 Expires: November 25, 2008 May 24, 2008 7 What Makes For a Successful Protocol? 8 draft-iab-protocol-success-04.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 25, 2008. 35 Abstract 37 The Internet community has specified a large number of protocols to 38 date, and these protocols have achieved varying degrees of success. 39 Based on case studies, this document attempts to ascertain factors 40 that contribute to or hinder a protocol's success. It is hoped that 41 these observations can serve as guidance for future protocol work. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 46 1.1. What is Success? . . . . . . . . . . . . . . . . . . . . . 4 47 1.2. Success Dimensions . . . . . . . . . . . . . . . . . . . . 4 48 1.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 5 49 1.3. Effects of Wild Success . . . . . . . . . . . . . . . . . 6 50 1.4. Failure . . . . . . . . . . . . . . . . . . . . . . . . . 6 51 2. Initial Success Factors . . . . . . . . . . . . . . . . . . . 8 52 2.1. Basic Success Factors . . . . . . . . . . . . . . . . . . 8 53 2.1.1. Positive Net Value (Meet a Real Need) . . . . . . . . 8 54 2.1.2. Incremental Deployability . . . . . . . . . . . . . . 10 55 2.1.3. Open Code Availability . . . . . . . . . . . . . . . . 10 56 2.1.4. Freedom From Usage Restrictions . . . . . . . . . . . 11 57 2.1.5. Open Specification Availability . . . . . . . . . . . 11 58 2.1.6. Open Maintenance Processes . . . . . . . . . . . . . . 11 59 2.1.7. Good Technical Design . . . . . . . . . . . . . . . . 11 60 2.2. Wild Success Factors . . . . . . . . . . . . . . . . . . . 12 61 2.2.1. Extensible . . . . . . . . . . . . . . . . . . . . . . 12 62 2.2.2. No Hard Scalability Bound . . . . . . . . . . . . . . 12 63 2.2.3. Threats Sufficiently Mitigated . . . . . . . . . . . . 12 64 3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 6. Informative References . . . . . . . . . . . . . . . . . . . . 14 68 Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 16 69 A.1. HTML/HTTP vs. Gopher and FTP . . . . . . . . . . . . . . . 17 70 A.1.1. Initial Success Factors . . . . . . . . . . . . . . . 17 71 A.1.2. Wild Success Factors . . . . . . . . . . . . . . . . . 17 72 A.1.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 18 73 A.2. IPv4 vs. IPX . . . . . . . . . . . . . . . . . . . . . . . 18 74 A.2.1. Initial Success Factors . . . . . . . . . . . . . . . 18 75 A.2.2. Wild Success Factors . . . . . . . . . . . . . . . . . 18 76 A.2.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 19 77 A.3. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 A.3.1. Initial Success Factors . . . . . . . . . . . . . . . 19 79 A.3.2. Wild Success Factors . . . . . . . . . . . . . . . . . 19 80 A.3.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 20 81 A.4. Inter-domain IP Multicast vs Application overlays . . . . 20 82 A.4.1. Initial Success Factors . . . . . . . . . . . . . . . 20 83 A.4.2. Wild Success Factors . . . . . . . . . . . . . . . . . 21 84 A.4.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 21 85 A.5. Wireless Application Protocol (WAP) . . . . . . . . . . . 21 86 A.5.1. Initial Success Factors . . . . . . . . . . . . . . . 22 87 A.5.2. Wild Success Factors . . . . . . . . . . . . . . . . . 22 88 A.5.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 22 89 A.6. Wired Equivalent Privacy (WEP) . . . . . . . . . . . . . . 22 90 A.6.1. Initial Success Factors . . . . . . . . . . . . . . . 22 91 A.6.2. Wild Success Factors . . . . . . . . . . . . . . . . . 23 92 A.6.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 23 93 A.7. RADIUS vs. TACACS+ . . . . . . . . . . . . . . . . . . . . 23 94 A.7.1. Initial Success Factors . . . . . . . . . . . . . . . 23 95 A.7.2. Wild Success Factors . . . . . . . . . . . . . . . . . 24 96 A.7.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 24 97 A.8. Network Address Translators (NATs) . . . . . . . . . . . . 24 98 A.8.1. Initial Success Factors . . . . . . . . . . . . . . . 24 99 A.8.2. Wild Success Factors . . . . . . . . . . . . . . . . . 25 100 A.8.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 25 101 Appendix B. IAB Members at the time of this writing . . . . . . . 26 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 103 Intellectual Property and Copyright Statements . . . . . . . . . . 27 105 1. Introduction 107 One of the goals of the Internet Engineering Task Force (IETF) is to 108 define protocols which successfully meet their implementation and 109 deployment goals. Based on case studies, this document identifies 110 some of the factors influencing success and failure of protocol 111 designs. It is hoped that this document will be of use to the 112 following audiences: 114 o IESG members deciding whether to charter a Working Group to do 115 work on a specific protocol; 116 o Working Group participants selecting among protocol proposals; 117 o Document authors developing a new protocol specification; 118 o Anyone evaluating the success of a protocol experiment. 120 1.1. What is Success? 122 In discussing the factors that help or hinder the success of a 123 protocol, we need to first define what we mean by "success". A 124 protocol can be successful and still not be widely deployed, if it 125 meets its original goals. However, in this document, we consider a 126 successful protocol to be one that both meets its original goals and 127 is widely deployed. Note that "widely deployed" does not mean 128 "inter-domain"; successful protocols (e.g., DHCP [RFC2131]) may be 129 widely deployed solely for intra-domain use. 131 The following are examples of successful protocols: 133 Inter-domain: IPv4 [RFC0791], TCP [RFC0793], HTTP [RFC2616], DNS 134 [RFC1035], BGP [RFC4271], UDP [RFC0768], SMTP [RFC2821], SIP 135 [RFC3261]. 136 Intra-domain: ARP [RFC0826], PPP [RFC1661], DHCP [RFC2131], RIP 137 [RFC1058], OSPF [RFC2328], Kerberos [RFC4120], NAT [RFC3022]. 139 1.2. Success Dimensions 141 Two major dimensions on which a protocol can be evaluated are scale 142 and purpose. When designed, a protocol is intended for some range of 143 purposes, and was designed for use on a particular scale. 145 Figure 1 graphically depicts these concepts. 147 Scale ^ 148 | 149 | +------------+ 150 | | | 151 | | Original | 152 | | Protocol | 153 | | Design | 154 | | Space | 155 | | | 156 <-----------------------------------------------> Purpose 158 Figure 1 160 According to these metrics, a "successful" protocol is one that is 161 used for its original purpose and at the originally intended scale. 162 A "wildly successful" protocol far exceeds its original goals, either 163 in terms of purpose (being used in scenarios far beyond the initial 164 design) or in terms of scale (being deployed on a scale much greater 165 than originally envisaged) or both. That is, it has overgrown its 166 bounds and has ventured out "into the wild". 168 1.2.1. Examples 170 HTTP is an example of a "wildly successful" protocol that exceeded 171 its design in both purpose and scale: 173 Scale ^ +---------------------------------------+ 174 | | Actual Deployment | 175 | | | 176 | | | 177 | | +------------+ | 178 | | | Original | | 179 | | (Web | Design | (Firewall | 180 | | Services) | Space | Traversal) | 181 | | | (Web) | | 182 <-----------------------------------------------> Purpose 184 Another example of a wildly successful protocol is IPv4. Although it 185 was designed for all purposes ("Everything over IP and IP over 186 Everything"), it has been deployed on a far greater scale than it was 187 originally designed for; the limited address space only became an 188 issue after it had already vastly surpassed its original design. 190 Another example of a successful protocol is ARP. Originally intended 191 for a more general purpose (namely, resolving network layer addresses 192 to link layer addresses regardless of the media type or network layer 193 protocol), ARP was widely deployed for a narrower scope of uses 194 (resolution of IPv4 addresses to Ethernet MAC addresses), but then 195 was adopted for other uses such as detecting network attachment 196 (DNAv4 [RFC4436]). Also, like IPv4, ARP is deployed on a much 197 greater scale (in terms of number of machines, but not number on the 198 same subnet) than originally expected. 200 Scale ^ +-------------------+ 201 | | Actual Deployment | 202 | | | 203 | | | Original Design Space 204 | | +-------------+--------------+ 205 | | |(IP/Ethernet)|(Non-IP) | 206 | |(DNA)| | | 207 | | | |(Non-Ethernet)| 208 | | | | | 209 <-----------------------------------------------> Purpose 211 1.3. Effects of Wild Success 213 Wild success can be both good and bad. A wildly successful protocol 214 is so useful that it can solve more problems or address more 215 scenarios or devices. This may indicate that it is time to revise 216 the protocol to better accommodate the new design space. 218 However, if a protocol is used for a purpose other than what it was 219 designed for: 221 o There may be undesirable side effects because of design decisions 222 that are appropriate for the originally intended purpose, but 223 inappropriate for the new purpose. 224 o There may be performance problems if the protocol was not designed 225 to scale to the extent to which it was deployed. 226 o Implementers may attempt to add or change functionality to work 227 around the design limitations without complete understanding of 228 their effect on the overall protocol behavior and invariants. 229 o Wildly successful protocols become high value targets for 230 attackers because of their popularity and the potential for 231 exploitation of uses or extensions that are less well understood 232 and tested than the original protocol. 234 A wildly successful protocol is therefore vulnerable to "death by 235 success", collapsing as a result of attacks or scaling limitations. 237 1.4. Failure 239 Failure, or the lack of success, cannot be determined before allowing 240 sufficient time to pass (e.g., 5-10 years for an average protocol). 241 Failure criteria include: 243 o No mainstream implementations. There is little or no support in 244 hosts, routers, or other classes of relevant devices. 245 o No deployment. Devices that support the protocol are not 246 deployed, or if they are, then the protocol is not enabled. 247 o No use. While the protocol may be deployed, there are no 248 applications or scenarios that actually use the protocol. 250 At the time a protocol is first designed, the three above conditions 251 hold, which is why it is important to allow sufficient time to pass 252 before evaluating the success or failure of a protocol. 254 The lack of a value chain can make it difficult for a new protocol to 255 progress from implementation to deployment to use. While the term 256 "chicken and egg" problem is sometimes used to describe the lack of a 257 value chain, the lack of implementation, deployment or use is not the 258 cause of failure, it is merely a symptom. 260 There are many strategies that have been used in the past for 261 overcoming the initial lack of implementations, deployment, and use, 262 although none of these guarantee success. For example: 264 o Address a critical and imminent problem. If the need is severe 265 enough, the industry is incented to adopt it as soon as 266 implementations exist, and well-known need is sufficient to 267 motivate implementations. For example, NAT provided an immediate 268 address sharing capability to the individual deploying it 269 (Appendix A.8). Thus, when creating a protocol, consider whether 270 it can be easily tailored or expanded to directly target a 271 critical problem; if it only solves part of the problem, consider 272 what would be needed in addition. 273 o Provide a "killer app" with low deployment costs. This strategy 274 can be used to generate demand where none existed before. See the 275 HTTP case study in Appendix A.1 for an example. 276 o Provide value for existing unmodified applications. This solves 277 the chicken-and-egg problem by ensuring that use exists as soon as 278 the protocol is deployed, and therefore the benefit can be 279 realized immediately. See the WEP case study in Appendix A.6 for 280 an example. 281 o Reduce complexity and cost by narrowing the intended purpose 282 and/or scope to an area where it is easiest to succeed. This may 283 allow removing complexity that is not required for the narrow 284 purpose. Removing complexity reduces the cost of implementation 285 and deployment to where the resulting cost may be very low 286 compared to the benefit. For example, link-scoped multicast is 287 far more successful than, say, inter-domain multicast (see 288 Appendix A.4). 290 o A government or other entity may provide incentives or 291 disincentives that motivate implementation and deployment. For 292 example, specific cryptographic algorithms may be mandated. As 293 another example, Japan started an economic incentive program to 294 generate IPv6 [RFC2460] implementations and deployment. 296 As we will see, such strategies are often successful because they 297 directly target the top success factors. 299 2. Initial Success Factors 301 In this section, we identify factors that contribute to success and 302 "wild" success. 304 Note that a successful protocol will not necessarily include all the 305 success factors and some success factors may be present even in 306 failed designs. Nevertheless, experience appears to indicate that 307 the presence of success factors seems to improve the probability of 308 success. 310 The success factors, and their relative importance, were suggested by 311 a series of case studies (Appendix A). 313 2.1. Basic Success Factors 315 2.1.1. Positive Net Value (Meet a Real Need) 317 It is critical to the success of a protocol that the benefits of 318 deploying the protocol (monetary or otherwise) outweigh the costs, 319 which include: 321 o Hardware cost: Protocols that don't require hardware changes are 322 easier to deploy than those that do. Overlay networks are one way 323 to avoid requiring hardware changes. However, often hardware 324 updates are required even for protocols whose functionality could 325 be provided solely in software. Vendors often implement new 326 functionality only within later branches of the code tree, which 327 may only run on new hardware. As a result, the safest way to 328 avoid hardware upgrade cost is to design for backward 329 compatibility with both existing hardware and software. 330 o Operational interference: Protocols that don't require changes to 331 other operational processes and tools are easier to deploy than 332 ones that do. For example, IPsec [RFC4301] interferes with 333 NetFlow [RFC3954] deep packet inspection which can be important to 334 operators. 336 o Retraining: Protocols that have no configuration, or are very easy 337 to configure/manage, are cheaper to deploy. 338 o Business dependencies: Protocols that don't require changes to a 339 business model (whether for implementers or deployers) are easier 340 to deploy than ones that do. There are costs associated with 341 changing billing and accounting systems and retraining of 342 associated personnel, and in addition the assumptions on which the 343 previous business model was based may change. For example, some 344 time ago many service providers had business models built around 345 dial-up with an assumption that machines were not connected all 346 the time; protocols that desired always-on connectivity required 347 the business model to change since the networks were not optimized 348 for always-on. Similarly, some service providers have business 349 models that assume that upstream bandwidth is underutilized; peer- 350 to-peer protocols may require this business model to change. 351 Finally, many service providers have business models based on 352 charging for the amount of bandwidth consumed on the link to a 353 customer; multicast protocols interfere with this business model 354 since they provide a way for a customer to consume less bandwidth 355 on the source link by sending multicast traffic, as opposed to 356 paying more to source many unicast streams, without having some 357 other mechanism to cover the cost of replication in the network 358 (e.g., router CPU, downstream link bandwidth, extra management). 359 Multicast protocols also complicate business models based on 360 charging the source of traffic based on the amount of multicast 361 replication, since the source may not be able to predict the cost 362 until a bill is received. 364 Similarly, there are many types of benefit, including: 366 o Relieving pain: Protocols that drastically lower costs (monetary 367 or otherwise) that exist prior to deploying the protocol are 368 easier to show direct benefit from, since they address a burning 369 need. 370 o Enabling new scenarios: Protocols that enable new capabilities, 371 scenarios, or user experiences can provide significant value, 372 although the benefit may be harder to realize, as there may be 373 more risk involved. 374 o Incremental improvements: Protocols that provide incremental 375 improvements (e.g., better video quality) generate a small 376 benefit, and hence can be successful as long as the cost is small. 378 There are at least two example cases of cost/benefits tradeoffs. In 379 the first case, even upon initial deployment, the benefit outweighs 380 the cost. In the second case, there is an upfront cost that 381 outweighs the initial benefit, but the benefit grows over time (e.g., 382 as more nodes or applications support it). The former model is much 383 easier to get initial deployment, but over time both can be 384 successful. The second model has a danger for the initial 385 deployments that if others don't deploy the protocol then the initial 386 deployers have lost value, and so they must take on some risk in 387 deploying the protocol. 389 Success most easily comes when the natural incentive structure is 390 aligned with the deployment requirements. That is, those who are 391 required to deploy, manage, or configure something are the same as 392 those who gain the most benefit. In summary, it is best if there is 393 significant positive net value at each organization where a change is 394 required. 396 2.1.2. Incremental Deployability 398 A protocol is incrementally deployable if early adopters gain some 399 benefit even though the rest of the Internet does not support the 400 protocol. There are several aspects to this. 402 Protocols that can be deployed by a single group or team (e.g., 403 intra-domain) have a greater chance of success than those that 404 require cooperation across organizations (or, in the worst case 405 require a "flag day" where everyone has to change simultaneously). 406 For example, protocols that don't require changes to infrastructure 407 (e.g., router changes, service provider support, etc.) have a greater 408 chance of success than ones that do, since less coordination is 409 needed, NAT being a canonical example. Similarly, protocols that 410 provide benefit when only one end changes have a greater chance of 411 success than ones that require both ends of communication to support 412 the protocol. 414 Finally, protocol updates that are backwards compatible with older 415 implementations have a greater chance of success than ones that 416 aren't. 418 2.1.3. Open Code Availability 420 Protocols with freely available implementation code have a greater 421 chance of success than protocols that do not. Often this is more 422 important than any technical consideration. For example, it can be 423 argued that when deciding between IPv4 and IPX [IPX], this was the 424 determining factor, even though in many ways IPX was technically 425 superior to IPv4. Similar arguments have been made for the success 426 of RADIUS [RFC2865] over TACACS+ [TACACS+]. See Appendix A for 427 further discussion. 429 2.1.4. Freedom From Usage Restrictions 431 Freedom from usage restrictions means that anyone who wishes to 432 implement or deploy can do so without legal or financial hindrance. 433 Within the IETF, this point often comes up when evaluating between 434 technologies, one of which has known Intellectual Property associated 435 with it. Often the industry chooses the one with no known 436 Intellectual Property, even if it is technically inferior. 438 2.1.5. Open Specification Availability 440 Open specification availability means the protocol specification is 441 made available to anyone who wishes to use it. This is true for all 442 Internet Drafts and RFCs and has contributed to the success of 443 protocol specifications developed within or contributed to the IETF. 445 The various aspects of this factor include: 447 o World-wide distribution: Is the specification accessible from 448 anywhere in the world? 449 o Unrestricted distribution: Are there no legal restrictions on 450 getting the specification? 451 o Permanence: Does the specification remain even after the creator 452 is gone? 453 o Stable: Is there a stable version of the specification which does 454 not change? 456 2.1.6. Open Maintenance Processes 458 This factor means that the protocol is maintained by open processes, 459 and mechanisms exist for public comment on the protocol, and the 460 protocol maintenance process allows the participation of all 461 constituencies that are affected by the protocol. 463 2.1.7. Good Technical Design 465 This factor means that the protocol follows good design principles 466 that lead to ease of implementation and interoperability, such as 467 those described in "Architectural Principles of the Internet" 468 [RFC1958]. For example, simplicity, modularity, and robustness to 469 failures are all key design factors. Similarly, clarity in 470 specifications is another aspect of good technical design that 471 facilitates interoperability and ease of implementation. However, 472 experience shows that good technical design has minimal impact on 473 initial success compared with other factors. 475 2.2. Wild Success Factors 477 The following factors do not seem to significantly affect initial 478 success, but can affect whether it becomes wildly successful. 480 2.2.1. Extensible 482 Protocols that are extensible are more likely to be wildly successful 483 in terms of being used for purposes outside their original design. 484 An extensible protocol may carry general purpose payloads/options, or 485 may be easy to add a new payload/option type. Such extensibility is 486 desirable for protocols that intend to apply to all purposes (like 487 IP). However, for protocols designed for a specialized purpose, 488 extensibility should be carefully considered before including it. 490 2.2.2. No Hard Scalability Bound 492 Protocols that have no inherent limit near the edge of the originally 493 envisioned scale are more likely to be wildly successful in terms of 494 scale. For example, IPv4 had no inherent limit near its originally 495 envisioned scale; the address space limit was not hit until it was 496 already wildly successful in terms of scale. Another type of 497 inherent limit would be a performance "knee" that causes a meltdown 498 (e.g., a broadcast storm) once a scaling limit is passed. 500 2.2.3. Threats Sufficiently Mitigated 502 The more successful a protocol becomes, the more attractive a target 503 it will be. Protocols with security flaws may still become wildly 504 successful provided that they are extensible enough to allow the 505 flaws to be addressed in subsequent revisions. Examples include 506 SSHv1 and IEEE 802.11 with WEP. However, the combination of security 507 flaws and limited extensibility tends to be deadly. For example, 508 some early server-based multiplayer games ultimately failed due to 509 insufficient protections against cheating, even though they were 510 initially successful. 512 3. Conclusions 514 The case studies described in Appendix A indicate that the most 515 important initial success factors are filling a real need, and being 516 incrementally deployable. When there are competing proposals of 517 comparable benefit and deployability, open specifications and code 518 become significant success factors. Open source availability is 519 initially more important than open specification maintenance. 521 In most cases, technical quality was not a primary factor in initial 522 success. Indeed, many successful protocols would not pass IESG 523 review today. Technically inferior proposals can win if they are 524 openly available. Factors which do not seem to be significant in 525 determining initial success (but may affect wild success) include 526 good design, security, and having an open specification maintenance 527 process. 529 Many of the case studies concern protocols originally developed 530 outside the IETF, which the IETF played a role in improving only 531 after initial success was certain. While the IETF focuses on design 532 quality which is not a factor in determining initial protocol 533 success, once a protocol succeeds, a good technical design may be key 534 to it staying successful, or in dealing with wild success. Allowing 535 extensibility in an initial design enables initial shortcomings to be 536 addressed. 538 Security vulnerabilities do not seem to limit initial success, since 539 vulnerabilities often become interesting to attackers only after the 540 protocol becomes widely deployed enough to become a useful target. 541 Finally, open specification maintenance is not important to initial 542 success since many successful protocols were initially developed 543 outside the IETF or other standards bodies, and were only 544 standardized later. 546 In light of our conclusions, we recommend that the following 547 questions be asked when evaluating protocol designs: 549 o Does the protocol exhibit one or more of the critical initial 550 success factors? 551 o Are there implementers who are ready to implement the technology 552 in ways that are likely to be deployed? 553 o Are there customers (especially high-profile customers) who are 554 ready to deploy the technology? 555 o Are there potential niches where the technology is compelling? 556 o If so, can complexity be removed to reduce cost? 557 o Is there a potential killer app? Or can the technology work 558 underneath existing unmodified applications? 559 o Is the protocol sufficiently extensible to allow potential 560 deficiencies to be addressed in the future? 561 o If it is not known whether the protocol will be successful, should 562 the market decide first? Or should the IETF work on multiple 563 alternatives and let the market decide among them? Are there 564 factors listed in this document which may predict which is more 565 likely to succeed? 567 In the early stages (e.g. BOFs, design of new protocols), evaluating 568 the initial success factors is important in facilitating success. 569 Similarly, efforts to revise unsuccessful protocols should evaluate 570 whether the initial success factors (or enough of them) were present, 571 rather than focusing on wild success which is not yet a problem. For 572 a revision of a successful protocol, on the other hand, focusing on 573 the wild success factors is more appropriate. 575 4. Security Considerations 577 This document discusses attributes that affect the success of 578 protocols. It has no specific security implications. 579 Recommendations on security in protocol design can be found in 580 [RFC3552]. 582 5. IANA Considerations 584 This document requires no actions by the IANA. 586 6. Informative References 588 [IEEE-802.11] 589 IEEE, "Wireless LAN Medium Access Control (MAC) and 590 Physical Layer (PHY) Specifications", ANSI/IEEE 591 Std 802.11, 2007. 593 [IMODE] NTT DoCoMo, "i-mode", 594 . 596 [IPX] Novell, "IPX Router Specification", Novell Part 597 Number 107-000029-001, 1992. 599 [ISO-8879] 600 ISO, "Information processing -- Text and office systems -- 601 Standard Generalized Markup Language (SGML)", ISO 8879, 602 1986. 604 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 605 August 1980. 607 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 608 September 1981. 610 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 611 RFC 793, September 1981. 613 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 614 converting network protocol addresses to 48.bit Ethernet 615 address for transmission on Ethernet hardware", STD 37, 616 RFC 826, November 1982. 618 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 619 STD 9, RFC 959, October 1985. 621 [RFC1035] Mockapetris, P., "Domain names - implementation and 622 specification", STD 13, RFC 1035, November 1987. 624 [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, 625 June 1988. 627 [RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., 628 Torrey, D., and B. Alberti, "The Internet Gopher Protocol 629 (a distributed document search and retrieval protocol)", 630 RFC 1436, March 1993. 632 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 633 RFC 1661, July 1994. 635 [RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup 636 Language - 2.0", RFC 1866, November 1995. 638 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 639 RFC 1958, June 1996. 641 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 642 RFC 2131, March 1997. 644 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 646 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 647 (IPv6) Specification", RFC 2460, December 1998. 649 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 650 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 651 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 653 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 654 April 2001. 656 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 657 "Remote Authentication Dial In User Service (RADIUS)", 658 RFC 2865, June 2000. 660 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 661 Address Translator (Traditional NAT)", RFC 3022, 662 January 2001. 664 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 665 A., Peterson, J., Sparks, R., Handley, M., and E. 666 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 667 June 2002. 669 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 670 Text on Security Considerations", BCP 72, RFC 3552, 671 July 2003. 673 [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 674 9", RFC 3954, October 2004. 676 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 677 Kerberos Network Authentication Service (V5)", RFC 4120, 678 July 2005. 680 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 681 Protocol Architecture", RFC 4251, January 2006. 683 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 684 Protocol 4 (BGP-4)", RFC 4271, January 2006. 686 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 687 Internet Protocol", RFC 4301, December 2005. 689 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 690 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 692 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 693 E. Klein, "Local Network Protection for IPv6", RFC 4864, 694 May 2007. 696 [TACACS+] Carrel, D. and L. Grant, "The TACACS+ Protocol, Version 697 1.78", Internet-Draft (Expired) draft-grant-tacacs-02.txt, 698 January 1997, 699 . 701 [WAP] Open Mobile Alliance, "Wireless Application Protocol 702 Architecture Specification", . 707 Appendix A. Case Studies 709 In this Appendix, we include several case studies to illustrate the 710 importance of potential success factors. Many other equally good 711 case studies could have been included, but, in the interests of 712 brevity, only a sampling is included here that is sufficient to 713 justify the conclusions in the body of this document. 715 A.1. HTML/HTTP vs. Gopher and FTP 717 A.1.1. Initial Success Factors 719 Positive net value: HTTP [RFC2616] with HTML [RFC1866] provided 720 substantially more value than Gopher [RFC1436] and FTP [RFC0959]. 721 Among other things, HTML/HTTP provided support for forms, which 722 opened the door for commercial uses of the technology. In this 723 sense, it enabled new scenarios. Furthermore, it only required 724 changes by entities that received benefits and hence the cost and 725 benefits were aligned. 727 Incremental deployability: Browsers and servers were incrementally 728 deployable, but initial browsers were also backwards compatible with 729 existing protocols such as FTP and Gopher. 731 Open code availability: Server code was open. Client source code was 732 initially open to academic use only. 734 Restriction-free: Academic use licenses were freely available. HTML 735 encumbrance only surfaced later. 737 Open specification availability: Yes. 739 Open maintenance process: Not at first, but eventually. This 740 illustrates that it is not necessary to have an open maintenance 741 process at first to achieve success. The maintenance process becomes 742 important after initial success. 744 Good technical design: Fair. Initially there was no support for 745 graphics, HTML was missing many SGML [ISO-8879] features, and HTTP 746 1.0 had issues with congestion control and proxy support. These 747 sorts of issues would typically prevent IESG approval today. 748 However, they did not prevent the protocol from becoming successful. 750 A.1.2. Wild Success Factors 752 Extensible: Extensibility was excellent along multiple dimensions, 753 including HTTP, HTML, graphics, forms, Java, JavaScript, etc. 755 No hard scalability bound: Excellent. There was no registration 756 process, as there was with Gopher, which allowed it to scale much 757 better. 759 Threats sufficiently mitigated: No. There was initially no support 760 for confidentiality (e.g., protection of credit card numbers), and 761 HTTP 1.0 had cleartext passwords in Basic auth. 763 A.1.3. Discussion 765 HTML/HTTP addressed scenarios that no other protocol addressed. 766 Since deployment was easy, the protocol quickly took off. Only after 767 HTML/HTTP became successful did security become an issue. HTML/ 768 HTTP's initial success occurred outside the IETF, although HTTP was 769 later standardized and refined, addressing some of the limitations. 771 A.2. IPv4 vs. IPX 773 A.2.1. Initial Success Factors 775 Positive net value: There were initially many competitors, including 776 IPX, AppleTalk, NetBEUI, OSI, and DECNet. All of them had positive 777 net value. However, NetBEUI, and DECNet were not designed for 778 internetworking, which limited scalability and eventually stunted 779 their growth. 781 Incremental deployability: None of the competitors (including IPv4) 782 had incremental deployability, although there were few enough nodes 783 that a flag day was manageable at the time. 785 Open code availability: IPv4 had open code from BSD, whereas IPX did 786 not. Many argue that this was the primary reason for IPv4's success. 788 Restriction-free: Yes for IPv4, No for IPX. 790 Open specification availability: Yes for IPv4, No for IPX. 792 Open maintenance process: Yes for IPv4, No for IPX. 794 Good technical design: The initial design of IPv4 was fair, but 795 arguably IPX was initially better. Improvements to IPv4 such as DHCP 796 came much later. 798 A.2.2. Wild Success Factors 800 Extensible: Both IPv4 and IPX were extensible to new transports, new 801 link types, and new applications. 803 No hard scalability bound: Neither had a hard scalability bound close 804 to the design goals. IPX arguably scaled higher before hitting any 805 bound. 807 Threats sufficiently mitigated: Neither IPv4 nor IPX had threats 808 sufficiently mitigated. 810 A.2.3. Discussion 812 Initially it wasn't clear that IPv4 would win. There were also other 813 competitors, such as OSI. However, ARPA funded IPv4 implementation 814 on BSD and this open source initiative led to many others picking up 815 IPv4 which ultimately made a difference in IPv4 succeeding rather 816 than its competitors. Even though IPX initially had a technically 817 superior design, IPv4 succeeded because of its openness. 819 A.3. SSH 821 A.3.1. Initial Success Factors 823 Positive net value: SSH [RFC4251] provided greater value than 824 competitors. Kerberized telnet required deployment of a Kerberos 825 server. IPsec required a public key infrastructure (PKI) or pre- 826 shared key authentication. While the benefits were comparable, the 827 overall costs of the alternatives were much higher, and they 828 potentially required deployment by entities that did not directly 829 receive benefit. Hence unlike the alternatives, the cost and 830 benefits of SSH were aligned. 832 Incremental deployability: Yes, SSH required SSH clients and servers, 833 but did not require a key distribution center (KDC) or credential 834 pre-configuration. 836 Open code availability: Yes 838 Restriction-free: It is unclear whether SSH was truly restriction- 839 free or not. 841 Open specification availability: Not at first, but eventually. 843 Open maintenance process: Not at first, but eventually. 845 Good technical design: SSHv1 was fair. It had a number of technical 846 issues that were addressed in SSHv2. 848 A.3.2. Wild Success Factors 850 Extensibility: Good. SSH allowed adding new authentication 851 mechanisms. 853 No hard scalability bound: SSH had excellent scalability properties. 855 Threats sufficiently mitigated: No. SSHv1 was vulnerable to man-in- 856 the-middle attacks. 858 A.3.3. Discussion 860 The "leap of faith" trust model (accept an untrusted certificate the 861 first time you connect) was initially criticized by "experts", but 862 was popular with users. It provided vastly more functionality and 863 didn't require a KDC and so was easy to deploy. These factors made 864 SSH a clear winner. 866 A.4. Inter-domain IP Multicast vs Application overlays 868 We now look at a protocol which has not been successful (i.e., has 869 not met its original design goals) after a long period of time has 870 passed. Note that this discussion applies only to inter-domain 871 multicast, not intra-domain or intra-subnet multicast. 873 A.4.1. Initial Success Factors 875 Positive net value: Unclear. When many receivers of the same stream 876 exist, the benefit relieves pain near the sender, and in some cases 877 enables new scenarios. However, when few receivers exist, the 878 benefits are only incremental improvements when compared with 879 multiple streams. While there was positive value in bandwidth 880 savings, this was offset by the lack of viable business models, and 881 lack of tools. Hence the costs generally outweighed the benefits. 883 Furthermore, the costs are not necessarily aligned with the benefits. 884 Inter-domain Multicast requires changes by (at least) applications, 885 hosts, and routers. However, it is the applications that get the 886 primary benefit. For application layer overlaps, on the other hand, 887 only the applications need to change, and hence the cost is lower 888 (and so are the benefits), and cost and benefits are aligned. 890 Incremental deployability: Poor for inter-domain multicast, since it 891 required every router in the end-to-end path between a source and any 892 receiver to support multicast. This severely limited the 893 deployability of native multicast. Initially the strategy was to use 894 an overlay network (the MBone) to work around this. However, the 895 overlay network eventually suffered from performance problems at high 896 fan-out points, and so adding another node required more coordination 897 with other organizations to find someone that was not overloaded and 898 agreed to forward traffic on behalf of the new node. 900 Incremental deployability was good for application-layer overlays, 901 since only the applications need to change. However, benefit only 902 exists when the sender(s) and receivers both support the overlay 903 mechanism. 905 Open code availability: Yes. 907 Restriction-free: Yes. 909 Open specification availability: Yes for inter-domain multicast. 910 Application-layer overlays are not standardized, but left to each 911 application. 913 Open maintenance process: Yes for inter-domain multicast. 914 Application-layer overlays are not standardized, but left to each 915 application. 917 Good technical design: This is debatable for inter-domain multicast. 918 In many respects, the technical design is very efficient. In other 919 respects, it results in per-connection state in all intermediate 920 routers, which is questionable at best. Application-layer overlays 921 do not have the disadvantage, but receive a smaller benefit. 923 A.4.2. Wild Success Factors 925 Extensible: Yes. 927 No hard scalability bound: Inter-domain multicast had scalability 928 issues in terms of number of groups, and in terms of number of 929 sources. It scaled extremely well in terms of number of receivers. 930 Application-layer overlays scales well in all dimensions, except that 931 it does not scale as well as inter-domain multicast in terms of 932 bandwidth since it still results in multiple streams over the same 933 link. 935 Threats sufficiently mitigated: No for inter-domain-multicast, since 936 untrusted hosts can create state in intermediate routers along an 937 entire path. Better for application-layer multicast. 939 A.4.3. Discussion 941 Because the benefits weren't enough to outweigh the costs for 942 entities (service providers and application developers) to use it, 943 instead the industry has tended to choose application overlays with 944 replicated unicast. 946 A.5. Wireless Application Protocol (WAP) 948 The Wireless Application Protocol (WAP) [WAP] is another protocol 949 which has not been successful, but is worth comparing against other 950 protocols. 952 A.5.1. Initial Success Factors 954 Positive net value: Compared to competitors such as HTTP/TCP/IP, and 955 NTT DoCoMo's i-mode [IMODE], the relative value of WAP is unclear. 956 It suffered from a poor experience, and a lack of tools. 958 Incremental deployability: Poor. WAP required a WAP-to-HTTP proxy in 959 the service provider, WAP support in phones, and adding a new site 960 often required participation by the service provider. 962 Open code availability: No. 964 Restriction-free: No. WAP has two patents with royalties required. 966 Open specification availability: No. 968 Open maintenance process: No, there was a US$27000 entrance fee. 970 Good technical design: No, a common complaint was that WAP was 971 underspecified and hence interoperability was difficult. 973 A.5.2. Wild Success Factors 975 Extensible: Unknown. 977 No hard scalability bound: Excellent. 979 Threats sufficiently mitigated: Unknown. 981 A.5.3. Discussion 983 There were a number of close competitors to WAP. Incremental 984 deployability was easier with the competitors, and the restrictions 985 on code and specification access were significant factors that 986 hindered its ability to succeed. 988 A.6. Wired Equivalent Privacy (WEP) 990 WEP is a part of the IEEE 802.11 standard [IEEE-802.11], which 991 succeeded in being widely deployed in spite of its faults. 993 A.6.1. Initial Success Factors 995 Positive net value: Yes. WEP provided security when there was no 996 alternative, and it only required changes by entities that got 997 benefit. 999 Incremental deployability: Yes. Although one needed to configure both 1000 the access point and stations, each wireless network could 1001 independently deploy WEP. 1003 Open code availability: Essentially no, because of RC4. 1005 Restriction-free: No for RC4, but otherwise yes. 1007 Open specification availability: No for RC4, but otherwise yes. 1009 Open maintenance process: Yes. 1011 Good technical design: No, WEP had an inappropriate use of RC4. 1013 A.6.2. Wild Success Factors 1015 Extensible: IEEE 802.11 was extensible enough to enable development 1016 of replacements for WEP. However, WEP itself was not extensible. 1018 No hard scalability bound: No. 1020 Threats sufficiently mitigated: No. 1022 A.6.3. Discussion 1024 Even though WEP was not completely open and restriction free, and did 1025 not have a good technical design, it still became successful because 1026 it was incrementally deployable and it provided significant value 1027 when there was no alternative. This again shows that value and 1028 deployability are more significant success factors than technical 1029 design or openness, particularly when no alternatives exist. 1031 A.7. RADIUS vs. TACACS+ 1033 A.7.1. Initial Success Factors 1035 Positive net value: Yes for both, and it only required changes by 1036 entities that got benefit. 1038 Incremental deployability: Yes for both (just change clients and 1039 servers). 1041 Open code availability: Yes for RADIUS, initially no for TACACS+, but 1042 eventually yes. 1044 Restriction-free: Yes for RADIUS, unclear for TACACS+. 1046 Open specification availability: Yes for RADIUS, Initially no for 1047 TACACS+, but eventually yes. 1049 Open maintenance process: Initially no for RADIUS, but eventually 1050 yes. No for TACACS+. 1052 Good technical design: Fair for RADIUS (there was no confidentiality 1053 support, and no authentication of Access Requests, it had home grown 1054 ciphersuites based on MD5). Good for TACACS+. 1056 A.7.2. Wild Success Factors 1058 Extensible: Yes for both. 1060 No hard scalability bound: Excellent for RADIUS (UDP-based), Good for 1061 TACACS+ (TCP-based). 1063 Threats sufficiently mitigated: No for RADIUS (no support for 1064 confidentiality, existing implementations are vulnerable to 1065 dictionary attacks, use of MD5 now vulnerable to collisions). 1066 TACACS+ was better since it supported encryption. 1068 A.7.3. Discussion 1070 Since both provided positive net value and were incrementally 1071 deployable, those factors were not significant. Even though TACACS+ 1072 had a better technical design in most respects, and eventually 1073 provided openly available specifications and source code, the fact 1074 that RADIUS had an open maintenance process as well as openly 1075 available specifications and source code early on was the determining 1076 factor. This again shows that having a better technical design is 1077 less important in determining success than other factors. 1079 A.8. Network Address Translators (NATs) 1081 Although NAT is not, strictly speaking, a "protocol" per se, but 1082 rather a "mechanism" or "algorithm", we include a case study since 1083 there are many mechanisms that only require a single entity to change 1084 to reap the benefit (TCP congestion control algorithms are another 1085 example in this class) and it is important to include this class of 1086 mechanisms in the discussion since it exemplifies a key point in the 1087 discussion of incremental deployability. 1089 A.8.1. Initial Success Factors 1091 Positive net value: Yes. NATs provided the ability to connect 1092 multiple devices when only a limited number of addresses were 1093 available, and also provided a (limited) security boundary as a side 1094 effect. Hence it both relieved pain involved with acquiring multiple 1095 addresses, as well as enabled new scenarios. Finally, it only 1096 required deployment by the entity that got the benefit. 1098 Incremental deployability: Yes. One could deploy a NAT without 1099 coordinating with anyone else, including a service provider. 1101 Open code availability: Yes. 1103 Restriction-free: Yes at first (patents subsequently surfaced). 1105 Open specification availability: Yes. 1107 Open maintenance process: Yes. 1109 Good technical design: Fair. NAT functionality was underspecified, 1110 leading to unpredictable behavior in general. In addition, NATs 1111 caused problems for certain classes of applications. 1113 A.8.2. Wild Success Factors 1115 Extensible: Fair. NATs supported some but not all UDP and TCP 1116 applications. Adding application layer gateway functionality was 1117 difficult. 1119 No hard scalability bound: Good. There is a scalability bound 1120 (number of ports available), but none near the original design goals. 1122 Threats sufficiently mitigated: Yes. 1124 A.8.3. Discussion 1126 The absence of an unambiguous specification was not a hindrance to 1127 initial success since the test cases weren't well defined and 1128 therefore each implementation could decide for itself what scenarios 1129 it would handle correctly. 1131 Even with its technical problems, NAT succeeded because of the value 1132 it provided. Again this shows that the industry is willing to accept 1133 technically problematic solutions when there is no alternative and 1134 the technology is easy to deploy. 1136 Indeed, NAT became wildly successful by being used for additional 1137 purposes [RFC4864], and to a large scale including multiple levels of 1138 NATs in places. 1140 Appendix B. IAB Members at the time of this writing 1142 Loa Andersson 1143 Leslie Daigle 1144 Elwyn Davies 1145 Kevin Fall 1146 Russ Housley 1147 Olaf Kolkman 1148 Barry Leiba 1149 Kurtis Lindqvist 1150 Danny McPherson 1151 David Oran 1152 Eric Rescorla 1153 Dave Thaler 1154 Lixia Zhang 1156 Authors' Addresses 1158 Dave Thaler 1159 IAB 1160 One Microsoft Way 1161 Redmond, WA 98052 1162 USA 1164 Phone: +1 425 703 8835 1165 Email: dthaler@microsoft.com 1167 Bernard Aboba 1168 IAB 1169 One Microsoft Way 1170 Redmond, WA 98052 1171 USA 1173 Phone: +1 425 706 6605 1174 Email: bernarda@microsoft.com 1176 Full Copyright Statement 1178 Copyright (C) The IETF Trust (2008). 1180 This document is subject to the rights, licenses and restrictions 1181 contained in BCP 78, and except as set forth therein, the authors 1182 retain all their rights. 1184 This document and the information contained herein are provided on an 1185 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1186 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1187 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1188 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1189 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1190 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1192 Intellectual Property 1194 The IETF takes no position regarding the validity or scope of any 1195 Intellectual Property Rights or other rights that might be claimed to 1196 pertain to the implementation or use of the technology described in 1197 this document or the extent to which any license under such rights 1198 might or might not be available; nor does it represent that it has 1199 made any independent effort to identify any such rights. Information 1200 on the procedures with respect to rights in RFC documents can be 1201 found in BCP 78 and BCP 79. 1203 Copies of IPR disclosures made to the IETF Secretariat and any 1204 assurances of licenses to be made available, or the result of an 1205 attempt made to obtain a general license or permission for the use of 1206 such proprietary rights by implementers or users of this 1207 specification can be obtained from the IETF on-line IPR repository at 1208 http://www.ietf.org/ipr. 1210 The IETF invites any interested party to bring to its attention any 1211 copyrights, patents or patent applications, or other proprietary 1212 rights that may cover technology that may be required to implement 1213 this standard. Please address the information to the IETF at 1214 ietf-ipr@ietf.org.