idnits 2.17.1 draft-halpern-trust-ianapolicy-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 (16 September 2020) is 1318 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 137 looks like a reference -- Missing reference section? 'RFC2026' on line 168 looks like a reference -- Missing reference section? 'RFC5378' on line 169 looks like a reference 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. M. Halpern, Ed. 3 Internet-Draft Ericsson 4 Intended status: Informational G. D. Deen, Ed. 5 Expires: 20 March 2021 Comcast-NBCUniversal 6 16 September 2020 8 IETF Trust Proposed Policy on Rights in IANA Parameter Registry Data 9 draft-halpern-trust-ianapolicy-00 11 Abstract 13 The document is to inform the IETF community of a proposed 14 clarification to the Public Domain status of the IANA Protocol 15 Registries by the IETF Trust.. This document has been developed to 16 explain the proposal and to solicit community discussion and feedback 17 on this proposal. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 20 March 2021. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Historic Intent . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Proposed Action . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.2. issues . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.3. Constraints . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 64 9. Informative References . . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 The IETF Trust is charged with managing the intellectual property 70 assets of the IETF and the IANA. Some users of the IANA Protocol 71 Registry have enquired about what copyright terms are granted by the 72 IETF Trust to consumers of the IANA protocol parameter data. 74 This draft describes a proposed clarification on that policy, and 75 then presents the motivation and explanation behind it for context. 76 This is intended to inform the IETF and IANA community, to enable 77 community discussion of the proposal, and to solicit feedback on the 78 proposed clarification. 80 2. Historic Intent 82 It is the collective understanding of the IETF Trustees that the 83 intent has always been that the IANA Protocol Registry parameters 84 should be in the Public Domain for free use without any restrictions. 85 This is as it has been managed, however , we could not find anywhere 86 those intentions were documented in either policy form or in a 87 declaration attached to the IANA Protocol Registry lists. 89 The IETF Trustees believe the reason that a formal policy or 90 declaration was not documented is that in US law, under which both 91 the IETF Trust and the IANA Protocol Registry operate, lists of data 92 such as in the IANA Protocol Registry are not copyrightable. Since 93 they are exempt from copyright, there is therefore no copyright 94 notice that is associated with the list of data for the IANA Protocol 95 Registry. 97 3. Proposed Action 99 The lack of a clearly citable policy for the IANA Protocol Registry 100 data has caused confusion for a number of users and it is the IETF 101 Trust's intention that establishing a clearly citable policy will 102 remove the confusion and make it easier for users to use the IANA 103 Protocol Registry service. 105 The IETF Trust proposes formally declaring that the IANA Protocol 106 Registry lists are in the Public Domain and proposes using the 107 Creative Commons Zero (CC0) designation. 109 A notice of this clarification will be made available to enable 110 consumers of the IANA Protocol Registry to have clear guidance on the 111 IETF Trust's policy. 113 The formally declared policy that the IETF Trust proposes is the 114 following: 116 3.1. Policy 118 _Copyrights in IANA Protocol Registries._ The Trustees of the IETF 119 Trust waive any copyrights held by the IETF Trust associated with the 120 contents of the IANA Protocol Registries in accordance with the 121 Creative Commons Zero (CC0) designation described at 122 https://creativecommons.org/publicdomain/zero/1.0/. 124 The Trustees intend that the IANA Protocol Registries are in the 125 Public Domain and are freely available for unrestricted use. This 126 grant only relates to copyright in documents and does not include 127 other rights including patents or trademarks related to or referenced 128 in the documents. In accordance with the CC0 public domain 129 dedication, in no way are the patent or trademark rights of any 130 person affected by CC0, nor are the rights that other persons may 131 have in the work or in how the work is used. The IANA makes no 132 warranties about the work, and disclaims liability for all uses of 133 the work, to the fullest extent permitted by applicable law. 135 4. Discussion 137 The protocol parameters and protocol parameter registries [1] have 138 traditionally been considered as "Public Domain" with no licensing 139 statement or other information published about this on either the 140 IETF Trust or IANA websites. This approach has two problems that 141 need to be addressed. 143 First, This position is not clear enough for some people who for 144 their own legal reasons, need an explicit public statement of the 145 licensing (or lack of licensing) of the protocol parameters and their 146 registries. 148 Second, There are a number of jurisdictions in which there is no 149 concept of "public domain" and for anything to be considered public 150 domain the rights holders need to explicitly waive their rights. 152 The policy proposed above addresses these issues while still 153 maintaining the core principle that protocol parameters are "Public 154 Domain". 156 4.1. Background 158 The IANA protocol parameter registries can be categorized into 159 several broad categories. 161 Standards Action (new values and changes are determined only through 162 Standards Track or Best Current Practice RFCs in the IETF Stream.) 163 Example: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 164 Message Types https://www.iana.org/assignments/dhcpv6-parameters 166 IETF Review (new values and changes are determined only through RFCs 167 in the IETF Stream -- those that have been shepherded through the 168 IESG as AD-Sponsored or IETF working group documents [RFC2026] 169 [RFC5378], have gone through IETF Last Call, and have been approved 170 by the IESG as having IETF consensus. Example: DKIM Signature Tag 171 Specifications https://www.iana.org/assignments/dkim-parameters 173 Specification Required (new values and changes must be reviewed and 174 approved by a designated expert and must have a permanent and readily 175 available public specification - Experts decide if the specification 176 is acceptable) Example: ACME Account Object Fields 177 https://www.iana.org/assignments/acme 179 Expert Review (new values and changes are reviewed and determined by 180 IESG designated experts)) Example: Vendor media types 181 https://www.iana.org/assignments/media-types 183 First Come First Served (new values and changes are processed so long 184 as basic eligibility requirements are met, assessed by IANA staff) 185 Example: Private enterprise numbers https://www.iana.org/assignments/ 186 enterprise-numbers 188 Registries where IANA does not make the assignments, but only 189 replicates the data with the help of an expert. Example: Ether Types 190 https://www.iana.org/assignments/ieee-802-numbers/ 191 A well developed ecosystem of applications and users has built up to 192 use these parameters, and we can reasonably assume that the IP 193 lawyers at those companies have approved the use of the protocol 194 parameters on the basis of their current licensing status. 196 IANA regularly receives queries about the licensing of the Web pages 197 that contain the parameters, which they had previously been replying 198 to with the following text: 200 | The use of material from the iana.org website is permissible with 201 | the following conditions: 202 | 203 | 1. Provide attribution to the source, including provision of a 204 | URL so that users can find out the complete context if they 205 | choose; 206 | 207 | 2. The materials are used in context; You may not edit or 208 | selectively quote the material to make it false or misleading; 209 | 210 | 3. You do not use the materials in a way that implies ICANN 211 | sponsorship or approval of your work. This includes not 212 | reproducing the ICANN or IANA logos separate from where they may 213 | appear within the materials. 214 | 215 | With the above conditions, you may use materials from the website. 217 The Trustees will work with IANA to create a revised statement to be 218 used in response when a new policy is adopted, and to clarify the 219 distinction between the parameters themselves which are the Trust's, 220 and the web site which is maintained by PTI. The above statement is 221 included here only to provide clarity on the current approach. 223 4.2. issues 225 The IETF Trust does not want to assert any form of rights over the 226 protocol parameters or the protocol parameter registries for the 227 following reasons: 229 1. The IETF Trust believes that having the protocol parameters and 230 the protocol parameter registries in the Public Domain is the 231 most beneficial position for the Internet as a whole. 233 2. Under US law, simple facts such as the protocol parameters cannot 234 be copyrighted nor can a simple uncurated database of those 235 facts. 237 3. Some of the protocol parameters and protocol parameter registries 238 were created under US Government contract and so automatically 239 assigned to the Public Domain. The IETF Trust does not want to 240 change that position [nor attempt to identify exactly which 241 protocol parameter and protocol parameter registries this applies 242 to]. 244 However, there are problems in some jurisdictions with this "Public 245 Domain" dedication, which need to be addressed: 247 1. Some jurisdictions recognise a Database Right even if the 248 individual contents of the database are not copyright and no 249 curation of those contents has taken place. 251 2. Not all jurisdictions have the same definition of what is 252 copyrightable as the US meaning that the protocol parameters may 253 be copyrightable in some jurisdictions. 255 3. Some jurisdictions automatically assign rights and these rights 256 therefore need to be explicitly waived, which then could affect 257 the protocol parameters or protocol parameter registries if 258 applied in conjunction with one of the points above. 260 In addition some of the protocol parameter registries include text 261 snippets, some from RFCs or other documents, that could be considered 262 copyrighted and the existence of this text should not be allowed to 263 cause a problem. 265 4.3. Constraints 267 The proposed policy meets the following constraints: 269 1. Must not include any assertion of rights by the IETF Trust as 270 that may not be possible (as explained above) 272 2. Where the IETF Trust may have copyrights that have been 273 automatically assigned then those copyrights should be waived as 274 fully as possible. 276 3. Must be as broadly internationally applicable as possible. 278 4. Must ensure that any text that may be considered as copyrighted, 279 including that from an RFC or another document, is included so 280 that there is no ambiguity. 282 In addition, the proposed means of publication meets the following 283 constraint: 285 1. Must not interfere with the automated processing of the IANA 286 protocol parameter registries. 288 5. Acknowledgements 290 The material in the discussion section is largely taken from material 291 provided by Jay Daley, the IETF Executive Director. 293 This document was developed by the 2020 IETF Trustees: Glenn Deen, 294 Joel Halpern, John Levine, Kathleen Moriarty, Stephan Wenger 296 6. IANA Considerations 298 While not mandated by this Informational document, it is expected 299 that IANA will post the policy, when adopted by the Trust, in 300 appropriate places on the IANA web sites. 302 7. Security Considerations 304 While one can imagine security issues arising indirectly from uses of 305 the data being provided, the Trust does not see any security issues 306 in the adoption of this policy. 308 8. Normative References 310 9. Informative References 312 Authors' Addresses 314 Joel M. Halpern (editor) 315 Ericsson 316 P. O. Box 6049 317 Leesburg, VA 20178 318 United States of America 320 Email: joel.halpern@ericsson.com 322 Glenn Deen (editor) 323 Comcast-NBCUniversal 324 100 Universal City Plaza 325 Universal City, CA 91608 326 United States of America 328 Email: glenn.deen@nbcuni.com