idnits 2.17.1 draft-iab-rfcefdp-rfced-model-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document obsoletes RFC6635, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC8728, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 09, 2021) is 1015 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 842 -- Looks like a reference, but probably isn't: '2' on line 844 -- Looks like a reference, but probably isn't: '3' on line 846 -- Looks like a reference, but probably isn't: '4' on line 848 -- Looks like a reference, but probably isn't: '5' on line 850 -- Looks like a reference, but probably isn't: '6' on line 852 -- Looks like a reference, but probably isn't: '7' on line 854 -- Looks like a reference, but probably isn't: '8' on line 856 -- Looks like a reference, but probably isn't: '9' on line 858 -- Looks like a reference, but probably isn't: '10' on line 860 -- Looks like a reference, but probably isn't: '11' on line 862 -- Looks like a reference, but probably isn't: '12' on line 864 -- Looks like a reference, but probably isn't: '13' on line 866 -- Looks like a reference, but probably isn't: '14' on line 868 -- Looks like a reference, but probably isn't: '15' on line 870 -- Looks like a reference, but probably isn't: '16' on line 872 -- Looks like a reference, but probably isn't: '17' on line 875 -- Looks like a reference, but probably isn't: '18' on line 877 -- Looks like a reference, but probably isn't: '19' on line 879 -- Looks like a reference, but probably isn't: '20' on line 882 -- Looks like a reference, but probably isn't: '21' on line 884 -- Looks like a reference, but probably isn't: '22' on line 886 -- 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) -- Obsolete informational reference (is this intentional?): RFC 6635 (Obsoleted by RFC 8728) -- Obsolete informational reference (is this intentional?): RFC 8728 (Obsoleted by RFC 9280) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 30 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre, Ed. 3 Internet-Draft Mozilla 4 Obsoletes: RFC8728 (if approved) July 09, 2021 5 Intended status: Informational 6 Expires: January 10, 2022 8 RFC Editor Model (Version 3) 9 draft-iab-rfcefdp-rfced-model-00 11 Abstract 13 This document describes Version 3 of the RFC Editor model. As 14 specified here, the model divides the responsibilities for the RFC 15 Series into two high-level functions: policy definition governing the 16 Series as a whole, and policy implementation through publication of 17 documents in the Series. The policy definition function is the 18 responsibility of the RFC Series Working Group (RSWG), which produces 19 policy proposals that are subject to approval by the RFC Series 20 Approval Board (RSAB). The policy implementation function is 21 primarily the responsibility of the RFC Production Center (RPC), 22 under the ultimate authority of the IETF Administration Limited 23 Liability Company (LLC). 25 This document reflects experience gained with version 1 of the RFC 26 Editor Model as specified in RFC 5620 and with version 2 as specified 27 in RFC 6635 and RFC 8728. 29 This document obsoletes RFC 8728. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 10, 2022. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Overview of the Model . . . . . . . . . . . . . . . . . . . . 4 67 3. Policy Definition Function . . . . . . . . . . . . . . . . . 5 68 3.1. Structure and Roles . . . . . . . . . . . . . . . . . . . 5 69 3.1.1. RFC Series Working Group (RSWG) . . . . . . . . . . . 5 70 3.1.2. RFC Series Approval Board (RSAB) . . . . . . . . . . 6 71 3.2. Process . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.2.1. Intent . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.2.2. Specifics . . . . . . . . . . . . . . . . . . . . . . 8 74 3.2.3. Community Calls for Comment . . . . . . . . . . . . . 10 75 3.2.4. Appeals . . . . . . . . . . . . . . . . . . . . . . . 10 76 3.2.5. Anti-Harassment Policy . . . . . . . . . . . . . . . 11 77 4. RFC Series Editor/Advisor (RSEA) . . . . . . . . . . . . . . 11 78 4.1. RSEA Selection . . . . . . . . . . . . . . . . . . . . . 12 79 4.2. RSEA Performance Evaluation . . . . . . . . . . . . . . . 12 80 5. Policy Implementation Function . . . . . . . . . . . . . . . 12 81 5.1. Roles and Processes . . . . . . . . . . . . . . . . . . . 12 82 5.2. Editorial and Publication Policies . . . . . . . . . . . 13 83 5.3. Resolution of Disagreements between Authors and the RPC . 13 84 5.4. Administrative Implementation . . . . . . . . . . . . . . 14 85 5.4.1. Vendor Selection for the RFC Production Center . . . 14 86 5.4.2. Budget . . . . . . . . . . . . . . . . . . . . . . . 15 87 6. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 6.1. Editorial Stream . . . . . . . . . . . . . . . . . . . . 15 89 6.2. Creating and Deleting Streams . . . . . . . . . . . . . . 15 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 92 9. Changes from Version 2 of the RFC Editor Model . . . . . . . 16 93 9.1. RFC Series Editor . . . . . . . . . . . . . . . . . . . . 16 94 9.2. RFC Series Oversight Committee (RSOC) . . . . . . . . . . 16 95 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 11.1. Informative References . . . . . . . . . . . . . . . . . 17 98 11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 99 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 102 1. Introduction 104 NOTE: This document is a work in progress. Although it is intended 105 to describe consensus forged in the RFC Editor Future Development 106 Program, many aspects are not yet settled; as a result, this document 107 contains proposals and conjectures that do not yet have consensus in 108 the Program. Where possible, open issues are identified herein to 109 foster discussion. 111 Documents in the Request for Comments (RFC) series have been 112 continually published since 1969 [RFC8700]. The RFC series is 113 described in [RFC8729]. RFC 8729 uses the term "RFC Editor function" 114 or "RFC Editor" to identify the collective set of responsibilities 115 for publishing documents in the RFC series. 117 The processes and organizational models for publication of RFCs have 118 changed significantly over the years. Most recently, in 2009 119 [RFC5620] defined the RFC Editor Model (Version 1) and in 2012 120 [RFC6635] defined the RFC Editor Model (Version 2), since modified 121 slightly in 2020 by [RFC8728]. 123 In order to provide a sustainable basis for continued publication of 124 the RFC series, this document describes Version 3 of the RFC Editor 125 model, which divides the responsibilities for the RFC Series into two 126 high-level functions: policy definition governing the Series as a 127 whole, and policy implementation through publication of documents in 128 the Series. The policy definition function is the responsibility of 129 the RFC Series Working Group (RSWG), which produces policy proposals 130 that are subject to approval by the RFC Series Approval Board (RSAB). 131 The policy implementation function is primarily the responsibility of 132 the RFC Production Center (RPC), under the ultimate authority of the 133 IETF Administration Limited Liability Company (LLC) [RFC8711]. 135 This document obsoletes RFC 8728 by making a full update to the RFC 136 Editor Model, changing the responsibilities of existing bodies and 137 functions, and introducing new functions (see Section 7 of this 138 document for a summary of the changes from Version 2). 140 2. Overview of the Model 142 Version 2 of the RFC Editor Model [RFC8728] specified a structure 143 consisting of the RFC Series Editor, the RFC Production Center, and 144 the RFC Publisher, with oversight provided by the RFC Series 145 Oversight Committee (RSOC) on behalf of the Internet Architecture 146 Board (IAB). 148 Discussion within the RFCED-Future Program has led in the direction 149 of a more consensus-oriented structure (similar in some respects to 150 the structure of technical work within the IETF or IRTF) that retains 151 roles for specialized expertise in document editing and publication. 153 The policy definition function is performed by the RFC Series Working 154 Group (RSWG), which produces policy proposals that are subject to 155 approval by the RFC Series Approval Board (RSAB), after which such 156 policies are formally established. The RSWG is an open working group 157 (as described below) that seeks input and participation from a wide 158 range of persons who are have an interest in the RFC Series. The 159 RSAB consists of appointed members who represent the various RFC 160 streams [RFC8728] as well as an expert in technical publishing, the 161 RFC Series Editor/Advisor (RSEA). 163 The policy implementation function is performed by the RFC Production 164 Center (RPC), under the ultimate authority of the IETF Administration 165 Limited Liability Company (IETF LLC). 167 In short: 169 o The RSWG establishes policy, with input from the community, the 170 RSAB, and the RSEA. 172 o The RSAB considers those proposals and approves or returns as 173 appropriate. 175 o The RPC periodically reports to the RSAB on how it is implementing 176 established policies. 178 o The RSEA provides expert advice to the RPC and RSAB on how to 179 implement established policies on an ongoing and operational 180 basis, which can include raising issues or initiating proposed 181 policy changes within the RSWG. 183 o If issues arise with the implementation of particular policies, 184 the RPC brings them to the RSAB who interprets the policy and 185 provides interim guidance to the RPC, informing the RSWG of those 186 interpretations. 188 The remainder of this document describes the model in greater detail. 190 3. Policy Definition Function 192 Policies governing the RFC series as a whole shall be defined in the 193 open through proposals that are generated by and discussed within the 194 RFC Series Working Group (RSWG) and then approved by the RFC Series 195 Approval Board (RSAB). 197 Policies under the purview of the RSWG and RSAB might include but are 198 not necessarily limited to document formats, processes for 199 publication and dissemination of RFCs, and overall management of the 200 RFC series. 202 3.1. Structure and Roles 204 3.1.1. RFC Series Working Group (RSWG) 206 The RFC Series Working Group (RSWG) shall formulate proposals 207 regarding policies that govern the RFC series. The intent is that 208 the RSWG operate in a way similar to working groups in the IETF and 209 research groups in the IRTF. Therefore, all RSWG meetings shall be 210 open to any participant, subject to intellectual property policies 211 which must be consistent with those of the IETF as specified in BCP 212 78 [RFC5378] and BCP 79 [RFC8179]. 214 The RSWG shall operate by rough consensus, a mode of operation 215 informationally described in [RFC7282]. 217 When the RSWG is formed, all discussions shall take place on an open 218 email discussion list. Subsequently, the RSWG may decide by rough 219 consensus to also use additional tooling (e.g., GitHub as specified 220 in [RFC8874]), forms of communication (e.g., in-person or online 221 meetings), and working methods (e.g., design teams) as long as they 222 are consistent with [RFC2418]. 224 All interested persons are welcome to participate in the RSWG 225 (subject to anti-harassment policies as described below). This 226 includes participants in the IETF and IRTF, IAB and IESG members, RFC 227 authors, individuals who use RFCs in procurement decisions, and the 228 like. The IETF LLC Board members, staff, and the IETF Executive 229 Director are invited to participate as community members in the RSWG 230 to the extent permitted by any relevant IETF LLC policies. Members 231 of the RSAB are also expected to participate actively. 233 The RSWG shall have two chairs, one appointed by the IESG and the 234 other appointed by the IAB. When the RSWG is formed, the chair 235 appointed by the IESG shall serve for a term of one (1) year and the 236 chair appointed by the IAB shall serve for a term of two (2) years; 237 thereafter, chairs shall serve for a term of two (2) years, with no 238 term limits on renewal. The appointing bodies shall determine their 239 own processes for making these appointments, such as provision for an 240 open nominations period. Community members who have concerns about 241 the performance of an RSWG chair should direct their feedback to the 242 relevant appointing body. Each appointing body shall have the power 243 to remove its appointed chair at its discretion. 245 It is the responsibility of the chairs to encourage rough consensus 246 within the RSWG and to follow that consensus in their decision 247 making, for instance regarding advancement of proposals to the RSAB. 249 NOTE: This section is intended to address ISSUE #9 [1], ISSUE #14 250 [2], ISSUE #16 [3], ISSUE #41 [4], ISSUE #44 [5], ISSUE #68 [6], and 251 ISSUE #72 [7]. 253 3.1.2. RFC Series Approval Board (RSAB) 255 The RFC Series Approval Board (RSAB) shall act as the approving body 256 for proposals generated within the RSWG. The sole function of RSAB 257 is to review policy proposals generated by the RSWG; it shall have no 258 independent authority to formulate policy on its own. It is expected 259 that the RSAB will respect the rough consensus of the RSWG wherever 260 possible, without ceding its review function. 262 The voting members of the RSAB shall be as follows: 264 o One delegate representing the IETF stream, appointed by the IESG 266 o One delegate representing the IAB stream, appointed by the IAB 268 o The IRTF Chair, representing the IRTF stream 270 o The Independent Submissions Editor [RFC8730] 272 o The RFC Series Editor/Advisor 274 To ensure the smooth functioning of the RFC Series, the RSAB shall 275 include the IETF Executive Director as a non-voting member since the 276 IETF LLC is ultimately responsible for the operation of the policy 277 implementation function. The RSAB may at its discretion include 278 additional non-voting members, for instance a liaison from the RPC. 280 The IAB and IESG delegates must be selected by the Nominating 281 Committee [RFC3777] to their respective bodies (i.e., they must not 282 be liaison or ex-officio members). These delegates shall serve for 283 one-year renewable terms. If it becomes necessary to replace such a 284 delegate for any reason, then for the sake of continuity the IAB or 285 IESG should name a new delegate to complete the term. 287 Whenever a new stream is created (see below), the document that 288 creates the stream shall specify if a voting member representing that 289 stream shall also be added to the RSAB, along with any rules and 290 processes related to that representative (e.g., whether the 291 representative is a member of the body responsible for the stream or 292 an appointed delegate thereof. 294 The RSAB shall choose a chair from among its members using a method 295 to be determined by the RSAB. 297 The RSAB is expected to operate via email, in-person meetings, 298 teleconferencing systems, and any additional tooling it deems 299 necessary. 301 The RSAB shall keep a public record of its proceedings, including 302 minutes of all meetings and a record of all decisions. 304 The RSAB shall announce plans and agendas for their meetings on the 305 RFC Editor website and by email to the RSWG at least a week before 306 such meetings. The meetings shall be open for public attendance and 307 the RSAB may consider allowing open participation. If the RSAB needs 308 to discuss a confidential matter in executive session, that part of 309 the meeting shall be private to the RSAB, but must be noted on the 310 agenda, and must be documented in the minutes with as much detail as 311 the confidentiality requirements permit. 313 NOTE: This section is intended to address ISSUE #9 [8], ISSUE #38 314 [9], ISSUE #50 [10], and ISSUE #53 [11]. 316 3.2. Process 318 3.2.1. Intent 320 The intent is to provide an open forum by which policies related to 321 the RFC series are defined and evolved. The general expectation is 322 that all interested parties will participate in the RSWG, and that 323 only under extreme circumstances should RSAB members need to hold 324 "CONCERN" positions as described below. 326 Because policy issues can be difficult and contentious, RSWG 327 participants and RSAB members are strongly encouraged to work 328 together in a spirit of good faith and mutual understanding to 329 achieve rough consensus (see [RFC7282]). In particular, RSWG members 330 are encouraged to take RSAB concerns seriously, and RSAB members are 331 encouraged to clearly express their concerns early in the process and 332 to be responsive to the community. All parties are encouraged to 333 respect the value of each stream and the long term health and 334 viability of the RFC series. 336 This process is intended to be one of continuous consultation. RSAB 337 members should consult with their constituent stakeholders (e.g., 338 authors, editors, tool developers, and consumers of RFCs) on an 339 ongoing basis, so that when the time comes to consider a proposal, 340 there should be no surprises. Appointing bodies are expected to 341 establish whatever processes they deem appropriate to facilitate this 342 goal. 344 3.2.2. Specifics 346 The following process shall be used to formulate or modify processes 347 related to the RFC series: 349 1. An individual participant in the RSWG generates a proposal in the 350 form of an Internet-Draft. 352 2. If there is sufficient interest in the proposal, RSWG may adopt 353 the proposal as a draft proposal of the RSWG, much the same way a 354 working group of the IETF or IRTF would (see [RFC2418]). 356 3. The RSWG shall then further develop the proposal. Members of the 357 RSAB are expected to participate in discussion relating to such 358 proposals so that they are fully aware of proposals early in the 359 policy definition process and so that any issues or concerns that 360 they have will be raised during the development of the proposals 361 and will not be left until the RSAB review period. 363 4. At some point, if the RSWG chairs believe there may be rough 364 consensus for the proposal to advance, they will issue a working 365 group last call. 367 5. After a suitable period of time, the RSWG chairs will determine 368 whether rough consensus for the proposal exists. If comments 369 have been received and substantial changes have been made, it is 370 expected that additional last calls may be necessary. 372 6. Once consensus is established in the RSWG, the RSAB shall issue a 373 community call for comments as further described below. Should 374 substantial comments be received, the RSWG will again consider 375 those comments and make revisions as they see fit. At this same 376 time, the RSAB will consider the proposal. 378 7. Should substantial changes be made, additional community calls 379 for comment should be issued by the RSAB, and again comments 380 considered by the RSWG. 382 8. Once all comments have been been addressed, the RSWG chairs will 383 submit the proposal to the RSAB for its consideration. 385 9. Within a reasonable period of time, the RSAB will then poll on 386 the proposal. Positions may be as follows: * "YES": the proposal 387 should be approved * "CONCERN": the proposal raises substantial 388 concerns that must be addressed. * "RECUSE": the person holding 389 the position has a conflict of interest. 391 Anyone holding a "CONCERN" position must explain their concern to the 392 community in detail. The explanation may or may not be actionable. 394 A CONCERN may be made for two reasons: 396 o The proposal represents a serious problem for the group a 397 particular member represents. 399 o The member believes that the proposal would cause serious harm to 400 the overall series, including harm to the long term health and 401 viability of the series. 403 No CONCERN should ever come as a surprise to the RSWG. 405 1. If a CONCERN exists, discussion will take place within the RSWG. 406 Again, all RSAB members are expected to participate. 408 2. A proposal without any CONCERN positions is approved. If 409 substantial changes have been made in order to address CONCERN 410 positions, an additional call for community input might be 411 necessary. 413 3. If, after a suitable period of time, any CONCERN positions 414 remain, a formal vote of the RSAB is taken. If a majority of 415 RSAB members vote to approve, the proposal is approved. 416 Otherwise, it is returned to the RSWG. In the case of a tie, the 417 proposal is approved. 419 4. When a proposal is approved, a notification is sent to the 420 community, and the document enters the queue for publication as 421 an RFC. 423 ISSUE #22 [12]: In which stream [RFC8729] are these documents 424 published? Is a new stream (e.g., the "Editorial Stream") needed? 426 3.2.3. Community Calls for Comment 428 When a community call for comment is made, the RSAB sends a notice 429 containing: 431 o A subject line beginning with 'Call for Comment:' 433 o A clear, concise summary of the proposal 435 o A URL for the proposal document 437 o Any commentary or questions for the community that the RSAB deems 438 necessary (using their usual decision-making procedures) 440 o Clear instructions on how to provide public comments 442 o A deadline for comments 444 Notices will always be sent to the rfc-interest mailing list. The 445 RSAB and RSWG should also send notices to other communities that may 446 be interested in or impacted by a proposal as they see fit, following 447 policies for those fora as appropriate. Notices are also to be made 448 available and archived on the rfc-editor.org web site, and other 449 communication channels can be established for notices (e.g., using an 450 RSS feed, social media). 452 A comment period will not last less than two weeks. Comments will be 453 publicly archived on the rfc-editor.org web site. 455 NOTE: This section is intended to address ISSUE #67 [13]. 457 3.2.4. Appeals 459 Appeals of RSWG decisions shall be made to the RSAB. Decisions of 460 the RSWG can only be appealed on grounds of failure to follow the 461 correct process. Appeals should be made within 30 days of any 462 action, or in the case of failure to act, of notice having been given 463 to the RSWG. The RSAB will then decide if the process was followed 464 and will direct RSWG chairs as to what procedural actions are 465 required. 467 Appeals of RSAB decisions shall be made to the IAB and should be made 468 within thirty (30) days of public notice of the relevant RSAB 469 decision (typically, when minutes are posted). The appeals body 470 shall decide whether a process failure occurred and what if any 471 corrective action should take place. 473 NOTE: This section is intended to address ISSUE #16 [14] and ISSUE 474 #36 [15]. 476 3.2.5. Anti-Harassment Policy 478 The IETF anti-harassment policy [16] also applies to the RSWG and 479 RSAB, which strive to create and maintain an environment in which 480 people of many different backgrounds are treated with dignity, 481 decency, and respect. Participants are expected to behave according 482 to professional standards and demonstrate appropriate workplace 483 behavior. See also [RFC7154], [RFC7776], and [RFC8716]. 485 4. RFC Series Editor/Advisor (RSEA) 487 NOTE: Discussion continues within the RFCED-Future Program regarding 488 the roles and responsibilities of an expert in technical publication 489 processes. To retain flexibility (e.g., as to whether this 490 individual plays more of an advisory role or more of a singular 491 leadership role), this document temporarily refers to the individual 492 as the "RFC Series Editor/Advisor" ("RSEA"). 494 The RFC Series Editor/Advisor (RSEA) is a senior technical publishing 495 professional who will apply their deep knowledge of technical 496 publishing processes to the RFC series. 498 The primary responsibilities of the RSEA are as follows: 500 o Serve as a voting member on the RSAB. 502 o Identify problems with the RFC publication process and 503 opportunities for improvement. 505 o Provide expert advice regarding policy proposals within the RSWG. 507 o If requested, provide expert advice to the RPC and IETF LLC. 509 Matters on which the RSEA might be consulted could include proposed 510 changes to the RFC style guide [RFC7322], RFC formatting in general, 511 web presence, copyright matters, archiving policy, and dissemination 512 and cataloguing of RFCs. 514 NOTE: This section is intended to address ISSUE #12 [17] and ISSUE 515 #24 [18]. 517 4.1. RSEA Selection 519 The RSEA will be selected by a search committee formed by the IETF 520 Executive Director, taking into account the role definition [19] as 521 well as other information that the committee deems necessary or 522 helpful in making its decision. 524 4.2. RSEA Performance Evaluation 526 Periodically, the IETF Executive Director will send out to the 527 community a call for input on the performance of the RSEA. The 528 evaluation will be based on criteria specified in the role 529 definition. Criteria could include matters such as the following: 531 o Was the RSEA an active participant in RSWG/RSAB discussions and 532 meetings? 534 o Did the RSEA provide useful advice to the RSWG and RPC? 536 o Did the RSEA exercise good judgment in RSAB decision making? 538 o Was the RSEA effective in advising the community on policy 539 direction? 541 The IETF Executive Director will review the feedback, consulting with 542 stream manager representatives, and then produce a recommendation to 543 the IETF LLC Board. The LLC will then make a decision, taking into 544 account the IETF Executive Director's recommendation. 546 Whether the RSEA role is structured as a contractual or employee 547 relationship is a matter for the IETF LLC and the IETF Executive 548 Director to determine. 550 5. Policy Implementation Function 552 5.1. Roles and Processes 554 Publication of RFCs shall be continue to be handled by the RFC 555 Production Center (RPC) function in accordance with high-level 556 policies currently in force or yet to be defined following the 557 processes specified in the foregoing sections of this document. 559 All matters of budget, timetable and impact on its performance 560 targets, are between the RPC and IETF LLC. 562 The RPC shall report regularly to the RSAB, RSWG, and broader 563 community regarding the contents and progress of its work program and 564 any key risks or issues affecting it. 566 In the event that the RPC is required to make a decision without 567 consultation that would normally deserve consultation, or makes a 568 decision against the advice of the RSAB, then it must notify the 569 RSAB. 571 This document does not specify the exact relationship between the 572 IETF LLC and the RPC function; for example, the RPC function could be 573 provided by a separate corporate entity under contract to the IETF 574 LLC, it could be performed by employees of the IETF LLC, or the IETF 575 LLC could work with independent contractors for some or all aspects 576 of the RPC function. The exact relationship is a matter for the IETF 577 LLC and the IETF Executive Director to determine. 579 The IETF LLC has authority over negotiating performance targets for 580 the RPC and also has responsibility for ensuring that those targets 581 are adhered to. The IETF LLC is empowered to appoint a manager or to 582 convene a committee to complete these activities. 584 Community members who have concerns about the performance of the RPC 585 can request that the IETF LLC look into the matter. Even if the IETF 586 LLC opts to delegate this activity, concerns should be raised with 587 the IETF LLC. The IETF LLC is ultimately responsible to the 588 community via the mechanisms outlined in its charter. 590 5.2. Editorial and Publication Policies 592 Under and consistent with the high-level policies defined for the RFC 593 Series in general or particular streams, the RPC shall define more 594 particular policies regarding matters related to the editorial 595 preparation and final publication and dissemination of RFCs. 596 Examples include: 598 o Maintenance of a styleguide that defines editorial standards to 599 which RFCs must adhere (see [RFC7322] and related updates). 601 o Policies regarding the file formats that are accepted as input to 602 the editing and publication process. 604 o Policies regarding the final structure and layout of published 605 documents; in the context of the XML vocabulary ([RFC7991]), such 606 policies could include matters such as the exact XML elements and 607 attributes used to capture the semantic content of RFCs. 609 5.3. Resolution of Disagreements between Authors and the RPC 611 NOTE: This section is intended to address ISSUE #59 [20] and ISSUE #6 612 [21]. 614 During the process of editorial preparation and publication, 615 disagreements can arise between the authors of an RFC-to-be and the 616 RPC. Where an existing policy clearly applies, typically such 617 disagreements are handled in a straightforward manner through direct 618 consultation between the authors and the RPC, sometimes in 619 collaboration with other individuals such as a document shepherd, 620 IETF working group chair, IRSG research group chair, or IETF Area 621 Director. 623 However, if it is unclear whether an existing policy applies, or if 624 the interpretation of an existing policy is unclear, the parties may 625 need to consult with additional individuals or bodies (e.g., RSAB, 626 IESG, IRSG, or stream manager) to help achieve a resolution. The 627 following points are intended to provide more particular guidance. 629 o If there is a conflict with a policy for a particular stream, the 630 RPC should consult with the relevant stream manager to help 631 achieve a resolution, if needed also conferring with a per-stream 632 body such as the IESG or IRSG. 634 o If there is a conflict with a cross-stream policy, the RPC should 635 consult with the RSAB to achieve a resolution. 637 o If the disagreement raises a new issue that is not covered by an 638 existing policy or that cannot be resolved through consultation 639 between the RPC and other relevant individuals and bodies as 640 described above), the issue should be brought to the RSWG in order 641 to formulate a new policy. However, in the interest of time the 642 disagreement may be resolved as the parties best see fit while the 643 RSWG formulates a more general policy. 645 5.4. Administrative Implementation 647 The exact implementation of the administrative and contractual 648 activities described here are a responsibility of the IETF LLC. 650 5.4.1. Vendor Selection for the RFC Production Center 652 Vendor selection is done in cooperation with the streams and under 653 the final authority of the IETF LLC. 655 The IETF LLC develops the work definition (the Statement of Work) for 656 the RPC and manages the vendor selection process. The work 657 definition is created within the IETF LLC budget and takes into 658 account the stream managers and community input. 660 The process to select and contract for an RFC Production Center and 661 other RFC-related services, is as follows: 663 o The IETF LLC establishes the contract process, including the steps 664 necessary to issue an RFP when necessary, the timing, and the 665 contracting procedures. 667 o The IETF LLC establishes the Selection Committee, which will 668 consist of the IETF Executive Director and other members selected 669 by the IETF LLC in consultation with the stream managers. The 670 Committee shall select a chair from among its members. 672 o The Selection Committee selects the vendor, subject to the 673 successful negotiation of a contract approved by the IETF LLC. In 674 the event that a contract cannot be reached, the matter shall be 675 referred to the Selection Committee for further action. 677 5.4.2. Budget 679 The expenses discussed in this document are not new expenses. They 680 have been and remain part of the IETF LLC budget. 682 The RFC Series portion of the IETF LLC budget shall include funding 683 to support the RSE/A, RFC Production Center, and the Independent 684 Stream. 686 The IETF LLC has the responsibility to approve the total RFC Editor 687 budget (and the authority to deny it). All relevant parties must 688 work within the IETF LLC budgetary process. 690 6. Streams 692 NOTE: This section is intended to address ISSUE #22 [22]. 694 6.1. Editorial Stream 696 This document creates the Editorial Stream. 698 Any and all future documents produced by the RSWG and approved by the 699 RSAB shall be published in the Editorial Stream. 701 6.2. Creating and Deleting Streams 703 Creation and deletion of streams within the RFC Series shall be 704 accomplished within the Editorial Stream: proposals for such changes 705 shall be made in the RSWG and, if approved by the RSAB, such changes 706 shall be documented in RFCs published within the Editorial Stream. 708 7. IANA Considerations 710 This document defines several functions within the overall RFC Editor 711 structure, and it places the responsibility for coordination of 712 registry value assignments with the RFC Production Center. The IETF 713 LLC will facilitate the establishment of the relationship between the 714 RFC Production Center and IANA. 716 This document does not create a new registry nor does it register any 717 values in existing registries, and no IANA action is required. 719 8. Security Considerations 721 The same security considerations as those in [RFC8729] apply. The 722 processes for the publication of documents must prevent the 723 introduction of unapproved changes. Since the RFC Editor maintains 724 the index of publications, sufficient security must be in place to 725 prevent these published documents from being changed by external 726 parties. The archive of RFC documents, any source documents needed 727 to recreate the RFC documents, and any associated original documents 728 (such as lists of errata, tools, and, for some early items, originals 729 that are not machine readable) need to be secured against any kind of 730 data storage failure. 732 The IETF LLC should take these security considerations into account 733 during the implementation and enforcement of the RFC Editor component 734 contracts. 736 9. Changes from Version 2 of the RFC Editor Model 738 9.1. RFC Series Editor 740 The RSWG and RSAB together provide a public process by which policies 741 for the RFC series can be defined. It is expected that these bodies 742 will therefore cover some of the responsibilities of the RFC Series 743 Editor under Version 2. 745 9.2. RFC Series Oversight Committee (RSOC) 747 In practice, the relationships and lines of authority and 748 responsibility between the IAB, RSOC, and RSE have proved unwieldy 749 and somewhat opaque. To overcome some of these issues, this document 750 dispenses with the RSOC. 752 10. IANA Considerations 754 This document has no actions for IANA. 756 11. References 758 11.1. Informative References 760 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 761 Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, 762 September 1998, . 764 [RFC3777] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, 765 and Recall Process: Operation of the Nominating and Recall 766 Committees", RFC 3777, DOI 10.17487/RFC3777, June 2004, 767 . 769 [RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights 770 Contributors Provide to the IETF Trust", BCP 78, RFC 5378, 771 DOI 10.17487/RFC5378, November 2008, 772 . 774 [RFC5620] Kolkman, O., Ed. and IAB, "RFC Editor Model (Version 1)", 775 RFC 5620, DOI 10.17487/RFC5620, August 2009, 776 . 778 [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor 779 Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June 780 2012, . 782 [RFC7154] Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54, 783 RFC 7154, DOI 10.17487/RFC7154, March 2014, 784 . 786 [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", 787 RFC 7282, DOI 10.17487/RFC7282, June 2014, 788 . 790 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 791 DOI 10.17487/RFC7322, September 2014, 792 . 794 [RFC7776] Resnick, P. and A. Farrel, "IETF Anti-Harassment 795 Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, March 796 2016, . 798 [RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", 799 RFC 7991, DOI 10.17487/RFC7991, December 2016, 800 . 802 [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property 803 Rights in IETF Technology", BCP 79, RFC 8179, 804 DOI 10.17487/RFC8179, May 2017, 805 . 807 [RFC8700] Flanagan, H., Ed., "Fifty Years of RFCs", RFC 8700, 808 DOI 10.17487/RFC8700, December 2019, 809 . 811 [RFC8711] Haberman, B., Hall, J., and J. Livingood, "Structure of 812 the IETF Administrative Support Activity, Version 2.0", 813 BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020, 814 . 816 [RFC8716] Resnick, P. and A. Farrel, "Update to the IETF Anti- 817 Harassment Procedures for the Replacement of the IETF 818 Administrative Oversight Committee (IAOC) with the IETF 819 Administration LLC", BCP 25, RFC 8716, 820 DOI 10.17487/RFC8716, February 2020, 821 . 823 [RFC8728] Kolkman, O., Ed., Halpern, J., Ed., and R. Hinden, Ed., 824 "RFC Editor Model (Version 2)", RFC 8728, 825 DOI 10.17487/RFC8728, February 2020, 826 . 828 [RFC8729] Housley, R., Ed. and L. Daigle, Ed., "The RFC Series and 829 RFC Editor", RFC 8729, DOI 10.17487/RFC8729, February 830 2020, . 832 [RFC8730] Brownlee, N., Ed. and B. Hinden, Ed., "Independent 833 Submission Editor Model", RFC 8730, DOI 10.17487/RFC8730, 834 February 2020, . 836 [RFC8874] Thomson, M. and B. Stark, "Working Group GitHub Usage 837 Guidance", RFC 8874, DOI 10.17487/RFC8874, August 2020, 838 . 840 11.2. URIs 842 [1] https://github.com/intarchboard/program-rfced-future/issues/9 844 [2] https://github.com/intarchboard/program-rfced-future/issues/14 846 [3] https://github.com/intarchboard/program-rfced-future/issues/16 848 [4] https://github.com/intarchboard/program-rfced-future/issues/41 850 [5] https://github.com/intarchboard/program-rfced-future/issues/44 852 [6] https://github.com/intarchboard/program-rfced-future/issues/68 854 [7] https://github.com/intarchboard/program-rfced-future/issues/72 856 [8] https://github.com/intarchboard/program-rfced-future/issues/9 858 [9] https://github.com/intarchboard/program-rfced-future/issues/38 860 [10] https://github.com/intarchboard/program-rfced-future/issues/50 862 [11] https://github.com/intarchboard/program-rfced-future/issues/53 864 [12] https://github.com/intarchboard/program-rfced-future/issues/22 866 [13] https://github.com/intarchboard/program-rfced-future/issues/67 868 [14] https://github.com/intarchboard/program-rfced-future/issues/16 870 [15] https://github.com/intarchboard/program-rfced-future/issues/36 872 [16] https://www.ietf.org/about/groups/iesg/statements/anti- 873 harassment-policy/ 875 [17] https://github.com/intarchboard/program-rfced-future/issues/12 877 [18] https://github.com/intarchboard/program-rfced-future/issues/24 879 [19] https://github.com/intarchboard/program-rfced- 880 future/blob/master/Issue12-RSE-role.md 882 [20] https://github.com/intarchboard/program-rfced-future/issues/59 884 [21] https://github.com/intarchboard/program-rfced-future/issues/6 886 [22] https://github.com/intarchboard/program-rfced-future/issues/22 888 Acknowledgments 890 Portions of this document were borrowed from [RFC5620], [RFC6635], 891 [RFC8728], and earlier proposals within the RFCED-Future Program by 892 Martin Thomson, Brian Carpenter, and Michael StJohns. Thanks to the 893 chairs of the Program, Eliot Lear and Brian Rosen, for their 894 leadership and assistance. Thanks also for feedback and proposed 895 text and feedback to Jari Arkko, Sarah Banks, Scott Bradner, Carsten 896 Bormann, Nevil Brownlee, Ben Campbell, Jay Daley, Martin Duerst, Lars 897 Eggert, Adrian Farrel, Stephen Farrell, Sandy Ginoza, Bron Gondwana, 898 Joel Halpern, Wes Hardaker, Bob Hinden, Russ Housley, Christian 899 Huitema, John Klensin, Mirja Kuehlewind, Ted Lemon, John Levine, Lucy 900 Lynch, Andrew Malis, Larry Masinter, S. Moonesamy, Mark Nottingham, 901 Tommy Pauly, Colin Perkins, Julian Reschke, Eric Rescorla, Adam 902 Roach, Alice Russo, Doug Royer, Rich Salz, Tim Wicinski, and Nico 903 Williams. 905 Author's Address 907 Peter Saint-Andre (editor) 908 Mozilla 910 Email: stpeter@jabber.org