Internet Draft Crocker and Malamud Expires May 1, 1993 Possible Changes in the Standards Development Process (Draft 5.1) 1. Introduction 1.1 Status of this Memo This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or made obsolete by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. 1.2 Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Status of this Memo . . . . . . . . . . . . . . . . . . 1 1.2 Contents . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 Abstract . . . . . . . . . . . . . . . . . . . . . . . . 2 1.4 Background of POISED Group . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 The Current World . . . . . . . . . . . . . . . . . . . 4 2.2 The Obvious Problems . . . . . . . . . . . . . . . . . . 5 2.3 The Real Problems . . . . . . . . . . . . . . . . . . . 7 3. The Proposed Structure . . . . . . . . . . . . . . . . . . . 9 3.1 The Technical Task Force . . . . . . . . . . . . . . . . 10 PAGE 1 Internet Draft Crocker and Malamud 3.2 Architectural and Process Guidelines . . . . . . . . . . 14 3.3 The Process Board . . . . . . . . . . . . . . . . . . . 16 3.4 The Editor . . . . . . . . . . . . . . . . . . . . . . . 18 4. The Process . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1 Selection of the Leadership . . . . . . . . . . . . . . 19 4.2 Selection of Technical Task Force Leaders . . . . . . . 21 4.3 Openness as a General Principle . . . . . . . . . . . . 24 5. Transition . . . . . . . . . . . . . . . . . . . . . . . . . 25 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 27 7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 1.3 Abstract This document is a response to the call for a working group to examine the Process for Organization of Internet Standards (POISED). The document contains one possible set of solutions to the issues examined by the POISED working group. It does not reflect a position of the working group and is not necessarily a consensus view. The document suggests the replacement of the current technology development bodies of the Internet (the IAB, IETF, IESG, and IRTF) with a new, streamlined structure. We refer to this community as the Technical Task Force of the Internet. In this system, working groups would define problems and review solutions and design teams would come up with solutions to those problems. Working groups would be part of areas. Area Chairs would, together with an Architect and an overall Chair, form a Technical Board, which would manage the workings of the Technical Task Force. A Process Board would provide oversight to the process, requiring that the Technical Task Force develop objective technical and process criteria and adhere to those criteria. The document also deals at length the with questions of accountability of boards to the general membership. The document recommends a set of procedures, such as open meetings, and discusses ways of handling the selection and approval process for personnel changes. The document considers many of these issues within the broader context of the Internet Society as well as the Technical Task Force. PAGE 2 Internet Draft Crocker and Malamud 1.4 Background of POISED Group The Process for Organization of Internet Standards (POISED) working group was formed with the explicit charter to "to examine the Internet standards process and the responsibilities of the IAB, with attention to the relationship between the IAB and IETF/IESG." This Internet Draft examines those issues. In addition to the explicit charter provisions, there was extensive discussion by the POISED group of a variety of other issues such as the structure of the IAB and the by-laws of the Internet Society. We find that the Internet standards process is closely tied to these broader issues and our recommendations thus take a broader scope than might have been initially anticipated. This report is simply a preliminary set of recommendations and should not be taken as the policy of the IETF, the IESG, the IAB, or the Internet Society. It is also important to stress that this report represents our personal views and does not necessarily reflect a consensus view among the POISED working group. In particular, while we make preliminary recommendations it should be stressed that there may be several solutions to these problems and that we make specific recommendations as a method of focusing the discussion, not to forestall any other approaches. The report is a distillation of the views of many people. Members of the Internet Society trustees, the IAB, the IESG, the IRTF, and the IETF have all contributed their input and their insight. We do not cite these many reviewers by name as we feel that this will provide more freedom to reach a compromise in the ensuing discussions. This report begins with an examination of the current process and the problems that process has encountered. Next, we recommend a restructuring of that process, replacing the current organizational framework with a streamlined set of bodies and procedures. I n addition, we examine the role of the Internet Society and provide a set of recommendations on the structure of that society and on the process by which it operates. We conclude with a brief transition plan. Our goal throughout this effort has been to examine structural and procedural changes that will streamline the process of technology development for the Internet, making it smoother, more predictable, PAGE 3 Internet Draft Crocker and Malamud and speedier. We propose a model that we believe will put our best technical leadership at the beginning of the process, and will accelerate technology development while still preserving due process, fairness, and accountability. 2. Background 2.1 The Current World Standards development for the Internet uses a model that is substantially unchanged from the early DARPA roots. The Internet Architecture Board, originally appointed by DARPA, has been a self- selecting body. The IAB appoints two task forces to assist it: o The Internet Engineering Task Force (IETF) o The Internet Research Task Force (IRTF) The IAB appoints a chair of the IETF, who selects a series of Area Directors who serve at his discretion. The collection of Area Directors form the Internet Engineering Steering Group (IESG) which collectively provides technical and process management of the IETF. The Area Directors (AD) in turn may appoint people to an Area Directorate who assist them in the management of the area. Each area has a set of working groups that are formed by the IESG. Each working group is given a charter and a chair, appointed by the IESG. The working group meets at one or more IETFs (and occasionally at other times) and produces one or more specifications. In theory at least, the working group has then fulfilled its charge and disbands. Most working groups set themselves the goal of producing one or more standards-track specifications. The IRTF has a similar structure. The chair of the IAB appoints a chair of the IRTF, who in turn manages an Internet Research Steering Group (IRSG), comprised of the chairs of the various research groups in the IRTF. The work of the IRTF ranges from classical research to advanced development activities, including such notable successes as multicasting and Privacy Enhanced Mail. Recently, the Internet Society was formed as an umbrella group for this process. The Internet Society has a much wider charter than the standards-development functions of the IAB and IETF, but one of the prime motivations for formation of the society was an institutional "home" for the IAB and the IETF, with all the implications of legal protection of the standards-making process. The PAGE 4 Internet Draft Crocker and Malamud Internet Society started with three organizational members, who appointed the first three trustees. These trustees in turn selected the rest of the trustees. The Society has individual and corporate members. Voting rights in the Society are available to individual, not corporate members of the society. Although the by-laws do not specifically require election of trustees, Internet Society officials indicate that their intention is to have the majority of the trustees elected by the membership. The Internet Society trustees are empowered to select members of the IAB. The system has thus evolved that trustees are selected by some method, who in turn appoint IAB members. IAB members select their chair, and also name the chair of the IETF. The IETF chair selects an IESG. 2.2 The Obvious Problems The formation of the POISED group was in reaction to a recent IAB decision, the selection of the International Organization for Standardization (ISO) definition of a Connectionless Network Service (CLNS) as a basis for focusing a long-standing discussion on future evolution of the Internet Protocol. The publication by the IAB of an Internet Draft on IP version 7 was the culmination of several steps. Routing and addressing in the Internet have become increasingly critical issues, with routing tables exploding in size and the IP address space rapidly depleting. Work in the traditional IETF working groups, such as the one working on the Border Gateway Protocol (BGP), did not appear to be making sufficient progress towards a solution. To address these problems, the IAB formed a special Routing and Addressing (ROAD) task force. Selection of a task force by the IAB on an invitation-only basis was a significant departure from the usual IETF tradition of open working groups. The IAB felt that a focused effort by a selected group was needed given the seriousness of the situation. The ROAD group considered the issues at several meetings and in intense electronic mail exchanges, but was unable to make any specific recommendations on a solution to the problems at hand. The ROAD group work was reviewed by the IESG and the IESG made a recommendation for a PAGE 5 Internet Draft Crocker and Malamud period of further study by a series of traditional IETF working groups. That recommendation was forwarded to the IAB. The IAB reviewed the IESG recommendation and felt that the problems at hand were so severe that a more focused effort was needed. It overruled the IESG recommendation and instead proposed that the ISO CLNS be considered as a straw man, and that this straw man be studied intensively by one or more IETF working groups. An Internet Draft was prepared by the IAB. With an IETF meeting coming, the Internet Draft was published and a one-page summary was prepared by the Chair announcing the draft. The depth of community reaction to the IPv7 draft was immediate, loud, and clear. The IESG felt that the decision to focus on one protocol was premature and that the IAB had exceeded its role in the process. Many members of the IETF felt that the IAB had prematurely decided on one technical solution without proper deliberations by an open IETF working group. It was felt by some that the straw man nature of the draft was obscured by the stronger language contained in the one-page summary. However, others feel that the problem was not merely a public relations situation in which the press release was too strong. To many people, the problem was in the decision contained in the underlying draft, not a problem with wording in the summary. The community reaction led to two results. First, the IPv7 decision was set aside and the original IESG recommendation for a period of intensive study of alternative solutions was adopted. Second, the POISED working group was formed to determine if there were steps that could be taken to prevent such a painful level of controversy in the future. Part of the depth of the reaction to the IPv7 decision was rooted in a feeling among many members of the IETF that there had a been a pattern of decisions by the IAB which were out of out of synch with the expectations and desires of the IETF. As is usual in such situations, there were merits in the arguments on both sides. The IAB has always brought important insight and wisdom to bear on the issues at hand. In some of the more spectacular cases, however, it appeared that the decisions of the IAB were in disagreement with the expectations of the membership of the IETF. At the very least there is a pattern of communications problems related to the distance between the IAB and the IETF. PAGE 6 Internet Draft Crocker and Malamud There has been a great deal of discussion on whether a problem exists or not. There is clearly a perceived problem and, in our view, a perceived problem is a real one. In particular, to the extent that perceptions exist that the IAB is isolated, the IETF is irresponsible, or the Internet Society is unresponsive, we must begin to deal with those perceptions. It is important, however, to look beyond the perceptions and attempt to address the real underlying causes. 2.3 The Real Problems One of the biggest problems uncovered during the discussion of the POISED working group has been delay. It is clear that we need to maintain high standards of quality, but is also clear that we have built up a bureaucracy that must be retuned. Specifications are formed by the working group, forwarded to the area directorate, considered by the IESG, then forwarded to the IAB. Multiple levels of review are important, but in many cases the relative functions of the IESG and the IAB are unclear, leading to delay. Additional delay is also built in from reviews by the RFC Editor and by the IETF Secretariat. We do not criticize individual actions here, but do point out that the end result is that documents that have gone through a tremendous amount of effort from the working group are often returned. Delay shows that things are broken on both sides of the process. The IAB has justifiably sent many drafts back after uncovering real and substantial problems in the specifications. The IESG has likewise caused delay, sometimes through the sheer volume of work the volunteers have to manage, sometimes through more systematic problems such as an inefficient use of the IETF secretariat. The problem of delay is a symptom of broader problems throughout the system. One of the biggest reasons for the depth of reaction on the IPv7 controversy, and in many situations, has been the element of surprise. In the case of the IPv7 controversy, for example, few in the community realized that a decision was forthcoming. This surprise appears to be, in great part, responsible for the furor that resulted from the decision. The surprise is a result of the complexity of the system and the fact that all members of the leadership are volunteers with high workloads. The complexity of our process, the distance between PAGE 7 Internet Draft Crocker and Malamud players, and the volume of paperwork, as well as the complexity of the entire technical arena have all combined to make our process uncertain. Surprise carries two kinds of cost. First, it raises the amount of time that it takes to get a standard through the system. Technical specifications are sent back to the working group for refinement, initial approaches are abandoned, and potentially controversial projects are delayed. The real cost of surprise, however, is human. Surprise causes contention in the community and makes it harder for us to work together. People drop out of the system, institutional barriers form between groups such as the IAB and IESG, and we loose the ability to focus on producing technology. A variety of problems have also arisen based on the historical genesis of the structure of the IAB and the IETF. The membership of the IETF views itself as an independent body, yet the reality of the structure is that the IETF is at the bottom of a hierarchy of committees. There is great confusion as to who is in charge. Related to the question of the hierarchy is the question of accountability. Our leaders do not serve fixed terms or have any form of accountability to the membership. A lack of accountability of the leadership to the membership has resulted in a great deal of ill will and situations such as the IPv7 controversy. Accountability is a key issue, and there is a great desire by all involved in the process to avoid a process of accountability that destroys the focus on technical matters that have made the Internet so successful. A process of formal voting and rigid committees, such as is found in ANSI or other standards-making bodies, does not seem to fit the technical focus of our community. Rough consensus has been the process by which all portions of the Internet have made decisions. The IAB functions by consensus, working groups and the IESG also function in this manner. The challenge is to find a way to instill accountability by consensus, yet still maintain due process and, at the same time, rapidly develop and deploy new solutions to pressing technical problems. There is one other set of issues that we found to be crucial. The Internet Society has been formed with clearly laudable intention PAGE 8 Internet Draft Crocker and Malamud of broadening support for the Internet beyond a technical few. The Internet Society has the potential for being an institutional home for technology development in the Internet, yet go far beyond technology development, providing education, a professional society, publications, conferences, and many other desirable functions. The IETF and IAB have been placed under the auspices of the Internet Society. Yet, the number of IETF members who have joined the Internet Society is remarkably low and there is still significant resistance to placement of the IETF within the Internet Society framework. We believe that the Internet Society has a scope beyond that of the IETF, but that the IETF is crucial to the initial development of the Internet Society. There are steps that the Society can take to underscore its commitment to an open, democratic process that will greatly help in gaining the support of the technical development community. In trying to fix these problems, we have avoided focusing on the actions of specific individuals. We feel strongly that the problems facing the Internet community are rooted in the current structure and processes, and will not be fixed through simple changes in personnel. It should be noted, however, that there is considerable feeling at all levels that some personnel changes are needed, but that the current structure makes it very difficult to initiate and complete those personnel changes. A system has built up over time consisting of the IRTF, the IETF, Area Directorates, the IESG, the IAB, and, recently, the Internet Society. All of this superstructure is built on top of the fundamental activities: people developing code and standards and coming to a rough consensus on the best approach. Just as the superstructure has not always functioned perfectly, we are increasingly having problems with working groups not producing solutions of high quality. 3. The Proposed Structure In this section, we propose a revision to the existing structure. Our main goals are to shift away from a focus on the IAB and the IETF as separate organizations and find a way of streamlining the process of technology development. We also try to craft a system that includes due process guarantees to ensure fairness, but at the same PAGE 9 Internet Draft Crocker and Malamud time help preserve our focus on working technology instead of paper standards. 3.1 The Technical Task Force We start by considering all of the organizations as a single community, the Technical Task Force. Our first proposal is thus that the Internet Society charter this group, the Technical Task Force. The Technical Task Force is responsible for standards-development, for the development of technology, and for all of the functions we have grown used to in the IAB, the IRTF, the IESG, and the IETF. We explain in this section how the functions of these different bodies can be streamlined into a simple structure consisting of working groups and design teams, governed by a Process Board and a Technical Board. We attempt to integrate the functions of architectural review and advanced development into the mainstream of the process through an enhanced view of the working group. The core of the process is the working group. We start by concentrating on this core. We can then build up an organizational structure that adds technical review, process guarantees, logistical management, and other functions. The working group is, by definition, an open group looking at a problem. Anybody can attend as an individual. This openness is both essential and inherently inefficient. Working groups often suffer, however, from "design by committee." It is not uncommon, therefore, for small, self-selected groups to form and work out proposals. The proposal for a Simple Management Protocol (SMP) Framework is a notable recent example. The desire for small, self-selecting teams can also be seen in the Research Task Force. IRTF members felt strongly that they had conflicting pressures to make their committees open but to limit participation to focus on problems. The notion of small, self-selected design teams seems both useful and inevitable. We take note of this effect and acknowledge its place in the technical development process. The design team is defined as being closed and self-selecting. The SMP Framework group is an example of a design team. The MIME effort was largely the effort of a few developers working closely together (and also collaborating well with the working group who contributed a great deal to the process). PAGE 10 Internet Draft Crocker and Malamud Some of the IRTF groups function as design teams and have produced valuable contributions ranging from IP multicasting to PEM. Our proposal thus begins with a system of design teams and working groups. In the traditional top-down approach in which leaders set the agenda, a working group is formed with a problem to solve. One or more design teams can go off and try to solve the problem. The resulting solutions are brought before the working group, which decides on the technical merits of the approaches and revises and edits them until a rough consensus is reached. Although design teams are self-selecting groups it is essential that a working group must allow the proposals of all design teams to be heard. If a substantial proposal is on the table, the working group has an obligation to consider it. Any one design team may be closed, but the working group must consider all competing proposals. A design team does not have to be in response to a pre-existing working group. If a group comes in with a substantial proposal to a real problem, there is an obligation to form an open working group to consider that proposal. The working group must give enough time to other design teams to come up with alternative solutions to the problem. Working groups are collected under the umbrella of an area, which has one or more (co-)chairs. We propose that long-term development (the research or advanced development function) and a coherent approach to development (the architecture function) are integral parts of the development of standards. The current partition of architecture to the IAB and research to the IRTF has made it hard to move the results of advanced development into the engineering phases of technology development. It has led to a situation in which some of the best minds are no longer part of the day-to-day development of solutions for the Internet. We thus propose folding many of the architectural, research, and engineering functions into an integrated Technical Task Force. All of these functions are handled through working groups. The traditional working group is the engineering working group, an open forum chartered for a problem of limited scope which operates for a limited duration. A research working group is also an open forum, but operates for a longer duration trying to solve a problem of limited scope. Note PAGE 11 Internet Draft Crocker and Malamud that to the extent that researchers wish to take a few people to try and solve a problem, they may easily do so as a design team. The working group is the open forum where the research results are discussed and reviewed. There are instances where this model may not match the current IRTF structure. In particular, we distinguish between advanced development efforts and true research programs. We use the term research working group as a shorthand for advanced development activities and recognize that true research may not fit in our framework. In particular, there are situations where researchers wish to compare proposals in a closed setting out of a concern that their ideas may be prematurely misinterpreted. We feel that such gatherings have an important place in the development of technology, but might be more appropriately provided by other portions of the Internet Society. The Internet Society provides an important forum for this type of work to take place, existing in proximity to the Technical Task Force without necessarily having to exist within it. We feel that this is a matter that the Internet Society should actively investigate in order to provide a forum that preserves the many positive features of the current IRTF. The third type of group is the architectural working group which operates for a longer duration, trying to solve a problem of broader scope. Normally, an area will have one architectural working group, but on occasion it may make sense for more than one to exist. It may also be useful for two or more areas to share a single architectural working group or for two architectural working groups in different areas to work together on a specific topic. The definition of three forms of working groups is not meant to set definitions in stone. The key point is that a forum is provided for people to try and determine the best solution for predefined problems. The key is the problem to be solved and we describe three forms of working groups only to emphasize that they can perform functions in addition to the production of a standards-track specification. Working groups are collected into areas. The area is managed by one or more area (co-)chairs. The area chair(s) may wish to form an Area Advisory Group (AAG) which serves at the chairs' discretion. The purpose of the AAG will differ by area. In some cases, the AAG will PAGE 12 Internet Draft Crocker and Malamud be a series of "deputy chairs." In other cases, the AAG will be a place where senior members of the community can provide advice. We feel it is inappropriate to decide the structure of these bodies as the matter should be left to the discretion of the Area Chair and the Technical Board. The collection of area chairs acts as the governing body for standards development and other technical aspects of the process. We call this body the Technical Board. The Technical Board has a chair, who is the leader of the Technical Task Force of the Internet. We envision the chair of the Technical Board as being a different person from the Area Chairs. Members of the Technical Board would serve for two-year terms, ensuring that the line management of the working groups is highly responsive to the technical community. We also recognize the tremendous time commitment by dedicated volunteers for these positions and feel that two-year terms make it much easier to find talented people to serve. We do not see a need for term limitations to prevent a person from serving multiple terms. We envision the definition of areas to be fluid, changing according to the technical needs of the community. It is a crucial part of our proposal that we continue to avoid the turf wars that other standards bodies have found in standing, permanent committees. We do not have those turf wars and we wish to retain this very important feature of the IETF. It is an important feature of our system that it is the working groups that form the Technical Task Force and that area definitions are simply a management tool. We do not split areas by some rigid definition: some are layers in the protocol stack, some are functional areas. We feel this fluid approach where all the working groups are the Technical Task Force is crucial. In addition to Area Chairs, the Technical Board would include other positions. We recommend, for instance, that the formal position of Architect be reinstituted. Such a position would provide a valuable function of monitoring the cohesion of the architecture across areas and providing the integrated architectural vision that is so sorely needed for the Internet. The Technical Board has overall responsibility for management of the standards process. It is responsible for taking working group PAGE 13 Internet Draft Crocker and Malamud documents that have made it through an area and collectively deciding on the standards status of that document. It is responsible for developing objective criteria by which documents can be judged, then applying those criteria to prospective standards. We would hope that under such a system, the working group becomes the focus of the Technical Task Force. We hope that members of the leadership, ranging from trustees of the Internet Society to the members of the Process and Technical Boards would take an active part in working groups. In summary, we propose a system of working groups and design teams, collected together into an area. The collection of areas forms the Technical Task Force of the Internet. It is the responsibility of this Technical Task Force to develop technology, some of that technology resulting in standards for the Internet. 3.2 Architectural and Process Guidelines The best guarantee of due process is the establishment of a set of objective criteria by which proposals may be judged. It would be the obligation of the Technical Task Force to develop and make widely known those criteria. The IETF and IAB currently have a set of criteria for review, but while great effort has been placed in the development of the 3-stage Proposed, Draft, and Standard status for documents, we feel that not enough attention has been placed on detailed, objective criteria for review. While there are in fact some global criteria (e.g., running code), we feel that it is necessary to have a much richer, detailed body of literature that details our design decisions and our operating procedures. This does not, however, mean that we must have a complicated rule book or a bureaucratic straightjacket. Properly formulated criteria can help move the system along and keep the focus on technical quality. Criteria for review are both technical and procedural. The requirement that a working group presents a fair playing field that allows multiple design teams to compete is an example of a due process requirement. Another example is that if a design team forms independently and comes up with a substantial proposal a working group must be formed to review it. PAGE 14 Internet Draft Crocker and Malamud Many of the procedural requirements come to the very heart of what makes us different from other standards-making bodies. Many of these differences have not been brought out of the realm of collective wisdom and unwritten understandings and made explicit. For example, there is wide consensus that the Internet community makes standards based on things that work. Running code, as David Clark has observed, is the fundamental characteristic that makes the Internet different from other standards-development organizations. Running code as a principle is short-hand for a set of criteria that have developed over time. For routing, for example, a protocol must have three independent, interoperable implementations before being considered as a standard. A more stringent version of the requirement for interoperability would be to require a bakeoff with an independent observer. Another important criterion for review is that a new protocol must not hurt the installed base. The Internet is a working, complex system and it is widely acknowledged that the technical community has an obligation to keep that system going. A criterion for review could thus be published stating that any proposal that adds to an existing protocol will receive increased scrutiny, and anything that changes an existing protocol will receive even greater scrutiny. Similarly, proposals that work at the infrastructural level of the Internet are likely to require more careful review than those that operate at the top level. Specifically, a message of the day protocol that operates on a previously unused port should require a lower level of review than a proposal to change the IP header definition. Making these principles explicit means that there is a basis for judging proposals. If one group advocates a politically correct solution but has no code, the community can point to the requirements and objectively decide against the political solution and for a more technically-based decision. If a group complains that they have a great idea that a working group ignored, we can point to the objective requirements. Procedural requirements go hand-in-hand with architectural requirements. For the Internet, there is no grand architecture against which all proposals can be measured. The architecture of the Internet, as Vinton Cerf has pointed out, can frequently be found in the protocols. Architectural cohesion consists of an examination of PAGE 15 Internet Draft Crocker and Malamud the nitty-gritty details of the individual specifications to see if they match up. We feel that there should be more architectural cohesion in the Internet, hence the proposal to revise the position of Architect of the Internet. However, there are also architectural principles implicit in many IAB decisions. By pulling out those principles, we can begin building a body of written decisions that make explicit our assumptions. In the examination of one specification for example, the IAB discovered a text field in a header that did not specify the character set to be used. Stating that text fields in headers must specify a character set is an example of an architectural principle. By making these principles explicit (and in writing), the community starts to build up a set of objective criteria over time. We want to stress that objective criteria do not mean a reversion to the bureaucratic morass of other organizations: we can preserve and even enhance the qualities that have made the Internet so successful. The use of objective criteria, built on a case by case basis, does not alleviate the need for coherent architectural vision. The two go hand in hand, one providing a bottom up approach, the other a top down design. We need both approaches for the Internet. 3.3 The Process Board While we envision the Technical Task Force establishing standards, there is a need for an independent body to guarantee that the process works properly. We propose the formation of a Process Board consisting of 5 members. Members of the Process Board are selected by the membership of the Technical Task Force subject to ratification or selection by the Internet Society trustees as described below. The Process Board has as its primary obligation preservation of the integrity of the standards-making system. If an individual feels that an action in the Technical Task Force has violated the established procedures, the Process Board will hold a hearing on the matter and render a decision in writing. This review function of the Process Board is, we hope, something that need not be exercised on a frequent basis. The Process Board will not be making technical judgments. It will be judging if the PAGE 16 Internet Draft Crocker and Malamud objective technical and process requirements published by the Technical Task Force have been observed in a specific instance. There will be instances where there are insufficient objective criteria to make a decision. In this case, the Process Board would send the decision back to the Technical Board, directing it to make explicit its criteria for decision. The Technical Board would, if the criteria to be established are substantial enough, hold hearings to determine what its policy should be. For example, in examining a technical decision, if the Technical Board had formed a closed group, the Process Board might have insisted that a working group be formed to define a problem. If one technology had been picked over another, the Process Board might have held hearings on the number of interoperable implementations, whether the working group had a chance to consider alternative solutions, or whether there were concrete criteria established for picking one solution over another. The Process Board could, in our view, even look at a set of criteria and judge that they were not a technically- adequate base for making a decision. We envision this Process Board as having other functions related to the integrity of mechanisms in the Technical Task Force. As discussed below in the section on selection, there needs to be some relationship between the Internet Society and the Task Force. We view the Internet Society trustees as assisting in the selection of membership of the Process Board, thus providing that link. The Process Board, in turn, would, together with the membership of the Technical Task Force, assist in the appointment of the Area Chairs and other members of the Technical Board. The Process Board would also be asked to ratify any reorganization of the Technical Task Force into different areas. In addition, the Process Board would have the responsibility for establishing the high-level technical direction of negotiations with other standards bodies. Much of the liaison with other bodies would be at the working group level, but high-level issues would be handled by the Process Board, based on the overall technical direction established within the Technical Task Force. For example, the Internet Society might wish to establish itself as an international standards-making body under the provisions of the International Telecommunication Union. The organizational PAGE 17 Internet Draft Crocker and Malamud relationship is a matter for decision by the trustees of the Internet Society. Questions of detail at a single protocol are handled by the working group. However, to the extent that we send a delegation to a plenary of a group like the CCITT, we view the Process Board, as the senior members of the technical community, representing us. The Process Board should be constituted with fixed terms. We recommend three-year terms, with the initial five appointments made for staggered terms so that there is an opportunity to select one or two members each year. We feel that this provides a balance between the need for periodic change and the need for terms long enough to give people the independence to make tough decisions. 3.4 The Editor Dissemination of information is a crucial function of the Internet, the Internet Society, and the Technical Task Force. The Request for Comment (RFC) series is the bedrock of the process. The RFCs have built over time and there is great public confusion over the difference between the types of RFCs. We feel that there is a need for a series of informational documents for the community. If a group wishes to document some technical function, for example, it should be able to do so and publish that documentation into the public record without necessarily submitting that information to a working group for approval. It is important, however, to make sure that there is no confusion between these informational documents and standards of the Technical Task Force. We recommend that the Internet Society trustees establish the position of an independent Editor, That Editor is responsible for preserving the integrity and independence of the publication process and the maintenance of an on-line archive that contains standards documents, informational documents, and the agenda, minutes, and decisions of various bodies of the Internet Society. We do not envision the position of Editor being responsible for production of agendas, minutes, and decisions, but will be simply managing the forum where these documents would be placed. This on-line forum would be freely available to the general public using, at a minimum, an e-mail based information server and anonymous FTP. The Editor would be able to use any other methods of dissemination that encouraged broad availability of the public record. PAGE 18 Internet Draft Crocker and Malamud The current funding for the position of Editor of the RFCs, for the computers needed to disseminate information, and for the Internet Assigned Numbers Authority is currently provided for by the U.S. government. These activities take money and the Internet Society will need to work with current funding sources or develop new ones to provide continuity in these essential tasks. Note that this Editor function would not be also responsible for the publication of newsletters, journals, and other material of the Internet Society. We are concerned here only that an independent, technical person be appointed to supervise the publication of the technical documentation of the Internet. We also recommend that the function of the Internet Assigned Numbers Authority (IANA) be undertaken by the Editor. The IANA function is one of the more important examples of technical information that must be maintained, and we believe it makes sense to have this function also be part of the independent position of Editor. In this report, we recommend the appointment of an independent, technical Editor and that this appointment be for a three-year term. We do not, however, address the area of organization of the publications of the Technical Task Force. Specifically, we do not address the question of the organization of the Request for Comment series. 4. The Process 4.1 Selection of the Leadership It is clear that the IETF membership wishes rough consensus to be the grounds for decision-making and there is a clear consensus against a voting process. Rough consensus is an inherently ambiguous process and we believe that the question of how we select our leaders is one of the most crucial elements of this proposal. It is clear that a system of fixed terms is necessary and that the selection of leaders should be with some form of consent by the general membership. We note, however, that defining the membership of the technical task force is difficult. We view the technology development community as being anybody who is on the Internet and who helps deploy solutions. Attendance at the IETF general meetings is not a requirement, nor should it be. PAGE 19 Internet Draft Crocker and Malamud The IETF is a fluid body. As we change physical locations for meetings, the makeup of attendees changes. As we begin to incorporate video and audio broadcasts over the network into our meetings, the definition of presence at a meeting becomes more ambiguous. Finally,one of the big differences between our process and the more traditional standards-making organizations is our emphasis on the use of the network: a large travel budget is not a requirement for participation. The question thus becomes how do we balance the need for accountability to the membership with the inherent difficulty in deciding what that membership is? We find it useful to begin to break the issue down into pieces. In our system, there are three governing bodies that must be selected: o the Internet Society trustees o the Process Board o the Technical Board We begin with the question of the trustees. There has been a desire within the Internet Society to ensure the long-term viability of the body through measures such as appointment of trustees during the initial period of operation. While these concerns are understandable, we feel that if Internet Society is to be viewed as a legitimate body to house the Technical Task Force it is essential that the democratic election of the leadership be clearly established in the by-laws. We propose that the by-laws require election of 1/3 of the trustees every year by the membership. We feel that in an ideal world that all trustees should be elected, but realize that the Internet Society by-laws make such a change dependent on the unanimous consent of all three of the Charter Members. Gaining such unanimous consent may be politically unrealistic, but we do feel it crucial that the by- laws require all other trustees to be elected. In addition, there should be a method by which individual members can nominate potential trustees, either through an open nomination process or one that specifies 1% of the membership can sign a petition to require placement of the individual on the ballot. Again, these provisions are fundamental to the character and nature of an open Internet Society and should be in the by-laws. PAGE 20 Internet Draft Crocker and Malamud One suggestion we have heard repeated several times has been that the Internet Society should place all trustees up for election this year with staggered terms. This approach is similar to the one that was adopted by the Usenix board for its trustees. The effect would be an immediate end to any perceived legitimacy problems and would allow the Internet Society and the standards-making bodies to get on with the technical challenges facing the Internet. We feel such a step is not essential, and that there is merit in the stability of an initially appointed board, but do strongly recommend immediate election of one-third of the trustees and changes in the by-laws to require elections and an open nominating procedure are absolutely essential. 4.2 Selection of Technical Task Force Leadership We now turn our attention to the selection of the governing boards of the Technical Task Force. A wide variety of variants on the rough consensus model have been suggested. We can break the problem of selecting leadership into three parts: o selection of a slate of nominees o selection of one person for the position o ratification of that selection There needs to be some form of link between the technical task force and the Internet Society. We propose that link be at the level of the Process Board. There are two possible models (and infinite variations) for how this might work. In the first model, there is an open nomination process. The trustees select the one of the nominees and the Technical Task Force then ratifies that choice. Ratification of that choice would be through the process of rough consensus. Rough consensus can mean approval by rough consensus, or veto by rough consensus. Veto by rough consensus might be taken to mean that (almost) everybody agrees that the choice is bad, or it might use the standard that a "substantial" number of objections constitutes a veto. We are well aware of the ambiguity in the terms "consensus" and "substantial" and return to that question below. In the second model, the Technical Task Force prepares a slate of a limited number of nominees. This slate is presented to the Internet Society trustees, who make a selection. Note that it is possible that PAGE 21 Internet Draft Crocker and Malamud the number of nominees equals the number of positions, in which case the Internet Society trustees would have been asked to ratify and not select. We are thus faced with a situation that must balance several considerations. First, it is absolutely essential that the selection process be objectively fair. Objectively fair means that we must be able to walk into a litigation situation and demonstrate that the Technical Task Force is not just a cartel formed to freeze out outsiders or limit competition. A second consideration is the desire for accountability to the membership of the Technical Task Force in a way that avoids defining membership. We wish to avoid gaming situations that allow one organization to send many people to a particular meeting, or wait for a particular meeting location to bring up a situation. Rough consensus works well for approval or veto of a specific name, but it is our opinion that this is not an adequate method of deciding who to select. The process of rough consensus for standards making consists of looking a competing proposals and deciding how to proceed. While this process of review and compromise works well for paper proposals, it is very hard to modify people to reflect a consensus. If the Technical Task Force wishes to select its leadership directly, we recommend that objective criteria be established that list qualifications for membership on the Process Board. A working group would be then formed to select potential nominees and those nominees would be presented to the membership at a plenary. If there is no overwhelming consensus on one choice for a position, we feel it essential that the Technical Task Force then forward multiple names to the Internet Society trustees who would make the final selection. If there is a clear consensus within the Technical Task Force, then the trustees are merely asked to ratify the selection. We believe that the standard for selection must be that if a substantial number of people object, there is no consensus and multiple names must be forwarded. Any other procedure leaves us open to charges of an ambiguous, unfair process. PAGE 22 Internet Draft Crocker and Malamud While selection of the Process Board involves the Internet Society trustees, we view the selection of the Technical Board as being a matter for decision solely within the technical community. Again, we recommend a procedure whereby the membership of the Technical Task Force attempt to forge a consensus for members of the Technical Board and that the name is sent to the Process Board for ratification. In the case of a lack of consensus, the Process Board would select the members of the Technical Board from a slate determined by the membership. It is not clear that the use of rough consensus will scale indefinitely. Rough consensus requires that an intervening group make the selection and eventually it may be desirable to move towards direct selection of the Process Board and the Technical Board by the membership of the Technical Task Force. Such a direct selection would require some form of voting. Several proposals have been advanced, such as the requirement that a person have attended n of the last m IETF meetings to be empowered to vote. Another proposal has been that a person must be certified by a board of their peers as to technical competence before being allowed to vote or pass some other form of literacy test. We defer the question of direct voting in this report, but point out that the issue will probably need to be revisited. In addition, we defer the question of "electronic attendees" as a matter that needs to be worked out by the Technical Task Force. In both cases, however, the Technical Task Force would be required to establish objective criteria to preserve due process. One other principle is worth mentioning. Rough consensus is an inherently uncertain procedure. Somebody must decide if that consensus exists. We envision the Chair of the Technical Task Force making that decision, but there is the potential for abuse in such a system. We propose that if 50 people sign (by electronic mail or on paper) a petition protesting any decision of the Technical Task Force, that the Process Board would hold a hearing on the decision to try and determine if there were was truly a basis for deciding on rough consensus. To avoid ambiguity, the Technical Task Force will need to establish as many concrete criteria for decision-making as possible. This makes a determination of a consensus more easily verified. These criteria hold for technical decisions as well as personnel decisions. PAGE 23 Internet Draft Crocker and Malamud Deciding that people in leadership roles should have certain qualifications (e.g., Area Chairs should first have served as working group chairs) will make decision making significantly simpler. 4.3 Openness as a General Principle The Technical Task Force and the Internet Society are more than just a professional society. We are a group that makes standards, and must observe the due process requirements of open decision making appropriate to such a governmental body. We propose that a general set of principles be applied to all meetings of the Technical Board, the Process Board, and the Internet Society trustees. All meetings of these bodies should, as a general rule, be open to observers, should have an agenda published 30 days in advance, and should specify the location of the meeting. In addition, we recommend that individuals be allowed to submit written comments in advance on agenda items and that the chair of the meeting be required to hear oral statements of a representative sample of interested parties. We also recommend that meetings of all three groups use, to the greatest extent possible, the Internet. For example, we believe that it is now technically feasible to have meetings of Internet bodies broadcast audio over the Multicast Backbone (MBONE), enabling those the entire Internet to listen to the process. Finally, we recommend that minutes of the meetings be posted on the network within 30 days and that any decisions on substantive matters be rendered in writing and posted. While meetings of the governing boards must be open and conduct their affairs in an open manner, we feel that it is equally important that the rest of the Society also conduct its affairs in the light of day. When committees are formed, there should be a call to the membership for participation and an open process of selection. When decisions are made or when budgets are decided, it is ultimately in the interests of the Society and its parts to disclose such information. We do note that these general principles cannot be uniformly applied to all situations. For example, the IESG currently conducts a great deal of its work by electronic mail and teleconference and the principle of openness needs to be balanced with the need for keeping the process moving. In addition, there are situations, particularly PAGE 24 Internet Draft Crocker and Malamud relating to personnel matters, that may need to be dealt with in an executive session. We do not wish to determine which situations require modification of the general principles of openness, but do feel that such situations should be the exception, not the rule. When it is necessary to hold a closed meeting, or one held without sufficient notice, this should be a conscious exception to the principles of openness. 5. Transition This report proposes a sweeping set of changes that reorganize the current bodies into a Technical Task Force, a Process Board, and an Editor. All of these would be under the umbrella of the Internet Society, but the Internet Society would underscore the importance of principles such as open meetings and the election of officials by the membership. We believe that the first step is to see if there is a rough consensus among the IETF that these steps would begin to solve the problems that led to the formation of the POISED group. Consensus by the POISED group and more generally in the IETF would be essential preliminary steps. To the extent that there appears to be a clear consensus at the next IETF, a nomination working group could meet and make its initial recommendations. These names would help give an air reality to these proposals, making concrete the types of people that would fill the positions. The working group would be charged with establishing the initial area definitions and the names of the people to fill the two-year positions on the Technical Board. The working group would also establish a set of staggered terms for the Process Board of one, two, and three years and recommend names to fill those positions. The names for both groups would be one person per slot if a consensus is available, or multiple names if a consensus cannot be reached. If accepted by the IETF, we propose that the recommendations and the slate of names be submitted to the Internet Society trustees. We believe that there are many ramifications of the changes here and hope that the trustees would consider these steps at an open meeting where PAGE 25 Internet Draft Crocker and Malamud members of the IETF, the IESG, and the IAB are able to voice their opinions. If in fact there is agreement that the changes are appropriate and the names selected are acceptable, we believe that these changes could be in place as early as the Columbus IETF. This is a rapid change, but we note that the major function of the IETF, the operation of working groups, would not be disrupted. Transition from old bodies to the new ones will certainly require careful coordination, but we anticipate a substantial overlap in personnel making will make this transition challenging yet workable. Simultaneous with the appointment of the Process Board, the Internet Society would have to consider changes in its by-laws. Putting these changes up for an advisory vote by the membership would be one way for the trustees to determine if there is substantial support for the types of process changes we have recommended. Since elections can proceed at the discretion of the trustees under the current by-laws, one procedure would be to put trustees up for election and add on that same ballot a referendum on the proposals presented here. A two-step transition is envisioned. At the November IETF, the proposals are debated. During the next few months, the Internet Society would ratify selections, modify by-laws, and hold elections. At the next IETF, the changes would go into place. We recognize that the transition schedule is aggressive. The problems facing the community are serious and should be addressed. However, our transition plan does depend on a strong consensus emerging around the major details of the structural changes proposed. To the extent that a consensus does not emerge the transition plan should be extended. We do not currently have a structural system in place in the Internet standards-development bodies that allow change to occur gracefully. Appointments have no fixed terms and there are no easy procedures to make changes in process explicit. While quick adoption of a new system may be a bit abrupt, we feel it is essential that we rapidly move towards a system that institutionalizes change. Failure to do so can only lead to another episode like IP version 7. PAGE 26 Internet Draft Crocker and Malamud 6. Conclusion We find that the Internet technical development process has worked well for many years because of its focus on technical content. Rigid separation between an Internet Architecture Board and the technical committees of the IRTF and the IETF have diffused that focus on technical content. The creation of a Technical Task Force that streamlines the operation of technology development would renew the technical focus that we need. Concentration on working groups and design teams will allow the talented engineers and researchers in the community to focus on their work. Process guarantees are absolutely essential in any standards- development body. We find that open meetings with published agendas and written decisions are a crucial element to the preservation of due process. In addition, it is crucial that an explicit set of process and architectural guidelines be developed and published to guide future development, to help train new members of the community, and to preserve a fair and neutral forum for the incorporation of new technology. These objective guidelines enhance the technical process. We have the opportunity to explicitly state requirements such as working code, thus making a clear, objective statement of how we differ from other technology development organizations. Failure to focus on principles such as working code mean that we continue a long slide towards design by committee, complex bureaucracy, and all the other negative aspects of other standards bodies. An explicit focus on principles such as working code and rough consensus allow us to clearly concentrate on what matters: the construction of a billion node network and new ways to use that network. Objective criteria are not enough. We need to have clearly defined leadership positions with fixed terms. Those leadership positions must be accountable to the general membership. Consent of the governed has been the most persistent theme we have heard during the tenure of this working group. In the case of members of the Process Board and the Technical Board, the membership of the Technical Task Force selects criteria for its leadership and comes to a rough consensus on who the leaders might be. If there is not rough consensus, then a set of potential nominees PAGE 27 Internet Draft Crocker and Malamud are selected. For members of the Process Board, the Internet Society trustees either select or ratify members. In the case of the Technical Board, the Process Board either selects or ratifies members. In the case of the Internet Society trustees, we find it crucial that the membership of that Society must select its leaders. The Internet Society is ultimately only as good as its membership and we must trust that membership to make wise decisions. We feel that strong adherence to principles of accountability and openness will allow the technical community to become an integral, active part of the Internet Society. There is one overriding goal in this proposal: allowing the community to get back to the real problems facing us. We need a system that can adapt easily to changing needs without the level of gridlock we have found inherent in the current system. The current system does not adapt well to needs for personnel changes, to needs for structural changes, or to needs for changes in process. We think it is important, indeed crucial, that these changes are put into effect in a manner that preserves the parts of our system that work. In particular, the Internet has many senior leaders who have contributed immensely, both in the past and in the present. If the changes we propose are to work, they will only work if we are able to enlist those leaders. We cannot create a system where our best talent does not want to participate. Finally , we want to see a more flexible, streamlined structure and more objective criteria for making decisions. We feel that these changes will allow us to get back to the consideration of network management that works, routing protocols that scale, a security infrastructure that can be trusted, resource discovery techniques that find information, and the thousands of other technical challenges that face us. 7. Authors' Addresses Steve Crocker Carl Malamud Trusted Information Systems 302 W. Glendale Avenue 3060 Washington Road Alexandria, VA 22301 Glenwood, MD 21738 carl@malamud.com crocker@tis.com This Internet Draft expires May 1, 1993. PAGE 28