Network Working Group T. Hardie Internet-Draft Qualcomm, Inc. June 2003 Twelve heresies, two visions, and one belief draft-hardie-12-2-1-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The IETF brings together a technical community that shares a common dedication to making the best possible engineering choices and protocol standards for the Internet as whole. The community shares a number of common beliefs, which create the basis of a common work style and inform many of the decisions made within the IETF. As in many communities of believers, some of these beliefs have been elevated to the status of dogma. In the process of considering reform, the treatment of these as unquestionable may be hindering progress. This document challenges some of the beliefs which the author believes have become dogmatic. It also presents two visions for the evolution of the IETF and articulates a single belief. 1. The Heresies 1.1 Rough consensus. "rough consensus and running code" is a way to judge whether or not an an idea will work, not a goal in and of itself. Dave Clark's much-quoted credo for the IETF cites "rough consensus and running code" as the key criteria for decision making in the IETF. Aside from a pleasing alliteration, these two touchstones provide a concise summary of the ideals which guide the IETF's decision making. The first implies an open process in which any technical opinion will be heard and any participant's concerns addressed; the second implies a recognition that any decision must be grounded in solid engineering and the known characteristics of the network and its uses. As touchstones, they are excellent. The aim of the IETF is to make the best possible engineering choices and protocol standards for the Internet as a whole, and these two statements should guide it in making its choices and standards. Note, though, that they should be guidelines, not inflexible rules. We rely on this viewpoint as a way of judging things for many situations, but we can't be hamstrung by it. There are times when the IETF's need to make a decision on a technical point may be greater than its need to use consensus as a process to reach that goal. RFC 3127 documents one such occasion. There are others where the failure to use other methods delayed or destroyed important efforts, and these occasions should warn us not to treat this advice as dogma. 1.2 Working group participation. Working groups need to identify their participants. The IETF uses an open process which allows technical contributions from any one, regardless of affiliation or attendance. This is a good thing. A bad thing which has arisen from that good thing is a reluctance to identify the participants in a working group effort, presumably out of fear that working group "members" will ignore the input of those who are not members and that the openness will thus be compromised. Openness is important, but the result of this choice can be broken working group processes. Chairs and document authors may have to make generic pleas for participation or document review, rather than asking specific individuals to undertake those tasks. Since some of those who might be willing if asked instead assume someone else will take the task, participation is reduced despite there being a pool of participants who are fundamentally committed to the work. Identifying working group participants acknowledges that the IETF is much larger than the current pool of authors or slate of Area Directors and working group chairs. Making participation more explicit improves the ability of those outside a particular effort to tap expertise in it and enables the organization to identify those who may be ready to take on new roles as authors, chairs, or mentors. Identifying participants should not exclude technical comments from those outside an effort who review its work, and checks and balance may, of course, still be needed to make sure such exclusion does not occur. 1.3 Working group oversight. Self-organizing working groups need oversight to ensure that the decisions they reach are the best decisions for the Internet as a whole. A rational decision for a working group may not be the right decision for the IETF as a whole. From some perspectives, it may be rational to resist change to deployed clients, even though they contribute to congestion or lack security. It may be rational to avoid interoperability with competing systems, so that a larger scope for the current effort may be planned. It may even be rational for the working group to replicate at one layer a suite of services developed or being developed at another, so as to avoid dependencies. At the moment, the IETF has poor mechanisms to deal with those tensions, even though most IETF participants would agree that congestion control, security, interoperability, and the reuse of a common core set of services are all laudable design goals. The community reviews charters and constrains them such that efforts are expected to meet certain design goals. There can be pushback during IETF Last Call or during the IESG's review. Fundamentally, though, we trust that participants have internalized the issues and that they, therefore, will handle the tension themselves. That can and does work, but we need other mechanisms to reinforce it: some of those may be training, some may be structural reviews at periodic intervals, and some may be creating methods to ensure that cross-speciality expertise is more consistently available. Some form of oversight is required, though, to ensure that it has worked. The current form, though, is not the only possibility. The IETF might shift to a system in which working groups are not entirely self-organizing but instead requires participation by those with specific expertise or points of view (e.g. security, operations), so that "oversight" is in fact part of normal working group processes. It also might mean oversight by bodies other than those currently handling the task, but with the same duty to examine the working group's output from the broader perspectives available outside the group or its area. 1.4 Interim meetings. Interim meetings are not inherently a bad thing. Working groups need to make progress throughout the year, not just in the period immediately before and after an IETF plenary meeting. While the IETF's main mode of operations, working on mailing lists, supports this goal, face to face time can help. Face to face meetings or open conference calls can help a group make progress by helping focus the participant's efforts and by providing for a quicker exchange of ideas than is possible on mailing lists. Interim meetings can be just as open to those doing the work as the plenary meetings, provided they are well-advertised, planned sufficiently far in advance, and take into account the need for fairness in travel budgeting when selecting locations. Interim meetings do not allow for the same level of interaction outside the core participant group as is allowed by IETF plenary meetings, but minuted results provide a reasonable degree of openness for those not actively engaged in the work. 1.5 Areas. It does make sense to group work together. The existence of useful directorates outside the set of current areas (e.g the LDAP directorate or XML directorate) indicates that this grouping may in fact be valuable at multiple levels, and that some groupings may intersect. The current set of areas and interactions may or may not make sense and may or may not be sufficient, but the idea is fundamentally sound. 1.6 Dependencies. The work of one group must be able to depend on the work of another. An organization with expected output of the IETF must be able to have the work of one unit depend on the work of another. Working groups commonly divide their work into multiple related documents, rather than trying to create a single, monolithic specification. The IETF as a larger community needs to be able to do the same thing, by allowing specific groups' work to depend on that being done at other layers or in other areas. One advantage the IETF has in open review and input is that when one group's lack of conclusive output is gating other work, those waiting can add their energy to the working group they depend on. 1.7 One way. There is no fundamental requirement that the IETF use a single way to make decisions or progress standards. While it is important to specify the ways decisions happen and progress is made, there is no reason to assume that one single process must be used in all cases. Having multiple ways of doing things that fit different circumstances allows us to focus on the output needed, rather than the process used to achieve it. As we consider reform, we must recognize that replacing one single way of doing the work with any other single way of doing the work will move the pain, but may accomplish little else. 1.8 Legal fiction. The IETF operates under a legal fiction that relates its work to ISOC; that fiction needs to be replaced with a new legal fiction that lets the IETF stand apart. The legal fiction that the IETF is an organized activity of ISOC grew out of the need for the IETF to have an organizational home that could provide insurance, legal counsel, and related services. The author believes that it also grew out of the reluctance of many participants in the IETF to be pinned down as a membership organization, for reasons articulated in 1.2, above. To restate those reasons in an organizational form, the author believes that there was considerable concern that those funding the IETF would expect or receive treatment that limited the IETF's ability to make the best engineering decisions for the Internet. Allowing the IETF to exist as an activity, rather than an organization, put it at one remove from direct funding and helped assuage those fears. The IETF existed prior to ISOC's formation, and has related to the IAB, IRTF, RFC Editor and other organizations in ways very different from those currently in place. The current legal fiction has had a host of unintended consequences, and we find ourselves at a moment when ending it makes sense. ISOC has a stable income stream related to PIR's management of the .org TLD, and it has itself created a new structure to refocus its priorities. The IETF, too, is considering reform and in so doing it has the opportunity to put in place other mechanisms to ensure that it retains the ability to make the best possible engineering decisions while obtaining the ability to make more direct decisions about its supporting organizations and external relationships. 1.9 Paid staff. The pride the IETF takes in having volunteer effort should not blind the IETF to the opportunities that having paid staff may represent. There are already a number of critical services that the IETF derives through Memoranda of Understanding or other contracts, and the benefits in event planning, publication services, and related capabilities are clear. There are other areas, such as working group management, where the IETF does not use paid staff and where doing so would represent a fundamental change in the nature of the IETF. There are also, however, some grey areas where having paid staff who worked directly for the IETF might be a significant advantage. An IETF-employed executive director might logically negotiate contracts on its behalf, for example, where one employed via an MoU would be barred from negotiating at least that contract, if not all contracts. 1.10 Document Series. The existence of an independent, technical RFC editor is vital to the ongoing dialog about what technologies and services will improve the Internet. It is also best served by splitting the document series so that IETF-produced documents and other documents published by the RFC editor cannot be confused. At the moment, there is a tension between the community's need and desire for an open publication series which allows for wide-ranging documents exploring the space of packet-switched networking and the community's need for a clear set of specifications for the protocols and practices it has developed. Note, in particular, that the community needs for the set to be clear as well as the documents themselves to be clear. This tension means that attempts to publish the specifications which have not been considered or selected by some working groups face resistance that may derive from the need for a clear set, rather than any inherent flaw in the ideas themselves. The IETF has tried to assuage that tension by supplementary marking, using the "standards track" and "Informational or Experimental" as tags to indicate which documents do and do not belong to the set. This effort has largely failed. It is blurred partly by our own rules, which allow some IETF-produced or set-relevant documents to use the same categories as those outside the IETF set. It is also blurred by the ease of misunderstanding the categories and the ease of elision of the supplementary marking. Further efforts to increase the supplementary marking, with "IESG notes" and similar commentary take a great deal of time and increase the tension between the two needs articulated above. There is also no substantial indication that they are or will be more effective. Eliminating these efforts and returning the others to primary markings is both likely to be more effective and likely to increase the freedom of the RFC editor to publish documents that, in its independent judgement, should be part of the ongoing dialog on how to improve the Internet. 1.11 Personalities. The IETF community has consistently placed its trust in specific individuals, trusting that they had the personal contacts, charisma, or technical knowledge to resolve thorny problems. This trust is a mistake. It is not a mistake because the assessments of those individuals are wrong; it is a mistake because it works around structural problems with the effort and abilities of people who may not always be available. To answer the question: "Should the reform process be managed by the AD for the General area?" with "Sure, I trust Harald to do the job." is confuse the personal abilities and manner of the current person doing the job with the job itself. To scale to a reasonable level, the IETF must be able to define the work associated with specific roles. It can then recruit or train people for those roles. Working the mechanism in reverse, so that the individual's capacities are the primary gauge for the scope of the job occupied, makes for serious succession problems. 1.12 Reform. "If it ain't broke don't fix it" does not apply on a piecemeal basis to complex systems. In a reform process, ruling some items out of bounds for change because they do not cause current pain is a mistake. If you change any fundamental part of a system, you must consider whether the other parts of a system need to be adjusted to handle new load, tasks, or interactions. This does not mean that all change must occur at once, but it does mean that the process of reform must be open to change at all levels. 2. The Visions 2.1 New integration along traditional lines. The author believes that the IETF has traditionally been integrated in two different ways, one formal and one informal. The formal integration relates to the steps of the standards process and the precursor steps of working group formation and chartering. The informal integration is an overlapping set of personal relationships that allows participants to identify skills, perspectives, or energy needed to complete the efforts identified in the formal processes. During a period of rapid growth and a follow-on period of contraction, the second system has been strained to the point of failure. Though the IETF retains a large pool of skilled professionals with energy and needed perspectives, the overlap in personal networks is now not sufficient to associate those with the efforts the IETF has taken on. This has led to delay, lowered quality, and frustration, both among those whose skills and perspectives are not appropriately connected to salient efforts and among those whose efforts have stalled for lack of energy or early input by those with relevant expertise. One path forward for the IETF is to retain much or all of its current formal process, but take the traditionally informal lines of integration and to increase its efforts to create and support them. It may also have to shift some of those lines of integration from the informal to the formal. The SIR proposal, and especially its color-coded variant (SIRS), provides one example of how the IETF might create a formal mechanism (opportunity for early review by those outside an area) to replace the informal mechanism of passing work back and forth among one's colleagues. Beyond that are a host of possible mechanisms. Having an identifiable group of committed participants may create an esprit de corps among those actively participating in a particular working group that will carry on beyond the group's tasks. Initial training sessions can create lines of contact both among a cohort trained together and between those trained and the trainers. That can be extended by fostering round table discussions among participants from different groups, document authors, and chairs. Cross-area and cross-working group integration can be improved by setting up liaison roles. Mentoring programs and peer review systems can be used to create new lines of communication. The connection provided by directorates can also be extended, both by having open-membership directorates for some specific topics and by increasing the amount of inter and intra-group communication expected. None of the changes described above is a magic bullet, and none, at first glance, creates much structural change in the IETF. Each mechanism is, after all, an elaboration of something we already do. It is, instead, a cultural change that suggests the real strength of the IETF is that it brings together folks from substantially different backgrounds who still share a common goal. More importantly, it suggests that to retain that strength the IETF needs to foster mechanisms that brings those folks together early and often. It also presumes that with renewed strength in this core area that the quality problems, delay, and frustration can be addressed within the framework already established. There is a long-held belief by some that the real work of any organization gets done in hallways. For the IETF, the right response to that may be to make sure that the networks of folks in those hallways is vibrant, active, and just as open to new membership and participation as its formal processes have always been. That may mean moving some of those meetings out of the hallway and into meeting rooms and mailing lists, but the trade-off might be worth it. 2.2 Coordination as an alternate path. The vision set out above presumes that the best result is an IETF with approximately the same scope as it has now but an increased effectiveness within that scope. More importantly, it presumes that a tight integration among the different parts of the IETF is of benefit to each of those parts. One contrary view is that the right path may actually be to shift to a model in which the different parts of the IETF are far more loosely integrated than they are now. Under this view, the IETF as a whole should become a coordinating body, which would create and coordinate more focused organizations. To some extent, this view recognizes that a great deal of the work of protocol development and Internet engineering is done outside of the IETF as it stands now, and that this is not likely to change. Rather than attempting to change that fact, it suggests that the IETF should evolve to be a coordinating body that can reconcile the work both of its sub-organizations and those organizations outside the current IETF which wish to be part of the larger framework. It also answers the question of how to maintain informal personal networks by suggesting that the natural size of an organization of this type should be one in which the participants can or would know each other personally. Under such a system, the IETF would create individual organizations for its areas or other suitable clusters of activity, and it would then create a set of mechanisms to coordinate the work in those activities. The individual organizations might have working groups and directorates that behave much as they do now, but the integration with other organizations would be different. These mechanisms might include liaisons, cross-cluster meetings and mailing lists, and periodic review. That coordination could include organizations that have historically been focused on specific applications of IETF technology. At the forefront of this vision of the IETF is the idea that the field of protocol design and Internet engineering is very large and getting larger, and that getting all of the work into a single organization is unwieldy and unlikely. Rather than attempt it, it suggests that the right answer is to create a group of smaller, focused organizations that can take on specific roles. As a coordinating body, the IETF's role would be both to charter new organizations as needed and to coordinate them once chartered. A critical part of that coordination would be ensuring that work done in one organization is reviewed in other organizations whose work would be effected. To some extent, the IETF already holds this vision, since it does not do all protocol design in a single working group or even a single working group per area. Whether it wants to extend that vision to clusters of working groups as a mechanism for scaling may depend on how we balance the types of coordination. It would also depend on the development of a host of subsidiary mechanisms for coordination that we don't have now. Despite that dependence on systems with no running code, there is an argument to be made that this simply recognizes a reality--that groups spin off to take on new tasks--and attempts to enable the IETF to retain a coordination role after that has occurred. As the field expands, this may well be one of the key ways that the IETF can help ensure that engineering decisions take into account what's best for the Internet as a whole. 3. The Belief. The work is worth doing. The IETF has no enforcement power. Every adherent to any standard or engineering recommendation put forward by the IETF follows it voluntarily. That makes clear that the work of the IETF is not to manage the Internet, or even manage protocol development for the Internet. The work of the IETF is to provide a community and set of tools for those who want to see the Internet grow and develop; nothing more. Nothing less. That work is worth doing. 6. Security Considerations. Any change to organizational structure creates risk that attackers will be able to game the new system in ways they could not game the old. 7. IANA Considerations. This document does contain any actions for IANA. 8. Normative References None. 9. Non-Normative References Mitton, D. et al. "Authentication, Authorization, and Accounting: Protocol Evaluation", RFC3127. (RFC3127) Carpenter, B. et al. "Careful Additional Review of Documents (CARD) by Senior IETF Reviewers (SIRS)" draft-carpenter-solution-sirs-01.txt (SIRS) 10. Author's Address Ted Hardie Qualcomm, Inc. 675 Campbell Technology Parkway Suite 200 Campbell, CA U.S.A. EMail: hardie@qualcomm.com Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.