One document matched: draft-bradner-rfc3979bis-04.txt
Differences from draft-bradner-rfc3979bis-03.txt
Network Working Group Scott Bradner
Internet-Draft Harvard University
Intended status: BCP
Obsoletes: 3979, 4879 Jorge Contreras
Updates: 2026 American University
Expires: October 8, 2013 April 8, 2013
Intellectual Property Rights in IETF Technology
draft-bradner-rfc3979bis-04.txt
Abstract
The IETF policies about Intellectual Property Rights (IPR), such as
patent rights, relative to technologies developed in the IETF are
designed to ensure that IETF working groups and participants have as
much information about any IPR constraints on a technical proposal as
possible. The policies are intended to benefit the Internet
community and the public at large, while respecting the legitimate
rights of IPR holders. This memo details the IETF policies
concerning IPR related to technology worked on within the IETF. It
also describes the objectives that the policies are designed to meet.
This memo updates RFC 2026 and obsoletes RFC 3979 and RFC 4879.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 8, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Bradner & Contreras [Page 1]
Internet-Draft RFC 3979 bis April 2013
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
[tbd]
1. Definitions
The following definitions are for terms used in the context of this
document. Other terms, including "IESG," "ISOC," "IAB," and "RFC
Editor," are defined in [RFC2028].
a. "Alternate Stream": the IAB Document Stream, the IRTF Document
Stream and the Independent Submission Stream, each as defined in
Section 5.1 of [RFC4844].
b. "Contribution": any submission to the IETF intended by the
Contributor for publication as all or part of an Internet-Draft or
RFC and any statement made within the context of an IETF activity,
in each case that is intended to affect the IETF Standards Process
or that is related to the activity of an Alternate Stream that has
adopted this definition.
Such statements include oral statements, as well as written and
electronic communications, which are addressed to:
o the IETF plenary session,
o any IETF working group or portion thereof,
o any IETF "birds of a feather" (BOF) session or portion thereof,
o any IETF-sanctioned design team 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,
o any IETF mailing list, web site, chat room or discussion board,
operated by or under the auspices of the IETF, including the
IETF list itself,
o the RFC Editor or the Internet-Drafts function.
Statements made outside of an IETF session, mailing list or other
function, or that are clearly not intended to be input to an IETF
activity, group or function, are not Contributions in the context
Bradner & Contreras [Page 2]
Internet-Draft RFC 3979 bis April 2013
of this document. For example, the presentations made by invited
speakers at IETF plenary sessions to discuss advances in Internet
technology generally, or to describe their existing products or
technologies, are not Contributions.
Throughout this memo, the term "written Contribution" is used.
For purposes of this memo, "written" means reduced to a written or
visual form in any language and any media, permanent or temporary,
including but not limited to traditional documents, e-mail
messages, discussion board postings, slide presentations, text
messages, instant messages, and transcriptions of oral statements.
c. "Contributor": an individual submitting a Contribution
d. "Covers" or "Covered" mean that a valid claim of a patent or a
patent application (including a provisional patent application) in
any jurisdiction , or any other Intellectual Property Right, would
necessarily be infringed by the exercise of a right (e.g., making,
using, selling, importing, distribution, copying, etc.) with
respect to an Implementing Technology. For purposes of this
definition, "valid claim" means a claim of any unexpired patent or
patent application which shall not have been withdrawn, cancelled
or disclaimed, nor held invalid by a court of competent
jurisdiction in an unappealed or unappealable decision.
e. "IETF": In the context of this document, the IETF includes all
individuals who participate in meetings, working groups, mailing
lists, functions and other activities 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.
f. "IETF Documents": RFCs and Internet-Drafts that are published as
part of the IETF Standards Process. These are also referred to as
"IETF Stream Documents" as defined in Section 5.1.1 of RFC 4844.
g. "IETF Standards Process": the activities undertaken by the IETF in
any of the settings described in the above definition of
Contribution. The IETF Standards Process may include
participation in activities and publication of documents that are
not directed toward the development of IETF standards or
specifications, such as the development and publication of
informational documents.
h. "IPR" or "Intellectual Property Rights": means a patent, utility
model, or similar right that may Cover an Implementing Technology,
whether such rights arise from a registration or renewal thereof,
or an application therefore, in each case anywhere in the world.
Bradner & Contreras [Page 3]
Internet-Draft RFC 3979 bis April 2013
See [RFC5378] for a discussion of Trademarks.
i. "Implementing Technology": means a technology that implements an
IETF specification or standard.
j. "Internet-Draft": a temporary document used in the IETF and RFC
Editor processes, as described in [RFC2026].
k. "Participating in an IETF discussion or activity": means making a
Contribution, as described above, or in any other way acting in
order to influence the outcome of a discussion relating to the
IETF Standards Process. Without limiting the generality of the
foregoing, attending all or part of a session at a live IETF
meeting is deemed to mean participating in the entire session.
Sending a message to an email list is deemed to constitute
participating in the associated email discussion for its entire
duration and any successor email discussions. Likewise, simply
subscribing to or reading messages received from an IETF email
list does not constitute participation in the relevant IETF
discussion.
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.
m. "RFC": the basic publication series for the IETF. RFCs are
published by the RFC Editor and once published are never modified.
(See [RFC2026] Section 2.1)
2. Introduction
The IETF policies about Intellectual Property Rights (IPR), such as
patent rights, relative to technologies developed in the IETF are
designed to ensure that IETF working groups and participants have as
much information about any IPR constraints on a technical proposal as
possible. The policies are intended to benefit the Internet
community and the public at large, while respecting the legitimate
rights of IPR holders. This memo details the IETF policies
concerning IPR related to technology worked on within the IETF. It
also describes the objectives that the policies are designed to meet.
This memo updates RFC 2026 [RFC2026] and obsoletes RFC 3979 [RFC3979]
and RFC 4879 [RFC4879].
Bradner & Contreras [Page 4]
Internet-Draft RFC 3979 bis April 2013
Section 1 defines the terms used in this document. Sections 3
through 11 set forth the IETF's policies and procedures relating to
IPR. Section 13 lists the changes between this document and RFCs
3979 and 4879. A separate document [RFC5378] deals with rights (such
as copyrights and Trademarks) in Contributions, including the right
of IETF and its participants to publish and create derivative works
of those Contributions. This document is not intended to address
those issues. See RFC 6702 [RFC6702] for a discussion of "Promoting
Compliance with Intellectual Property Rights (IPR) Disclosure Rules".
/ 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. Contributions to the IETF
3.1. General Policy
In all matters relating to Intellectual Property Rights, the intent
is to benefit the Internet community and the public at large, while
respecting the legitimate rights of others.
3.2. 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, on his or her own behalf, and on
behalf of the organizations the Contributor represents or is
sponsored by (if any) when submitting the Contribution.
A. The Contributor represents that he or she has made or will
promptly make all disclosures required by Section 5.1.1 of this
document.
B. The Contributor represents that 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.
4. Actions for Documents for which IPR Disclosure(s) Have Been Received
A. The IESG, IAB, ISOC and IETF Trust disclaim any responsibility for
identifying the existence of or for evaluating the applicability
of any IPR, disclosed or otherwise, to any IETF technology,
specification or standard, and will take no position on the
validity or scope of any such IPR.
B. When the IETF Secretariat has received a notification under
Bradner & Contreras [Page 5]
Internet-Draft RFC 3979 bis April 2013
Section 5.1.3 of the existence of non-participant IPR that
potentially Covers a technology under discussion at IETF or which
is the subject of an IETF Document, the IETF Secretariat will
request that the identified third party make an IPR disclosure in
accordance with the provisions of Section 5. If such third party
declines to make such a disclosure within a reasonable period of
time, as determined by the IESG, then the IESG may submit an IPR
disclosure identifying such third party IPR, with an indication
that such IPR disclosure is being made based on the identification
of such IPR by an IETF participant other than the IPR holder.
C. When an IPR disclosure has been made as provided in Section 5 of
this document, the IETF Secretariat shall request from the
purported holder of such IPR, a written assurance that upon
approval by the IESG for publication of the relevant IETF
specification(s) as one or more RFCs, all persons will be able to
obtain the right to implement, use, distribute and exercise other
rights with respect to Implementing Technology under one of the
licensing options specified in Section 5.5.A below unless such a
statement has already been submitted. The working group proposing
the use of the technology with respect to which the Intellectual
Property Rights are disclosed may assist the IETF Secretariat in
this effort.
The results of this procedure shall not, in themselves, block
publication of an IETF Document or advancement of an IETF Document
along the standards track. A working group may take into
consideration the results of this procedure in evaluating the
technology, and the IESG may defer approval when a delay may
facilitate obtaining such assurances. The results will, however,
be recorded by the IETF Secretariat, and be made available online.
D. Determination of Provision of Reasonable and Non-discriminatory
Terms
The IESG will not make any determination that any terms for the
use of an Implementing Technology has been fulfilled in practice.
5. IPR Disclosures
This document refers to the IETF participant making disclosures,
consistent with the general IETF philosophy that participants in the
IETF act as individuals. A participant's obligation to make a
disclosure is also considered satisfied if the IPR owner or the
participant's employer or sponsor makes an appropriate disclosure in
place of the participant doing so.
Bradner & Contreras [Page 6]
Internet-Draft RFC 3979 bis April 2013
5.1. Who Must Make an IPR Disclosure?
5.1.1. A Contributor's IPR in his or her Contribution
A. Any Contributor who reasonably and personally knows of IPR meeting
the conditions of Section 5.6 which the Contributor believes
Covers or may ultimately Cover his or her written Contribution
(other than a Contribution that is not intended to be used as an
input into the IETF Standards Process), or which the Contributor
reasonably and personally knows his or her employer or sponsor may
assert against Implementing Technologies based on such written
Contribution, must make a disclosure in accordance with this
Section 5.
B. An IPR discloser must withdraw a previous disclosure if a revised
Contribution negates the previous IPR disclosure, and must amend a
previous disclosure if a revised Contribution substantially alters
the matters disclosed in a previous disclosure.
5.1.2. An IETF Participant's IPR in Contributions by Others
Any individual participating in an IETF discussion or activity who
reasonably and personally knows of IPR meeting the conditions of
Section 5.6 which the individual believes Covers or may ultimately
Cover a written Contribution made by another person, or which such
IETF participant reasonably and personally knows his or her employer
or sponsor may assert against Implementing Technologies based on such
written Contribution, must make a disclosure in accordance with this
Section 5.
5.1.3. IPR of Others
If any person has information about IPR that may Cover a written
Contribution, but such person is not required to disclose such IPR
because it does not meet the criteria in Section 6.6 (e.g., the IPR
is not owned or controlled by the person or his or her employer or
sponsor, or such person is not an IETF participant), such person is
encouraged to file a third party disclosure as described in Section
5.3 below. Such a notice should be filed as soon as reasonably
possible after the IETF participant realizes the connection.
5.2. The Timing of Providing Disclosure
Timely IPR disclosure is important because working groups need to
have as much information as they can while they are evaluating
alternative solutions.
Bradner & Contreras [Page 7]
Internet-Draft RFC 3979 bis April 2013
5.2.1. Timing of Disclosure Under Section 5.1.1
A. The IPR disclosure required pursuant to section 5.1.1 must be made
as soon as reasonably possible after the Contribution is submitted
or made unless the required disclosure is already on file. For
example, if the Contribution is an update to a Contribution for
which an IPR disclosure has already been made and the
applicability of the disclosure is not changed by the new
Contribution, then no new disclosure is required. But if the
Contribution is a new one, or is one that changes an existing
Contribution such that the revised Contribution is no longer
Covered by the disclosed IPR or would be Covered by new or
different IPR, then a disclosure must be made.
B. If a Contributor first learns of IPR in its Contribution that
meets the conditions of Section 5.6, for example a new patent
application or the discovery of a relevant patent in a patent
portfolio, after the Contribution is published in an Internet-
Draft, a disclosure must be made as soon as reasonably possible
after the IPR becomes reasonably and personally known to the
Contributor.
C. Participants who realize that the making of a Contribution that
will be Covered by IPR meeting the conditions of Section 5.6 is
likely are strongly encouraged to make a preliminary IPR
disclosure. That IPR disclosure should be made as soon after
coming to the realization as reasonably possible, not waiting
until the Contribution is actually posted or ready for posting.
5.2.2. Timing of Disclosure Under Section5.1.2
The IPR disclosure required pursuant to section 5.1.2 must be made as
soon as reasonably possible after the Contribution is made, unless
the required disclosure is already on file.
Participants who realize that IPR meeting the conditions of Section
5.6 will be or has been incorporated into a Contribution, or is
seriously being discussed in a working group, are strongly encouraged
to make a preliminary IPR disclosure. That IPR disclosure should be
made as soon after coming to the realization as reasonably possible,
not waiting until the Contribution is actually made.
If an IETF participant first learns of IPR that meets the conditions
of Section 5.6 in a Contribution by another party, for example a new
patent application or the discovery of a relevant patent in a patent
portfolio, after the Contribution was made, an IPR disclosure must be
made as soon as reasonably possible after the Contribution or IPR
becomes reasonably and personally known to the participant.
Bradner & Contreras [Page 8]
Internet-Draft RFC 3979 bis April 2013
5.3. How Must an IPR Disclosure be Made?
IPR disclosures are made by following the instructions at
http://www.ietf.org/ipr-instructions.
5.4. What Must be in an IPR Disclosure? Updating IPR Disclosures.
5.4.1. What Must be in an IPR Disclosure?
An IPR disclosure must list the numbers of any issued patents or
published patent applications or indicate that the claim is based on
unpublished patent applications. The IPR disclosure must also list
the name(s) of the inventors and the specific IETF Document(s) or
activity affected. If the IETF Document is an Internet-Draft, it
must be referenced by specific version number. In addition, if the
IETF Document includes multiple parts and it is not reasonably
apparent which part of such IETF Document is alleged to be Covered by
the IPR in question, the discloser must identify the sections of the
IETF Document that are alleged to be so Covered.
5.4.2. Updating IPR Disclosures.
A. An IPR disclosure must be updated or a new disclosure made
promptly after any of the following has occurred: the publication
of a previously unpublished patent application, the abandonment of
a patent application and/or the issuance of a patent thereon, a
material change to the IETF Document covered by the Disclosure
that causes the Disclosure to be covered by additional IPR. If a
patent has issued, then the new IPR disclosure must include the
patent number and, if the claims of the granted patent differ from
those of the application in manner material to the relevant
Contribution, the IPR disclosure must describe any differences in
applicability to the Contribution. If the patent application was
abandoned, then the new IPR disclosure must explicitly withdraw
any earlier IPR disclosures based on the application. IPR
disclosures against a particular Contribution are assumed to be
inherited by revisions of the Contribution and by any RFCs that
are published from the Contribution unless the disclosure has been
updated or withdrawn.
B. If an IPR holder files patent applications in additional
countries, the claims of which are substantially identical to the
claims of a patent or patent application previously disclosed in
an IPR disclosure, the IPR holder is not required to make a new or
updated IPR disclosure as a result of filing such applications or
the issuance of patents on such applications.
Bradner & Contreras [Page 9]
Internet-Draft RFC 3979 bis April 2013
C. An IETF participant must make a new IPR disclosure if a
Contribution becomes Covered by IPR that was not previously
disclosed against the relevant Contribution, and such IETF
participant reasonably and personally knows of such IPR.
D. New or revised IPR disclosures may be made voluntarily at any
other time, provided that no updated IPR disclosure may retract,
revoke or limit any licensing commitment made in an earlier IPR
disclosure.
5.4.3. The requirement to make an IPR disclosure is not satisfied by the
submission of a blanket statement that IPR may exist on every
Contribution or a general category of Contributions. This is the
case because the aim of the disclosure requirement is to provide
information about specific IPR against specific technology under
discussion in the IETF. The requirement is also not satisfied by a
blanket statement of willingness or commitment to license all
potential IPR Covering such technology under fair, reasonable and
non-discriminatory terms for the same reason. However, the
requirement for an IPR disclosure is satisfied by a blanket statement
of the IPR discloser's commitment to license all of its IPR meeting
the requirements of Section 5.6 (and either Section 5.1.1 or 5.1.2)
to implementers of an IETF specification on a royalty-free (and
otherwise reasonable and non-discriminatory) basis as long as any
other terms and conditions are disclosed in the IPR disclosure.
5.5. Licensing Information in an IPR Disclosure
A. Since IPR disclosures will be used by IETF working groups during
their evaluation of alternative technical solutions, it is helpful
if an IPR disclosure includes information about licensing of the
IPR in case Implementing Technologies require a license.
Specifically, it is helpful to indicate whether, upon approval by
the IESG for publication as an RFC of the relevant IETF
specification(s), all persons will be able to obtain the right to
implement, use, distribute and exercise other rights with respect
to an Implementing Technology a) under a royalty-free and
otherwise reasonable and non- discriminatory license, or b) under
a license that contains reasonable and non-discriminatory terms
and conditions, including a reasonable royalty or other payment,
or c) without the need to obtain a license from the IPR holder.
B. The inclusion of a licensing declaration is not mandatory but it
is encouraged so that the working groups will have as much
information as they can during their deliberations. If the
inclusion of a licensing declaration in an IPR disclosure would
significantly delay its submission it is quite reasonable to
Bradner & Contreras [Page 10]
Internet-Draft RFC 3979 bis April 2013
submit an IPR disclosure without a licensing declaration and then
submit a new IPR disclosure when the licensing declaration becomes
available. IPR disclosures that voluntarily provide text that
includes licensing information, comments, notes, or URL for other
information may also voluntarily include details regarding
specific licensing terms that the IPR holder intends to offer to
implementers of Implementing Technologies, including maximum
royalty rates
C. It is likely that IETF participants will rely on licensing
declarations and other information that may be contained in an IPR
disclosure and that they will make technical, legal and commercial
decisions on the basis of such commitments and information. Thus,
when licensing declarations and information, comments, notes, or
URLs for further information are contained in an IPR disclosure,
such materials shall be deemed irrevocable, and will attach to the
associated IPR, and all implementers of Implementing Technologies
will be justified and entitled to rely on such materials in
relating to such IPR, whether or not it is subsequently
transferred to a third party by the IPR holder making the
commitment or providing the information. IPR holders making IPR
disclosures that contain licensing declarations or providing such
information, comments, notes or URLs for further information must
ensure that such commitments are binding on any subsequent
transferee of the relevant IPR.
D. Licensing declarations must be made by people who are authorized
to make such declarations.
5.6. Level of Control over IPR requiring Disclosure
IPR disclosures under Sections 5.1.1. and 5.1.2 are required with
respect to IPR that is owned directly or indirectly, by the
individual or his/her employer or sponsor (if any) or that such
persons otherwise have the right to license or assert.
5.7. Disclosures for Oral Contributions.
If a Contribution is oral and is not followed promptly by a written
disclosure of the same material, and if such oral Contribution would
be subject to a requirement that an IPR Disclosure be made had such
oral Contribution been written, then the Contributor must accompany
such oral Contribution with an oral declaration that he/she is aware
of relevant IPR in as much detail as reasonably possible, or file an
IPR Declaration with respect to such oral Contribution that otherwise
complies with the provisions of Sections 5.1 to 5.6 above.
6. Failure to Disclose
Bradner & Contreras [Page 11]
Internet-Draft RFC 3979 bis April 2013
There may be cases in which individuals are not permitted by their
employers or by other factors to disclose the existence or substance
of patent applications or other IPR. Since disclosure is required
for anyone making a Contribution or participating in IETF activities,
a person who is not willing or able to disclose IPR for this reason,
or any other reason, must not contribute to or participate in IETF
activities with respect to technologies that he or she reasonably and
personally knows to be Covered by IPR which he or she will not
disclose.
Contributing to or participating in IETF activities about a
technology without making required IPR disclosures is a violation of
IETF process.
In addition to any remedies or defenses that may be available to
implementers and others under the law with respect to such a
violation (e.g., rendering the relevant IPR unenforceable), the IESG
may, when it in good faith concludes that such a violation has
occurred, impose penalties including, but not limited to, suspending
the posting/participation rights of the offending individual,
suspending the posting/participation rights of other individuals
employed by the same company as the offending individual, amending,
withdrawing or superseding the relevant IETF Documents, and publicly
announcing the facts surrounding such violation, including the name
of the offending individual and his or her employer or sponsor. See
[RFC6701] for details.
7. Evaluating Alternative Technologies in IETF Working Groups
In general, IETF working groups prefer technologies with no known IPR
claims or, for technologies with claims against them, an offer of
royalty-free licensing. But IETF working groups have the discretion
to adopt technology with a commitment of fair and non-discriminatory
terms, or even with no licensing commitment, if they feel that this
technology is superior enough to alternatives with fewer IPR claims
or free licensing to outweigh the potential cost of the licenses.
Over the last few years the IETF has adopted stricter requirements
for some security technologies. It has become common to have a
mandatory-to-implement security technology in IETF technology
specifications. This is to ensure that there will be at least one
common security technology present in all implementations of such a
specification that can be used in all cases. This does not limit the
specification from including other security technologies, the use of
which could be negotiated between implementations. An IETF consensus
has developed that no mandatory-to-implement security technology can
be specified in an IETF specification unless it has no known IPR
claims against it or a royalty-free license is available to all
Bradner & Contreras [Page 12]
Internet-Draft RFC 3979 bis April 2013
implementers of the specification unless there is a very good reason
to do so. This limitation does not extend to other security
technologies in the same specification if they are not listed as
mandatory-to-implement.
It should also be noted that the absence of IPR disclosures is not
the same thing as the knowledge that there will be no IPR claims in
the future. People or organizations not currently involved in the
IETF or people or organizations that discover IPR they feel to be
relevant in their patent portfolios can make IPR disclosures at any
time.
It should also be noted that the validity and enforceability of any
IPR may be challenged for legitimate reasons, and the mere existence
of an IPR disclosure should not automatically be taken to mean that
the disclosed IPR is valid or enforceable. Although the IETF can
make no actual determination of validity, enforceability or
applicability of any particular IPR claim, it is reasonable that a
working group will take into account on their own opinions of the
validity, enforceability or applicability of Intellectual Property
Rights in their evaluation of alternative technologies. However,
IETF working group members shall not, as part of any IETF activity,
engage in negotiation of licensing or other commercial terms with any
IPR holder.
8. Change Control for Technologies
The IETF must have change control over the technology described in
any standards track IETF Documents in order to fix problems that may
be discovered or to produce other derivative works.
In some cases the developer of patented or otherwise controlled
technology may decide to hand over to the IETF the right to evolve
the technology (a.k.a., "change control"). The implementation of an
agreement between the IETF and the developer of the technology can be
complex. (See [RFC1790] and [RFC2339] for examples.)
Note that there is no inherent prohibition against a standards track
IETF Document making a normative reference to proprietary technology.
For example, a number of IETF Standards support proprietary
cryptographic transforms.
9. Licensing Requirements to Advance Standards Track IETF Documents
RFC 6410 [RFC6410] Section 2.2 states: "If the technology required to
implement the specification requires patented or otherwise controlled
technology, then the set of implementations must demonstrate at least
two independent, separate and successful uses of the licensing
Bradner & Contreras [Page 13]
Internet-Draft RFC 3979 bis April 2013
process. " A key word in this text is "requires." The mere
existence of disclosed IPR does not necessarily mean that licenses
are actually required in order to implement the technology.
10. No IPR Disclosures in IETF Documents
IETF Documents must not contain any mention of specific IPR. All
specific IPR disclosures must be submitted as described in Section 5.
Readers should always refer to the on-line web page to get a full
list of IPR disclosures received by the IETF concerning any
Contribution. (http://www.ietf.org/ipr/)
11. Application to non-IETF Stream Documents
This memo has been developed for the benefit and use of the IETF
community. As such, the rules set forth herein apply to all
Contributions and IETF Documents that are in the "IETF Document
Stream" as defined in Section 5.1.1 of RFC 4844 (i.e., those that are
contributed, developed, edited and published as part of the IETF
Standards Process). The IAB Document Stream, the IRTF Document
Stream and the Independent Submission Stream, each as defined in
Section 5.1 of RFC 4844 are referred to collectively herein as
"Alternate Streams".
The legal rules that apply to documents in Alternate Streams are
established by the managers of those Alternate Streams as defined in
[RFC 4844]. (i.e., the Internet Architecture Board (IAB), Internet
Research Steering Group (IRSG) and Independent Submission Editor).
These managers may elect, through their own internal processes, to
cause this memo to be applied to documents contributed to them for
development, editing and publication in their respective Alternate
Streams. If an Alternate Stream manager elects to adopt this memo,
they must do so in a manner that is public and notifies their
respective document contributors that this memo applies to their
respective Alternate Streams. In such case, each occurrence of the
term "Contribution," and "IETF Document" in this memo shall be read
to mean a contribution or document in such Alternate Stream, as the
case may be. It would be advisable for such Alternate Stream manager
to consider adapting the definitions of "Contribution," and other
provisions in the memo to suit their particular needs.
12. Security Considerations
This memo relates to IETF process, not any particular technology.
There are security considerations when adopting any technology,
whether IPR-protected or not. A working group should take those
security considerations into account as one part of evaluating the
technology, just as IPR is one part, but there are no known issues of
Bradner & Contreras [Page 14]
Internet-Draft RFC 3979 bis April 2013
security with IPR procedures.
13. Changes Since RFC 3979 and RFC 4879
[this section will be revised before publication to list the actual
changes that are approved]
This document combines RFC 3979 and RFC 4879.
Reordered the defined terms
Boilerplate -- since the document boilerplate formerly in BCP79 Sec.
5 has been moved to the Trust Legal Provisions since 2009, deleted
the boilerplate requirements from this document.
Foreign Counterparts -- don't need to file a new IPR disclosure
Provisional Apps -- suggest that these be required to be disclosed
only if they are filed with claims.
Inventor names -- added words requiring that inventors be listed
along with patent numbers.
Oral statements -- the existing text is internally contradictory.
Some places say that disclosures must be made for oral statements,
but others talk about disclosures only being required following
publication as an ID. Proposed that oral statements don't trigger
the normal IPR disclosure obligations, as oral statements are
inherently imprecise and it's hard to know when they describe
something covered by the technical terms of a patent claim.
However, if an oral contribution is made and it is not followed by
a written contribution, then the oral discloser must either make a
concurrent oral IPR disclosure or file a formal written
disclosure.
Other Contribution Clarification -- suggested a number of other
clarifications to the definition of Contribution that have come up
over the years, including the addition of BOFs.
WG Consideration of Patents -- this is mostly in the existing
language, but added a sentence saying that WGs should not engage
in collective licensing negotiation.
Disclosure of licensing terms is ok -- added a sentence.
Licensing commitments are irrevocable -- added a paragraph.
Lurkers -- this is a complicated issue that runs throughout the
Bradner & Contreras [Page 15]
Internet-Draft RFC 3979 bis April 2013
document. At a high level, suggested that lurkers ARE required to
make IPR disclosures, to avoid a Rambus situation.
Penalties -- This paragraph outlining possible sanctions the IESG may
impose should be reconciled with the recent RFC that discusses
penalties.
Updating Disclosures - added a number of clauses to address issues
that have come up over the years, including updating obligations
if an employee changes jobs or his/her employer buys another
company.
Alternate Streams - borrowed and adapted the copyright language used
in the Trust Legal Provisions. Each alternate stream
(Independent, IRTF and IAB) would need to take some action
(preferably issuing an RFC) to adopt BCP 79 for its stream. This
was done with copyright already, and pretty smoothly.
IETF Exec Dir -- flagged the various places where the IETF Exec
Director is supposed to do something under this policy. Not sure
whether these things are getting done today or by whom. Need to
rationalize and update these procedures based on the current admin
structure.
Generally, also tried to cut back some of the historical and
explanatory text that seemed outdated
14. References
14.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC 2028, October 1996.
[RFC4844] Daigle, L. Ed. and Internet Architecture Board, "The RFC
Series and RFC Editor", RFC 4844, July 2007.
[RFC6410] Housley, R., D. Crocker, and E. Burger, "Reducing the
Standards Track to Two Maturity Levels", RFC 6401, October 2011.
14.2. Informative References
[RFC1790] Cerf, V., "An Agreement between the Internet Society and
Sun Microsystems, Inc. in the Matter of ONC RPC and XDR
Protocols", RFC 1790, April 1995.
Bradner & Contreras [Page 16]
Internet-Draft RFC 3979 bis April 2013
[RFC2339] The Internet Society and Sun Microsystems, "An Agreement
Between the Internet Society, the IETF, and Sun Microsystems, Inc.
in the matter of NFS V.4 Protocols", RFC 2339, May 1998.
[RFC5378] Bradner, S. Ed, J. Contreras, Ed, "Rights Contributors
Provide to the IETF Trust", RFC 5378, November 2008
[RFC6701] Farrel, A., and P. Resnick, "Sanctions Available for
Application to Violators of IETF IPR Policy", RFC 6702, August
2012
[RFC6702] Polk, T. and P. Saint-Andre, "Promoting Compliance with
Intellectual Property Rights (IPR)Disclosure Rules", RFC 6702,
August 2012
IANA Considerations
This memo requires no action by the IANA. [this section should be
removed for publication]
15. Editor's Addresses
Scott Bradner
Harvard University
1350 Mass. Ave.
Cambridge MA, 02138
Phone: +1 617 495 3864
EMail: sob@harvard.edu
Jorge Contreras
American University
4801 Massachusetts Ave. NW
Washington, DC 20016
Email: cntreras@gmail.com
Changes in revisions of this document
version 00 -> version 01
many clean ups suggested by Russ Housley
removed "informational" from section 5.1.1
version 01 -> version 02
change RFC 2026 reference in section 9 to RFC 6410
fixed multiple references to (old) section 6
Bradner & Contreras [Page 17]
Internet-Draft RFC 3979 bis April 2013
revised section 5.5 to clarify the intention, as suggested by David
Rudin
version 02 -> version 03
created a definition of "participation" in the definitions section as
suggested by multiple people
A number of changes suggested by Adrian Farrel
expanded introduction by including a copy of the abstract
fixed reference to RFC 6701
add mention of RFC 6702 to the introduction and added RFC 6702 to
the references
removed last sentence of section 5.4.2 B
removed discussion of asking for info on non-US patents from
section 13
revised 5.4.2.C
add note about inheritance to section 5.4.2.A
revise list of bullets for definition of contribution - section
1.b
added 5.5.D
fixed wording problem in 5.2.2 noted by SM
version 03 -> version 04
revised definition of "Participating in an IETF discussion or
activity" section 1.k
changed language re "foreign" patents - section 5.4.2 B
removed mention of claims in provisional applications in section 1.d
Bradner & Contreras [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-22 04:41:19 |