idnits 2.17.1 draft-klensin-newtrk-8540style-harmful-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document updates RFC4460, but the header doesn't have an 'Updates:' 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 (June 7, 2019) is 1785 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 8540 (Obsoleted by RFC 9260) -- Duplicate reference: RFC8540, mentioned in 'LC8540-Ballot', was also mentioned in 'RFC8540'. -- Obsolete informational reference (is this intentional?): RFC 8540 (Obsoleted by RFC 9260) -- Duplicate reference: RFC8540, mentioned in 'LC8540-Statement', was also mentioned in 'LC8540-Ballot'. -- Obsolete informational reference (is this intentional?): RFC 8540 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 4460 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft June 7, 2019 4 Intended status: Informational 5 Expires: December 9, 2019 7 RFC Publication of Errata of Standards Track Documents Considered 8 Harmful 9 draft-klensin-newtrk-8540style-harmful-00 11 Abstract 13 There appear to be some recent trends in the IETF, involving both 14 published documents and proposals, to use Informational Documents to 15 effectively update Standards Track ones, presenting documents as 16 normative while avoiding the requirements for a higher level of 17 community review and consensus and relationship tracking that would 18 be required, in practice, for Standards Track updates RFC 4460, 19 titled "Stream Control Transmission Protocol (SCTP) Specification 20 Errata and Issues" and RFC 8540, titled "Stream Control Transmission 21 Protocol: Errata and Issues in RFC 4960", were published as 22 Informational documents although their clear intent is to update, or 23 posit alternatives to some of the provisions of, RFcs 2960 and 4960 24 respectively. This critique suggests that it is undesirable for the 25 IETF to publish documents of that type and form, explains the 26 reasons, and identifies several alternatives. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 9, 2019. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Identifying Issues with Informational Updates or Reflections 64 on Standards Track Documents . . . . . . . . . . . . . . . . 3 65 2.1. Use of Normative Languege . . . . . . . . . . . . . . . . 4 66 2.2. Failure to Explicitly Update Precedessor Documents . . . 4 67 2.3. Usability: Organization by Erratum Date and Number . . . 5 68 2.4. IETF Consensus and "Verified" Errata . . . . . . . . . . 6 69 3. Problem Statement and Alternatives . . . . . . . . . . . . . 6 70 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 8.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 Recent developments strongly suggest that IETF procedures and 82 criteria for accepting and publishing documents, particularly 83 Informational documents that appear to modify Standards Track ones, 84 are in need of review. This document is a critique of those 85 criteria, using two recent published documents as examples of styles 86 and practices that should, in the opinion of the author, not be 87 repeated. It does not alter or update the content of the RFCs 88 mentioned in this document as examples, nor does it address the 89 substantive content of those RFCs. The intention of this document is 90 to encourage the IETF (and any relevant related bodies) to address 91 any issues around using Informational RFCs to demonstrably update 92 Standards track RFCs in a different way in the future. 94 RFC 4460, titled "Stream Control Transmission Protocol (SCTP) 95 Specification Errata and Issues" [RFC4460] and RFC 8540, titled 96 "Stream Control Transmission Protocol: Errata and Issues in RFC 4960" 97 [RFC8540], were Informational documents although their clear intent 98 was to update RFcs 2960 [RFC2960] and 4960 [RFC4960] respectively or 99 at least to posit alternatives to some of the specifications in those 100 documents in a way that calls them into doubt. This critique 101 suggests that it is undesirable for the IETF to publish documents of 102 that type and form, explains the reasons, and identifies several 103 alternatives. 105 This document does not alter or update the content of RFCs 2960 or 106 4960 in any way, nor does it address the substantive content of RFCs 107 4460 or 8540. While it includes an analysis of the structure, 108 organization, and some of the statements of the latter two (focusing 109 on RFC 8540 as the more recent example), those documents are only 110 particular examples. 112 2. Identifying Issues with Informational Updates or Reflections on 113 Standards Track Documents 115 There have been many discussions in the IETF over the years about 116 people who have confused RFCs, including Informational and 117 Experimental ones, with IETF Standards. Other discussions -- which 118 some see as related and others do not -- have focused rather more on 119 how readers, implementers, and others who depend on standards are 120 expected to figure out exactly what documents or portions of 121 documents are normatively part of a given standard (see the 122 discussion of the NEWTRK effort in Section 3). While it would be 123 difficult to characterize the overall community consensus on these 124 points in any simple way, three things are clear. First, no 125 significant changes have been made in this area in the last decade 126 (and probably not in the more than two decades since RFC 2026 127 [RFC2026] was published). Second, there is little the IETF or RFC 128 Editor can do in terms of procedures or document structure that will 129 prevent any confusion that is caused deliberately by organizations 130 trying to trick others into believing that their non-standards track 131 RFCs (or, for that matter, Internet-Drafts) are actually IETF 132 standards. And finally, that Informational documents that appear to 133 be Standards Track ones or updates to them are almost certainly an 134 invitation to confusion about what, exactly, is the standard. 136 Using the recently-published RFC 8540 as an example, this section 137 identifies and discusses several of the issues with updates or 138 apparent updates to standards track documents, especially 139 Informational ones. It is worth reiterating that, while RFC 8540 is 140 the example used, there are other RFCs that have been published (as 141 well as future works that might be introduced) that fall into these 142 areas of concern. Those include, in particular, RFC 4650, mentioned 143 above, which apparently acted as the inspiration and justification 144 for 8540. 146 2.1. Use of Normative Languege 148 The text of RFC 8540 uses standardized, BCP 14, IETF normative 149 language [RFC2119] [RFC8174] in many places. Although most or all 150 are quotations from suggested text in errata (see below), Section 2 151 of the RFC specifies use of those terms and their interpretation in 152 the usual normative sense. 154 Even when explicit terminology conforming to RFC 2119 is not used, 155 the document strongly implies that the changes it suggests are 156 normative and replace text in the earlier document. For example, 157 even the abstract says "It provides deltas to RFC4960", which is 158 consistent with approved updates to that document, not just 159 suggestions in the relevant errata (see Section 2.2 and Section 2.4). 161 Given the long history of concerns and complaints about confusion of 162 Informational and Experimental documents with standards track ones, 163 use of normative language in RFCs that are not on standards track is 164 almost certainly undesirable. If such use in a particular document 165 cannot be avoided, the use should almost certainly be associated with 166 clear, document-specific, explanations about the status of the 167 document and that terminology, rather than just relying on generic 168 boilerplate that few people read carefully. 170 2.2. Failure to Explicitly Update Precedessor Documents 172 The documents in the RFC Series have always been considered to be 173 archival: for historical and other reasons, documents, once issued, 174 may be replaced or updated by other documents but are not, 175 themselves, ever changed (RFC 4844 Section 4.3 [RFC4844]). In some 176 ways, that principle is in conflict with generally recognized good 177 practices for standards documents where it is an advantage to have 178 only one current document describing a standard and for references to 179 that standard to be stable and point to the latest version. There 180 has, so far, been clear consensus in the IETF that the tradeoffs 181 required for an archival series are worth it although there have been 182 various efforts to mitigate the perceived conflicts with alternate 183 numbering overlays such as BCP and STD numbers and the former FYI 184 series. 186 However, one of the long-standing consequences with the archival 187 policy that RFCs, once issued, are never modified and reissued under 188 the same number is that one cannot look at a document and tell 189 whether it has been replaced or updated by others or not. If one has 190 access to an RFC index (and thinks to look), "updated by" and 191 "obsoleted by" information is available there or one can search newer 192 documents to see the relationship to earlier ones. However, if an 193 Informational RFC is issued that merely summarizes suggested changes, 194 whether based on errata or not, there are no such metadata threads -- 195 the only way one can start with the original document and find the 196 commentary involves searching for document numbers in titles, a 197 procedure that is notoriously unreliable (in part because such titles 198 have been discouraged in the past). So, whatever the intention was 199 for issuing such a document, it is unlikely to be helpful except to 200 those who find out about the relationship by other means. 202 2.3. Usability: Organization by Erratum Date and Number 204 Possibly as a result of wanting to get documents published quickly as 205 Informational ones, some of the documents that are the subject of 206 this critique are inconsistent with the tradition of the RFC Series 207 publishing documents that are comprehensible and useful to the 208 reader. 210 For example, RFC 8540 is organized in sequential order by errata 211 number, which is equivalent in most or all cases to sequential by 212 date. While that may provide a useful historical record (or not), it 213 makes it nearly impossible to understand from a protocol or 214 implementation perspective unless readers carefully go through all 215 pages (more than ninety in the case of 8540) and make their own 216 notes. The RFC actually identifies the most serious part of that 217 problem in the last paragraph of the introduction (Section 1) which 218 says that the reader "must use care to ensure that a field or item is 219 not updated later on within the document." In some cases, e.g., at 220 the end of Section 3.1.2, partial cross-references appear and 221 mitigate the problem somewhat, but many of the cross-references that 222 could make the document easier to follow are either missing or merely 223 provide a strong hint that the reader must study the entire document. 225 Similarly, even with the ordering of material as described above, the 226 document could have been made considerably more useful if it had 227 indexes by topic and by section of the base documents (RFC 4960 in 228 the case of 8540). The IESG has asserted in the past that their 229 obligations to the community for documents that they intended to 230 publish in the IETF's name included requiring that indexes be added 231 when doing so was needed for document clarity or usability. Such 232 indexes were not provided. Unless the IESG has changed its position 233 on its responsibilities and authority, that is, at best, a lost 234 opportunity. 236 2.4. IETF Consensus and "Verified" Errata 238 The status boilerplate for RFC 8540 indicates that it "represents the 239 consensus of the IETF community". That is fine, but it is unclear 240 what IETF consensus represents in the case of a document that appears 241 to be normative. If it is just consensus that the document should be 242 published, that should be clear and should be clear in text, not just 243 in boilerplate. Certainly it does not represent consensus that all 244 "verified" errata have been accepted by the IETF community as a 245 correct description of the listed issues and appropriate fixes for 246 them: verification of errata normally involves only authors, WG 247 Chairs (if the document was produced by a still-active WG), and 248 relevant Area Directors. 250 There is, of course, also the very old question of whether a document 251 that is approved for publication by the IESG with one "yes" vote and 252 the rest of the IESG being on record as having no objection (in 253 several cases, after expressing one or more), abstaining, or not 254 recording a position (see Section 5). 256 Contrary to the apparent claim in the documents that their contents 257 simply reproduce the verified errata and the changes they specified, 258 the ballot report on the RFC-to-be strongly implies that IESG members 259 felt it was entitled to second-guess that text and suggest other 260 solutions [LC8540-Ballot]. That suggests another difficulty with the 261 approach used in RFC 8540: if the IESG members are correct and the 262 proposals in the errata should be adjusted to reflect the IETF 263 community's best understanding, then the document is no longer an 264 (Informational) errata summary; if the errata contents are preserved, 265 then the document probably does not represent IETF consensus about 266 what should be done. 268 3. Problem Statement and Alternatives 270 The discussion above strongly suggests that publishing Informational 271 documents in the RFC Series that appear to update Standards Track 272 ones is not a good idea. The WG suggested in its summary for IETF 273 Last Call for what became RFC 8540 that an errata listing like that 274 provided by RFCs 4460 and 8540 is helpful in producing replacements 275 for the original documents [LC8540-Statement] but there is no 276 evidence that the same purpose could not be served by retaining the 277 same list as an Internet-Draft until the actual replacement document 278 is ready to be published and then either discarding that I-D or, if 279 the WG felt a need to do so, incorporating the errata listing as an 280 appendix in the final document. Keeping the errata summary as an 281 Internet-Draft, rather than publishing it as an RFC would also 282 eliminate some of the questions about consensus discussed in 283 Section 2.4. 285 In addition to the "just don't do this" approach that is at least 286 implicitly suggested above, the IETF has considered several other 287 approaches to the problem of Standards Track documents that have 288 accumulated extensive errata or otherwise require minor or major 289 upgrades. One thing all of them seem to have in common is that all 290 of these alternatives involve Standards Track documents, allowing the 291 traditional "updates" and "obsoleted" mechanisms to be used, thereby 292 addressing at least some of the concerns described in Section 2.2. 293 After that, those proposals diverge, at least in part based on the 294 specific view they have of the problem or how much of the problems 295 they have wished to take on. 297 One recent draft addresses minor (or "non-major") replacements to 298 existing documents [ID.draft-roach-bis-documents], but it has become 299 clear from discussions on the IETF mailing list (and the document 300 itself) that there is disagreement about the circumstances to which 301 it is applicable. At least in its initial draft, Section 4 of that 302 Internet-Draft argues strongly for avoiding incremental updates 303 rather than generating and publishing replacement documents. 305 A difficulty with any "just replace the earlier document" approach is 306 that the IETF has often found it to be necessary, or at least 307 desirable, to define protocols in several different documents 308 covering different aspects or components of the whole and sometimes 309 updated or extended separately. Producing a complete and 310 comprehensive revision each time would, even if desirable, simply 311 take long enough to be inconsistent with the speed at which the 312 Internet has historically evolved. As those documents are extended 313 or updated in turn and documents are obsoleted without everything 314 that points to them being replaced (or at least clearly identified 315 and their status clarified), there are significant opportunities for 316 confusion about what is, or is not, included in a particular standard 317 that even a "just replace" model would not solve. In the 2003-2006 318 period, the IETF created a WG, called NEWTRK [NEWTRK-charter] 319 [NEWTRK-WG]. NEWTRK was, among other things, intended to address the 320 question of interrelationships among standards and updates and to 321 provide a framework for documents that -- in the form of 322 Applicability Statements [RFC2026] or otherwise -- would be able to 323 conveniently describe (or at least identify) the component parts of a 324 standard, the relationships among them, implementation status where 325 appropriate, and to do so without being limited by the restrictions 326 associated with, e.g., RFCs with STD numbers. While the WG produced 327 multiple documents that were intended to address those issues and 328 reached rough consensus on at least some of them, the effort never 329 led to actual changes. The reasons for that are probably not worth 330 too much effort or speculation now (well over a decade later) but it 331 may be appropriate to ask questions about whether the time is now 332 right to address the more fundamental issues raised by NEWTRK. 334 Even without opening up the standards process and document model as 335 NEWTRK proposed, if a summary of issues in a standard (with or 336 without recommendations) is needed before an update or replacement 337 document can be generated, that is an entirely appropriate role for 338 an Applicability Statement. 340 4. Conclusion 342 The analysis in this document suggests that Informational documents 343 that are written with the appearance of Standards Track ones, 344 especially when they appear to update one or more Standards Track 345 documents, use language or references that the IETF normally reserves 346 for requirements in standards track documents, and/or creates 347 confusion about assertions of IETF consensus are, at best, 348 undesirable. 350 As particularly problematic examples, RFCs 4460 and 8540 are written 351 as Informational RFCs whose text strongly suggests that they provide 352 definitive updates to Standards Track documents. That is a bad idea 353 for many reasons of which the most important may be that they have 354 high potential for creating confusion as to what the relevant 355 standard actually is and what features and possible changes actually 356 represent IETF consensus. Their problems are compounded by an 357 organizational style --and the absence of comprehensive indexes or 358 cross-references -- that makes it quite hard to follow them and the 359 recommendations they are making. 361 The IETF has multiple alternatives to that approach. They include 362 creating the list of errata as an Internet-Draft but publishing only 363 a updating or replacement document in the RFC Series, publishing 364 documents of this type only if they are extensively revised to 365 explain exactly what they are and to eliminate any language that can 366 be construed as either normative or making assertions about IETF 367 consensus on technical issues, publishing one or more Applicability 368 Statements to describe the issue with the original specification, or 369 moving toward standards status documents as envisioned by NEWTRK. 370 All but the last are possible today; any of them would be a better 371 solution than Informational documents with content and structure 372 similar to RFCs 4460 and 8540. 374 5. Acknowledgements 376 While the initial working draft of this document was largely underway 377 before the author reviewed the IESG ballot comments on RFC 8540, the 378 ballot comments by Ignas Bagdonas, Ben Campbell, Alissa Cooper, 379 Suresh Krishnan, Terry Manderson, Alexey Melnikov, Eric Rescorla, 380 Alvaro Retana, Adam Roach, and Martin Vigoureux strongly reinforced 381 the conclusion that this document was necessary and informed some of 382 the text. 384 Spencer Dawkins and Heather Flanigan made suggestions about an an 385 intermediate draft that preceded the first posted version. 387 6. IANA Considerations 389 This memo includes no requests to or actions for IANA. However, if a 390 Standards Track document contains specifications for IANA and an 391 Informational one were to appear to update those instructions, that 392 would create ambiguities for IANA as well as the broader community. 394 7. Security Considerations 396 While this critique does not address security issues directly, the 397 security of the Internet is almost certainly improved when the IETF 398 does not introduce confusion about the status of its protocols. 400 8. References 402 8.1. Normative References 404 [RFC8540] Stewart, R., Tuexen, M., and M. Proshin, "Stream Control 405 Transmission Protocol: Errata and Issues in RFC 4960", 406 RFC 8540, DOI 10.17487/RFC8540, February 2019, 407 . 409 8.2. Informative References 411 [ID.draft-roach-bis-documents] 412 Roach, A., "Process for Handling Non-Major Revisions to 413 Existing RFCs", May 2019, 414 . 417 [LC8540-Ballot] 418 IETF Internet Engineering Steering Group (IESG), "Stream 419 Control Transmission Protocol: Errata and Issues in RFC 420 4960: IESG Writeups", 2018, 421 . 423 [LC8540-Statement] 424 IETF Transport Area Working Group, "Stream Control 425 Transmission Protocol: Errata and Issues in RFC 4960: 426 Approval Announcement: Working Group Summary", 2018, 427 . 429 [NEWTRK-charter] 430 IETF, "New IETF Standards Track Discussion", 2006, 431 . 433 Retrieved 2019-06-02 435 [NEWTRK-WG] 436 IETF, "New IETF Standards Track Discussion (newtrk)", 437 September 2006, 438 . 440 Retrieved 2019-06-02 442 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 443 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 444 . 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", BCP 14, RFC 2119, 448 DOI 10.17487/RFC2119, March 1997, 449 . 451 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 452 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 453 Zhang, L., and V. Paxson, "Stream Control Transmission 454 Protocol", RFC 2960, DOI 10.17487/RFC2960, October 2000, 455 . 457 [RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and 458 M. Tuexen, "Stream Control Transmission Protocol (SCTP) 459 Specification Errata and Issues", RFC 4460, 460 DOI 10.17487/RFC4460, April 2006, 461 . 463 [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC 464 Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, 465 July 2007, . 467 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 468 RFC 4960, DOI 10.17487/RFC4960, September 2007, 469 . 471 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 472 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 473 May 2017, . 475 Author's Address 477 John C Klensin 478 1770 Massachusetts Ave, Ste 322 479 Cambridge, MA 02140 480 USA 482 Phone: +1 617 245 1457 483 Email: john-ietf@jck.com