idnits 2.17.1 draft-klensin-rfcplusplus-alternatives-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2018) is 2085 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3 (Obsoleted by RFC 10) -- Obsolete informational reference (is this intentional?): RFC 825 (Obsoleted by RFC 1111, RFC 1543, RFC 2223) -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft July 13, 2018 4 Intended status: Informational 5 Expires: January 14, 2019 7 Alternatives to the RFC++ "Switch Labels" Proposal 8 draft-klensin-rfcplusplus-alternatives-00 10 Abstract 12 A BoF, identified as RFC++ and focused on possible changes to the 13 identification of a broad range of documents and sources with the 14 term "RFC", has been scheduled for IETF 102 and extensively discussed 15 on an associated mailing list. At least based on the BoF proposal, 16 the BoF was expected to accept a particular problem description as 17 both adequate and sufficiently important to justify changes and then 18 to consider one particular proposal. Mailing list discussions have 19 indicated that neither the problem statement nor the proposal are 20 without controversy. An Internet Draft has been posted that 21 describes that particular proposal in more detail. Without 22 significant analysis of the problem statement, this draft mentions 23 that proposal as a possible member of a family of similar proposals 24 and then outlines some other families of proposals for the 25 convenience of BoF participants and the community more generally. 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 January 14, 2019. 44 Copyright Notice 46 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Note in Draft for Initial Version . . . . . . . . . . . . 2 63 1.2. Questions about The Problem . . . . . . . . . . . . . . . 2 64 1.3. Discussion List . . . . . . . . . . . . . . . . . . . . . 3 65 2. Possibility 1: Remove the "RFC" name and label from non-IETF 66 documents . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Possibility 2: Qualifying Labels Rather than Replacing THem . 3 68 4. Possibility 3: Create and Use More Supplmental Labels, 69 Building on STD, BCP, and FYI . . . . . . . . . . . . . . . . 4 70 5. Possibility 4: Treat Problem as an Educational One . . . . . 5 71 6. Possibility 5: The Really Radical Solution . . . . . . . . . 7 72 7. Additional Possibilities and Evaluation . . . . . . . . . . . 8 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 11. Informative References . . . . . . . . . . . . . . . . . . . 9 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 1.1. Note in Draft for Initial Version 83 This is a very preliminary and hastily-prepared draft, provided in 84 the hope of contributing some specific alternatives to the one 85 presented in the request for the "The label 'RFC' BOF" at IETF 102, 86 now scheduled for 18:10 Montreal time on Monday 16 July 2018. It is 87 also written somewhat more personally than is typical of more mature 88 Internet Drafts. Please forgive typographical errors, poorly- 89 constructed sentences, and omissions resulting from the associated 90 constraints. 92 1.2. Questions about The Problem 94 There has been considerable discussion on the RFC++ list 95 [RFCplusplus-list] and elsewhere about whether there is actually a 96 problem that requires solving and whether, given that any change has 97 costs, the problems are severe enough that solutions are in order or 98 whether we should just live with them. 100 Those issues are out of scope for this document. It assumes 101 (contrary to the opinion of the author) that there is a problem, 102 largely as described in a 1995 analysis [RFC1796], that measures 103 taken since have been ineffective, and that the IETF community will 104 conclude that there is a problem worth solving. If so, the solution 105 included in the BOF proposal [RFCplusplus-proposal] and initial 106 document [Thomson-RFCplusplus] is only one of several possibilities. 107 The balance of this Internet-Draft outlines some of those other 108 possibilities. 110 1.3. Discussion List 112 Discussion of this document and related issues should be directed to 113 the Rfcplusplus@ietf.org mailing list. 115 2. Possibility 1: Remove the "RFC" name and label from non-IETF 116 documents 118 This possibility is described in a document posted just before the 119 normal posting cutoff [Thomson-RFCplusplus]. It essentially suggests 120 replacing the RFC name and numbers on non-IETF documents with other 121 names and numbering series. It is not further described here other 122 than to note that several people have argued that, if a key property 123 of an experiment is that it can be undone in a way that leaves things 124 at the status quo before the experiment started, it is not an 125 experiment but a change that can be reversed only at considerable 126 cost if at all. 128 3. Possibility 2: Qualifying Labels Rather than Replacing THem 130 The following is derived, with permission, from Brian Carpenter's 131 email titled "Qualified Labels", Tuesday, July 10, 2018 14:23 +1200. 133 1. Continue to use the RFC series as today for multiple purposes. 134 But recognise more clearly that the number is an archival 135 reference. 137 2. For all normal purposes, including citations, use a *qualified* 138 label. Rather than writing a formal definition, there's an 139 example of each qualifier below. 141 An advantage is that this can be retrofitted straightforwardly to 142 *all* RFCs, indexes, citation libraries, etc. And it could be 143 removed just as easily if it proves to be a problem rather than a 144 solution. 146 Examples 148 RFC8200-STD (or RFC8200-STD86) 149 RFC8414-PS 150 RFC5681-DS 151 RFC2026-BCP (or RFC2026-BCP9) 153 RFC7557-EXPT 154 RFC8394-INFO (for IETF informationals) 155 RFC7663-IAB 156 RFC7575-RSCH (for IRTF informationals) 157 RFC8351-INDEP (for Independent informationals) 159 RFC2460-OBS 160 RFC1128-UNK 161 RFC1130-HIST 163 Figure 1 165 4. Possibility 3: Create and Use More Supplmental Labels, Building on 166 STD, BCP, and FYI 168 Many years ago, the RFC Editor, encouraged by the IETF, introduced 169 supplementary numbering systems, overlaid on the archival RFC numbers 170 and identifying conceptual documents rather than specific documents 171 and instances. Those series -- "STD", "BCP", and the now-retired 172 "FYI" -- have served their original purpose of identifying documents 173 and grouping closely-related work together and/or providing a 174 reference to current versions rather than specific documents. They, 175 especially STD, have been less successful than its original 176 description [RFC1311] or RFC 1796 might have anticipated, i.e., for 177 distinguishing between standards and other documents. At least part 178 of the reason has been that those numbers are not assigned to 179 Proposed (and, earlier, Draft) Standards and much of the Internet 180 continues to run on Proposed Standards and legacy Draft Standards. 181 By contrast, "BCP" has worked rather well for identifying those 182 documents (although some people still believe that conflating IETF 183 process documents with operational best practice ones in the same 184 subseries has been a mistake). 186 Arguably the main reason those numbering subseries have not been more 187 successful is that we have not used them consistently in citations, 188 rather than using RFC numbers. At least part of the problem is that 189 our tooling has historically favored use of RFC numbers rather than 190 the subseries ones and there has not been good guidance as to when to 191 use RFC numbers and when to use the subseries ones, especially when 192 the subseries designation refers to more than one document. It is 193 probably worth noting that a document that is a good candidate for 194 the RFC most-cited by others, RFC 2119, is almost always referred to 195 by its RFC number rather than as BCP 14, a situation that is actually 196 a source of confusion since BCP 14 now includes the modifications in 197 RFC 8174. The issues of what should be referenced and how, and 198 appropriate tooling to reinforce whatever decisions are made, would 199 face almost any new system, including qualifying labels, as well. 201 A very high-level overview of the proposal is to assign the same 202 sorts of labels contemplated in Section 2 and Section 3, but to treat 203 them as additional subseries labels rather than suffixes or 204 replacements. All traditional RFC Servies documents would continue 205 to receive RFC numbers, building on our experience with STD, BCP, and 206 FYI. As part of that process, the IETF would be required to consider 207 whether to apply "STD" to all standards-track documents as 208 contemplated by various proposals over the years 209 [Klensin-std-numbers] or to invent a separate category, e.g., "PSTD", 210 to distinguish between Proposed and Full Standards. 212 As with the Qualified Labels proposal, one of the advantages of this 213 approach is that we understand how to back away from if it turns out 214 to be either problematic or not worth the trouble. This proposal, 215 and both of those above, would commit us to maintaining, long-term, 216 effective and working cross-reference tables and collections of links 217 to find older documents together with newer ones (even if only to 218 resolve citations from documents that are not under the contorl of 219 the IETF community). That would not be a cost-free activity. Recent 220 experience with changes in the organization of the IETF's own web 221 pages suggest that we are not (or at least historically have not 222 been) good at similar tasks. 224 5. Possibility 4: Treat Problem as an Educational One 226 This possibility is somewhat different from the preceding two because 227 it makes a very different assumption about the problem to be solved. 228 The assumption is that most of those who are confused by the current 229 arrangements can be plausibly divided into three categories: 231 o Those who have been deliberately confused by others and who do not 232 actually read the documents, read only those sections suggested by 233 others, or read them very superficially. 235 o Those who read contemporary documents (as distinct from those 236 published before the latest revisions of status explanations 237 [RFC7841]) with a reasonable amount of care and who are still 238 confused about the status or origins of particular documents. 240 o Those who are confused about general relationships in the series 241 as distinct from about the status of particular documents. 243 This author and several others have suggested that the first category 244 above is hopeless, first because eliminating deliberate deception 245 (especially where lazy, willing, or stupid victims are involved) is 246 impossible without changes in human nature. Second, there is enough 247 evidence of sometimes-successful efforts to get people to believe 248 that very preliminary, non-WG, Internet Drafts are IETF products or 249 standards that it is almost certain that driving the deceivers away 250 from the RFC Series would simply cause more of the focus of their 251 efforts to shift to Internet Drafts. It is perhaps worth noting 252 that, no matter what we do about labels, as long as every RFC-like 253 document and every Internet Draft bears a notice claiming copyright 254 for the IETF Trust it will provide a foundation for those who want to 255 claim that all of them are IETF products (see Section 6 below). 256 Certainly neither of the possibilities above would be likely to 257 significantly impede efforts to deliberately confuse people. 259 The second category is problematic because there is little evidence 260 so far that, with regard to contemporary documents, its membership is 261 non-trivial. The language of the current statements and additional 262 hints in document structure appear to be very clear and, according to 263 the introductory material in RFC 7841, were adopted precisely to 264 address earlier text and arrangements that were less so. RFC 7841 265 was published only a bit over two years ago, some documents in the 266 RFC Series that were posted after it (or at least with higher 267 numbers) do not appear to support the new requirements, and it is 268 likely too early to tell how effective it will be in clarifying 269 differences about document origin and levels of consensus. The need 270 for more time to evaluate its success actually cuts both ways -- it 271 is possible that the new text and organization got extra attention 272 because it was new and that, as people get used to it, it will just 273 be skimmed over as more pointless boilerplate. That might require 274 other corrections in the future almost independent of what is done 275 with labels or other series identifiers. 277 Nonetheless, if the explanations in current RFCs (deriving from RFC 278 7841) are inadequate, the correct fix is probably to re-open and 279 rethink that document instead of, or possibly in addition to, 280 attempting to reorganize the RFC Series or its labels. 282 The third category relates primarily to how the RFC Series is 283 organized and what documents appear in it. That appears to be a 284 rather different problem from the claimed one that was described in 285 the BOF request. If new labeling models are added to the connection 286 handled through the RFC Editor function, copyrighted by the IETF 287 Trust, etc., it is quite likely that confusion about different 288 sources and status within that collection of documents will increase 289 rather than decrease, at least in the short to medium term. Unless 290 we do something far more radical than I believe has been seriously 291 proposed (see Section 6), the solution to confusion about 292 relationships among documents processed by the RFC Editor is more 293 likely to lie in better explanatory materials (RFC 4844 [RFC4844] is 294 definitely not a tutorial and was not intended to be) and more 295 obvious references to them, not, or not just, in tinkering with 296 document names. 298 6. Possibility 5: The Really Radical Solution 300 This proposal is a strawman to help clarify the options. I believe 301 it would be a terrible idea but can imagine that some people would 302 disagree. Certainly there have been suggestions on the mailing list 303 that could lead in this direction, but I'm not aware of anyone going 304 all the way to this approach as a conclusion. 306 The RFC Series was intended, at the beginning, to be a very broad 307 collection of notes and thoughts about aspects of the network 308 considered very broadly [RFC0003] and evolved considerably over the 309 next decade and a half [RFC0825], with IETF documents included after 310 the IETF got started a few years later and only later including what 311 became known as standards or standards track documents. Subsequent 312 to that, we've explicitly distinguished between types of documents 313 (Standards Track, BCP, Informational, Experimental) and then made the 314 relationships we call Streams explicit. We have also spent a lot of 315 time and other resources trying to get copyrights and other IPR 316 issues associated with the Series just right and, as noted above, 317 have made some decisions that may aid those who benefit from 318 confusion. Most of us who have been involved with software and 319 protocols for many years know that patching, and adding patches on 320 top of patches, eventually turns into a problem of its own. It may 321 still be the right solution to keep doing that, but perhaps it is 322 time to ask the question of whether, if we actually have a serious 323 problem, the RFC Series, as a series and as an RFC Editor Function 324 that serves different streams with at least slightly different 325 conventions, priorities, and authority models is reaching the end of 326 its useful life or that the community has outgrown it. If so, rather 327 than trying to sort out the best, or least problematic, next patch 328 while acknowledging that it will leave problems unsolved, we should 329 be thinking through how to retire the "RFC" concept and Series. That 330 would imply putting the IETF Stream (presumably with new names) more 331 squarely under the control of the IETF, IESG, and, where relevant, 332 the IETF Trust, rather than having a mostly-independent RFC Series 333 Editor and RFC Editor Function, and thinking about ways to deal with 334 what we have been calling other streams as entirely separate document 335 collections with their own (or at least separate from the IETF) 336 editorial and publishing arrangements and so on. 338 As has been pointed out on-list in another context, history would 339 strongly suggest that, if we were to move in that direction, the IETF 340 should effectively reverse the decisions made years ago, first to 341 publish its documents in the RFC Series and then to publish its 342 standards there, create its own names, and leave the "RFC" title (and 343 whatever was useful of the RFC Editor Function) to the other streams 344 if they could agree, but maybe it is too late for that. 346 Again, I don't believe that is a good idea. I believe that sorting 347 out a transition and doing a lot of retroactive work, keeping new 348 documents properly linked to older ones, or both, would prove 349 incredibly painful and costly in terms of community time and, 350 specifically, IETF, IAB, RFC Editor, and IASA time and other 351 resources. Almost certainly, there would be a great deal of 352 confusion during the transition period, which might be longer than we 353 would expect. However, it is not completely obvious that, for 354 example, sorting out all of the issues with the initial proposal made 355 for the BOF (as in Section 2 above, in the associated Internet Draft 356 [Thomson-RFCplusplus], or other small variations), including those 357 with references among documents and actually being ready to 358 transition out of the experiment should that prove necessary, would 359 be enough less painful and costly that, if giving up on the RFC model 360 had enough other potential benefits, it should not be considered as 361 an alternative. 363 7. Additional Possibilities and Evaluation 365 The possibilities listed above are, of course, not exhaustive and 366 more ideas may be suggested that are preferable to any of them. The 367 author of this draft would urge that people balance the choices 368 against whatever is agreed about the problem to be solved (i.e., 369 whether the proposed solution will really solve or significantly 370 mitigate that problem), the costs of making changes and conversions 371 (noting that any change involves costs including creating confusion 372 for those who are used to the current system), and the risks if any 373 changes (whether couched as experiments or not) fail and we have to 374 back out of those changes. 376 8. Acknowledgements 378 Brian Carpenter's analysis of the issues involved in suggested 379 changes to the RFC Series and his specific proposal (in Section 3 380 above) were essential to motivating this draft and much of its 381 content. Late posting of thise draft would have been impossible 382 without Alissa Cooper's agreement, which is greatly appreciated 384 9. IANA Considerations 386 [[CREF1: RFC Editor: Please remove this section before publication.]] 388 This memo includes no requests to or actions for IANA However, those 389 considering the costs of various possible changes should note that 390 changing our document model will likely require some corresponding 391 changes for IANA's registries and tools, an update to our IANA 392 Considerations model [RFC8126], or other adjustments. 394 10. Security Considerations 396 -- To be supplied in later iterations if there are any -- 398 11. Informative References 400 [Klensin-std-numbers] 401 klensin, J., "STD Numbers and the IETF Standards Track", 402 July 2018, . 405 [RFC0003] Crocker, S., "Documentation conventions", RFC 3, 406 DOI 10.17487/RFC0003, April 1969, 407 . 409 [RFC0825] Postel, J., "Request for comments on Requests For 410 Comments", RFC 825, DOI 10.17487/RFC0825, November 1982, 411 . 413 [RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311, 414 DOI 10.17487/RFC1311, March 1992, 415 . 417 [RFC1796] Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are 418 Standards", RFC 1796, DOI 10.17487/RFC1796, April 1995, 419 . 421 [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC 422 Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, 423 July 2007, . 425 [RFC7841] Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed., 426 "RFC Streams, Headers, and Boilerplates", RFC 7841, 427 DOI 10.17487/RFC7841, May 2016, 428 . 430 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 431 Writing an IANA Considerations Section in RFCs", BCP 26, 432 RFC 8126, DOI 10.17487/RFC8126, June 2017, 433 . 435 [RFCplusplus-list] 436 IETF, "Mailing list for the RFC++ BoF", 437 email rfcplusplus@ietf.org, July 2018. 439 [RFCplusplus-proposal] 440 Thomson, M. and M. Shore, "The label "RFC" (RFCplusplus)", 441 June 2018, . 443 [Thomson-RFCplusplus] 444 Thomson, M., "The Label 'RFC'", draft-thomson-rfcplusplus- 445 label (work in progress), July 2018, 446 . 449 Author's Address 451 John C Klensin 452 1770 Massachusetts Ave, Ste 322 453 Cambridge, MA 02140 454 USA 456 Phone: +1 617 245 1457 457 Email: john-ietf@jck.com