[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Network Working Group                                 J. M. Halpern, Ed.
Internet-Draft                                                  Ericsson
Intended status: Informational                           G. D. Deen, Ed.
Expires: 20 March 2021                              Comcast-NBCUniversal
                                                       16 September 2020

  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 https://datatracker.ietf.org/drafts/current/.

   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.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Halpern & Deen            Expires 20 March 2021                 [Page 1]

Internet-Draft           IETF Trust IANA Policy           September 2020

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Historic Intent . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Proposed Action . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Policy  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  issues  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.3.  Constraints . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   9.  Informative References  . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

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

Halpern & Deen            Expires 20 March 2021                 [Page 2]

Internet-Draft           IETF Trust IANA Policy           September 2020

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

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.

Halpern & Deen            Expires 20 March 2021                 [Page 3]

Internet-Draft           IETF Trust IANA Policy           September 2020

   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

   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

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 https://www.iana.org/assignments/dhcpv6-parameters

   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 https://www.iana.org/assignments/dkim-parameters

   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 https://www.iana.org/assignments/

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

Halpern & Deen            Expires 20 March 2021                 [Page 4]

Internet-Draft           IETF Trust IANA Policy           September 2020

   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 iana.org 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

Halpern & Deen            Expires 20 March 2021                 [Page 5]

Internet-Draft           IETF Trust IANA Policy           September 2020

   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

   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

Halpern & Deen            Expires 20 March 2021                 [Page 6]

Internet-Draft           IETF Trust IANA Policy           September 2020

   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

   Email: joel.halpern@ericsson.com

   Glenn Deen (editor)
   100 Universal City Plaza
   Universal City, CA 91608
   United States of America

   Email: glenn.deen@nbcuni.com

Halpern & Deen            Expires 20 March 2021                 [Page 7]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/