doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc5377.txt b/doc/rfc/rfc5377.txt
new file mode 100644
index 0000000..362e852
--- /dev/null
+++ b/doc/rfc/rfc5377.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                    J. Halpern, Ed.
+Request for Comments: 5377                                          Self
+Category: Informational                                    November 2008
+
+
+                Advice to the Trustees of the IETF Trust
+               on Rights to Be Granted in IETF Documents
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2008 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
+   (http://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.
+
+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 accepts 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Halpern                      Informational                      [Page 1]
+
+RFC 5377                 Outbound Rights Advice            November 2008
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  Purpose in Granting Rights  . . . . . . . . . . . . . . . . . . 2
+   3.  Powers and Authority  . . . . . . . . . . . . . . . . . . . . . 3
+   4.  Recommended Grants of Right to Copy . . . . . . . . . . . . . . 4
+     4.1.  Rights Granted for Reproduction of RFCs . . . . . . . . . . 5
+     4.2.  Rights Granted for Quoting from IETF Contributions  . . . . 5
+     4.3.  Rights Granted for Implementing Based on IETF
+           Contributions . . . . . . . . . . . . . . . . . . . . . . . 5
+     4.4.  Rights Granted for Use of Text from IETF Contributions  . . 6
+     4.5.  Additional Licenses for IETF Contributions  . . . . . . . . 6
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
+     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
+
+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 made up of the members of the
+   IAOC [RFC4371].  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.
+
+
+
+
+
+Halpern                      Informational                      [Page 2]
+
+RFC 5377                 Outbound Rights Advice            November 2008
+
+
+   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.  Appeals of the actions of the Trustees
+   of the IETF Trust are governed by other documents.  As the Trustees
+   are the members of the IAOC, the appeals procedure documented in BCP
+   101 (currently [RFC4371]) is applicable.
+
+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, which is made up of the members
+   of the IAOC, as described in [RFC4071] and [RFC4371].  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
+
+
+
+
+Halpern                      Informational                      [Page 3]
+
+RFC 5377                 Outbound Rights Advice            November 2008
+
+
+   Contributions to meet these goals.  The IETF Trust License Policy is
+   available from http://trustee.ietf.org/license-info.
+
+   The rough consensus described in this document reflects the agreement
+   of the IETF as of the IETF Last Call, and the Trustees of the IETF
+   Trust are to begin drafting license text and other materials to act
+   on these instructions upon IESG approval of this document for RFC
+   publication.  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.
+
+
+
+
+Halpern                      Informational                      [Page 4]
+
+RFC 5377                 Outbound Rights Advice            November 2008
+
+
+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
+
+
+
+Halpern                      Informational                      [Page 5]
+
+RFC 5377                 Outbound Rights Advice            November 2008
+
+
+   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.
+
+
+
+
+
+Halpern                      Informational                      [Page 6]
+
+RFC 5377                 Outbound Rights Advice            November 2008
+
+
+   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
+
+   [RFC5378]  Bradner, S., Ed. and J. Contreras, Ed., "Rights
+              Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
+              November 2008.
+
+7.2.  Informative References
+
+   [RFC3935]  Alvestrand, H., "A Mission Statement for the IETF",
+              BCP 95, RFC 3935, October 2004.
+
+   [RFC4071]  Austein, R. and B. Wijnen, "Structure of the IETF
+              Administrative Support Activity (IASA)", BCP 101,
+              RFC 4071, April 2005.
+
+   [RFC4371]  Carpenter, B. and L. Lynch, "BCP 101 Update for IPR
+              Trust", BCP 101, RFC 4371, January 2006.
+
+
+
+
+
+
+
+
+Halpern                      Informational                      [Page 7]
+
+RFC 5377                 Outbound Rights Advice            November 2008
+
+
+Author's Address
+
+   Joel M. Halpern (editor)
+   Self
+   P. O. Box 6049
+   Leesburg, VA  20178
+   US
+
+   EMail: jmh@joelhalpern.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Halpern                      Informational                      [Page 8]
+