idnits 2.17.1 draft-carpenter-rfc-principles-01.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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (18 May 2020) is 1438 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 8728 (Obsoleted by RFC 9280) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. E. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational 18 May 2020 5 Expires: 19 November 2020 7 Principles of the Request for Comments Series 8 draft-carpenter-rfc-principles-01 10 Abstract 12 This document discusses the underlying principles of the Internet 13 technical community's Request for Comments document Series. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on 19 November 2020. 32 Copyright Notice 34 Copyright (c) 2020 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 39 license-info) in effect on the date of publication of this document. 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. Code Components 42 extracted from this document must include Simplified BSD License text 43 as described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Proposed Principles . . . . . . . . . . . . . . . . . . . . . 6 51 3.1. The RFC Series as a Whole . . . . . . . . . . . . . . . . 6 52 3.2. The RFC Series Editor . . . . . . . . . . . . . . . . . . 8 53 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 56 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 57 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 10 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 61 1. Introduction 63 This document was written as background material for ongoing 64 discussions about the role of the Request for Comments (RFC) Series 65 Editor (the RSE). This version is purely personal opinion, but with 66 some community comments incorporated. The author welcomes further 67 comments, best sent to the mailing list rfc-interest@rfc-editor.org 68 if they concern the RFC Series in general, or to the mailing list 69 rfced-future@iab.org if they concern the role of the RSE 70 specifically. 72 The RFC Series has a 50 year history, too long to summarise here, so 73 the reader is assumed to be familiar with [RFC8700]. However, the 74 Series does not appear to have a documented set of principles or a 75 full charter. This will make the obvious first task of the future 76 RSE -- developing a strategy for the Series -- hard, if not 77 impossible. The goal of this document is to outline what those 78 principles might be, for community debate. Once the principles are 79 clear, the next step could be to draft a full charter based on them, 80 also for community debate. Alternatively, the principles could be 81 incorporated in a revision of [RFC8729]. 83 This document does not aim to provide a problem statement or gap 84 analysis, and technical matters such as RFC formatting are completely 85 out of scope. Matters concerning the IETF standards process, and how 86 it uses the Series, are also out of scope. Some problems in the 87 standards process are problems in how the IETF uses the RFC Series, 88 not problems in the Series itself. (Interested readers can find 89 comments on that topic in [I-D.carpenter-request-for-comments].) 91 The document starts with a review of existing background material 92 that touches on principles of the Series, and then offers a set of 93 proposed principles for debate. 95 2. Background 97 The RFC Editor web site states the following: 99 The RFC series contains technical and organizational documents 100 about the Internet, including the specifications and policy 101 documents produced by four streams: the Internet Engineering 102 Task Force (IETF), the Internet Research Task Force (IRTF), the 103 Internet Architecture Board (IAB), and Independent Submissions. 105 This says little about underlying principles. Instead, consider the 106 original guidance from the author of the first RFC: 108 I present here some of the tentative agreements reached and some of 109 the open questions encountered. Very little of what is here is firm 110 and reactions are expected. 112 [RFC0001], Steve Crocker, 7 April 1969. 114 More recently, Steve wrote this in [RFC8700]: 116 The basic ground rules were that anyone could say anything and 117 that nothing was official. And to emphasize the point, I used 118 Bill Duvall's suggestion and labeled the notes "Request for 119 Comments". 121 Partly as a result of this starting point, the tradition has always 122 been that RFCs may be used rather freely, including reproduction in 123 their entirety and translation into other languages. In more recent 124 years, the IETF has asserted change control over its own documents, 125 even when published as RFCs, by virtue of the IETF Trust's legal 126 conditions. This raises the issue of who owns the copyright. Some 127 RFCs are considered to have been placed in the public domain as a 128 result of being part of government funded projects. Copyright in 129 some others presumably belongs to their authors, or to those authors' 130 employers. To the extent legally possible, the copyright in the RFC 131 Series currently belongs to the IETF Trust in addition to the 132 authors. 134 For completeness, note that each RFC stream has its own policy on 135 copyright and change control issues, not discussed in detail here. 137 In any case, the question of copyright is not the same as asking who 138 "owns" the RFC Series in an overall ethical and societal sense. It 139 is easy to establish who does _not_ own the Series: 141 1. The IETF does not own it, because the Series preceded the IETF by 142 17 years. 144 2. Therefore the IESG does not own it. 146 3. As noted, the IETF Trust only has limited intellectual property 147 rights in some (but not all) RFCs. 149 4. At some point in history, both ARPA (who funded the ARPAnet) and 150 USC/ISI (who provided RFC editing under contract) could have made 151 a claim. But that faded when a paid RFC Editor was directly 152 contracted by ISOC. 154 5. ISOC could perhaps make a claim, having funded the Series for 155 many years now. ISOC has a broad purpose which certainly 156 empowers it to support the RFC Series, but that does not imply 157 control or ownership. 159 6. The IETF LLC, technically a subsidiary of ISOC, therefore does 160 not own the Series either, although it does channel the contracts 161 and money formerly handled directly by ISOC. 163 7. Finally, the Internet Architecture Board could make a claim based 164 on its charter [RFC2850], which states that: 166 The RFC series constitutes the archival publication channel 167 for Internet Standards and for other contributions by the 168 Internet research and engineering community. RFCs are available 169 free of charge to anyone via the Internet. The IAB must approve 170 the appointment of an organization to act as RFC Editor and the 171 general policy followed by the RFC Editor. 173 This text makes it clear that the RFC Series is much broader in 174 scope than the IETF, and limits the IAB's authority to matters of 175 general policy. 177 A reasonable conclusion from the above is that none of the I* 178 organisations (IETF Trust, IETF LLC, IETF, IESG, IAB or ISOC) can 179 claim exclusivity of ownership or control over the RFC Series. 181 Despite the limited authority granted by its own charter, the IAB has 182 published various RFCs about the Series as a whole. I quote here 183 from two in particular. 185 Firstly, [RFC8729] states as follows: 187 The RFC Series is the archival series dedicated to documenting 188 Internet technical specifications, including general contributions 189 from the Internet research and engineering community as well as 190 standards documents. 192 RFCs are available free of charge to anyone via the Internet. 194 ... 196 The RFC Editor is an expert technical editor and series editor, 197 acting to support the mission of the RFC Series. As such, the RFC 198 Editor is the implementer handling the editorial management of the 199 RFC Series, in accordance with the defined processes. In addition, 200 the RFC Editor is expected to be the expert and prime mover in 201 discussions about policies for editing, publishing, and archiving 202 RFCs. 204 ... 206 The IAB monitors the effectiveness of the policies in force and their 207 implementation to ensure that the RFC Editor activity meets the 208 editorial management and document publication needs as referenced in 209 this document. In the event of serious non-conformance, the IAB, 210 either on its own initiative or at the request of the IETF 211 Administration LLC Board, may require the IETF Executive Director to 212 vary or terminate and renegotiate the arrangements for the RFC Editor 213 activity. 215 A second document clarifies that RFC Series Editor has considerable 216 independence (in addition to the obvious independence of the 217 Independent Series Editor). To quote from [RFC8728]: 219 The RFC Editor function is responsible for 220 the packaging and distribution of the documents. As such, documents 221 from these streams are edited and processed by the Production Center 222 and published by the Publisher. The RFC Series Editor will exercise 223 strategic leadership and management over the activities of the RFC 224 Publisher and the RFC Production Center (both of which can be seen as 225 back-office functions) and will be the entity that: 227 * Represents the RFC Series and the RFC Editor function within the 228 IETF and externally. 230 * Leads the community in the design of improvements to the RFC 231 Series. 233 * Is responsible for planning and seeing to the execution of 234 improvements in the RFC Editor production and access processes. 236 * Is responsible for the content of the rfc-editor.org web site, 237 which is operated and maintained by the RFC Publisher. 239 * Is responsible for developing consensus versions of vision and 240 policy documents. These documents will be reviewed by the RFC 241 Series Oversight Committee (Section 3.1) and subject to its 242 approval before final publication. 244 3. Proposed Principles 246 This section, in particular, needs community review. Some of it is 247 adapted from existing documents. 249 3.1. The RFC Series as a Whole 251 1. The RFC Series is the archival series that documents Internet 252 technical specifications, descriptions, and commentaries, 253 including general contributions from the Internet research and 254 engineering community, as well as standards documents. It also 255 includes some organisational documents from the same community. 257 * "Archival" means that the documents must be available for the 258 indefinite future in a form that is trusted by all parties. 259 In particular there must be no doubt as to the precise 260 original text and diagrams, regardless of the format in which 261 the documents are stored or displayed. Errors or omissions 262 detected after publication, and subsequent modifications or 263 extensions of the document content, do not change the archived 264 document itself. 266 2. All RFCs are available free of charge to anyone via the Internet. 267 They may be freely translated in their entirety into any 268 language. 270 3. Request for Comments means Request for Comments. 272 * There is an inherent modesty in calling our documents 273 "requests for comments". We get things wrong, we want 274 comments, we want errata, we want operational feedback, and we 275 want to go round that loop again. This property is a useful 276 counter-balance to any occurrence of groupthink in the 277 community. 279 4. RFCs come from various streams, i.e. originating organisations. 281 * Each stream has its own policy on change control, copyright, 282 and patents, with the IETF Trust generally acting as a 283 repository for intellectual property rights that are not 284 retained by the authors. 286 * Each stream has full control of the technical content of its 287 documents. 289 * The RFC Editor team has control of editorial matters, subject 290 to review by the relevant stream and the document authors. In 291 particular, a badly written document may be returned to its 292 stream for improvements if an abnormal amount of copy-editing 293 is required. 295 * If an individual member of the RFC Editor team has personal 296 comments on the technical content of a draft RFC, they must be 297 handled in person, using the appropriate mechanism of the 298 stream concerned, not as an RFC Editor matter. 300 * If the RFC Editor team believes that a draft RFC contains a 301 serious technical flaw, which the stream declines to change, 302 the RFC Editor cannot block the document indefinitely. Note 303 that there is more discussion of such disagreements in 304 Section 4.3 of [RFC8728]. 306 * New streams may in principle be created, subject to community 307 agreement and guidelines to be defined. 309 * Defunct streams may be closed, subject to community agreement. 311 5. The RFC Series is community property and must operate on behalf 312 of the community as a whole. 314 * The exact definition of the relevant community is open for 315 debate. One definition is: the IETF, the IRTF, the IAB and 316 the many other people who have contributed to, or made use of, 317 the RFC Series over the last fifty years. In particular, many 318 users of the RFC series, ranging for example from junior 319 hardware or software engineers to senior executives overseeing 320 procurement decisions, will never participate directly in the 321 IETF or IRTF. 323 6. Major decisions about the future of the RFC Series should be 324 taken by a rough consensus of this very broad community. 326 * How to reach out to this community and judge its consensus is 327 an open question. The mechanism needs to be open to all 328 interested parties, but with a well-defined process and checks 329 and balances. Although the community is broader than the 330 IETF, the IETF Working Group rough consensus process may be 331 the best model. 333 3.2. The RFC Series Editor 335 1. The RFC Series Editor is an independent professional editor, 336 serving a much wider community than just the IETF. Given the 337 economic and social importance of the Internet, this is a serious 338 responsibility. Similar roles might be executive leadership 339 positions at a technical or academic publisher. 341 Five responsibilities adapted from [RFC8728] apply: 343 * Represents the RFC Series and the RFC Editor function within 344 the IETF, IRTF and externally. 346 * Leads the community in the design of improvements to the RFC 347 Series. 349 * Is responsible for developing vision and policy documents, and 350 establishing community consensus for them. 352 * Is responsible for planning and overseeing the execution of 353 improvements in the RFC Editor production and access 354 processes, in collaboration with IETF LLC as appropriate. 356 * Is responsible for the content of the RFC Editor web site, 357 which is operated and maintained by the RFC Publisher. 359 2. The RFC Series Editor, while paid to serve the community, is a 360 member of the same professional peer group as IAB members, IESG 361 members, IETF and IRTF group chairs, and other experienced 362 members of the technical community, each with their own distinct 363 professional skills. 365 3. The position of RFC Series Editor answers to the community as a 366 whole. 368 * The grant of authority in the IAB charter should be reviewed 369 in this light. 371 4. Conclusion 373 In summary, the RFC Series exists for the Internet community as a 374 whole, must retain its independence, openness and autonomy, and must 375 continue to be managed by a senior professional editor. 377 5. Security Considerations 379 Security issues are discussed in all recent RFCs. This uniformity 380 illustrates the coherence of the RFC Series and the way it has been 381 used to ensure a degree of order in the chaotic world of Internet 382 design, implementation and deployment. 384 An assumption in our community is that all actors act in good faith, 385 subject of course to normal human failures. As far as possible, the 386 RFC Editor regime needs to be immune to malicious acts of any kind. 387 For that reason, it is important that appropriate organisational 388 checks and balances are in place. 390 6. IANA Considerations 392 This document makes no request of the IANA. 394 7. Acknowledgements 396 Important comments were received from Carsten Bormann, Nevil 397 Brownlee, Adrian Farrel, Stephen Farrell, Joel Halpern, John Klensin, 398 Mark Nottingham, Tommy Pauly, Eric Rescorla, Adam Roach, Mike 399 StJohns, Martin Thomson, and others. 401 8. References 403 [I-D.carpenter-request-for-comments] 404 Carpenter, B., "Request for Comments", Work in Progress, 405 Internet-Draft, draft-carpenter-request-for-comments-01, 406 19 June 2019, . 409 [RFC0001] Crocker, S., "Host Software", RFC 1, DOI 10.17487/RFC0001, 410 April 1969, . 412 [RFC2850] Internet Architecture Board and B. Carpenter, Ed., 413 "Charter of the Internet Architecture Board (IAB)", 414 BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000, 415 . 417 [RFC8700] Flanagan, H., Ed., "Fifty Years of RFCs", RFC 8700, 418 DOI 10.17487/RFC8700, December 2019, 419 . 421 [RFC8728] Kolkman, O., Ed., Halpern, J., Ed., and R. Hinden, Ed., 422 "RFC Editor Model (Version 2)", RFC 8728, 423 DOI 10.17487/RFC8728, February 2020, 424 . 426 [RFC8729] Housley, R., Ed. and L. Daigle, Ed., "The RFC Series and 427 RFC Editor", RFC 8729, DOI 10.17487/RFC8729, February 428 2020, . 430 Appendix A. Change log [RFC Editor: Please remove] 432 draft-carpenter-rfc-principles-01, 2020-05-18: 434 * Numerous updates following initial community comments. 436 draft-carpenter-rfc-principles-00, 2020-05-09: 438 * Initial version (some content based on draft-carpenter-request- 439 for-comments-01). 441 Author's Address 443 Brian Carpenter 444 School of Computer Science 445 University of Auckland 446 PB 92019 447 Auckland 1142 448 New Zealand 450 Email: brian.e.carpenter@gmail.com