Request for Comments: 3669 Cisco Systems, Inc.
Updates: 2026 February 2004
Category: Informational
Guidelines for Working Groups on Intellectual Property Issues
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This memo lays out a conceptual framework and rules of thumb useful
for working groups dealing with Intellectual Property Rights (IPR)
issues. It documents specific examples of how IPR issues have been
dealt with in the IETF.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. The Approach . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. PPP CCP and ECP. . . . . . . . . . . . . . . . . . . . . 4
4.2. IPS WG (IP Storage). . . . . . . . . . . . . . . . . . . 5
4.3. PEM and PKI issues . . . . . . . . . . . . . . . . . . . 5
4.4. VRRP (Virtual Router Redundancy Protocol). . . . . . . . 6
4.5. Secure Shell (SecSH) . . . . . . . . . . . . . . . . . . 6
4.6. IDN (Internationalized Domain Name). . . . . . . . . . . 7
5. General Principles . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Types of IPR . . . . . . . . . . . . . . . . . . . . . . 8
5.2. When to Think About IPR. . . . . . . . . . . . . . . . . 9
5.3. IPR as a Technology Evaluation Factor. . . . . . . . . . 9
5.4. Patents versus Pending Patents Applied For . . . . . . . 10
5.5. Applicability: It’s Hard to Prove a Negative . . . . . . 11
5.6. Licensing Terms. . . . . . . . . . . . . . . . . . . . . 12
5.7. Third-Party Disclosure of IPR Claims . . . . . . . . . . 14
5.7.1 Third-Party Disclosure Advice. . . . . . . . . . . 14
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16
9. Author’s Address . . . . . . . . . . . . . . . . . . . . . . . 16
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
1. Introduction
This memo lays out a conceptual framework and rules of thumb to
assist working groups dealing with IPR issues. The goal is to
achieve a balance between the needs of IPR claimants and the
implementers of IETF standards which is appropriate to current times.
As part of trying to distill out principles for dealing with IPR in
IETF working groups, it provides case studies of working group IPR
treatment. In other words, it documents the running code of the IETF
process.
This memo does not describe IPR procedures for document authors or
IPR claimants. Those are covered in two other memos, on submission
rights [5] and IPR in the IETF [6]. Rather, this memo is for working
groups that are trying to decide what to do about technology
contributions which have associated IPR claims.
2. The Problem
Traditionally the IETF has tried to avoid technologies which were
"protected" through IPR claims. However, compromises have been made
since before the IETF was born. The "common knowledge" of the IETF,
that IPR-impacted technology was anathema, has never recognized that
the Internet has run on IPR-impacted technologies from the beginning.
Nowadays the majority of the useful technologies brought to the IETF
have some sort of IPR claim associated with them.
It will always be better for the Internet to develop standards based
on technology which can be used without concern about selective or
costly licensing. However, increasingly, choosing a technology which
is not impacted by IPR over an alternative that is may produce a
weaker Internet. Sometimes there simply isn’t any technology in an
area that is not IPR-impacted. It is not always the wrong decision
to select IPR-impacted technology, if the choice is made knowingly,
after considering the alternatives and taking the IPR issues into
account.
The IETF is not a membership organization. Other standards-making
bodies may have membership agreements that member organizations must
sign and adhere to in order to participate. Membership agreements
may include strict procedures for dealing with IPR, or perhaps a
requirement that technology must be licensed royalty-free. This is
currently not possible in the IETF.
Even if the IETF had membership agreements, they would be difficult
to formulate in a way that covered IPR issues, because the IETF’s
work includes technology from other sources and because the IETF
collaborates with organizations that work with different approaches
to intellectual property. The IETF can encounter four different IPR
situations, at almost any time during the life of a document:
o A document submitter notes their (or their represented
organization’s) IPR claim regarding the contents of the document.
o A non-submitter IETF participant claims that the contents of a
document are covered by their (or their represented
organization’s) own IPR.
o An IETF participant notes IPR that is claimed by an individual or
organization with which neither an author of the document, nor the
participant noting the IPR, have an affiliation.
o An individual or organization that does not participate in the
IETF, but that monitors its activities, discovers that a document
intersects that individual’s or organization’s established or
pending intellectual property claims. It may come forward right
away, or wait and let the IETF work progress.
In working group activities, the IETF does not have detailed rules
for each situation. Working groups have essentially only one rule
they can invoke -- about individuals not participating in activities
related to a technology if they do not disclose known IPR. Beyond
that a working group can only make recommendations and requests.
Since every case is unique, and there are close to no general rules,
working groups need a great deal of freedom in dealing with IPR
issues. However, some amount of consistency is important so that
both contributors and users of eventual standards can know what to
expect.
3. The Approach
The goal of this memo is not to make rules. The goal is to give
working groups as much information as possible to make informed
decisions, and then step out of the way. The other IPR working group
memos [5][6] lay out what needs to be done once a particular piece of
technology is selected as a working group draft. However, this
doesn’t help when a working group is trying to decide whether or not
to select a technology in the first place. This third memo is
written to help in making that decision. We want to build a
conceptual framework, a new set of "common knowledge", to make it
easier for working groups to deal with intellectual property issues.
To do so, we first present "case studies" in Section 4 -- real events
that have happened in recent years, and how different working groups
dealt with them -- plus notes on possible lessons to be learned. In
Section 5, we expand on these lessons and try to extract general
principles.
4. Case Studies
The best way to know what works in dealing with IPR is to look at
past attempts to do so. The following are selected as cases from
which general lessons might be extracted. Other lessons might be
extracted from other cases, but the cases below cover the important
ones.
4.1. PPP CCP and ECP
The PPP Working Group adopted technology for PPP’s Connection Control
Protocol and Encryption Control Protocol about which an IPR
disclosure had been received. They indicated to the IESG that they
believed the patented technology was the best approach, and was
better than no standards at all.
At that time, under the policies documented in RFC 1602 [1] (the
precursor to RFC 2026), progress on any standard was to stop at the
Proposed Standard phase until specific assurances about licensing
terms could be obtained from all IPR claimants. However, as
described in RFC 1915 [3], in the case of PPP ECP and CCP, the IPR
claimant balked at the requirement for specific assurances.
In the end, with support from the working group, the variance
procedure described in RFC 1871 [2] was followed to grant an
exception to the RFC 1602 requirements. If it had not been granted,
the ECP and CCP standards could have been blocked permanently.
Lessons:
o IPR claimants, even when their intentions are good, may strongly
resist being forced to make specific public statements about
licensing terms. If explicit statements of licensing terms are
required, then the publicly stated terms will probably be
"worst-case", which would provide little useful information.
4.2. IPS WG (IP Storage)
The IPS (IP Storage) Working Group evaluated technology developed
outside of the working group, "secure remote password" (SRP, RFC 2945
[7]). At the time, there was one known IPR claim, and the proposed
licensing terms were apparently reasonable. SRP had become a
proposed standard without going through any working group, so IETF
participants may have been less likely to notice it in order to make
statements about IPR. In any case, two more possible IPR claims were
uncovered after the IPS working group had already decided to make SRP
required. One of the possible IPR claimants did not make a strong
IPR claim itself, and did not want to take the time to determine
whether it actually had a claim, though it acknowledged it might have
a claim. In both cases it was difficult to obtain concrete
information on possible licensing terms, even though words like
"reasonable" and "non-discriminatory" were used in the IPR
statements. Rumors of what they might be like did not sound good.
The working group participants took the claims, potential and
otherwise, very seriously, and decided not to use SRP after all, even
though they had already chosen it based on other criteria.
Lessons:
o IPR claims may appear at any time in the standards process.
o Take impreciseness seriously. Attempt to get clarification on
both IPR claims and licensing terms.
4.3. PEM and PKI issues
The PEM (Privacy-Enhanced Mail) Working Group wanted to use public
key technology. In the mid-90s, the basic principles of public key
infrastructure had been patented for years. The patent holder had
shown a tendency to actively enforce its rights, and to prefer
software sales to licensing. This was seen as a significant
potential issue, one which could possibly interfere with the easy
deployment of Internet technology. However, there was no alternative
technology that came close to its capabilities. Adopting an
alternative would have damaged the standard’s usefulness even more
than adopting a technology with IPR claims. The case was so
compelling that the working group participants decided to move
forward on standardizing it and even requiring it.
One factor which was noted was that the patents were mature, and
would expire within a few years. That meant that although the
patents might be significant to start with, they would not be in the
long run. This lowered the perceived risk of using the IPR-impacted
technology.
Lessons:
o IPR is just one issue in deciding whether to adopt a technology.
o IPR is not an all-or-nothing issue. There are different types and
levels of IPR protection.
o The IPR’s lifecycle phase can be a consideration.
4.4. VRRP (Virtual Router Redundancy Protocol)
The working group was standardizing VRRP based on a protocol
developed outside the IETF. The IPR claimant supported that protocol
and stated that it would license its IPR for that protocol if it
became the standard, but not for the similar protocol the working
group was developing. The working group participants decided to go
ahead and standardize the protocol developed in the working group
anyway. The IPR claimant has only claimed its patent when someone
else claimed a patent against it. There is no evidence that the
working group participants actually thought about the implications of
the IPR claim when they went ahead with their choice of protocol.
Lessons:
o IPR claims should never be disregarded without good cause. Due
diligence should be done to understand the consequences of each
claim.
4.5. Secure Shell (SecSH)
This is primarily an unfinished trademark issue, not a patent issue,
since the patent issue has been worked out outside of the IETF. The
holder of a trademark wants the IETF to stop using "SSH" in the names
and bodies of its proposed standards. The working group participants
have thought through the details of the claims, and possible
implications and risks, and decided to go ahead and continue using
the names as they are now.
Lessons:
o Working group participants can evaluate IPR claims not only for
their possible validity, but also for the risk of misjudging that
validity. The impact of honoring the IPR claim may be major or
minor.
4.6. IDN (Internationalized Domain Name)
The IDN Working Group dealt with a number of IPR claims. Several
were made which did not overlap with the technology -- the IPR
claimants said the patents were being announced just in case the
working group decided to go that way. In one case, even though a
patent was announced as purely defensive, many working group
participants investigated the claims themselves. They concluded that
it did not overlap.
In one case, an IPR claimant asserted that the working group’s
documents, and in fact the IETF as a whole, were infringing on its
rights. Individual working group participants consulted with their
legal advisers, concluded that the claims would not overlap the
working group’s developing technology, and decided that they need not
be concerned about the claims. This was reflected in the direction
the group as a whole decided to take.
In another case, patent claims were asserted that appeared to be
derived from working group discussion, rather than vice versa (or
independent discovery). The claimants were known to be following the
working group’s work when the ideas were proposed, and their patent
filing was considerably subsequent to that time.
In 2000 the IDN Working Group discovered a patent that some
participants thought might apply to one of their main drafts. If it
did, it could affect their work profoundly -- to the extent that some
suggested that if they could not work out reasonable licensing terms
with the IPR claimant they might just disband. As a group and
individually, participants corresponded with the IPR claimant in
order to get an explicit statement of licensing terms, preferably
royalty-free. By doing so they gained a better understanding of just
which working group activities were seen as infringing on the patent,
and at least some understanding of the IPR claimant’s intentions and
philosophy. Since the patent holder seemed to have an interest in
using the patent for profit, the group discussed the issues on its
mailing list. They overtly talked about how they could change their
proposed technology to avoid having to contest the patent, and the
extent to which the patent might be countered by claims of prior art.
Meanwhile, individually they were talking to their legal advisors.
Gradually, a collective opinion formed that the working group
documents did not infringe on the patent. Since then, the patent has
been ignored. However, they are keeping a watchful eye out for
continuation patents which might have already been submitted.
Lessons:
o It’s sometimes beneficial to push IPR claimants to find out what
they think their claims cover and what their licensing terms are.
o Possibilities of prior art should be considered.
o It’s all right, and sometimes beneficial, to discuss IPR claims
and gather information about possible prior art on the group list.
The results of such discussion can be considered when deciding
whether to develop a technology (but remember that neither the
IETF nor any working group takes a stand on such claims as a body,
and the group is not the best place to get legal advice).
5. General Principles
Given the case studies above, there are a few principles that working
groups can start with in dealing with IPR. Every working group needs
to develop and follow its own consensus, and actual treatments will
vary as much as they have in the past. However, every working group
also needs to take IPR seriously, and consider the needs of the
Internet community and the public at large, including possible future
implementers and users who will not have participated in the working
group process when the standardization is taking place.
5.1. Types of IPR
A primer on the different types of IPR would be large, unreliable,
and redundant with other Working Group documents [4][5][6]. For
informal exploration, see those documents and other relevant sources
on the web. Readers with more serious concerns should consult their
legal advisors. In the United States, briefly:
o Trademarks indicate the sources of goods. Service marks indicate
the sources of services. They protect the use of particular marks
or similar marks.
o Copyrights protect the expressions of ideas (not the ideas
themselves), in almost any form, and allow "fair use". Copyrights
expire but they can be renewed.
o Patents protect "inventions". They expire (utility patents expire
after 20 years), but follow-on patents can cover similar
technologies and can have nearly the same implications for use in
the Internet as the original patents.
5.2. When to Think About IPR
This memo does not describe IPR procedures for document authors or
IPR claimants. Rather, this memo is for working group participants
who are trying to decide what to do about IPR claims related to their
work. A working group as a whole needs to think about IPR issues:
o when examining a technology, and deciding whether to initiate work
on it.
o when deciding whether to adopt a draft as a working group
document.
o when choosing between two or more working group drafts that use
different technologies.
o when deciding whether to depend on a technology developed outside
the working group.
o when comparing different kinds of IPR protection.
At each of these times, the working group is strongly encouraged to
solicit disclosure of IPR claims and licensing terms. A working
group’s job will be a lot easier if IPR details are discovered early,
but it should realize that IPR claims may appear at any time.
Working groups should anticipate that an IPR claimant might choose
not to participate in the IETF, but instead to monitor from a
distance while the relevant technology is being discussed and
evaluated. A working group’s knowledge of IPR claims may therefore
depend upon when a claimant steps forward during the course of a
working group’s deliberations.
5.3. IPR as a Technology Evaluation Factor
How do you weigh IPR claims against other issues when deciding
whether to adopt a technology?
The ultimate goal of the IETF is to promote the overall health,
robustness, flexibility, and utility of the Internet infrastructure.
We base architectural decisions on our long-term extrapolations of
requirements by thinking in these terms. When considering a
particular technology, we compare it with other technologies not just
for its elegance of design in and of itself, but also for how it fits
in the bigger picture. This is done at multiple levels. It is
examined for how it fits into the overall design of the working
group’s output, how it fits into the particular Internet
infrastructure area, how it fits with work going on in other areas,
and how it fits in the long view of the Internet architecture.
Similarly, when evaluating a technology, working group participants
consider IPR claims on it (including possible copyright issues with
text describing it). The issue is not whether a particular piece of
technology is IPR-impacted -- we use IPR-impacted technology every
minute. The question is how much the IPR protection will limit the
technology’s usefulness in building a robust, highly useful Internet.
Thus, the only significant questions are: is the IPR claim relevant,
and what are the terms under which the technology can be used? When
technology is free from IPR protection the answer is easy. When it
is IPR-impacted, some licensing terms make the IPR issues
insignificant compared to the engineering issues. Other terms can
make a technology unusable even if it is perfect otherwise.
The problem with IPR as a technology evaluation factor is that it is
unlikely that a working group, as an entity, can ever claim to have
reached consensus on most IPR issues. The IETF as a whole, and a
working group as a whole, takes no stance on the validity of any IPR
claim. It would be inappropriate for a working group chair to
declare that consensus had been reached that, for example, a
company’s patent was invalid. Individual participants will need to
use whatever legal advice resources they have access to in order to
form their own individual opinions. Discussions about the validity
of IPR may take place under the auspices of the working group, in
particular about relative risks of technology choices. Individual
participants may take these discussions into account. The working
group as a body may not take a stance on validity, but it may make
choices based on perceived risk.
5.4. Patents versus Pending Patents Applied For
The IETF does not (cannot) expect IPR claimants to tell a working
group specifically how they think a particular patent applies. If a
patent has already been granted, the IETF can reasonably expect
disclosure of the patent number and possibly the relevant IETF
document sections, which will allow working group participants to
explore details of the claims. If a patent has not yet been granted
(or if knowledge of the patent is restricted, e.g., for security
reasons), significantly less information is available. In most
countries patent applications are published 18 months after they are
filed, but in the USA that can be avoided if the applicant does not
also file outside the USA. In some countries applications are a