doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc5378.txt b/doc/rfc/rfc5378.txt
new file mode 100644
index 0000000..cc24d42
--- /dev/null
+++ b/doc/rfc/rfc5378.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                    S. Bradner, Ed.
+Request for Comments: 5378                            Harvard University
+BCP: 78                                                J. Contreras, Ed.
+Obsoletes: 3978, 4748                                         WilmerHale
+Updates: 2026                                              November 2008
+Category: Best Current Practice
+
+
+             Rights Contributors Provide to the IETF Trust
+
+Status of This Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  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
+
+   The IETF policies about rights in Contributions to the IETF are
+   designed to ensure that such Contributions can be made available to
+   the IETF and 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner & Contreras      Best Current Practice                  [Page 1]
+
+RFC 5378                   RFC 3978-incoming               November 2008
+
+
+Table of Contents
+
+   1. Definitions .....................................................3
+   2. Introduction ....................................................5
+      2.1. No Retroactive Effect ......................................5
+   3. Exposition of Why These Procedures Are the Way They Are .........6
+      3.1. Rights Granted in Contributions ............................6
+      3.2. Rights to Use Contributions ................................6
+      3.3. Right to Produce Derivative Works ..........................6
+      3.4. Rights to Use Trademarks ...................................8
+      3.5. Contributions Not Subject to Copyright .....................8
+      3.6. Copyright in RFCs ..........................................9
+   4. Non-IETF Documents ..............................................9
+   5. Rights in Contributions .........................................9
+      5.1. General Policy .............................................9
+      5.2. Confidentiality Obligations ...............................10
+      5.3. Rights Granted by Contributors to the IETF Trust ..........10
+      5.4. Sublicenses by the IETF Trust .............................11
+      5.5. No Patent License .........................................11
+      5.6. Representations and Warranties ............................11
+      5.7. No Duty to Publish ........................................12
+      5.8. Trademarks ................................................12
+      5.9. Copyright in RFCs .........................................12
+      5.10. Contributors' Retention of Rights ........................12
+   6. Legends, Notices and Other Standardized Text in IETF
+      Documents ......................................................13
+   7. Security Considerations ........................................13
+   8. References .....................................................14
+      8.1. Normative References ......................................14
+      8.2. Informative References ....................................14
+   9. Acknowledgments ................................................15
+   10. Changes since RFC 3978 ........................................15
+   11. Declaration from the IAB ......................................16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner & Contreras      Best Current Practice                  [Page 2]
+
+RFC 5378                   RFC 3978-incoming               November 2008
+
+
+1.  Definitions
+
+   The following definitions are for terms used in the context of this
+   document.  Other terms, including "IESG", "ISOC", "IAB", and "RFC
+   Editor" are defined in [RFC2028].
+
+   a. "Contribution": any submission to the IETF intended by the
+      Contributor for publication as all or part of an Internet-Draft or
+      RFC (except for RFC Editor Contributions described in Section 4
+      below) and any statement made within the context of an IETF
+      activity.  Such statements include oral statements in IETF
+      sessions as well as written and electronic communications, made at
+      any time or place, that are addressed to:
+
+      o the IETF plenary session,
+      o any IETF working group or portion thereof,
+      o any Birds of a Feather (BOF) session,
+      o the IESG, or any member thereof on behalf of the IESG,
+      o the IAB, or any member thereof on behalf of the IAB,
+      o any IETF mailing list, including the IETF list itself, any
+        working group or design team list, or any other list functioning
+        under IETF auspices,
+      o the RFC Editor or the Internet-Drafts function (except for RFC
+        Editor Contributions, as described in Section 4 below).
+
+      Statements made outside of an IETF session, mailing list, or other
+      function, that are clearly not intended to be input to an IETF
+      activity, group, or function are not IETF Contributions in the
+      context of this document.
+
+   b. "Contributor": an individual submitting a Contribution.
+
+   c. "Indirect Contributor": any person who has materially or
+      substantially contributed to a Contribution without being
+      personally involved in its submission to the IETF.
+
+   d. "Copyright": the legal right granted to an author in a document or
+      other work of authorship under applicable law.  A "copyright" is
+      not equivalent to a "right to copy".  Rather a copyright
+      encompasses all of the exclusive rights that an author has in a
+      work, such as the rights to copy, publish, distribute and create
+      derivative works of the work.  An author often cedes these rights
+      to his or her employer or other parties as a condition of
+      employment or compensation.
+
+   e. "IETF": in the context of this document, the IETF includes all
+      individuals who participate in meetings, working groups, mailing
+      lists, functions, and other activities that are organized or
+
+
+
+Bradner & Contreras      Best Current Practice                  [Page 3]
+
+RFC 5378                   RFC 3978-incoming               November 2008
+
+
+      initiated by ISOC, the IESG, or the IAB under the general
+      designation of the Internet Engineering Task Force (IETF), but
+      solely to the extent of such participation.
+
+   f. "IETF Documents": RFCs and Internet-Drafts that are used in the
+      IETF Standards Process as defined in 1(g).  This is identical to
+      the "IETF stream" defined in [RFC4844].
+
+   g. "IETF Standards Process": the activities undertaken by the IETF in
+      any of the settings described in 1(a) above.
+
+   h. "IETF Trust": a trust established under the laws of the
+      Commonwealth of Virginia, USA, in order to hold and administer
+      intellectual property rights for the benefit of the IETF.
+
+   i. "Internet-Draft": temporary documents used in the IETF Standards
+      Process.  Internet-Drafts are posted on the IETF web site by the
+      IETF Secretariat.  As noted in Section 2.2 of RFC 2026, Internet-
+      Drafts have a nominal maximum lifetime of six months in the IETF
+      Secretariat's public directory.
+
+   j. "Legend Instructions": the standardized text that is maintained by
+      the IETF Trust and is included in IETF Documents and the
+      instructions and requirements for including that standardized text
+      in IETF Documents.  The text and instructions are posted from time
+      to time at http://trustee.ietf.org/license-info.
+
+   k. "RFC": the publication series used by the IETF among others.  RFCs
+      are published by the RFC Editor.  Although RFCs may be superseded
+      in whole or in part by subsequent RFCs, the text of an RFC is not
+      altered once published in RFC form.  (See [RFC2026] Section 2.1.)
+
+   l. "Reasonably and personally known": something an individual knows
+      personally or, because of the job the individual holds, would
+      reasonably be expected to know.  This wording is used to indicate
+      that an organization cannot purposely keep an individual in the
+      dark about certain information just to avoid the disclosure
+      requirement.
+
+   m. "Non-IETF documents": Internet-Drafts that are submitted to the
+      RFC Editor independently of the IETF Standards Process.  (See
+      Section 4.)
+
+
+
+
+
+
+
+
+
+Bradner & Contreras      Best Current Practice                  [Page 4]
+
+RFC 5378                   RFC 3978-incoming               November 2008
+
+
+2.  Introduction
+
+   In all matters of copyright and document procedures, the intent is to
+   benefit the Internet community and the public at large, while
+   respecting the legitimate rights of others.
+
+   Under the laws of most countries and current international treaties
+   (for example the "Berne Convention for the Protection of Literary and
+   Artistic Work" [Berne]), authors obtain numerous rights in the works
+   they produce automatically upon producing them.  These rights include
+   copyrights, moral rights, and other rights.  In many cases, if the
+   author produces a work within the scope of his or her employment,
+   most of those rights are usually assigned to the employer, either by
+   operation of law or, in many cases, under contract.  (The Berne
+   Convention names some rights as "inalienable", which means that the
+   author retains them in all cases.)
+
+   In order for Contributions to be used within the IETF Standards
+   Process, including when they are published as Internet-Drafts or
+   RFCs, certain limited rights must be granted to the IETF Trust, which
+   then grants the necessary rights to the IETF.  In addition,
+   Contributors must make representations to the IETF Trust and the IETF
+   regarding their ability to grant these rights.
+
+   Section 1 provides definitions used in these policies.  Sections 3
+   and 4 of this document explain the rationale for these provisions.
+   Sections 1, 2, 5, and 6 of this document are normative, the other
+   sections are informative.  RFC 3979 (BCP 79) [RFC3979] deals with
+   rights, including possible patent rights, in technologies developed
+   or specified as part of the IETF Standards Process.  This document is
+   not intended to address those issues.  This memo obsoletes RFCs 3978
+   [RFC3978] and 4748 [RFC4748] and, with RFC 3979 (BCP 79) and
+   [RFC5377], replaces Section 10 of RFC 2026 [RFC2026].
+
+   This document is not intended as legal advice.  Readers are advised
+   to consult their own legal advisors if they would like a legal
+   interpretation of their rights or the rights of the IETF Trust
+   [RFC4371] in any Contributions they make.
+
+2.1.  No Retroactive Effect
+
+   This memo does not retroactively obtain additional rights from
+   Contributions that predate the date that the IETF Trust announces the
+   adoption of these procedures.
+
+
+
+
+
+
+
+Bradner & Contreras      Best Current Practice                  [Page 5]
+
+RFC 5378                   RFC 3978-incoming               November 2008
+
+
+3.  Exposition of Why These Procedures Are the Way They Are
+
+3.1.  Rights Granted in Contributions
+
+   The IETF Trust and the IETF must obtain the right to publish an IETF
+   Contribution as an RFC or an Internet-Draft from the Contributors.
+
+   A primary objective of this policy is to obtain from the document
+   authors only the non-exclusive rights that are needed to develop and
+   publish IETF Documents and to use IETF Contributions in the IETF
+   Standards Process and potentially elsewhere.
+
+   The authors retain all other rights, but cannot withdraw the above
+   rights from the IETF Trust and the IETF.
+
+   It is important to note that under this document, Contributors are
+   required to grant certain rights to the IETF Trust (see Section
+   5.3.), which holds all IETF-related intellectual property on behalf
+   of the IETF community.  The IETF Trust will, in turn, grant a
+   sublicense of these rights to all IETF participants for use in the
+   IETF Standards Process (see Section 5.4.).  This sublicense is
+   necessary for the standards development work of the IETF to continue.
+   In addition, the IETF Trust may grant certain other sublicenses of
+   the rights that it is granted under this document.  In granting such
+   other sublicenses, the IETF Trust will be guided and bound by
+   documents such as [RFC5377].
+
+3.2.  Rights to Use Contributions
+
+   It is important that the IETF receive assurances from all
+   Contributors that they have the authority to grant the IETF the
+   rights that they claim to grant because, under the laws of most
+   countries and applicable international treaties, copyright rights
+   come into existence when a work of authorship is created (but see
+   Section 3.5 below regarding public domain documents), and the IETF
+   cannot make use of IETF Contributions if it does not have sufficient
+   rights with respect to these copyright rights.  The IETF and its
+   participants would run a greater risk of liability to the owners of
+   these rights without this assurance.  To this end, the IETF asks
+   Contributors to give the assurances in Section 5.6 below.  These
+   assurances are requested, however, only to the extent of the
+   Contributor's reasonable and personal knowledge.  (See Section 1(l).)
+
+3.3.  Right to Produce Derivative Works
+
+   The IETF needs to be able to evolve IETF Documents in response to
+   experience gained in the deployment of the technologies described in
+   such IETF Documents, to incorporate developments in research, and to
+
+
+
+Bradner & Contreras      Best Current Practice                  [Page 6]
+
+RFC 5378                   RFC 3978-incoming               November 2008
+
+
+   react to changing conditions on the Internet and other IP networks.
+   The IETF may also decide to permit others to develop derivative works
+   based on Contributions.  In order to do this, the IETF must be able
+   to produce derivatives of its documents; thus, the IETF must obtain
+   the right from Contributors to produce derivative works.  Note that
+   the right to produce translations is required before any Contribution
+   can be published as an RFC, to ensure the widest possible
+   distribution of the material in RFCs.  The right to produce
+   derivative works, in addition to translations, is required for all
+   IETF Standards Track documents and for most IETF non-Standards Track
+   documents.  There are two exceptions to this requirement: documents
+   describing proprietary technologies and documents that are
+   republications of the work of other standards organizations.
+
+   The right to produce derivative works must be granted in order for an
+   IETF working group to accept a Contribution as a working group
+   document or otherwise work on it.  For non-working group
+   Contributions where the Contributor requests publication as a
+   Standards Track RFC, the right to produce derivative works must be
+   granted before the IESG will issue an IETF Last Call and, for most
+   non-Standards Track, non-working group Contributions, before the IESG
+   will consider the Internet-Draft for publication.  Occasionally a
+   Contributor may not want to grant publication rights or the right to
+   produce derivative works before finding out if a Contribution has
+   been accepted for development in the IETF Standards Process.  In
+   these cases, the Contributor may include a limitation on the right to
+   make derivative works in the form specified in the Legend
+   Instructions.  A working group can discuss the Contribution with the
+   aim to decide if it should become a working group document, even
+   though the right to produce derivative works or to publish the
+   Contribution as an RFC has not yet been granted.  However, if the
+   Contribution is accepted for development, the Contributor must
+   resubmit the Contribution without the limitation notices before a
+   working group can formally adopt the Contribution as a working group
+   document.  The IETF Trust may establish different policies for
+   granting sublicenses with respect to different types of Contributions
+   and content within Contributions (such as executable code versus
+   descriptive text or references to third-party materials).  The IETF
+   Trust's policies concerning the granting of sublicenses to make
+   derivative works will be guided by RFC [RFC5377].
+
+   The IETF has historically encouraged organizations to publish details
+   of their technologies, even when the technologies are proprietary,
+   because understanding how existing technology is being used helps
+   when developing new technology.  But organizations that publish
+   information about proprietary technologies are frequently not willing
+   to have the IETF produce revisions of the technologies and then
+   possibly claim that the IETF version is the "new version" of the
+
+
+
+Bradner & Contreras      Best Current Practice                  [Page 7]
+
+RFC 5378                   RFC 3978-incoming               November 2008
+
+
+   organization's technology.  Organizations that feel this way can
+   specify that a Contribution be published with the other rights
+   granted under this document but may withhold the right to produce
+   derivative works other than translations.
+
+   In addition, IETF Documents frequently make normative references to
+   standards or recommendations developed by other standards
+   organizations.  Since the publications of some standards
+   organizations are not public documents, it can be quite helpful to
+   the IETF to republish, with the permission of the other standards
+   organization, some of these documents as RFCs so that the IETF
+   community can have open access to them to better understand what they
+   are referring to.  In these cases, the RFCs can be published without
+   the right for the IETF to produce derivative works.  In both of the
+   above cases, in which the production of derivative works is excluded,
+   the Contributor must include a special legend in the Contribution, as
+   specified in the Legend Instructions, in order to notify IETF
+   participants about this restriction.
+
+3.4.  Rights to Use Trademarks
+
+   Contributors may wish to seek trademark or service mark protection on
+   any terms that are coined or used in their Contributions.  The IETF
+   makes no judgment about the validity of any such trademark rights.
+   However, the IETF requires each Contributor, under the licenses
+   described in Section 5.3 below, to grant the IETF Trust a perpetual
+   license to use any such trademarks or service marks solely in
+   exercising rights to reproduce, publish, discuss, and modify the IETF
+   Contribution.  This license does not authorize the IETF or others to
+   use any trademark or service mark in connection with any product or
+   service offering.
+
+3.5.  Contributions Not Subject to Copyright
+
+   Certain documents, including those produced by the U.S. government
+   and those which are in the public domain, may not be protected by the
+   same copyright and other legal rights as other documents.
+   Nevertheless, we ask each Contributor to grant to the IETF the same
+   rights he or she would grant, and to make the same representations,
+   as though the IETF Contribution were protected by the same legal
+   rights as other documents, and as though the Contributor could be
+   able to grant these rights.  We ask for these grants and
+   representations only to the extent that the Contribution may be
+   protected.  We believe they are necessary to protect the ISOC, the
+   IETF Trust, the IETF, the IETF Standards Process, and all IETF
+   participants, and because the IETF does not have the resources or
+   wherewithal to make any independent investigation as to the actual
+   proprietary status of any document submitted to it.
+
+
+
+Bradner & Contreras      Best Current Practice                  [Page 8]
+
+RFC 5378                   RFC 3978-incoming               November 2008
+
+
+3.6.  Copyright in RFCs
+
+   As noted above, Contributors to the IETF (or their employers) retain
+   ownership of the copyright in their Contributions.  This includes
+   Internet-Drafts and all other Contributions made within the IETF
+   Standards Process (e.g., via e-mail, oral comment, and otherwise).
+   However, it is important that the IETF (through the IETF Trust) own
+   the copyright in documents that are published as RFCs (other than
+   Informational RFCs and RFCs that are submitted as RFC Editor
+   Contributions).  Ownership of the copyright in an RFC does not
+   diminish the Contributors' rights in their underlying contributions,
+   but it does prevent anyone other than the IETF Trust (and its
+   licensees) from republishing or modifying an RFC in RFC format.  In
+   this respect, Contributors are treated the same as anybody else:
+   though they may extract and republish their own Contributions without
+   limitation, they may not do so in the RFC format used by the IETF.
+   And while this principle (which is included in Section 5.9 below) may
+   appear to be new to the IETF, it actually reflects historical
+   practice and has been observed for many years through the inclusion
+   of an ISOC or IETF Trust copyright notice on all RFC documents since
+   the publication of RFC 2026.
+
+4.  Non-IETF Documents
+
+   This document only relates to Contributions made as part of the IETF
+   Processes.  Other documents that are referred to as Internet-Drafts
+   and RFCs may be submitted to and published by the RFC Editor
+   independently of the IETF Standards Process.  Such documents are not
+   covered by this document, unless the controlling entity for that
+   document stream, as described in [RFC4844] chooses to apply these
+   rules.  Non-IETF Contributions must be marked appropriately as
+   described in the Legend Instructions.  See the RFC Editor web page
+   for information about the policies concerning rights in RFC Editor
+   Documents; for other document streams, the controlling entity must be
+   contacted.  See Section 11 for a declaration from the IAB on this
+   matter.
+
+5.  Rights in Contributions
+
+5.1.  General Policy
+
+   By submission of a Contribution, each person actually submitting the
+   Contribution and each named co-Contributor is deemed to have read and
+   understood the rules and requirements set forth in this document.
+   Each Contributor is deemed, by the act of submitting a Contribution,
+   to enter into a legally-binding agreement to comply with the terms
+   and conditions set forth in this document.
+
+
+
+
+Bradner & Contreras      Best Current Practice                  [Page 9]
+
+RFC 5378                   RFC 3978-incoming               November 2008
+
+
+   The Contributor is further deemed to have agreed that he/she has
+   obtained the necessary permissions to enter into such an agreement
+   from any party that the Contributor reasonably and personally knows
+   may have rights in the Contribution, including, but not limited to,
+   the Contributor's sponsor or employer.
+
+   No further acknowledgment, signature, or other action is required to
+   bind a Contributor to these terms and conditions.  The operation of
+   the IETF and the work conducted by its many participants is dependent
+   on such agreement by each Contributor, and each IETF participant
+   expressly relies on the agreement of each Contributor to the terms
+   and conditions set forth in this document.
+
+5.2.  Confidentiality Obligations
+
+   No information or document that is subject to any requirement of
+   confidentiality or any restriction on its dissemination may be
+   submitted as a Contribution or otherwise considered in any part of
+   the IETF Standards Process, and there must be no assumption of any
+   confidentiality obligation with respect to any Contribution.  Each
+   Contributor agrees that any statement in a Contribution, whether
+   generated automatically or otherwise, that states or implies that the
+   Contribution is confidential or subject to any privilege, can be
+   disregarded for all purposes, and will be of no force or effect.
+
+5.3.  Rights Granted by Contributors to the IETF Trust
+
+   To the extent that a Contribution or any portion thereof is protected
+   by copyright or other rights of authorship, the Contributor and each
+   named co-Contributor grant a perpetual, irrevocable, non-exclusive,
+   royalty-free, world-wide, sublicensable right and license to the IETF
+   Trust under all such copyrights and other rights in the Contribution:
+
+   a. to copy, publish, display, and distribute the Contribution, in
+      whole or in part,
+
+   b. to prepare translations of the Contribution into languages other
+      than English, in whole or in part, and to copy, publish, display,
+      and distribute such translations or portions thereof,
+
+   c. to modify or prepare derivative works (in addition to
+      translations) that are based on or incorporate all or part of the
+      Contribution, and to copy, publish, display, and distribute such
+      derivative works, or portions thereof unless explicitly disallowed
+      in the notices contained in a Contribution (in the form specified
+      by the Legend Instructions), and
+
+
+
+
+
+Bradner & Contreras      Best Current Practice                 [Page 10]
+
+RFC 5378                   RFC 3978-incoming               November 2008
+
+
+   d. to reproduce any trademarks, service marks, or trade names which
+      are included in the Contribution solely in connection with the
+      reproduction, distribution, or publication of the Contribution and
+      derivative works thereof as permitted by this Section 5.3,
+      provided that when reproducing Contributions, trademark and
+      service mark identifiers used in the Contribution, including TM
+      and (R), will be preserved.
+
+5.4.  Sublicenses by the IETF Trust
+
+   The IETF Trust will sublicense the rights granted to it under Section
+   5.3 to all IETF participants for use within the IETF Standards
+   Process.  This license is expressly granted under a license agreement
+   issued by the IETF Trust, which can be found at
+   http://trustee.ietf.org/license-info.
+
+   This license is expressly granted under a license agreement issued by
+   the IETF Trust and must contain a pointer to the full IETF Trust
+   agreement.
+
+   In addition, the IETF Trust may grant additional sublicenses of the
+   licenses granted to it hereunder.  In doing so, the IETF Trust will
+   comply with the guidance provided under RFC 5377 [RFC5377].
+
+5.5.  No Patent License
+
+   The licenses granted in Section 5.3 shall not be deemed to grant any
+   right under any patent, patent application, or other similar
+   intellectual property right disclosed by the Contributor under BCP 79
+   [RFC3979] or otherwise.
+
+5.6.  Representations and Warranties
+
+   With respect to each Contribution, each Contributor represents that,
+   to the best of his or her knowledge and ability:
+
+   a. The Contribution properly acknowledges all Contributors, including
+      Indirect Contributors.
+
+   b. No information in the Contribution is confidential, and the IETF,
+      IETF Trust, ISOC, and its affiliated organizations may freely
+      disclose any information in the Contribution.
+
+   c. There are no limits to the Contributor's ability to make the
+      grants, acknowledgments, and agreements herein that are reasonably
+      and personally known to the Contributor.
+
+
+
+
+
+Bradner & Contreras      Best Current Practice                 [Page 11]
+
+RFC 5378                   RFC 3978-incoming               November 2008
+
+
+   d. The Contributor has not intentionally included in the Contribution
+      any material that is defamatory or untrue or which is illegal
+      under the laws of the jurisdiction in which the Contributor has
+      his or her principal place of business or residence.
+
+   e. All trademarks, trade names, service marks, and other proprietary
+      names used in the Contribution that are reasonably and personally
+      known to the Contributor are clearly designated as such where
+      reasonable.
+
+5.7.  No Duty to Publish
+
+   The Contributor, and each named co-Contributor, acknowledges that the
+   IETF has no duty to publish or otherwise use or disseminate any
+   Contribution.  The IETF reserves the right to withdraw or cease using
+   any Contribution that does not comply with the requirements of this
+   Section 5.
+
+5.8.  Trademarks
+
+   Contributors who claim trademark rights in terms used in their IETF
+   Contributions are requested to state specifically what conditions
+   apply to implementers of the technology relative to the use of such
+   trademarks.  Such statements should be submitted in the same way as
+   is done for other intellectual property claims.  (See [RFC3979]
+   Section 6.)
+
+5.9.  Copyright in RFCs
+
+   Subject to each Contributor's (or its sponsor's) ownership of its
+   underlying Contributions as described in Section 5.6 (which ownership
+   is qualified by the irrevocable licenses granted under Section 5.3),
+   each Contributor hereby acknowledges that the copyright in any RFC in
+   which such Contribution is included, other than an RFC that is an RFC
+   Editor Contribution, shall be owned by the IETF Trust.  Such
+   Contributor shall be deemed to assign to the IETF Trust such
+   Contributor's copyright interest in the collective work constituting
+
+   such RFC upon the submission of such RFC for publication, and
+   acknowledges that a copyright notice acknowledging the IETF Trust's
+   ownership of the copyright in such RFC will be included in the
+   published RFC.
+
+5.10.  Contributors' Retention of Rights
+
+   Although Contributors provide specific rights to the IETF, it is not
+   intended that this should deprive them of their right to exploit
+   their Contributions.  To underscore this principle, the IETF Trust is
+
+
+
+Bradner & Contreras      Best Current Practice                 [Page 12]
+
+RFC 5378                   RFC 3978-incoming               November 2008
+
+
+   directed to issue a license or assurance to Contributors, which
+   confirms that they may each make use of their Contributions as
+   published in an RFC in any way they wish, subject only to the
+   restriction that no Contributor has the right to represent any
+   document as an RFC, or equivalent of an RFC, if it is not a full and
+   complete copy or translation of the published RFC.
+
+6.  Legends, Notices and Other Standardized Text in IETF Documents
+
+   The IETF requires that certain standardized text be reproduced
+   verbatim in certain IETF Documents (including copies, derivative
+   works, and translations of IETF Documents).  Some of this
+   standardized text may be mandatory (e.g., copyright notices and
+   disclaimers that must be included in all RFCs) and some may be
+   optional (e.g., limitations on the right to make derivative works).
+   The text itself, as well as the rules that explain when and how it
+   must be used, is contained in the Legend Instructions.  The Legend
+   Instructions may be updated from time to time, and the version of the
+   standardized text that must be included in IETF Documents is that
+   which was posted in the Legend Instructions on the date of
+   publication.
+
+   The IETF reserves the right to refuse to publish Contributions that
+   do not include the legends and notices required by the Legend
+   Instructions.
+
+   It is important to note that each Contributor grants the IETF Trust
+   rights pursuant to this document and the policies described herein.
+   The legends and notices included in certain written Contributions
+   such as Internet-Drafts do not themselves convey any rights.  They
+   are simply included to inform the reader (whether or not part of the
+   IETF) about certain legal rights and limitations associated with such
+   documents.
+
+   It is also important to note that additional copyright notices are
+   not permitted in IETF Documents except in the case where such
+   document is the product of a joint development effort between the
+   IETF and another standards development organization or is a
+   republication of the work of another standards development
+   organization.  Such exceptions must be approved on an individual
+   basis by the IAB.
+
+7.  Security Considerations
+
+   This memo relates to the IETF process, not any particular technology.
+   There are security considerations when adopting any technology, but
+   there are no known issues of security with IETF Contribution rights
+   policies.
+
+
+
+Bradner & Contreras      Best Current Practice                 [Page 13]
+
+RFC 5378                   RFC 3978-incoming               November 2008
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+             3", BCP 9, RFC 2026, October 1996.
+
+   [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in
+             the IETF Standards Process", BCP 11, RFC 2028, October
+             1996.
+
+   [RFC3979] Bradner, S., Ed., "Intellectual Property Rights in IETF
+             Technology", BCP 79, RFC 3979, March 2005.
+
+   [RFC4371] Carpenter, B., Ed., and L. Lynch, Ed., "BCP 101 Update for
+             IPR Trust", BCP 101, RFC 4371, January 2006.
+
+8.2.  Informative References
+
+   [RFC3978] Bradner, S., Ed., "IETF Rights in Contributions", BCP 78,
+             RFC 3978, March 2005.
+
+   [RFC4748] Bradner, S., Ed., "RFC 3978 Update to Recognize the IETF
+             Trust", BCP 78, RFC 4748, October 2006.
+
+   [RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFC
+             Series and RFC Editor", RFC 4844, July 2007.
+
+   [RFC5377] Halpern, J., Ed., "Advice to the Trustees of the IETF Trust
+             on Rights to be Granted in IETF Documents", RFC 5377,
+             November 2008.
+
+   [Berne]   "Berne Convention for the Protection of Literary and
+             Artistic Work", http://www.wipo.int/treaties/en/ip/berne/
+             trtdocs_wo001.html.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner & Contreras      Best Current Practice                 [Page 14]
+
+RFC 5378                   RFC 3978-incoming               November 2008
+
+
+9.  Acknowledgments
+
+   The editors would like to acknowledge the help the IETF IPR Working
+   Group provided during the development of the document.
+
+10.  Changes since RFC 3978
+
+   This document represents a significant reorganization and rewording
+   of RFC 3978, along with a number of substantive changes.
+
+   The most basic change is to limit this document to the rights that a
+   Contributor grants to the IETF Trust when making a Contribution.  All
+   sublicenses of rights for the use of IETF Documents must be provided
+   by the IETF Trust.  (See Section 5.4.)
+
+   Material added from RFC 4748 that recognized the IETF Trust.
+
+   Most of the material relating to RFC Editor documents has been
+   removed since the RFC Editor maintains their own rules and processes
+   for RFC Editor documents.  Renamed these documents to "non-IETF
+   documents".  Added section 11 from the IAB discussing this topic.
+
+   Changes in the definitions section include defining the terms
+   "Contribution", "Indirect Contributor", "Copyright", "IETF Trust",
+   and "Legend Instructions", as well as minor tweaks to some of the
+   other definitions.
+
+   The responsibility for the text of notices has been given to the IETF
+   Trust and removed from this document.  (See Section 6.)
+
+   Clarified that Contributors enter into a legally binding contract
+   when they submit a Contribution.  (See Section 5.1.)
+
+   The right to produce derivative works provided by the Contributor to
+   the IETF Trust is not limited to being within the IETF Standards
+   Process.
+
+   Made it clear that this document does not deal with patent licenses.
+   (See Section 5.5.)
+
+   Clarified the ownership of the Copyrights to IETF Documents.  (See
+   Section 5.9.)
+
+   Clarified the rights retained by authors of IETF Contributions.  (See
+   Section 5.10.)
+
+
+
+
+
+
+Bradner & Contreras      Best Current Practice                 [Page 15]
+
+RFC 5378                   RFC 3978-incoming               November 2008
+
+
+11.  Declaration from the IAB
+
+   The IAB discussed the IPR documents during its most recent call.  It
+   unanimously decided that the IAB stream is to be covered by the
+   incoming IPR document.  It is our understanding that IAB stream
+   documents' IPR are then automatically covered by the outbound rights
+   that the IETF Trust will establish based on the advice in [RFC5377].
+
+   We also want to stress that, for any change in the inbound rights for
+   streams other than the IETF and IAB streams, there needs to be a
+   stream-dependent discussion and approval process, as indicated in RFC
+   4844, "The RFC Series and RFC Editor" [RFC4844], section 4.2.3.
+
+   To that extent, section 4 of the document should explicitly mention
+   that the IRTF, the Independent, and any possible future streams are
+   not covered by the document.
+
+   For the IAB,
+
+   Olaf Kolkman
+   April 4, 2008
+
+Editors' Addresses
+
+   Scott Bradner
+   Harvard University
+   29 Oxford St.
+   Cambridge MA, 02138 USA
+
+   Phone: +1 617 495 3864
+   EMail: sob@harvard.edu
+
+
+   Jorge L. Contreras
+   WilmerHale
+   1875 Pennsylvania Avenue NW
+   Washington, DC 20006 USA
+
+   Phone: +1 202 663 6872
+   EMail: jorge.contreras@wilmerhale.com
+
+
+
+
+
+
+
+
+
+
+
+Bradner & Contreras      Best Current Practice                 [Page 16]
+