Internet DRAFT - draft-halpern-trust-ianapolicy
draft-halpern-trust-ianapolicy
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
draft-halpern-trust-ianapolicy-00
Abstract
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
Registry.
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
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
https://creativecommons.org/publicdomain/zero/1.0/.
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
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 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
https://www.iana.org/assignments/acme
Expert Review (new values and changes are reviewed and determined by
IESG designated experts)) Example: Vendor media types
https://www.iana.org/assignments/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/
enterprise-numbers
Registries where IANA does not make the assignments, but only
replicates the data with the help of an expert. Example: Ether Types
https://www.iana.org/assignments/ieee-802-numbers/
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
facts.
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
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:
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)
Ericsson
P. O. Box 6049
Leesburg, VA 20178
United States of America
Email: joel.halpern@ericsson.com
Glenn Deen (editor)
Comcast-NBCUniversal
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]
