The LEAP Protocol Development Model Mohsen Banan public@mohsen.banan.1.byname.net Version 0.4 First Published: August 4, 2000 Last Updated: June 16, 2000 Copyright fcl 2000 Mohsen Banan Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. A Component of The LEAP Manifesto This article is one of a series of articles describing various aspects of the Mobile Messaging industry and the LEAP protocols. For the complete collection of articles see The LEAP Manifesto [2 ], available at http://www.LeapForum.org/LEAP/Manifesto/roadMap/index.html. The LEAP Manifesto is also available at the Free Proto- cols Foundation website at http://www.FreeProtocols.org/LEAP/Manifesto/roadMap/index.html. 1 Contents 1 Introduction 3 2 Protocol Phases of Development 4 2.1 Initial Protocol Development . . . . . . . 5 2.2 Global Parameter Assignment . . . . . . 5 2.3 Protocol Publication . . . . . . . . . . . . 6 2.4 Patent-Freedom . . . . . . . . . . . . . . 7 2.4.1 The Free Protocols Foundation . . 7 2.4.2 LEAP's Adherence to the FPF Pro- cedures . . . . . . . . . . . . . . * * 9 2.4.3 Author's Patent-Free Declaration 9 2.5 Maintenance and Enhancement . . . . . . 9 2.5.1 Open Maintenance Organizations 10 2.5.2 Working Groups . . . . . . . . . 10 2.5.3 Maintaining Patent-Freedom . . . 11 2.6 Endorsement by a Standards Body . . . . 11 3 Economic Consequences of Protocols 12 3.1 Principles for Maintaining Protocol Integrity 13 4 Standards Organizations: Do They Mean Any- thing? 13 5 Our Independence of the IETF 15 5.1 Do We Need the IETF? . . . . . . . . . . 16 2 1 Introduction Protocols come in all shapes and sizes, and from a variety of sources. Some are proprietary, intended for use exclu- sively by their developer. Others may be "open" in some sense, indicating that they are intended for more general, public usage. In this context, the word "open" can mean any one of several different things. It may mean nothing more than that the protocol has been published by its de- veloper. The protocol may still be very tightly controlled: revision of the protocol may remain the exclusive right of the developer, the protocol may be protected by patent or copyright restrictions, and use of the protocol may re- quire a licensing agreement. This is a very narrow, and to our mind misleading, use of the word "open." At the other extreme, the protocol may be open to a very high degree of public accessibility: it can be pub- lished by an open mechanism such as RFC publication, undergo revision by means of public working groups, and be entirely free of usage restrictions. A protocol satis- fying all these criteria can be said to be "open" in the broadest sense. Protocols are often referred to as "open" to imply that they are open in a broad sense, whereas in fact they are open only in the narrowest sense. To a large extent, the character of a protocol is defined by the processes used to develop it. This article is about a particular set of protocols called called LEAP, or the Lightweight & Efficient Application Protocols. LEAP is a set of high-performance, efficient protocols intended for mobile and wireless applications. The LEAP protocols are intended to be open in the absolutely broadest sense of the word; they are intended to be freely and permanently available, subject to public review and revision, and without usage restrictions of any kind. The processes used to develop the LEAP protocols have been such as to ensure that they have these intended characteristics. In this article we describe the LEAP development pro- cess. In the next section we provide a general description of the various phases of development that a protocol may go through. Then in subsequent sections we describe the specific processes used for the LEAP protocols at each phase of development. In this article we also discuss the enormous economic influences that protocols can exert, and we point out the potential for corruption that inevitably accompanies this. We describe our general philosophy regarding protocol development, and we present what we consider to be the 3 key principles which must be upheld in order to maintain protocol integrity in the face of corrupting influences. Fi- nally, we provide justification for some of the protocol development choices we have made which others may consider to be unconventional or controversial. 2 Protocol Phases of Development Over its lifetime, a protocol typically goes through a num- ber of developmental phases. In general, from conception to decease, a protocol may go through some or all of the following phases: 1. Initial Development. A protocol may be initially developed in a variety of ways, e.g. by a standards organization, a private business, or the academic community. 2. Global Parameter Assignment. If necessary, global parameters must be assigned to the protocol, for example by the IANA. 3. Publication. If the protocol is intended for public usage, as opposed to exclusive in-house usage, then it must be made publicly available, for example by being published as an Internet RFC. 4. Patent-Freedom. If the developers of a protocol intend it to be patent-free rather than proprietary, then they must take appropriate steps to work to- wards a patent-free result. 5. Industry Usage. The ultimate test of a protocol is whether or not it becomes widely accepted and implemented in the industry at large. This is an aspect of protocol evolution which is not under the direct control of its developer. 6. Maintenance and Enhancement. Protocols fre- quently undergo revision and enhancement as a re- sult of experience and/or changing industry require- ments. Depending on the intended character of the protocol, this may take place by closed and propri- etary processes, or by open and public ones. 7. Endorsement by a Standards Body. Once a pro- tocol has become accepted as an industry standard, it may receive the formal sanction of a standards body. Depending on its purpose, nature, and history, a pro- tocol may undergo some, all, or none of these phases. 4 Also, a protocol may iterate through phases (3) to (7) multiple times, as it undergoes maturation via repeated revision and re-publication. In general, the developers of a protocol define and control the policy and processes to be applied to the pro- tocol at every phase of development except (5) and (7). The developers have no direct control of (5) at all, and only minimal influence over (7). The processes used at each phase of development de- termine the character of the resulting protocol. In the fol- lowing sections of this article we will describe the pro- cesses applied to the LEAP protocols at each phase of development except (5). 2.1 Initial Protocol Development The conception and early development of a protocol can take place in a variety of ways. A traditional source of In- ternet protocols is the IETF/IESG. Other sources of pro- tocols are private businesses, the academic community, or even a single individual. In the case of LEAP, initial development of the pro- tocols was carried out by Neda Communications, Inc., a private business. We believe that there is a tendency among established standards bodies to regard their own, officially sanctioned protocols as authoritative, while any other protocol is of questionable worth or validity. However, the history of protocol development does not support this view. Small groups of individuals have created protocols with far-reaching consequences (e.g. the World Wide Web), just as es- tablished standards bodies have created protocols which failed to achieved industry acceptance. For this reason we do not regard any one source of protocols as necessarily superior to any other. 2.2 Global Parameter Assignment It may be necessary to assign global parameters to a pro- tocol. In the case of LEAP, the necessary UDP port assign- ments for ESRO and EMSD have been made through the IANA. 5 2.3 Protocol Publication If a protocol is intended to be an open protocol, as op- posed to an in-house or proprietary one, then it must be made publicly available. This can be accomplished in various ways; the protocol can be self-published by the developer, or it can be published through an independent agency such as the Internet RFC Editor. In common with other Internet protocols, the LEAP protocols have been published in the form of Internet RFCs [3 ], [1 ]. RFC publication provides a number of signifi- cant advantages: - World-Wide Access. RFC publication ensures world- wide access to the published protocol. There are numerous Web and FTP sites world-wide that carry the complete series of RFC documents - if a par- ticular site is busy or unavailable, a person seeking an RFC can simply go to another. - Unrestricted Access. A user may download an RFC publication completely freely, without incur- ring any legal restrictions whatsoever. All that is required to acquire the full text of an RFC is its number or title. There are no copying or other dis- tribution restrictions attached to RFCs. - Permanence. RFC publication is permanent. Even if the creator of a protocol should go out of busi- ness or otherwise become defunct, the RFC itself will remain in existence. - Stability. Once published, an RFC is fixed - it can- not undergo change. If a new revision of the stan- dard must be issued, this is handled by issuing the revision under a new RFC number. - Quality Assurance. The RFC Editor maintains publication quality control, and will decline to pub- lish a document which, in the Editor's opinion, falls below the required technical and/or editorial RFC standards. For these reasons, RFC publication is the traditional, mainstream publication mechanism for Internet protocols, and virtually all Internet-related protocols are published this way. RFC publication of the LEAP protocols ensures that they are freely, easily and permanently accessible to anyone who wishes to use them. 6 2.4 Patent-Freedom If a protocol is intended to be open rather than propri- etary, then the protocol developers may take steps to work towards a patent-free result. In the case of a public protocol, the presence of patented components within the protocol is very undesirable. A public protocol provides a well-defined interoperability specification for an industry, so that businesses and other organizations can create products and services indepen- dently, which can then be relied upon to function and in- teroperate correctly. The protocol is a positive, enabling force for the entire industry. In order for the protocol to play this role, anyone who wishes to implement and use it must be able to do so freely. The presence of patented components within the protocol places restrictions on its usage, and there- fore undermines this purpose. Furthermore, the presence of the patent brings an enormously unfair market advan- tage to the patent holder. By exercising his patent rights, the patent holder can gain financial benefit from compet- ing companies who wish to use the protocol, or can stifle competition altogether by denying the competing com- pany the right to use the protocol at all. Software patents thus pose a significant danger to pro- tocols. In some cases patents become included in proto- cols by accident - that is, without deliberate intentional- ity on the part of the protocol developer. In other cases, however, an unscrupulous company or organization may deliberately introduce patented components into a proto- col, in an attempt to gain market advantage via ownership of the protocol. In either case, the protocol can then be held hostage by the patent-holder, to the great disadvantage of anyone else who may wish to use it. Patented protocols thus have the effect of inhibiting free and open competition, and are therefore highly detrimental to the industry and the consumer. The LEAP protocols are intended to be fully open and without usage restrictions of any kind. We have therefore exercised great diligence throughout their development to ensure their patent-freedom. 2.4.1 The Free Protocols Foundation Various mechanisms exist for working towards a patent- free result. In developing the LEAP protocols, we have adopted a set of procedures defined for this purpose by 7 the Free Protocols Foundation. The Free Protocols Foundation, or FPF, is an indepen- dent, non-profit organization whose mission is to prevent the inclusion of patented components within protocols. The FPF has established a set of policies and procedures for protocol development that is designed to ensure, inso- far as this is possible, that the resulting protocol is patent- free. In general, there may be both an Author and a Work- ing Group involved in the development of a protocol. The Author is the company, organization or other entity that has primary responsibility for the protocol. In some cases, the protocol may also undergo development at the hands of a Working Group - a set of independent in- dividuals or companies who work cooperatively on the protocol, usually via public mailing lists. The FPF de- fines procedures for both Authors and Working Groups, allowing both to participate in the development of a pro- tocol, while still maintaining the patent-free character of the protocol. For example, both an Author and a set of Working Groups are involved in the development of LEAP. As noted above, the LEAP protocols were initially devel- oped by Neda Communications, Inc., and this company continues to take primary responsibility for their mainte- nance. In addition, as described in Section 2.5, continued enhancement and revision of the protocols takes place by means of various Working Groups. Both the Author and the Working Group may wish to make public declarations regarding the patent-freedom of the protocol. The Author may wish to make an initial declaration that the protocol is intended to be patent-free; and the Working Group may wish to make a declaration that it operates according to the FPF Working Group pro- cedures, thereby maintaining the patent-free nature of the protocol. In addition to defining protocol development proce- dures, the FPF also acts as an independent, public forum in which Authors and Working Groups may make these declarations. Such declarations which are submitted to the FPF are published on its website. For complete information on the Free Protocols Foun- dation and its procedures, see the FPF website at http://www.FreeProtocols.org. 8 2.4.2 LEAP's Adherence to the FPF Procedures Development of the LEAP protocols conforms in all re- gards to the processes and procedures of the Free Pro- tocols Foundation. LEAP's compliance with these pro- cesses ensures, insofar as this is possible, that the LEAP protocols are, and will remain, patent-free. We have adopted the FPF processes because they are available for use by any protocol developer, without the requirement that the developer be part of a formal stan- dards organization. Various standards organizations in- clude processes within their protocol development pro- cedures which work towards patent-freedom. In general, however, these patent-free processes are created for the standards organization's internal use, and are not avail- able for a protocol which is not officially sanctioned by the organization. The FPF, on the other hand, is entirely egalitarian, providing the same level of support for patent-freedom to any protocol developer. To our knowledge, the FPF is unique in this regard. 2.4.3 Author's Patent-Free Declaration Neda Communications, Inc., the original Author of the LEAP protocols, has made a declaration to the FPF that the LEAP protocols are intended to be patent-free. This declaration includes statements to the effect that: - To the best of the Author's knowledge, the protocol is not subject to any patent restrictions. - It is the Author's intention to maintain the protocol patent-free. - In the event that the Author becomes aware of any patent restrictions relating to the protocol, or if a patent right assertion is made with respect to the protocol, the Author undertakes to make prompt disclosure of this fact to the FPF. The complete text of the declaration can be seen on the FPF website at http://www.FreeProtocols.org. 2.5 Maintenance and Enhancement Protocols are usually not static, but instead typically un- dergo continued revision and enhancement. Depending on the character of the protocol, this may take place by 9 closed, in-house processes, or by open and public ones. Since LEAP is intended to be a fully open protocol, it is maintained by fully open processes. 2.5.1 Open Maintenance Organizations The LEAP protocols are developed and maintained through a set of public organizations. At present there are three of these: - LeapForum.org. The LEAP Forum is a central clearing-house for information and pointers relat- ing to the LEAP protocols in general. For com- plete information, visit the LEAP Forum website at http://www.leapforum.org/. - ESRO.org. ESRO.org is an open organization for the development and maintenance of the ESRO pro- tocol. For complete information, visit the ESRO website at http://www.esro.org/. - EMSD.org. EMSD.org is an open organization for the development and maintenance of the EMSD protocol. For complete information, visit the EMSD website at http://www.emsd.org/. Additional maintenance organizations are expected to be created as the LEAP protocol family grows. None of these are standards organizations. They are simply forums to allow information exchange and coop- erative effort relating to the LEAP protocols and technol- ogy. Participation in these organizations takes place via various mailing lists which are hosted by each organiza- tion. Any interested company, organization or individual may participate by joining one or more of these mailing lists. Neither the organizations nor their mailing lists have any membership structure; nor does participation require any membership fees or other financial obligation. For more information, and to subscribe to one or more mailing lists, visit the How To Participate area at any of the above websites. 2.5.2 Working Groups In particular, ESRO.org and EMSD.org each host a Work- ing Group mailing list. It is through the Working Group mailing lists that active development of the protocols takes place. Anyone may participate in the development of the 10 ESRO and EMSD protocols by subscribing to the corre- sponding Working Group mailing list. To subscribe to the ESRO Development Working Group mailing list, visit http://www.esro.org/joinESROmailingList/esroSpec.html. To subscribe to the EMSD Development Working Group mailing list, visit http://www.emsd.org/joinEMSDmailingList/emsdSpec.html. This open development process ensures that commen- tary and participation is open to any industry constituency that may be affected by the LEAP protocols. 2.5.3 Maintaining Patent-Freedom Since the LEAP protocols are intended to be patent-free, the Working Groups must function in a way which pre- serves their patent-freedom. All LEAP protocol Work- ing Groups therefore conform fully to the Free Protocols Foundation policies and procedures for Working Groups. These procedures ensure, insofar as possible, that a proto- col remains patent-free despite undergoing collective de- velopment by a public Working Group. For more infor- mation, refer to the FPF website at http://www.FreeProtocols.org. All Working Group contributors are required to ad- here to these procedures. The Working Group imposes adherence to these procedures by requiring that all con- tributors agree to them as a condition of participation. Both the ESRO Development Working Group and the EMSD Development Working Group have made declara- tions to the FPF that they conform fully to its patent-free policies and procedures. The text of these declarations can be seen on the FPF website. 2.6 Endorsement by a Standards Body The ultimate arbiter of any particular protocol is the in- dustry itself, in which a multitude of individual decisions leads to the acceptance or rejection of the protocol. The acceptance of a protocol as a standard is therefore some- thing that occurs independently of formal endorsement by a standards body. Standards organizations such as the IETG/IESG cer- tainly have no monopoly on innovation, creativity, or com- petence. Any company, organization or individual is ca- pable of creating protocols that become successful, far- reaching industry standards, without the sponsorship or sanction of a standards body. 11 For example HTTP, the protocol which forms the ba- sis of world-wide Internet communications, was devel- oped and achieved prominence entirely independently of any formal standards body. The same is true of Pretty Good Privacy (PGP), now a world-wide encryption stan- dard. These and many other protocols became industry standards despite lack of any official endorsement. For these reasons we believe that official endorsement of a protocol as a standard has little meaning, and that genuine legitimacy for a protocol derives from its indus- try usage. We therefore have no immediate plans to sub- ject the LEAP protocols to any formal standards track process. If and when they become widespread within the industry, we may at that time place them on standards track and seek their formal endorsement as a standard. 3 Economic Consequences of Proto- cols In general, protocols are a positive, enabling force for an industry. Protocols define an agreed-upon expected be- haviour, allowing businesses to create products and ser- vices independently of one another, which can then be relied upon to interoperate correctly. It may happen that one or more rival protocols arise, which address more or less the same industry need. Un- der these circumstances the rival protocols will effectively compete with one another, just as products and services do. It is usually most beneficial to the industry for there to be a single commonly-accepted protocol, so it is often the case that one protocol eventually displaces all others, thereby becoming an industry "standard." In the early stages of formation of a new industry, this competition among protocols is of great benefit to the in- dustry. As in the case of products and services, compe- tition is a mechanism for selection of the best. Free and open competition allows the success or failure of proto- cols to be determined on the basis of their merits, and their fitness to serve the overall interests of the industry. In an ideal world, the success of protocols would be determined exlusively on this basis. However, this is not an ideal world, and forces can arise which interfere with the free and fair competitive process. In particular, the adoption of a protocol by an industry can have enormous economic consequences. And where there is money, there is the potential for corruption. Businesses may attempt to exercise control over pro- 12 tocols in various ways. During protocol development, they may seek to introduce patented components into the protocol, that they can subsequently exploit to their ad- vantage. They may seek to control the protocol publi- cation process, thereby allowing them to impose copy- right restrictions on the protocols, or even make unilat- eral, unannounced changes to the protocol specifications. They may develop and/or maintain the protocol by means of closed, exclusionary processes, which deny broad tech- nical review of the protocol, and allow its design to be dictated by minority business self-interests. 3.1 Principles for Maintaining Protocol In- tegrity We believe that there are three basic, fundamental prin- ciples for defending against these sorts of underhanded activities. These are: - Patent-freedom - RFC publication - Maintenance by open organizations Each of these provides a vital assurance of protocol integrity. Patent-freedom ensures that a patent-holder can- not subvert free-market competition among products and services based on the protocol. RFC publication ensures that the protocol is freely available to anyone who wishes to use it. And maintenance by open organizations ensures that development of the protocol takes place by demo- cratic, rather than oligarchic, processes. This trilogy of principles represent the most basic guar- antees of the integrity of a protocol. If any one of these things is missing, then this means that some attempt is being made to control or limit access to the protocol. In the case of a public protocol, there is no valid reason for doing this. 4 Standards Organizations: Do They Mean Anything? In addition to its general, industry-wide economic bene- fits, the adoption of a protocol also brings a unique set of benefits to its developer. These benefits consist of name recognition, and first-mover advantages in terms of de- velopment and sales of services and products based on 13 the protocol. There may also be other significant bene- fits, such as those resulting from ownership of software patents related to the protocol. These benefits can result in a huge financial windfall for the protocol developer. For this reason, the devel- oper has an enormous vested interest in the adoption of his protocol in preference to any others. And this may lead the developer to promote his protocol in ways which subvert the free and fair competitive process among pro- tocols. One of the ways a business may do this is by seeking to exert inappropriate influence or control over the activities of standards organizations. In particular, the developer may seek to have his protocol labelled as a "standard," while denying this label to other protocols. Alternatively, a business or group of businesses may form their own "standards organization" as an exclusive pro- motional vehicle for their own protocol. In either case the standards organization is in effect in the pocket of Big Business, and their discriminatory labelling of their own protocol as a "standard" represents another form of corruption. Though this serves the self-interest of the developer, it is likely to cause the industry to adopt the "wrong" protocol - i.e. not the one that best serves its overall needs. This is enormously detrimental to the in- dustry at large and the consumer. The incentives for businesses to indulge in these un- derhanded tactics is in direct proportion to the size of the industry and the financial stakes. And in the wireless data communications industry, the stakes are very high indeed. As a result of this, we are currently seeing an enor- mous amount of standards-related activity in the wire- less arena. Since 1998 a large number of self-proclaimed standards organizations relating to wireless data have been created, are claiming legitimacy, and are attempting to impose their own protocols on the industry. Among these recently-formed groups are: - Wireless Application Protocol (WAP) Forum - Mobile Internet Phone Services (MIPS) Forum - Global Mobile Commerce Forum (GMCF) - CDMA Development Group (CDG) - Universal Wireless Consortium (UWC) - GSM Alliance - Global TDMA Forum - Mobile Data Initiative 14 - Portable Computer & Communications Association (PCCA) Each of these organizations is an independent entity, with its own claim of legitimacy, its own protocol pub- lication mechanism, and its own set of restrictions and limitations on participation. Beyond the realm of specific wireless subnetworks, there is no reasonable need for this large number of independent standards organizations. Many of these organizations are simply an instrument of Big Business. They are the result of a group of busi- nesses forming an industry association or forum, for the purpose of branding their own protocol as a "standard." At best, this labelling of some protocols but not oth- ers as "standards" is meaningless; it is a semantic shell game. And at worst, this labelling is an attempt by Big Business to market one set of protocols in competition with another. Marketing has its place in the promotion of a company's own products and services. But an industry protocol represents a public trust, and business marketing has no place in this arena. We believe that the ultimate criterion of the legiti- macy of a protocol is its acceptance and usage in the in- dustry at large. And the industry at large is entirely capa- ble of establishing its own winners and losers by means of free and fair competition among protocols. This arbitrary standards labelling serves only to corrupt this competitive process. Our philosophy regarding protocol development re- quires only that the developer make sure that he adheres to the basic trilogy of principles described above. Beyond that, free and fair competition will do the rest. By making it clear that these self-promoting consor- tia have no genuine legitimacy, we seek to reduce their influence and the harm they do to the industry. 5 Our Independence of the IETF We are developing the LEAP protocols independently of the IETF, and we have not sought out their formal en- dorsement by the IETF. Our decision to work independently of the IETF is a result of our previous experiences with IETF. Based on our interactions with the IETF, we have concluded that the illegitimate influence that the IESG and the IAB exert over non-IETF protocol specifications is counterproduc- tive. We believe that the IESG and IAB are both prej- 15 udiced against externally-generate protocols (a frame of mind sometimes referred to as Not Invented Here syn- drome), and that they engage in the active supression of competing protocols which originate outside their own domain. The IETF has become an autocratic organization that acts to suppress innovation rather than encourage it. In- deed, on its own mailing lists, the IETF acronym has been referred to as the "Innovation Extermination Task Force," and the IETF/IESG/IAB has been referred to as a "cult." We do not consider either of these characterizations as being in the least inappropriate. Our conclusion is that Big Business and political in- terests have now taken over the critical decision making processes within the IETF/IESG/IAB. We have come to this conclusion after many years of attempting to work within the system to bring the IETF back to it its original intended purpose. Our interactions with the IETF relating to several issues are publicly available: - The complete record of our communications with the IESG and RFC Editor relating to publication of RFC-2188 is available at http://www.esro.org/communicationRecord/index* *.html. - The complete record of our communications with the IESG relating to the IESG invitation to place RFC-2188 on standards track is available at http://www.esro.org/noStdT* *rack/main.html. - Our complaint regarding the delays in publication of RFC-2188 is available at http://www.esro.org/iesgNote/index.html. - The complete record of our communications with the IESG and RFC Editor relating to publication of RFC-2524 is available at http://www.emsd.org/communicationRecord/index* *.html. Based on the above records we have come to the con- clusion that the IESG is now characterized by irresponsi- bility, incompetence and arrogance. 5.1 Do We Need the IETF? We believe that a lesser IETF will be a better IETF. The IETF has been a source of new protocols in the past, and there is no reason why it cannot continue to create and develop new protocols in the future. But traditionally, the scope of IETF has gone far be- yond this; the IETF has also claimed responsibility for judging, labelling and ratifying protocols. We believe 16 that these IETF functions are unnecessary and inappro- priate. All the functions that the IETF claims to provide can be accomplished by means of: - The Free Protocols Foundation - The RFC publication process - Maintenance by open Working Groups - Free and fair competition among protocols The first three items above are sufficient to ensure that a protocol is patent-free, is freely available, and is open to democratic and egalitarian development processes. And the fourth item above provides a more than ad- equate mechanism for determining which protocols be- come enduring industry standards, and which fall by the wayside. So what positive thing can the IETF offer that is not better provided elsewhere? The answer is: not much. We have no objection to the IETF existing as an en- tity, developing protocols, and making them available for use. What we demand is that other protocols have exactly the same opportunities as those of the IETF. These consist of the opportunity to be made public, and the opportunity to be judged by means of open competition, and on the basis of their merits. What we object to most strenuously, is the IETF/IESG/IAB arrogating to itself the power to quash protocols that it considers to be in competition to its own. This is not the job of the IETF/IESG/IAB; this is the job of fair compe- tition. We believe that the collective intelligence and exper- tise of the Internet technical community is adequate pro- tection against widespread adoption of "wrong" proto- cols, and we believe that the market and the consumer can collectively make the right eventual decisions. The actions of irresponsible entities such as IESG and IAB, claiming illegitimate authority to select winners and losers at the time of initial publication of protocols, on the pre- text of protecting the network and the consumer, in fact does more harm than good. References [1] M. Banan. Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Ver- sion 1.3. Request for Comments (Informational) 17 2524, Neda Communications, Inc., February 1999. Online document is available at ftp://ftp.isi.edu/in- notes/rfc2524.txt. [2] Mohsen Banan. Lightweight & Efficient Applica- tion Protocol (LEAP) Manifesto. Technical Re- port 108-101-01, LEAP Forum, Bellevue, WA, January 2000. Online document is available at http://www.freeprotocols.org/pubs/biblio/108-101- 01/index.html. [3] M. Taylor, J. Cheng, and M. Banan. AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2. Request for Comments (Informational) 2188, Neda Communications, Inc., September 1997. Online document is available at ftp://ftp.isi.edu/in-notes/rfc2188.txt. 18