idnits 2.17.1 draft-ietf-iasa2-rfc6635bis-04.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 (October 4, 2019) is 1665 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 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 (~~), 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: 6635 (if approved) J. Halpern, Ed. 5 Intended status: Informational Ericsson 6 Expires: April 6, 2020 R. Hinden, Ed. 7 Check Point Software 8 October 4, 2019 10 RFC Editor Model (Version 2) 11 draft-ietf-iasa2-rfc6635bis-04 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 April 6, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 22 96 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 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 IETF Administrative 108 Oversight Committee (IAOC) is eliminated, and its oversight and 109 advising functions transferred to the new LLC. This document 110 obsoletes [RFC6635] to replace all references to the IASA and related 111 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 its 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. To ensure this, the 503 RSE will be subject to a conflict of interest policy established by 504 the LLC. 506 2.2. RFC Production Center 508 The RFC Production Center function is performed by a paid contractor, 509 and the contractor's responsibilities include the following: 511 1. Editing inputs from all RFC streams to comply with the RFC Style 512 Manual, under the direction of the RSE; 514 2. Creating records of edits performed on documents; 516 3. Identifying where editorial changes might have technical impact 517 and seeking necessary clarification; 519 4. Engaging in dialog with authors, document shepherds, IANA, and/ 520 or stream-dependent contacts when clarification is needed; 522 5. Creating records of dialog with document authors; 524 6. Requesting advice from the RFC Series Editor as needed; 526 7. Providing suggestions to the RFC Series Editor as needed; 528 8. Providing sufficient resources to support reviews of RFC 529 Publisher performance by the RFC Series Editor and external 530 reviews of the RFC Editor function initiated by the IAB or LLC; 532 9. Coordinating with IANA to ensure correct documentation of IANA- 533 performed protocol registry actions; 535 10. Assigning RFC numbers; 537 11. Establishing publication readiness of each document through 538 communication with the authors, document shepherds, IANA, and/or 539 stream-dependent contacts, and, if needed, with the RFC Series 540 Editor; 542 12. Forwarding documents that are ready for publication to the RFC 543 Publisher; 545 13. Forwarding records of edits and author dialog to the RFC 546 Publisher so these can be preserved; 548 14. Liaising with the streams as needed. 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 Production Center contractor is to be selected through an LLC 555 Request for Proposal (RFP) process as described in Section 4.1. 557 2.3. RFC Publisher 559 The RFC Publisher responsibilities include the following: 561 1. Announcing and providing on-line access to RFCs. 563 2. Providing an on-line system to submit RFC Errata. 565 3. Providing on-line access to approved RFC Errata. 567 4. Providing backups. 569 5. Providing storage and preservation of records. 571 6. Authenticating RFCs for legal proceedings. 573 All these activities will be done under the general direction, but 574 not day-to-day management, of the RSE and need some level of 575 coordination with various submission streams and the RSE. 577 The RFC Publisher contractor is to be selected through an LLC RFP 578 process as described in Section 4.1. 580 3. Committees 582 3.1. RFC Series Oversight Committee (RSOC) 584 The IAB is responsible for the oversight of the RFC Series and acts 585 as a body for final conflict resolution, including the process 586 described in Section 4.3. 588 In order to provide continuity over periods longer than the NomCom 589 appointment cycle [RFC3777] and assure that oversight includes 590 suitable subject matter expertise, the IAB will establish a group 591 that implements oversight for the IAB, the RFC Series Oversight 592 Committee (RSOC). 594 The RSOC will act with authority delegated from the IAB: in general, 595 it will be the RSOC that will approve consensus policy and vision 596 documents as developed by the RSE in collaboration with the 597 community. While it is expected that the IAB will exercise due 598 diligence in its supervision of the RSOC, the RSOC should be allowed 599 the latitude to do its job without undue interference from the IAB. 600 Therefore, it is expected that the IAB will accord RSOC reports and 601 recommendations the benefit of the doubt. 603 For all decisions that affect the RSE individually (e.g., hiring and 604 firing), the RSOC prepares recommendations for the IAB, but approval 605 of these recommendations is the responsibility of the IAB. For 606 instance the RSOC would do the following: 608 o perform annual reviews of the RSE and report the result of these 609 reviews to the IAB. 611 o manage RSE candidate selection and advise the IAB on candidate 612 appointment (in other words, select the RSE subject to IAB 613 approval). 615 RSOC members are expected to recognize potential conflicts of 616 interest and behave accordingly. 618 For the actual recruitment and selection of the RSE, the RSOC will 619 propose a budget for the search process. It will work with the LLC 620 to refine that budget and develop remuneration criteria and an 621 employment agreement or contracting plans, as appropriate. 623 The RSOC will be responsible for ensuring that the RFC Series is run 624 in a transparent and accountable manner. 626 The RSOC shall develop and publish its own rules of order. 628 The initial RSOC was charged with designing and executing a 629 solicitation, search, and selection process for the first actual (not 630 transitional or "acting") RSE appointment. That process involved 631 iteration on this and related documents and evaluation of various 632 strategies and options. During the creation of this document, it was 633 expected that the RSOC would describe the process it ultimately 634 selected to the community. The RSOC did involve the community in 635 interim considerations when that was likely to be of value. 636 Following completion of the selection process, the RSOC will 637 determine the best way to share information learned and experience 638 gained with the community and determine how to best preserve that 639 information for future use. 641 3.1.1. RSOC Composition 643 The RSOC will operate under the authority of the IAB, with the IAB 644 retaining final responsibility. The IAB will delegate authority and 645 responsibility to the RSOC as appropriate and as RSOC and RSE 646 relationships evolve. The RSOC will include people who are not 647 current IAB members. Currently, this is aligned with the IAB program 648 structure. The IAB will designate the membership of the RSOC with 649 the following goals: preserving effective stability; keeping it small 650 enough to be effective, and keeping it large enough to provide 651 general Internet community expertise, specific IETF expertise, 652 publication expertise, and stream expertise. Members serve at the 653 pleasure of the IAB and are expected to bring a balance between 654 short- and long-term perspectives. Specific input about, and 655 recommendations of, members will be sought from the streams, the LLC, 656 and the RSE. 658 In addition to the members from outside of the IAB appointed to the 659 RSOC, IAB members may participate as full members of the RSOC. Under 660 most circumstances, there will be a specific individual IAB member 661 appointed by the IAB as the program lead, who will be a full member 662 of the RSOC. This member's role is distinct from any RSOC-internal 663 organizational roles, such as would be created by the RSOC choosing 664 to appoint a chair from among its members. Other IAB members may 665 choose to be full members of the RSOC, with the consent of the IAB. 666 This consent is primarily concerned with avoiding overpopulating the 667 RSOC and providing it with relatively stable membership, which will 668 work best if it is not too large a committee. 670 The LLC will appoint an individual to serve as its liaison to the 671 RSOC. The RSE and the LLC Liaison will serve as non-voting ex 672 officio members of the RSOC. Either or both can be excluded from its 673 discussions if necessary. 675 4. Administrative Implementation 677 The exact implementation of the administrative and contractual 678 activities described here are a responsibility of the IETF 679 Administration Limited Liability Company [I-D.ietf-iasa2-rfc4071bis] 680 in cooperation with the RFC Series Editor. The authority structure 681 is described in Figure 2 below. 683 +----------------+ +----------------+ 684 | | | | 685 | IAB | | LLC | 686 | | | | 687 +==========+-----+ +-+--------------+ 688 | | . 689 | RSOC | . 690 | | . 691 +----+-----+ . 692 | . 693 | . 694 | ................... 695 | . . 696 +--------V---V----+ . 697 | | . 698 | RFC | . 699 | Series | . 700 | Editor | . 701 | | . 702 +--------+--------+ . 703 | . 704 | ................. 705 | . . 706 +--+----------------+ . 707 | . | . 708 | . | . 709 +---V-----V--+ +--V----V---+ 710 | RFC | | RFC | 711 | Production | | Publisher | 712 | Center | | | 713 +------------+ +-----------+ 715 Authority Structure of the RFC Series 717 Legend: 719 ------- IAB RFC Series Oversight 720 ....... LLC Contract/Budget Oversight 722 Figure 2 724 4.1. Vendor Selection for the Production and Publisher Functions 726 As stated earlier, vendor selection is done in cooperation with the 727 streams and under the final authority of the LLC. 729 The RSE owns and develops the work definition (the SOW) and 730 participates in the LLC vendor selection process. The work 731 definition is created within the LLC budget and takes into account 732 the stream managers and community input. 734 The process to select and contract for an RFC Production Center, RFC 735 Publisher, and other RFC-related services, is as follows: 737 o The LLC establishes the contract process, including the steps 738 necessary to issue an RFP when necessary, the timing, and the 739 contracting procedures. 741 o The LLC establishes the Selection Committee, which will consist of 742 the RSE, the LLC Executive Director, and other members selected by 743 the RSOC and the LLC. The Committee shall be chaired by the RSE. 745 o The Selection Committee selects the vendor, subject to the 746 successful negotiation of a contract approved by the LLC. In the 747 event that a contract cannot be reached, the matter shall be 748 referred to the Selection Committee for further action. 750 o The Selection Committee may select an RFC Publisher either through 751 the LLC RFP process or, at the Committee's option, the Committee 752 may select the IETF Secretariat to provide RFC Publisher services, 753 subject to negotiations in accordance with the LLC procedures. 755 4.2. Budget 757 The expenses discussed in this document are not new expenses. They 758 have been and remain part of the IETF Administration Limited 759 Liability Company [I-D.ietf-iasa2-rfc4071bis] budget. 761 The RFC Series portion of the LLC budget shall include funding to 762 support the RSE, RFC Production Center, RFC Publisher, and the 763 Independent Stream. 765 The LLC has the responsibility to approve the total RFC Editor budget 766 (and the authority to deny it). The RSE must work within the LLC 767 budgetary process. 769 The RSE is responsible for managing the RFC Editor function to 770 operate within those budgets. If production needs change, the RSE is 771 responsible for working with the Production Center, and where 772 appropriate, other RFC Editor component institutions, relevant 773 streams, and/or the RSOC to determine what the correct response 774 should be. If they agree that a budgetary change is needed, that 775 decision needs to be taken to the LLC. 777 4.3. Disagreements among Entities Related to the RFC Editor 779 The RFC Series Editor and the RFC Production Center and Publisher 780 facilities work with the various streams to produce RFCs. 781 Disagreements may arise between these entities during the execution 782 of the RFC Editor operations. In particular, different streams may 783 disagree with each other, or disagree with the RFC Editor function. 784 Potentially, even the RSOC or the LLC could find themselves in 785 disagreement with some aspect of the RFC Editor operations. Note 786 that disagreements between an author and the RFC Production Center 787 are not cross-entity issues, and they are to be resolved by the RSE, 788 in accordance with the rest of this document. 790 If such cross-entity disagreements arise, the community would 791 generally hope that they can be resolved politely and directly. 792 However, this is not always possible. At that point, any relevant 793 party would first formally request a review and reconsideration of 794 the decision. If the party still disagrees after the 795 reconsideration, that party may ask the RSE to decide or, especially 796 if the RSE is involved, the party may ask the IAB Chair (for a 797 technical or procedural matter) to mediate or appoint a mediator to 798 aid in the discussions, although he or she not is obligated to do so. 799 All parties should work informally and in good faith to reach a 800 mutually agreeable conclusion. As noted below, any such issues that 801 involve contractual matters must be brought to the attention of the 802 LLC. If the IAB Chair is asked to assist in resolving the matter, 803 the Chair may ask for advice or seek assistance from anyone the Chair 804 deems helpful. The Chair may also alert any appropriate individuals 805 or organizations to the existence of the issue. 807 If such a conclusion is not possible through the above less formal 808 processes, then the matter must be registered with the RFC Series 809 Oversight Committee. The RSOC may choose to offer advice to the RSE 810 or more general advice to the parties involved and may ask the RSE to 811 defer a decision until it formulates its advice. However, if a 812 timely decision cannot be reached through discussion, mediation, and 813 mutual agreement, the RSE is expected to make whatever decisions are 814 needed to ensure the smooth operation of the RFC Editor function; 815 those decisions are final. 817 The RSE may make final decisions unilaterally only to assure the 818 functioning of the process, and only while there is an evaluation of 819 current policies to determine whether they are appropriately 820 implemented in the decision or need adjustment. In particular, it 821 should be noted that final decisions about the technical content of 822 individual documents are the exclusive responsibility of the stream 823 approvers from which those documents originate, as shown in the 824 illustration in Figure 1. 826 If informal agreements cannot be reached, then formal RSOC review and 827 decision making may be required. If so, the RSE must present the 828 issues involved to the community so that the community is aware of 829 the situation. The RSE will then report the issue to the RSOC for 830 formal resolution by the RSOC with confirmation by the IAB in its 831 oversight capacity. 833 IAB and community discussion of any patterns of disputes are expected 834 to inform future changes to RFC Series policies, including possible 835 updates to this document. 837 4.4. Issues with Contractual Impact 839 If a disagreement or decision has immediate or future contractual 840 consequences, it falls under [I-D.ietf-iasa2-rfc4071bis]. If this 841 happens the RSE must identify the issue and provide advice to the 842 LLC. Additionally, if the RSOC has also developed advice, it should 843 forward that advice to the LLC. 845 The LLC must notify the RSOC and IAB regarding the action it 846 concludes is required to resolve the issue based on its applicable 847 procedures and provisions in the relevant contracts. 849 5. IANA Considerations 851 This document defines several functions within the overall RFC Editor 852 structure, and it places the responsibility for coordination of 853 registry value assignments with the RFC Production Center. The LLC 854 will facilitate the establishment of the relationship between the RFC 855 Production Center and IANA. 857 This document does not create a new registry nor does it register any 858 values in existing registries, and no IANA action is required. 860 6. Security Considerations 862 The same security considerations as those in [RFC4844] apply. The 863 processes for the publication of documents must prevent the 864 introduction of unapproved changes. Since the RFC Editor maintains 865 the index of publications, sufficient security must be in place to 866 prevent these published documents from being changed by external 867 parties. The archive of RFC documents, any source documents needed 868 to recreate the RFC documents, and any associated original documents 869 (such as lists of errata, tools, and, for some early items, originals 870 that are not machine readable) need to be secured against any kind of 871 data storage failure. 873 The LLC should take these security considerations into account during 874 the implementation and enforcement of the RFC Editor component 875 contracts. 877 7. Acknowledgments 879 The RFC Editor model was conceived and discussed in hallways and on 880 mailing lists. The first iteration of the text on which this 881 document is based was first written by Leslie Daigle, Russ Housley, 882 and Ray Pelletier. In addition to the members of the IAOC and IAB in 883 conjunction with those roles, major and minor contributions were made 884 by (in alphabetical order): Bob Braden, Brian Carpenter, Sandy 885 Ginoza, Alice Russo, Joel M. Halpern, Alfred Hoenes, Paul Hoffman, 886 John Klensin, Subramanian Moonesamy, and Jim Schaad. 888 The IAOC members at the time this RFC Editor model was approved were 889 (in alphabetical order): Bernard Aboba (ex officio), Eric Burger, 890 Dave Crocker, Marshall Eubanks, Bob Hinden, Russ Housley (ex 891 officio), Ole Jacobsen, Ray Pelletier (non-voting), and Lynn St. 892 Amour (ex officio). 894 The IAB members at the time the initial RFC Editor model was approved 895 were (in alphabetical order): Loa Andersson, Gonzalo Camarillo, 896 Stuart Cheshire, Russ Housley, Olaf Kolkman, Gregory Lebovitz, Barry 897 Leiba, Kurtis Lindqvist, Andrew Malis, Danny McPherson, David Oran, 898 Dave Thaler, and Lixia Zhang. In addition, the IAB included two ex 899 officio members: Dow Street, who was serving as the IAB Executive 900 Director, and Aaron Falk, who was serving as the IRTF Chair. 902 The IAB members at the time the this RFC was approved were (in 903 alphabetical order): Bernard Aboba, Ross Callon, Alissa Cooper, 904 Spencer Dawkins, Joel Halpern, Russ Housley, David Kessens, Olaf 905 Kolkman, Danny McPherson, Jon Peterson, Andrei Robachevsky, Dave 906 Thaler, and Hannes Tschofenig. In addition, at the time of approval, 907 the IAB included two ex officio members: Mary Barnes who was serving 908 as the IAB Executive Director, and Lars Eggert, who was serving as 909 the IRTF Chair. 911 Bob Hinden served as documented editor for this version of this 912 document that aligned it with the IASA 2.0 model. 914 8. Change log [RFC Editor: Please remove] 916 draft-ietf-iasa2-rfc6635bis-04, 2019-October-4 918 * Changes relating to issues reaised during last call. Includes 919 changing conflict of interest text to point to LLC conflict 920 interest policy, and several editorial clarifications and 921 corrections. 923 draft-ietf-iasa2-rfc6635bis-03, 2019-January-7 925 * Removed IAB as an author to follow current model for IAB stream 926 documents. 927 * Added note to Abstract that the IAB (to be removed by the RFC 928 Editor), that the IAB is requested to publish this document as 929 a replacement for RFC 6635. 930 * Editorial Changes. 932 draft-ietf-iasa2-rfc6635bis-02, 2019-January-3 934 * Changed references to point to current IASA 2.0 structure 935 document [I-D.ietf-iasa2-rfc4071bis] 937 draft-ietf-iasa2-rfc6635bis-01, 2018-August-23 939 * Changed to Obsolete RFC6635 from Update. 940 * Changed remaining occurrences of Board. 941 * Changed IETF Administration Limited Liability Corporation to 942 IETF Administration Limited Liability Company. 943 * Editorial Changes. 945 draft-ietf-iasa2-rfc6635bis-00, 2018-August-22 947 * Working Group draft. 948 * Removed remaining references to RFC4071. 949 * Changed most occurrences of LLC Board to LLC. 950 * Editorial Changes. 952 draft-hinden-iasa2-rfc6635bis-01, 2018-August-6 954 * Changed occurrences of IASA to IETF Administration Limited 955 Liability Corporation ("LLC"). 956 * Changed occurrences of IAOC to LLC Board. 957 * Changed occurrences of IAD to LLC Executive Director. 958 * Added paragraph to introduction about purpose of this version 959 of the document, and updated Abstract similarly. 960 * Added new editor to acknowledgement section. 961 * Changed document to now oboslete RFC6635. 963 draft-hinden-iasa2-rfc6635bis-00, 2018-August-6 965 * Original version with only changes from RFC6635 were to convert 966 to ID format. 968 9. References 970 9.1. Normative References 972 [I-D.ietf-iasa2-rfc4071bis] 973 Haberman, B., Hall, J., and J. Livingood, "Structure of 974 the IETF Administrative Support Activity, Version 2.0", 975 draft-ietf-iasa2-rfc4071bis-11 (work in progress), April 976 2019. 978 [RFC2850] Internet Architecture Board and B. Carpenter, Ed., 979 "Charter of the Internet Architecture Board (IAB)", BCP 980 39, RFC 2850, DOI 10.17487/RFC2850, May 2000, 981 . 983 [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC 984 Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, 985 July 2007, . 987 [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor 988 Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June 989 2012, . 991 9.2. Informative References 993 [RFC3777] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, 994 and Recall Process: Operation of the Nominating and Recall 995 Committees", RFC 3777, DOI 10.17487/RFC3777, June 2004, 996 . 998 [RFC5620] Kolkman, O., Ed. and IAB, "RFC Editor Model (Version 1)", 999 RFC 5620, DOI 10.17487/RFC5620, August 2009, 1000 . 1002 Authors' Addresses 1004 Olaf M. Kolkman (editor) 1006 Email: olaf@nlnetlabs.nl 1007 Joel M. Halpern (editor) 1008 Ericsson 1010 Email: joel.halpern@ericsson.com 1012 Robert M. Hinden (editor) 1013 Check Point Software 1014 959 Skyway Road 1015 San Carlos, CA 94070 1016 USA 1018 Email: bob.hinden@gmail.com