Network Working Group T. Hardie Internet-Draft Editor October 2003 An Outline Proposal for the Means to Accomplish the IETF's Ends. 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 This outline contains a short description of the IETF's core work and a description of structures and processes which might be used to accomplish it. Many of the elements described are already in use either formally or informally. This document does, however, propose some new mechanisms to support the work of the IETF. The IESG does not believe that this document is complete, nor has it decided on a course of action based on this or any other proposal. The IESG does hope that presenting an outline set of mechanisms, both old and new, will foster discussion. The IESG hopes community will consider both whether the mechanisms described here would meet the IETF's needs and, especially, whether the linkages among the abstracted functions it describes are adequate and complete. Table of Contents The IETF community Section 1 The IETF's work Section 2 Investigation Section 2.1 Development Section 2.2 Review Section 2.3 Specification Section 2.4 Assessment Section 2.5 Reporting Section 2.6 Maintenance Section 2.7 Typical flows of activity Section 2.8 Working Group Structure and Activity Section 3 Specification Group. Section 3.1 IANA Team Section 3.2 Exploratory Group Section 3.3 Investigative Group Section 3.4 Working Group Activity Section 3.5 Area Board Structure and Activity Section 4 CREW Structure and Activity Section 5 IESG Structure and Activity Section 6 Directorate Structure and Activity Section 7 IAB Structure and Activity Section 8 The Nominating Committee Section 9 Ombudsperson Section 10 Business Management and Staffing Section 11 External Relationships Section 12 Document Series Section 13 Change Process Section 14 Educational Processes Section 15 Security Considerations Section 16 IANA Considerations Section 17 Normative References Section 18 References Section 19 Normative References Section 19.1 Informative References Section 19.2 Editor's Address Section 20 1. The IETF community. The IETF is a community of active participants dedicated to producing timely, high quality engineering work that describes protocols and practices. These protocols and practices are expected to have secure and scalable implementations. They are also expected to be interoperable and widely deployed. The protocols and practices we work on are either part of the infrastructure of the Internet or they run on top of that infrastructure. To foster interoperability and to further development, the IETF maintains public access to its specifications and public registries of its protocol parameters; it also encourages publication and registration by those who have private extensions that fit within the Internet framework. Where interoperability is served by making this statement, the IETF designates specifications as Internet standards, reflecting the IETF community's belief that the specification is sufficiently advanced to allow for multiple, interoperable implementations and to support widespread deployment on the Internet. The document below puts forward a revised set of structures as the basis for change in the IETF; more importantly, though, it puts forward a set of ongoing activities while will allow the community to continue to adapt its behavior as new challenges arise. In identifying these revisions and activities, the primary motivation has been to enhance the IETF community's ability to produce relevant, high-quality engineering work suitable for deployment on the Internet. It should be noted that the change in these structures is not meant to change the purpose, scope, or activities of the IETF; in protocol terms it is a change in syntax meant to clarify operations, rather than a change in the semantics of those operations. 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 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. These issues have been expressed in the problem statement working group, but a broad range of the symptoms expressed there derive from the same root cause: the IETF has scaled in the past using personal trust networks as a critical part of its infrastructure, and that system cannot meet the current need. This document proposes correcting that problem by shifting the IETF's existing practice toward one in which process plays a larger role. This does not mean that individuals will not be able to contribute in a strongly varied set of ways; it means that IETF will move toward a system in which specific roles have well defined responsibilities, so that the IETF can train, recruit and fill those roles more effectively. The current system, in which the individual's capacities are the primary gauge for the scope of the job occupied, makes for serious problems of scaling and succession. 2. The IETF's work. Prior to describing the structures used to carry out the IETF's activities, it may be useful to provide a short taxonomy of the kinds of work the IETF takes on. The following list is not meant to be exhaustive, and it probably can be visualized best as a set of tasks that create a filter function--generating new ideas related to IP-based technologies, refining a subset of those in community dialog, and creating specifications for their implementation and use. 2.1 Investigation. This is usually limited to the investigation of known problems with the existing Internet infrastructure or protocol suite, rather than open-ended investigation. 2.2 Development. This encompasses both the development of infrastructure protocols and the development of protocols which the IETF believes meet a need for the Internet's users or operators which has previously not been met and for which an interoperable standard is critical or of very significant value. 2.3 Review. The IETF reviews protocols and practices which have been externally developed, provides commentary on these, and may choose to adopt them. 2.4 Specification. The IETF creates specifications of the protocols it has developed and of best practices which have been approved by community consensus. 2.5. Assessment. The IETF assesses the maturity of its specifications. 2.6 Reporting. The IETF documents experiments and their results when those experiments relate to the IETF's core concerns. 2.7 Maintenance. The IETF maintains archives of its specifications, the parameters and values assigned to protocols it has develops, and, as noted above, the results of its experiments. It also maintains attaches its assessments to those specifications. 2.8 Typical flows of activity Below are a few examples of typical activity flows; these are not meant to be exhaustive, but they should serve to illustrate some of the variability in process required to achieve the IETF's goals. 2.8.1 IETF-sponsored Protocol Development Investigation--Development--Specification--Assessment--Maintenance 2.8.2 External Experiment Review--Reporting--Maintenance 2.8.3 External Protocol adopted by the IETF Review--Specification--Assessment--Maintenance 2.8.4 Assessment-derived Protocol Development Assessment--Development--Specification--Assessment--Maintenance 2.8.5 Externally derived Protocol Parameter Review--Maintenance. This section (2.x) is meant to describe the semantics of the operations before the document moves into syntax. This is a 100,000 foot view, and it is a big leap from there to the specifications below. Nevertheless, including some abstract semantics seemed useful as a starting place. 3. Working Group Structure and Activity. Working Groups are the fundamental organizational structure for participation in the IETF. This document describes four types of Working Groups and examines how each fits into the work of the IETF. These types are not immutable; the IETF can eliminate, increase, or change the number of types available as needs arise. These four fit well with common patterns of activity, but it should be noted that those patterns of activity may not fit neatly into these forms in the common case of a working group with multiple projects related to a single goal. It will be common in that case for one project to be, say, in a specification phase and another under investigation. As noted below, different types of groups may be chartered by different organizations within the IETF, and it is requirement in multi-project cases for the primary chartering organization to consult with those responsible for other areas when approving or extending a charter. This is an extension of existing practice, in which the IESG and IAB consult on working group charter decisions. All working groups share certain core attributes: they will have a charter which describes the scope of the work and the tasks to be completed; they will have one or more identified Chairs who are responsible to the community for the group meeting the charter; they will maintain open, public records of their mailing list traffic, face-to-face meetings, and proposals. Note that maintaining a public record of proposals is a new requirement, as historically IETF Working Groups have used a naming convention for Internet Drafts to indicate which proposals were under active development by a Working Group. Since Internet Drafts expire after six months, this record is not always available. In order to maintain a consistent public record, the IETF would now require that any document accepted as work item will be made part of an archival series. This series is described in Section 11, below. An added benefit of this change is that it reduces the likelihood that specifications which are incomplete will be published in the existing archival series when a Working Group fails to complete a work item. This currently occurs fairly frequently when there is a desire to maintain a record of the work done even if it did not complete successfully. 3.1) Specification Group. Specification groups are chartered to develop documents which describe particular protocols or domain-specific best practices for use on the Internet. These charters will normally contain a concise statement of the problem the Specification Group is tackling, the documents expected as the output of the group, and a set of dates by which each of the group's documents is expected. The development of requirements, use cases, or scenarios is out of scope for Specification Groups, as this work should be substantially complete by the time the group is chartered. Note that this does not imply that specific documents addressing each of those points will be required prior to chartering a Specification Group, only that the problem statement and proposed work plan must be clear. Specification groups are chartered by the IESG in consultation with the community and management oversight is provided by the Area Directors for the Area in which they fall. The specification group is a narrower version of the existing Working Group, in that they will not take on use cases, requirements, or scenarios (Exploratory or Investigative Groups might be used to develop those where institutional support is required for that work). 3.2) IANA Team. IANA Teams are Working Groups with very restricted charters, composed of tasks that arise periodically in the extension or maintenance of an existing standard. These teams may, for example, serve as the review groups for IANA registries which require IETF consensus for registration (and as working groups they may issue last calls or otherwise request input from the broader community). They may also serve as technical communities for review of proposals which build upon an existing core technology, in cases where that extension has been defined as a part of the core protocol. Though it is theoretically possible for an IANA team to be in place concurrently with a specification group related to the same protocol or technology, this should arise only when there is no overlap in scope. Because the work of the IANA team is episodic in nature, it is particularly important that it have a core group of committed participants and that its Chair or Chair(s) be able to solicit review from specific individuals; see below, Section 1.5, for further discussion of this point. IANA Teams are chartered by the Area Board for the Area in which they fall, in consultation with the community, and management oversight is provided by the Area Directors for that Area. See below, Section 2, for a description of the Area Boards. This is a new type of group, subsuming some work currently taken on by the IANA review teams and extending it to work done by subject-matter experts and directorates. Originally, this document proposed that these be called "maintenance teams", but it became clear that this constituted an attractive nuisance. Calling them IANA teams eliminates that attraction and fits the core of the role. In particular, it eliminates the possibility of extension by an IANA team for a protocol not explicitly designed for such extension. Again, the line has to be somewhere, and this got moved into a fairly conservative place. It should be noted that it should not be presumed that every Specification Group will be succeeded by an IANAe team. These should be chartered only if the technical work requires this type of effort. Note also that IANA teams are chartered by the Area Board. The underlying theory here is that new work (taken on by an S.G, for example) requires extensive cross-area review, but that the decision on whether existing work will require this type of maintenance is best handled by subject matter experts. 3.3) Exploratory group Exploratory groups are relatively informal groups which carry on discussions about work which might require the attention of the IETF. These groups are essentially self-organizing in the early stages, as those interested in a particular topic or work item informally identify others with similar interests. Those organizing an exploratory group may at some point decide to open the discussion to the IETF community as whole, typically by holding a meeting at one of the IETF meetings sessions. Doing so requires that the organizers provide details of how they meet the basic Working Group requirements: where the archival record of their discussions will be kept, an agenda describing the scope of the discussion for the meeting, and a Chair or Chairs responsible for running the meeting. Exploratory groups may develop use cases, scenarios, or requirements documents as part of their internal efforts to determine whether the work is ready for standardization or a focused investigative activity. Since exploratory groups do not have work plans approved by the IETF community, their proposals are not expected to be archival, but should be published as Internet Drafts so they are available for public review. Approval of proposals for exploratory groups to meet at IETF meetings may be given by the IESG, the IAB, or by any four members of the Area Board of the area in which work will take place. See below, Section 4, for a description of the Area Board. Where there is contention over resources at an IETF meeting, the Secretariat will prefer proposals by date of the confirmed proposal while balancing the needs of different Areas. The IESG has historically approved BoFs after consulting the IAB and discussing the scope with the proposers. Since the right to propose work is one of the most fundamental aspects of openness, eliminating the restriction that the IESG be the single approver of exploratory groups is an important method for distributing power into the organization. It is equally important, of course, for the IESG to be able to approve them as the predecessors to new work. By distributing that right, this mechanism eliminates both the possibility that the IESG will be a choke point and the perception that it is one. This also eliminates the "max two BoFs" rule, by allowing continued sponsorship. It is expected, though, that it would get harder and harder to get sponsors when the work isn't becoming a specification group or an investigative group. 3.4) Investigative Group The IRTF (Internet Research Task Force) has research groups which are focused on long term research related to the Internet. It has the writ to explore topics which may or may not admit of solutions. There are, however, cases where the IETF is considering a proposal for work and is not yet sure that the proposal is workable within the context of the Internet architecture. Investigative Groups are short term task forces set up to explore proposals and determine whether or not the work proposed merits further specification and standardization. These groups are chartered by the IAB and management oversight is provided by one or more domain experts within the IAB, who will coordinate their work with the Area Directors and Board(s) for the appropriate areas. These groups should not produce specifications, but they may produce documents describing use cases, requirements, or scenarios which motivate work and help delineate its scope. This mechanism is new and the management structure is new. It is expected that these will be fairly rare, but there are cases where continued investigation of a problem space is warranted but should take place within the context of a strong focus on the Internet Architecture. A large part of the effort in an Investigative Group is likely to focus on how to get to an appropriate scope for a Specification Group from an initial proposal. 3.5) Working Group Activity. All Working Groups are open to participation by anyone, no matter whether the group is a Specification Group, an Exploratory Group, an IANA Team, or Investigative Group. Anyone may join a Working Group mailing list at any time, and anyone may provide technical commentary as input to a Working Group at any time. A subset of those participating in the Working Group commit to taking on specific roles: Working Group Chair, document editor, or technical analyst. Each of the participants taking one of these special roles will be identified on the working group pages and in documents produced during their tenure. Working Group Chairs are responsible for the Working Group meeting its charter, and they have broad powers to accomplish this task. They may select specific document editors, replace document editors who are not meeting established milestones, and assign analysis tasks to the working group's technical analysts. Most importantly, they are responsible for determining whether work is sufficiently advanced to be forwarded for community review as complete. This means that they both gauge whether the Working Group has achieved rough consensus on a document and provide a written technical assessment of the work. The working group Chair or Chairs may decline to forward a document for community review whenever they believe it is technically incomplete, incorrect, or does not reflect the Working Group's consensus. They must do so by stating the basis of that decision in a written message to the group. This decision is subject to appeal along the established appeal chain. Because of the power inherent in this role, the same individual must never serve as both Chair and document editor for the same working group. The responsibilities of a Working Group Chair to the Working Group and Area Board (See Section 2, below) represent a significant outlay of time and energy. Chairs should expect to spend about one day a week on these activities, though the actual amount may vary from week to week. This description of a Working Group's Chair role adds a substantial technical role as technical reviewer, strengthens the ability of the Chair to hire and fire within the group, and formalizes the custom that a Working Group Chair should not be a document editor. The "provide a written technical assessment of the work" is also intended to take the place of the AD doing the write-up on a document. Document editors are responsible for merging the contributions of the Working Group members into a coherent specification. Typically, they are substantial contributors of text to the final document, but they must be able to integrate the work of others in order to reflect the view of the group. This text moves away from the concept of author to the concepts of editor/contributor. This may provide an opportunity to recognize more folks involved in creating a spec, but it may also weaken the recognition to those holding the pen. Watching this carefully will be required. There are two types of technical analysts; those associated with a Working Group effort and those outside the Working Group, whose views are solicited as an early indication of the likely results of broader community review. For the second, see below, Section 5, for a description of the CREW (Committed reviewers of early work). This makes the working group responsible for the first stage of cross-area review. The role and function of the technical reviewers is a formalization of the stuckee role, and much of the text of this section is lifted from the stuckee draft. The aim here is to ensure that in-depth technical review occurs by encouraging specific individuals to put their names to such a review. Typically, the work of the Working Group is done by the exchange of contributions and reviews by email. Working Groups also commonly hold face-to-face meetings at IETF meetings, and they may hold conference calls either of the whole group or specific sub-groups. All Working Group activity which does not take place on a mailing list must be minuted within a reasonable period and is subject to confirmation on the mailing list. 4. Area Board Structure and Activity Each Area Board consists of at least the Area Directors and one Working Group Chair per group in the Area; current IAB members who have served as Area Directors or Working Group Chairs in the Area may choose to serve or may decline to serve at their own discretion. If there a multiple Working Group Chairs for a single group, the Chairs may choose who will sit on the Board by any method that is mutually agreeable, but, in general, it is preferred that a Chair that has not previously served be given precedence over one who has. A Chair or chair(s) may also choose to propose that another contributing participant of their working group take the role; this is subject to the approval of the Area Board by majority vote. If a single individual serves as Working Group chair to multiple groups, that individual may serve only on behalf of one of those groups, and may not nominated another member of the working group under the replacement rules. Other members may be included for one year terms after nomination by four current members and approval by majority vote. Each Board will have one Board Secretary, tasked with setting agendas, arranging for minutes, and communicating results of the Board's work. The Area Directors for the salient Area will solicit candidates for this office from among the Board's members. The Area Directors will forward a nominee to the Board, which may confirm or decline the candidate by majority vote. Area Directors may not serve as Board Secretaries of their own area, but may fulfill their functions during short periods in which the role is vacant. Board Secretaries will normally serve one year terms, but the office may become vacant early if the incumbent's place on the Board lapses and is not renewed. This is all new. Part of the theory is to move some of those in the Area into roles closer to that of an AD, as prep for their taking on that role and/or as relief to the ADs. A main part of the theory, though, is that the value of the IETF is in cross-area review and consultation; this provides a new locus of review and consultation. Concerns expressed that the Working Group chairs may not be the best folks to hold these roles have been addressed by having Chairs capable of nominating replacements without soliciting three other nominations and by allowing their nominees to serve with majority vote. The Area Board has five main functions: it considers the need for IANA teams within its area and charters them in consultation with the community; it reviews Experimental and Informational documents forwarded by the Area Director from the RFC Editor and makes recommendations about their disposition to the RFC Editor; it manages educational and mentoring programs specific to its area; its members may approve the scheduling of an Exploratory Group meeting ; and its members may recommend that a particular document not produced within the IETF be considered as a candidate for standardization. It is also consulted by the IAB during the chartering of an Investigative Group and by the IESG during the chartering of a Specification Group. Note that the area board makes recommendations to the RFC Editor on Informational or Experimental documents--not to the IESG. For the review of documents, larger Boards may and should consider forming small teams with expertise in specific areas, so that a ready team of reviewers is available for related documents. Where a document is not obviously associated with such a team, the Board Secretary should ask for volunteers to review the document, setting a minimum of four reviewers. If a Board has fewer than four members, the whole Board should review all documents referred to it. Any four members of an Area Board may recommend that a document produced outside the IETF Working Group process be considered for standardization. The four members will commonly form or be part of an expertise-specific review team within the Board, but this is not required. New stuff, but along the lines of formalizing the core groups of existing areas; the hope is that by increasing recognition and responsibility for these roles that support for them can be increased. Each Area Board is expected to carry out its activities largely through mailing lists which are closed to external subscription but maintain public archives. The Board Secretary may schedule teleconferences to handle issues which require in-depth or real-time discussion. Minutes from those meetings will be posted to the public mailing list. These teleconferences may be supported with IETF funds if the mechanisms to support them are not readily available among the members. Each Area Board is also expected to have a public meeting at each IETF to discuss the work of the Area and solicit input on its direction from the community This is intended to work as a cross between an Area open meeting and a mini-plenary; giving opportunities for concerns to be raised but also opportunities for cross-group fertilization and input. 5.) CREW structure and activity. The CREW (Committed Reviewers of Early Work) is composed of individuals who volunteer to provide early technical review of documents for Working Groups in which they are not active participants. Anyone who is serving or has served as a technical analyst, document editor, or working group chair may volunteer to serve as a CREW participant by providing a short description of her or his technical areas of interest and agreeing to provide reviews on request. A CREW participant may decline any specific request for a review, but will be removed from the rolls of active participants if he or she refuses three successive requests without accepting a request, completes no reviews in a specific calendar year, or fails on two occasions in a single year to complete reviews which she or he has agreed to provide. Anyone completing five reviews in a single calendar year is immune to removal for that year, even if they decline further requests. The IETF secretariat will provide in the appropriate formats an electronic listing of reviewers along with their stated areas of interest and copies of their previous reviews; it will also provide a mailing list for the whole set of CREW participants, for use by those working groups generally soliciting input rather than issuing a targeted request. The aim of this activity is to provide early access to a broader community review of the work and an early gauge of the impact of the Working Group's choices on other groups and areas. It is expected that Working Group Chairs will solicit input from CREW participants early in the development phase of documents, and they may continue to solicit input over successive drafts. The input of CREW participants is not automatically privileged over the input of Working Group members, but Chairs may request changes to meet the review comments when they believe that the expertise or perspective contained in the review is not adequately represented by the Working Group participants. When a group is proposed, the chartering body may include requirements for external review by those with specific technical areas of expertise. The Chairs are responsible for determining that these requirements have been met; they may meet them by soliciting review by the CREW or, where available, through review by a directorate or relevant maintenance team. See below, Section 5 for discussion of directorates and their functions. Very SIR-like (SIRS), obviously, but with an aim to leave participation more open. The SIR mechanism seemed very unlikely to garner potential implementors, while a more open mechanism seemed likely to allow both for more senior reviewers and the work of first timers actually working on implementations. 6) IESG Structure and Activity Briefly, the Internet Engineering Steering Group (IESG) is the group responsible for the IETF standards process. A BCP containing a detailed description of its charter, is expected as part of the ongoing definition of IETF roles. Its current charter is discussed in (IESG-CHARTER), but this is not a normative description. The IESG has the following members: the IETF Chair, who also functions as the General Area Director when this area is active; the Area Directors for the IETF Areas; and the IAB Chair, as an ex-officio member. The IETF Chair and the Area Directors are selected by the IETF NomCom according to the procedures of BCP 10 (NOMCOM). This eliminates the Executive Director as ex-officio member, since that is a position associated with a specific contractor The IESG also has liaisons, who are members of the IESG mailing list and may attend all IESG meetings. The Liaison positions exist to facilitate the work of the IETF by expediting communication with other entities involved in the IETF process; which positions to have is decided by the IESG. The liaisons are selected as appropriate by the bodies they represent. At the time of this writing, the liaisons present represent the following bodies: the RFC Editor; the IANA; and the IAB. In addition, members of the IETF Secretariat are subscribed to the mailing list and present in the IESG meetings as needed in order to serve as a support function. Decisions of the IESG are made by the IETF Chair and the Area Directors. All IESG members can participate in the IESG's discussions. The IESG charters and terminates Specification Groups, selects the Chairs of Specification Groups and IANA Teams, and monitors their progress. While an Area's Directors and Board are the primary engine of coordination within the Area, the IESG is responsible for coordination across areas. It is also responsible, in consultation with the IETF community, for the creation and termination of Areas. As noted elsewhere, technical review of documents is done within Working Groups and may be done by directorates or the CREW. The IESG is, however, responsible for the final technical assessment of all IETF specifications and the final decision to advance them as IETF standards. It also assigns review of candidates for publication outside the Standards track to specific Area Boards. The IESG may divide the work of final assessment for documents intended to be standards in any way which is consonant with its charter and with this document. As of this writing, the IESG plans to use a team-based approach. According to that plan, documents forwarded as candidates for standardization are assigned to a team by the IETF Chair in consultation with the responsible Area Director. After assignment, the document is placed on the team agenda for a specific week, and each member of the team is responsible for providing an assessment of the document and reading the reviews provided by the working group technical analysts, CREW, and working group chairs by that date. A member of the team may, however, request that the document be deferred for a single meeting. Team members record positions on the standardization of a document in ways similar to that described in the current informational charter (IESG-CHARTER), in that a member may choose to raise no objection, may discuss an issue, and may approve. They may not, however, abstain for any reason; if a member would need to recuse herself or himself from reviewing a document, the other reviewer for that area should provide the review. Note that this internal plan does not change the appeals process, so that any decision of the IESG appealed to the IESG is automatically considered by the full IESG. This is meant to make the IESG a manageable job again without removing the final cross-area assessment. Note that the emphasis on early cross-area review by the CREW is critical to making this work, as is the Area Board review of non-Standards track documents. This focuses on the IESG as _final_ technical assessment team, but stresses the existence and importance of other review. It also leaves open the idea that an AD may "provide an assessment" by asking someone else to do that review if that is the best way to get one done; that, unfortunately, requires a personal network that is not specified here, but remains one of the ways forward. It otherwise gives strong emphasis to the specification Working Groups and cross-area coordination. Unlike other proposals, this does not split the function of the IESG into document review and technical leadership, but leaves the IESG pretty much as it is currently constituted as the technical leadership team. Note also the increased power given to Working Group Chairs above means that the IESG will no longer have the sole authority to block; moving the Chairs to use that new power when appropriate will take a culture change. The IESG has responsibility for the administration of IETF logistics, including operation of the Internet-Draft and Candidate Specification document series, as well as the IETF meeting event. As noted elsewhere, the actual administration is delegated to the Business Manager and Secretariat (see below, Section 11). This diminishes the IESG role in the day-to-day administration of the contracted services. 7) Directorate Structure and Activity Directorates are groups of subject-matter experts convened by one or more Area Directors to serve as a resource related to their subject. They may give advice to the Area Director or to Working Groups which solicit their input. Like comments from the CREW, comments from a Directorate may be considered by the Working Group Chair or Area Director as the basis for requirements to update a document, but it is the responsibility of the Chair or Area Director to impose those requirements. The names of the members of a Directorate should be public, and any comments which become the basis of requirements should be recorded either in the Working Group archives or by the Area Director in the notes associated with a document. 8) IAB Structure and Activity The Charter of the IAB is set out in RFC 2850 (IAB-CHARTER). This document updates that document by naming the IAB as the body which charters investigative groups, as a group which may schedule Exploratory Group meetings, and by designating its members as potential participants in Area Boards. It also specifies that the the IAB, with the IESG, votes to confirm a candidate as Ombudsperson (See Section 10, below for a description of the Ombudsperson's role). 9) The Nominating Committee. The NomCom selects the members of the IESG and IAB according to the system set out in (NOMCOM). This document does not update those mechanisms, but it does introduce new responsibilities for the individuals serving on the IESG and IAB and so should be considered by the NomCom in its deliberations. This document also introduces a new role for NomCom in carrying out the public solicitation of potential candidates for Ombudsperson. This system is different from the closed review of potential candidates for IAB and IESG, both in that the nominations must be public and in that the confirmation is carried out jointly by the IETF and IAB. See below, section 10, for more details. 10) Ombudsperson. The Ombudsperson acts to help ensure that IETF mechanisms are not abused by providing independent oversight of IETF processes. Any IETF participant may request that the Ombudsperson review the public record of a Working Group, Area Board, IETF, or IESG decision to determine whether the IETF processes functioned correctly. The Ombudsperson has no power to conduct investigations, but she or he may, at her or his discretion, request time on the agenda of any body outside the NomCom in order to put forward the concerns raised. If this is not sufficient to resolve issues, the Ombudsperson will help the participant to understand the appeals process. It remains the responsibility of the concerned individual to file the appeal. Public nominations for candidates to serve for a year in the role of Ombudsperson are solicited by the NomCom Chair two months prior to the Fall IETF meeting. The NomCom discusses the candidacies on its closed list, and makes a nomination two weeks prior to the Fall IETF meeting. A candidate must be confirmed by majority vote of the IESG and IAB during their joint meeting. If the candidate proposed by the NomCom is not confirmed, the NomCom must propose a new candidate. The sitting Ombudsperson remains in office until a candidate has been confirmed or, if that individual cannot serve, the NomCom Chair serves in this role until confirmation is complete. If an Ombudsperson leaves during the course of the one year term, the NomCom will nominate a replacement to serve the remainder of the term plus one year. This is a role clearly desired by the community, but the scope of the role has not been clear. In putting together text, the most important aspect of the role seemed to the right to "be heard" and that the right to have access to any agenda was therefor key. Investigative powers, on the other hand, seemed likely to be problematic so this document sticks to the public record as the source of information. 11) Business management and staffing. The IETF is largely a volunteer organization, but it does maintain contracts with a number of external organizations who provide support or other services. Work on updating the mechanisms by which those relationships are managed is ongoing. This document assumes that whatever mechanisms emerge, the business management role inside the IETF will have no necessary connection to the IETF standards process and so the day to day work of managing the contracts by which support services are provided will not necessarily fall to those with any specific role in the standards process. This section originally outlined a new role, essentially a a professional able to take on the "task requester" position of managing contracts. Since there is work going on to update those mechanisms, this section shifted to document the core assumption that the new mechanism would not presume that the same people managing the standards process managed the business relationships. That seems both likely to help us in reducing the load on those managing the standards process and likely to reduce the set of skills required for those roles. Hopefully, both of those changes will increase the pool of those able to serve. 12) External relationships. The responsibility for handling external relations rests with the IAB, as described in the IAB Charter (IAB-CHARTER). However, when technical cooperation is required, it is essential that the work be coordinated with the relevant Areas. This often means that an Area Director or Board participant will function in a liaison role with other organizations. The IAB may decide, however, to appoint others to those tasks whenever it believes that this is more appropriate. 13) Document Series. The requirement that Working Group documents be archival implies the creation of a new document series outside the current Internet Draft series. This series, called Candidate Specifications, is intended to be relatively lightweight in publication. The Chair of the salient Working Group must approve publication of the initial version of any Candidate Specification, but it may be updated by the Document Editor as required. Candidate Specifications may have normative references to any document, including Internet Drafts. As noted above, C.S. is a new series, meant to be the archival equivalent of draft-ietf-wgname. When a Specification Group believes that a Candidate Specification is ready to be considered for status as an IETF standard, its Chair completes the technical analysis described in Section 1.5 above and requests community review in an IETF Last Call. Following the completion of that Last Call, the IESG conducts a final review and either advances the document to Initial Standard or provides public feedback to the Working Group on issues raised during the IESG's review. An Initial Standard must have normative references only to archival documents, but this may include specific versions of Candidate Specifications. After an Initial Standard has been implemented and in use for six months, it may progress to Full Standard by demonstrating that there exist two interoperable implementations of every required feature of the specification. A Full Standard must have normative references only to archival documents, and it is preferred that these be at least at the level of Initial Standard or its equivalent. This requirement may be waived by the IESG if the archival document referenced is considered stable in the aspect referenced by the Full Standard. By keeping this as a 3 stage process but with a lower initial requirements and a dropped requirement for lock step movement of normative references, we may be able to keep useful elements of the existing three stage system while improving the ability to move forward in a reasonable amount of time. Getting to Full and proving interoperability should be valuable, and reducing external dependencies may help us do that more often. 14) Change process As before, the IETF may choose to update its processes by forming a working group that will consider the needs or advantages of specific changes. A simplified mechanism is, however, presented here as a method for the adoption of new processes. Any member of an Area Board may propose that the Area Board consider a new process for adoption by the IETF as a whole. Such a proposal must be documented as an Internet Draft, and should indicate clearly the working of the proposal and the current documents which it updates or obsoletes. If a two-thirds majority of that Area Board concurs that the IETF should consider the new or updated process, the Board Secretary for that Board notes the action to the IESG. The Area Directors for the Areas that have not considered the process must then request that the process be considered by the other Area Boards. Other Area Boards then consider the document and vote on whether it should be approved; a two thirds majority is required in each case to approve. If all Area Boards approve the document, the process it documents becomes part of the IETF process. If a majority approve the document, but not all approve it, the Area Director for the General Area should strongly consider the formation of a Specification Team to propose new processes in the area; the Area Director for the General Area may also, however, recommend to the IAB that an Investigative Team be formed to consider the question. All new, and designed to create a change process that has a low bar for proposal, a reasonable bar for full-fledged consideration, and a fairly high bar for change. Note, however, that every single Area Director could be against the proposal and it could still pass. Note also that a single Area objecting to a proposal can stall it in this process, but cannot stall it in the working group process, so there are two separate ways forward. 15) Educational processes As noted above, each Area Board has responsibility for educational processes supporting its Area. There is, however, also a need for a set of educational process which are more general (generally, orientation meetings for newcomers to the IETF or newcomers to specific roles in the IETF). Therefore, the General area will maintain a set of ongoing working groups, essentially maintenance teams, charged with managing, developing, and delivering those cross-area educational programs which are needed and appropriate. The exact set of those teams may vary at any one time but shall consist at least of one dedicated to the general orientation of newcomers to the IETF and one dedicated to the orientation of those taking on new roles as Chairs, members of Area Boards, technical reviewers, and members of the CREW. 16. 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. 17. IANA Considerations. This document does contain any actions for IANA. 18. Acknowledgments. This document lifts ideas, text, and explanations from a variety of sources, not always with their prior knowledge or consent. The work of Dave Crocker, Brian Carpenter, and the participants in the SiRS experiment informs the section on the CREW. The work of the problem statement working group and the solutions mailing list have both been instrumental in identifying scope and potential improvements. The Genera Area Directorate has given early comments on the work; Spencer Dawkins, in particular, provided extensive feedback. Leslie Daigle, John Klensin, April Marine, James Kempf, Melinda Shore, and Rob Austein also provided comments on early drafts. 19. References 19.1 Normative References Galvin, J. "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees". BCP 10. (NOMCOM) Carpenter, B. ed. "Charter of the Internet Architecture Board". BCP 39. (IAB-CHARTER). 19.2 Non-Normative References Alvestrand, H. "An IESG Charter" draft-iesg-charter-03.txt (IESG-CHARTER) Carpenter, B. et al. "Careful Additional Review of Documents (CARD) by Senior IETF Reviewers (SIRS)" draft-carpenter-solution-sirs-01.txt (SIRS) 20. Editor'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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.