draft-ietf-ipr-3978-incoming-00.txt   draft-ietf-ipr-3978-incoming-01.txt 
Network Working Group S. Bradner Network Working Group S. Bradner
Internet-Draft Harvard University Internet-Draft Harvard University
Jorge Contreras Jorge Contreras
WilmerHale WilmerHale
Editors Editors
February 2007 Rights Contributors provide to the IETF Trust
Rights Contributions provide to the IETF Trust
<draft-ietf-ipr-3978-incoming-00.txt> <draft-ietf-ipr-3978-incoming-01.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
skipping to change at page 1, line 36 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 26, 2007. This Internet-Draft will expire on December 26, 2007.
Copyright Notice Copyright (C) IETF Trust (2007).
Copyright (C) The IETF Trust (2007).
Abstract Abstract
The IETF policies about rights in Contributions to the IETF are The IETF policies about rights in Contributions to the IETF are
designed to ensure that such Contributions can be made available to designed to ensure that such Contributions can be made available to
the IETF and Internet communities while permitting the authors to the IETF and Internet communities while permitting the authors to
retain as many rights as possible. This memo details the IETF retain as many rights as possible. This memo details the IETF
policies on rights in Contributions to the IETF. It also describes policies on rights in Contributions to the IETF. It also describes
the objectives that the policies are designed to meet. This memo the objectives that the policies are designed to meet. This memo
obsoletes RFC 3978 and, with RFC 3979 and RFC xxx (-outgoing), obsoletes RFC 3978 and 4748 and, with RFC 3979 and RFC xxx
replaces Section 10 of RFC 2026. (-outgoing), replaces Section 10 of RFC 2026.
Table of Contents Table of Contents
1. Definitions 1. Definitions
2. Introduction 2. Introduction
3. Rights in IETF Contributions 2.1 No Retroactive Effect
3.1. General Policy 3. Exposition of why these procedures are the way they are
3.2. Confidentiality Obligations 3.1. Rights Granted in Contributions
3.3. Granting of Rights and Permissions 3.2. Rights to use Contributions
3.4. Representations and Warranties 3.3. Right to Produce Derivative Works
3.5. No Duty to Publish 3.4. Rights to use Trademarks
3.6. Trademarks 3.5. Contributions Not Subject to Copyright
4. Rights in RFC Editor Contributions 3.6. Copyright in RFCs
4.1. Requirements from Section 3 4. RFC Editor Documents
4.2. Granting of Rights and Permissions 5. Rights in Contributions
5. Notices Required in IETF Documents 5.1. General Policy
5.1. IPR Disclosure Acknowledgement 5.2. Confidentiality Obligations
5.2. Derivative Works Limitation 5.3. Rights Granted by Contributors to the IETF Trust
5.3. Publication Limitation 5.4. Sublicenses by IETF Trust
5.4. Copyright Notice 5.5. No Patent License
5.5. Disclaimer 5.6. Representations and Warranties
5.6. Exceptions 5.7. No Duty to Publish
6. Notices and Rights Required in RFC Editor Contributions 5.8. Trademarks
7. Exposition of why these procedures are the way they are 5.9. Copyright in RFCs
7.1. Rights Granted in IETF Contributions 6. Legends, Notices and Other Standardized Text in IETF Documents
7.2. Rights to use Contributed Material 7. Security Considerations
7.3. Right to Produce Derivative Works 8. References
7.4. Rights to use Trademarks 8.1. Normative References
7.5. Who Does This Apply To? 8.2. Informative References
8. Contributions Not Subject to Copyright 9. Acknowledgements
9. Security Considerations 10. Editors' Addresses
10. References
10.1. Normative References
10.2. Informative References
11. Acknowledgements
Editor's Address
Full Copyright Statement Full Copyright Statement
1. Definitions 1. Definitions
The following definitions are for terms used in the context of
thisdocument. Other terms, including "IESG," "ISOC," "IAB," and
"RFCEditor," are defined in [RFC2028].
The following definitions are for terms used in the context of this a. "Contribution": any submission to the IETF intended by the
document. Other terms, including "IESG," "ISOC," "IAB," and "RFC
Editor," are defined in [RFC2028].
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 Contributor for publication as all or part of an Internet-Draft or
RFC (except for RFC Editor Contributions described below) and any RFC (except for RFC Editor Contributions described in Section 4
statement made within the context of an IETF activity. Such below) and any statement made within the context of an IETF
statements include oral statements in IETF sessions, as well as activity. Such statements include oral statements in IETF
written and electronic communications made at any time or place, sessions, as well as written and electronic communications made at
which are addressed to: any time or place, which are addressed to:
o the IETF plenary session, o the IETF plenary session,
o any IETF working group or portion thereof, o any IETF working group or portion thereof,
o the IESG, or any member thereof on behalf of the IESG, 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 the IAB or any member thereof on behalf of the IAB,
o any IETF mailing list, including the IETF list itself, any o any IETF mailing list, including the IETF list itself, any
working group or design team list, or any other list working group or design team list, or any other list
functioning under IETF auspices, functioning under IETF auspices,
o the RFC Editor or the Internet-Drafts function (except for RFC o the RFC Editor or the Internet-Drafts function (except for RFC
Editor Contributions described below). Editor Contributions described in Section 4 below).
Statements made outside of an IETF session, mailing list or other Statements made outside of an IETF session, mailing list or other
function, that are clearly not intended to be input to an IETF function, that are clearly not intended to be input to an IETF
activity, group or function, are not IETF Contributions in the activity, group or function, are not IETF Contributions in the
context of this document. context of this document.
b. "Contributor": an individual submitting a Contribution.
d. "Internet-Draft": temporary documents used in the IETF and RFC c. "Copyright" means the legal right granted to an author in a
Editor processes. Internet-Drafts are posted on the IETF web site document or other work of authorship under applicable law. A
by the IETF Secretariat and have a nominal maximum lifetime in the "copyright" is not equivalent to a "right to copy". Rather a
Secretariat's public directory of 6 months, after which they are copyright encompasses all of the exclusive rights that an author
removed. Note that Internet-Drafts are archived many places on the has in a work, such as the rights to copy, publish, distribute and
Internet, and not all of these places remove expired Internet- create derivative works of the work. An author often cedes these
Drafts. Internet-Drafts that are under active consideration by the rights to his or her employer or other parties as a condition of
IESG are not removed from the Secretariat's public directory until employment or compensation.
that consideration is complete. In addition, the author of an d. "IETF": In the context of this document, the IETF includes all
Internet-Draft can request that the lifetime in the Secretariat's individuals who participate in meetings, working groups, mailing
public directory be extended before the expiration. lists, functions and other activities which are organized or
initiated by ISOC, the IESG or the IAB under the general
e. "RFC": the basic publication series for the IETF. RFCs are designation of the Internet Engineering Task Force or IETF, but
published by the RFC Editor and once published are never modified. solely to the extent of such participation.
(See [RFC2026] Section 2.1) e. "IETF Documents": RFCs and Internet-Drafts.
f. "IETF Standards Process": the activities undertaken by the IETF in
f. "RFC Editor Contribution": An Internet-Draft intended by the any of the settings described in 1(c) below.
Contributor to be submitted to the RFC Editor for publication as g. "IETF Trust": A trust established under the laws of the
an Informational or Experimental RFC but not intended to be part Commonwealth of Virginia, USA, in order to hold and administer
of the IETF Standards Process. intellectual property rights for the benefit of the IETF.
h. "Internet-Draft": temporary documents used in the IETF Standards
g. "IETF Internet-Drafts": Internet-Drafts other than RFC Editor Process. Internet-Drafts are posted on the IETF web site by the
Contributions. Note that under Section 3.3 the grant of rights in IETF Secretariat. As noted in Section 2.2 of RFC 2026, Internet-
regards to IETF Internet-Drafts as specified in this document is Drafts have a nominal maximum lifetime of six months in the IETF
perpetual and irrevocable and thus survives the Secretariat's Secretariat's public directory.
removal of an Internet-Draft from the public directory, except as i. "Legend Instructions" means the standardized text that is
limited by Section 3.3 (C). (See [RFC2026] Sections 2.2 and 8) included in IETF Documents and the instructions and requirements
for including that standardized text in IETF Documents, each as
h. "IETF Documents": RFCs and Internet-Drafts except for Internet- posted from time to time at www.ietf.org/legends.
Drafts that are RFC Editor Contributions and the RFCs that are j. "RFC": the basic publication series for the IETF. RFCs are
published from them. 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
i. "RFC Editor Documents": RFCs and Internet-Drafts that are RFC altered once published in RFC form. (See [RFC2026] Section 2.1)
Editor Contributions and the RFCs that may be published from them. k. "Reasonably and personally known": means something an individual
j. "Contribution": IETF Contributions and RFC Editor Contributions.
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, knows personally or, because of the job the individual holds,
would reasonably be expected to know. This wording is used to would reasonably be expected to know. This wording is used to
indicate that an organization cannot purposely keep an individual indicate that an organization cannot purposely keep an individual
in the dark about patents or patent applications just to avoid the in the dark about patents or patent applications just to avoid the
disclosure requirement. But this requirement should not be disclosure requirement. But this requirement should not be
interpreted as requiring the IETF Contributor or participant (or interpreted as requiring the IETF Contributor or participant (or
his or her represented organization, if any) to perform a patent his or her represented organization, if any) to perform a patent
search to find applicable IPR. search in an attempt to find applicable IPR.
2. Introduction 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 Under the laws of most countries and current international treaties
(for example the "Berne Convention for the Protection of Literary and (for example the "Berne Convention for the Protection of Literary and
Artistic Work" [Berne]), authors obtain numerous rights in the works Artistic Work" [Berne Convention]), authors obtain numerous rights in
they produce automatically upon producing them. These rights include the works they produce automatically upon producing them. These
copyrights, moral rights and other rights. In many cases, if the rights include copyrights, moral rights and other rights. In many
author produces a work within the scope of his or her employment, cases, if the author produces a work within the scope of his or her
most of those rights are usually assigned to the employer, either by employment, most of those rights are usually assigned to the
operation of law or, in many cases, under contract. (The Berne employer, either by operation of law or, in many cases, under
Convention names some rights as "inalienable", which means that the contract. (The Berne Convention names some rights as "inalienable",
author retains them in all cases.) 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. This document obsoletes RFC 3978 [RFC3978].
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 Trust and the IETF. In
addition, Contributors must make representations to IETF Trust and
the IETF regarding their ability to grant these rights. These
necessary rights and representations have until now been laid out in
Section 10 of [RFC2026]. In the years since [RFC2026] 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 [RFC2026] 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. In order for Contributions to be used within the IETF Standards
Sections 3, 4, 5, and 6 of this document address the rights in Process, including when they are published as Internet-Drafts or
Contributions previously covered by Section 10 of [RFC2026] and the RFCs, certain limited rights must be granted to the IETF Trust, which
"Note Well" explanatory text presented at many IETF activities. then grants the necessary rights to the IETF. In addition,
Sections 7 and 8 then explain the rationale for these provisions, Contributors must make representations to IETF Trust and the IETF
including some of the clarifications that have become understood regarding their ability to grant these rights.
since the adoption of [RFC2026]. 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 [RFC3979] deals with rights in technologies Section 1 provides definitions used in these policies. Sections 3
and 4 of this document explain the rationale for these provisions.
Only sections 5 and 6 of this document are normative, the other
sections are informative. A companion document RFC 3979 [RFC3979]
deals with rights, including possible patent rights, in technologies
developed or specified as part of the IETF Standards Process. This developed or specified as part of the IETF Standards Process. This
document is not intended to address those issues. document is not intended to address those issues. This memo
obsoletes RFC 3978 and 4748 and, with RFC 3979 and RFC
The rights addressed in this document fall into the following xxx(-outgoing), replaces Section 10 of RFC 2026.
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 This document is not intended as legal advice. Readers are advised to
consult their own legal advisors if they would like a legal consult their own legal advisors if they would like a legal
interpretation of their rights or the rights of the IETF in any interpretation of their rights or the rights of the IETF Trust in any
Contributions they make. Contributions they make.
2.1 No Retroactive Effect 2.1 No Retroactive Effect
This memo does not retroactively obtain additional rights from This memo does not retroactively obtain additional rights from
Contributions that predate the publication of this memo as a RFC. Contributions that predate the date that the IETF Trust announces the
adoption of these procedures.
2.2 Boilerplate updates by the IETF Trust 3. Exposition of Why These Procedures Are the Way They Are
In the past the IETF has had to publish new RFCs to make editorial or
other minor updates to the boilerplate required on IETF Internet
Drafts. This memo grants to the IETF Trust the explicit right to
approve minor boilerplate changes as long as any such changes are
consistent with philosophical goals of the current versions of the
BCPs defining the IETF's philosophical goals for contributions. The
IETF Trust is also authorized to handle special cases and fix minor
errors.
3. Rights in IETF Contributions 3.1. Rights Granted in Contributions
The IETF Trust and IETF must obtain the right to publish an IETF
Contribution as an RFC or an Internet-Draft from the Contributors.
The following are the rights the IETF requires in all IETF A primary objective of this policy is to obtain from the document
Contributions: 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.
3.1. General Policy The authors retain all other rights, but cannot withdraw the above
rights from the IETF Trust and IETF.
In all matters of copyright and document procedures, the intent is to It is important to note that under this document Contributors are
benefit the Internet community and the public at large, while required to grant certain rights to the IETF Trust, which holds all
respecting the legitimate rights of others. 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. 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 [-outbound].
By submission of a Contribution, each person actually submitting the 3.2. Rights to use Contributions
Contribution, and each named co-Contributor, is deemed to agree to Because, under the laws of most countries and applicable
the terms and conditions set forth in this document, on his or her international treaties, copyright rights come into existence when a
own behalf and on behalf of the organization the Contributor work of authorship is created (but see Section 3.5 below regarding
represents or is sponsored by (if any), when submitting the public domain documents), and IETF cannot make use of IETF
Contribution. 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 Section5.6 below. These
assurances are requested, however, only to the extent of the
Contributor's reasonable and personal knowledge. (See Section 1(l))
3.2. Confidentiality Obligations 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
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. 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 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 [-outbound.
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
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. 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.
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. 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 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 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 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 Trust, 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.
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 IETF's RFC format. And while
this principle (which is included in Section 5.9 below) may appear to
be new to 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. RFC Editor Documents
This document only relates to Contributions made as part of the IETF
Standards Process. 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 "RFC Editor
Documents" are not covered by this document. RFC Editor
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.
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, 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. No further
acknowledgement, 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 No information or document that is subject to any requirement of
confidentiality or any restriction on its dissemination may be confidentiality or any restriction on its dissemination may be
submitted as a Contribution or otherwise considered in any part of submitted as a Contribution or otherwise considered in any part of
the IETF Standards Process, and there must be no assumption of any the IETF Standards Process, and there must be no assumption of any
confidentiality obligation with respect to any Contribution. Each confidentiality obligation with respect to any Contribution. Each
Contributor agrees that any statement in a Contribution, whether Contributor agrees that any statement in a Contribution, whether
generated automatically or otherwise, that states or implies that the generated automatically or otherwise, that states or implies that the
Contribution is confidential or subject to any privilege, can be Contribution is confidential or subject to any privilege, can be
disregarded for all purposes, and will be of no force or effect. disregarded for all purposes, and will be of no force or effect.
3.3. Rights Granted by Contributors to the IETF Trust 5.3. Rights Granted by Contributors to the IETF Trust
To the extent that a Contribution or any portion thereof is protected To the extent that a Contribution or any portion thereof is protected
by copyright or other rights of authorship, the Contributor, and each by copyright or other rights of authorship, the Contributor, and each
named co-Contributor, and the organization he or she represents or is named co-Contributor, and the organization he or she represents or is
sponsored by (if any) grant a perpetual, irrevocable, non-exclusive, sponsored by (if any) grant a perpetual, irrevocable, non-exclusive,
royalty-free, world-wide right and license to the IETF Trust under royalty-free, world-wide right and license to the IETF Trust under
all such copyrights and other rights in the Contribution. all such copyrights and other rights in the Contribution.
[editor question - since the IETF trust does not actually make
modified versions etc - should this say "permit the copying,
publication, ... of the Contribution ..."]
(A) to copy, publish, display, and distribute the Contribution, in (A) to copy, publish, display, and distribute the Contribution, in
whole or in part, whole or in part,
(B) to prepare translations of the Contribution into languages other (B) to prepare translations of the Contribution into languages other
than English, and to copy, publish, display, and distribute such than English, in whole or in part, and to copy, publish, display,
translations or portions thereof, and distribute such translations or portions thereof,
(C) unless explicitly disallowed in the notices contained in a (C) unless explicitly disallowed in the notices contained in a
Contribution [as per Section 5.2 below], to modify or prepare Contribution [in the form specified by the Legend Instructions],
derivative works (in addition to translations) that are based on to modify or prepare derivative works (in addition to
or incorporate all or part of the Contribution, and to copy, translations) that are based on or incorporate all or part of the
publish, display, and distribute such derivative works, and Contribution, and to copy, publish, display, and distribute such
derivative works, or portions thereof, and
(D) to reproduce any trademarks, service marks or trade names which (D) to reproduce any trademarks, service marks or trade names which
are included in the Contribution solely in connection with the are included in the Contribution solely in connection with the
reproduction, distribution or publication of the Contribution and reproduction, distribution or publication of the Contribution and
derivative works thereof as permitted by this Section 3.3, derivative works thereof as permitted by this Section 5.3,
provided that when reproducing Contributions, trademark and provided that when reproducing Contributions, trademark and
service mark identifiers used in the Contribution, including TM service mark identifiers used in the Contribution, including TM
and (r) will be preserved. and (R) will be preserved.
The licenses granted in this Section 3.3 shall not be deemed to grant 5.4 Sublicenses by IETF Trust
any right under any patent, patent application or other similar 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 [TRUST LICENSE
DOCUMENT].
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 xxx [-outbound].
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 intellectual property right disclosed by the Contributor under BCP 79
or otherwise. or otherwise.
3.4. Representations and Warranties 5.6. Representations and Warranties
With respect to each Contribution, each Contributor represents that With respect to each Contribution, each Contributor represents that
to the best of his or her knowledge and ability: to the best of his or her knowledge and ability:
a. The Contribution properly acknowledges all major Contributors. A a. The Contribution properly acknowledges all major Contributors. A
major Contributor is any person who has materially or major Contributor is any person who has materially or
substantially contributed to the IETF Contribution. substantially contributed to the Contribution.
b. No information in the Contribution is confidential and the IETF, b. No information in the Contribution is confidential and the IETF,
IETF Trust, ISOC, and its affiliated organizations may freely IETF Trust, ISOC, and its affiliated organizations may freely
disclose any information in the Contribution. disclose any information in the Contribution.
c. There are no limits to the Contributor's ability to make the c. There are no limits to the Contributor's ability to make the
grants, acknowledgments and agreements herein that are reasonably grants, acknowledgments and agreements herein that are reasonably
and personally known to the Contributor. and personally known to the Contributor.
d. The Contributor has not intentionally included in the Contribution d. The Contributor has not intentionally included in the Contribution
any material which is defamatory or untrue or which is illegal any material which is defamatory or untrue or which is illegal
under the laws of the jurisdiction in which the Contributor has under the laws of the jurisdiction in which the Contributor has
his or her principal place of business or residence. his or her principal place of business or residence.
e. All trademarks, trade names, service marks and other proprietary e. All trademarks, trade names, service marks and other proprietary
names used in the Contribution that are reasonably and personally names used in the Contribution that are reasonably and personally
known to the Contributor are clearly designated as such where known to the Contributor are clearly designated as such where
reasonable. reasonable.
3.5. No Duty to Publish 5.7. No Duty to Publish
The Contributor, and each named co-Contributor, acknowledges that the The Contributor, and each named co-Contributor, acknowledges that the
IETF has no duty to publish or otherwise use or disseminate any IETF has no duty to publish or otherwise use or disseminate any
Contribution. The IETF reserves the right to withdraw or cease using Contribution. The IETF reserves the right to withdraw or cease using
any Contribution that does not comply with the requirements of any Contribution that does not comply with the requirements of
Section 3.3 and Section 3.4 or 4.2. Section 5.3 and Section 5.4 or 5.6.
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 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.)
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.
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 IETF Trust 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 Internet-Draft,
(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
IETF Trust and the IETF any more rights than the license to the
original RFC Editor Contribution, and
(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.
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 IETF
Trust 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
IETF Trust 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).
5.1. IPR Disclosure Acknowledgement (required in all Internet-Drafts)
"By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79."
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.
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 RFCs.
5.4. Copyright Notice (required for all IETF Documents)
(Normally placed at the end of the IETF Document.)
"Copyright (C) The IETF Trust (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."
Copyright notices from other organizations or individuals 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, THE
IETF TRUST 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."
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 IETF Trust <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 IETF Trust <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 at: 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.
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 three copyright release statements:
A. "By submitting this Internet-Draft, I accept the provisions of
Section 3 of BCP 78."
B. "By submitting this Internet-Draft, I accept the provisions of
Section 4 of BCP 78."
C. The Copyright Notice specified in Section 5.4 and the
disclaimer specified in section 5.5.
7. Exposition of Why These Procedures Are the Way They Are
7.1. Rights Granted in IETF Contributions
The IETF Trust and 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 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 .ti -3 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 Trust and IETF.
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.
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. 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.
7.4. Rights to Use Trademarks 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.)
Contributors may wish to seek trademark or service mark protection on 5.9 Copyright in RFCs
any terms that are coined or used in their IETF Contributions. IETF Subject to each Contributor's (or its sponsor's) ownership of its
makes no judgment about the validity of any such trademark rights. underlying Contributions (which ownership is qualified by the
However, the IETF requires each Contributor, under the licenses irrevocable licenses granted under Section 5.3), each Contributor
described in Section 3.3 above, to grant IETF a perpetual license to hereby acknowledges that the copyright in any RFC in which such
use any such trademarks or service marks solely in exercising its Contribution is included, other than an Informational RFC or an RFC
rights to reproduce, publish and modify the IETF Contribution. This that is an RFC Editor Contribution, shall be owned by the IETF Trust.
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.
8. Contributions Not Subject to Copyright 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, are
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.
Certain documents, including those produced by the U.S. government The IETF reserves the right to refuse to publish Contributions that
and those which are in the public domain, may not be protected by the do not include the legends required by the Legend Instructions.
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 Trust, 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 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.
7. Security Considerations
This memo relates to IETF process, not any particular technology. This memo relates to IETF process, not any particular technology.
There are security considerations when adopting any technology, but There are security considerations when adopting any technology, but
there are no known issues of security with IETF Contribution rights there are no known issues of security with IETF Contribution rights
policies. policies.
10. References 8. References
10.1. Normative References
8.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC 2028, October 1996. the IETF Standards Process", BCP 11, RFC 2028, October 1996.
[RFC3979] Bradner, S., Ed, "Intellectual Property Rights in IETF [RFC3979] Bradner, S., Ed, "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005. Technology", BCP 79, RFC 3979, March 2005.
[Trust] IETF Trust Agreement - http://iaoc.ietf.org/docs/IETF-Trust-
Agreement-Executed-12-15-05.pdf
10.2. Informative References 8.2. Informative References
[RFC3978] Bradner, S. Ed., "IETF Rights in Contributions", RFC 3978, [RFC3978] Bradner, S. Ed., "IETF Rights in Contributions", RFC 3978,
March 2005. March 2005.
[Berne] "Berne Convention for the Protection of Literary and Artistic [Berne] "Berne Convention for the Protection of Literary and Artistic
Work", http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html Work", http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html
11. Acknowledgements 9. Acknowledgements
The editors would like to acknowledge the help of the IETF IPR The editors would like to acknowledge the help of the IETF IPR
Working Group provided during the development of the document. Working Group provided during the development of the document.
Editor's Address 10. Editors' Addresses
Scott Bradner Scott Bradner
Harvard University Harvard University
29 Oxford St. 29 Oxford St.
Cambridge MA, 02138 Cambridge MA, 02138 USA
Phone: +1 617 495 3864 Phone: +1 617 495 3864
EMail: sob@harvard.edu EMail: sob@harvard.edu
Jorge L. Contreras Jorge L. Contreras
WilmerHale WilmerHale
1875 Pennsylvania Avenue NW 1875 Pennsylvania Avenue NW
Washington, DC 20006 USA Washington, DC 20006 USA
Phone: +1 202 663 6872 Phone: +1 202 663 6872
Email: jorge.contreras@wilmerhale.com Email: jorge.contreras@wilmerhale.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). This document is subject to the
Copyright (C) The IETF Trust (2007). rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights. This
This document is subject to the rights, licenses and restrictions document and the information contained herein are provided on an "AS
contained in BCP 78, and except as set forth therein, the authors IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTSOR
retain all their rights. IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
This document and the information contained herein are provided on an EXPRESSOR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS USE OFTHE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS PURPOSE.
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 Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. 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.
Copies of IPR disclosures made to the IETF Secretariat and any Acknowledgement
assurances of licenses to be made available, or the result of an Funding for the RFC Editor function is currently provided by the
attempt made to obtain a general license or permission for the use of Internet Society. ??
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.
US1DOCS 6241323v2
 End of changes. 67 change blocks. 
635 lines changed or deleted 385 lines changed or added

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