idnits 2.17.1 draft-thomson-rfcplusplus-label-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 document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 02, 2018) is 2124 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 386 -- Looks like a reference, but probably isn't: '2' on line 388 -- Looks like a reference, but probably isn't: '3' on line 390 -- Looks like a reference, but probably isn't: '4' on line 392 == Outdated reference: A later version (-14) exists of draft-pantos-hls-rfc8216bis-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Experimental July 02, 2018 5 Expires: January 3, 2019 7 The Label "RFC" 8 draft-thomson-rfcplusplus-label-00 10 Abstract 12 The perception and reality of the RFC series have long been separate. 13 More than 20 years of attempts to correct perception, starting with 14 RFC 1796, have been unsuccessful. This document proposes an 15 experiment to see if changing the labels on document will have any 16 effect on fixing that problem. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 3, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 1. Introduction 52 RFC 1796 [RFCS] was published in April of 1995. At that time, it was 53 clear that there was an "regrettably well spread misconception" that 54 the label "RFC" implied "some level of recognition". Not a lot has 55 changed in the 23 years since that statement. 57 The common perception of the significance of the "RFC" label is 58 simple. That simple interpretation doesn't capture the broad range 59 of uses that the label is applied to. The view expressed in RFC 1796 60 was that this loss of information was adequately addressed by further 61 engaging in dialog. This includes the provision of prominent notices 62 in documents, such as the "Status of this Note" section, as well as 63 providing explanations about what documents mean. This view further 64 holds that the merits of a document do not solely derive from the 65 status of the document, but from the quality and substance of its 66 contents. 68 This document suggests that this view to some degree underestimates 69 the value of a label (or "brand"). It also overestimates the 70 willingness of audiences to engage with the nuanced interpretation 71 that is required to appreciate the complexity of a document. An RFC 72 can address complex technical matters that require considerable 73 expertise in the field to understand with enough detail to appreciate 74 the full implications. 76 The Internet Standards Process [RFC2026] describes a process that has 77 consistently produced quality documents. This document proposes an 78 experiment that limits the use of the "RFC" label to the product of 79 that process. 81 The value of the other documents currently published on the RFC 82 series is undeniable. The creation of new series' for documents 83 produced by different processes will ensure that critical information 84 - and dissenting viewpoints - retain a venue for reaching an 85 audience. 87 2. Nuance in Interpretation 89 Misconceptions about the significance of publication as an RFC is 90 commonplace. This isn't a design failure, but an inherent property 91 of the current system of document streams. However, that potential 92 for misunderstanding can be problematic. 94 Capturing the nuance required to properly understand a protocol is 95 difficult, and a large number of documents fail to properly convey 96 that status. 98 For example, ZRTP [RFC6189] was published as an informational RFC on 99 the IETF stream after the IETF reached consensus to develop DTLS-SRTP 100 [RFC5764] for the same use case. 102 Similarly, HTTP Live Streaming (HLS) [RFC8216] was published on the 103 Independent Submissions Stream in defiance of a standardized 104 protocol, MPEG-DASH [DASH]. 106 Both describe de-facto standards, each of which are implemented in 107 more than one product and deployed. Both are also highly 108 contentious. 110 Each captures a range of design decisions that differ from the 111 commonly-accepted view. Aspects of these designs have merit and 112 documenting them has value, if only from the perspective of 113 understanding alternative approaches. 115 That value does not naturally extend to deployment, even if each 116 document contains enough detail to implement and deploy the protocol 117 they describe. If nothing else, the deployment of these protocols 118 could adversely affect interoperability relative to implementations 119 of their more widely accepted alternatives. 121 Information about the status of the document is contained entirely in 122 the "Status of this Note" section. For instance, ZRTP is published 123 with IETF consensus, so the significance of it not being an "Internet 124 Standards Track specification" is easily lost. That it also limits 125 its mention of DTLS-SRTP to comparative criticisms makes it possible 126 to interpret the document as it represents itself: a newer, superior 127 technique. 129 There are numerous examples of RFCs that make an honest 130 representation of their status in more than just the boilerplate. In 131 addition to those proprietary documents that identify that status in 132 their title, a number of documents are clear about status and intent. 133 For example, though RFC 6886 [NAT-PMP] was deployed, it includes 134 clear statements on status, as well as sections on how to migrate to 135 the IETF consensus protocol [RFC6887]; to go further, because RFC 136 5690 [ACK-CONGESTION] was never deployed, it avoids any 137 misapprehension by not requesting allocation of necessary codepoints. 139 3. No Shortage of Venues for Publication 141 So why is the publication of an RFC so keenly sought, when the 142 document doesn't capture the output of the Internet Standards 143 Process? 144 It might be reasonable to say that the goal is to create a stable, 145 referenceable specification for a technology that might be of 146 interest to the Internet community. This view is consistent with the 147 rationale given in the Section 2 of [RFC4846], which formalized the 148 Independent Submissions Stream. 150 For the examples given, a principled reason for publication is well 151 justified. While neither document represents IETF consensus, they 152 are both technical contributions of some value. 154 It's not obvious that this goal is not accomplished by publishing 155 specifications on a web site. For instance, the examples from 156 Section 2 both ZRTP and HLS have a presence on the Internet where 157 specifications and related material are published 158 (http://zfoneproject.com/zrtp_ietf.html [1] and 159 https://developer.apple.com/streaming/ [2] respectively). The 160 Internet Archive (https://web.archive.org/ [3]) shows that these 161 sites have been available and stable for an extended period. 162 Furthermore, both websites publish links to updated specifications 163 ([ZRTPBIS] and [HLSBIS]). 165 If the intent is to reach an IETF audience, then there are many other 166 venues for publication that achieve the same goal. For instance, 167 input from the academic community is often provided in the form of 168 papers. Other inputs variously use blogs, journal articles, source 169 code repositories, and even posts to mailing lists. For work that is 170 taken as a normative dependency a higher standard of publication is 171 likely necessary, but most of these alternative forms can be cited 172 informatively. 174 4. RFC == Standards Track 176 This documents proposes reserving the "RFC" label for those documents 177 that are the product of the Internet Standards Process [RFC2026]. 179 It's true that the Internet Standards Process isn't perfect and it 180 cannot guarantee a particular level of quality. Any failings can 181 (and should) be addressed by improving the process. 183 Reserving the RFC Series for the publication of products of the 184 Internet Standards Process would ensure clarity about what "RFC" 185 means. 187 4.1. New Labels for Other Documents 189 The IETF publishes informational and experimental documents. The 190 expectations around what level of agreement is necessary to publish 191 these documents differs from documents published on the standards 192 track. These documents should use other labels. 194 The IETF publishes best current practice (BCP) documents that 195 describe its own processes. These don't codify agreement about a 196 protocol inasmuch as they don't describe something implemented in 197 software. They do follow the same processes and require similar 198 levels of agreement. Use of the RFC label for BCP documents is 199 appropriate, though there is no inherent reason not to use another 200 label either. 202 Similarly, the IRTF and IAB produce documents that do not represent 203 an agreement in the same way. These documents should use other 204 labels. 206 The possible exception to this are the documents produced by the 207 Crypto-Forum Research Group (CFRG). If it is considered important to 208 publish CFRG documents with the "RFC" label, then it should be 209 possible to attain IETF consensus for publication in the RFC Series. 211 The Independent Submissions Editor also publishes RFCs. These 212 documents should use other labels. 214 4.2. No Change to Existing Documents 216 There is no point in revising existing documents. These documents 217 were published with an expectation of immutability. Thus, any 218 attempt to relabel these would be limited to changing document 219 metadata. Copies of documents taken prior to any updates might not 220 be updated. 222 Any misconception that might exist in relation to existing documents 223 is likely irreparable. Retracting the issuance of RFC numbers for 224 the hundreds of documents that might need to be assigned new labels 225 retrospectively isn't realistic. Thus, this document does not 226 propose any action for documents already published. 228 4.3. Should the Experiment Fail 230 If the community determines that the negative consequences of this 231 experiment outweigh the benefits, then documents published with new 232 labels will be allocated RFC numbers. This requires that during the 233 experiment: 235 o the altered publication system needs to produce an output for 236 affected documents that would be compatible with later publication 237 as RFC; and 239 o the ongoing experiment - specifically its potential for failure - 240 be considered when implementing changes to processes on affected 241 streams. 243 It might also be possible to reserve RFC numbers, which would 244 preserve the loosely chronological ordering of RFCs by number. This 245 document does not take any position on whether this effort would be 246 worthwhile. 248 4.4. A New Label is Necessary 250 Almost every RFC published in the last 35 years contains a "Status of 251 this Memo" section. Recent documents include a markings in the 252 header, signifying the stream and status (or category). In addition, 253 the most widely used source for RFCs, https://tools.ietf.org/html/ 254 [4], uses a colour-coding scheme to highlight the status of 255 documents. 257 The "STD" label hasn't been especially effective in distinguishing 258 those documents that attain the rare status of Full Internet 259 Standard. The BCP subseries has been more effective, perhaps because 260 of the greater familiarity of its primary audience with its meaning. 262 It's possible that with a move to presenting RFCs in HTML rather than 263 text, new methods of signaling status could be developed. For 264 instance, using styling such as colour, layout, or font choice to 265 represent origin and status. However, the choice of rendering is not 266 part of the canonical XML document. Alternative renderings could 267 legitimately erase that information. 269 That leads to the conclusion that clearer marking for status, while 270 possibly helpful, would not be sufficiently effective in addressing 271 the problem. 273 5. How To Measure Success 275 A term of 3 years is proposed as being long enough to provide enough 276 evidence to assess the effect of a change of labels. 278 One hypothesis this experiment proposes to test is the degree to 279 which the "RFC" label motivates authors seeking publication. Though 280 numbers are unlikely to provide a clear answer when so much of the 281 problem is subjective, measuring the rate of submission and 282 publication for affected documents could provide some insight. 284 Measuring different sources gives a multiple perspectives relative to 285 the output of the standards process. For instance, informational 286 documents are closely related to the standards process and so are 287 hypothesized to be relatively unaffected by any change, whereas IAB 288 documents might follow a separate cadence and could be unaffected. 290 Documents published by the IETF as Informational, and those published 291 on the Independent Submissions Stream are most likely to have a high 292 enough volume to produce a large enough sample. Publication rates 293 for other sources might not be high enough to observe differences. 295 In the first test, the rate of requests for publication over time is 296 recorded. If the introduction of the experiment causes the number to 297 drop relative to long-term trends, then that drop might indicate that 298 interest in publication is driven in part by the label. 300 The second test will record the number of documents published using 301 new labels. A drop in publication rate relative to that of those 302 documents published with the "RFC" label could also indicate that a 303 change of label has some effect. 305 Trends in publication rates are easy to gather; some work might be 306 required to establish the rate of submissions prior to the 307 commencement of any experiment. 309 Any measurement is susceptible to noise, and the rate of publication 310 on many streams is not high, nor is it consistent. Some allowance 311 should be made for fluctuations as the experiment is commenced, or as 312 processes change to support the experiment. 314 6. Security and Privacy Considerations 316 It is believed that there are none. 318 7. IANA Considerations 320 This document makes no request of IANA. 322 8. References 324 8.1. Informative References 326 [ACK-CONGESTION] 327 Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding 328 Acknowledgement Congestion Control to TCP", RFC 5690, 329 DOI 10.17487/RFC5690, February 2010, 330 . 332 [DASH] "Dynamic adaptive streaming over HTTP (DASH)", ISO/ 333 IEC 23009-1, May 2014. 335 [HLSBIS] Pantos, R., "HTTP Live Streaming 2nd Edition", draft- 336 pantos-hls-rfc8216bis-02 (work in progress), June 2018. 338 [NAT-PMP] Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol 339 (NAT-PMP)", RFC 6886, DOI 10.17487/RFC6886, April 2013, 340 . 342 [NEWTRK-RFC] 343 Rosenberg, J. and A. Mankin, "What's In a Name: RFC", 344 draft-rosenberg-mankin-newtrk-rfc-00 (work in progress), 345 October 2004. 347 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 348 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 349 . 351 [RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent 352 Submissions to the RFC Editor", RFC 4846, 353 DOI 10.17487/RFC4846, July 2007, 354 . 356 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 357 Security (DTLS) Extension to Establish Keys for the Secure 358 Real-time Transport Protocol (SRTP)", RFC 5764, 359 DOI 10.17487/RFC5764, May 2010, 360 . 362 [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 363 Media Path Key Agreement for Unicast Secure RTP", 364 RFC 6189, DOI 10.17487/RFC6189, April 2011, 365 . 367 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 368 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 369 DOI 10.17487/RFC6887, April 2013, 370 . 372 [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", 373 RFC 8216, DOI 10.17487/RFC8216, August 2017, 374 . 376 [RFCS] Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are 377 Standards", RFC 1796, DOI 10.17487/RFC1796, April 1995, 378 . 380 [ZRTPBIS] Zimmermann, P., Johnston, A., and T. Cross, "ZRTP: Media 381 Path Key Agreement for Unicast Secure RTP", draft- 382 zimmermann-rfc6189bis-00 (work in progress), July 2016. 384 8.2. URIs 386 [1] http://zfoneproject.com/zrtp_ietf.html 388 [2] https://developer.apple.com/streaming/ 390 [3] https://web.archive.org/ 392 [4] https://tools.ietf.org/html/ 394 Acknowledgments 396 This isn't really a new position. It's a little embarrassing to find 397 that all these arguments are merely a reiteration of arguments 398 articulated more than a decade ago. [NEWTRK-RFC] contains many of 399 the same arguments. 401 Author's Address 403 Martin Thomson 404 Mozilla 406 Email: martin.thomson@gmail.com