idnits 2.17.1 draft-nottingham-where-does-that-come-from-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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (12 March 2021) is 1141 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft 12 March 2021 4 Intended status: Informational 5 Expires: 13 September 2021 7 Clarifying IETF Document Status 8 draft-nottingham-where-does-that-come-from-00 10 Abstract 12 There is widespread confusion about the status of Internet-Drafts and 13 RFCs, especially regarding their association with the IETF and other 14 streams. This document recommends several interventions to more 15 closely align reader perceptions with actual document status. 17 Note to Readers 19 _RFC EDITOR: please remove this section before publication_ 21 The issues list for this draft can be found at 22 https://github.com/mnot/I-D/labels/where-does-that-come-from 23 (https://github.com/mnot/I-D/labels/where-does-that-come-from). 25 The most recent (often, unpublished) draft is at 26 https://mnot.github.io/I-D/where-does-that-come-from/ 27 (https://mnot.github.io/I-D/where-does-that-come-from/). 29 Recent changes are listed at https://github.com/mnot/I-D/commits/gh- 30 pages/where-does-that-come-from (https://github.com/mnot/I-D/commits/ 31 gh-pages/where-does-that-come-from). 33 See also the draft's current status in the IETF datatracker, at 34 https://datatracker.ietf.org/doc/draft-nottingham-where-does-that- 35 come-from/ (https://datatracker.ietf.org/doc/draft-nottingham-where- 36 does-that-come-from/). 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on 13 September 2021. 55 Copyright Notice 57 Copyright (c) 2021 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 62 license-info) in effect on the date of publication of this document. 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. Code Components 65 extracted from this document must include Simplified BSD License text 66 as described in Section 4.e of the Trust Legal Provisions and are 67 provided without warranty as described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 73 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3 74 2.1. RFCs . . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2.1.1. Proposal 1: logo usage . . . . . . . . . . . . . . . 3 76 2.1.2. Proposal 2: visual distinction . . . . . . . . . . . 4 77 2.1.3. Proposal 3: domain usage . . . . . . . . . . . . . . 4 78 2.2. Internet-Drafts . . . . . . . . . . . . . . . . . . . . . 5 79 2.2.1. Proposal 4: logo usage . . . . . . . . . . . . . . . 5 80 2.2.2. Proposal 5: visual distinction . . . . . . . . . . . 5 81 2.2.3. Proposal 6: domain usage . . . . . . . . . . . . . . 5 82 2.2.4. Proposal 7: boilerplate . . . . . . . . . . . . . . . 6 83 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 84 4. Normative References . . . . . . . . . . . . . . . . . . . . 7 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 87 1. Introduction 89 There is widespread confusion about the status of Internet-Drafts and 90 RFCs -- specifically, regarding their association with the IETF and 91 other streams. It is commonly perceived that all RFCs and all 92 Internet-Drafts are associated with and approved by the IETF. 94 This is likely due to the conflation of the IETF and RFC brands; most 95 people think of them in close association, and do not appreciate the 96 concept of streams, because it is not surfaced obviously in the 97 documents. These impressions are reinforced by our reuse of IETF 98 infrastructure for publishing and managing drafts on other streams, 99 as well as drafts on no stream. 101 These observations are not new. In the past, changes to boilerplate 102 have been proposed and implemented to distinguish document status. 103 However, the current boilerplate is obscure; it requires a knowledge 104 of the Internet Standards Process to interpret, and furthermore, many 105 readers gloss over boilerplate language. 107 This problem is also important to solve. Beyond confusion in the 108 press and by implementers, standards-based interoperability is 109 increasingly being considered by competition regulators as a remedy 110 to abuse of power in Internet-related markets. Consensus status and 111 stream association is critical to their interpretation of a given 112 specification. 114 Additionally, the still in-progress change to the v3 format for 115 Internet-Drafts and RFCs affords an opportunity to adjust how these 116 documents are rendered in a manner that leads to more appropriate 117 perceptions about their status. 119 Therefore, Section 2 contains several recommendations for strong, 120 clear interventions along these lines. 122 1.1. Notational Conventions 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 2. Recommendations 132 2.1. RFCs 134 The following recommendations apply to the publication of RFCs. 136 2.1.1. Proposal 1: logo usage 138 The purpose of this proposal is to create a strong, clear link 139 between document status and logo usage. 141 The IETF, IRTF and IAB stream managers MUST ask the RFC Editor to 142 place their respective logos on HTML, HTMLized and PDF renderings of 143 RFCs on the applicable stream, and only on those documents. The logo 144 should be displayed prominently at the top of the document. 146 The Independent Submissions Editor MAY designate a logo for 147 equivalent use. 149 The tools team is directed to honour these requests in any renderings 150 of these RFCs on sites under their control. This includes the 151 negative condition; i.e., IETF, IRTF, and IAB logos should not appear 152 on or in association with RFCs on other streams. 154 2.1.2. Proposal 2: visual distinction 156 The purpose of this proposal is to create a strong, clear link 157 between document status and document presentation. 159 The RFC Editor is directed to propose stream-specific presentation of 160 RFCs that vary in visually significant ways; e.g., use of typeface, 161 decoration, formatting such as alignment and spacing, and other 162 typographic controls. 164 2.1.3. Proposal 3: domain usage 166 The purpose of this proposal is to create a strong, clear link 167 between document status and the domain name(s) where the document is 168 found. 170 The IETF, IRTF and IAB stream managers SHOULD designate what 171 hostname(s) RFCs from their streams are to be available upon. 172 Initially, this is likely to be datatracker.ietf.org, although stream 173 managers might designate a more specific place (such as 174 specs.irtf.org) instead of or in addition to that location. 176 The Independent Submission Editor SHOULD designate what hostname(s) 177 RFCs from their stream are to be available upon, if any. Independent 178 Submissions MUST NOT be designated to appear on ietf.org, irtf.org or 179 iab.org hostnames. 181 The tools team is directed to assure that these instructions are 182 carried out - in particular, that each stream's RFCs appear only on 183 the designated hostnames (within the scope of hostnames that the 184 tools team has access to), and RFCs from other streams do not appear 185 on the designated hostnames. 187 Note that placeholder documents MAY be used to indicate where a 188 document on another stream can be found, while clearly stating that 189 the target document is not associated with the stream in question; 190 however, automatic redirects MUST NOT be used. 192 Note that if a stream manager does not indicate any domains for such 193 use, it implies that those RFCs will only appear on rfc-editor.org, 194 not any tools team-controlled sites. 196 2.2. Internet-Drafts 198 The following recommendations apply to the publication of Internet- 199 Drafts. 201 2.2.1. Proposal 4: logo usage 203 The purpose of this proposal is to create a strong, clear link 204 between document status and logo usage. 206 The tools team is directed to display the logos of the IETF, IRTF and 207 IAB prominently at the top of HTML, HTMLized, and PDF renderings of 208 Internet-Drafts on those streams (using the appropriate logo), and 209 only drafts on those streams. These logos should not appear anywhere 210 on documents that are not on these streams, nor should the appear on 211 pages associated with them (e.g., datatracker metadata). 213 2.2.2. Proposal 5: visual distinction 215 The purpose of this proposal is to create a strong, clear link 216 between document status and document presentation. 218 The tools team is directed to propose stream-specific presentation of 219 Internet-Drafts that vary in visually significant ways; e.g., use of 220 typeface, decoration (e.g., 'DRAFT' background images), formatting 221 such as alignment and spacing, and other typographic controls. 223 2.2.3. Proposal 6: domain usage 225 The purpose of this proposal is to create a strong, clear link 226 between document status and the domain name(s) where the document 227 (and metadata about it) is found. 229 The tools team is directed to request control of the 'internet- 230 drafts.org' domain name from ISOC (with assistance from the LLC), and 231 to use this domain for publishing drafts not associated with a 232 stream, along with any other material generic to Internet-Drafts 233 (such as the master index of drafts). Drafts on a given stream MAY 234 be published there with consent from that stream's manager. 236 The IETF, IRTF and IAB stream managers MAY designate what hostname(s) 237 Internet-Drafts on their streams are to be available upon. 238 Initially, this is likely to be datatracker.ietf.org, although stream 239 managers might designate a more specific place (such as 240 drafts.irtf.org) instead of or in addition to that location. 242 The Independent Submission Editor MAY designate a hostname that 243 Internet-Drafts from their stream are to be available upon. 244 Independent Submissions MUST NOT be designated to appear on ietf.org, 245 irtf.org or iab.org hostnames. 247 The tools team is directed to assure that these instructions are 248 carried out - in particular, that each stream's drafts appear only on 249 the designated hostnames (within the scope of hostnames that the 250 tools team has access to), and drafts from other streams do not 251 appear on the designated hostnames. 253 Note that placeholder documents MAY be used to indicate where a 254 document on another stream can be found (including on internet- 255 drafts.org), while clearly stating that the target document is not 256 associated with the stream in question; however, automatic redirects 257 MUST NOT be used. 259 2.2.4. Proposal 7: boilerplate 261 The purpose of this proposal is to create a strong, clear statement 262 of the document's actual association (or lack thereof) with a stream 263 in its boilerplate. 265 The tools team is directed to modify this text in the Internet-Draft 266 boilerplate: 268 Internet-Drafts are working documents of the Internet Engineering 269 Task Force (IETF). Note that other groups may also distribute 270 working documents as Internet-Drafts. The list of current Internet- 271 Drafts is at https://datatracker.ietf.org/drafts/current/. 273 to, in the case of IETF stream documents: 275 This Internet-Draft is a working document of the Internet Engineering 276 Task Force (IETF). Note that other parties are able to distribute 277 working documents as Internet-Drafts. The list of current Internet- 278 Drafts is at https://internet-drafts.org/drafts/current/. 280 in the case of IRTF stream documents: 282 This Internet-Draft is a working document of the Internet Research 283 Task Force (IRTF). Note that other parties are able to distribute 284 working documents as Internet-Drafts. The list of current Internet- 285 Drafts is at https://internet-drafts.org/drafts/current/. 287 in the case of IAB stream documents: 289 This Internet-Draft is a working document of the Internet Architecture 290 Board (IAB). Note that other parties are able to distribute 291 working documents as Internet-Drafts. The list of current Internet- 292 Drafts is at https://internet-drafts.org/drafts/current/. 294 in the case of Independent stream documents: 296 This Internet-Draft is an Independent Submission for publication in the 297 RFC Series. Note that other parties are able to distribute 298 working documents as Internet-Drafts. The list of current Internet- 299 Drafts is at https://internet-drafts.org/drafts/current/. 301 in the case of documents not associated with a stream: 303 This Internet-Draft is a working document that has not been adopted 304 by any stream that would lead to RFC publication. The list of current 305 Internet-Drafts is at https://internet-drafts.org/drafts/current/. 307 3. Security Considerations 309 This document has no direct security impact. 311 4. Normative References 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, 315 DOI 10.17487/RFC2119, March 1997, 316 . 318 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 319 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 320 May 2017, . 322 Author's Address 324 Mark Nottingham 325 Prahran VIC 326 Australia 328 Email: mnot@mnot.net 329 URI: https://www.mnot.net/