idnits 2.17.1 draft-iab-rfc-editor-model-v2-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5620]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes RFC5620, but the abstract doesn't seem to directly say this. It does mention RFC5620 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 9, 2012) is 4457 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4844 (Obsoleted by RFC 8729) ** Obsolete normative reference: RFC 4071 (Obsoleted by RFC 8711) -- Obsolete informational reference (is this intentional?): RFC 5620 (Obsoleted by RFC 6548, RFC 6635) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Kolkman (Ed.) 3 Internet-Draft 4 Obsoletes: 5620 (if approved) J. Halpern (Ed.) 5 Intended status: Informational Ericsson 6 Expires: August 12, 2012 IAB 7 February 9, 2012 9 RFC Editor Model (Version 2) 10 draft-iab-rfc-editor-model-v2-03 12 Abstract 14 The RFC Editor performs a number of functions that may be carried out 15 by various people or entities. The RFC Editor model described in 16 this document divides the responsibilities for the RFC Series into 17 three functions: The RFC Series Editor, the RFC Production Center, 18 and the RFC Publisher. The Internet Architecture Board (IAB) 19 oversight by way of delegation to the RFC Series Oversight Committee 20 (RSOC) is described, as is the relationship between the IETF 21 Administrative Oversight Committee (IAOC) and the RSOC. This 22 document reflects the experience gained with RFC Editor Model version 23 1, documented in [RFC5620] and obsoletes that document. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 12, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. RFC Editor Model . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. RFC Series Editor . . . . . . . . . . . . . . . . . . . . 6 62 2.1.1. Strategic Leadership and Management of the 63 Publication and Production Functions . . . . . . . . . 7 64 2.1.2. Representation of the RFC Series . . . . . . . . . . . 7 65 2.1.2.1. Representation to the IETF . . . . . . . . . . . . 7 66 2.1.2.2. External Representation . . . . . . . . . . . . . 8 67 2.1.3. Development of RFC Production and Publication . . . . 9 68 2.1.4. Development of the RFC Series . . . . . . . . . . . . 9 69 2.1.5. Workload . . . . . . . . . . . . . . . . . . . . . . . 10 70 2.1.6. Qualifications . . . . . . . . . . . . . . . . . . . . 10 71 2.1.7. Conflict of Interest . . . . . . . . . . . . . . . . . 11 72 2.2. RFC Production Center . . . . . . . . . . . . . . . . . . 11 73 2.3. RFC Publisher . . . . . . . . . . . . . . . . . . . . . . 12 74 3. Committees . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 3.1. RFC Series Oversight Committee (RSOC) . . . . . . . . . . 12 76 3.1.1. RSOC Composition . . . . . . . . . . . . . . . . . . . 14 77 4. Administrative Implementation . . . . . . . . . . . . . . . . 14 78 4.1. Vendor Selection for the Production and Publisher 79 Functions . . . . . . . . . . . . . . . . . . . . . . . . 15 80 4.2. Budget . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 4.3. Disagreements Among RFC Editor Related Entities . . . . . 17 82 4.4. Issues with Contractual Impact . . . . . . . . . . . . . . 18 83 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 84 6. Security considerations . . . . . . . . . . . . . . . . . . . 18 85 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 90 1. Introduction 92 The IAB, on behalf of the Internet technical community, is concerned 93 with ensuring the continuity of the RFC Series, orderly RFC Editor 94 succession, maintaining RFC quality, and RFC document accessibility. 95 The IAB is also sensitive to the concerns of the IETF Administrative 96 Oversight Committee (IAOC) about providing the necessary services in 97 a cost effective and efficient manner. 99 The RFC series is described in [RFC4844]. Its Section 3.1 defines 100 "RFC Editor": 102 Originally, there was a single person acting as editor of the RFC 103 Series (the RFC Editor). The task has grown, and the work now 104 requires the organized activity of several experts, so there are 105 RFC Editors, or an RFC Editor organization. In time, there may be 106 multiple organizations working together to undertake the work 107 required by the RFC Series. For simplicity's sake, and without 108 attempting to predict how the role might be subdivided among them, 109 this document refers to this collection of experts and 110 organizations as the "RFC Editor". 112 The RFC Editor is an expert technical editor and series editor, 113 acting to support the mission of the RFC Series. As such, the RFC 114 Editor is the implementer handling the editorial management of the 115 RFC Series, in accordance with the defined processes. In addition, 116 the RFC Editor is expected to be the expert and prime mover in 117 discussions about policies for editing, publishing, and archiving 118 RFCs. 120 RFC 4844 makes no attempt to explore the internal organization of the 121 RFC Editor. However, RFC 4844 envisions changes in the RFC Editor 122 organizational structure. There have been several iterations on 123 efforts to improve and clarify this structure. These have been led 124 by the IAB, in consultation with the community and many leadership 125 bodies within the community. This first resulted in the publication 126 of [RFC5620], and then in further discussions leading to this 127 document. In undertaking this evolution, the IAB considered changes 128 that increase flexibility and operational support options, provide 129 for the orderly succession of the RFC Editor, and ensure the 130 continuity of the RFC series, while maintaining RFC quality, 131 maintaining timely processing, ensuring document accessibility, 132 reducing costs, and increasing cost transparency. The model set 133 forth below describes the internal organization of the RFC Editor, 134 while remaining consistent with RFC 4844. 136 Note that RFC 4844 uses the term "RFC Editor function" or "RFC 137 Editor" as the collective set of responsibilities for which this memo 138 provides a model for internal organization. This memo defines the 139 term "RFC Series Editor" or "Series Editor" for one of the 140 organizational components. 142 The RFC Editor model was first approved in October 1, 2008 and 143 understanding thereof has evolved since. During the implementation 144 of version 1 of the model [RFC5620] it was quickly realized that the 145 role of the RSE and the oversight responsibilities needed to be 146 structured differently. In order to gain experience with 'running 147 code' a transitional RFC Series Editor was hired who analyzed the 148 managerial environment and provided recommendations. This version of 149 the model is based on his recommendations and the subsequent 150 extensive discussion in the IETF community, on the rfc-interest list 151 and within the IAB. A such, this document obsoletes [RFC5620]. 153 The document, and the resulting structures, will be modified as 154 needed through normal procedures. The RSE, and the IAB, through the 155 RFC oversight committee (see Section 3.1), will continue to monitor 156 discussions within the community about potential adjustments to the 157 RFC Editor model and recognizes that the process described in this 158 document may need to be adjusted to align with any changes that 159 result from such discussions, hence the version number in the title. 161 The IAB and IAOC maintain their chartered responsibility as defined 162 in [RFC2850] and [RFC4071]. 164 2. RFC Editor Model 166 The RFC Editor model divides the responsibilities for the RFC Series 167 into the following components: 169 o RFC Series Editor ("RSE"). 171 o RFC Production Center. 173 o RFC Publisher. 175 The structure and relationship of the components of the RFC Series 176 Production and Process is schematically represented by the figure 177 below. The picture does not depict oversight and escalation 178 relations. It does include the streams and their managers (which are 179 not part of the RFC Series Editor nor the production or publication 180 facilities) in order to more fully show the context in which the RFC 181 Series Editor operates. 183 +-------------+ 184 | | 185 +--------------+ IAB <------------+ 186 | | | | 187 | |=============| | 188 | | | | 189 | | RSOC <------------+ 190 | | | | 191 | +-------+-----+ +-----+-----+ 192 | | | | 193 | +...........|.........+ | Community | 194 | . | . | at | 195 | . +-------V-----+ . | Large | 196 | . | | . | | 197 | . | RFC | . +-----+-----+ 198 | . | Series | . | 199 | . | Editor <------------+ 200 | . | | . 201 | . +-+---------+-+ . 202 | . | | . 203 +-------------+ +-----V-------+ . +--V--+ +--V--+ . +-----+ 204 | | | | . | | | | . | | 205 | Independent | | Independent | . | RFC | | | . | E | 206 | Authors +--> Submission +-----> | | | . | n | 207 | | | Editor | . | P | | | . | d | 208 | | | | . | r | | RFC | . | | 209 +-------------+ +-------------+ . | o | | | . | U | 210 +-------------+ +-------------+ . | d | | P | . | s | 211 | | | | . | u | | u | . | e | 212 | IAB +--> IAB +-----> c | | b | . | r | 213 | | | | . | t | | l | . | s | 214 +-------------+ +-------------+ . | i +---> i +--------> | 215 +-------------+ +-------------+ . | o | | s | . | & | 216 | | | | . | n | | h | . | | 217 | IRTF +--> IRSG +---->| | | e | . | R | 218 | | | | . | C | | r | . | e | 219 +-------------+ +-------------+ . | e | | | . | a | 220 +-------------+ +-------------+ . | n | | | . | d | 221 | | | | . | t | | | . | e | 222 | IETF +--> IESG +-----> e | | | . | r | 223 | | | | . | r | | | . | s | 224 +-------------+ +-------------+ . +-----+ +-----+ . +-----+ 225 . . 226 +..... RFC Editor ....+ 228 Structure of RFC Series production and process. 230 Figure 1 232 In this model documents are produced and approved through multiple 233 document streams. The stream manager for each stream is responsible 234 for the content of that stream. The four streams that now exist are 235 described in [RFC4844]. The RFC Editor function is responsible for 236 the packaging and distribution of the documents. As such, documents 237 from these streams are edited and processed by the Production Center 238 and published by the Publisher. The RFC Series Editor will exercise 239 strategic leadership and management over the activities of the RFC 240 Publisher and the RFC Production Center (both of which can be seen as 241 back office functions) and will be the entity that: 243 o Represents the RFC Series and the RFC Editor Function within the 244 IETF and externally. 246 o Leads the community in the design of improvements to the RFC 247 Series. 249 o Is responsible for planning and seeing to the execution of 250 improvements in the RFC Editor Production and Access Processes. 252 o Is responsible for the content of the rfc-editor.org web site, 253 which is operated and maintained by the RFC Publisher. 255 o The RSE will develop consensus versions of vision and policy 256 documents. These documents will be reviewed by the RFC Series 257 Oversight Committee (Section 3.1 and subject to its approval 258 before final publication. 260 These responsibilities are defined below, although the specific work 261 items under them are a matter for the actual employment contract and 262 its Statement of Work. 264 The IAB and IAOC maintain their chartered responsibility as defined 265 in [RFC2850] and [RFC4071]. More details on the oversight by the IAB 266 via the RFC Series Oversight Committee (RSOC) can be found in 267 Section 3.1. For example, the RSE does not have the direct authority 268 to hire or fire RFC Editor contractors or personnel. 270 2.1. RFC Series Editor 272 The RFC Series Editor is the individual with overall responsibility 273 for the quality, continuity, and evolution of the RFC Series. 275 The RSE is appointed by the IAB, but formally hired by the IAOC. The 276 IAB delegates the direct oversight over the RSE to the RSOC, which it 277 appoints. 279 The RSE is expected to cooperate closely with the IAOC and the stream 280 managers. 282 2.1.1. Strategic Leadership and Management of the Publication and 283 Production Functions 285 With respect to the Publication and Production functions, the RSE 286 provides input to the IASA budget, statements of work, and manages 287 vendor selection processes. The RSE performs annual reviews of the 288 Production and Publication function which are then provided to the 289 RSOC the IASA, and the community. If the IAOC concludes that it is 290 necessary, private financial details may be elided from the public 291 version. 293 The RSE is responsible for the performance of the Production Center 294 and Publisher. The RSE is responsible for issues that go beyond the 295 production or publication functions, such as cross-stream 296 coordination of priorities. Issues that require changes to the 297 budget or contracts shall be brought to the attention of the IAD by 298 the RSE. 300 The RSE is also responsible for creating documentation and structures 301 that will allow for continuity of the RFC Series' in the face of 302 changes in contracts and personnel. 304 Vendor selection for the Production and Publisher functions is done 305 in cooperation with the streams and under final authority of the 306 IASA. Details on this process can be found in Section 4.1. 308 2.1.2. Representation of the RFC Series 310 The RSE is the primary representative of the RFC Series. This 311 representation is important both internally, relative to the IETF, 312 and externally. 314 2.1.2.1. Representation to the IETF 316 The RSE is the primary point of contact to the IETF on matters 317 relating to the RFC series in general, or policy matters relating to 318 specific documents. Issues of practical details in the processing of 319 specific documents are generally worked directly with the RFC 320 Production Center staff. 322 This includes providing suitable reports to the community at large; 323 providing email contact for policy questions and inputs; and enabling 324 and participating in suitable on-line forums for discussion of issues 325 related to the RFC Series. 327 Due to the history and nature of the interaction between the RSE and 328 the IETF, certain principles, described in the following subsections, 329 must be understood and adhered to by the RSE in his or her 330 interactions with the community. These apply to the representation 331 function, as well as to the leadership the RSE provides for 332 Production and Series Development. 334 2.1.2.1.1. Volunteerism 336 The vast majority of Internet technical community work is led, 337 initiated, and done by community volunteers, including oversight, 338 policy-making, and direct production of, for example, many software 339 tools. The Series Editor while not a volunteer is dependent upon 340 these volunteer participants. Also, the spirit of the community is 341 heavily focused on and draws from these volunteers. As such, the 342 Series Editor needs to support the vitality and effectiveness of 343 volunteer participation. 345 2.1.2.1.2. Policy Authority 347 All decisions are to be made in the overall interest of the broader 348 Internet community. The RSE is responsible for identifying 349 materially concerned interest groups within the Internet community 350 and reach out to them. Those interest groups include at least the 351 IETF community, the IRTF community, the network research community, 352 and the network operations community. Other interest groups might 353 also be materially interested. 355 The RSE must consult with the community on policy issues. The RSE 356 works with the community to achieve policy that meets the overall 357 quality, continuity, and evolution goals the RSE is charged with 358 meeting. As described below in Section 3.1 the RSE reports the 359 results of such interactions, to the RSOC, including a description of 360 the outreach efforts and the specific recommendations on policy. 361 This enables the RSOC to provide the oversight the IAB is required to 362 apply, as well as to confirm that the Internet community has been 363 properly consulted and considered in making policy. 365 2.1.2.2. External Representation 367 From time to time, individuals or organizations external to the IETF 368 need a contact person to talk to about the RFC Series. The RSE or 369 the RSE's designate serve this role. 371 Over time, the RSE should determine what if any means should be 372 employed to increase end-user awareness of the series, to reinforce 373 the stature of the Series, and will provide the contact point for 374 outside parties seeking information on the Series or the Editor. 376 2.1.3. Development of RFC Production and Publication 378 Closely related to providing strategic leadership and management to 379 the RFC Production and Publication functions is the need to develop 380 and improve those functions. The RSE is responsible for ensuring 381 that such ongoing development takes place. 383 This effort must include the dimensions of document quality, 384 timeliness of production, and accessibility of results. It must also 385 specifically take into account issues raised by the IETF community, 386 including all the RFC Streams. 388 2.1.4. Development of the RFC Series 390 In order to develop the RFC Publication series the RSE is expected to 391 develop a relationships with the Internet technical community. With 392 that community, the Editor is expected to engage in a process of 393 articulating and refining a vision for the Series and its continuous 394 evolution. The RSE is expected to also engage with other users of 395 the RFC series, in particular with the consumers of these documents 396 such as those people who use them to specify products, write code, 397 test behaviors, or other related activities. 399 Concretely: 401 The RSE is responsible for the coordination of discussion on 402 Series evolution among the Series' Stream participants and the 403 broader Internet technical community. 405 In time the RSE is expected to develop and refine a vision for the 406 RFC Series, including examining: 408 the technical specification series, as it continues to evolve. 409 The RSE is expected to take a broad view and be looking for the 410 best ways to evolve the series for the benefit of the entire 411 Internet Community. As such, the RSE may even consider 412 evolution beyond the historical 'by engineers for engineers' 413 emphasis; and 415 its publication-technical environment: looking at whether it 416 should be slowly changing in terms of publication and archiving 417 techniques; particularly to better serve the communities that 418 produce and depend on the RFC Series. For example, all of 419 those communities have been slowly changing to include 420 significant multi-lingual and non-native-English populations. 421 Another example is that some of these constituencies also have 422 a shifted to include significant groups of members whose 423 primary focus is on the constraints and consequences of network 424 engineering, rather than a primary interest in the engineering 425 issues themselves. 427 For this type of responsibility the RSE cooperates closely with the 428 community and under oversight of the RSOC and thus ultimately under 429 oversight of the IAB. 431 2.1.5. Workload 433 The job is expected initially to take on average half of an FTE 434 (approx 20 hrs per week), with the workload per week near full time 435 during IETF weeks, well over 20 hours per week in the first few 436 months of the engagement, and higher during special projects. 438 2.1.6. Qualifications 440 The RFC Series Editor is a senior technology professional. The 441 following qualifications are desired: 443 1. Strategic leadership and management experience fulfilling the 444 requirements outlined in this document, the many aspects of this 445 role, and the coordination of the overall RFC Editor process. 447 2. Good understanding of the English language and technical 448 terminology related to the Internet. 450 3. Good communication skills. 452 4. Experience with editorial processes. 454 5. Ability to develop strong understanding of the IETF and RFC 455 process. 457 6. Independent worker. 459 7. Willingness to, and availability for, Travel. 461 8. The ability to work effectively in a multi-actor and matrixed 462 environment with divided authority and responsibility similar to 463 that described in this document. 465 9. Experience with and ability to participate in, and manage 466 activities by email and teleconferences, not just face-to-face 467 interactions 469 10. Demonstrated experience in strategic planning and the management 470 of entire operations is desired. 472 11. Experience as an RFC author desired. 474 2.1.7. Conflict of Interest 476 The RSE is expected to avoid even the appearance of conflict of 477 interest or judgment in performing these roles. As such, the RSE is 478 barred from having any ownership, advisory, or other relationship to 479 the vendors executing the Publication or Production functions except 480 as specified elsewhere in this document. If necessary, an exception 481 can be made after public disclosure of those relationships and with 482 the explicit permission of the IAB and IAOC. 484 2.2. RFC Production Center 486 RFC Production is performed by a paid contractor, and the contractor 487 responsibilities include: 489 1. Editing inputs from all RFC streams to comply with the RFC Style 490 Manual, under the direction of the RSE; 492 2. Creating records of edits performed on documents; 494 3. Identifying where editorial changes might have technical impact 495 and seeking necessary clarification; 497 4. Engaging in dialog with authors, document shepherds, IANA, 498 and/or stream-dependent contacts when clarification is needed; 500 5. Creating records of dialog with document authors; 502 6. Requesting advice from the RFC Series Editor as needed; 504 7. Providing suggestions to the RFC Series Editor as needed; 506 8. Providing sufficient resources to support reviews of RFC 507 Publisher performance by the RFC Series Editor and external 508 reviews of the RFC Editor initiated by the IAB or IAOC; 510 9. Coordinating with IANA to perform protocol parameter registry 511 actions; 513 10. Assigning RFC numbers; 515 11. Establishing publication readiness of each document through 516 communication with the authors, document shepherds, IANA and/or 517 stream-dependent contacts, and, if needed, with the RFC Series 518 Editor; 520 12. Forwarding ready-to-publish documents to the RFC Publisher; 522 13. Forwarding records of edits and author dialog to the RFC 523 Publisher so these can be preserved; 525 14. Liaising with the streams as needed. 527 All these activities will be done under the general direction, but 528 not day to day management, of the RSE and need some level of 529 coordination with various submission streams and the RSE. 531 The RFC Production Center contractor is to be selected through an 532 IASA RFP process as described in Section 4.1. 534 2.3. RFC Publisher 536 The RFC Publisher responsibilities include: 538 1. Announcing and providing on-line access to RFCs. 540 2. Providing on-line system to submit RFC Errata. 542 3. Providing on-line access to approved RFC Errata. 544 4. Providing backups. 546 5. Providing storage and preservation of records. 548 6. Authenticating RFCs for legal proceedings. 550 All these activities will be done under the general direction, but 551 not day to day management, of the RSE and need some level of 552 coordination with various submission streams and the RSE. 554 The RFC Publisher contractor is to be selected through an IASA RFP 555 process as described in Section 4.1. 557 3. Committees 559 3.1. RFC Series Oversight Committee (RSOC) 561 The IAB is responsible for oversight over the RFC Series and acts as 562 a body for final conflict resolution, including the process described 563 in Section 4.3. 565 In order to provide continuity over periods longer than the nomcom 566 appointment cycle and assure that oversight includes suitable subject 567 matter expertise, the IAB will establish a group that implements 568 oversight for the IAB, the RFC Series Oversight Committee (RSOC). 570 The RSOC will act with authority delegated from the IAB: In general 571 it will be the RSOC that will approve consensus policy and vision 572 documents as developed by the RSE in collaboration with the 573 community. While it is expected that the IAB will exercise due 574 diligence in its supervision of the RSOC, the RSOC should be allowed 575 the latitude to do its job without undue interference from the IAB. 576 Therefore, it is expected that the IAB will accord RSOC reports and 577 recommendations the benefit of the doubt. 579 For all decisions that affect the RSE individually (e.g. hiring and 580 firing) the RSOC prepares recommendations for the IAB but final 581 decision is the responsibility of the IAB. For instance the RSOC 582 would: 584 o perform annual reviews of the RSE and report the result of these 585 reviews to the IAB. 587 o manage RSE candidate selection and advise the IAB on candidate 588 appointment (in other words select the RSE subject to IAB 589 approval) 591 RSOC members are expected to recognize potential conflicts of 592 interest and behave accordingly. 594 For the actual recruitment and selection of the RSE, RSOC will 595 propose a budget for the search process, and work with IASA to refine 596 that budget and develop remuneration criteria and an employment 597 agreement or contracting plans, as appropriate. 599 The RSOC will be responsible to ensure that the RFC Series is run in 600 a transparent and accountable manner. 602 The RSOC shall develop and publish its own rules of order. 604 The initial RSOC is charged with designing and executing a 605 solicitation, search, and selection process for the first actual 606 (non-transition or "acting") RSE appointment. That process will 607 inevitably involve iteration on this and related documents and 608 evaluation of various strategies and options. The RSOC is expected 609 to describe the process it ultimately selects to the community and to 610 involve the community in interim considerations when that is likely 611 to be of value. Upon completion of the selection process, the RSOC 612 will determine the best way to share information learned and 613 experience gained with the community and to determine how to best 614 preserve that information for future use. 616 3.1.1. RSOC Composition 618 The RSOC will operate under the authority of the IAB, with the IAB 619 retaining final responsibility. The IAB will delegate authority and 620 responsibility to the RSOC as appropriate and as RSOC and RSE 621 relationships evolve. The RSOC will include people who are not 622 current IAB members. Currently, this is aligned with the IAB Program 623 structure. The IAB will designate the membership of the RSOC with 624 the goals of preserving effective stability, keeping it small enough 625 to be effective, but large enough to provide general Internet 626 Community expertise, specific IETF expertise, Publication expertise, 627 and stream expertise. Members serve at the pleasure of the IAB and 628 are expected to bring a balance between short and long term 629 perspective. Specific input about, and recommendations of, members 630 will be sought from the streams, the IASA, and the RSE. 632 The IAOC will appoint an individual to serve as its Liaison to the 633 RSOC. The RSE and this Liaison will serve as non-voting ex-officio 634 members of the RSOC. Either or both can be excluded from its 635 discussions if necessary. 637 4. Administrative Implementation 639 The exact implementation of the administrative and contractual 640 activities described here are a responsibility of the IETF 641 Administrative Oversight Committee (IAOC, [RFC4071]) in cooperation 642 with the RFC Series Editor. The authority structure is described in 643 Figure 2 below. 645 +----------------+ +----------------+ 646 | | | | 647 | IAB | | IAOC | 648 | | | | 649 +==========+-----+ +-+-----------+--+ 650 | | . 651 | RSOC | . 652 | | . 653 +----+-----+ . 654 | . 655 | . 656 | ................... 657 | . . 658 +--------V---V----+ . 659 | | . 660 | RFC | . 661 | Series | . 662 | Editor | . 663 | | . 664 +--------+--------+ . 665 | . 666 | ................. 667 | . . 668 +--+----------------+ . 669 | . | . 670 | . | . 671 +---V-----V--+ +--V----V---+ 672 | RFC | | RFC | 673 | Production | | Publisher | 674 | Center | | | 675 +------------+ +-----------+ 677 Authority Structure of RFC Series 679 Legend: 681 ------- IAB RFC Series Oversight 682 ....... IAOC Contract/Budget Oversight 684 Figure 2 686 4.1. Vendor Selection for the Production and Publisher Functions 688 As stated earlier, vendor selection is done in cooperation with the 689 streams and under the final authority of the IAOC. 691 The RSE owns and develops the work definition (the SOW) and 692 participates in the IASA Vendor selection process. The work 693 definition is created within the IASA budget and takes into account 694 the stream managers and community input. 696 The process to select and contract for an RFC Production Center, RFC 697 Publisher, and other RFC-related services, is as follows: 699 o The IAOC establishes the contract process, including the steps 700 necessary to issue an RFP when necessary, the timing, and the 701 contracting procedures. 703 o The IAOC establishes the Selection Committee, which will consist 704 of the RSE, the IAD, and other members selected by the RSOC and 705 the IAOC. The Committee shall be chaired by the RSE. 707 o The Selection Committee selects the vendor, subject to the 708 successful negotiation of a contract approved by the IAOC. In the 709 event that a contract cannot be reached, the matter shall be 710 referred to the Selection Committee for further action. 712 o The Selection Committee may select an RFC Publisher either through 713 the IASA RFP process, or, at the Committee's option, the Committee 714 may select the IETF Secretariat to provide RFC Publisher services, 715 subject to negotiations in accordance with the IASA procedures. 717 4.2. Budget 719 The expenses discussed in this document are not new expenses. They 720 have been and remain part of the IETF Administrative Support Activity 721 (IASA, [RFC4071]) budget. 723 The RFC Series portion of the IASA Budget shall include entries for 724 the RSOC, RSE, RFC Production Center, and the RFC Publisher. The 725 IASA Budget shall also include entries for the streams, including the 726 independent stream. 728 The IAOC has the responsibility to approve the total RFC Editor 729 budget (and the authority to deny it.) The RSE must work within the 730 IAOC budgetary process. 732 The RSE is responsible for managing the RFC Editor to operate within 733 those budgets. If product needs change, the RSE is responsible for 734 working with the Production Center, and where appropriate, other RFC 735 Editor component institutions, relevant Streams, and/or the RSOC to 736 determine what the correct response should be. If they agree that a 737 budgetary change is needed, that needs to be taken to the IAD and the 738 IAOC. 740 4.3. Disagreements Among RFC Editor Related Entities 742 The RFC Series Editor, and the RFC Production and Publication 743 facilities, work with the various streams to produce RFCs. 744 Disagreements may arise during the execution of the RFC Editor 745 operations. In particular, different streams may disagree with each 746 other, or disagree with the RFC Editor function. Potentially, even 747 the RSOC or the IAOC could find themselves in disagreement with some 748 aspect of the RFC Editor operations. Note that disagreements between 749 an author and the production facility are not cross-entity issues, 750 and are to be resolved by the RSE, in accordance with the rest of 751 this document. 753 If such cross-entity disagreements arise, the community would 754 generally hope that they can be resolved politely and directly. 755 However, this is not always possible. At that point, any relevant 756 party would first formally request a review and reconsideration of 757 the decision. If the party still disagrees after the 758 reconsideration, that party may ask the RSE to decide or, especially 759 if the RSE is involved, the party may ask the IAB Chair (for a 760 technical or procedural matter) to mediate or appoint a mediator to 761 aid in the discussions, although he or she not is obligated to do so. 762 All parties should work informally and in good faith to reach a 763 mutually agreeable conclusion. As noted below, any such issues which 764 involve contractual matters must be brought to the addition of the 765 IAOC. If the IAB Chair is asked to assist in resolving the matter, 766 the Chair may ask for advice or seek assistance from anyone the Chair 767 deems helpful. The chair may also alert any appropriate individuals 768 or organizations to the existence of the issue. 770 If such a conclusion is not possible through those less formal 771 processes, then the matter must be registered with the RFC Series 772 Oversight Committee. The RSOC may choose to offer advice to the RSE 773 or more general advice to the parties involved and may ask the RSE to 774 defer a decision until it formulates its advice. However, if a 775 timely decision cannot be reached through discussion, mediation, and 776 mutual agreement, the Series Editor is expected to make whatever 777 decisions are needed to ensure the smooth functioning of the RFC 778 Editor function; those decisions are final. 780 The RSE may make final decisions unilaterally only to assure the 781 functioning of the process and evaluation of whether current policies 782 are appropriately implemented in the decision or need adjustment. In 783 particular, it should be noted that final decisions about the 784 technical content of individual documents are the exclusive 785 responsibility of the stream approvers for those documents, as shown 786 in the illustration in Figure 1. 788 If informal agreements cannot be reached, then formal RSOC review and 789 decision making may be required. If so, the the RSE must identify 790 the issues involved to the community, so that the community is aware 791 of the situation. The RSE will the report the issue to the RSOC for 792 formal resolution by the RSOC with confirmation by the IAB in its 793 oversight capacity. 795 IAB and community discussion of any patterns of disputes are expected 796 to inform future changes to Series policies including possible 797 updates to this document. 799 4.4. Issues with Contractual Impact 801 If a disagreement or decision has immediate or future contractual 802 consequences it falls under BCP 101 and IASA, and thus the Series 803 Editor must identify the issue and provide his or her advice to the 804 IAOC and, if the RSOC has provided advice, forward that advice as 805 well. The IAOC must notify the RSOC and IAB that this action is 806 being taken and then proceed to have it resolved according to its 807 applicable procedures subject to any special provisions in the 808 relevant contracts. 810 5. IANA considerations 812 This document defines several functions within the overall RFC Editor 813 structure, and it places the responsibility for coordination of 814 registry value assignments with the RFC Production Center. The IAOC 815 will facilitate the establishment of the relationship between the RFC 816 Production Center and IANA. 818 This document does not create a new registry nor does it register any 819 values in existing registries, and no IANA action is required. 821 6. Security considerations 823 The same security considerations as those in RFC 4844 apply. The 824 processes for the publication of documents must prevent the 825 introduction of unapproved changes. Since the RFC Editor maintains 826 the index of publications, sufficient security must be in place to 827 prevent these published documents from being changed by external 828 parties. The archive of RFC documents, any source documents needed 829 to recreate the RFC documents, and any associated original documents 830 (such as lists of errata, tools, and, for some early items, originals 831 that are not machine-readable) need to be secured against failure of 832 the storage medium and other similar disasters. 834 The IAOC should take these security considerations into account 835 during the implementation and enforcement of the RFC Editor model 836 contracts. 838 7. Acknowledgments 840 The RFC Editor model was conceived and discussed in hallways and on 841 mail lists. The first iteration of the text on which this document 842 is based was first drafted by Leslie Daigle, Russ Housley, and Ray 843 Pelletier. In addition to the members of the IAOC and IAB in 844 conjunction with those roles, major and minor contributions were made 845 by (in alphabetical order): Bob Braden, Brian Carpenter, Sandy 846 Ginoza, Alice Hagens, Joel M. Halpern, Alfred Hoenes, Paul Hoffman, 847 John Klensin, Subramanian Moonesamy, and Jim Schaad. 849 The IAOC members at the time this RFC Editor model was approved were 850 (in alphabetical order): Bernard Aboba, Eric Burger, Dave Crocker, 851 Marshall Eubanks, Bob Hinden, Russ Housley, Ole Jacobsen, Ray 852 Pelletier (non-voting), and Lynn St.Amour (ex officio). 854 The IAB members at the time the initial RFC Editor model was approved 855 were (in alphabetical order): Loa Andersson, Gonzalo Camarillo, 856 Stuart Cheshire, Russ Housley, Olaf Kolkman, Gregory Lebovitz, Barry 857 Leiba, Kurtis Lindqvist, Andrew Malis, Danny McPherson, David Oran, 858 Dave Thaler, and Lixia Zhang. In addition, the IAB included two ex- 859 officio members: Dow Street, who was serving as the IAB Executive 860 Director, and Aaron Falk, who was serving as the IRTF Chair. 862 The IAB members at the time the this RFC was approved were (in 863 alphabetical order): Bernard Aboba, Ross Callon, Alissa Cooper, 864 Spencer Dawkins, Joel Halpern, Russ Housley, David Kessens, Olaf 865 Kolkman, Danny McPherson, Jon Peterson, Andrei Robachevsky, Dave 866 Thaler, and Hannes Tschofenig. In addition, the IAB included at the 867 time of approval two ex-officio members: Mary Barnes who was serving 868 as the IAB Executive Director, and Lars Eggert, who was serving as 869 the IRTF Chair. 871 8. References 873 8.1. Normative References 875 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC 876 Series and RFC Editor", RFC 4844, July 2007. 878 [RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF 879 Administrative Support Activity (IASA)", BCP 101, 880 RFC 4071, April 2005. 882 [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of 883 the Internet Architecture Board (IAB)", BCP 39, RFC 2850, 884 May 2000. 886 8.2. Informative References 888 [RFC5620] Kolkman, O. and IAB, "RFC Editor Model (Version 1)", 889 RFC 5620, August 2009. 891 Authors' Addresses 893 Olaf M. Kolkman 895 EMail: olaf@nlnetlabs.nl 897 Joel M. Halpern 898 Ericsson 900 EMail: joel.halpern@ericsson.com 902 Internet Architecture Board 904 EMail: iab@iab.org