doc: Add RFC documents

1 files changed, 349 insertions, 0 deletions

diff --git a/doc/rfc/rfc8721.txt b/doc/rfc/rfc8721.txt
new file mode 100644
index 0000000..674366a
--- /dev/null
+++ b/doc/rfc/rfc8721.txt
@@ -0,0 +1,349 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                   J. Halpern, Ed.
+Request for Comments: 8721                                      Ericsson
+Obsoletes: 5377                                            February 2020
+Category: Informational                                                 
+ISSN: 2070-1721
+
+
+Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF
+                               Documents
+
+Abstract
+
+   Contributors grant intellectual property rights to 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
+   management includes granting the licenses to copy, implement, and
+   otherwise use IETF Contributions, among them Internet-Drafts and
+   RFCs.  The Trustees of the IETF Trust accept direction from the IETF
+   regarding the rights to be granted.  This document describes the
+   desires of the IETF regarding outbound rights to be granted in IETF
+   Contributions.  This document obsoletes RFC 5377 solely for the
+   purpose of removing references to the IETF Administrative Oversight
+   Committee (IAOC), which was part of the IETF Administrative Support
+   Activity (IASA).
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8721.
+
+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.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Purpose in Granting Rights
+   3.  Powers and Authority
+   4.  Recommended Grants of Right to Copy
+     4.1.  Rights Granted for Reproduction of RFCs
+     4.2.  Rights Granted for Quoting from IETF Contributions
+     4.3.  Rights Granted for Implementing Based on IETF Contributions
+     4.4.  Rights Granted for Use of Text from IETF Contributions
+     4.5.  Additional Licenses for IETF Contributions
+   5.  IANA Considerations
+   6.  Security Considerations
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   Author's Address
+
+1.  Introduction
+
+   Under the current operational and administrative structures, IETF
+   intellectual property rights are vested in the IETF Trust
+   administered 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 [RFC5378].  The Trustees of the IETF Trust 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 documents.
+
+   For consistency and clarity, this document uses the same terminology
+   laid out in [RFC5378] and uses the same meanings as defined in that
+   document.
+
+   The IETF Trust, by way of its Trustees, has indicated, as is
+   consistent with the IETF structure, 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 articulate those wishes.
+   This document represents the wishes of the IETF regarding the rights
+   granted to all users in regard to IETF Contributions, until it is
+   superseded.
+
+2.  Purpose in Granting Rights
+
+   In providing a description of the wishes of the IETF with regard to
+   rights granted in RFCs, it is helpful to keep in mind the purpose of
+   granting such rights.
+
+   The mission of the IETF is to produce documents that make the
+   Internet work better (see [RFC3935] for more details).  These
+   documents, when completed, are published as RFCs.
+
+   An important subclass of RFCs is standards describing protocols; for
+   these, the primary value to the Internet is the ability of
+   implementors to build solutions (products, software, etc.) that
+   interoperate using these standards.  Hence, the IETF has a strong
+   interest in seeing accurate, interoperable implementations of the
+   material the IETF publishes.  The IETF Trust grants rights to copy to
+   people to make use of the text in the RFCs in order to encourage
+   accurate and interoperable implementations.
+
+   As early implementations from Internet-Drafts make use of
+   descriptions in those Internet-Drafts, similar desires apply to
+   Internet-Drafts.
+
+   Similar considerations also apply to non-standard, non-protocol
+   documents such as BCP (Best Current Practice) and Informational
+   documents; in this document, we recommend a common approach to the
+   issue of right-to-use licenses for all IETF documents.
+
+   Previous documents regarding rights in IETF documents have included
+   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,
+   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
+   issues that need prompt attention.  As such, this document describes
+   the IETF desires to the Trustees of the IETF Trust, but does not
+   provide the specific legal wording to address the goals.  The
+   selection, and updating as necessary, of legal wording is left to the
+   Trustees of the IETF Trust.
+
+3.  Powers and Authority
+
+   As described in the introduction, and formally specified in
+   [RFC5378], the legal authority for determining and granting users
+   rights to copy material in RFCs and other IETF Contributions rests
+   with the Trustees for the IETF Trust.  This document provides
+   guidance to that body, based on the rough consensus of the IETF.  The
+   Trustees of the IETF Trust have the authority and responsibility to
+   determine the exact text insertions (or other mechanisms), if any,
+   needed in Internet-Drafts, RFCs, and all IETF Contributions to meet
+   these goals.  The IETF Trust License Policy is available from
+   [TRUST-LEGAL] <https://trustee.ietf.org/docs/IETF-Trust-License-
+   Policy.pdf>.
+
+   To ensure continuity, the starting point for license text and other
+   materials will be that previously created by the Trustees of the IETF
+   under the authority of [RFC5377] which this document supersedes.
+   Changes to the IETF documentation, and document policies themselves,
+   take effect as determined by the Trustees of the IETF Trust.
+
+   This document does not specify what rights the IETF Trust receives
+   from others in IETF Contributions.  That is left to another document
+   ([RFC5378]).  While care has been taken by the working group in
+   developing this document, 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 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 in line with that fact.  Similarly, the rights
+   granted for pre-existing documents can not be expanded unless the
+   holders of rights in those Contributions choose to grant expanded
+   rights.  Nonetheless, to the degree it can, and without embarking on
+   a massive effort, it is desirable if similar rights to those
+   described below can be granted in older RFCs.
+
+4.  Recommended Grants of Right to Copy
+
+   The IETF grants rights to copy and modify parts of IETF Contributions
+   in order to meet the objectives described earlier.  As such,
+   different circumstances and different parts of documents may need
+   different grants.  This section contains subsections for each such
+   different grant that is currently envisioned.  Each section is
+   intended to describe a particular usage, to describe how that usage
+   is recognizable, and to 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 limitations should be put on such granting.
+
+   These recommendations for outgoing rights are structured around the
+   assumptions documented in [RFC5378].  Thus, this document is about
+   granting rights derived from those granted to the 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 purposes
+   that fit with the goals of the IETF.  This discussion is also
+   separate from discussion of the rights the IETF itself requires in
+   documents 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 rights we wish to grant to others.
+
+4.1.  Rights Granted for Reproduction of RFCs
+
+   It has long been IETF policy to encourage copying of RFCs in full.
+   This permits wide dissemination of the material, without risking loss
+   of context or meaning.  The IETF wishes to continue to permit anyone
+   to make full copies and translations of RFCs.
+
+4.2.  Rights Granted for Quoting from IETF Contributions
+
+   There is rough consensus that it is useful to permit quoting without
+   modification of excerpts from IETF Contributions.  Such excerpts may
+   be of any length and in any context.  Translation of quotations is
+   also to be permitted.  All such quotations should be attributed
+   properly to the IETF and the IETF Contribution from which they are
+   taken.
+
+4.3.  Rights Granted for Implementing Based on IETF Contributions
+
+   IETF Contributions often include components intended to be directly
+   processed by a computer.  Examples of these include ABNF definitions,
+   XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values,
+   MIBs, ASN.1, and classical programming code.  These are included in
+   IETF Contributions for clarity and precision in specification.  It is
+   clearly beneficial, when such items are included in IETF
+   Contributions, to permit the inclusion of such code components in
+   products that implement the Contribution.  It has been pointed out
+   that in several important contexts, use of such code requires 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, tool systems, etc.)  Such use frequently requires some
+   changes to the text of the code from the IETF Contribution.  Another
+   example is that 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 included in such products, it follows that we need to
+   permit such modification.  While there has been discussion of
+   restricting in some way the rights to make such modifications, the
+   rough consensus of the IETF is that such restrictions are likely a
+   bad idea, and are certainly very complex to define.
+
+   As such, the rough consensus is that the IETF Trust is to grant
+   rights such that code components of IETF Contributions can be
+   extracted, modified, and used by anyone in any way desired.  To
+   enable the broadest possible extraction, modification, and usage, the
+   IETF Trust should avoid adding software license obligations beyond
+   those already present in a Contribution.  The granted rights to
+   extract, modify, and use code should allow creation of derived works
+   outside the IETF that may carry additional license obligations.  As
+   the IETF Trust can not grant rights it does not receive, the rights
+   to extract, modify, and use code described in this paragraph can not
+   be granted in IETF Contributions that are explicitly marked as not
+   permitting derivative works.
+
+   While it is up to the Trustees of the IETF Trust to determine the
+   best way of meeting this objective, two mechanisms are suggested here
+   that are believed to be helpful in documenting the intended grant to
+   readers and users of IETF Contributions.
+
+   Firstly, the Trustees of the IETF Trust should maintain, in a
+   suitable, easily accessible 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 above.  The Trustees of the IETF
+   Trust will add to this list as they deem suitable or as they are
+   directed by the IETF.
+
+   Additionally, the Trustees of the IETF Trust should define a textual
+   representation to be included in an IETF Contribution to indicate
+   that a portion of the document is considered by the authors (and
+   later, the working group, and upon approval, the IETF) to be code and
+   thus subject to the permissions granted to use code.
+
+4.4.  Rights Granted for Use of Text from IETF Contributions
+
+   There is no consensus at this time to permit the use of text from
+   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
+   rights independently of the rights they have granted to the IETF by
+   making the Contribution.
+
+4.5.  Additional Licenses for IETF Contributions
+
+   There have been contexts where the material in an IETF Contribution
+   is also available under other license terms.  The IETF wishes to be
+   able to include content that is available under such licenses.  It is
+   desirable to indicate in the IETF Contribution that other licenses
+   are available.  It would be inappropriate and confusing if such
+   additional licenses restricted the rights the IETF intends to grant
+   in the content of RFCs.
+
+   However, the IETF does not wish to have IETF Contributions contain
+   additional licenses, as that introduces a number of additional
+   difficulties.  Specifically, additional text in the document, and any
+   additional 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 contents of IETF Contributions.
+
+   Authors of Contributions retain all rights in their Contributions.
+   As such, an author may directly grant any rights they wish separately
+   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 information, possibly including open source code and documents, or
+   contact the author directly.
+
+5.  IANA Considerations
+
+   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 (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 Trust whether they create such a list and
+   whether they choose to involve the IANA in maintaining that list.
+
+6.  Security Considerations
+
+   This document introduces no new security considerations.  It is a
+   process document about the IETF's IPR rights being granted to other
+   people.  While there may be attacks against the integrity or
+   effectiveness of the IETF processes, this document does not address
+   such issues.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC5377]  Halpern, J., Ed., "Advice to the Trustees of the IETF
+              Trust on Rights to Be Granted in IETF Documents",
+              RFC 5377, DOI 10.17487/RFC5377, November 2008,
+              <https://www.rfc-editor.org/info/rfc5377>.
+
+   [RFC5378]  Bradner, S., Ed. and J. Contreras, Ed., "Rights
+              Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
+              DOI 10.17487/RFC5378, November 2008,
+              <https://www.rfc-editor.org/info/rfc5378>.
+
+7.2.  Informative References
+
+   [RFC3935]  Alvestrand, H., "A Mission Statement for the IETF",
+              BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
+              <https://www.rfc-editor.org/info/rfc3935>.
+
+   [TRUST-LEGAL]
+              IETF Trust, "Legal Provisions Relating to IETF Documents",
+              March 2015, <http://trustee.ietf.org/docs/IETF-Trust-
+              License-Policy.pdf>.
+
+Author's Address
+
+   Joel M. Halpern (editor)
+   Ericsson
+   P. O. Box 6049
+   Leesburg, VA 20178
+   United States of America
+
+   Email: joel.halpern@ericsson.com