idnits 2.17.1 draft-ietf-iasa2-rfc6635bis-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 7, 2019) is 1936 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-iasa2-rfc4071bis-03 ** Obsolete normative reference: RFC 4844 (Obsoleted by RFC 8729) ** Obsolete normative reference: RFC 6635 (Obsoleted by RFC 8728) -- Obsolete informational reference (is this intentional?): RFC 3777 (Obsoleted by RFC 7437) -- Obsolete informational reference (is this intentional?): RFC 5620 (Obsoleted by RFC 6548, RFC 6635) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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: 6635 (if approved) J. Halpern, Ed. 5 Intended status: Informational Ericsson 6 Expires: July 11, 2019 R. Hinden, Ed. 7 Check Point Software 8 January 7, 2019 10 RFC Editor Model (Version 2) 11 draft-ietf-iasa2-rfc6635bis-03 13 Abstract 15 The RFC Editor model described in this document divides the 16 responsibilities for the RFC Series into three functions: the RFC 17 Series Editor, the RFC Production Center, and the RFC Publisher. 18 Internet Architecture Board (IAB) oversight via the RFC Series 19 Oversight Committee (RSOC) is described, as is the relationship 20 between the IETF Administration Limited Liability Company and the 21 RSOC. This document reflects the experience gained with "RFC Editor 22 Model (Version 1)", documented in RFC 5620; and obsoletes RFC 6635 to 23 replace all references to the IASA and related structures with those 24 defined by the IASA 2.0 Model. 26 [RFC Editor: Please remove the following paragraph prior to 27 publication.] 29 The IASA2 WG requests that the IAB publish this replacement for RFC 30 6635. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on July 11, 2019. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. The RFC Editor Function . . . . . . . . . . . . . . . . . 4 68 2. RFC Editor Model . . . . . . . . . . . . . . . . . . . . . . 5 69 2.1. RFC Series Editor . . . . . . . . . . . . . . . . . . . . 7 70 2.1.1. Strategic Leadership and Management of the 71 Publication and Production Functions . . . . . . . . 8 72 2.1.2. Representation of the RFC Series . . . . . . . . . . 8 73 2.1.2.1. Representation to the IETF . . . . . . . . . . . 8 74 2.1.2.2. External Representation . . . . . . . . . . . . . 9 75 2.1.3. Development of RFC Production and Publication . . . . 10 76 2.1.4. Development of the RFC Series . . . . . . . . . . . . 10 77 2.1.5. Workload . . . . . . . . . . . . . . . . . . . . . . 11 78 2.1.6. Qualifications . . . . . . . . . . . . . . . . . . . 11 79 2.1.7. Conflict of Interest . . . . . . . . . . . . . . . . 12 80 2.2. RFC Production Center . . . . . . . . . . . . . . . . . . 12 81 2.3. RFC Publisher . . . . . . . . . . . . . . . . . . . . . . 13 82 3. Committees . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 3.1. RFC Series Oversight Committee (RSOC) . . . . . . . . . . 13 84 3.1.1. RSOC Composition . . . . . . . . . . . . . . . . . . 15 85 4. Administrative Implementation . . . . . . . . . . . . . . . . 15 86 4.1. Vendor Selection for the Production and Publisher 87 Functions . . . . . . . . . . . . . . . . . . . . . . . . 16 88 4.2. Budget . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 4.3. Disagreements among Entities Related to the RFC Editor . 18 90 4.4. Issues with Contractual Impact . . . . . . . . . . . . . 19 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 93 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 94 8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 20 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 96 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 97 9.2. Informative References . . . . . . . . . . . . . . . . . 22 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 100 1. Introduction 102 This document reflects the experience gained with "RFC Editor Model 103 (Version 1)", documented in [RFC5620], and updates the RFC Editor 104 Model (Version 2) to be aligned with the new IASA 2.0 Model 105 [I-D.ietf-iasa2-rfc4071bis] that creates a IETF Administration 106 Limited Liability Company ("LLC") managed by a board of directors 107 ("LLC Board"). As part of the IASA 2.0 Model the Internet 108 Administrative Oversight Committee (IAOC) is eliminated, and its 109 oversight and advising functions transferred to the new LLC. This 110 document obsoletes [RFC6635] to replace all references to the IASA 111 and related structures with those defined by the IASA 2.0 Model. 113 The IAB, on behalf of the Internet technical community, is concerned 114 with ensuring the continuity of the RFC Series, orderly RFC Editor 115 succession, RFC quality, and RFC document accessibility. The IAB is 116 also sensitive to the concerns of the LLC about providing the 117 necessary services in a cost-effective and efficient manner. 119 The contemporary RFC Editor model [RFC5620] was first approved in 120 October 2008, and our understanding of the model has evolved with our 121 experience since. During the implementation of version 1 of the 122 model [RFC5620], it was quickly realized that the role of the RFC 123 Series Editor (RSE) and the oversight responsibilities needed to be 124 structured differently. In order to gain experience with "running 125 code", a transitional RSE was hired who analyzed the managerial 126 environment and provided recommendations. This was followed by the 127 appointment of an acting RSE, who ably managed the series while work 128 was undertaken to select and hire a permanent RSE. This version of 129 the model is based on the recommendations of both temporary RFC 130 Series Editors and the extensive discussion in the IETF community, on 131 the rfc-interest list, and within the IAB. 133 This document, and the resulting structures, will be modified as 134 needed through normal procedures. The RSE, and the IAB, through the 135 RFC Oversight Committee (see Section 3.1), will continue to monitor 136 discussions within the community about potential adjustments to the 137 RFC Editor model and recognize that the process described in this 138 document may need to be adjusted to align with any changes that 139 result from such discussions; hence, the version number in the title. 141 The IAB maintains it's responsibilities as defined in [RFC2850]. 143 1.1. The RFC Editor Function 145 The RFC Series is described in [RFC4844]. Its Section 3.1 defines 146 "RFC Editor": 148 Originally, there was a single person acting as editor of the RFC 149 Series (the RFC Editor). The task has grown, and the work now 150 requires the organized activity of several experts, so there are 151 RFC Editors, or an RFC Editor organization. In time, there may be 152 multiple organizations working together to undertake the work 153 required by the RFC Series. For simplicity's sake, and without 154 attempting to predict how the role might be subdivided among them, 155 this document refers to this collection of experts and 156 organizations as the "RFC Editor". 158 The RFC Editor is an expert technical editor and series editor, 159 acting to support the mission of the RFC Series. As such, the RFC 160 Editor is the implementer handling the editorial management of the 161 RFC Series, in accordance with the defined processes. In 162 addition, the RFC Editor is expected to be the expert and prime 163 mover in discussions about policies for editing, publishing, and 164 archiving RFCs. 166 RFC 4844 does not explore the internal organization of the RFC 167 Editor. However, RFC 4844 envisions changes in the RFC Editor 168 organizational structure. There have been several iterations on 169 efforts to improve and clarify this structure. These have been led 170 by the IAB, in consultation with the community and many leadership 171 bodies within the community. This first resulted in the publication 172 of [RFC5620] and then in further discussions leading to this 173 document. Some of the details on this evolution can be found below. 174 In undertaking this evolution, the IAB considered changes that 175 increase flexibility and operational support options, provide for the 176 orderly succession of the RFC Editor, and ensure the continuity of 177 the RFC Series, while maintaining RFC quality, maintaining timely 178 processing, ensuring document accessibility, reducing costs, and 179 increasing cost transparency. The model set forth below describes 180 the internal organization of the RFC Editor, while remaining 181 consistent with RFC 4844. 183 Note that RFC 4844 uses the term "RFC Editor function" or "RFC 184 Editor" as the collective set of responsibilities for which this memo 185 provides a model for internal organization. This memo defines the 186 term "RFC Series Editor" or "Series Editor" for one of the 187 organizational components. 189 2. RFC Editor Model 191 The RFC Editor model divides the responsibilities for the RFC Series 192 into the following components: 194 o RFC Series Editor (RSE) 196 o RFC Production Center 198 o RFC Publisher 200 The structure and relationship of the components of the RFC Series 201 production and process is schematically represented by the figure 202 below. The picture does not depict oversight and escalation 203 relations. It does include the streams and their managers (which are 204 not part of the RFC Series Editor, the RFC Production Center, or 205 Publisher facilities) in order to more fully show the context in 206 which the RFC Series Editor operates. 208 +-------------+ 209 | | 210 +--------------+ IAB <------------+ 211 | | | | 212 | |=============| | 213 | | | | 214 | | RSOC <------------+ 215 | | | | 216 | +-------+-----+ +-----+-----+ 217 | | | | 218 | +...........|.........+ | Community | 219 | . | . | at | 220 | . +-------V-----+ . | Large | 221 | . | | . | | 222 | . | RFC | . +-----+-----+ 223 | . | Series | . | 224 | . | Editor <------------+ 225 | . | | . 226 | . +-+---------+-+ . 227 | . | | . 228 +-------------+ +-----V-------+ . +--V--+ +--V--+ . +-----+ 229 | | | | . | | | | . | | 230 | Independent | | Independent | . | RFC | | | . | E | 231 | Authors +--> Submission +-----> | | | . | n | 232 | | | Editor | . | P | | | . | d | 233 | | | | . | r | | RFC | . | | 234 +-------------+ +-------------+ . | o | | | . | U | 235 +-------------+ +-------------+ . | d | | P | . | s | 236 | | | | . | u | | u | . | e | 237 | IAB +--> IAB +-----> c | | b | . | r | 238 | | | | . | t | | l | . | s | 239 +-------------+ +-------------+ . | i +---> i +--------> | 240 +-------------+ +-------------+ . | o | | s | . | & | 241 | | | | . | n | | h | . | | 242 | IRTF +--> IRSG +---->| | | e | . | R | 243 | | | | . | C | | r | . | e | 244 +-------------+ +-------------+ . | e | | | . | a | 245 +-------------+ +-------------+ . | n | | | . | d | 246 | | | | . | t | | | . | e | 247 | IETF +--> IESG +-----> e | | | . | r | 248 | | | | . | r | | | . | s | 249 +-------------+ +-------------+ . +-----+ +-----+ . +-----+ 250 . . 251 +..... RFC Editor ....+ 253 Structure of RFC Series Production and Process 255 Figure 1 257 In this model, documents are produced and approved through multiple 258 document streams. The stream manager for each stream is responsible 259 for the content of that stream. The four streams that now exist are 260 described in [RFC4844]. The RFC Editor function is responsible for 261 the packaging and distribution of the documents. As such, documents 262 from these streams are edited and processed by the Production Center 263 and published by the Publisher. The RFC Series Editor will exercise 264 strategic leadership and management over the activities of the RFC 265 Publisher and the RFC Production Center (both of which can be seen as 266 back-office functions) and will be the entity that: 268 o Represents the RFC Series and the RFC Editor Function within the 269 IETF and externally. 271 o Leads the community in the design of improvements to the RFC 272 Series. 274 o Is responsible for planning and seeing to the execution of 275 improvements in the RFC Editor production and access processes. 277 o Is responsible for the content of the rfc-editor.org web site, 278 which is operated and maintained by the RFC Publisher. 280 o Is responsible for developing consensus versions of vision and 281 policy documents. These documents will be reviewed by the RFC 282 Series Oversight Committee (Section 3.1) and subject to its 283 approval before final publication. 285 These responsibilities are defined below, although the specific work 286 items under them are a matter for the actual employment contract and 287 its Statement of Work (SOW). 289 The IAB maintain it's chartered responsibility as defined in 290 [RFC2850]. More details on the oversight by the IAB via the RFC 291 Series Oversight Committee (RSOC) can be found in Section 3.1. For 292 example, the RSE does not have the direct authority to hire or fire 293 RFC Editor contractors or personnel. 295 2.1. RFC Series Editor 297 The RFC Series Editor is the individual with overall responsibility 298 for the quality, continuity, and evolution of the RFC Series. 300 The RSE is appointed by the IAB, but formally hired by the LLC. The 301 IAB delegates the direct oversight over the RSE to the RSOC, which it 302 appoints. 304 The RSE is expected to cooperate closely with the LLC and the stream 305 managers. 307 2.1.1. Strategic Leadership and Management of the Publication and 308 Production Functions 310 With respect to the RFC Publisher and Production Center functions, 311 the RSE provides input to the LLC budget, SOWs, and manages vendor 312 selection processes. The RSE performs annual reviews of the RFC 313 Production Center and Publisher function, which are then provided to 314 the RSOC, the LLC, and the community. Normally, private financial 315 details would not be included in a public version unless the LLC 316 concludes it is necessary to make such information public. 318 The RSE is responsible for the performance of the RFC Production 319 Center and Publisher. The RSE is responsible for issues that go 320 beyond the RFC Production Center or Publisher functions, such as 321 cross-stream coordination of priorities. Issues that require changes 322 to the budget or contracts shall be brought to the attention of the 323 LLC by the RSE. 325 The RSE is also responsible for creating documentation and structures 326 that will allow for continuity of the RFC Series in the face of 327 changes in contracts and personnel. 329 Vendor selection for the RFC Production Center and Publisher 330 functions is done in cooperation with the streams and under final 331 authority of the LLC. Details on this process can be found in 332 Section 4.1. 334 2.1.2. Representation of the RFC Series 336 The RSE is the primary representative of the RFC Series. This 337 representation is important both internally, relative to the IETF, 338 and externally. 340 2.1.2.1. Representation to the IETF 342 The RSE is the primary point of contact to the IETF on matters 343 relating to the RFC Series in general, or policy matters relating to 344 specific documents. Issues of practical details in the processing of 345 specific documents are generally worked through directly with the RFC 346 Production Center staff. 348 This includes providing suitable reports to the community at large, 349 providing email contact for policy questions and inputs, and enabling 350 and participating in suitable on-line forums for discussion of issues 351 related to the RFC Series. 353 Due to the history and nature of the interaction between the RSE and 354 the IETF, certain principles, described in the following subsections, 355 must be understood and adhered to by the RSE in his or her 356 interactions with the community. These apply to the representation 357 function, as well as to the leadership the RSE provides for 358 production and series development. 360 2.1.2.1.1. Volunteerism 362 The vast majority of Internet technical community work is led, 363 initiated, and done by community volunteers, including oversight, 364 policy making, and direct production of, for example, many software 365 tools. The RSE, while not a volunteer, is dependent upon these 366 volunteer participants. Also, the spirit of the community is heavily 367 focused on and draws from these volunteers. As such, the RSE needs 368 to support the vitality and effectiveness of volunteer participation. 370 2.1.2.1.2. Policy Authority 372 All decisions are to be made in the overall interest of the broader 373 Internet community. The RSE is responsible for identifying 374 materially concerned interest groups within the Internet community 375 and reaching out to them. Those interest groups include at least the 376 IETF community, the IRTF community, the network research community, 377 and the network operations community. Other interest groups might 378 also be materially interested. 380 The RSE must consult with the community on policy issues. The RSE 381 works with the community to achieve policy that meets the overall 382 quality, continuity, and evolution goals the RSE is charged with 383 meeting. As described in Section 3.1, the RSE reports the results of 384 such interactions to the RSOC, including a description of the 385 outreach efforts and the specific recommendations on policy. This 386 enables the RSOC to provide the oversight the IAB is required to 387 apply, as well as to confirm that the Internet community has been 388 properly consulted and considered in making policy. 390 2.1.2.2. External Representation 392 From time to time, individuals or organizations external to the IETF 393 need a contact person to talk to about the RFC Series. The RSE, or 394 the RSE's designate, serves this role. 396 Over time, the RSE should determine what, if any, means should be 397 employed to increase end-user awareness of the series, to reinforce 398 the stature of the series, and to provide the contact point for 399 outside parties seeking information on the series or the Editor. 401 2.1.3. Development of RFC Production and Publication 403 Closely related to providing strategic leadership and management to 404 the RFC Production Center and Publisher functions is the need to 405 develop and improve those functions. The RSE is responsible for 406 ensuring that such ongoing development takes place. 408 This effort must include the dimensions of document quality, 409 timeliness of production, and accessibility of results. It must also 410 specifically take into account issues raised by the IETF community, 411 including all the streams feeding into the RFC Editor function. 413 2.1.4. Development of the RFC Series 415 In order to develop the RFC Series, the RSE is expected to develop a 416 relationship with the Internet technical community. The Editor is 417 expected to engage with the Internet technical community in a process 418 of articulating and refining a vision for the series and its 419 continuous evolution. The RSE is also expected to engage other users 420 of the RFC Series, in particular, the consumers of these documents, 421 such as those people who use them to specify products, write code, 422 test behaviors, or other related activities. 424 Concretely: 426 The RSE is responsible for the coordination of discussion on 427 series evolution among the series' stream participants and the 428 broader Internet technical community. 430 In time, the RSE is expected to develop and refine a vision for 431 the RFC Series, including examining: 433 * The RFC Series, as it continues to evolve. The RSE is expected 434 to take a broad view and look for the best ways to evolve the 435 series for the benefit of the entire Internet community. As 436 such, the RSE may even consider evolution beyond the historical 437 'by engineers for engineers' emphasis; and 439 * Its publication-technical environment, by looking at whether it 440 should be slowly changing in terms of publishing and archiving 441 techniques -- particularly to better serve the communities that 442 produce and depend on the RFC Series. For example, all of 443 those communities have been slowly changing to include a 444 significant population of multi-lingual individuals or non- 445 native speakers of English. Another example is that some of 446 these constituencies also have shifted to include significant 447 groups whose primary focus is on the constraints and 448 consequences of network engineering, rather than a primary 449 interest in the engineering issues themselves. 451 For this type of responsibility, the RSE cooperates closely with the 452 community, and operates under oversight of the RSOC: thus, 453 ultimately, under oversight of the IAB. 455 2.1.5. Workload 457 On average, the job is expected to take half of a full-time 458 equivalent position (FTE, thus approx 20 hrs per week), with the 459 workload per week nearing full time during IETF weeks. In addition, 460 the job is expected to take more than 20 hours per week in the first 461 few months of the engagement and when involved in special projects. 463 2.1.6. Qualifications 465 The RFC Series Editor is a senior technology professional. The 466 following qualifications are desired: 468 1. Strategic leadership and management experience fulfilling the 469 requirements outlined in this document, the many aspects of this 470 role, and the coordination of the overall RFC Editor process. 472 2. Good understanding of the English language and technical 473 terminology related to the Internet. 475 3. Good communication skills. 477 4. Experience with editorial processes. 479 5. Ability to develop strong understanding of the IETF and RFC 480 process. 482 6. Independent worker. 484 7. Willingness to, and availability for, travel. 486 8. The ability to work effectively in a multi-actor and matrixed 487 environment with divided authority and responsibility similar to 488 that described in this document. 490 9. Experience with and ability to participate in, and manage, 491 activities by email and teleconferences, not just face-to-face 492 interactions. 494 10. Demonstrated experience in strategic planning and the management 495 of entire operations. 497 11. Experience as an RFC author. 499 2.1.7. Conflict of Interest 501 The RSE is expected to avoid even the appearance of conflict of 502 interest or judgment in performing these roles. As such, the RSE is 503 barred from having any ownership, advisory, or other relationship to 504 the vendors executing the RFC Publisher or Production Center 505 functions except as specified elsewhere in this document. If 506 necessary, an exception can be made after public disclosure of those 507 relationships and with the explicit permission of the IAB and LLC. 509 2.2. RFC Production Center 511 The RFC Production Center function is performed by a paid contractor, 512 and the contractor's responsibilities include the following: 514 1. Editing inputs from all RFC streams to comply with the RFC Style 515 Manual, under the direction of the RSE; 517 2. Creating records of edits performed on documents; 519 3. Identifying where editorial changes might have technical impact 520 and seeking necessary clarification; 522 4. Engaging in dialog with authors, document shepherds, IANA, and/ 523 or stream-dependent contacts when clarification is needed; 525 5. Creating records of dialog with document authors; 527 6. Requesting advice from the RFC Series Editor as needed; 529 7. Providing suggestions to the RFC Series Editor as needed; 531 8. Providing sufficient resources to support reviews of RFC 532 Publisher performance by the RFC Series Editor and external 533 reviews of the RFC Editor function initiated by the IAB or LLC; 535 9. Coordinating with IANA to ensure correct documentation of IANA- 536 performed protocol registry actions; 538 10. Assigning RFC numbers; 540 11. Establishing publication readiness of each document through 541 communication with the authors, document shepherds, IANA, and/or 542 stream-dependent contacts, and, if needed, with the RFC Series 543 Editor; 545 12. Forwarding documents that are ready for publication to the RFC 546 Publisher; 548 13. Forwarding records of edits and author dialog to the RFC 549 Publisher so these can be preserved; 551 14. Liaising with the streams as needed. 553 All these activities will be done under the general direction, but 554 not day-to-day management, of the RSE and need some level of 555 coordination with various submission streams and the RSE. 557 The RFC Production Center contractor is to be selected through an LLC 558 Request for Proposal (RFP) process as described in Section 4.1. 560 2.3. RFC Publisher 562 The RFC Publisher responsibilities include the following: 564 1. Announcing and providing on-line access to RFCs. 566 2. Providing an on-line system to submit RFC Errata. 568 3. Providing on-line access to approved RFC Errata. 570 4. Providing backups. 572 5. Providing storage and preservation of records. 574 6. Authenticating RFCs for legal proceedings. 576 All these activities will be done under the general direction, but 577 not day-to-day management, of the RSE and need some level of 578 coordination with various submission streams and the RSE. 580 The RFC Publisher contractor is to be selected through an LLC RFP 581 process as described in Section 4.1. 583 3. Committees 585 3.1. RFC Series Oversight Committee (RSOC) 587 The IAB is responsible for the oversight of the RFC Series and acts 588 as a body for final conflict resolution, including the process 589 described in Section 4.3. 591 In order to provide continuity over periods longer than the NomCom 592 appointment cycle [RFC3777] and assure that oversight includes 593 suitable subject matter expertise, the IAB will establish a group 594 that implements oversight for the IAB, the RFC Series Oversight 595 Committee (RSOC). 597 The RSOC will act with authority delegated from the IAB: in general, 598 it will be the RSOC that will approve consensus policy and vision 599 documents as developed by the RSE in collaboration with the 600 community. While it is expected that the IAB will exercise due 601 diligence in its supervision of the RSOC, the RSOC should be allowed 602 the latitude to do its job without undue interference from the IAB. 603 Therefore, it is expected that the IAB will accord RSOC reports and 604 recommendations the benefit of the doubt. 606 For all decisions that affect the RSE individually (e.g., hiring and 607 firing), the RSOC prepares recommendations for the IAB, but the final 608 decision is the responsibility of the IAB. For instance the RSOC 609 would do the following: 611 o perform annual reviews of the RSE and report the result of these 612 reviews to the IAB. 614 o manage RSE candidate selection and advise the IAB on candidate 615 appointment (in other words, select the RSE subject to IAB 616 approval). 618 RSOC members are expected to recognize potential conflicts of 619 interest and behave accordingly. 621 For the actual recruitment and selection of the RSE, the RSOC will 622 propose a budget for the search process. It will work with the LLC 623 to refine that budget and develop remuneration criteria and an 624 employment agreement or contracting plans, as appropriate. 626 The RSOC will be responsible for ensuring that the RFC Series is run 627 in a transparent and accountable manner. 629 The RSOC shall develop and publish its own rules of order. 631 The initial RSOC was charged with designing and executing a 632 solicitation, search, and selection process for the first actual (not 633 transitional or "acting") RSE appointment. That process involved 634 iteration on this and related documents and evaluation of various 635 strategies and options. During the creation of this document, it was 636 expected that the RSOC would describe the process it ultimately 637 selected to the community. The RSOC did involve the community in 638 interim considerations when that was likely to be of value. 639 Following completion of the selection process, the RSOC will 640 determine the best way to share information learned and experience 641 gained with the community and determine how to best preserve that 642 information for future use. 644 3.1.1. RSOC Composition 646 The RSOC will operate under the authority of the IAB, with the IAB 647 retaining final responsibility. The IAB will delegate authority and 648 responsibility to the RSOC as appropriate and as RSOC and RSE 649 relationships evolve. The RSOC will include people who are not 650 current IAB members. Currently, this is aligned with the IAB program 651 structure. The IAB will designate the membership of the RSOC with 652 the following goals: preserving effective stability; keeping it small 653 enough to be effective, and keeping it large enough to provide 654 general Internet community expertise, specific IETF expertise, 655 publication expertise, and stream expertise. Members serve at the 656 pleasure of the IAB and are expected to bring a balance between 657 short- and long-term perspectives. Specific input about, and 658 recommendations of, members will be sought from the streams, the LLC, 659 and the RSE. 661 In addition to the members from outside of the IAB appointed to the 662 RSOC, IAB members may participate as full members of the RSOC. Under 663 most circumstances, there will be a specific individual IAB member 664 appointed by the IAB as the program lead, who will be a full member 665 of the RSOC. This member's role is distinct from any RSOC-internal 666 organizational roles, such as would be created by the RSOC choosing 667 to appoint a chair from among its members. Other IAB members may 668 choose to be full members of the RSOC, with the consent of the IAB. 669 This consent is primarily concerned with avoiding overpopulating the 670 RSOC and providing it with relatively stable membership, which will 671 work best if it is not too large a committee. 673 The LLC will appoint an individual to serve as its liaison to the 674 RSOC. The RSE and the LLC Liaison will serve as non-voting ex 675 officio members of the RSOC. Either or both can be excluded from its 676 discussions if necessary. 678 4. Administrative Implementation 680 The exact implementation of the administrative and contractual 681 activities described here are a responsibility of the IETF 682 Administration Limited Liability Company [I-D.ietf-iasa2-rfc4071bis] 683 in cooperation with the RFC Series Editor. The authority structure 684 is described in Figure 2 below. 686 +----------------+ +----------------+ 687 | | | | 688 | IAB | | LLC | 689 | | | | 690 +==========+-----+ +-+--------------+ 691 | | . 692 | RSOC | . 693 | | . 694 +----+-----+ . 695 | . 696 | . 697 | ................... 698 | . . 699 +--------V---V----+ . 700 | | . 701 | RFC | . 702 | Series | . 703 | Editor | . 704 | | . 705 +--------+--------+ . 706 | . 707 | ................. 708 | . . 709 +--+----------------+ . 710 | . | . 711 | . | . 712 +---V-----V--+ +--V----V---+ 713 | RFC | | RFC | 714 | Production | | Publisher | 715 | Center | | | 716 +------------+ +-----------+ 718 Authority Structure of the RFC Series 720 Legend: 722 ------- IAB RFC Series Oversight 723 ....... LLC Contract/Budget Oversight 725 Figure 2 727 4.1. Vendor Selection for the Production and Publisher Functions 729 As stated earlier, vendor selection is done in cooperation with the 730 streams and under the final authority of the LLC. 732 The RSE owns and develops the work definition (the SOW) and 733 participates in the LLC vendor selection process. The work 734 definition is created within the LLC budget and takes into account 735 the stream managers and community input. 737 The process to select and contract for an RFC Production Center, RFC 738 Publisher, and other RFC-related services, is as follows: 740 o The LLC establishes the contract process, including the steps 741 necessary to issue an RFP when necessary, the timing, and the 742 contracting procedures. 744 o The LLC establishes the Selection Committee, which will consist of 745 the RSE, the LLC Executive Director, and other members selected by 746 the RSOC and the LLC. The Committee shall be chaired by the RSE. 748 o The Selection Committee selects the vendor, subject to the 749 successful negotiation of a contract approved by the LLC. In the 750 event that a contract cannot be reached, the matter shall be 751 referred to the Selection Committee for further action. 753 o The Selection Committee may select an RFC Publisher either through 754 the LLC RFP process or, at the Committee's option, the Committee 755 may select the IETF Secretariat to provide RFC Publisher services, 756 subject to negotiations in accordance with the LLC procedures. 758 4.2. Budget 760 The expenses discussed in this document are not new expenses. They 761 have been and remain part of the IETF Administration Limited 762 Liability Company [I-D.ietf-iasa2-rfc4071bis] budget. 764 The RFC Series portion of the LLC budget shall include entries for 765 the RSOC, RSE, RFC Production Center, and the RFC Publisher. The LLC 766 budget shall also include entries for the streams, including the 767 independent stream. 769 The LLC has the responsibility to approve the total RFC Editor budget 770 (and the authority to deny it). The RSE must work within the LLC 771 budgetary process. 773 The RSE is responsible for managing the RFC Editor function to 774 operate within those budgets. If production needs change, the RSE is 775 responsible for working with the Production Center, and where 776 appropriate, other RFC Editor component institutions, relevant 777 streams, and/or the RSOC to determine what the correct response 778 should be. If they agree that a budgetary change is needed, that 779 decision needs to be taken to the LLC. 781 4.3. Disagreements among Entities Related to the RFC Editor 783 The RFC Series Editor and the RFC Production Center and Publisher 784 facilities work with the various streams to produce RFCs. 785 Disagreements may arise between these entities during the execution 786 of the RFC Editor operations. In particular, different streams may 787 disagree with each other, or disagree with the RFC Editor function. 788 Potentially, even the RSOC or the LLC could find themselves in 789 disagreement with some aspect of the RFC Editor operations. Note 790 that disagreements between an author and the RFC Production Center 791 are not cross-entity issues, and they are to be resolved by the RSE, 792 in accordance with the rest of this document. 794 If such cross-entity disagreements arise, the community would 795 generally hope that they can be resolved politely and directly. 796 However, this is not always possible. At that point, any relevant 797 party would first formally request a review and reconsideration of 798 the decision. If the party still disagrees after the 799 reconsideration, that party may ask the RSE to decide or, especially 800 if the RSE is involved, the party may ask the IAB Chair (for a 801 technical or procedural matter) to mediate or appoint a mediator to 802 aid in the discussions, although he or she not is obligated to do so. 803 All parties should work informally and in good faith to reach a 804 mutually agreeable conclusion. As noted below, any such issues that 805 involve contractual matters must be brought to the attention of the 806 LLC. If the IAB Chair is asked to assist in resolving the matter, 807 the Chair may ask for advice or seek assistance from anyone the Chair 808 deems helpful. The Chair may also alert any appropriate individuals 809 or organizations to the existence of the issue. 811 If such a conclusion is not possible through the above less formal 812 processes, then the matter must be registered with the RFC Series 813 Oversight Committee. The RSOC may choose to offer advice to the RSE 814 or more general advice to the parties involved and may ask the RSE to 815 defer a decision until it formulates its advice. However, if a 816 timely decision cannot be reached through discussion, mediation, and 817 mutual agreement, the RSE is expected to make whatever decisions are 818 needed to ensure the smooth operation of the RFC Editor function; 819 those decisions are final. 821 The RSE may make final decisions unilaterally only to assure the 822 functioning of the process, and only while there is an evaluation of 823 current policies to determine whether they are appropriately 824 implemented in the decision or need adjustment. In particular, it 825 should be noted that final decisions about the technical content of 826 individual documents are the exclusive responsibility of the stream 827 approvers from which those documents originate, as shown in the 828 illustration in Figure 1. 830 If informal agreements cannot be reached, then formal RSOC review and 831 decision making may be required. If so, the RSE must present the 832 issues involved to the community so that the community is aware of 833 the situation. The RSE will then report the issue to the RSOC for 834 formal resolution by the RSOC with confirmation by the IAB in its 835 oversight capacity. 837 IAB and community discussion of any patterns of disputes are expected 838 to inform future changes to RFC Series policies, including possible 839 updates to this document. 841 4.4. Issues with Contractual Impact 843 If a disagreement or decision has immediate or future contractual 844 consequences, it falls under [I-D.ietf-iasa2-rfc4071bis]; thus, the 845 RSE must identify the issue and provide his or her advice to the LLC; 846 additionally, if the RSOC has provided advice, forward that advice as 847 well. The LLC must notify the RSOC and IAB regarding the action it 848 concludes is required to resolve the issue based on its applicable 849 procedures and provisions in the relevant contracts. 851 5. IANA Considerations 853 This document defines several functions within the overall RFC Editor 854 structure, and it places the responsibility for coordination of 855 registry value assignments with the RFC Production Center. The LLC 856 will facilitate the establishment of the relationship between the RFC 857 Production Center and IANA. 859 This document does not create a new registry nor does it register any 860 values in existing registries, and no IANA action is required. 862 6. Security Considerations 864 The same security considerations as those in [RFC4844] apply. The 865 processes for the publication of documents must prevent the 866 introduction of unapproved changes. Since the RFC Editor maintains 867 the index of publications, sufficient security must be in place to 868 prevent these published documents from being changed by external 869 parties. The archive of RFC documents, any source documents needed 870 to recreate the RFC documents, and any associated original documents 871 (such as lists of errata, tools, and, for some early items, originals 872 that are not machine readable) need to be secured against any kind of 873 data storage failure. 875 The LLC should take these security considerations into account during 876 the implementation and enforcement of the RFC Editor component 877 contracts. 879 7. Acknowledgments 881 The RFC Editor model was conceived and discussed in hallways and on 882 mailing lists. The first iteration of the text on which this 883 document is based was first written by Leslie Daigle, Russ Housley, 884 and Ray Pelletier. In addition to the members of the IAOC and IAB in 885 conjunction with those roles, major and minor contributions were made 886 by (in alphabetical order): Bob Braden, Brian Carpenter, Sandy 887 Ginoza, Alice Russo, Joel M. Halpern, Alfred Hoenes, Paul Hoffman, 888 John Klensin, Subramanian Moonesamy, and Jim Schaad. 890 The IAOC members at the time this RFC Editor model was approved were 891 (in alphabetical order): Bernard Aboba (ex officio), Eric Burger, 892 Dave Crocker, Marshall Eubanks, Bob Hinden, Russ Housley (ex 893 officio), Ole Jacobsen, Ray Pelletier (non-voting), and Lynn St. 894 Amour (ex officio). 896 The IAB members at the time the initial RFC Editor model was approved 897 were (in alphabetical order): Loa Andersson, Gonzalo Camarillo, 898 Stuart Cheshire, Russ Housley, Olaf Kolkman, Gregory Lebovitz, Barry 899 Leiba, Kurtis Lindqvist, Andrew Malis, Danny McPherson, David Oran, 900 Dave Thaler, and Lixia Zhang. In addition, the IAB included two ex 901 officio members: Dow Street, who was serving as the IAB Executive 902 Director, and Aaron Falk, who was serving as the IRTF Chair. 904 The IAB members at the time the this RFC was approved were (in 905 alphabetical order): Bernard Aboba, Ross Callon, Alissa Cooper, 906 Spencer Dawkins, Joel Halpern, Russ Housley, David Kessens, Olaf 907 Kolkman, Danny McPherson, Jon Peterson, Andrei Robachevsky, Dave 908 Thaler, and Hannes Tschofenig. In addition, at the time of approval, 909 the IAB included two ex officio members: Mary Barnes who was serving 910 as the IAB Executive Director, and Lars Eggert, who was serving as 911 the IRTF Chair. 913 Bob Hinden served as documented editor for this version of this 914 document that aligned it with the IASA 2.0 model. 916 8. Change log [RFC Editor: Please remove] 918 draft-ietf-iasa2-rfc6635bis-03, 2019-January-7 920 * Removed IAB as an author to follow current model for IAB stream 921 documents. 922 * Added note to Abstract that the IAB (to be removed by the RFC 923 Editor), that the IAB is requested to publish this document as 924 a replacement for RFC 6635. 925 * Editorial Changes. 927 draft-ietf-iasa2-rfc6635bis-02, 2019-January-3 929 * Changed references to point to current IASA 2.0 structure 930 document [I-D.ietf-iasa2-rfc4071bis] 932 draft-ietf-iasa2-rfc6635bis-01, 2018-August-23 934 * Changed to Obsolete RFC6635 from Update. 935 * Changed remaining occurrences of Board. 936 * Changed IETF Administration Limited Liability Corporation to 937 IETF Administration Limited Liability Company. 938 * Editorial Changes. 940 draft-ietf-iasa2-rfc6635bis-00, 2018-August-22 942 * Working Group draft. 943 * Removed remaining references to RFC4071. 944 * Changed most occurrences of LLC Board to LLC. 945 * Editorial Changes. 947 draft-hinden-iasa2-rfc6635bis-01, 2018-August-6 949 * Changed occurrences of IASA to IETF Administration Limited 950 Liability Corporation ("LLC"). 951 * Changed occurrences of IAOC to LLC Board. 952 * Changed occurrences of IAD to LLC Executive Director. 953 * Added paragraph to introduction about purpose of this version 954 of the document, and updated Abstract similarly. 955 * Added new editor to acknowledgement section. 956 * Changed document to now oboslete RFC6635. 958 draft-hinden-iasa2-rfc6635bis-00, 2018-August-6 960 * Original version with only changes from RFC6635 were to convert 961 to ID format. 963 9. References 965 9.1. Normative References 967 [I-D.ietf-iasa2-rfc4071bis] 968 Haberman, B., Hall, J., and J. Livingood, "Structure of 969 the IETF Administrative Support Activity, Version 2.0", 970 draft-ietf-iasa2-rfc4071bis-03 (work in progress), 971 December 2018. 973 [RFC2850] Internet Architecture Board and B. Carpenter, Ed., 974 "Charter of the Internet Architecture Board (IAB)", BCP 975 39, RFC 2850, DOI 10.17487/RFC2850, May 2000, 976 . 978 [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC 979 Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, 980 July 2007, . 982 [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor 983 Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June 984 2012, . 986 9.2. Informative References 988 [RFC3777] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, 989 and Recall Process: Operation of the Nominating and Recall 990 Committees", RFC 3777, DOI 10.17487/RFC3777, June 2004, 991 . 993 [RFC5620] Kolkman, O., Ed. and IAB, "RFC Editor Model (Version 1)", 994 RFC 5620, DOI 10.17487/RFC5620, August 2009, 995 . 997 Authors' Addresses 999 Olaf M. Kolkman (editor) 1001 Email: olaf@nlnetlabs.nl 1003 Joel M. Halpern (editor) 1004 Ericsson 1006 Email: joel.halpern@ericsson.com 1007 Robert M. Hinden (editor) 1008 Check Point Software 1009 959 Skyway Road 1010 San Carlos, CA 94070 1011 USA 1013 Email: bob.hinden@gmail.com