<?xml version="1.0" encoding="US-ASCII"?>

<rfc category="info" submissionType="IETF" ipr="trust200902"
     docName="draft-halpern-trust-ianapolicy-00"
     version="3" xmlns:xi="http://www.w3.org/2001/XInclude">

  <front>
    <title abbrev="IETF Trust IANA Policy">IETF Trust Proposed Policy on
    Rights in IANA Parameter Registry Data</title>

    <author fullname="Joel M. Halpern" initials="J. M." role="editor"
            surname="Halpern">
      <organization abbrev="Ericsson">Ericsson</organization>

      <address>
        <postal>
          <street>P. O. Box 6049</street>
          <city>Leesburg</city>
          <region>VA</region>
          <code>20178</code>
          <country>US</country>
        </postal>
        <email>joel.halpern@ericsson.com</email>
      </address>
    </author>

    <author fullname="Glenn Deen" initials="G. D." role="editor"
            surname="Deen">
      <organization abbrev="Comcast-NBCUniversal">Comcast-NBCUniversal
      </organization>

      <address>
        <postal>
          <street>100 Universal City Plaza</street>
          <city>Universal City</city>
          <region>CA</region>
          <code>91608</code>
          <country>US</country>
        </postal>
        <email>glenn.deen@nbcuni.com</email>
      </address>
    </author>

    <date month="September" year="2020" day="16"/>

    <area>General</area>

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="Introduction" title="Introduction">
      <t>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.  
      </t>
      <t>
	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.</t>

    </section>  
    <section anchor="HistoricIntent" title="Historic Intent">
      <t>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.
      </t>
      <t>
	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.   
      </t>


    </section>

    <section anchor="ProposedAction" title="Proposed Action">
      <t>
	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. 
      </t>
      <t>
	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.
      </t>
      <t>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.
      </t>
      <t>
	The formally declared policy that the IETF Trust proposes is
	the following: 
      </t>

      <section anchor="Policy" title="Policy">
	<t>
	  <em>Copyrights in IANA Protocol Registries.</em> 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
	  <eref target="https://creativecommons.org/publicdomain/zero/1.0/"/>.
	</t>
	<t>
	  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. 
	</t>
      </section>

    </section>

    <section anchor="Discussion" title="Discussion">
      <t>
	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. </t>

      <t> 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.  </t>

      <t> 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.</t>


      <t>The policy proposed above addresses these issues while still
      maintaining the core principle that protocol parameters are
      "Public Domain".</t>

      <section anchor="Background" title="Background">
	<t>The IANA protocol parameter registries can be categorized into
	several broad categories. </t>

	<t>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 
	<eref target="https://www.iana.org/assignments/dhcpv6-parameters"/></t>
	
	<t>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
	<eref target="https://www.iana.org/assignments/dkim-parameters"/>
	</t>
	
	<t>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
	<eref target="https://www.iana.org/assignments/acme"/>
	</t>
	
	<t>Expert Review (new values and changes are reviewed and
	determined by IESG designated experts)) Example: Vendor media types
	<eref target="https://www.iana.org/assignments/media-types"/>
	</t>
	
	<t>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

	<eref target="https://www.iana.org/assignments/enterprise-numbers"/>
	</t>
	
	<t>Registries where IANA does not make the assignments, but
	only replicates the data with the help of an expert. Example:
	Ether Types
	<eref target="https://www.iana.org/assignments/ieee-802-numbers/"/>
	</t>

	<t>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.</t>

	<t>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:</t>

	<blockquote>
	  <t>The use of material from the iana.org website is
	  permissible with the following conditions:</t>
	  
	  <t>1. Provide attribution to the source, including provision of a
	  URL so that users can find out the complete context if they choose;
	  </t>
	  
	  <t>2. The materials are used in context; You may not edit or
	  selectively quote the material to make it false or misleading;
	  </t>
	  
	  <t>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.</t>
	  
	  <t>With the above conditions, you may use materials from the
	  website.</t>
	</blockquote>
	
	<t>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.</t>
      </section>
      <section anchor="Issues" title="issues">
	
	<t>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:</t>
	
	<ol>
	  <li><t>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.</t></li>
	  
	  <li><t>Under US law, simple facts such as the protocol
	  parameters cannot be copyrighted nor can a simple uncurated
	  database of those facts.</t></li>
	  
	  <li><t>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].</t></li>
	</ol>
	
	<t>However, there are problems in some jurisdictions with this
	"Public Domain" dedication, which need to be addressed:</t>

	<ol>
	  <li><t>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.</t></li>
	  
	  <li><t>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.</t></li>
	  
	  <li><t>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. </t></li>
	</ol>

	<t>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.</t>
      </section>
      
      <section anchor="Constraints" title="Constraints">
	
	<t>The proposed policy meets the following constraints:</t>
	
	<ol>
	  <li><t>Must not include any assertion of rights by the IETF
	  Trust as that may not be possible (as explained above)</t></li>
	  
	  <li><t>Where the IETF Trust may have copyrights that have been
	  automatically assigned then those copyrights should be waived as
	  fully as possible.</t></li>
	  
	  <li><t>Must be as broadly internationally applicable as possible.
	  </t></li>
	  
	  <li><t>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.</t></li>
	</ol>

	<t>In addition, the proposed means of publication meets the
	following constraint:</t>
	<ol>
	  <li><t>Must not interfere with the automated processing of the
	  IANA protocol parameter registries.
	  </t></li>
	</ol>
      </section>
    </section>


    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The material in the discussion section is largely taken from
      material provided by Jay Daley, the IETF Executive Director.  </t>
      
      <t>This document was developed by the 2020 IETF Trustees:
      Glenn Deen, Joel Halpern, John Levine, Kathleen Moriarty,
      Stephan Wenger
      </t> 
      </section>

      <section title="IANA Considerations">
	<t>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.</t>
      </section>

      <section title="Security Considerations">
	<t>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.
	</t>
      </section>
    </middle>

    <back>
      <references>
	<name>Normative References</name>

      </references>

      <references>
	<name>Informative References</name>

      </references>

    </back>
  </rfc>

