Network Working Group G. Kowack, Ed. Internet-Draft Riveronce Expires: April 29, 2011 October 26, 2010 RFC Editor Model Version 2 draft-kowack-rfc-editor-model-v2-00 Abstract The RFC Editor publishes the Internet's archival series of technical and informational documents. RFC 5620 defines RFC Editor Model Version 1, whose implementation began in January 2010. Model 1 divides RFC Editor activities into a number of components, including the RFC Series Editor (RSE). During 2010, a "Transitional RFC Series Editor" performed and evaluated the RSE role. Based on direct experience, extensive discussions with the community, and research, the TRSE provides this updated version of RFC 5620. This draft revises the RSE job description, and makes recommendations for the search and selection process for a permanent RSE. This memo also clarifies RFC Editor and RSE activities using established approaches of management and oversight of a publication service, tailored for the style of the Internet technical community. Careful attention is paid to ensuring stable operations. This document observes that RSE responsibilities demand a very high level of editorial and managerial expertise. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 29, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Kowack Expires April 29, 2011 [Page 1] Internet-Draft RFC Editor Model (Version 2) October 2010 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Executive Summary: Refinements to the RFC Editor Model . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. RFC Editor Model . . . . . . . . . . . . . . . . . . . . . . . 10 4. RFC Series Editor . . . . . . . . . . . . . . . . . . . . . . 12 4.1. RSE Executive-Level Management . . . . . . . . . . . . . . 13 4.2. RSE General Responsibilities . . . . . . . . . . . . . . . 20 4.3. RFC Series Editor Specific Responsibilities . . . . . . . 26 4.4. RSE Professional Qualifications . . . . . . . . . . . . . 29 4.5. RSE Term of Office . . . . . . . . . . . . . . . . . . . . 30 5. Independent Submission Editor . . . . . . . . . . . . . . . . 30 5.1. Independent Submission Editor General Responsibilities . . 30 5.2. ISE Professional Qualifications . . . . . . . . . . . . . 31 5.3. ISE Term of Office . . . . . . . . . . . . . . . . . . . . 32 5.4. Independent Submission Stream Editorial Board . . . . . . 32 6. RFC Production Center . . . . . . . . . . . . . . . . . . . . 32 7. RFC Publisher . . . . . . . . . . . . . . . . . . . . . . . . 33 8. Committees . . . . . . . . . . . . . . . . . . . . . . . . . . 34 8.1. RFC Series Advisory Group (RSAG) . . . . . . . . . . . . . 34 9. Resolution of Disagreements . . . . . . . . . . . . . . . . . 36 9.1. Disagreements between RFC Editor Components and Model Participants . . . . . . . . . . . . . . . . . . . . . . . 36 9.2. RSE Review of Inter-Stream Conflicts . . . . . . . . . . . 37 10. Re-Establishing an RFC Editor Stream Capability . . . . . . . 37 11. Future Considerations . . . . . . . . . . . . . . . . . . . . 38 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 13. Security Considerations . . . . . . . . . . . . . . . . . . . 38 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 15.1. Normative References . . . . . . . . . . . . . . . . . . . 39 15.2. Informative References . . . . . . . . . . . . . . . . . . 39 Appendix A. 2010-11 RSE Search and Selection Process . . . . . . 39 A.1. Overview and Criteria . . . . . . . . . . . . . . . . . . 39 A.2. Structure . . . . . . . . . . . . . . . . . . . . . . . . 40 A.3. Stream Appointments . . . . . . . . . . . . . . . . . . . 40 A.4. RSAG Appointees . . . . . . . . . . . . . . . . . . . . . 40 Kowack Expires April 29, 2011 [Page 2] Internet-Draft RFC Editor Model (Version 2) October 2010 A.5. SSC Regular Member Qualifications . . . . . . . . . . . . 41 A.6. Additional Qualifications for Streams Appointees . . . . . 41 A.7. Additional Qualifications for RSAG Appointees . . . . . . 41 A.8. Non-Voting Members . . . . . . . . . . . . . . . . . . . . 42 A.9. SSC Assistants and Additional Expert Advisors . . . . . . 42 A.10. SSC Approval of Job Description . . . . . . . . . . . . . 42 A.11. Financial and Legal Preparations . . . . . . . . . . . . . 42 A.12. SSC Alignment with RSE Job Description . . . . . . . . . . 43 A.13. SSC Call for Candidates . . . . . . . . . . . . . . . . . 43 A.14. Applications and Short List . . . . . . . . . . . . . . . 43 A.15. Confidentiality . . . . . . . . . . . . . . . . . . . . . 44 A.16. Best and Final . . . . . . . . . . . . . . . . . . . . . . 44 A.17. IAB Process Review . . . . . . . . . . . . . . . . . . . . 44 A.18. IAOC / SSC Joint Negotiation . . . . . . . . . . . . . . . 45 A.19. SSC DRAFT SCHEDULE . . . . . . . . . . . . . . . . . . . . 45 A.20. No Suitable Candidate . . . . . . . . . . . . . . . . . . 45 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46 Kowack Expires April 29, 2011 [Page 3] Internet-Draft RFC Editor Model (Version 2) October 2010 1. Executive Summary: Refinements to the RFC Editor Model The RFC Series is the Internet technical community's official medium, through which it communicates with itself and the rest of the world. The RFC Editor is the community-defined and -supported function that accepts documents from different streams, makes textual edits for clarity and formal correctness as prescribed in the RFC Series Style Manual, and publishes and archives those documents as RFCs for free access by everyone. RFC 5620 first defined the components and processes of the present- day RFC Editor (Model Version 1), including the RFC Series Editor (RSE) as its leading component. However, the attempt to hire a new RSE proved difficult and resulted in retention of a Transitional RSE, or TRSE. The TRSE was asked to perform the RSE functions described in RFC 5620, to determine if those descriptions matched what was needed and, if necessary, recommend changes to the role of the RSE and refinements to the RFC Editor model based on his experience. The central observation of the TRSE is that: the RSE role demands the expertise and experience of a senior manager and subject matter expert in technical writing, technical publishing, and technical series development. This observation drives the clarifications and changes recommended here to RFC Editor Model Version 1. Although modest, these changes are fundamental to the future success of the RFC Editor's service to the Internet community. The first clarification is: the overall leadership and management of RFC Editor functions must be by the RFC Series Editor - the editorial and publications subject matter and management expert. However, this general leadership must be tempered by two considerations. o The Internet technical community has requirements, processes, and traditions that must be followed by the RSE and across the entire RFC Editor function o The line between the responsibilities of the RSE and of the IETF Administration and Oversight Committee (IAOC) must be clarified. The new model combines RFC Editor leadership as it would be practiced in a typical not-for-profit organization with the following Internet community-driven practices: Kowack Expires April 29, 2011 [Page 4] Internet-Draft RFC Editor Model (Version 2) October 2010 o seek community input appropriately and widely, o encourage volunteer initiative and contribution, and o practice supervision according to specified procedures. This model recommends collaboration between the RSE and the IAOC analogous to the partnership between line management and finance as practiced in most modern corporations:. o The RSE is responsible for regular editorial activities management, including long-term editorial planning. o The IAOC retains its leadership of legal and financial matters. The RSE reports to the IAB for general matters. The IAB retains its responsibility for ensuring proper RSE policy formation and adherence. Additional recommendations for changes to model provided in RFC 5620 include: o The independence of the Independent Submission Stream and Independent Submission Editor (ISE) is reiterated. o The role of the RSE Advisory Group (RSAG) is marginally expanded to ensure the RSE follows community will and to provide counsel to the IAB when the RSE is either unavailable or the subject of a discussion. This memo also clarifies the RSE's responsibility for maintaining Series quality. The updated model divides Series continuity, a key element of the RSE role, into editorial and operational continuity. To accomplish the former, the RSE is to maintain and develop the RFC Series Style Manual. To ensure the latter, the RSE is to develop and maintain the RFC Series Procedures Manual. To return the RFC Editor to its historical level of independence, this memo recommends creation of an RFC Editor stream. Finally, an updated RSE search and selection process is proposed. This process is rooted in community participation, qualified participants and expert advisors, and follows carefully described procedures and elements to ensure a successful hire. An unexpected consequence of the TRSE effort is that most of the changes proposed for the updated model return the RFC Editor to the style and perspective used during the first 40 years of its life, although adapted to today's structure and operation of the technical Kowack Expires April 29, 2011 [Page 5] Internet-Draft RFC Editor Model (Version 2) October 2010 community. This memo concludes that this time-proven arrangement is the best way, to serve the requirements of the Internet technical community. 2. Background The RFC Series is the Internet technical community's official medium, through which it communicates with itself and the rest of the world. 6,000 RFCs since 1969 comprise one of the most extensive and influential technical series in history. Without openly available RFCs, the Internet could not have been built, could not operate, and could not continue its remarkable advance. The RFC Editor is the community-defined and -supported function that accepts draft documents from the community, makes textual edits for clarity and formal correctness, and publishes and archives those documents as RFCs freely accessible by everyone. RFC 5620 first defined the components and processes of the present- day RFC Editor, including the RFC Series Editor, its leading component. This document clarifies the role of the RFC Series Editor and other RFC Editor components. The origin of these changes go back to the very start of the series. The role of RFC Editor dates back to the publication of RFC 1 in April 1969. One of the longest standing institutions in the Internet community, the RFC Editor thus predates the IETF (the producer of Internet Standards) by nearly two decades. Initially, the role of the RFC editor was played by a single technical expert who,like other community members and leaders in those days, was supported by outside funding. The RFC Editor initiated and participated in the highest level of policy debates, and made unilateral decisions of great significance to the community including, until the mid-1990s, decisions about RFC technical content. The high degree of autonomy of the RFC editor reflected the culture of the technical community in those days, when a new and rapidly changing environment relied heavily upon individual initiative. Moreover, Jon Postel, the first RFC Editor, had a genius for giving power to the community and creating new forms of community participation and contribution. There was little or no perceived need for careful resolution, in advance, of issues surrounding roles and authority. The relative informality of that era was widely accepted and allowed the community to be free of the collective overhead of financial administration. Kowack Expires April 29, 2011 [Page 6] Internet-Draft RFC Editor Model (Version 2) October 2010 The RFC Editor wore multiple hats, even counting only those related to editorial work. These included acting as an editor, manager of an editorial service, manager of a technical series, manager of intellectual property and of an archive, maker of RFC Editor policy, and leader in policy implementation. Informal processes were widely accepted as sufficient for managing these multiple complex roles. By the mid-1990s, the Internet's transition from being a primarily research-oriented facility was coming to an end. Research funding for the RFC Editor would not much longer be available. In cooperation with the community, the Internet Society began to fund the RFC Editor directly. The RFC Editor was in a new position, its support now coming directly from the community it served. The demands on the RFC Editor were increasing as the community produced more documents -- and desired more timely editorial processing of those documents. With the addition of editorial staff, the RFC Editor grew from a single editor into a team; a division of labor began, and management overhead increased. While all the functions of the RFC Editor remained the responsibility of one individual during this period, the RFC Editor had progressively less authority to make technical changes to submitted drafts. The other institutions of the Internet technical community were also evolving, becoming more deliberately structured and formal. These changes were partly a natural consequence of organizational maturation and growth. They were also motivated, as stated in RFC 4844, by these considerations: "...the Internet engineering and research community as a whole has grown and come to require more openness and accountability in all organizations supporting it. More than ever, this community needs an RFC Series that is supported (operationally and in terms of its principles) such that there is a balance of: o expert implementation; o clear management and direction -- for operations and evolution across the whole RFC Series (whether originating in the IETF or not); and o appropriate community input into and review of activities." The community reached a consensus, documented in RFC 4844, on a more rigorous framework for the RFC series and the "RFC Editor function" (a term RFC 4844 introduced, to clarify that it could be performed by one or more persons). In doing so, it took steps to pry apart and further define various responsibilities. That included definition of the RFC streams, which to the present day comprise: Kowack Expires April 29, 2011 [Page 7] Internet-Draft RFC Editor Model (Version 2) October 2010 o IETF Document Stream, o IAB Document Stream, o IRTF Document Stream, and o Independent Submission Stream. RFC 4844, however, intentionally made no attempt to explore the internal organization of the RFC Editor. That task fell to RFC 5620, published in August 2009. RFC 5620 defined or clarified the roles of the four major components of the RFC Editor: the RFC Series Editor, the Independent Submissions Editor, and the RFC Production Center and the RFC Publisher. RFC 5620 separated these in part to permit flexible implementation (separately or by combinations of contractors). During this same period, the IAB chose to move editorial and archiving services from the University of Southern California's Information Sciences Institute to the winner of an open, competitive RFP bid. The IEFT Administrative Oversight Committee (IAOC) established two new agreements: one for the independent submissions editor, the other for a single organization to provide a production center and publication services. The production center houses all the RFC editorial staff and their internal manager; the publisher is a server on which all RFCs and drafts are published, archived, and made available to all. The RFC Editor began to operate under the new model in January 2010, and continues to do so today. A simultaneous and extensive effort to locate an RFC Series Editor did not yield an appointment. Concerned with series continuity, the IAB created a temporary position, the Transitional RFC Series Editor (TRSE). The TRSE was to do the job of the RFC Series Editor and maintain series continuity through 2010. Based on direct experience, the TRSE was to determine RSE requirements and propose an updated job description, and corresponding RFC 5620 revisions. This document, Version 2 of the RFC Series Editor Model, results from that effort. For the RSE job description to result in a successful engagement, it must satisfy several challenges. First, it must reflect the inherent complexity of the RSE role. As defined in 5620, the RSE works on four levels: o with the community, to obtain their perspectives on policy and policy requirements, o with community leaders to investigate and determine policies and implementations, Kowack Expires April 29, 2011 [Page 8] Internet-Draft RFC Editor Model (Version 2) October 2010 o with staff and contractor management for provision of specified services, and o as the executive-level manager of the RFC Series. Second, many RSE work items are specific to this role and this community. The job must satisfy the editorial, publication, distribution, and promotional needs of the series. The RSE job description must carefully define the RSE's relationship to other community entities. This is one of the few times there will be a community-supported job with extensive involvement in policy development and, in some cases, in policy setting (e.g., certain components of the Style Manual). That involvement, and the overall conduct of the Editor, must be consistent with community requirements and values. Third, any job needs to be sensibly structured. The description must be clear and unambiguous. Each individual task must be reasonable and do-able, and the entire set of tasks must make sense in combination. Responsibility and authority must align. The job requirements must be broadly consistent with the skills and experience level of a single appointee. Finally, to serve the community, the Series Editor must have the freedom to be professional while under contract to the IAOC and subject to review by the IAB -- neither of which can be expected to include individuals with the same level of editorial background or expertise. The Series Editor must be able to balance his/her own initiative and decision-making with the right amount of community dialog, in the right way, at the right times. These, then, are the considerations that the TRSE believes central to success in attracting, hiring, and retaining a qualified candidate. The revised model addresses these considerations by clarifying RSE responsibilities and relationships and by describing accepted community consultation practices. Many of the updates here are straightforward descriptions of how the Transitional RFC Series Editor executed the role during 2010. Where possible, this version retains the text and arrangement of the original RFC 5620. This version is consistent with RFC 4844 (as was RFC 5620). The IAB intends publication of this second version to complete the current cycle of RFC editor model development. A newly appointed RFC Series Editor should be able to begin work under a job description that is complete, well structured, and reasonable, one that will Kowack Expires April 29, 2011 [Page 9] Internet-Draft RFC Editor Model (Version 2) October 2010 allow the vast majority of the new RSE's time and energy to be devoted to doing the job rather than to coping with structural or other changes. Of course such changes, small or large, may be required as the position evolves. The RSE and RSAG, along with the IAB, must continue to monitor the efficacy of the RSE model and respond to changing circumstances As always, the IAB invites the and community to provide observations and suggestions. 3. RFC Editor Model The RFC Editor model divides the responsibilities for the RFC Series into the following components: o RFC Series Editor ('RSE') and RFC Series Advisory Group (RSAG), o Independent Submission Editor ('ISE') and Independent Submission Editorial Board (ISEB), o RFC Production Center (RPC), and o RFC Publisher (RFC Pub). The RFC Series production process under this structure is schematically represented by the figure below. All major components are present. The figure only roughly depicts oversight relations. Kowack Expires April 29, 2011 [Page 10] Internet-Draft RFC Editor Model (Version 2) October 2010 +---------+ +---------+ | | | | | IAB | | IAOC | | | | | +-----+---+ +--+------+ +......RFC Editor.....................|.........|........+ . | | . . +-------------+ +----------+ +--V---------V--+ . . | | | | | | . . | Independent | | RFC | | RFC | . . | Stream | | Series <..> Series | . . | Editorial | | Advisory | | Editor | . . | Board | | Group | | | . . +-----------+-+ +----------+ +-+--------+----+ . ............+ | | | . . | | | . +-----------+ . +-V-----------+ +----V--+ +-V-------+ . +-----+ | Community | . | Independent | | RFC | | | . | | | at +---> Submission +---> | | RFC | . | E | | Large | . | Editor | | P | | | . | n | +-----------+ . +-------------+ | r | | P | . | d | +.................+ | o +-->| u +-----> | +-----------+ +-------------+ . | d | | b | . | U | | | | | . | u | | l | . | s | | IAB +---> IAB +---> c | | i | . | e | | | | | . | t | | s | . | r | +-----------+ +-------------+ . | i | | h | . | s | +-----------+ +-------------+ . | o | | e | . | & | | | | | . | n | | r | . | R | | IRTF +---> IRSG +---> | | | . | e | | | | | . | C | | | . | a | +-----------+ +-------------+ . | e | | | . | d | +-----------+ +-------------+ . | n | | | . | e | | | | | . | t | | | . | r | | IETF +---> IESG +---> e | | | . | s | | | | | . | r | | | . | | +-----------+ +-------------+ . +-------+ +---------+ . +-----+ . . +..........................+ Ordinary RFC Series production and process In the model, drafts are separately produced and approved through one of the streams; they are then submitted to the RFC Editor. The four current streams are described in [2]. Under the model, the streams, themselves parts of the community, are the direct "production side customers" of the RFC Editor. Those include draft authors and editors, various committees unique to each stream, and the stream Kowack Expires April 29, 2011 [Page 11] Internet-Draft RFC Editor Model (Version 2) October 2010 approvers. These actors singly and collectively receive editorial service from the RFC Editor. Those include the RFC Production Center accepting submitted drafts, providing editorial feedback and guidance, making format and editorial changes, and producing numbered RFCs archived and freely available to all via the Publisher. Readers and other users of RFCs (e.g., mirror sites), and users of Publisher services such as search, are referred to here as RFC Editor "consumption-side customers." Final decisions about the technical content of individual documents are the exclusive responsibility of corresponding stream approvers. Cases will arise in which editorial staff recommend a text change (for example, to correct grammar) but the author perceives a change in technical meaning. When this occurs, editorial staff should review the text and advise the author (about, for instance, how the text is likely be read by typical readers of English). But the stream approver will always have final say. The model allows for implementation of RFC Editor components and their functions under separate or joint contractual arrangements. Bidders may make proposals that include one or more contractors. Much of the reporting structure is subject to change over time and will depend on plans and the manner in which contracts are awarded. Details of the implementation are the responsibility of the RFC Series Editor and the IAOC, including when and how the reporting structure can be changed (see Section 4.1.5). However, to preclude conflicts of interest and to support balanced and independent management, the RSE must not be from the same organization as any of the other components of the RFC Editor, unless the IAB acts to override this provision in a specific instance, which it will do only after reviewing the matter with RSAG. 4. RFC Series Editor The RFC Series Editor (variously 'RSE' or 'Series Editor') is an executive-level manager and subject matter expert in technical writing, publishing, and series development. The Series Editor is responsible for the entire RFC Editor and all its components, functions, and staff, separately and in combination -- including the RFC Publisher and the RFC Production Center. The RSE is the only component of the RFC Editor with this scope and authority. The Independent Submission Editor, Independent Submission Stream, and Independent Submission Stream Editorial Board, however, function independently of the RFC Series Editor. The RSE obtains advice and analysis from the RFC Series Advisory Group, or RSAG. Kowack Expires April 29, 2011 [Page 12] Internet-Draft RFC Editor Model (Version 2) October 2010 The RFC Series Editor is an individual who has direct reports including contractors and managers. The RSE may have assistants. The RSE appointee is a specific individual, not an organization or an alternate. Under exceptional circumstances when the RSE is unavailable, a temporary substitute may be made, but only with prior approval of the IAB, and only after the IAB has consulted the RSAG. Section 4.1, immediately below, defines the role of the Series Editor. It describes where and how RSE management practices must follow internet community practices and requirements. 4.1. RSE Executive-Level Management Performing the RSE role requires the expertise and experience of a senior managerial professional in technical writing, publications and series development. The position has extensive content and RFC- Editor-wide scope, and is expected to entail a multi-year term of office (see section 3.6). The RSE will initiate and lead many discussions, make many day-to-day decisions, and set editorial policies. This individual cannot help but have tremendous influence. The approach here is to grant the RSE explicit formal authority to match the requirements of the job (and, where appropriate, its implicit influence). That authority is tempered by a context of customary practices that ensure the RSE acts in the interest of the community. In RFC Editor Model Version 1, the community outlined the role of, and delegated various authorities to, the RFC Series Editor. The RSE was to exercise "executive-level management over many of the activities of the RFC Publisher and the RFC Production Center...". However, RFC 5620 did not attempt to define "executive-level management" nor explain how that might change as the RFC Editor Model evolved. This document defines RSE "executive level management" beginning with regular professional practices in typical not-for-profit organizations, including: o directing day-to-day operations, o reviewing processes, structures, and performance, and making changes, o analyzing customer requirements and strategic opportunities, o developing long-term goals and plans, including budgeting, Kowack Expires April 29, 2011 [Page 13] Internet-Draft RFC Editor Model (Version 2) October 2010 o interacting with and supporting peers and colleagues, o reporting upwards and to constituents, and o representing their function in the marketplace. However, leadership in the Internet community is not practiced as in many other organizations. In particular, as the community's perception of a decision's importance increases, the greater is the need for community review and discussion, in order to reach community consensus. More than in other organizations, some decisions will require broad community participation during their development. In such cases, what counts is the RSE's ability to inspire, support and distill community discussion. To be successful, the RSE must be free to do, or facilitate, the following: o make broad analyses of the scene, o discover items in need of change or repair, o determine possible fixes, o collect and present all pertinent information, o initiate and organize community discussion, o help the community reach a consensus, and then o implement the decision. Performing this role is leveraged by the RSE's having a "bully pulpit" - an excellent platform from which to speak. The RSE must be able to speak to an issue, making arguments on their own merits; but the RSE cannot expect to be successful simply by "asserting authority". The process described here will afford the RSE opportunities to make major contributions and have significant impact. The RSE's relatively unusual (in our community) incoming publications expertise, knowledge gained from day-to-day RSE work experience, and time in grade will give this individual considerable leverage. To be able to exercise the sort of consensus-building leadership envisioned for this role, the RSE must not be blocked from investigating any subject within the scope of the RSE job description, or from using professional techniques of the RSE's choosing. As the RSE and RFC Editor staff apply their specialized knowledge, they will develop unique perspectives and insights. They must be Kowack Expires April 29, 2011 [Page 14] Internet-Draft RFC Editor Model (Version 2) October 2010 free, and encouraged, to shape those insights into their own unique vision for the RFC Series. Only through this process will they be able to make a full contribution to the community and continue to develop, and realize the full potential of the RFC Series. Freedom to practice their profession is also fundamental to attracting top rank candidates and to retaining a qualified, motivated, senior publications management professional. Section 4.1.1 to Section 4.1.6 discuss six areas in which community principles and processes modify conventional management practices or are of particular importance. The RSE must: o seek appropriate community discussion and input, o obtain opinion from across the entire community, o encourage and support volunteer initiative and contribution, o supervise according to specified procedures, o cooperate with the IAOC, and o report to the IAB for general matters and to the IAOC for RSE contract requirements while following community direction. 4.1.1. Seek appropriate community discussion and input Determining the long-term direction and evaluating overall performance of the RFC Editor is the privilege of the Internet community. In principle, the community could at any time require as much discussion, or prior approval, as they wish on any matter. However, the community elected to create the RSE position with certain responsibilities and authorities. The community will get the best results if the RSE is trusted to identify when to act independently and when to seek community discussion and review prior to acting. To support community consideration of RFC Editor issues, the RSE will ensure the RFC Editor will: o use open and transparent processes, o make regular reports, o encourage and participate in discussions with the community across a wide range of RFC Editor related subjects, and Kowack Expires April 29, 2011 [Page 15] Internet-Draft RFC Editor Model (Version 2) October 2010 o follow community consensus. The RSE must be liberal in what is reported, whether or not specific items appear to require community discussion or consensus (except, of course, when standard personnel practices require discretion). The RSE is responsible for balancing decision-making independence with prior discussion and approval by the community. Within scope, the RSE is free to make decisions, determining case-by-case how much prior discussion is appropriate. Nevertheless, the RSE is responsible for gaining the community's acceptance of those decisions and must be prepared to act accordingly if acceptance is not obtained. The RSE should not act, or appear to act, in an abrupt or unilateral manner. The RSE must also remain open to and seek input from the community as to whether they are achieving the right balance of independence and input on individual decisions and in aggregate. The RSE is expected to seek the guidance and counsel of the RSAG in these matters. RSAG members will maintain their own dialog with community members to ensure the RSE is aware of community thought, to assist the RSE in distinguishing between useful and frivolous input, and to help the RSE refine his approach to this process. Subjects for which prior community notice or discussion must always occur include those that: o directly and significantly affect community activities (e.g., a change in the Procedures Manual where RFC Editor staff interact with the streams), o change long-standing practices that have customarily required community discussion or consensus (though of course these practices may change over time), o are significant and irreversible, and o significantly impact the look and feel of the series, or how the series can be used. Subjects for which discussion does not need to occur include those in which: o the Series Editor has been previously authorized to set policy (e.g., in parts of the Style Manual), o a decision is based on another authority's mandate (e.g., personnel confidentiality practices, IETF Trust requirements), Kowack Expires April 29, 2011 [Page 16] Internet-Draft RFC Editor Model (Version 2) October 2010 o the matter is strictly one of internal management within the RFC Editor, o a decision has been previously made on RFC Editor policy in agreement with the community (i.e., the RSE is able to say "this has already been agreed") or a schedule of discussions has been agreed but certain dates have not arrived, and o the differences among outcomes are too slight to justify consultation (in practice this will apply to relatively minor issues). The community must aim to provide input on RFC Editor performance in a concerted and constructive way. This is especially true regarding individual performance of RFC Editor staff. The RSE must ensure that the community can easily provide such input, maintaining appropriate confidentiality (e.g., for personnel issues). On occasion, the community may fail to respond to repeated calls for comment, or their responses may be incomplete. In such cases (optionally after seeking advice from the RSAG), the RSE is free to make a decision. As always, the RSE should report such decisions, and seek community input as to whether these decisions might need to be revisited in the future. Another example of a boundary of community participation in decisions concerns the Style Manual. The Manual could consist of two major sections. The first would contain rules of usage and layout that RFC Editor staff must follow when producing RFCs. This part would be as small as practical. The second part would consist of guidance and examples of usage, grammar, punctuation and such for authors of drafts. The first part depends upon editorial and publications expertise; the RFC Editor would determine its content. The second part would be created with direct community participation, to ensure its usefulness. 4.1.2. Obtain opinion from across the entire community The RSE must seek and obtain input from across the entire community. As the RSE and staff gain new insights and a broad vision for the Series and the RFC Editor, they must communicate this in reports to encourage input from and discussion with every part of the community. Internet technical community entities and leaders often do not exercise 'leadership' or represent constituencies as one finds in conventional organizations. Rather, they have expertise, responsibility, and authority to work within specific areas. For every significant decision they must seek community opinion, engage Kowack Expires April 29, 2011 [Page 17] Internet-Draft RFC Editor Model (Version 2) October 2010 in discussion, and give the community opportunity to review and comment. When working with these entities, the RSE must not give them primacy over community consensus, nor give undue weight to particular entities. The RSE is free to participate in debates with the same degree of knowledge, initiative, insight as employed anywhere in the community, including other senior leadership positions. 4.1.3. Encourage volunteer initiative and contribution Volunteers have always done the work in the community. They have shown exceptional initiative and industry. The vast majority of things get done because an individual or group takes action, often without prior official 'approval'; frequently there is no structure in place to even grant approval in the first place. The RSE must work with and encourage volunteer initiative. In addition, in order to maintain community participation, the RSE should convert volunteer activities into staff activities only if doing so is required to get the job done, and when the job is important enough to warrant allocating resources. Although the RSE may be responsible for specific items, it is not necessary for the RSE to be the one who does them, only that they get done. This requires that the RSE (a) not obstruct community initiatives, (b) engage the community when an area that requires their participation does not yet appear to have active attention, and (c) support the community in determining requirements, including quality requirements. The community has a long practice of engaging volunteers from its different entities in such a way that participation and authority have been distributed and expanded, rather than collected and concentrated. The RSE must continue this practice, which has been one of our great strengths. 4.1.4. Supervise according to specified procedures The closeness of RSE supervision of RFC Editor components and staff depends upon the degree to which the job is defined (often through community process), and includes direct community participation Current operations of the RFC Production Center illustrate one end of this spectrum. The PC performs a well-defined function and works closely with the streams. RFC Production Center activities are specified by contract, the Procedures Manual, and the Style Manual. The RSE will manage this sort of component using conventional contract management practices in line with these processes. The RSE will not supervise this component closely; contractor internal management will do that. Rather, the RSE will provide direction and Kowack Expires April 29, 2011 [Page 18] Internet-Draft RFC Editor Model (Version 2) October 2010 guidance where agreed procedures are unclear or where Production Center performance is not within specification. Contractor management may request direction, or the RSE may initiate direction. The RSE may require changes to formal procedures and implementation by the contractor. The RSE will inform the community and request reviews at least to the extent that procedural changes affect or are of interest to the community. At the other end of this spectrum are, for example, direct reports or assistants to the RSE. How analysts or assistants perform their work will not typically be of interest to the community and this work is not typically structured around formal processes. The RSE should supervise this sort of staff as closely as the she believes necessary. 4.1.5. Follow IAOC-RSE cooperation practices If the RSE anticipates procedural or other changes with contractual, legal, or financial consequences, they must seek the counsel of and action by the IAOC. Similarly, the IAOC must request RSE participation and counsel where administrative, financial or legal matters require managerial changes. Thus, the IAOC continues to exercise its responsibility and authority for financial and legal matters as in RFC Editor Model Version 1. The IAOC and RSE are expected to resolve most issues without involving the IAB. But when they are unable to reach agreement, IAB guidance must be sought. Both short and long-term issues are to be handled in the same manner. Long-term issues include long-term planning activities, revised and new plans, contracts and other agreements, and requests for proposals (RFPs). The RSE and IAOC will jointly evaluate bids and make recommendations for awards. As above, the RSE will act as the subject matter expert for editor-related services, and will seek input from and represent content issues to the community. The IAOC as above, will take lead on financial, contract, and legal issues. The IAB, as above, will be the final arbiter when the RSE and IAOC cannot agree. The internal and external reporting structure of the RFC Editor may not be changed without the approval of the RSE and the IAOC. This includes contract-mandated changes. As with other such decisions, the RSE and IOAC must bring disagreements to the IAB for review and resolution. Questions relating to contractor or individual performance may be raised by either the RSE or IOAC, including recommendations to terminate the contract of an individual or contractor. The RSE and IAOC must each respond to a concern or proposal of the other. If Kowack Expires April 29, 2011 [Page 19] Internet-Draft RFC Editor Model (Version 2) October 2010 they cannot agree on a remedy after extensive review and discussion, they must bring the issue to the IAB. Although the RSE is not required to make regular reports specifically to the IAOC, they must keep the IAOC informed of events with anticipated administrative, legal, or contractual consequences. The RSE must support IAOC planning cycles and general administrative requirements. The IAOC must similarly keep the RSE informed of anticipated administrative, legal, or contract issues that may effect the RFC Editor. 4.1.6. Report to IAB in general, IAOC for RSE The RSE listens to, takes input from, and makes reports to the community, as described above. The RSE reports to the IAB as necessary to support the IAB's role in ensuring proper management of the RFC Editor. This includes regular written reports, which will be publicized. The RSE reports to the IAOC specifically regarding the RSE's work contract. If the IAOC has concerns about RSE contractual performance, they should first bring them to the RSE. If they cannot agree on a resolution, the matter must be taken to the IAB for consultation. RSE reporting to the IAOC for matters directly related to the RSE's contract is distinct from, and must not be confused with, cooperation between the RSE and IAOC regarding general and financial management of the RFC Editor, as described in Section 4.1.5. Both the RSE and the IAOC must not allow the reporting relationship to influence the cooperative relationship, and vice versa. The RSE must keep the IAOC informed so they may fulfill their obligations regarding legal and financial oversight of the RSE contract. If there is a disagreement in this area, the IAOC and RSE must bring that to the attention of the IAB, which will have the final word on the subject. The IAOC cannot on its own remove the RSE from office. If there is a persistent concern about RSE contractual performance, it must be reviewed by the IAB. The IAB must in turn consult with the RSAG. 4.2. RSE General Responsibilities The RFC Series Editor is responsible for, and has authority in, the following areas Kowack Expires April 29, 2011 [Page 20] Internet-Draft RFC Editor Model (Version 2) October 2010 4.2.1. Maintain Series Continuity There are many issues associated with RFC Series continuity, including the look and feel of the series, indexing methods, policies for and accessibility of the publications, archiving and publication policies, IPR and copyright issues, errata policies and procedures, and publication format policies. Series continuity comprises editorial continuity and operational continuity. Editorial continuity is the maintenance and development of the editorial character of the Series (e.g., look and feel) in a way that preserves the constancy of the series. Constancy means that changes will be made only when there is good reason to do so; when changes are required (e.g., in the format of RFCs)), they will be done in a deliberate, evolutionary way that respects the long-standing editorial practices of the series. Changes will be made with input from editorial staff, and will be available for review by and input from the community. The more substantive, broad, or abrupt a proposed change, the more important it will be to solicit agreement from the community before making the change. The RFC Series Style Manual is the primary vehicle for maintaining constancy in, and making changes to, editorial continuity. The RSE will prepare and maintain an RFC Style Manual to describe clearly the grammar, style, usage, typography, punctuation, and spelling standards that will guide the drafting and editing of RFCs, so that all publications will appear in clear, concise technical prose. The primary audiences for the Style Manual are authors, editors, the stream managers, the RFC Production Center, and the RFC Publisher. Implementation of many continuity-related decisions within the Style Manual will reside with the RFC production and publishing functions, as directed by the RSE. Operational Continuity. Over the long run, editorial staff must produce RFCs from drafts at least at the same rate the streams submit drafts. Operational continuity is maintaining and planning for consistent, regular output from RFC Editor staff including contractors. This includes all related editorial staff support activities, including feedback and advice for authors and streams, regular reports, liaison activities, and attendance at meetings. If there is a disruption of editorial services, the RFC Series Editor and the IAOC are responsible for promptly acquiring and directing new resources to maintain RFC output. New teams of editors or additional contractors may be needed. The RSE must keep the RFC Editor Procedures Manual and Style Manual up to date to provide sufficient direction to alternate editors, per above. The RSE must maintain sound understanding of those processes in order to direct new Kowack Expires April 29, 2011 [Page 21] Internet-Draft RFC Editor Model (Version 2) October 2010 resources when required. We refer to maintaining editorial output during a disruption as "exceptional continuity". As in all matters when planning for or maintenance of operational continuity has legal or contractual consequences, the RSE will communicate and coordinate with the IAOC. 4.2.2. Maintain and Develop RFC Series Quality RFC Series quality is the collective responsibility of the Internet technical community. The RFC Series Editor shares responsibility for editorial quality with the other members of the RFC Editor. The streams each have responsibility for technical and content quality in their respective areas. The RSE's quality responsibilities include editorial quality delivered through published RFCs, editorial service (or process) quality provided to the streams, and quality of access, accessibility, and access services for users. The RSE must develop and maintain output measurement techniques and statistics collection in order to monitor and improve service (production) quality. The RSE is also responsible for advancing the overall quality of the series, in cooperation with the community and its entities, especially the streams. 4.2.2.1. Quality Editorial quality management comprises changes made by RFC Editor staff as drafts are refined into published RFCs. Editorial quality must meet the requirements of three groups: o authoritative community entities (e.g., the IETF Trust regarding IP notices), o authors and streams ("producer-side service quality"), and o re-distributors and users of RFCs ("consumption-side quality") The RFC Series Editor must maintain and develop editorial quality that satisfies and balances requirements of all three groups. During 2010, it was determined that the community has almost no knowledge of the demographics of RFCs end-users, of how they use RFCs, or end-user requirements. The RSE should seek to learn more about RFC end-use and end-users to inform quality-related decisions, discussed immediately below in Section 4.2.2.2. Work to date suggests that the end-user community may include the following groups: Kowack Expires April 29, 2011 [Page 22] Internet-Draft RFC Editor Model (Version 2) October 2010 o RFC implementers. This group intersects with working group participants. The latter is an unknown proportion of the former, o network operators (of RFC implementations), o academics, researchers and students, o marketers, and requirements writers, o policy-makers, and o re-distributors (e.g., mirror site operators) and publishers. The RSE should improve collective understanding of the demographics of RFC use and its implications for RFC quality. The RSE should seek community participation in this effort, especially stream members. The RSE should discuss findings with the community and streams to determine any impact on editorial goals and practices. 4.2.2.2. RFC Editor production and service quality There are the three principal RFC Editor services, each with specific quality requirements: o processing of drafts into RFCs and support for authors and the streams, provided by the RFC Editor, o access-related services provided via the RFC Publisher, and o general writing guidance and training for authors and others in the streams. Draft processing and support ("production-side support") . Presently, the RFC Editor provides only one level of editing and support, which is minimal and does not vary according to the needs of particular drafts. The RSE will continue to develop practices in this area to respond to changing general needs and specific draft- editing requirements. In the latter case, the RSE will investigate whether a "red flag" service is appropriate. Such a service, available on authors' request, would give special attention to drafts thought to be particularly complex, extensive, or to have an especially critical audience. The RSE will determine whether there are resource consequences to planned changes to editorial practices. Access-related services. Access-related services include web site services such as search and indexing tools. The RSE should continue to develop these services. As stated above, most implementation will be by contractors and volunteers. Kowack Expires April 29, 2011 [Page 23] Internet-Draft RFC Editor Model (Version 2) October 2010 Stream and author guidance and training During 2010, the RSE received repeated requests for general technical writing training, especially for non-native speakers of English. The RSE should investigate this area and look for opportunities to reduce authors' costs (largely in time), improve the quality of drafts submitted, and reduce RFC Editor processing time and costs. 4.2.2.3. Performance Measures and Statistics As executive-level manager, the RSE will direct development of carefully-targeted RFC Editor performance measures, including statistics, their graphical representation, and publication on the RFC Editor web site and elsewhere. Creating meaningful production statistics is complex, subtle, and error-prone. Even simple and obvious statistics can mislead observers and motivate suboptimal editing and production. The RSE will improve measures to illuminate productivity and minimize distortion. The RSE will aid the community in understanding the meaning and limitations of published statistics. The RSE will use performance measures as input to planning with the IAOC and to inform contracts, contract revisions, and requests for proposals. 4.2.2.4. RFC Editor and RSE professional expertise The RSE will maintain RFC Editor professional expertise in two areas. The RSE will ensure that staff and contractors maintain minimum standards of, and steadily improve, professional skills and knowledge. Staff professional advancement is the responsibility of the RSE. Contractor professional development is the responsibility of the contractor, as directed by the RSE by inclusion in contracts. The RSE is responsible for maintaining and developing his own expertise as needed to support the requirements and processes described in this document. This includes developing intimate knowledge of editorial practices and procedures to protect the community from service disruption, developing editorial services and the Series overall, and advising the community and staff. 4.2.2.5. Survey Overall Series Quality [RFC5620] section 3.1 states that the RFC Editor is to exercise "executive-level management over the implementation of policies, process, and procedures established to ensure the quality and consistency of the RFC Series." The RSE will at least once every three years survey overall Series quality to verify that the Series is meeting the needs of the community at large, production side customers (streams), consumption side customers (end users), and Kowack Expires April 29, 2011 [Page 24] Internet-Draft RFC Editor Model (Version 2) October 2010 others. This evaluation will include analyses of long-term quality trends and measures. The RSE will seek the streams' participation. The RSE will publish a report, preferably jointly with the streams, including recommendations for improvements. 4.2.3. Represent the RFC Series to the Community The RSE will represent the RFC Editor, the Series, and its long-term development, to the community. This includes keeping the community informed of ongoing activities and progress against plans, analyses and observations, exceptional items, and long-term plans. Accordingly, the RSE will participate in RFC Editor on-line facilities such as web sites, and editor-oriented mail lists and discussion media. The RSE is responsible for ensuring that every inquiry or complaint about the Series receives a timely and appropriate response. 4.2.4. Represent and promote the RFC Series to the outside world The RSE will represent and promote the Series to the outside world. Promotion concerns: 1. Identifying and communicating with those who would benefit from the RFC Series, and showing them where and how to access the series. Promotion complements accessibility. This includes ensuring the RFC Series is accessible via conventional means, such as electronic card catalogs, and ISSN numbers, which must be kept current. 2. Improving broad awareness of the role of, and contributions by, the technical community widely, and in targeted communities. Increasing the stature of the Series reinforces other community initiatives. Promotion can rapidly become very costly in both time (especially management opportunity cost) and money. The RSE's priority is to do at least rudimentary promotion that is economical and readily accomplished. The RSE should undertake extensive promotions only after discussion with the community. Explanations of costs and specific, targeted benefits should always accompany recommendations for promotional efforts. Over the long run, the RSE should survey comparable organizations and series to see how they promote themselves and what that suggests for RFC Series promotion. Kowack Expires April 29, 2011 [Page 25] Internet-Draft RFC Editor Model (Version 2) October 2010 4.2.5. Identify and lead community discussion In collaboration with the RFC Series Advisory Group (RSAG), the RSE will identify and lead community discussion of important issues and opportunities facing the RFC Series. The RSAG may formally request that the RSE to investigate areas it believes have not been sufficiently addressed. 4.3. RFC Series Editor Specific Responsibilities In addition to the processes, requirements, and activities above, the RSE is responsible for the following specific items. Some major items described above are repeated here. 4.3.1. General Planning, Prioritization, and Reporting Many of the responsibilities and tasks in this document are open- ended. The RSE cannot accomplish all these tasks at the same time with any reasonable level of resources. The RSE must manage the extent of tasks, and their prioritization and execution. The RSE must clearly communicate plans and expectations to the community and other entities. 1. Within 6 months of the RSE's appointment, or a date agreed with the IAB, the RSE will publish an initial work plan and road map. The RSE will indicate which initiatives and activities will be focused on over the remainder of the first calendar year, including their own activities and those of other RFC Editor Components. These plans will distinguish between ongoing operational duties and focused initiatives. In developing this initial plan, the RSE will have had the assistance of the RSAG. 2. By 5 December each year thereafter, the RSE will publish a plan and road map for the upcoming calendar year. 3. By 1 February each year, the RSE will publish an Annual Report of the RFC Editor. This will include a review against the preceding year's plans and highlight lessons learned that are reflected in the new calendar year plan and road map. Summary statistics will be included. The RSE may ask RFC Editor components to produce relevant reports on request. The RSAG will review and comment on the RSE's draft before the final annual report is published. The RSE will issue a monthly report for delivery to the IAB and publication to the community. Kowack Expires April 29, 2011 [Page 26] Internet-Draft RFC Editor Model (Version 2) October 2010 4.3.2. RFC Series Continuity The RSE will take all steps necessary to maintain the editorial and operational continuity and consistency of the Series consistent with the procedures described elsewhere in this document. The RSE will maintain the Style and Procedures Manuals in support of consistency and proper RFC Editor operations. The Procedures Manual will include a description of tasks performed by the RSE. The RSE will publish a long-term schedule for regular (by default annual) updates to and reviews of, each document. This does not preclude occasional or as-required incremental updates to these documents. 4.3.3. Reviews The RSE may conduct reviews of any process or component of the RFC Editor at any time. The RSE will conduct annual assessments of the RFC process and of all components of the RFC Editor (ISE and Stream, RFC Production Center and RFC Publisher). Reviews will incorporate feedback from the RSAG and will include input from the community. Reviews will be presented to the IAB and be available to the community. Reviews of the ISE will follow procedures that respect the independence of the ISE and Independent Submission Stream. In particular, the RSE will request a member of the RSAG to independently create and chair an Independent Submission Stream and Editor review committee. The committee will consist of 5 regular members, at least three of whom will come from the RSAG; two may come from the community, appointed by the chair after an open call to the community. The RSE and the chair of the IS review committee will jointly develop a review process and outline, which will then be independently completed by the review committee. Comprehensive annual reviews may prove costly and unnecessary. Accordingly, the RSE may elect, after discussion with the IAB, RSAG, and IAOC, to alternate limited and comprehensive reviews on two or three-year cycles. The RSE will participate, on request, in IAB-initiated external reviews of the RFC Editor and/or any of its components, and will support and coordinate with the IAB and/or IAOC as required. Kowack Expires April 29, 2011 [Page 27] Internet-Draft RFC Editor Model (Version 2) October 2010 4.3.4. Regular RFC Editor Operations and RFC Series Oversight The RSE will manage day-to-day operational issues that have not previously been delegated (i.e., to contractors), including: 1. managing issues as they arise from the streams (production side customers), community, entities, and from within the RFC Editor components, 2. resolving resource allocation questions, including balancing stream requests for priority handling of drafts, 3. organizing, structuring, and leading regular and special RFC Editor meetings, 4. participating in author document reviews, 5. developing and maintaining FAQs for RFC publication, and 6. administering and participating (directly or via delegates) in various (e.g., rfc-interest) RFC Editor-related mailing lists. 4.3.5. Ongoing Developmental Issues The RSE will: 1. work with the stream managers in maintaining policies for an RFC errata process, 2. develop policies for the types of indexes that the RFC series will support by default and the metadata that may be required to support those indexes, and 3. approve tools for the validation of syntax of documents containing formal languages. 4.3.6. Liaison, Coordination, and Collaboration The RSE will: 1. provide all necessary points of contact and services to support policy inputs and questions (from, for example, the community or other entities), 2. take part in formal meetings, telechats, and other communications among entities (e.g., IESG and IAB), as well as general meetings such as the IETF, or retreats, as required. The RSE will make reports as required, Kowack Expires April 29, 2011 [Page 28] Internet-Draft RFC Editor Model (Version 2) October 2010 3. conduct coordination meetings (including, e.g., telechats) with the streams (production-side customers) and components of the RFC Editor, 4. liaise and work with the IAB so that the IAB may be confident there has been sufficient community review before significant policies or policy changes are adopted, and 5. participate, on request, in IAB-initiated external reviews of the RFC Editor and/or any of its components, coordinating with the IAB and/or IAOC as required. 4.3.7. Process and Document Evolution and Innovations The RSE will consider innovations to improve efficiency, coordination, transparency, and quality. The RSE will continuously monitor the RFC production process for possible improvements, and propose and evaluate experiments as input to RSE recommendations. The RSE will also, as appropriate, support process experiments proposed by the Internet community. 4.3.8. Organize and Structure Performance Measures The RSE is responsible for requesting appropriate contractor reports, including statistics. Contractors will allocate sufficient resources to satisfy reporting activities and to respond to requests for changes. 4.4. RSE Professional Qualifications The RFC Series Editor provides general and editorial leadership of the RFC Editor, and meets the following qualifications unless noted otherwise: 1. Experience as a senior manager and subject matter expert in technical writing, technical publications, and technical series development. Executive management experience must be commensurate with the requirements outlined elsewhere in this document and the many aspects of the RSE role, including the tasks of coordinating the overall RFC Editor process, 2. Experience with complex organizations with substantial group processes. The RSE must be skilled at participating in group processes, managing and getting value from them. The RSE must understand and appreciate delegation. Experience with and understanding of the IETF and RFC process is desirable. Kowack Expires April 29, 2011 [Page 29] Internet-Draft RFC Editor Model (Version 2) October 2010 3. Good understanding of the English language and technical terminology related to the Internet, 4. Excellent skill communication and, especially, listening, 5. Independent worker, and 6. Experience as an RFC author is desirable. 4.5. RSE Term of Office The default RSE term of office is five years with no restrictions on renewals, and with provision for shorter actual contracts and intermediate reviews. Individual contract periods may be shorter due to practical issues. Specific contract duration will be determined by the IAOC with participation by the RSE Search and Selection Committee, per their defined participation in the hiring process, and with the agreement of the IAB. Terms of office for the RSE, ISE, and RFC Production Center must be adjusted to avoid concurrent transitions. 5. Independent Submission Editor 5.1. Independent Submission Editor General Responsibilities The Independent Submission Editor (ISE) provides general and editorial leadership of the Independent Submissions Stream. The ISE is an individual who may have assistants and who is responsible for: 1. Maintaining technical quality of the Independent Submission stream. 2. Reviewing, approving, and processing Independent Submissions. 3. Forwarding to the Production Center the Internet-Drafts that have been accepted for publication as RFCs in the Independent Submission Stream. 4. Reviewing and approving RFC errata in Independent Submissions. 5. Coordinating work and conforming to general RFC Series policies as specified by the IAB and RSE. 6. Providing statistics and documentation as requested by the RSE. 7. Providing sufficient resources (i.e., ISE time) to support RFC Series Editor reviews of the Independent Submissions Stream, and Kowack Expires April 29, 2011 [Page 30] Internet-Draft RFC Editor Model (Version 2) October 2010 external reviews of the RFC Editor initiated by the IAB or IAOC. 8. Being available when possible to participate in escalation procedures and RFC Editor focused internal reviews. 5.2. ISE Professional Qualifications The Independent Submission Editor is a senior position for which the following qualifications are desired: 1. Technical competence, i.e., broad technical experience and perspective across the whole range of Internet technologies and applications, and specifically, the ability to work effectively with portions of that spectrum in which no personal expertise exists. 2. Thorough familiarity with the RFC series. 3. An ability to define and constitute advisory and document review arrangements. If those arrangements include an Editorial Board similar to the current one or some equivalent arrangement, assess the technical competence of potential Editorial Board members. 4. Good standing in the technical community, in and beyond the IETF. 5. Demonstrated editorial skills, good command of the English language, and demonstrated history of being able to work effectively with technical documents and materials created by others. 6. The ability to work effectively in a multi-actor environment with divided authority and responsibility similar to that described in this document. The Independent Submission Editor may seek support from an advisory board Section 5.2qu and may form a team to perform the activities needed to fulfill his responsibilities. The individual with the listed qualifications will be selected by the IAB after input is collected from the community. An approach similar to the one used by the IAB to select an IAOC member every other year (as described in Appendix A) should be used. While the ISE itself is considered a volunteer function, the IAB considers maintaining the Independent Submission stream within the RFC Series part of the IAB's supported activities, and will include the expenses made for the support of the ISE in its IASA-supported budget. Kowack Expires April 29, 2011 [Page 31] Internet-Draft RFC Editor Model (Version 2) October 2010 5.3. ISE Term of Office The default ISE term of office is five years with no restrictions on renewals, and with provision for shorter actual contracts and intermediate reviews. Individual contract periods may be shorter due to practical issues. Terms of office for the RSE, ISE, and RFC Production Center should be staggered to avoid terminating concurrently. 5.4. Independent Submission Stream Editorial Board The Independent Stream Editor is supported by an Editorial Board for the review of Independent Submission stream documents. This volunteer Editorial Board currently exists, and its members serve, at the pleasure of the ISE. The existence of this board is simply noted within this model; additional discussion is out of scope for this document. 6. RFC Production Center RFC Production is performed by a paid contractor, and the contractor responsibilities include, under the direction of the RSE: 1. Editing inputs from all RFC streams to comply with the RFC Style Manual, 2. Creating records of edits performed on documents; 3. Identifying where editorial changes might have technical impact and seeking necessary clarification, 4. Engaging in dialogue with authors, document shepherds, IANA, and/or stream-dependent contacts when clarification is needed, 5. Creating records of dialogue with document authors, 6. Requesting advice from the RFC Series Editor as needed, 7. Offering suggestions to the RFC Series Editor as needed, 8. Providing sufficient resources to support reviews of RFC Publisher performance by the RFC Series Editor and external reviews of the RFC Editor initiated by the IAB or IAOC, 9. Coordinating with IANA to perform protocol parameter registry actions, Kowack Expires April 29, 2011 [Page 32] Internet-Draft RFC Editor Model (Version 2) October 2010 10. Assigning RFC numbers, 11. Establishing publication readiness of each document through communication with the authors, document shepherds, IANA and/or stream-dependent contacts, and, if needed, with the RFC Series Editor, 12. Forwarding ready-to-publish documents to the RFC Publisher, 13. Forwarding records of edits and author dialogue to the RFC Publisher so these can be preserved, and 14. Liaising with various streams as requested by the RSE. The RFC Production Center contractor should be selected by the RSE and IAOC through an open RFP process. The RSE and IAOC will seek bidders who, among other things, are able to provide a professional, quality, timely, and cost- effective service against the established style and production guidelines. Contract terms, including length of contract, extensions and renewals, shall be as defined in an RFP. The opportunity to bid shall be broadly available. 7. RFC Publisher The RFC Publisher comprises the managed computing resources where RFCs and related information are archived, publicized, and that support open access. Included are the management services required to support and maintain that capability. The term "RFC Publisher" does not follow common usage; it does not in any way refer to the senior manager in a publishing organization. RFC Publisher responsibilities include: 1. Announcing and providing on-line access to RFCs. 2. Providing on-line system to submit RFC Errata. 3. Providing on-line access to approved RFC Errata. 4. Providing backups. 5. Providing storage and preservation of records. 6. Authenticating RFCs for legal proceedings. All these activities are under general supervision of the RSE, who will provide an appropriate level of coordination with the streams Kowack Expires April 29, 2011 [Page 33] Internet-Draft RFC Editor Model (Version 2) October 2010 and other entities as required The publisher is inherently a far simpler service to implement and manage than any other component of the RFC Editor. Experience gained during 2010 shows that combining the publisher with another subcontract (in this case the IETF Secretariat contract) can be effective and can reduce management overhead. Separate publisher implementation could increase overhead costs. 8. Committees 8.1. RFC Series Advisory Group (RSAG) 8.1.1. Charter The RSAG provides expert, informed guidance (chiefly) to the RSE in matters affecting the RFC Series' operation and development. That includes providing long-term perspective in support of consistency and constancy of the RFC Series interpretation over time. Such matters include, but are not limited to, issues in operation of and planning for RFC model components, and consideration of additional RFC streams, to give a sense of the range of topics covered. The RSAG serves four functions: 1. advising the RSE, upon request, on matters related to operation and direction of the Series, 2. supporting the RSE's connection to and alignment with the community through informal community discussions, and by discussion with the RSE about their observations regarding community opinion and RSE engagement with the community, 3. participating, and providing leadership, in RSE analysis and review committees on request of the RSE, and 4. providing counsel to the IAB or IAOC in situations where the RSE cannot be available. The group provides guidance to the RSE, who as required will address operational issues or opportunities with other components of the RFC Editor. In cases where these issues have contractual or financial effects, the RSE works cooperatively with the IAOC, as described elsewhere in this document. The RSAG also serves to advise the RSE on long-term, large-scale developments for the RFC Series. This informs the proposals the RSE takes to the community for discussion, and to the IAOC as proposals for implementation. Kowack Expires April 29, 2011 [Page 34] Internet-Draft RFC Editor Model (Version 2) October 2010 The RSAG will assist the RSE in identifying and leading community discussion of important issues and opportunities facing the RFC Series. In this way, the RSAG ensures the RSE is aware of community opinion and requirements. In turn, the RSE must keep the RSAG sufficiently informed of major issues and plans so that the RSAG may interact with the community knowledgeably; and so that in cases where the community, the IAB, or the IAOC require (as described above), the RSAG will be able to provide their informed counsel. The RSAG is chartered by the IAB. As such, the RSAG operates independently of the IAB to fulfill that charter. The IAB retains its oversight role and is responsible for ensuring that the community has adequate discussion of important topics. 8.1.2. Membership RSAG full (non-liaison) members are all at-large members; they do not represent a particular RFC stream or any organizations. The RSE is a member, and unless she chooses otherwise, RSAG chair. Full members serve staggered, 3-year terms, with no limit on renewals. There is no hard upward limit on the number of full RSAG members, but it is anticipated that it will remain roughly around the "low teens" to facilitate committee management and ease of discussion. The RSE selects members for their experience and interest in the RFC Series as well as in editing and publishing. Outside (non community members) editorial and publishing experts may be members, especially well-known leaders in technical writing and publications. Outside experts must not be more than a minority of full members. In particular, there is no requirement or expectation that RSAG members will be IAB members. The Series Editor proposes RSAG members in consultation with sitting RSAG members; the IAB then confirms and formally appoints those members. In addition to full members, each RFC stream approver will appoint a liaison to the RSAG to provide context specific to their stream. The liaisons need not be members of the stream approval bodies. Initially, there will be no IAOC or IAB liaison for their oversight role; however, as experience is gained, the IAOC, IAB, or RSAG may request such liaisons. Unless explicitly indicated otherwise, only full RSAG members will provide direct counsel to the IAB or IAOC. The RSAG does not select or appoint the RSE, or any other component of the RFC Editor model, although it is an important resource for informing any selection process. Kowack Expires April 29, 2011 [Page 35] Internet-Draft RFC Editor Model (Version 2) October 2010 The full members will serve at the pleasure of the IAB -- appointed by the IAB, and if necessary, removed by the IAB, which will only be done for reasons of professional misconduct or long-term non- participation. The IAB must confer with the RSE and the full members before removing a member. During the term of the Transitional RFC Series Editor, the RSAG has been on interim status. Once appointed, the new RSE will ask standing members to indicate their staggering preferences; the RSE will then determine and publicize terms of appointment, and declare the RSAG to be on permanent status. 9. Resolution of Disagreements 9.1. Disagreements between RFC Editor Components and Model Participants If during the execution of their activities, a disagreement arises over an implementation decision made by one of the components in the model, any relevant party should first request a review and reconsideration of the decision with the other party or parties, and inform the RSE that this activity is underway. All parties should work informally and in good faith to reach a mutually agreeable conclusion. If the parties resolve the issue, they should inform the RSE of the resolution and specify any procedural or other changes that it may entail. If one party still disagrees after the reconsideration, that party should ask the RSE to undertake a formal review. The RSE must inform and engage the RSAG in their advisory capacity, and may call for a review committee including members of the RSAG. The RSE and RSAG should seek to reach rough consensus on the resolution of the matter. If there is a technical or procedural matter that concerns the IAB, or an administrative, legal, or financial issue that concerns the IAOC, the RSE may request the guidance or participation of either or both of those bodies. If the disagreement directly involves the RSE, the RSE may ask the IAB to mediate or appoint a mediator to aid in the discussions, although the IAB is not obliged to do so. The RSAG should be used in this capacity unless there is good reason it should not (such as if the RSAG itself is a party to the disagreement). If a timely decision cannot be reached through discussion, mediation, and mutual agreement, the Series Editor is expected to make whatever decisions are needed to ensure the smooth functioning of the RFC Editor function. Such decisions must follow proper community- oriented practices as described in Section 4. Kowack Expires April 29, 2011 [Page 36] Internet-Draft RFC Editor Model (Version 2) October 2010 RSE decisions of this type are limited to the functioning of the RFC Editor processes and evaluation of whether current policies are being implemented appropriately or need adjustment. As described in Section 4, final decisions about the technical content of individual documents are the exclusive responsibility of the stream approvers for those documents. If a disagreement or decision has immediate or anticipated future contractual consequences, the Series Editor must identify the issue to the IAOC and, if the RSAG has provided related advice, the RSE should forward that to the IAOC. 9.2. RSE Review of Inter-Stream Conflicts Streams are encouraged to resolve conflicts on their own. Any stream approver may request RSE review of an inter-stream conflict at any time. Review by the RSE must include assembling a review committee of four disinterested RSAG members plus the RSE, who will chair the committee. RSE recommendations must be consistent with existing RFC-documented policy, insofar as documented policy covers the issue. RSE recommendations may not use informal (that is non-RFC) statements of practices such as those found in stream-internal documentation (such as web pages). 10. Re-Establishing an RFC Editor Stream Capability Before publication of RFC 4844, the RFC Editor could produce RFC Editor -related documents whenever the RSE thought them necessary, without approval from other entities. By formally dividing new document production into four distinct partitions, RFC 4844 eliminated this capability. Today, if the RSE wishes to publish an RFC, it must be approved by one of the streams. None is suitable; each could impose process or content requirements on the RSE, which could reduce the RFC Editor's independence. This might be especially so if the draft in question has impact on one or more of the streams. Adding new processes to permit RFC Editor publications to each stream would be complex and time-consuming, and would not clearly result in a satisfactory process. The Independent Submissions Stream, being a general-purpose stream under the RFC Editor, might appear suitable. However, if an RFC Editor draft were politically significant, some parties might put pressure on the Independent Submissions Editor- and on the RSE - which could jeopardize Independent Stream autonomy. The RSE must take all steps necessary to create an "RFC Editor Stream" as soon as practical. The RFC Editor Stream charter is to Kowack Expires April 29, 2011 [Page 37] Internet-Draft RFC Editor Model (Version 2) October 2010 produce Informational RFCs pertaining to the RFC Series in general, to the operation, practices, and performance of the RFC Editor, and to editorial subjects of interest to the community, including authors and draft editors from the streams. The Series Editor will be the stream approver. The RSE may accept and publish in-topic documents from outside the RFC Editor. The full members of the RSAG will comprise the (strictly) advisory editorial board of the RFC Editor stream. The RSE, in cooperation with the RSAG, will define a document approval process for this stream, to be presented to the community for review and feedback. Section 5, [RFC4844], discourages the creation of new streams. In order to be economical about adding this stream, the RFC Editor Stream could be the designated as the future repository of archived (and discontinued) series. In this case, it might be useful to begin the concept of the 'sub-stream', under which different 'adopted' archived series might reside. 11. Future Considerations In time, it may be necessary to provide oversight for the RFC Editor that is more active, focused and expert than is possible under the IAB. In that case, it may be useful to divide the RSAG into two groups. One could continue to provide guidance, the other could undertake the responsibilities and activities currently performed by the IAB. 12. IANA Considerations This document defines several functions within the overall RFC Editor structure, and it places the day-to-day coordination of registry value assignments with the RFC Production Center under the direction of the RSE. The IAOC will continue to facilitate the establishment of the relationship between the RFC Editor and IANA. This document does not create a new registry nor does it register any values in existing registries, and no IANA action is required. 13. Security Considerations The same security considerations as those in RFC 4844 apply. The processes for the publication of documents must prevent the introduction of unapproved changes. Since the RFC Editor maintains the index of publications, sufficient security must be in place to prevent these published documents from being changed by external Kowack Expires April 29, 2011 [Page 38] Internet-Draft RFC Editor Model (Version 2) October 2010 parties. The archive of RFC documents, any source documents needed to recreate the RFC documents, and any associated original documents (such as lists of errata, tools, and, for some early items, non- machine-readable originals) need to be secured against failure of the storage medium and other similar disasters. The RSE and IAOC should take these security considerations into account during the implementation of this RFC Editor model. 14. Acknowledgments [ed., TBD] 15. References 15.1. Normative References [RFC4844] Daigle, L. and IAB, "", 4844 RFC, July 2007. [RFC5620] Kolkman, O. and IAB, "RFC Series Editor Model (Version 1)", RFC 5620, August 2009. 15.2. Informative References [RFC4333] Huston, G. and G. Wijen, "The IETF Administrative Oversight Committee (IAOC) Member Selection Guidelines and Process", RFC 4333, December 2005. Appendix A. 2010-11 RSE Search and Selection Process This appendix describes the structures and processes for finding and selecting the first long-term RFC Series Editor, specifically during late 2010 and early 2011. A.1. Overview and Criteria Five community members will serve on a seven-member RSE Search and Selection (SSC) committee. The design of this committee aims to satisfy several key requirements. To ensure a representative range of points of view, the committee will be populated from different parts of the community. Committee members will have expertise in community processes, and there will be advisors from relevant professions. The SSC selection process will ensure that members will have the requisite background and skill for their mission. The process is defined to reduce confusion or risk of process failure. Kowack Expires April 29, 2011 [Page 39] Internet-Draft RFC Editor Model (Version 2) October 2010 Finally, the committee is intentionally small to permit quicker action and easier exchange of information. A.2. Structure The seven-member SSC will consist of five regular (voting) members: o two regular members appointed by the stream approvers, o two regular members appointed by RSAG regular members (that is, liaisons will not participate in the RSAG selection process), o one regular member appointed by [ed., TBD]. plus two non-voting advisors: o a volunteer Human Resources (HR) professional from the computing or networking industry, and o the Transitional RFC Series Editor All SSC members will be at-large members; each is to represent the community, not the group that appointed them. The committee will select a chair among the regular members. The SSC may appoint assistants as required. Decisions will be by rough consensus unless the committee chooses other processes. A.3. Stream Appointments The IETF stream approver, the IESG, will appoint one SSC member by a process of its choosing. The other three stream approvers (IAB, IRSG, and ISE) will collectively appoint the other member by a process of their own choosing. To ensure broad support for appointments, each stream appointee must be approved by the other stream approvers; that is, the IESG approver must approve the member proposed by the IAB, IRSG, and ISE approvers, and vice versa). Streams appointees may, but need not, be current participants in the streams or current stream leaders. To promote broad participation, current stream chairs are not eligible for appointment to the SSC. Each stream approver should widely survey members of their streams when making their selection. A.4. RSAG Appointees The two RSAG appointees may be from the RSAG or from the greater community. One of the two appointees may be a highly respected leader from the technical publications world without previous direct Kowack Expires April 29, 2011 [Page 40] Internet-Draft RFC Editor Model (Version 2) October 2010 participation in the community. The RSAG should seek community comment on their prospective candidate(s). A.5. SSC Regular Member Qualifications All SSC regular members must have: o broad experience and wide respect within the community, o experience interviewing and evaluating prospective hires and with interviewing,, o significant experience with editorial practices, and o skill at analyzing and resolving complex issues as members of teams. A.6. Additional Qualifications for Streams Appointees The streams appointees must have solid knowledge of stream editorial requirements and typical RFC Editor interactions from within at least one stream. A.7. Additional Qualifications for RSAG Appointees The RSAG appointees must have extensive knowledge of editorial practices in general and specifically of the processes of the RFC Editor and the duties and challenges of the RSE. This criterion may be ignored if one of the RSAG appointees is a leader in technical publishing, per above. The vast majority of RSE candidates will come from technical publishing, a profession different from that of most members of the community. Community members generally do not have extensive experience in search and hiring. To ensure that qualified candidates apply, the SSC will use the services of a professional search firm. A search professional may act as SSC HR advisor, or the SSC may require a separate HR advisor. The RSE and IAOC will locate a professional search firm in cooperation with the IAB. The SSC will have final approval of the search professional. The RSE will support the IAOC in determining budget requirements. The IAOC and IAB will seek financial support for a search firm. Kowack Expires April 29, 2011 [Page 41] Internet-Draft RFC Editor Model (Version 2) October 2010 A.8. Non-Voting Members In cooperation with the IAB, the TRSE will make a community call for a volunteer HR professional to serve on the SSC. The SSC have final approval for any such selection. If they a suitable candidate is not found, an HR professional will be sought with the assistance of ISOC staff; support will be sought from ISOC. The TRSE will advise the SSC on the RSE job description and the search and selection process, and on other topics on request. The TRSE will draft calls for candidates before the first meeting of the SSC and will be available to write or modify documents on request. The HR professional will provide guidance on hiring law and on standard HR processes, and practices. A.9. SSC Assistants and Additional Expert Advisors The SSC may engage volunteer help as needed from across the community and elsewhere. The SSC will publish names of volunteers and their roles. The SSC may also seek compensated expert help if required and unavailable on a volunteer basis. Names and roles of experts will be made public unless not possible due to confidentiality requirements. A.10. SSC Approval of Job Description The SSC will have final approval over job description postings, but may not diverge from RFC 5620bis. A.11. Financial and Legal Preparations Before the public call for RSE candidates, in cooperation with the IAB and the IAOC the TRSE will locate a suitable compensation specialist to be hired by the IAOC. The specialist will work with the TRSE to determine RSE compensation and related matters. In cooperation with the IAB, the TRSE will support the IAOC in determining a budget line item. The goal of the TRSE and IAOC is to have this information in place before the first meeting of the SSC. The SSC will review these items as soon as they are available and have right of approval of the budget items. SSC approval is required, also, to ensure that SSC are able to fulfill their mission. The TRSE will publish RSE compensation information to the community once it is available. There will be a budget for the SSC. Besides including the search firm and compensation specialist fees, the SSC and IAOC will agree on an advertising budget, and other items as required by the SSC. Kowack Expires April 29, 2011 [Page 42] Internet-Draft RFC Editor Model (Version 2) October 2010 The SSC will review the IAOC's RSE contractual terms with the IAOC to ensure that the process is effective and to maintain alignment between candidate and community requirements from start to finish. The committee may request changes to contract terms to reduce unnecessary barriers to unconventional candidates of otherwise high quality suited to this unusual position. A.12. SSC Alignment with RSE Job Description Hiring is a complex activity and no candidate will be a perfect fit. However, the committee may not diverge from the job description and 5620bis. A.13. SSC Call for Candidates The call for candidates will describe the application process. It will be distributed worldwide, including at least: o across the community, and o beyond the community: o technical publications offices at universities and research institutes, o technical publishers, including journals, o technical publications offices in technology companies, o government technical publications offices, and o other standards bodies, to be defined. The SSC will determine where to post notices, including mail lists and popular job posting web sites. The SSC is encouraged to use the personal networks of the community to "get the word out" but also cautioned to avoid language and postings that could encourage unqualified applicants. A.14. Applications and Short List The SSC will be responsible, with the support of the RSE and the HR professional, for the search and hiring process. The SSC will use interviews, reference checks, and other means to select a short list of no more than 10 candidates. Kowack Expires April 29, 2011 [Page 43] Internet-Draft RFC Editor Model (Version 2) October 2010 A.15. Confidentiality Aspects of the hiring process must be confidential, out of respect for candidates' needs, and by law. Nevertheless, the SSC will make every effort to communicate progress to the community. It is likely that community discussion of candidates will have to be limited to individuals or small groups. Members of the SSC and volunteers who participate in these reviews will be privy to confidential material and must agree to respect confidentiality. A.16. Best and Final The SSC will select a final candidate, or, at their discretion, two or three finalists. Before the SSC selects an RSE, the candidate(s) will meet with community leaders and primary colleagues of the RSE, including: o IAB Chair, o IAOC Chair and IAD, o IETF chair, o IRSG chair, o Independent Submissions Editor, and o Production Center Director. These interviews are for thoroughness, and to give each candidate an opportunity to meet the people with whom the RSE must work most closely -- a critical step for anyone considering the position. Interviews will be primarily by phone, but for a single preferred candidate may be face-to-face, if necessary. Interview results will be an important input to the SSC's decision. But these meetings do not imply that participants have final approval or veto power over the SSC's selection. A.17. IAB Process Review The SSC will send notice of their selection to the IAB. Notice will include the candidate's qualifications with respect to the RSE job description, and a review of the process. The IAB will review the search and selection process for completeness and compliance. If the IAB does not find any exceptions to process, it must approve the candidate. The IAB may not change the selection of the committee. If the IAB finds process exceptions, it must not step in and manage the search and selection process. It must publish a report to the Kowack Expires April 29, 2011 [Page 44] Internet-Draft RFC Editor Model (Version 2) October 2010 community about what those exceptions are and call for new search and selection activity with new process requirements. A.18. IAOC / SSC Joint Negotiation The SSC chair will shepherd the selected applicant through the final contracting process. The IAOC will negotiate the contract with the selected candidate in close consultation with the SSC chair. A start date for the new RSE will be agreed during negotiations. Once a contract is in place between the IAOC/SSC and the candidate, the IAB will be notified and, following standard practice, the contract will be forwarded to the Internet Society for signature. The SSC and IAOC will support the IAB in drafting a public announcement. This will complete the RSE selection process. A.19. SSC DRAFT SCHEDULE The committee will announce a final schedule soon after they are appointed, starting with this draft schedule: o 5620bis and Job Description agreed by community (target date TBD) o Calls for SSC members (target date TBD) o Announcement of SSC members (target date TBD) o First SSC meeting (target date TBD) o Financials and legal terms agreed (target date TBD) o Final "Call for Candidates" text completed (target 9 November) o SSC Call for Candidates (target 11 November at Beijing IETF) o Close of Application Period (date TBD) [Ed., Holiday lag?] o Vetting of "short list" of < 10 candidates (target date TBD) o Determination of Best and Final List (target date TBD) o Announcement of new RSE (target date TBD) A.20. No Suitable Candidate The SSC has the option to make no selection if they conclude that no suitable candidate has been found. In this case, they will explain this in their report and describe possible remedies. It will then be up to the IAB to determine (1) how to provide for continuity of the Kowack Expires April 29, 2011 [Page 45] Internet-Draft RFC Editor Model (Version 2) October 2010 series for another fixed interim period, (2) what went wrong with the job description or the search and selection process, and (3) what sort of new process should be undertaken. Author's Address Glenn Kowack (editor) Riveronce Email: glenn@riveronce.com Kowack Expires April 29, 2011 [Page 46]