idnits 2.17.00 (12 Aug 2021) /tmp/idnits23859/draft-atlas-external-normref-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 contain references ([RFC3967]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 29, 2017) is 1658 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 241 ** Downref: Normative reference to an Informational RFC: RFC 4858 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Atlas 3 Internet-Draft Juniper Networks 4 Intended status: Best Current Practice E. Lear 5 Expires: May 2, 2018 Cisco 6 J. Halpern 7 Ericsson 8 H. Flanagan 9 RFC Editor 10 J. Tantsura 11 Individual 12 October 29, 2017 14 Normative References in RFCs from Open Source 15 draft-atlas-external-normref-00 17 Abstract 19 IETF procedures generally require that a standards track RFC may not 20 have a normative reference to a non standards track specification 21 except those from other 22 standards bodies. This document creates an External Specification 23 registry, similar to the DownRef registry that has been created based 24 on [RFC3967] and permits normative references to community accepted 25 external specifications. 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 May 2, 2018. 44 Copyright Notice 46 Copyright (c) 2017 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 2. What Can Be Normatively Referenced? . . . . . . . . . . . . . 3 63 3. Procedure to be Used . . . . . . . . . . . . . . . . . . . . 4 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 69 7.2. Informative References . . . . . . . . . . . . . . . . . 5 70 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 The IETF follows the Standards Process [RFC2026] that describes to 76 what a standards track RFC can normatively refer. Information that 77 is normatively referenced is required to be understood and may be 78 necessary for implementation of the RFC. Essentially, if a 79 technology can be normatively referenced, then a standards track RFC 80 can be created that uses that technology. 82 Of course, the need to collaboratively build Internet technology is 83 well discussed in [RFC2026] Section 7 and the ability to reference 84 external Open Standard specifications as well as proprietary 85 specifications is described. Specifically, 87 Other proprietary specifications may be incorporated by reference 88 to a version of the specification as long as the proprietor meets 89 the requirements of section 10. If the other proprietary 90 specification is not widely and readily available, the IESG may 91 request that it be published as an Informational RFC. 93 The ID-nits checklist at https://www.ietf.org/id-info/checklist.html 94 [1] warns: 96 Normative and informative references to non-IETF documents are 97 permitted. However, it is best to minimize such normative 98 references, because assessing their status when the IETF document 99 advances on the standards-track is very difficult. It is 100 important to use the exact title, author name(s), organization and 101 publication date. 103 When a Working Group wishes to build based upon existing Open Source 104 technology, the lack of clarity around how that technology's status 105 will be assessed can either discourage such a dependency or add 106 unnecessary work by requiring republication as an Independent Stream 107 RFC, which will still require a downwards reference [RFC3967]. 109 This document provides clarity and a simple process to make it easy 110 to reference Open Source technology that the IETF community agrees is 111 acceptable. 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119, BCP 14 116 [RFC2119]. 118 2. What Can Be Normatively Referenced? 120 There are five basic requirements for a normative reference. 122 1. Is it stable, mature, and immutable (except for errata)? 124 Stable means that there are not expected to be frequent updated 125 versions. Mature is equivalent to being at least similar to a 126 Proposed Standard RFC. Immutable means that the referenced 127 content is not expected to change after RFC publication, except 128 for minor error corrections. This might be achieved by 129 referencing a particular dated version or a subsection of the 130 document. 132 2. Is it generally easily accessible and not subject to 133 confidentiality restrictions? 135 3. Is it a specification that describes the technology in sufficient 136 detail that someone else can design their own implementation to 137 properly interoperate with it and others' different 138 implementations? 140 The IETF generally prefers specifications over code. Code itself 141 lacks context to fully understand the intent or support an 142 interoperable different implementation. There may, of course, be 143 exceptions where an algorithm or codec is really most clearly 144 described in code. For example, while [RFC6716] has normative 145 code, there is also detailed documentation. If it is necessary 146 to reference code, a distribution is preferred because that can 147 be clear on the public interfaces and intent of the code. 149 4. Is it intended as a public interface? 151 5. Are the IPR associated with the normative reference clearly and 152 publicly documented so that the Working Group participants can 153 make an informed decision about building on top of the specified 154 technology? 156 3. Procedure to be Used 158 This procedure is modeled on that defined in [RFC3967] and [RFC8067] 159 for managing down references in RFCs. A registry of external non-SDO 160 references that have been accepted by the community, as indicated by 161 at least the first published RFC with a normative references to a 162 particular item, SHOULD be maintained for references that may see 163 reuse. That registry should indicate the reference, the RFC(s) 164 normatively referring to it, and a pointer to any IPR information 165 that is provided by the same source (e.g. Open Source Organization) 166 as the external non-SDO reference. A mechanism for this registry 167 could be the same as is done in datatracker for the DownRef registry 168 where the sponsoring AD updates the registry. 170 The following procedures apply to external non-SDO references that 171 are not yet in the External References registry. Information 172 included in calls for Working Group adoption, Working Group Last 173 Call, and IETF Last Call SHOULD include any normative references to 174 external non-SDO technology and a pointer to any IPR that is provided 175 by the same source as the external non-SDO technology. Working Group 176 and IETF participants should use this information in their 177 evaluations. The Document Shepherd [RFC4858] SHOULD indicate in her 178 or his report whether the document contains any external non-SDO 179 references that are not in the external references registry. This 180 will call the responsible Area Director's attention to verify that 181 the referenced item is acceptable. 183 The Working Group Chairs and responsible Area Director SHOULD verify 184 that the referenced item meets the requirements described earlier. 185 If the desired reference is to code, then the responsible Area 186 Director MUST determine whether it provides sufficient context, 187 clarity of intent, and intentional public interfaces. Judgement 188 calls are expected here as circumstances will vary. 190 4. Security Considerations 192 It is possible that external technology does not meet the security or 193 privacy expectations for Standards Track RFCs. This may require 194 additional considerations from the referring document. 196 5. IANA Considerations 198 There are no IANA considerations. 200 6. Acknowledgements 202 Thanks to Lucy Lynch for encouraging more thought on what can be done 203 to better the interaction between the IETF and Open Source work. 205 7. References 207 7.1. Normative References 209 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 210 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 211 . 213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 214 Requirement Levels", BCP 14, RFC 2119, 215 DOI 10.17487/RFC2119, March 1997, 216 . 218 [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track 219 Documents may Refer Normatively to Documents at a Lower 220 Level", BCP 97, RFC 3967, DOI 10.17487/RFC3967, December 221 2004, . 223 [RFC4858] Levkowetz, H., Meyer, D., Eggert, L., and A. Mankin, 224 "Document Shepherding from Working Group Last Call to 225 Publication", RFC 4858, DOI 10.17487/RFC4858, May 2007, 226 . 228 [RFC8067] Leiba, B., "Updating When Standards Track Documents May 229 Refer Normatively to Documents at a Lower Level", BCP 97, 230 RFC 8067, DOI 10.17487/RFC8067, January 2017, 231 . 233 7.2. Informative References 235 [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the 236 Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, 237 September 2012, . 239 7.3. URIs 241 [1] https://www.ietf.org/id-info/checklist.html 243 Authors' Addresses 245 Alia Atlas 246 Juniper Networks 248 Email: akatlas@juniper.net 250 Eliot Lear 251 Cisco 253 Email: lear@cisco.com 255 Joel Halpern 256 Ericsson 258 Email: Joel.Halpern@ericsson.com 260 Heather Flanagan 261 RFC Editor 263 Email: rse@rfc-editor.org 265 Jeff Tantsura 266 Individual 268 Email: jefftant.ietf@gmail.com