doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc3667.txt b/doc/rfc/rfc3667.txt
new file mode 100644
index 0000000..65d660c
--- /dev/null
+++ b/doc/rfc/rfc3667.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                         S. Bradner
+Request for Comments: 3667                            Harvard University
+BCP: 78                                                    February 2004
+Updates: 2026
+Category: Best Current Practice
+
+
+                      IETF Rights in Contributions
+
+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) The Internet Society (2004).  All Rights Reserved.
+
+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
+   updates RFC 2026, and, with RFC 3668, replaces Section 10 of RFC
+   2026.
+
+Table of Contents
+
+   1.  Definitions. . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  Rights in IETF Contributions . . . . . . . . . . . . . . . . .  5
+       3.1.  General Policy . . . . . . . . . . . . . . . . . . . . .  5
+       3.2.  Confidentiality Obligations. . . . . . . . . . . . . . .  5
+       3.3.  Granting of Rights and Permissions . . . . . . . . . . .  6
+       3.4.  Representations and Warranties . . . . . . . . . . . . .  7
+       3.5.  No Duty to Publish . . . . . . . . . . . . . . . . . . .  7
+       3.6.  Trademarks . . . . . . . . . . . . . . . . . . . . . . .  7
+   4.  Rights in RFC Editor Contributions . . . . . . . . . . . . . .  8
+       4.1.  Requirements from Section 3. . . . . . . . . . . . . . .  8
+       4.2.  Granting of Rights and Permissions . . . . . . . . . . .  8
+   5.  Notices Required in IETF Documents . . . . . . . . . . . . . .  9
+       5.1.  IPR Disclosure Acknowledgement . . . . . . . . . . . . . 10
+       5.2.  Derivative Works Limitation. . . . . . . . . . . . . . . 10
+       5.3.  Publication Limitation . . . . . . . . . . . . . . . . . 11
+
+
+
+Bradner                  Best Current Practice                  [Page 1]
+
+RFC 3667               IETF Rights in Submissions          February 2004
+
+
+       5.4.  Copyright Notice . . . . . . . . . . . . . . . . . . . . 11
+       5.5.  Disclaimer . . . . . . . . . . . . . . . . . . . . . . . 11
+       5.6.  Exceptions . . . . . . . . . . . . . . . . . . . . . . . 12
+   6.  Notices and Rights Required in RFC Editor Contributions. . . . 13
+   7.  Exposition of why these procedures are the way they are. . . . 13
+       7.1.  Rights Granted in IETF Contributions . . . . . . . . . . 13
+       7.2.  Rights to use Contributed Material . . . . . . . . . . . 14
+       7.3.  Right to Produce Derivative Works. . . . . . . . . . . . 14
+       7.4.  Rights to use Trademarks . . . . . . . . . . . . . . . . 16
+       7.5.  Who Does This Apply To?. . . . . . . . . . . . . . . . . 16
+   8.  Contributions Not Subject to Copyright . . . . . . . . . . . . 16
+   9.  Security Considerations. . . . . . . . . . . . . . . . . . . . 16
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+       10.1. Normative References . . . . . . . . . . . . . . . . . . 17
+       10.2. Informative References . . . . . . . . . . . . . . . . . 17
+   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
+   12. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 17
+   13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
+
+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 [RFC 2028].
+
+   a. "IETF":  In the context of this document, the IETF includes all
+      individuals who participate in meetings, working groups, mailing
+      lists, functions and other activities which are organized or
+      initiated by ISOC, the IESG or the IAB under the general
+      designation of the Internet Engineering Task Force or IETF, but
+      solely to the extent of such participation.
+
+   b. "IETF Standards Process": the activities undertaken by the IETF in
+      any of the settings described in 1(c) below.
+
+   c. "IETF 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 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,
+      which are addressed to:
+
+      o  the IETF plenary session,
+      o  any IETF working group or portion thereof,
+      o  the IESG, or any member thereof on behalf of the IESG,
+      o  the IAB or any member thereof on behalf of the IAB,
+
+
+
+
+Bradner                  Best Current Practice                  [Page 2]
+
+RFC 3667               IETF Rights in Submissions          February 2004
+
+
+      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 described 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.
+
+   d. "Internet-Draft": temporary documents used in the IETF and RFC
+      Editor processes.  Internet-Drafts are posted on the IETF web site
+      by the IETF Secretariat and have a nominal maximum lifetime in the
+      Secretariat's public directory of 6 months, after which they are
+      removed.  Note that Internet-Drafts are archived many places on
+      the Internet, and not all of these places remove expired
+      Internet-Drafts.  Internet-Drafts that are under active
+      consideration by the IESG are not removed from the Secretariat's
+      public directory until that consideration is complete.  In
+      addition, the author of an Internet-Draft can request that the
+      lifetime in the Secretariat's public directory be extended before
+      the expiration.
+
+   e. "RFC": the basic publication series for the IETF.  RFCs are
+      published by the RFC Editor and once published are never modified.
+      (See [RFC 2026] Section 2.1)
+
+   f. "RFC Editor Contribution": An Internet-Draft intended by the
+      Contributor to be submitted to the RFC Editor for publication as
+      an Informational or Experimental RFC but not intended to be part
+      of the IETF Standards Process.
+
+   g. "IETF Internet-Drafts": Internet-Drafts other than RFC Editor
+      Contributions.  Note that under Section 3.3(a) the grant of rights
+      in regards to IETF Internet-Drafts as specified in this document
+      is perpetual and irrevocable and thus survives the Secretariat's
+      removal of an Internet-Draft from the public directory, except as
+      limited by Section 3.3(a)(C).  (See [RFC 2026] Sections 2.2 and 8)
+
+   h. "IETF Documents":  RFCs and Internet-Drafts except for Internet-
+      Drafts that are RFC Editor Contributions and the RFCs that are
+      published from them.
+
+   i. "RFC Editor Documents":  RFCs and Internet-Drafts that are RFC
+      Editor Contributions and the RFCs that may be published from them.
+
+   j. "Contribution": IETF Contributions and RFC Editor Contributions.
+
+
+
+Bradner                  Best Current Practice                  [Page 3]
+
+RFC 3667               IETF Rights in Submissions          February 2004
+
+
+   k. "Contributor": an individual submitting a Contribution.
+
+   l. "Reasonably and personally known": means 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 patents or patent applications just to avoid the
+      disclosure requirement. But this requirement should not be
+      interpreted as requiring the IETF Contributor or participant (or
+      his or her represented organization, if any) to perform a patent
+      search to find applicable IPR.
+
+2. Introduction
+
+   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.)
+
+   This document details the rights that the IETF requires in IETF
+   Contributions and rights the IETF, as publisher of Internet-Drafts,
+   requires in all such Drafts including RFC Editor Contributions.  The
+   RFC Editor may also define additional rights required for RFC Editor
+   Contributions.
+
+   In order for works to be used within the IETF Standards Process or to
+   be published as Internet-Drafts, certain limited rights in all
+   Contributions must be granted to the IETF and Internet Society
+   (ISOC). In addition, Contributors must make representations to IETF
+   and ISOC regarding their ability to grant these rights.  These
+   necessary rights and representations have until now been laid out in
+   Section 10 of [RFC 2026].  In the years since [RFC 2026] was
+   published there have been a number of times when the exact intent of
+   Section 10 has been the subject of vigorous debate within the IETF
+   community.  The aim of this document is to clarify various
+   ambiguities in Section 10 of [RFC 2026] that led to these debates and
+   to amplify the policy in order to clarify what the IETF is currently
+   doing.
+
+   Section 1 gives definitions used in describing these policies.
+   Sections 3, 4, 5 and 6 of this document address the rights in
+   Contributions previously covered by Section 10 of [RFC 2026] and the
+
+
+
+Bradner                  Best Current Practice                  [Page 4]
+
+RFC 3667               IETF Rights in Submissions          February 2004
+
+
+   "Note Well" explanatory text presented at many IETF activities.
+   Sections 7 and 8 then explain the rationale for these provisions,
+   including some of the clarifications that have become understood
+   since the adoption of [RFC 2026].  The rules and procedures set out
+   in this document are not intended to substantially modify or alter
+   the IETF's current policy toward Contributions.
+
+   A companion document [RFC 3668] deals with rights in technologies
+   developed or specified as part of the IETF Standards Process.  This
+   document is not intended to address those issues.
+
+   The rights addressed in this document fall into the following
+   categories:
+
+   o  rights to make use of contributed material
+   o  copyrights in IETF documents
+   o  rights to produce derivative works
+   o  rights to use trademarks
+
+   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 in any
+   Contributions they make.
+
+3. Rights in IETF Contributions
+
+   The following are the rights the IETF requires in all IETF
+   Contributions:
+
+3.1.  General Policy
+
+   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.
+
+3.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.
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 5]
+
+RFC 3667               IETF Rights in Submissions          February 2004
+
+
+3.3.  Granting of Rights and Permissions
+
+   By submission of a Contribution, each person actually submitting the
+   Contribution, and each named co-Contributor, is deemed to agree to
+   the following terms and conditions, and to grant the following
+   rights, on his or her own behalf and on behalf of the organization
+   the Contributor represents or is sponsored by (if any) when
+   submitting the Contribution.
+
+   a. To the extent that a Contribution or any portion thereof is
+      protected by copyright and other rights of authorship, the
+      Contributor, and each named co-Contributor, and the organization
+      he or she represents or is sponsored by (if any) grant a
+      perpetual, irrevocable, non-exclusive, royalty-free, world-wide
+      right and license to the ISOC and the IETF under all intellectual
+      property rights in the Contribution:
+
+      (A)  to copy, publish, display and distribute the Contribution as
+           part of the IETF Standards Process or in an Internet-Draft,
+
+      (B)  to prepare or allow the preparation of translations of the
+           Contribution into languages other than English,
+
+      (C)  unless explicitly disallowed in the notices contained in a
+           Contribution [as per Section 5.2 below], to prepare
+           derivative works (other than translations) that are based on
+           or incorporate all or part of the Contribution, or comment
+           upon it, within the IETF Standards Process.  The license to
+           such derivative works not granting the ISOC and the IETF any
+           more rights than the license to the original Contribution,
+
+      (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 paragraph.  When reproducing Contributions, the IETF
+           will preserve trademark and service mark identifiers used by
+           the Contributor of the Contribution, including (TM) and (R)
+           where appropriate, and
+
+      (E)  to extract, copy, publish, display, distribute, modify and
+           incorporate into other works, for any purpose (and not
+           limited to use within the IETF Standards Process) any
+           executable code or code fragments that are included in any
+           IETF Document (such as MIB and PIB modules), subject to the
+           requirements of Section 5 (it also being understood that the
+           licenses granted under this paragraph (E) shall not be deemed
+           to grant any right under any patent, patent application or
+
+
+
+Bradner                  Best Current Practice                  [Page 6]
+
+RFC 3667               IETF Rights in Submissions          February 2004
+
+
+           other similar intellectual property right disclosed by the
+           Contributor under [IETF IPR]).
+
+   b. The Contributor grants the IETF and ISOC permission to reference
+      the name(s) and address(es) of the Contributor(s) and of the
+      organization(s) s/he represents or is sponsored by (if any).
+
+3.4.  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 major Contributors.  A
+      major Contributor is any person who has materially or
+      substantially contributed to the IETF Contribution.
+
+   b. No information in the Contribution is confidential and the IETF,
+      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.
+
+   d. The Contributor has not intentionally included in the Contribution
+      any material which 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.
+
+3.5.  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
+   Section 3.4 and Section 3.3 or 4.2.
+
+3.6.  Trademarks
+
+   Contributors, and each named co-Contributor, who claim trademark
+   rights in terms used in their IETF Contributions are requested to
+   state specifically what conditions apply to implementers of
+
+
+
+
+Bradner                  Best Current Practice                  [Page 7]
+
+RFC 3667               IETF Rights in Submissions          February 2004
+
+
+   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 [RFC 3668] Section 6.)
+
+4. Rights in RFC Editor Contributions
+
+   The following are the rights the IETF, as the publisher of Internet-
+   Drafts, requires in all RFC Editor Contributions:
+
+4.1.  Requirements from Section 3
+
+   All RFC Editor Contributions must meet the requirements of Sections
+   3.1, 3.2, 3.4, 3.5 and 3.6.
+
+4.2.  Granting of Rights and Permissions
+
+   By submission of an RFC Editor Contribution, each person actually
+   submitting the RFC Editor Contribution, and each named co-
+   Contributor, is deemed to agree to the following terms and
+   conditions, and to grant the following rights, on his or her own
+   behalf and on behalf of the organization the Contributor represents
+   or is sponsored by (if any) when submitting the RFC Editor
+   Contribution.
+
+   a. To the extent that an RFC Editor Contribution or any portion
+      thereof is protected by copyright and other rights of authorship,
+      the Contributor, and each named co-Contributor, and the
+      organization he or she represents or is sponsored by (if any)
+      grant a perpetual, irrevocable, non-exclusive, royalty-free,
+      world-wide right and license to the ISOC and the IETF under all
+      intellectual property rights in the RFC Editor Contribution for at
+      least the life of the Internet-Draft:
+
+      (A) to copy, publish, display and distribute the RFC Editor
+          Contribution as an RFC, and
+
+      (B) to prepare or allow the preparation of translations of the RFC
+          into languages other than English.
+
+      (C) unless explicitly disallowed in the notices contained in an
+          RFC Editor Contribution (as per Section 5.2 below), to prepare
+          derivative works (other than translations) that are based on
+          or incorporate all or part of the RFC Editor Contribution, or
+          comment upon it.  The license to such derivative works not
+          granting the ISOC and the IETF any more rights than the
+          license to the original RFC Editor Contribution, and
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 8]
+
+RFC 3667               IETF Rights in Submissions          February 2004
+
+
+      (D) to reproduce any trademarks, service marks or trade names
+          which are included in the RFC Editor Contribution solely in
+          connection with the reproduction, distribution or publication
+          of the RFC Editor Contribution and derivative works thereof as
+          permitted by this paragraph.  When reproducing RFC Editor
+          Contributions, the IETF will preserve trademark and service
+          mark identifiers used by the Contributor of the RFC Editor
+          Contribution, including (TM) and (R) where appropriate.
+
+   b. The Contributor grants the IETF and ISOC permission to reference
+      the name(s) and address(es) of the Contributor(s) and of the
+      organization(s) s/he represents or is sponsored by (if any).
+
+5.  Notices Required in IETF Documents
+
+   The IETF requires that certain notices and disclaimers described in
+   this Section 5 be reproduced verbatim in all IETF Documents
+   (including copies, derivative works and translations of IETF
+   Documents, but subject to the limited exceptions noted in Section
+   5.2).  This requirement protects IETF and its participants from
+   liabilities connected with these documents.  The copyright notice
+   also alerts readers that the document is an IETF Document, and that
+   ISOC claims copyright rights to certain aspects of the document, such
+   as its layout, the RFC numbering convention and the prefatory
+   language of the document.  This legend is not intended to imply that
+   ISOC has obtained ownership of the IETF Contribution itself, which is
+   retained by the author(s) or remains in the public domain, as
+   applicable.
+
+   Each IETF Document must include the required notices described in
+   this Section 5.  The required notices are the following:
+
+   a. The IPR Disclosure Acknowledgement described in Section 5.1
+      (required in all Internet-Drafts).
+   b. The Derivative Works Limitation described in Section 5.2 (for
+      specific IETF Documents only).
+   c. The Publication Limitation described in Section 5.3 (for specific
+      types of Internet-Drafts only).
+   d. The Copyright Notice described in Section 5.4 (for all IETF
+      Documents).
+   e. The Disclaimer described in Section 5.5 (for all IETF Documents).
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 9]
+
+RFC 3667               IETF Rights in Submissions          February 2004
+
+
+5.1.  IPR Disclosure Acknowledgement (required in all Internet-Drafts
+      only)
+
+   "By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668."
+
+5.2.  Derivative Works Limitation
+
+   If the Contributor desires to eliminate the IETF's right to make
+   modifications and derivative works of an IETF Contribution (other
+   than translations), one of the two of the following notices may be
+   included in the Status of Memo section of an Internet-Draft and
+   included in a published RFC:
+
+   a. "This document may not be modified, and derivative works of it may
+      not be created, except to publish it as an RFC and to translate it
+      into languages other than English."
+
+   b. "This document may not be modified, and derivative works of it may
+      not be created."
+
+   In the cases of MIB or PIB modules and in other cases where the
+   Contribution includes material that is meant to be extracted in order
+   to be used, the following should be appended to statement 5.2 (a) or
+   5.2 (b):
+
+      "other than to extract section XX as-is for separate use."
+
+   Notice 5.2(a) is used if the Contributor intends for the IETF
+   Contribution to be published as an RFC.  Notice 5.2(b) is used along
+   with the Publication Limitation in Section 5.3 when the Contributor
+   does not intend for the IETF Contribution to be published as an RFC.
+
+   These notices may not be used with any standards-track document or
+   with most working group documents, except as discussed in Section 7.3
+   below, since the IETF must retain change control over its documents
+   and the ability to augment, clarify and enhance the original IETF
+   Contribution in accordance with the IETF Standards Process.
+
+   Notice 5.2(a) may be appropriate when republishing standards produced
+   by other (non-IETF) standards organizations, industry consortia or
+   companies.  These are typically published as Informational RFCs, and
+   do not require that change control be ceded to the IETF.  Basically,
+   documents of this type convey information for the Internet community.
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 10]
+
+RFC 3667               IETF Rights in Submissions          February 2004
+
+
+   A fuller discussion of the rationale behind these requirements is
+   contained in Section 7.3 below.
+
+5.3.  Publication Limitation
+
+   If the Contributor only wants the IETF Contribution to be made
+   available in an Internet-Draft (i.e., does not want the IETF
+   Contribution to be published as an RFC) then the Contributor may
+   include the following notice in the Status of Memo section of the
+   Internet-Draft.
+
+      "This document may only be posted in an Internet-Draft."
+
+   This notice can be used on IETF Contributions that are intended to
+   provide background information to educate and to facilitate
+   discussions within IETF working groups but are not intended to be
+   published as an RFCs.
+
+5.4.  Copyright Notice (required for all IETF Documents)
+
+   (Normally placed at the end of the IETF Document.)
+
+      "Copyright (C) The Internet Society (year).  This document is
+      subject to the rights, licenses and restrictions contained in BCP
+      78, and except as set forth therein, the authors retain all their
+      rights."
+
+   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 the document is a republication of the work of
+   another standards organization.  Such exceptions must be approved on
+   an individual basis by the IAB.
+
+5.5.  Disclaimer (required in all IETF Documents)
+
+   (Normally placed at the end of the IETF Document after the copyright
+   notice.)
+
+      "This document and the information contained herein are provided
+      on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
+      THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
+      EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
+      THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
+      ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
+      PARTICULAR PURPOSE."
+
+
+
+
+Bradner                  Best Current Practice                 [Page 11]
+
+RFC 3667               IETF Rights in Submissions          February 2004
+
+
+5.6 Exceptions
+
+   Notwithstanding the provisions of this Section 5, in certain limited
+   cases an abbreviated notice may be placed on certain types of
+   derivative works of IETF Documents in accordance with this Section
+   5.6.
+
+   a. in MIB modules, PIB modules and similar material commonly
+      extracted from IETF Documents, except for material that is being
+      placed under IANA maintenance, the following abbreviated notice
+      shall be included in the body of the material that will be
+      extracted in lieu of the notices otherwise required by Section 5:
+
+         "Copyright (C) The Internet Society <year> .  This version of
+         this MIB module is part of RFC XXXX; see the RFC itself for
+         full legal notices."
+
+      When the MIB or PIB module is the initial version of a module that
+      is to be maintained by the IANA, the following abbreviated notice
+      shall be included:
+
+         "Copyright (C) The Internet Society <year>.  The initial
+         version of this MIB module was published in RFC XXXX; for full
+         legal notices see the RFC itself.  Supplementary information
+         may be available on
+         http://www.ietf.org/copyrights/ianamib.html."
+
+      For other types of components than "MIB", substitute "MIB module"
+      with an appropriate identifier.  In the case of MIB and PIB
+      modules this statement should be placed in the DESCRIPTION clause
+      of the MODULE-IDENTITY macro.
+
+      Variations of these abbreviated notices are not permitted except
+      in cases where the material to be extracted 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 organization.  Such variations must be approved
+      on an individual basis by the IAB.
+
+   b. short excerpts of IETF Documents presented in electronic help
+      systems, for example, the DESCRIPTION clauses for MIB variables,
+      do not need to include a copyright notice.
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 12]
+
+RFC 3667               IETF Rights in Submissions          February 2004
+
+
+6.  Notices and Rights Required in RFC Editor Contributions
+
+   Since the IETF acts as publisher of Internet Drafts, even for
+   Internet Drafts that are not intended to become part of the Standards
+   Process, the following are required in all such drafts to protect the
+   IETF and its processes.  The RFC Editor may require additional
+   notices.
+
+   a. An IPR Disclosure Acknowledgement, identical to that specified in
+      Section 5.1.
+
+   b. One of the following two copyright release statements:
+
+      A. "By submitting this Internet-Draft, I accept the provisions of
+         Section 3 of RFC 3667."
+
+      B. "By submitting this Internet-Draft, I accept the provisions of
+         Section 4 of RFC 3667."
+
+7.  Exposition of Why These Procedures Are the Way They Are
+
+7.1.  Rights Granted in IETF Contributions
+
+   The IETF/ISOC 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 the IETF Contributions in the IETF
+   Standards Process while leaving all other rights with the authors.
+
+   The non-exclusive rights that the IETF needs are:
+
+   a. the right to publish the document
+   b. the right to let the document be freely reproduced in the formats
+      that the IETF publishes it in
+   c. the right to let third parties translate it into languages other
+      than English
+   d. except where explicitly excluded (see Section 5.2), the right to
+      make derivative works within the IETF process.
+   e. the right to let third parties extract some logical parts, for
+      example MIB modules
+
+   The authors retain all other rights, but cannot withdraw the above
+   rights from the IETF/ISOC.
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 13]
+
+RFC 3667               IETF Rights in Submissions          February 2004
+
+
+7.2.  Rights to use Contributed Material
+
+   Because, under the laws of most countries and applicable
+   international treaties, copyright rights come into existence whenever
+   a work of authorship is created (but see Section 8 below regarding
+   public domain documents), and IETF cannot make use of IETF
+   Contributions if it does not have sufficient rights with respect to
+   these copyright rights, 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.  Without this
+   assurance, IETF and its participants would run a greater risk of
+   liability to the owners of these rights.
+
+   To this end, IETF asks Contributors to give the assurances in Section
+   3.4 above.  These assurances are requested, however, only to the
+   extent of the Contributor's reasonable and personal knowledge.  (See
+   Section 1(l))
+
+7.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
+   react to changing conditions on the Internet and other IP networks.
+   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 though that the IETF only requires
+   this right for the production of derivative works within the IETF
+   Standards Process.  The IETF does not need, nor does it obtain, the
+   right to let derivative works be created outside of the IETF
+   Standards Process other than as noted in Section 3.3 (E).
+
+   The right to produce derivative works 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 an IETF Contribution as a working group
+   document or otherwise work on it.  For non-working group IETF
+   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 IETF Contributions, before the
+   IESG will consider the Internet-Draft for publication.
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 14]
+
+RFC 3667               IETF Rights in Submissions          February 2004
+
+
+   Occasionally a Contributor may not want to grant publication rights
+   or the right to produce derivative works before finding out if an
+   IETF Contribution has been accepted for development in the IETF
+   Standards Process.  In these cases the Contributor may include the
+   Derivative Works Limitation described in Section 5.2 and the
+   Publication Limitation described in Section 5.3 in their IETF
+   Contribution.  A working group can discuss the Internet-Draft 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 IETF
+   Contribution as an RFC has not yet been granted.  If the IETF
+   Contribution is accepted for development the Contributor must then
+   resubmit the IETF Contribution without the limitation notices before
+   a working group can formally adopt the IETF Contribution as a working
+   group document.
+
+   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 claim
+   that the IETF version is the "new version" of the organization's
+   technology. Organizations that feel this way can specify that an IETF
+   Contribution can be published with the other rights granted under
+   this document but may withhold the right to produce derivative works
+   other than translations.  The right to produce translations is
+   required before any IETF Contribution can be published as an RFC to
+   ensure the widest possible distribution of the material in RFCs.
+
+   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 IETF Contribution, as specified in Section 5.2, in order to
+   notify IETF participants about this restriction.
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 15]
+
+RFC 3667               IETF Rights in Submissions          February 2004
+
+
+7.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 IETF Contributions.  IETF
+   makes no judgment about the validity of any such trademark rights.
+   However, the IETF requires each Contributor, under the licenses
+   described in Section 3.3 above, to grant IETF a perpetual license to
+   use any such trademarks or service marks solely in exercising its
+   rights to reproduce, publish and modify the IETF Contribution.  This
+   license does not authorize any IETF participant to use any trademark
+   or service mark in connection with any product or service offering,
+   but only in the context of IETF Documents and discussions.
+
+7.5.  Who Does This Apply To?
+
+   Rights and licenses granted to the IETF under this document are
+   granted to all individuals noted in Section 1(a), irrespective of
+   their employment or institutional affiliation.  However, these
+   licenses do not extend broadly to the employers, sponsors or
+   institutions of such individuals, nor do they authorize the
+   individuals to exercise any rights outside the specific context of
+   the IETF Standards Process.
+
+8.  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 as 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, the IETF Standards Process and all IETF participants, and
+   also 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.
+
+9. Security Considerations
+
+   This memo relates to 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                  Best Current Practice                 [Page 16]
+
+RFC 3667               IETF Rights in Submissions          February 2004
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC 2026]   Bradner, S., Ed, "The Internet Standards Process --
+                Revision 3", BCP 9, RFC 2026, October 1996.
+
+   [RFC 3668]   Bradner, S., Ed., "Intellectual Property Rights in IETF
+                Technology", BCP 79, RFC 3668, February 2004.
+
+10.2.  Informative References
+
+   [Berne]      "Berne Convention for the Protection of Literary and
+                Artistic Work",
+                http://www.wipo.int/treaties/ip/berne/index.html
+
+11.  Acknowledgements
+
+   The editor would like to acknowledge the help of the IETF IPR Working
+   Group and, in particular the help of Jorge Contreras of Hale and Dorr
+   for his careful legal reviews of this and other IETF IPR-related and
+   process documents.  The editor would also like to acknowledge the
+   extensive help John Klensin provided during the development of the
+   document.
+
+12.  Editor's Address
+
+   Scott Bradner
+   Harvard University
+   29 Oxford St.
+   Cambridge MA, 02138
+
+   Phone: +1 617 495 3864
+   EMail: sob@harvard.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 17]
+
+RFC 3667               IETF Rights in Submissions          February 2004
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78 and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed
+   to pertain to the implementation or use of the technology
+   described in this document or the extent to which any license
+   under such rights might or might not be available; nor does it
+   represent that it has made any independent effort to identify any
+   such rights.  Information on the procedures with respect to
+   rights in RFC documents can be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use
+   of such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository
+   at http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention
+   any copyrights, patents or patent applications, or other
+   proprietary rights that may cover technology that may be required
+   to implement this standard.  Please address the information to the
+   IETF at ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 18]
+