Internet-Draft IETF Trust IANA Policy September 2020
Halpern & Deen Expires 20 March 2021 [Page]
Network Working Group
Intended Status:
J. M. Halpern, Ed.
G. D. Deen, Ed.

IETF Trust Proposed Policy on Rights in IANA Parameter Registry Data


The document is to inform the IETF community of a proposed clarification to the Public Domain status of the IANA Protocol Registries by the IETF Trust.. This document has been developed to explain the proposal and to solicit community discussion and feedback on this proposal.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 20 March 2021.

Table of Contents

1. Introduction

The IETF Trust is charged with managing the intellectual property assets of the IETF and the IANA. Some users of the IANA Protocol Registry have enquired about what copyright terms are granted by the IETF Trust to consumers of the IANA protocol parameter data.

This draft describes a proposed clarification on that policy, and then presents the motivation and explanation behind it for context. This is intended to inform the IETF and IANA community, to enable community discussion of the proposal, and to solicit feedback on the proposed clarification.

2. Historic Intent

It is the collective understanding of the IETF Trustees that the intent has always been that the IANA Protocol Registry parameters should be in the Public Domain for free use without any restrictions. This is as it has been managed, however , we could not find anywhere those intentions were documented in either policy form or in a declaration attached to the IANA Protocol Registry lists.

The IETF Trustees believe the reason that a formal policy or declaration was not documented is that in US law, under which both the IETF Trust and the IANA Protocol Registry operate, lists of data such as in the IANA Protocol Registry are not copyrightable. Since they are exempt from copyright, there is therefore no copyright notice that is associated with the list of data for the IANA Protocol Registry.

3. Proposed Action

The lack of a clearly citable policy for the IANA Protocol Registry data has caused confusion for a number of users and it is the IETF Trust's intention that establishing a clearly citable policy will remove the confusion and make it easier for users to use the IANA Protocol Registry service.

The IETF Trust proposes formally declaring that the IANA Protocol Registry lists are in the Public Domain and proposes using the Creative Commons Zero (CC0) designation.

A notice of this clarification will be made available to enable consumers of the IANA Protocol Registry to have clear guidance on the IETF Trust's policy.

The formally declared policy that the IETF Trust proposes is the following:

3.1. Policy

Copyrights in IANA Protocol Registries. The Trustees of the IETF Trust waive any copyrights held by the IETF Trust associated with the contents of the IANA Protocol Registries in accordance with the Creative Commons Zero (CC0) designation described at

The Trustees intend that the IANA Protocol Registries are in the Public Domain and are freely available for unrestricted use. This grant only relates to copyright in documents and does not include other rights including patents or trademarks related to or referenced in the documents. In accordance with the CC0 public domain dedication, in no way are the patent or trademark rights of any person affected by CC0, nor are the rights that other persons may have in the work or in how the work is used. The IANA makes no warranties about the work, and disclaims liability for all uses of the work, to the fullest extent permitted by applicable law.

4. Discussion

The protocol parameters and protocol parameter registries [1] have traditionally been considered as "Public Domain" with no licensing statement or other information published about this on either the IETF Trust or IANA websites. This approach has two problems that need to be addressed.

First, This position is not clear enough for some people who for their own legal reasons, need an explicit public statement of the licensing (or lack of licensing) of the protocol parameters and their registries.

Second, There are a number of jurisdictions in which there is no concept of "public domain" and for anything to be considered public domain the rights holders need to explicitly waive their rights.

The policy proposed above addresses these issues while still maintaining the core principle that protocol parameters are "Public Domain".

4.1. Background

The IANA protocol parameter registries can be categorized into several broad categories.

Standards Action (new values and changes are determined only through Standards Track or Best Current Practice RFCs in the IETF Stream.) Example: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Message Types

IETF Review (new values and changes are determined only through RFCs in the IETF Stream -- those that have been shepherded through the IESG as AD-Sponsored or IETF working group documents [RFC2026] [RFC5378], have gone through IETF Last Call, and have been approved by the IESG as having IETF consensus. Example: DKIM Signature Tag Specifications

Specification Required (new values and changes must be reviewed and approved by a designated expert and must have a permanent and readily available public specification - Experts decide if the specification is acceptable) Example: ACME Account Object Fields

Expert Review (new values and changes are reviewed and determined by IESG designated experts)) Example: Vendor media types

First Come First Served (new values and changes are processed so long as basic eligibility requirements are met, assessed by IANA staff) Example: Private enterprise numbers

Registries where IANA does not make the assignments, but only replicates the data with the help of an expert. Example: Ether Types

A well developed ecosystem of applications and users has built up to use these parameters, and we can reasonably assume that the IP lawyers at those companies have approved the use of the protocol parameters on the basis of their current licensing status.

IANA regularly receives queries about the licensing of the Web pages that contain the parameters, which they had previously been replying to with the following text:

The use of material from the website is permissible with the following conditions:

1. Provide attribution to the source, including provision of a URL so that users can find out the complete context if they choose;

2. The materials are used in context; You may not edit or selectively quote the material to make it false or misleading;

3. You do not use the materials in a way that implies ICANN sponsorship or approval of your work. This includes not reproducing the ICANN or IANA logos separate from where they may appear within the materials.

With the above conditions, you may use materials from the website.

The Trustees will work with IANA to create a revised statement to be used in response when a new policy is adopted, and to clarify the distinction between the parameters themselves which are the Trust's, and the web site which is maintained by PTI. The above statement is included here only to provide clarity on the current approach.

4.2. issues

The IETF Trust does not want to assert any form of rights over the protocol parameters or the protocol parameter registries for the following reasons:

  1. The IETF Trust believes that having the protocol parameters and the protocol parameter registries in the Public Domain is the most beneficial position for the Internet as a whole.

  2. Under US law, simple facts such as the protocol parameters cannot be copyrighted nor can a simple uncurated database of those facts.

  3. Some of the protocol parameters and protocol parameter registries were created under US Government contract and so automatically assigned to the Public Domain. The IETF Trust does not want to change that position [nor attempt to identify exactly which protocol parameter and protocol parameter registries this applies to].

However, there are problems in some jurisdictions with this "Public Domain" dedication, which need to be addressed:

  1. Some jurisdictions recognise a Database Right even if the individual contents of the database are not copyright and no curation of those contents has taken place.

  2. Not all jurisdictions have the same definition of what is copyrightable as the US meaning that the protocol parameters may be copyrightable in some jurisdictions.

  3. Some jurisdictions automatically assign rights and these rights therefore need to be explicitly waived, which then could affect the protocol parameters or protocol parameter registries if applied in conjunction with one of the points above.

In addition some of the protocol parameter registries include text snippets, some from RFCs or other documents, that could be considered copyrighted and the existence of this text should not be allowed to cause a problem.

4.3. Constraints

The proposed policy meets the following constraints:

  1. Must not include any assertion of rights by the IETF Trust as that may not be possible (as explained above)

  2. Where the IETF Trust may have copyrights that have been automatically assigned then those copyrights should be waived as fully as possible.

  3. Must be as broadly internationally applicable as possible.

  4. Must ensure that any text that may be considered as copyrighted, including that from an RFC or another document, is included so that there is no ambiguity.

In addition, the proposed means of publication meets the following constraint:

  1. Must not interfere with the automated processing of the IANA protocol parameter registries.

5. Acknowledgements

The material in the discussion section is largely taken from material provided by Jay Daley, the IETF Executive Director.

This document was developed by the 2020 IETF Trustees: Glenn Deen, Joel Halpern, John Levine, Kathleen Moriarty, Stephan Wenger

6. IANA Considerations

While not mandated by this Informational document, it is expected that IANA will post the policy, when adopted by the Trust, in appropriate places on the IANA web sites.

7. Security Considerations

While one can imagine security issues arising indirectly from uses of the data being provided, the Trust does not see any security issues in the adoption of this policy.

8. Normative References

9. Informative References

Authors' Addresses

Joel M. Halpern (editor)
P. O. Box 6049
Leesburg, VA 20178
United States of America
Glenn Deen (editor)
100 Universal City Plaza
Universal City, CA 91608
United States of America