idnits 2.17.1 draft-iab-rfcefdp-rfced-model-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The '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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- 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 (September 21, 2021) is 948 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 963 -- Looks like a reference, but probably isn't: '2' on line 965 -- Looks like a reference, but probably isn't: '3' on line 967 -- Looks like a reference, but probably isn't: '4' on line 969 -- Looks like a reference, but probably isn't: '5' on line 971 -- Looks like a reference, but probably isn't: '6' on line 973 -- Looks like a reference, but probably isn't: '7' on line 975 -- Looks like a reference, but probably isn't: '8' on line 977 -- Looks like a reference, but probably isn't: '9' on line 979 -- Looks like a reference, but probably isn't: '10' on line 981 -- Looks like a reference, but probably isn't: '11' on line 983 -- Looks like a reference, but probably isn't: '12' on line 985 -- Looks like a reference, but probably isn't: '13' on line 987 -- Looks like a reference, but probably isn't: '14' on line 989 -- Looks like a reference, but probably isn't: '15' on line 991 -- Looks like a reference, but probably isn't: '16' on line 993 -- Looks like a reference, but probably isn't: '17' on line 995 -- Looks like a reference, but probably isn't: '18' on line 997 -- Looks like a reference, but probably isn't: '19' on line 999 -- Looks like a reference, but probably isn't: '20' on line 1001 -- Looks like a reference, but probably isn't: '21' on line 1003 -- Looks like a reference, but probably isn't: '22' on line 1005 -- Looks like a reference, but probably isn't: '23' on line 1007 -- Looks like a reference, but probably isn't: '24' on line 1010 -- Looks like a reference, but probably isn't: '25' on line 1012 -- Looks like a reference, but probably isn't: '26' on line 1014 -- Looks like a reference, but probably isn't: '27' on line 1016 -- Looks like a reference, but probably isn't: '28' on line 1018 -- Looks like a reference, but probably isn't: '29' on line 1020 -- Looks like a reference, but probably isn't: '30' on line 1022 -- Looks like a reference, but probably isn't: '31' on line 1024 -- Looks like a reference, but probably isn't: '32' on line 1026 -- Looks like a reference, but probably isn't: '33' on line 1028 -- Looks like a reference, but probably isn't: '34' on line 1030 -- Looks like a reference, but probably isn't: '35' on line 1032 -- Looks like a reference, but probably isn't: '36' on line 1035 -- Looks like a reference, but probably isn't: '37' on line 1037 -- Looks like a reference, but probably isn't: '38' on line 1039 -- Looks like a reference, but probably isn't: '39' on line 1041 == Unused Reference: 'RFC3777' is defined on line 880, but no explicit reference was found in the text -- 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 (~~), 4 warnings (==), 46 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) September 21, 2021 5 Updates: RFC7841, RFC8729 (if approved) 6 Intended status: Informational 7 Expires: March 25, 2022 9 RFC Series Policy Definition and Implementation 10 draft-iab-rfcefdp-rfced-model-03 12 Abstract 14 This document describes updated processes for defining and 15 implementing policies regarding the RFC Series as a whole and thus 16 specifies version 3 of RFC Editor Model. As specified here, the 17 model divides the responsibilities for the RFC Series into two high- 18 level tasks. Policy definition is the responsibility of the RFC 19 Series Working Group (RSWG), which produces policy proposals that are 20 subject to approval by the RFC Series Approval Board (RSAB). Policy 21 implementation is primarily the responsibility of the RFC Production 22 Center (RPC), under the ultimate authority of the IETF Administration 23 Limited Liability Company (IETF LLC). 25 This document obsoletes RFC 8728. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 25, 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Overview of the Model . . . . . . . . . . . . . . . . . . . . 4 63 3. Policy Definition . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. Structure and Roles . . . . . . . . . . . . . . . . . . . 5 65 3.1.1. RFC Series Working Group (RSWG) . . . . . . . . . . . 5 66 3.1.2. RFC Series Approval Board (RSAB) . . . . . . . . . . 6 67 3.2. Process . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 3.2.1. Intent . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.2.2. Workflow . . . . . . . . . . . . . . . . . . . . . . 9 70 3.2.3. Community Calls for Comment . . . . . . . . . . . . . 11 71 3.2.4. Appeals . . . . . . . . . . . . . . . . . . . . . . . 11 72 3.2.5. Anti-Harassment Policy . . . . . . . . . . . . . . . 12 73 4. Policy Implementation . . . . . . . . . . . . . . . . . . . . 12 74 4.1. Roles and Processes . . . . . . . . . . . . . . . . . . . 12 75 4.2. Implementation-Specific Policies . . . . . . . . . . . . 13 76 4.3. RPC Responsibilities . . . . . . . . . . . . . . . . . . 13 77 4.4. Resolution of Disagreements between Authors and the RPC . 15 78 4.5. Administrative Implementation . . . . . . . . . . . . . . 15 79 4.5.1. Vendor Selection for the RFC Production Center . . . 16 80 4.5.2. Budget . . . . . . . . . . . . . . . . . . . . . . . 16 81 5. RFC Series Consulting Editor (RSCE) . . . . . . . . . . . . . 16 82 5.1. RSCE Selection . . . . . . . . . . . . . . . . . . . . . 17 83 5.2. RSCE Performance Evaluation . . . . . . . . . . . . . . . 18 84 6. Editorial Stream . . . . . . . . . . . . . . . . . . . . . . 18 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 9.1. Informative References . . . . . . . . . . . . . . . . . 19 89 9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 Appendix A. Updates to RFC 7841 . . . . . . . . . . . . . . . . 22 91 A.1. First Paragraph . . . . . . . . . . . . . . . . . . . . . 23 92 A.2. Second Paragraph . . . . . . . . . . . . . . . . . . . . 23 93 A.3. Third Paragraph . . . . . . . . . . . . . . . . . . . . . 23 94 Appendix B. Changes from RFC 8728 . . . . . . . . . . . . . . . 23 95 B.1. RFC Series Editor . . . . . . . . . . . . . . . . . . . . 23 96 B.2. RFC Publisher . . . . . . . . . . . . . . . . . . . . . . 23 97 B.3. RFC Series Oversight Committee (RSOC) . . . . . . . . . . 24 98 Appendix C. Updates to RFC 8729 . . . . . . . . . . . . . . . . 24 99 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 102 1. Introduction 104 The Request for Comments (RFC) Series is the archival series 105 dedicated to documenting Internet technical specifications, including 106 general contributions from the Internet research and engineering 107 community as well as standards documents. As described in [RFC8700], 108 RFCs have been published continually since 1969. The overall 109 framework for the RFC Series and the RFC Editor function are 110 described in [RFC8729] and updated here. 112 The processes and organizational models for publication of RFCs have 113 changed significantly over the years. Most recently, in 2009 114 [RFC5620] defined the RFC Editor Model (Version 1) and in 2012 115 [RFC6635] defined the RFC Editor Model (Version 2), since modified 116 slightly in 2020 by [RFC8728]. 118 This document reflects experience gained with version 1 and version 2 119 of the Model, and therefore describes version 3 of the Model (see 120 Section 7 for a summary of the changes) while remaining consistent 121 with [RFC8729]. 123 More specifically, in order to ensure sustainable maintenance and 124 support of the RFC series based on the principles of expert 125 implementation, clear management and direction, and appropriate 126 community input [RFC8729], this document divides the responsibilities 127 for the RFC Series into two high-level tasks: 129 1. Policy definition governing the Series as a whole. This is the 130 responsibility of the RFC Series Working Group (RSWG), which 131 produces policy proposals that are subject to approval by the RFC 132 Series Approval Board (RSAB). 134 2. Policy implementation through publication of documents in the 135 Series. This is primarily the responsibility of the RFC 136 Production Center (RPC), under the ultimate authority of the IETF 137 Administration Limited Liability Company (LLC) [RFC8711]. 139 This document obsoletes RFC 8728. 141 2. Overview of the Model 143 Version 2 of the RFC Editor Model [RFC8728] specified a structure 144 consisting of the RFC Series Editor, the RFC Production Center, and 145 the RFC Publisher, with oversight provided by the RFC Series 146 Oversight Committee (RSOC) on behalf of the Internet Architecture 147 Board (IAB). 149 Discussion within the RFCED-Future Program has led in the direction 150 of a more consensus-oriented framework (similar in some respects to 151 the structure of technical work within the IETF or IRTF) that retains 152 roles for specialized expertise in document editing and publication. 154 Policy definition happens within the RFC Series Working Group (RSWG), 155 which produces policy proposals that are subject to approval by the 156 RFC Series Approval Board (RSAB), after which such policies are 157 formally established through publication in the Editorial Stream 158 within the RFC Series. The RSWG is an open working group (as 159 described below) that seeks input and participation through a public 160 process from a wide range of persons who have an interest in the RFC 161 Series. The RSAB consists of appointed members who represent the 162 various RFC streams [RFC8728] as well as an expert in technical 163 publishing, the RFC Series Consulting Editor (RSCE). 165 Policy implementation is performed by the RFC Production Center 166 (RPC), under the ultimate authority of the IETF Administration 167 Limited Liability Company (IETF LLC). 169 In short: 171 o The RSWG proposes policies that govern the RFC Series as a whole, 172 with input from the community, the RSAB, and the RSCE. 174 o The RSAB considers those proposals and approves them, returns them 175 to the RSWG for further consideration, or declines to publish 176 them, as appropriate. 178 o If approved, such proposals are published as RFCs in the Editorial 179 Stream and thus define the policies to be followed by the RSWG, 180 RSAB, RSCE, and RPC. 182 o The RSCE provides expert advice to the RPC and RSAB on how to 183 implement established policies on an ongoing and operational 184 basis, which can include raising issues or initiating proposed 185 policy changes within the RSWG. 187 o The RPC implements the policies defined by the Editorial Stream in 188 its day-to-day editing and publication of RFCs from other streams. 190 o If issues arise with the implementation of particular policies, 191 the RPC brings those issues to the RSAB, which interprets the 192 policies and provides interim guidance to the RPC, informing the 193 RSWG of those interpretations. 195 This model is designed to ensure public processes and definition 196 documents, clear responsibilities and mechanisms for updates and 197 changes to policies governing the RFC Series as a whole, and 198 operational implementation of the RFC Series, thus meeting the 199 requirements specified in Section 4 of [RFC8729]. 201 The remainder of this document describes the model in greater detail. 203 3. Policy Definition 205 Policies governing the RFC series as a whole are defined in the open 206 through proposals that are generated by and discussed within the RFC 207 Series Working Group (RSWG) and then approved by the RFC Series 208 Approval Board (RSAB). 210 Policies under the purview of the RSWG and RSAB might include but are 211 not necessarily limited to document formats, processes for 212 publication and dissemination of RFCs, and overall management of the 213 RFC series. 215 3.1. Structure and Roles 217 3.1.1. RFC Series Working Group (RSWG) 219 NOTE: There is discussion within the RFCED-Future Program regarding 220 the appropriate name for this entity; provisionally "RFC Series 221 Working Group" (RSWG) is used here, but the name might change in 222 future versions of this document. 224 The RFC Series Working Group (RSWG) shall formulate proposals 225 regarding policies that govern the RFC series. The intent is that 226 the RSWG operate in a way similar to working groups in the IETF and 227 research groups in the IRTF. Therefore, all RSWG meetings shall be 228 open to any participant, and all RSWG contributions shall be subject 229 to intellectual property policies, which must be consistent with 230 those of the IETF as specified in BCP 78 [RFC5378] and BCP 79 231 [RFC8179]. 233 The RSWG shall operate by rough consensus, a mode of operation 234 informally described in [RFC7282]. 236 When the RSWG is formed, all discussions shall take place on an open 237 email discussion list. Subsequently, the RSWG may decide by rough 238 consensus to also use additional tooling (e.g., GitHub as specified 239 in [RFC8874]), forms of communication (e.g., in-person or online 240 meetings), and working methods (e.g., design teams) as long as they 241 are consistent with [RFC2418]. 243 All interested persons are welcome to participate in the RSWG 244 (subject to anti-harassment policies as described below). This 245 includes participants in the IETF and IRTF, IAB and IESG members, 246 individuals who use RFCs in procurement decisions, authors of RFCs 247 and Internet-Drafts, developers of tools used to authors RFCs, and 248 the like. The IETF LLC Board members, staff, and the IETF Executive 249 Director are invited to participate as community members in the RSWG 250 to the extent permitted by any relevant IETF LLC policies. Members 251 of the RSAB are also expected to participate actively. 253 The RSWG shall have two chairs, one appointed by the IESG and the 254 other appointed by the IAB. When the RSWG is formed, the chair 255 appointed by the IESG shall serve for a term of one (1) year and the 256 chair appointed by the IAB shall serve for a term of two (2) years; 257 thereafter, chairs shall serve for a term of two (2) years, with no 258 term limits on renewal. The appointing bodies shall determine their 259 own processes for making these appointments, such as provision for an 260 open nominations period. Community members who have concerns about 261 the performance of an RSWG chair should direct their feedback to the 262 relevant appointing body. Each appointing body shall have the power 263 to replace its appointed chair at its discretion at any time, with 264 the replacement serving the remainder of the original chair's term. 266 It is the responsibility of the chairs to encourage rough consensus 267 within the RSWG and to follow that consensus in their decision 268 making, for instance regarding acceptance of new proposals and 269 advancement of proposals to the RSAB. 271 Absent specific guidance in this document regarding the roles and 272 responsibilities of the chairs, the general guidance provided in 273 Section 6.1 of [RFC2418] should be considered appropriate. 275 NOTE: This section is intended to address ISSUE #9 [1], ISSUE #14 276 [2], ISSUE #16 [3], ISSUE #28 [4], ISSUE #29 [5], ISSUE #41 [6], 277 ISSUE #44 [7], ISSUE #55 [8], ISSUE #68 [9], ISSUE #72 [10], and 278 ISSUE #80 [11]. 280 3.1.2. RFC Series Approval Board (RSAB) 282 The RFC Series Approval Board (RSAB) shall act as the approving body 283 for proposals generated within the RSWG. The only policy-making role 284 of the RSAB is to review policy proposals generated by the RSWG; it 285 shall have no independent authority to formulate policy on its own. 287 It is expected that the RSAB will respect the rough consensus of the 288 RSWG wherever possible, without ceding its review function. 290 The voting members of the RSAB shall be as follows: 292 o One delegate representing the IETF stream, appointed by the IESG 294 o One delegate representing the IAB stream, appointed by the IAB 296 o One delegate representing the IRTF stream, appointed by the IRTF 297 Chair 299 o The Independent Submissions Editor [RFC8730] 301 o The RFC Series Consulting Editor 303 For the avoidance of doubt, the RSAB shall continue to operate in the 304 case of any vacancies; however, such vacancies should be filled with 305 all due speed. 307 The appointing bodies shall determine their own processes for 308 appointing delegates, such as provision for an open nominations 309 period. If it becomes necessary to replace such a delegate for any 310 reason, then for the sake of continuity the appointing body should 311 name a new delegate to complete the former delegate's term. 313 To ensure the smooth functioning of the RFC Series, the RSAB shall 314 include the IETF Executive Director as a non-voting member since the 315 IETF LLC is ultimately responsible for implementation of policies 316 governing the RFC Series. The RSAB may at its discretion include 317 additional non-voting members, for instance a liaison from the RPC. 319 Whenever a new stream is created, the document that creates the 320 stream shall specify if a voting member representing that stream 321 shall also be added to the RSAB, along with any rules and processes 322 related to that representative (e.g., whether the representative is a 323 member of the body responsible for the stream or an appointed 324 delegate thereof). In effect, the RSCE is the voting member 325 representing the Editorial Stream. 327 The RSAB shall annually choose a chair from among its members using a 328 method to be determined by the RSAB. If the chair position is 329 vacated during the chair's term, the RSAB should choose a new chair 330 from among its members. 332 The RSAB is expected to operate via email, in-person meetings, 333 teleconferencing systems, and any additional tooling it deems 334 necessary. 336 The RSAB shall keep a public record of its proceedings, including 337 minutes of all meetings and a record of all decisions. 339 The RSAB shall announce plans and agendas for their meetings on the 340 RFC Editor website and by email to the RSWG at least a week before 341 such meetings. The meetings shall be open for public attendance and 342 the RSAB may consider allowing open participation. If the RSAB needs 343 to discuss a confidential matter in executive session, that part of 344 the meeting shall be private to the RSAB, but must be noted on the 345 agenda, and must be documented in the minutes with as much detail as 346 confidentiality requirements permit. 348 NOTE: This section is intended to address ISSUE #9 [12], ISSUE #38 349 [13], ISSUE #50 [14], ISSUE #53 [15], ISSUE #71 [16], and ISSUE #82 350 [17]. 352 3.2. Process 354 3.2.1. Intent 356 The intent is to provide an open forum by which policies related to 357 the RFC series are defined and evolved. The general expectation is 358 that all interested parties will participate in the RSWG, and that 359 only under extreme circumstances should RSAB members need to hold 360 "CONCERN" positions as described below. 362 Because policy issues can be difficult and contentious, RSWG 363 participants and RSAB members are strongly encouraged to work 364 together in a spirit of good faith and mutual understanding to 365 achieve rough consensus (see [RFC7282]). In particular, RSWG members 366 are encouraged to take RSAB concerns seriously, and RSAB members are 367 encouraged to clearly express their concerns early in the process and 368 to be responsive to the community. All parties are encouraged to 369 respect the value of each stream and the long-term health and 370 viability of the RFC series. 372 This process is intended to be one of continuous consultation. RSAB 373 members should consult with their constituent stakeholders (e.g., 374 authors, editors, tool developers, and consumers of RFCs) on an 375 ongoing basis, so that when the time comes to consider a proposal, 376 there should be no surprises. Appointing bodies are expected to 377 establish whatever processes they deem appropriate to facilitate this 378 goal. 380 3.2.2. Workflow 382 The following process shall be used to formulate or modify processes 383 related to the RFC series: 385 1. An individual participant in the RSWG generates a proposal in the 386 form of an Internet-Draft, which is submitted in full conformance 387 with the provisions of BCP 78 [RFC5378] and BCP 79 [RFC8179]. 389 2. If (following procedures for rough consensus) the chairs 390 determine that there is sufficient interest in the proposal, the 391 RSWG may adopt the proposal as a draft proposal of the RSWG, in 392 much the same way a working group of the IETF or research group 393 of the IRTF would (see [RFC2418]). 395 3. The RSWG shall then further develop the proposal. Members of the 396 RSAB are expected to participate in discussion relating to such 397 proposals so that they are fully aware of proposals early in the 398 policy definition process and so that any issues or concerns that 399 they have will be raised during the development of the proposal 400 (not be left until the RSAB review period). The RSWG chairs are 401 also expected to participate as individuals. 403 4. At some point, if the RSWG chairs believe there may be rough 404 consensus for the proposal to advance, they will issue a last 405 call for comment within the working group. 407 5. After a comment period of suitable length, the RSWG chairs will 408 determine whether rough consensus for the proposal exists (taking 409 their own feedback as individuals into account along with 410 feedback from other participants). If comments have been 411 received and substantial changes have been made, additional last 412 calls may be necessary. 414 6. Once consensus is established in the RSWG, the RSAB shall issue a 415 community call for comments as further described below. If 416 substantial comments have been received, the RSWG will again 417 consider those comments and make revisions as they see fit. At 418 this same time, the RSAB will also consider the proposal. 420 7. If substantial changes have been made, additional community calls 421 for comment should be issued by the RSAB, and again comments 422 considered by the RSWG. 424 8. Once all comments have been addressed, the RSWG chairs will 425 submit the proposal to the RSAB for its consideration. 427 9. Within a reasonable period of time, the RSAB will then poll among 428 its members regarding the proposal. Positions may be as follows: 430 * "YES": the proposal should be approved 432 * "CONCERN": the proposal raises substantial concerns that must 433 be addressed 435 * "RECUSE": the person holding the position has a conflict of 436 interest 438 Any RSAB member holding a "CONCERN" position must explain their 439 concern to the community in detail. The explanation might or might 440 not be actionable. 442 A CONCERN may be made for two reasons: 444 o The proposal represents a serious problem for the stream or group 445 that a particular member represents. 447 o The RSAB member believes that the proposal would cause serious 448 harm to the overall series, including harm to the long term health 449 and viability of the series. 451 Because RSAB members should have been participating in discussions 452 within the RSWG, no position of CONCERN should ever come as a 453 surprise to the RSWG. 455 1. If a CONCERN exists, discussion will take place within the RSWG. 456 Again, all RSAB members are expected to participate. 458 2. A proposal without any CONCERN positions is approved. If 459 substantial changes have been made in order to address CONCERN 460 positions, an additional call for community input might be 461 needed. 463 3. If, after a suitable period of time, any CONCERN positions 464 remain, a formal vote of the RSAB is taken. If a majority of 465 RSAB members vote to approve, the proposal is approved. 466 Otherwise, it is returned to the RSWG. In the case of a tie, the 467 proposal is approved. 469 4. When a proposal is approved, a notification is sent to the 470 community, and the document enters the queue for publication as 471 an RFC within the Editorial Stream. 473 NOTE: This section is intended to address ISSUE #45 [18] and ISSUE 474 #69 [19]. 476 3.2.3. Community Calls for Comment 478 When a community call for comment is made, the RSAB sends a notice 479 containing: 481 o A subject line beginning with 'Call for Comment:' 483 o A clear, concise summary of the proposal 485 o A URL for the proposal document 487 o Any commentary or questions for the community that the RSAB deems 488 necessary (using their usual decision-making procedures) 490 o Clear instructions on how to provide public comments 492 o A deadline for comments 494 Notices will always be sent to the rfc-interest mailing list. The 495 RSAB and RSWG should also send notices to other communities that may 496 be interested in or impacted by a proposal as they see fit, following 497 policies for those communities as appropriate. Notices are also to 498 be made available and archived on the rfc-editor.org web site. In 499 addition, other communication channels can be established for notices 500 (e.g., using an RSS feed or social media). 502 A comment period will not last less than two weeks. Comments will be 503 publicly archived on the rfc-editor.org web site. 505 NOTE: This section is intended to address ISSUE #67 [20]. 507 3.2.4. Appeals 509 Appeals of RSWG decisions shall be made to the RSAB. Decisions of 510 the RSWG can be appealed only on grounds of failure to follow the 511 correct process. Appeals should be made within 30 days of any 512 action, or in the case of failure to act, of notice having been given 513 to the RSWG. The RSAB will then decide if the process was followed 514 and will direct the RSWG chairs as to what procedural actions are 515 required. 517 Appeals of RSAB decisions shall be made to the IAB and should be made 518 within thirty (30) days of public notice of the relevant RSAB 519 decision (typically, when minutes are posted). The IAB shall decide 520 whether a process failure occurred and what if any corrective action 521 should take place. 523 NOTE: This section is intended to address ISSUE #16 [21] and ISSUE 524 #36 [22]. 526 3.2.5. Anti-Harassment Policy 528 The IETF anti-harassment policy [23] also applies to the RSWG and 529 RSAB, which strive to create and maintain an environment in which 530 people of many different backgrounds are treated with dignity, 531 decency, and respect. Participants are expected to behave according 532 to professional standards and to demonstrate appropriate workplace 533 behavior. See also [RFC7154], [RFC7776], and [RFC8716]. 535 4. Policy Implementation 537 4.1. Roles and Processes 539 Publication of RFCs shall is handled by the RFC Production Center 540 (RPC). 542 A few general considerations apply: 544 o The general roles and responsibilities of the RPC are defined by 545 RFCs published in the Editorial Stream (i.e., not directly by the 546 RSWG, RSAB, or RSCE). 548 o The RPC is advised by the RSCE and RSAB, and has a duty to consult 549 with them under specific circumstances, such as those relating to 550 disagreements between authors and the RPC. 552 o The RPC is contractually overseen by the IETF LLC to ensure that 553 it performs in accordance with contracts in place. 555 All matters of budget, timetable, and impact on its performance 556 targets, are between the RPC and IETF LLC. 558 The RPC shall report regularly to the IETF LLC, RSAB, RSWG, and 559 broader community regarding its activities and any key risks or 560 issues affecting it. 562 In the event that the RPC is required to make a decision without 563 consultation that would normally deserve consultation, or makes a 564 decision against the advice of the RSAB, the RPC must notify the 565 RSAB. 567 This document does not specify the exact relationship between the 568 IETF LLC and the RPC; for example, the work of the RPC could be 569 performed by a separate corporate entity under contract to the IETF 570 LLC, it could be performed by employees of the IETF LLC, or the IETF 571 LLC could engage with independent contractors for some or all aspects 572 of such work. The exact relationship is a matter for the IETF LLC to 573 determine. 575 The IETF LLC is responsible for the method of and management of the 576 engagement of the RPC. Therefore, the IETF LLC has authority over 577 negotiating performance targets for the RPC and also has 578 responsibility for ensuring that those targets are adhered to. The 579 IETF LLC is empowered to appoint a manager or to convene a committee 580 to complete these activities. 582 If individuals or groups within the community have concerns about the 583 performance of the RPC, they can request that the IETF LLC look into 584 the matter. Even if the IETF LLC opts to delegate this activity, 585 concerns should be raised with the IETF LLC. The IETF LLC is 586 ultimately responsible to the community via the mechanisms outlined 587 in its charter. 589 4.2. Implementation-Specific Policies 591 Under and consistent with the high-level policies defined for the RFC 592 Series in general or particular streams, the RPC shall define more 593 particular policies regarding matters related to the editorial 594 preparation and final publication and dissemination of RFCs. 595 Examples include: 597 o Maintenance of a style guide that defines editorial standards to 598 which RFCs must adhere (see [RFC7322] and the style guide web page 599 [24]). 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. More 608 generally, such policies could address the readability and 609 presentation of information in RFCs. 611 4.3. RPC Responsibilities 613 RPC responsibilities include the following: 615 1. Editing inputs from all RFC streams to comply with the RFC Style 616 Guide. 618 2. Creating and preserving records of edits performed on documents. 620 3. Identifying where editorial changes might have technical impact 621 and seeking necessary clarification. 623 4. Engaging in dialogue with authors, document shepherds, IANA, or 624 stream-specific contacts when clarification is needed. 626 5. Creating and preserving records of dialogue with document 627 authors. 629 6. Requesting advice from the RSAB and RSCE as needed. 631 7. Providing suggestions to the RSAB and RSCE as needed. 633 8. Participating in the creation of new Editorial Stream RFCs that 634 impact the RPC, at least in an advisory capacity. 636 9. Providing reports to the community on its performance and plans. 638 10. Consulting with the community on its plans. 640 11. Negotiating its specific plans and resources with the IETF LLC. 642 12. Providing sufficient resources to support reviews of RPC 643 performance by the IETF LLC. 645 13. Coordinating with IANA to ensure correct documentation of IANA- 646 performed protocol registry actions. 648 14. Assigning RFC numbers. 650 15. Establishing publication readiness of each document through 651 communication with the authors, document shepherds, IANA, or 652 stream-specific contacts, and, if needed, with the RSAB and 653 RSCE. 655 16. Liaising with stream managers and other representatives of the 656 streams as needed. 658 17. Announcing and providing on-line access to RFCs. 660 18. Providing an on-line system to submit RFC Errata. 662 19. Providing on-line access to approved RFC Errata. 664 20. Providing backups. 666 21. Providing storage and preservation of records. 668 22. Authenticating RFCs for legal proceedings. 670 4.4. Resolution of Disagreements between Authors and the RPC 672 During the process of editorial preparation and publication, 673 disagreements can arise between the authors of an RFC-to-be and the 674 RPC. Where an existing policy clearly applies, typically such 675 disagreements are handled in a straightforward manner through direct 676 consultation between the authors and the RPC, sometimes in 677 collaboration with other individuals such as a document shepherd, 678 IETF working group chair, IRSG research group chair, or IETF Area 679 Director. 681 However, if it is unclear whether an existing policy applies, or if 682 the interpretation of an existing policy is unclear, the parties may 683 need to consult with additional individuals or bodies (e.g., RSAB, 684 IESG, IRSG, or stream manager) to help achieve a resolution. The 685 following points are intended to provide more particular guidance. 687 o If there is a conflict with a policy for a particular stream, the 688 RPC should consult with the relevant stream manager to help 689 achieve a resolution, if needed also conferring with a per-stream 690 body such as the IESG or IRSG. 692 o If there is a conflict with a cross-stream policy, the RPC should 693 consult with the RSAB to achieve a resolution. 695 o If the disagreement raises a new issue that is not covered by an 696 existing policy or that cannot be resolved through consultation 697 between the RPC and other relevant individuals and bodies (as 698 described above), the issue should be brought to the RSWG in order 699 to formulate a new policy. However, in the interest of time the 700 disagreement may be resolved as the parties best see fit while the 701 RSWG formulates a more general policy. 703 NOTE: This section is intended to address ISSUE #6 [25] and ISSUE #59 704 [26]. 706 4.5. Administrative Implementation 708 The exact implementation of the administrative and contractual 709 activities described here are a responsibility of the IETF LLC. This 710 section provides general guidance regarding several aspects of such 711 activities. 713 NOTE: This section is intended to address ISSUE #25 [27], ISSUE #57 714 [28], ISSUE #61 [29], ISSUE #62 [30], and ISSUE #63 [31], 716 4.5.1. Vendor Selection for the RFC Production Center 718 Vendor selection is done in cooperation with the streams and under 719 the final authority of the IETF LLC. 721 The IETF LLC develops the work definition (the Statement of Work) for 722 the RPC and manages the vendor selection process. The work 723 definition is created within the IETF LLC budget and takes into 724 account the needs of stream managers as well as community input. 726 The process to select and contract for an RFC Production Center and 727 other RFC-related services is as follows: 729 o The IETF LLC establishes the contract process, including the steps 730 necessary to issue an RFP when necessary, the timing, and the 731 contracting procedures. 733 o The IETF LLC establishes a selection committee, which will consist 734 of the IETF Executive Director and other members selected by the 735 IETF LLC in consultation with the stream managers. The committee 736 shall select a chair from among its members. 738 o The selection committee selects the vendor, subject to the 739 successful negotiation of a contract approved by the IETF LLC. In 740 the event that a contract cannot be reached, the matter shall be 741 referred to the selection committee for further action. 743 4.5.2. Budget 745 The expenses discussed in this document are not new expenses. They 746 have been and remain part of the IETF LLC budget. 748 The RFC Series portion of the IETF LLC budget shall include funding 749 to support the RSCE, the RFC Production Center, and the Independent 750 Stream. 752 The IETF LLC has the responsibility to approve the total RFC Editor 753 budget (and the authority to deny it). All relevant parties must 754 work within the IETF LLC budgetary process. 756 5. RFC Series Consulting Editor (RSCE) 758 NOTE: Discussion continues within the RFCED-Future Program regarding 759 the appropriate title for an expert in technical publication 760 processes. Reflecting provisional agreement, this document refers to 761 the individual as the "RFC Series Consulting Editor" ("RSCE"). 763 The RFC Series Consulting Editor (RSCE) is a senior technical 764 publishing professional who will apply their deep knowledge of 765 technical publishing processes to the RFC series. 767 The primary responsibilities of the RSCE are as follows: 769 o Serve as a voting member on the RSAB 771 o Identify problems with the RFC publication process and 772 opportunities for improvement 774 o Provide expert advice regarding policy proposals within the RSWG 776 o If requested, provide expert advice to the RPC and IETF LLC 778 Matters on which the RSCE might be consulted could include the 779 following (see also Section 4 of [RFC8729]): 781 o Editing, processing, and publication of RFCs 783 o Publication formats for the RFC Series 785 o Changes to the RFC style guide 787 o Series-wide guidelines regarding document content and quality 789 o Web presence for the RFC Series 791 o Copyright matters related to the RFC Series 793 o Archiving, indexing, and accessibility of RFCs 795 The IETF LLC is responsible for the method of and management of the 796 engagement of the RSCE, including selection, evaluation, and the 797 timely filling of any vacancy. Therefore, whether the RSCE role is 798 structured as a contractual or employee relationship is a matter for 799 the IETF LLC to determine. 801 NOTE: This section is intended to address ISSUE #12 [32], ISSUE #24 802 [33], and ISSUE #55 [34]. 804 5.1. RSCE Selection 806 The IETF LLC will form a selection committee, including members from 807 the community, that will be responsible for making a recommendation 808 to the IETF LLC for the RSCE role. The selection committee will take 809 into account the role definition [35] as well as any other 810 information that the committee deems necessary or helpful in making 811 its decision. The IETF LLC is responsible for contracting or 812 employment of the RSCE. 814 5.2. RSCE Performance Evaluation 816 Periodically, the IETF LLC will evaluate the performance of the RSCE, 817 including a call for confidential input from the community. The IETF 818 LLC will produce a draft performance evaluation for the RSAB (not 819 including the RSCE), which will provide feedback to the IETF LLC. 821 6. Editorial Stream 823 This document creates the Editorial Stream as separate space for 824 publication of policies, procedures, guidelines, rules, and related 825 information regarding the RFC Series as a whole. 827 Any and all future documents produced by the RSWG and approved by the 828 RSAB shall be published in the Editorial Stream. Documents pubished 829 in the Editorial Stream shall have a status of Informational. The 830 Editorial Stream is not authorized to publish RFCs that are Standards 831 Track or Best Current Practice, since such RFCs are reserved to the 832 IETF Stream [RFC8729]. 834 The Editorial Stream will be used only to specify and update 835 policies, procedures, guidelies, rules, and related information 836 regarding the RFC Series as a whole; no other use of the Editorial 837 Stream is authorized by this memo and no other streams are so 838 authorized. This policy may be changed only by agreement of the IAB, 839 IESG, and IETF LLC. 841 The requirements and process for creating any additional RFC streams 842 are outside the scope of this document. 844 NOTE: This section is intended to address ISSUE #22 [36], ISSUE #35 845 [37], ISSUE #63 [38], and ISSUE #73 [39]. 847 7. Security Considerations 849 The same security considerations as those in [RFC8729] apply. The 850 processes for the publication of documents must prevent the 851 introduction of unapproved changes. Since the RFC Editor maintains 852 the index of publications, sufficient security must be in place to 853 prevent these published documents from being changed by external 854 parties. The archive of RFC documents, any source documents needed 855 to recreate the RFC documents, and any associated original documents 856 (such as lists of errata, tools, and, for some early items, originals 857 that are not machine-readable) need to be secured against any kind of 858 data storage failure. 860 The IETF LLC should take these security considerations into account 861 during the implementation and enforcement of any relevant contracts. 863 8. IANA Considerations 865 This document places responsibility for coordination of registry 866 value assignments with the RPC. The IETF LLC facilitates management 867 of the relationship between the RPC and IANA. 869 This document does not create a new registry nor does it register any 870 values in existing registries, and no IANA action is required. 872 9. References 874 9.1. Informative References 876 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 877 Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, 878 September 1998, . 880 [RFC3777] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, 881 and Recall Process: Operation of the Nominating and Recall 882 Committees", RFC 3777, DOI 10.17487/RFC3777, June 2004, 883 . 885 [RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights 886 Contributors Provide to the IETF Trust", BCP 78, RFC 5378, 887 DOI 10.17487/RFC5378, November 2008, 888 . 890 [RFC5620] Kolkman, O., Ed. and IAB, "RFC Editor Model (Version 1)", 891 RFC 5620, DOI 10.17487/RFC5620, August 2009, 892 . 894 [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor 895 Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June 896 2012, . 898 [RFC7154] Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54, 899 RFC 7154, DOI 10.17487/RFC7154, March 2014, 900 . 902 [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", 903 RFC 7282, DOI 10.17487/RFC7282, June 2014, 904 . 906 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 907 DOI 10.17487/RFC7322, September 2014, 908 . 910 [RFC7776] Resnick, P. and A. Farrel, "IETF Anti-Harassment 911 Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, March 912 2016, . 914 [RFC7841] Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed., 915 "RFC Streams, Headers, and Boilerplates", RFC 7841, 916 DOI 10.17487/RFC7841, May 2016, 917 . 919 [RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", 920 RFC 7991, DOI 10.17487/RFC7991, December 2016, 921 . 923 [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property 924 Rights in IETF Technology", BCP 79, RFC 8179, 925 DOI 10.17487/RFC8179, May 2017, 926 . 928 [RFC8700] Flanagan, H., Ed., "Fifty Years of RFCs", RFC 8700, 929 DOI 10.17487/RFC8700, December 2019, 930 . 932 [RFC8711] Haberman, B., Hall, J., and J. Livingood, "Structure of 933 the IETF Administrative Support Activity, Version 2.0", 934 BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020, 935 . 937 [RFC8716] Resnick, P. and A. Farrel, "Update to the IETF Anti- 938 Harassment Procedures for the Replacement of the IETF 939 Administrative Oversight Committee (IAOC) with the IETF 940 Administration LLC", BCP 25, RFC 8716, 941 DOI 10.17487/RFC8716, February 2020, 942 . 944 [RFC8728] Kolkman, O., Ed., Halpern, J., Ed., and R. Hinden, Ed., 945 "RFC Editor Model (Version 2)", RFC 8728, 946 DOI 10.17487/RFC8728, February 2020, 947 . 949 [RFC8729] Housley, R., Ed. and L. Daigle, Ed., "The RFC Series and 950 RFC Editor", RFC 8729, DOI 10.17487/RFC8729, February 951 2020, . 953 [RFC8730] Brownlee, N., Ed. and B. Hinden, Ed., "Independent 954 Submission Editor Model", RFC 8730, DOI 10.17487/RFC8730, 955 February 2020, . 957 [RFC8874] Thomson, M. and B. Stark, "Working Group GitHub Usage 958 Guidance", RFC 8874, DOI 10.17487/RFC8874, August 2020, 959 . 961 9.2. URIs 963 [1] https://github.com/intarchboard/program-rfced-future/issues/9 965 [2] https://github.com/intarchboard/program-rfced-future/issues/14 967 [3] https://github.com/intarchboard/program-rfced-future/issues/16 969 [4] https://github.com/intarchboard/program-rfced-future/issues/28 971 [5] https://github.com/intarchboard/program-rfced-future/issues/29 973 [6] https://github.com/intarchboard/program-rfced-future/issues/41 975 [7] https://github.com/intarchboard/program-rfced-future/issues/44 977 [8] https://github.com/intarchboard/program-rfced-future/issues/55 979 [9] https://github.com/intarchboard/program-rfced-future/issues/68 981 [10] https://github.com/intarchboard/program-rfced-future/issues/72 983 [11] https://github.com/intarchboard/program-rfced-future/issues/80 985 [12] https://github.com/intarchboard/program-rfced-future/issues/9 987 [13] https://github.com/intarchboard/program-rfced-future/issues/38 989 [14] https://github.com/intarchboard/program-rfced-future/issues/50 991 [15] https://github.com/intarchboard/program-rfced-future/issues/53 993 [16] https://github.com/intarchboard/program-rfced-future/issues/71 995 [17] https://github.com/intarchboard/program-rfced-future/issues/82 997 [18] https://github.com/intarchboard/program-rfced-future/issues/45 999 [19] https://github.com/intarchboard/program-rfced-future/issues/69 1001 [20] https://github.com/intarchboard/program-rfced-future/issues/67 1003 [21] https://github.com/intarchboard/program-rfced-future/issues/16 1005 [22] https://github.com/intarchboard/program-rfced-future/issues/36 1007 [23] https://www.ietf.org/about/groups/iesg/statements/anti- 1008 harassment-policy/ 1010 [24] https://www.rfc-editor.org/styleguide/ 1012 [25] https://github.com/intarchboard/program-rfced-future/issues/6 1014 [26] https://github.com/intarchboard/program-rfced-future/issues/59 1016 [27] https://github.com/intarchboard/program-rfced-future/issues/25 1018 [28] https://github.com/intarchboard/program-rfced-future/issues/57 1020 [29] https://github.com/intarchboard/program-rfced-future/issues/61 1022 [30] https://github.com/intarchboard/program-rfced-future/issues/62 1024 [31] https://github.com/intarchboard/program-rfced-future/issues/63 1026 [32] https://github.com/intarchboard/program-rfced-future/issues/12 1028 [33] https://github.com/intarchboard/program-rfced-future/issues/24 1030 [34] https://github.com/intarchboard/program-rfced-future/issues/55 1032 [35] https://github.com/intarchboard/program-rfced- 1033 future/blob/master/Issue12-RSE-role.md 1035 [36] https://github.com/intarchboard/program-rfced-future/issues/22 1037 [37] https://github.com/intarchboard/program-rfced-future/issues/35 1039 [38] https://github.com/intarchboard/program-rfced-future/issues/63 1041 [39] https://github.com/intarchboard/program-rfced-future/issues/73 1043 Appendix A. Updates to RFC 7841 1045 NOTE TO RFC EDITOR: Because this document (if approved) will be the 1046 first RFC in the Editorial Series, please apply the changes in this 1047 section to its boilerplate if directed to do so by the IAB. 1049 This document specifies the following text for the "Status of This 1050 Memo" section of RFCs published in the Editorial Stream. Any changes 1051 to this boilerplate must be made through the RFC Series Policy 1052 Definition process specified in this document. 1054 A.1. First Paragraph 1056 Because all Editorial Stream RFCs have a status of Informational, the 1057 first paragraph of the "Status of This Memo" section shall be as 1058 specified in Appendix A.2.1 of [RFC7841]. 1060 A.2. Second Paragraph 1062 The second paragraph of the "Status of This Memo" section shall be as 1063 follows: 1065 "This document is a product of the RFC Series Policy Definition 1066 process. It represents the consensus of the RFC Series Working Group 1067 approved by the RFC Series Approval Board. Such documents are not 1068 candidates for any level of Internet Standard; see Section 2 of RFC 1069 7841. 1071 A.3. Third Paragraph 1073 The third paragraph of the "Status of This Memo" section shall be as 1074 specified in Section 3.5 of RFC 7841. 1076 Appendix B. Changes from RFC 8728 1078 B.1. RFC Series Editor 1080 The RSWG and RSAB together provide a public process by which policies 1081 for the RFC Series can be defined. It is expected that these bodies 1082 will therefore cover many of the responsibilities of the RFC Series 1083 Editor function as defined by [RFC8728]. For example, representation 1084 to the IETF (Section 2.1.2.1 of [RFC8728] is no longer necessary 1085 because IETF participants can get involved in the RSWG, because the 1086 IETF has a delegate on the RSAB, and because the RPC provides reports 1087 directly to the community. 1089 B.2. RFC Publisher 1091 In practice the RFC Production Center (RPC) and RFC Publisher roles 1092 have been performed by the same entity and this practice is expected 1093 to continue; therefore this document dispenses with the distinction 1094 and refers only to the RPC. 1096 B.3. RFC Series Oversight Committee (RSOC) 1098 In practice, the relationships and lines of authority and 1099 responsibility between the IAB, RSOC, and RSE have proved unwieldy 1100 and somewhat opaque. To overcome some of these issues, this document 1101 dispenses with the RSOC. 1103 Appendix C. Updates to RFC 8729 1105 This document incorporates some text directly from [RFC8729] and also 1106 makes the following updates: 1108 o This document creates the Editorial Stream. 1110 o Future changes to policies governing the RFC Series as a whole now 1111 occur through documents defined by the RSWG, approved by the RSAB, 1112 and published in the Editorial Stream. 1114 o As described above, several responsibilities previously assigned 1115 to the "RFC Editor function" are now performed by the RSWG, RSAB, 1116 RPC, and IETF LLC (alone or in combination). These include 1117 aspects of operational oversight (Section 3.3 of [RFC8729]), 1118 policy oversight (Section 3.4 of [RFC8729]), the editing, 1119 processing, and publication of documents (Section 4.2 of 1120 [RFC8729]), and series-wide guidelines and rules (Section 4.4 of 1121 [RFC8729]). 1122 In addition, some details regarding these responsibilities have 1123 been modified to accord with the new framework defined in this 1124 document. 1126 Acknowledgments 1128 Portions of this document were borrowed from [RFC5620], [RFC6635], 1129 [RFC8728], [RFC8729], and earlier proposals submitted within the 1130 RFCED-Future Program by Martin Thomson, Brian Carpenter, and Michael 1131 StJohns. Thanks to the chairs of the Program, Eliot Lear and Brian 1132 Rosen, for their leadership and assistance. Thanks also for feedback 1133 and proposed text to Jari Arkko, Sarah Banks, Scott Bradner, Carsten 1134 Bormann, Nevil Brownlee, Ben Campbell, Jay Daley, Martin Duerst, Lars 1135 Eggert, Adrian Farrel, Stephen Farrell, Sandy Ginoza, Bron Gondwana, 1136 Joel Halpern, Wes Hardaker, Bob Hinden, Russ Housley, Christian 1137 Huitema, Ole Jacobsen, John Klensin, Mirja Kuehlewind, Ted Lemon, 1138 John Levine, Lucy Lynch, Andrew Malis, Larry Masinter, S. Moonesamy, 1139 Mark Nottingham, Tommy Pauly, Colin Perkins, Julian Reschke, Eric 1140 Rescorla, Adam Roach, Alice Russo, Doug Royer, Rich Salz, Tim 1141 Wicinski, and Nico Williams. 1143 Author's Address 1145 Peter Saint-Andre (editor) 1146 Mozilla 1148 Email: stpeter@stpeter.im