rfc8721xml2.original.xml   rfc8721.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" cons
<?rfc compact='yes'?> ensus="true" docName="draft-ietf-iasa2-rfc5377bis-03" indexInclude="true" ipr="t
<?rfc symrefs='yes'?> rust200902" number="8721" obsoletes="5377" prepTime="2020-02-26T17:10:45" script
<rfc category="info" ipr="trust200902" s="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="
obsoletes="5377" docName="draft-ietf-iasa2-rfc5377bis-03"> 3" tocInclude="true" xml:lang="en">
<link href="https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc5377bis-03" r
<?rfc toc="yes"?> el="prev"/>
<?rfc sortrefs="yes"?> <link href="https://dx.doi.org/10.17487/rfc8721" rel="alternate"/>
<?rfc rfcedstyle="yes"?> <link href="urn:issn:2070-1721" rel="alternate"/>
<?rfc subcompact="no"?>
<front> <front>
<title abbrev="Outbound Rights Advice">Advice to the Trustees of the IETF <title abbrev="Outbound Rights Advice">Advice to the Trustees of the IETF Tr
Trust on&nbsp;Rights&nbsp;to&nbsp;Be&nbsp;Granted&nbsp;in&nbsp;IETF&nbsp ust on Rights to Be Granted in IETF Documents</title>
;Documents</title> <seriesInfo name="RFC" value="8721" stream="IETF"/>
<author fullname="Joel M. Halpern" initials="J." role="editor" surname="Halp
<author fullname="Joel M. Halpern" initials="J.M.H." role="editor" ern">
surname="Halpern"> <organization abbrev="Ericsson" showOnFrontPage="true">Ericsson</organizat
<organization abbrev="Ericsson">Ericsson</organization> ion>
<address> <address>
<postal> <postal>
<street>P. O. Box 6049</street> <street>P. O. Box 6049</street>
<city>Leesburg</city> <city>Leesburg</city>
<region>VA</region> <region>VA</region>
<code>20178</code> <code>20178</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>joel.halpern@ericsson.com</email> <email>joel.halpern@ericsson.com</email>
</address> </address>
</author> </author>
<date month="02" year="2020"/>
<date month="August" year="2019" />
<area>General</area> <area>General</area>
<workgroup>IASA2</workgroup> <workgroup>IASA2</workgroup>
<keyword>IASA</keyword>
<abstract> <keyword>Trust</keyword>
<t>Contributors grant intellectual property rights to the IETF. The <abstract pn="section-abstract">
<t pn="section-abstract-1">Contributors grant intellectual property rights
to the IETF. The
IETF Trust holds and manages those rights on behalf of the IETF. The IETF Trust holds and manages those rights on behalf of the IETF. The
Trustees of the IETF Trust are responsible for that management. This Trustees of the IETF Trust are responsible for that management. This
management includes granting the licenses to copy, implement, and management includes granting the licenses to copy, implement, and
otherwise use IETF Contributions, among them Internet-Drafts and RFCs. otherwise use IETF Contributions, among them Internet-Drafts and RFCs.
The Trustees of the IETF Trust accept direction from the IETF regarding The Trustees of the IETF Trust accept direction from the IETF regarding
the rights to be granted. This document describes the desires of the the rights to be granted. This document describes the desires of the
IETF regarding outbound rights to be granted in IETF IETF regarding outbound rights to be granted in IETF
Contributions. This document obsoletes RFC 5377 solely for the Contributions. This document obsoletes RFC 5377 solely for the
purpose of removing references to the IAOC which was part of IASA.</t> purpose of removing references to the IETF Administrative Oversight Commit
tee
(IAOC), which was part of the IETF Administrative Support Activity (IASA).
</t>
</abstract> </abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t pn="section-boilerplate.1-1">
This document is not an Internet Standards Track specification; it i
s
published for informational purposes.
</t>
<t pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
</t>
<t pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8721" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t pn="section-boilerplate.2-1">
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) 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.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent
="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-introduction">Introductio
n</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent
="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-purpose-in-granting-right
s">Purpose in Granting Rights</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent
="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-powers-and-authority">Pow
ers and Authority</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent
="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-recommended-grants-of-rig
ht">Recommended Grants of Right to Copy</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t keepWithNext="true" pn="section-toc.1-1.4.2.1.1"><xref derive
dContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-rights-grante
d-for-reproduc">Rights Granted for Reproduction of RFCs</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t keepWithNext="true" pn="section-toc.1-1.4.2.2.1"><xref derive
dContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-rights-grante
d-for-quoting-">Rights Granted for Quoting from IETF Contributions</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3">
<t keepWithNext="true" pn="section-toc.1-1.4.2.3.1"><xref derive
dContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-rights-grante
d-for-implemen">Rights Granted for Implementing Based on IETF Contributions</xre
f></t>
</li>
<li pn="section-toc.1-1.4.2.4">
<t keepWithNext="true" pn="section-toc.1-1.4.2.4.1"><xref derive
dContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-rights-grante
d-for-use-of-t">Rights Granted for Use of Text from IETF Contributions</xref></t
>
</li>
<li pn="section-toc.1-1.4.2.5">
<t keepWithNext="true" pn="section-toc.1-1.4.2.5.1"><xref derive
dContent="4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-additional-li
censes-for-iet">Additional Licenses for IETF Contributions</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent
="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.6">
<t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent
="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-security-considerations">
Security Considerations</xref></t>
</li>
<li pn="section-toc.1-1.7">
<t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent
="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-references">References</x
ref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t keepWithNext="true" pn="section-toc.1-1.7.2.1.1"><xref derive
dContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-normative-ref
erences">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<t keepWithNext="true" pn="section-toc.1-1.7.2.2.1"><xref derive
dContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-informative-r
eferences">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent
="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedC
ontent="" format="title" sectionFormat="of" target="name-authors-address">Author
's Address</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
<t>Under the current operational and administrative structures, IETF <name slugifiedName="name-introduction">Introduction</name>
<t pn="section-1-1">Under the current operational and administrative struc
tures, IETF
intellectual property rights are vested in the IETF Trust administered intellectual property rights are vested in the IETF Trust administered
by a board of trustees. This includes the right to make use of IETF by a board of trustees. This includes the right to make use of IETF
Contributions, as granted by Contributors under the rules laid out in Contributions, as granted by Contributors under the rules laid out in
<xref target="RFC5378"></xref>. The Trustees of the IETF Trust <xref target="RFC5378" format="default" sectionFormat="of" derivedContent= "RFC5378"/>. The Trustees of the IETF Trust
are therefore responsible for defining the rights to copy granted by are therefore responsible for defining the rights to copy granted by
the IETF to people who wish to make use of the material in these the IETF to people who wish to make use of the material in these
documents.</t> documents.</t>
<t pn="section-1-2">For consistency and clarity, this document uses the sa
<t>For consistency and clarity, this document uses the same terminology me terminology
laid out in <xref target="RFC5378"></xref> and uses the same laid out in <xref target="RFC5378" format="default" sectionFormat="of" der
ivedContent="RFC5378"/> and uses the same
meanings as defined in that document.</t> meanings as defined in that document.</t>
<t pn="section-1-3">The IETF Trust, by way of its Trustees, has indicated,
<t>The IETF Trust, by way of its Trustees, has indicated, as is as is
consistent with the IETF structure, consistent with the IETF structure,
that it will respect the wishes of the IETF in regard to what these that it will respect the wishes of the IETF in regard to what these
granted rights ought to be. It is therefore the IETF's responsibility to granted rights ought to be. It is therefore the IETF's responsibility to
articulate those wishes. This document represents the wishes of the IETF articulate those wishes. This document represents the wishes of the IETF
regarding the rights granted to all users in regard to IETF regarding the rights granted to all users in regard to IETF
Contributions, until it is superseded.</t> Contributions, until it is superseded.</t>
</section> </section>
<section anchor="Purpose" numbered="true" toc="include" removeInRFC="false"
<section anchor="Purpose" title="Purpose in Granting Rights"> pn="section-2">
<t>In providing a description of the wishes of the IETF with regard to <name slugifiedName="name-purpose-in-granting-rights">Purpose in Granting
Rights</name>
<t pn="section-2-1">In providing a description of the wishes of the IETF w
ith regard to
rights granted in RFCs, it is helpful to keep in mind the purpose of rights granted in RFCs, it is helpful to keep in mind the purpose of
granting such rights.</t> granting such rights.</t>
<t pn="section-2-2">The mission of the IETF is to produce documents that m
<t>The mission of the IETF is to produce documents that make the Internet ake the Internet
work better (see <xref target="RFC3935"></xref> for more details). These work better (see <xref target="RFC3935" format="default" sectionFormat="of
" derivedContent="RFC3935"/> for more details). These
documents, when completed, are published as RFCs.</t> documents, when completed, are published as RFCs.</t>
<t pn="section-2-3">An important subclass of RFCs is standards describing
<t>An important subclass of RFCs is standards describing protocols; for protocols; for
these, the primary value to the Internet is the ability of implementors these, the primary value to the Internet is the ability of implementors
to build solutions (products, software, etc.) that interoperate using to build solutions (products, software, etc.) that interoperate using
these standards. Hence, the IETF has a strong interest in seeing these standards. Hence, the IETF has a strong interest in seeing
accurate, interoperable implementations of the material accurate, interoperable implementations of the material
the IETF publishes. The IETF Trust the IETF publishes. The IETF Trust
grants rights to copy to people to make use of the text in the RFCs in grants rights to copy to people to make use of the text in the RFCs in
order to encourage accurate and interoperable implementations.</t> order to encourage accurate and interoperable implementations.</t>
<t pn="section-2-4">As early
<t>As early
implementations from Internet-Drafts make use of descriptions in those implementations from Internet-Drafts make use of descriptions in those
Internet-Drafts, similar desires apply to Internet-Drafts.</t> Internet-Drafts, similar desires apply to Internet-Drafts.</t>
<t pn="section-2-5">Similar considerations also apply to non-standard,
<t>Similar considerations also apply to non-standard,
non-protocol documents such as BCP (Best Current Practice) and non-protocol documents such as BCP (Best Current Practice) and
Informational documents; in this document, we recommend a common Informational documents; in this document, we recommend a common
approach to the issue of right-to-use licenses for all IETF approach to the issue of right-to-use licenses for all IETF
documents.</t> documents.</t>
<t pn="section-2-6">Previous documents regarding rights in IETF documents
<t>Previous documents regarding rights in IETF documents have included have included
in the RFC text specific text to be used to achieve the stated goals. in the RFC text specific text to be used to achieve the stated goals.
This has proved problematic. When problems are found with such text, This has proved problematic. When problems are found with such text,
even when the problem is not a change in intent, it is necessary to even when the problem is not a change in intent, it is necessary to
revise the RFC to fix the problem. At best, this delays fixing legal revise the RFC to fix the problem. At best, this delays fixing legal
issues that need prompt attention. As such, this document describes issues that need prompt attention. As such, this document describes
the IETF desires to the Trustees of the IETF Trust, but does not the IETF desires to the Trustees of the IETF Trust, but does not
provide the specific legal wording to address the goals. The selection, provide the specific legal wording to address the goals. The selection,
and updating as necessary, of legal wording is left to the Trustees of and updating as necessary, of legal wording is left to the Trustees of
the IETF Trust.</t> the IETF Trust.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3">
<section title="Powers and Authority"> <name slugifiedName="name-powers-and-authority">Powers and Authority</name
<t>As described in the introduction, and formally specified in >
<xref target="RFC5378"></xref>, the legal authority for determining <t pn="section-3-1">As described in the introduction, and formally specifi
ed in
<xref target="RFC5378" format="default" sectionFormat="of" derivedContent=
"RFC5378"/>, the legal authority for determining
and granting users rights to copy material in RFCs and other IETF and granting users rights to copy material in RFCs and other IETF
Contributions rests with the Trustees for the IETF Contributions rests with the Trustees for the IETF
Trust. This Trust. This
document provides guidance to that body, based on the rough consensus of document provides guidance to that body, based on the rough consensus of
the IETF. The Trustees of the IETF Trust have the the IETF. The Trustees of the IETF Trust have the
authority and responsibility to determine the exact text insertions authority and responsibility to determine the exact text insertions
(or other mechanisms), if any, needed in (or other mechanisms), if any, needed in
Internet-Drafts, RFCs, and all IETF Contributions to meet these Internet-Drafts, RFCs, and all IETF Contributions to meet these
goals. The IETF Trust License Policy is available from goals. The IETF Trust License Policy is available from
<xref target="TRUST-LEGAL"></xref> <xref target="TRUST-LEGAL" format="default" sectionFormat="of" derivedCont
https://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf</t> ent="TRUST-LEGAL"/>
<eref target="https://trustee.ietf.org/docs/IETF-Trust-License-Policy.pd
<t>To ensure continuity, the starting point for license text and other f" brackets="angle"/>.</t>
<t pn="section-3-2">To ensure continuity, the starting point for license t
ext and other
materials will be that previously created by the Trustees of the IETF materials will be that previously created by the Trustees of the IETF
under the authority of <xref target="RFC5377"></xref> which this under the authority of <xref target="RFC5377" format="default" sectionForm at="of" derivedContent="RFC5377"/> which this
document supersedes. Changes to the IETF documentation, and document document supersedes. Changes to the IETF documentation, and document
policies themselves, take effect as determined by the Trustees of the policies themselves, take effect as determined by the Trustees of the
IETF Trust.</t> IETF Trust.</t>
<t pn="section-3-3">This document does not specify what rights the IETF Tr
<t>This document does not specify what rights the IETF Trust ust
receives from others in IETF Contributions. That is left to another receives from others in IETF Contributions. That is left to another
document (<xref target="RFC5378"></xref>). While care has been document (<xref target="RFC5378" format="default" sectionFormat="of" deriv edContent="RFC5378"/>). While care has been
taken by the working group in developing this document, taken by the working group in developing this document,
and care will be taken by the Trustees of the IETF Trust, and care will be taken by the Trustees of the IETF Trust,
to see that sufficient rights are granted to the IETF Trust in IETF to see that sufficient rights are granted to the IETF Trust in IETF
Contributions, it is also the case that the Trust can not grant rights Contributions, it is also the case that the Trust can not grant rights
it has not or does not receive, and it is expected that policies will be it has not or does not receive, and it is expected that policies will be
in line with that fact. Similarly, the rights granted for pre-existing in line with that fact. Similarly, the rights granted for pre-existing
documents can not be expanded unless the holders of rights in those documents can not be expanded unless the holders of rights in those
Contributions choose to grant expanded rights. Nonetheless, to the Contributions choose to grant expanded rights. Nonetheless, to the
degree it can, and without degree it can, and without
embarking on a massive effort, it is desirable if similar rights to embarking on a massive effort, it is desirable if similar rights to
those described below can be granted in older RFCs.</t> those described below can be granted in older RFCs.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4">
<section title="Recommended Grants of Right to Copy"> <name slugifiedName="name-recommended-grants-of-right">Recommended Grants
<t>The IETF grants rights to copy and modify parts of IETF Contributions of Right to Copy</name>
<t pn="section-4-1">The IETF grants rights to copy and modify parts of IET
F Contributions
in order to meet the objectives described earlier. As such, different in order to meet the objectives described earlier. As such, different
circumstances and different parts of documents may need different circumstances and different parts of documents may need different
grants. This section contains subsections for each such different grant grants. This section contains subsections for each such different grant
that is currently envisioned. Each section is intended to describe a that is currently envisioned. Each section is intended to describe a
particular usage, to describe how that usage is recognizable, and to particular usage, to describe how that usage is recognizable, and to
provide guidance to the Trustees of the IETF Trust as to what rights provide guidance to the Trustees of the IETF Trust as to what rights
the IETF would like to see granted in that circumstance and what the IETF would like to see granted in that circumstance and what
limitations should be put on such granting.</t> limitations should be put on such granting.</t>
<t pn="section-4-2">These recommendations for outgoing rights are structur
<t>These recommendations for outgoing rights are structured around the ed around the
assumptions documented in <xref target="RFC5378"></xref>. Thus, assumptions documented in <xref target="RFC5378" format="default" sectionF
ormat="of" derivedContent="RFC5378"/>. Thus,
this document is about granting rights derived from those granted to the this document is about granting rights derived from those granted to the
IETF Trust. The recommendations below are how those granted rights should IETF Trust. The recommendations below are how those granted rights should
in turn be passed on to others using IETF documents in ways and for in turn be passed on to others using IETF documents in ways and for
purposes that fit with the goals of the IETF. This discussion purposes that fit with the goals of the IETF. This discussion
is also separate from discussion of the rights the IETF itself requires is also separate from discussion of the rights the IETF itself requires
in documents in documents
to do its job, as those are not "outbound" rights. It is expected that to do its job, as those are not "outbound" rights. It is expected that
the rights granted to the IETF will be a superset of those copying the rights granted to the IETF will be a superset of those copying
rights we wish to grant to others.</t> rights we wish to grant to others.</t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4.1
<section title="Rights Granted for Reproduction of RFCs"> ">
<t>It has long been IETF policy to encourage copying of RFCs in full. <name slugifiedName="name-rights-granted-for-reproduc">Rights Granted fo
r Reproduction of RFCs</name>
<t pn="section-4.1-1">It has long been IETF policy to encourage copying
of RFCs in full.
This permits wide dissemination of the material, without risking loss This permits wide dissemination of the material, without risking loss
of context or meaning. The IETF wishes to continue to permit anyone to of context or meaning. The IETF wishes to continue to permit anyone to
make full copies and translations of RFCs.</t> make full copies and translations of RFCs.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4.2
<section title="Rights Granted for Quoting from IETF Contributions"> ">
<t>There is rough consensus that it is useful to permit quoting <name slugifiedName="name-rights-granted-for-quoting-">Rights Granted fo
r Quoting from IETF Contributions</name>
<t pn="section-4.2-1">There is rough consensus that it is useful to perm
it quoting
without modification of excerpts from IETF Contributions. Such without modification of excerpts from IETF Contributions. Such
excerpts may be of any length and in any context. Translation of excerpts may be of any length and in any context. Translation of
quotations is also to be permitted. All such quotations should be quotations is also to be permitted. All such quotations should be
attributed properly to the IETF and the IETF Contribution from which attributed properly to the IETF and the IETF Contribution from which
they are taken.</t> they are taken.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4.3
<section title="Rights Granted for Implementing Based on IETF ">
Contributions"> <name slugifiedName="name-rights-granted-for-implemen">Rights Granted fo
<t>IETF Contributions often include components intended to be directly r Implementing Based on IETF Contributions</name>
<t pn="section-4.3-1">IETF Contributions often include components intend
ed to be directly
processed by a computer. Examples of these include ABNF definitions, processed by a computer. Examples of these include ABNF definitions,
XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values, XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values,
MIBs, ASN.1, and classical programming code. These are included MIBs, ASN.1, and classical programming code. These are included
in IETF Contributions for clarity and precision in specification. It in IETF Contributions for clarity and precision in specification. It
is clearly beneficial, when such items are included in IETF is clearly beneficial, when such items are included in IETF
Contributions, to permit the inclusion of such code components in Contributions, to permit the inclusion of such code components in
products that implement the Contribution. It has been pointed out products that implement the Contribution. It has been pointed out
that in several important contexts, use of such code requires the that in several important contexts, use of such code requires the
ability to modify the code. One common example of this is simply the ability to modify the code. One common example of this is simply the
need to adapt code for use in specific contexts (languages, compilers, need to adapt code for use in specific contexts (languages, compilers,
tool systems, etc.) Such use frequently requires some changes to the tool systems, etc.) Such use frequently requires some changes to the
text of the code from the IETF Contribution. Another example is that text of the code from the IETF Contribution. Another example is that
code included in open source products is frequently licensed to permit code included in open source products is frequently licensed to permit
any and all of the code to be modified. Since we want this code any and all of the code to be modified. Since we want this code
included in such products, it follows that we need to permit such included in such products, it follows that we need to permit such
modification. While there has been discussion of restricting modification. While there has been discussion of restricting
in some way the rights to make such modifications, the rough consensus in some way the rights to make such modifications, the rough consensus
of the IETF is of the IETF is
that such restrictions are likely a bad idea, and are certainly very that such restrictions are likely a bad idea, and are certainly very
complex to define.</t> complex to define.</t>
<t pn="section-4.3-2"> As such, the rough consensus is that the IETF Tru
<t> As such, the rough consensus is that the IETF Trust is to grant st is to grant
rights such that code components of IETF Contributions can be rights such that code components of IETF Contributions can be
extracted, modified, and used by anyone in any way desired. To extracted, modified, and used by anyone in any way desired. To
enable the broadest possible extraction, modification, and usage, enable the broadest possible extraction, modification, and usage,
the IETF Trust should avoid adding software license obligations the IETF Trust should avoid adding software license obligations
beyond those already present in a Contribution. The granted beyond those already present in a Contribution. The granted
rights to extract, modify, and use code should allow creation rights to extract, modify, and use code should allow creation
of derived works outside the IETF that may carry additional of derived works outside the IETF that may carry additional
license obligations. As the IETF Trust can not grant rights license obligations. As the IETF Trust can not grant rights
it does not receive, the rights to extract, modify, and use code it does not receive, the rights to extract, modify, and use code
described in this paragraph can not be granted in IETF described in this paragraph can not be granted in IETF
Contributions that are explicitly marked as not permitting Contributions that are explicitly marked as not permitting
derivative works.</t> derivative works.</t>
<t pn="section-4.3-3">While it is up to the Trustees of the IETF Trust t
<t>While it is up to the Trustees of the IETF Trust to determine the o determine the
best way of meeting best way of meeting
this objective, two mechanisms are suggested here that are believed to this objective, two mechanisms are suggested here that are believed to
be helpful in documenting the intended grant to readers and users of be helpful in documenting the intended grant to readers and users of
IETF Contributions.</t> IETF Contributions.</t>
<t pn="section-4.3-4">Firstly, the Trustees of the IETF Trust should mai
<t>Firstly, the Trustees of the IETF Trust should maintain, in a ntain, in a
suitable, easily accessible suitable, easily accessible
fashion, a list of common RFC components that will be considered to fashion, a list of common RFC components that will be considered to
be code. To start, this list should include at least the items listed be code. To start, this list should include at least the items listed
above. The Trustees of the IETF Trust will add to this list as above. The Trustees of the IETF Trust will add to this list as
they deem suitable or as they are directed by the IETF.</t> they deem suitable or as they are directed by the IETF.</t>
<t pn="section-4.3-5">Additionally, the Trustees of the IETF Trust shoul
<t>Additionally, the Trustees of the IETF Trust should define a d define a
textual representation to textual representation to
be included in an IETF Contribution to indicate that a portion of the be included in an IETF Contribution to indicate that a portion of the
document is considered by the authors (and later, the working group, document is considered by the authors (and later, the working group,
and upon approval, the IETF) to be code and thus subject to the and upon approval, the IETF) to be code and thus subject to the
permissions granted to use code.</t> permissions granted to use code.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4.4
<section title="Rights Granted for Use of Text from IETF Contributions"> ">
<t>There is no consensus at this time to permit the use of text from <name slugifiedName="name-rights-granted-for-use-of-t">Rights Granted fo
r Use of Text from IETF Contributions</name>
<t pn="section-4.4-1">There is no consensus at this time to permit the u
se of text from
RFCs in contexts where the right to modify the text is required. The RFCs in contexts where the right to modify the text is required. The
authors of IETF Contributions may be able and willing to grant such authors of IETF Contributions may be able and willing to grant such
rights independently of the rights they have granted to the IETF by rights independently of the rights they have granted to the IETF by
making the Contribution.</t> making the Contribution.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4.5
<section title="Additional Licenses for IETF Contributions"> ">
<t>There have been contexts where the material in an IETF Contribution <name slugifiedName="name-additional-licenses-for-iet">Additional Licens
es for IETF Contributions</name>
<t pn="section-4.5-1">There have been contexts where the material in an
IETF Contribution
is also available under other license terms. The IETF wishes to be is also available under other license terms. The IETF wishes to be
able to include content that is available under such licenses. It is able to include content that is available under such licenses. It is
desirable to indicate in the IETF Contribution that other licenses are desirable to indicate in the IETF Contribution that other licenses are
available. It would be inappropriate and confusing if such additional available. It would be inappropriate and confusing if such additional
licenses restricted the rights the IETF intends to grant in the licenses restricted the rights the IETF intends to grant in the
content of RFCS.</t> content of RFCs.</t>
<t pn="section-4.5-2">However, the IETF does not wish to have IETF Contr
<t>However, the IETF does not wish to have IETF Contributions contain ibutions contain
additional licenses, as that introduces a number additional licenses, as that introduces a number
of additional difficulties. of additional difficulties.
Specifically, additional text in the document, and any additional Specifically, additional text in the document, and any additional
license referred to by permitted additional text, must not in any way license referred to by permitted additional text, must not in any way
restrict the rights the IETF intends to grant to others for using the restrict the rights the IETF intends to grant to others for using the
contents of IETF Contributions.</t> contents of IETF Contributions.</t>
<t pn="section-4.5-3">Authors of Contributions retain all rights in thei
<t>Authors of Contributions retain all rights in their Contributions. r Contributions.
As such, an author may directly grant any rights they wish separately As such, an author may directly grant any rights they wish separately
from what the IETF grants. However, a reader wishing to determine or from what the IETF grants. However, a reader wishing to determine or
make use of such grants will need to either consult external sources of make use of such grants will need to either consult external sources of
information, possibly including information, possibly including
open source code and documents, or contact the author directly.</t> open source code and documents, or contact the author directly.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5">
<section title="IANA Considerations"> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t>No values are assigned in this document, no registries are created, <t pn="section-5-1">No values are assigned in this document, no registries
are created,
and there is no action assigned to the IANA by this document. One list and there is no action assigned to the IANA by this document. One list
(of kinds of code sections) is anticipated, to be created and maintained (of kinds of code sections) is anticipated, to be created and maintained
by the Trustees of the IETF Trust. It is up to the Trustees of the IETF by the Trustees of the IETF Trust. It is up to the Trustees of the IETF
Trust whether they create such a list and Trust whether they create such a list and
whether they choose to involve the IANA in maintaining that list.</t> whether they choose to involve the IANA in maintaining that list.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-6">
<section title="Security Considerations"> <name slugifiedName="name-security-considerations">Security Considerations
<t>This document introduces no new security considerations. It is a </name>
<t pn="section-6-1">This document introduces no new security consideration
s. It is a
process document about the IETF's IPR rights being granted to other process document about the IETF's IPR rights being granted to other
people. While there may be attacks against the integrity or people. While there may be attacks against the integrity or
effectiveness of the IETF processes, this document does not address such effectiveness of the IETF processes, this document does not address such
issues.</t> issues.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references pn="section-7">
<?rfc include="reference.RFC.5377" ?> <name slugifiedName="name-references">References</name>
<references pn="section-7.1">
<reference anchor="RFC5378"> <name slugifiedName="name-normative-references">Normative References</na
<front> me>
<title>Rights Contributors Provide to the IETF Trust</title> <reference anchor="RFC5377" target="https://www.rfc-editor.org/info/rfc5
<author initials="S." surname="Bradner" role="editor"></author> 377" quoteTitle="true" derivedAnchor="RFC5377">
<author initials="J." surname="Contreras" role="editor"></author> <front>
<date month="October" year="2008" /> <title>Advice to the Trustees of the IETF Trust on Rights to Be Gran
</front> ted in IETF Documents</title>
<seriesInfo name="BCP" value="78"/> <author initials="J." surname="Halpern" fullname="J. Halpern" role="
<seriesInfo name="RFC" value="5378"/> editor">
</reference> <organization showOnFrontPage="true"/>
</references> </author>
<date year="2008" month="November"/>
<references title="Informative References"> <abstract>
<?rfc include="reference.RFC.3935" ?> <t>Contributors grant intellectual property rights to the IETF. T
he IETF Trust holds and manages those rights on behalf of the IETF. The Trustee
<reference anchor="TRUST-LEGAL"> s of the IETF Trust are responsible for that management. This management includ
<front> es granting the licenses to copy, implement, and otherwise use IETF Contribution
<title>Legal Provisions Relating to IETF Documents</title> s, among them Internet-Drafts and RFCs. The Trustees of the IETF Trust accepts
<author initials="" surname="IETF Trust" fullname="IETF Trust"> direction from the IETF regarding the rights to be granted. This document descr
</author> ibes the desires of the IETF regarding outbound rights to be granted in IETF Con
<date month="March" day="25" year="2015"/> tributions. This memo provides information for the Internet community.</t>
</front> </abstract>
<annotation> </front>
http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf <seriesInfo name="RFC" value="5377"/>
</annotation> <seriesInfo name="DOI" value="10.17487/RFC5377"/>
</reference> </reference>
<reference anchor="RFC5378" target="https://www.rfc-editor.org/info/rfc5
378" quoteTitle="true" derivedAnchor="RFC5378">
<front>
<title>Rights Contributors Provide to the IETF Trust</title>
<author initials="S." surname="Bradner" fullname="S. Bradner" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Contreras" fullname="J. Contreras" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="November"/>
<abstract>
<t>The IETF policies about rights in Contributions to the IETF are
designed to ensure that such Contributions can be made available to the IETF an
d Internet communities while permitting the authors to retain as many rights as
possible. This memo details the IETF policies on rights in Contributions to the
IETF. It also describes the objectives that the policies are designed to meet.
This memo obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces
Section 10 of RFC 2026. This document specifies an Internet Best Current Prac
tices for the Internet Community, and requests discussion and suggestions for im
provements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="78"/>
<seriesInfo name="RFC" value="5378"/>
<seriesInfo name="DOI" value="10.17487/RFC5378"/>
</reference>
</references>
<references pn="section-7.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="RFC3935" target="https://www.rfc-editor.org/info/rfc3
935" quoteTitle="true" derivedAnchor="RFC3935">
<front>
<title>A Mission Statement for the IETF</title>
<author initials="H." surname="Alvestrand" fullname="H. Alvestrand">
<organization showOnFrontPage="true"/>
</author>
<date year="2004" month="October"/>
<abstract>
<t>This memo gives a mission statement for the IETF, tries to defi
ne the terms used in the statement sufficiently to make the mission statement un
derstandable and useful, argues why the IETF needs a mission statement, and trie
s to capture some of the debate that led to this point. This document specifies
an Internet Best Current Practices for the Internet Community, and requests dis
cussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="95"/>
<seriesInfo name="RFC" value="3935"/>
<seriesInfo name="DOI" value="10.17487/RFC3935"/>
</reference>
<reference anchor="TRUST-LEGAL" target="http://trustee.ietf.org/docs/IET
F-Trust-License-Policy.pdf" quoteTitle="true" derivedAnchor="TRUST-LEGAL">
<front>
<title>Legal Provisions Relating to IETF Documents</title>
<author>
<organization showOnFrontPage="true">IETF Trust</organization>
</author>
<date month="March" year="2015"/>
</front>
</reference>
</references>
</references> </references>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.a">
<name slugifiedName="name-authors-address">Author's Address</name>
<author fullname="Joel M. Halpern" initials="J." role="editor" surname="Ha
lpern">
<organization abbrev="Ericsson" showOnFrontPage="true">Ericsson</organiz
ation>
<address>
<postal>
<street>P. O. Box 6049</street>
<city>Leesburg</city>
<region>VA</region>
<code>20178</code>
<country>United States of America</country>
</postal>
<email>joel.halpern@ericsson.com</email>
</address>
</author>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 42 change blocks. 
135 lines changed or deleted 399 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/