idnits 2.17.1 draft-carpenter-request-for-comments-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 an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scope than the IETF, and limits the IAB's authority to matters of' ) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 20, 2019) is 1743 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4693 (Obsoleted by RFC 6393) ** Obsolete normative reference: RFC 4844 (Obsoleted by RFC 8729) ** Obsolete normative reference: RFC 6635 (Obsoleted by RFC 8728) Summary: 6 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. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational June 20, 2019 5 Expires: December 22, 2019 7 Request for Comments 8 draft-carpenter-request-for-comments-01 10 Abstract 12 This document discusses the Internet technical community's common 13 document series and why its independence, and the professional status 14 of the RFC Series Editor, must be stoutly defended. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 22, 2019. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. TL;DR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. The Problems with the IETF's use of the RFC Series . . . . . 2 52 3. Who Owns the RFC Series? . . . . . . . . . . . . . . . . . . 3 53 4. Request for Comments means Request for Comments . . . . . . . 6 54 5. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 59 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 9 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 63 1. TL;DR 65 "I present here some of the tentative agreements reached and some of 66 the open questions encountered. Very little of what is here is firm 67 and reactions are expected." [RFC0001], Steve Crocker, 7 April 1969. 69 2. The Problems with the IETF's use of the RFC Series 71 It's very clear that there are problems with the way the IETF uses 72 the RFC series. For example, [RFC0791] is so badly written that it 73 would never pass an IETF working group last call, let alone an IETF 74 last call or an IESG review today. Although updated by three other 75 RFCs and having a dozen errata, it has never been replaced. Yet it 76 will be exercised billions of times today and every day. Another 77 example is that a newcomer wishing to implement even the simplest 78 mail user agent will not find an RFC telling her how to do so. A 79 method to mitigate this problem was proposed but not adopted 80 [I-D.ietf-newtrk-sample-isd]. A related problem is that finding the 81 latest version of a standard requires arcane knowledge; for example, 82 someone looking for the latest IPv6 standard via the popular search 83 tools is still quite likely to end up consulting RFC2460, although it 84 was obsoleted almost two years ago. Another example is the frequency 85 of references to RFC2616 for HTTP, obsoleted in 2014. 87 A major gripe about the RFC series is its limitation to ASCII and its 88 reliance on typewriter-friendly formatting and its lack of good 89 diagrams. Fortunately this is being worked on actively, so is not 90 further discussed here. 92 An occasional annoyance is that since the RFC series is long 93 established and serves a very wide community of authors, it includes 94 only some documents that are formally agreed statements of IETF rough 95 consensus and even fewer that are formally agreed statements of IETF 96 rough consensus about proposed standards or best current practice. 97 The IETF has preferred to maintain a distinction between proposed 98 standards and Internet standards, which means that there are even 99 fewer RFCs designated as Internet standards. An attempt to fix that 100 particular problem by reducing the number and hence complexity of the 101 categories [RFC6410] has not appeared to make significant 102 improvements in either the confusion or the ratio of Internet 103 Standards to Proposed ones. Efforts to reduce the distinction and 104 provide stable references to at least the current versions of updated 105 standards (e.g., [I-D.klensin-std-numbers]) have received little 106 interest. A proposal that reached IETF Working Group consensus to 107 publish a new form of document summarising the status of particular 108 complex standards [I-D.ietf-newtrk-repurposing-isd] did not satisfy 109 the IESG and was not advanced. 111 This problem area has been well known for many years [RFC1796] and 112 has occasionally led to concern that some vendors might mislead 113 customers by claiming conformance with a non-standard RFC. For this 114 reason, the header text on RFCs was clarified some years ago such 115 that readers can clearly distinguish standards from non-standards. 116 The original version of this was "This memo provides information for 117 the Internet community. This memo does not specify an Internet 118 standard of any kind." and has been used (with occasional updates to 119 the wording) since 1994, well before [RFC1796] was published. 121 There is therefore no lack of clarity, and has been none since 1994, 122 about which RFCs are normative statements of consensus and which are 123 not. Certainly, some readers will bypass the header text as "TL;DR" 124 (too long; didn't read) or ignore it as "DK;DC" (don't know; don't 125 care) but there is literally nothing the IETF can do about that. (In 126 the new RFC format, it would be possible and perhaps desirable to use 127 special typography to emphasise the document status, but it doesn't 128 solve the underlying problem of human behaviour, because nothing 129 can.) 131 I conclude that this set of problems is really nothing to do with the 132 RFC series as a publication venue and nothing to do with the format 133 of RFCs. It is entirely the result of the IETF's standards process; 134 if the IETF wants it fixed, it must look inwards at that process, and 135 not outwards at the community's open publication process. 137 3. Who Owns the RFC Series? 139 I am not asking this question in a legal sense. To the extent 140 legally possible, the copyright in the RFC series currently belongs 141 to the IETF Trust in addition to the authors, but the Trust's 142 purposes are broad: 144 "Such purposes include, but are not limited to, the advancement 145 of education and public interest by acquiring, holding, 146 maintaining and licensing certain existing and future 147 intellectual property and other property used in connection 148 with the Internet standards process and its administration, for 149 the advancement of the science and technology associated with 150 the Internet and related technology." 151 (IETF Trust Agreement, 2005) 153 In any case, the important question is who "owns" the RFC series in 154 an overall ethical and societal sense. 156 It's easier to answer the converse question: who doesn't own the RFC 157 series? 159 1. It's clear that the IETF doesn't own it, because the series 160 preceded the IETF by 17 years. 162 2. Therefore, of course, the IESG doesn't own it. 164 3. At some point in history, both ARPA (who funded the ARPAnet) and 165 ISI (who provided RFC editing under contract) could have made a 166 claim. But that faded when a paid RFC Editor was directly 167 contracted by ISOC. 169 4. ISOC could certainly make a claim, having funded the series for 170 many years now. However, ISOC, like the IETF Trust, has a broad 171 mission: 173 "Such educational, charitable, and scientific purposes 174 shall include carrying on activities: 176 1. To facilitate and support the technical evolution of the 177 Internet as a research and education infrastructure, and to 178 stimulate the involvement of the scientific community, industry, 179 government and others in the evolution of the Internet; 180 2. To educate the scientific community, industry and the public 181 at large concerning the technology, use and application of the 182 Internet; 183 3. To promote educational applications of Internet technology 184 for the benefit of government, colleges and universities, 185 industry, and the public at large; 186 4. To provide a forum for exploration of new Internet 187 applications, and to stimulate collaboration among organizations 188 in their operational use of the global Internet." 189 (Articles of Incorporation of the Internet Society) 191 5. The recently formed IETF LLC certainly doesn't own the series, 192 although it does channel the contracts and money formerly handled 193 directly by ISOC. 195 6. Finally, the Internet Architecture Board could make a claim based 196 on its charter [RFC2850], which states that: 198 "The RFC series constitutes the archival publication channel 199 for Internet Standards and for other contributions by the 200 Internet research and engineering community. RFCs are available 201 free of charge to anyone via the Internet. The IAB must approve 202 the appointment of an organization to act as RFC Editor and the 203 general policy followed by the RFC Editor." 205 This text makes it clear that the RFC series is much broader in 206 scope than the IETF, and limits the IAB's authority to matters of 207 general policy. 209 The reasonable conclusion from the above is that none of the I* 210 organisations (IETF Trust, IETF LLC, IETF, IESG, IAB or ISOC) can 211 claim exclusivity of ownership or control over the RFC series. It is 212 community property and must operate on behalf of the community as a 213 whole. 215 A first important consequence is that major decisions about the 216 future of the RFC Series must be taken by a consensus of a very broad 217 community. That doesn't mean the IETF or the IAB. It means the IETF 218 and IAB, plus the IRTF, plus many other people who have contributed 219 to, or made use of, the RFC Series over the last fifty years. How to 220 reach out to this community is in itself a big question. 222 A second important consequence is that the position of RFC Series 223 Editor answers to the community as a whole, not narrowly to the IAB. 224 In particular the RFC Series Editor has considerable independence (in 225 addition to the obvious independence of the Independent Series 226 Editor). To quote from [RFC6635]: 228 "The RFC Series Editor will exercise 229 strategic leadership and management over the activities of the RFC 230 Publisher and the RFC Production Center... [and] 232 o Represents the RFC Series and the RFC Editor Function within the 233 IETF and externally. 235 o Leads the community in the design of improvements to the RFC 236 Series. 238 o Is responsible for planning and seeing to the execution of 239 improvements in the RFC Editor production and access processes. 241 o Is responsible for the content of the rfc-editor.org web site, 242 which is operated and maintained by the RFC Publisher. 244 o Is responsible for developing consensus versions of vision and 245 policy documents." 247 In other words, the RFC Series Editor must be a highly respected 248 independent professional editor, not acting under orders, and serving 249 a much wider community than just the IETF. Given the economic and 250 social importance of the Internet, this is a very serious 251 responsibility, comparable to the editorship of a major newspaper of 252 record. 254 The community was very fortunate that the progenitors of the RFC 255 Editor function, in particular but not exclusively Steve Crocker, Jon 256 Postel, Joyce Reynolds and Bob Braden [I-D.flanagan-fiftyyears], were 257 modest and wise enough to know their own limitations, to learn about 258 professional editing as they went along, and to remain open and 259 sensitive to the needs of the whole Internet technical community. 260 When it eventually came time to appoint a professional series editor, 261 this proved very hard and fundamentally different from either 262 recruiting for technical leadership positions 263 [I-D.carpenter-community-leaders] or for administrative or 264 operational needs. Indeed the RFC Series Editor has always been, and 265 must remain, a member of the same peer group as IAB members, IESG 266 members, IETF and IRTF group chairs, and indeed participants in 267 general, each with their own professional skills. 269 4. Request for Comments means Request for Comments 271 There is an inherent modesty in calling our documents "requests for 272 comments". As the above quotation from RFC1 said right at the 273 beginning, we get things wrong. We want comments, we want errata, we 274 want operational feedback, and we want to go round that loop again 275 each time we update a specification. When we forget that, we are 276 getting dangerously close to arrogance and hubris. 278 Avoiding this trap is indeed the reason that the community has always 279 published a number of RFCs that are not the product of organised 280 groups, formalised some years ago as the Independent Stream of RFCs 281 [RFC4844]. Whether they document deployed solutions not invented in 282 the IETF, or alternative solutions not accepted by the IETF, or 283 informed technical opinions not discussed in the IETF, they remain 284 part of the broader community's open record, and a useful counter- 285 balance to any occurrence of groupthink in the IETF, IRTF or IAB. 287 Calling IETF standards "requests for comments" is what distinguishes 288 the IETF from most other standards organisations, and it's the right 289 thing to do. 291 5. Experiments 293 RFC1 started an experiment, which has been fairly successful so far, 294 certainly with consequences that were not foreseen at the time. 295 Another experiment was the IEN (Internet Experiment Note) series, 296 which ran from 1977 to 1982. Another one was the ION (IETF 297 Operational Notes) series, which ran briefly in 2006/7 [RFC4693]. 298 Finally, the usage of the RFC subseries designated "FYI", "STD", or 299 "BCP" has had limited success. "FYI" has been dropped, "STD" is 300 fairly useless as it is only applied to full Internet standards 301 (despite proposals to widen it, as mentioned above), and "BCP" has 302 been reasonably successful. 304 The next planned experiment is the major upgrade of RFC formatting, 305 which will inevitably cause some disturbance to the document 306 production process when it goes live. 308 A full analysis of these various experiments, their goals, and their 309 successes and failures, seems necessary before designing any future 310 experiment in the area of document series. 312 6. Conclusion 314 The IETF has not made a serious attempt to fix known major bugs in 315 its standards publication process in the last 15 years. These are 316 not bugs in the RFC Series but in the way the IETF uses the Series. 317 The RFC Series exists for the Internet community as a whole, must 318 retain its independence and autonomy, and must continue to be managed 319 by a senior professional editor. 321 7. Security Considerations 323 Security issues are discussed in all recent RFCs. This uniformity 324 illustrates the coherence of the RFC series and the way it has been 325 used to ensure a degree of order in the chaotic world of Internet 326 design, implementation and deployment. 328 8. IANA Considerations 330 This document makes no request of the IANA. Like the RFC series, the 331 IANA is a service provided for the benefit of the entire Internet 332 technical community in a coherent and consistent way. 334 9. Acknowledgements 336 Useful comments were received from various sources, but this document 337 is very much a personal statement. 339 10. References 341 [I-D.carpenter-community-leaders] 342 Carpenter, B., "Some Thoughts on IETF Community 343 Leadership", draft-carpenter-community-leaders-01 (work in 344 progress), June 2019. 346 [I-D.flanagan-fiftyyears] 347 Flanagan, H., "Fifty Years of RFCs", draft-flanagan- 348 fiftyyears-07 (work in progress), June 2019. 350 [I-D.ietf-newtrk-repurposing-isd] 351 Klensin, J. and J. Loughney, "Internet Standards 352 Documentation (ISDs)", draft-ietf-newtrk-repurposing- 353 isd-04 (work in progress), March 2006. 355 [I-D.ietf-newtrk-sample-isd] 356 Klensin, J., "Internet Standards Documentation (ISDs) - 357 Examples", draft-ietf-newtrk-sample-isd-00 (work in 358 progress), October 2004. 360 [I-D.klensin-std-numbers] 361 Klensin, J., "STD Numbers and the IETF Standards Track", 362 draft-klensin-std-numbers-02 (work in progress), July 363 2018. 365 [RFC0001] Crocker, S., "Host Software", RFC 1, DOI 10.17487/RFC0001, 366 April 1969, . 368 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 369 DOI 10.17487/RFC0791, September 1981, 370 . 372 [RFC1796] Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are 373 Standards", RFC 1796, DOI 10.17487/RFC1796, April 1995, 374 . 376 [RFC2850] Internet Architecture Board and B. Carpenter, Ed., 377 "Charter of the Internet Architecture Board (IAB)", 378 BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000, 379 . 381 [RFC4693] Alvestrand, H., "IETF Operational Notes", RFC 4693, 382 DOI 10.17487/RFC4693, October 2006, 383 . 385 [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC 386 Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, 387 July 2007, . 389 [RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the 390 Standards Track to Two Maturity Levels", BCP 9, RFC 6410, 391 DOI 10.17487/RFC6410, October 2011, 392 . 394 [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor 395 Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June 396 2012, . 398 Appendix A. Change log [RFC Editor: Please remove] 400 draft-carpenter-request-for-comments-00, 2018-06-06: 402 Initial version 404 draft-carpenter-request-for-comments-01, 2019-06-20: 406 Updated and extended. 408 Author's Address 409 Brian Carpenter 410 Department of Computer Science 411 University of Auckland 412 PB 92019 413 Auckland 1142 414 New Zealand 416 Email: brian.e.carpenter@gmail.com