[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-ipr-wg-guidelines

IPR                                                              S. Brim
Internet-Draft                                       Cisco Systems, Inc.
Expires: April 4, 2003                                   October 4, 2002

     Guidelines for Working Groups on Intellectual Property Issues

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   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."

   The list of current Internet-Drafts can be accessed at http://

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 4, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.


   This memo lays out a conceptual framework and rules of thumb useful
   for working groups dealing with IPR issues.  It documents specific
   examples of how IPR issues have been dealt with in the IETF.

Brim                      Expires April 4, 2003                 [Page 1]

Internet-Draft              WG IPR Guidelines               October 2002

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The Problem  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  The Approach . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Case Studies . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.1 IPS WG (IP Storage)  . . . . . . . . . . . . . . . . . . . . .  5
   4.2 PEM and PKI issues . . . . . . . . . . . . . . . . . . . . . .  5
   4.3 CDI WG (Content Distribution Internetworking)  . . . . . . . .  6
   4.4 VRRP (Virtual Router Redundancy Protocol)  . . . . . . . . . .  6
   4.5 Secure Shell (SecSH) . . . . . . . . . . . . . . . . . . . . .  7
   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 . . . . . . . . . . . . . . . . 10
   5.5 Applicability: It's Hard to Prove a Negative . . . . . . . . . 10
   5.6 No Universal License Terms . . . . . . . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
       References (Non-Normative) . . . . . . . . . . . . . . . . . . 13
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14

Brim                      Expires April 4, 2003                 [Page 2]

Internet-Draft              WG IPR Guidelines               October 2002

1. Introduction

   This memo lays out a conceptual framework and rules of thumb for
   working groups dealing with IPR issues.  The goal is to achieve a
   balance between the needs of IPR holders and the implementers of the
   Internet which is appropriate to current times.  As part of trying to
   distill out principles for dealing with IPR assertions in the IETF,
   it provides case studies of treatments of IPR issues that have
   already been worked out.  In other words, it documents the running
   code of the IETF process.

   This memo does not describe IPR procedures for document authors or
   IPR asserters.  Those are covered in two other memos coming out of
   the IPR working group, on IPR in  the IETF [5] and submitters' rights
   [6].  Rather, this memo is for working groups that are trying to
   decide what to do about IPR-encumbered technology contributions.

2. The Problem

   Traditionally the IETF has avoided technologies which were
   "encumbered" through IPR assertions.  However, compromises have been
   made since before the IETF was born.  The "common knowledge" of the
   IETF, that IPR-encumbered technology was anathema, has never dealt
   with the fact that the Internet has run on encumbered technologies
   from the beginning.  Nowadays the majority of the useful technologies
   brought to the IETF have some sort of IPR encumbrance associated with

   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 an unencumbered
   technology over an encumbered alternative may produce a significantly
   weaker Internet.  Sometimes there simply isn't any unencumbered
   technology in an area.

   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
   not possible in the IETF.

   Even if the IETF had membership agreements, they would be difficult
   to formulate in a way that covered IPR problems, because the IETF's
   work includes technology from other sources.  The IETF can encounter
   three different IPR situations:

   o  A draft is submitted noting the submitter's IPR claim.

Brim                      Expires April 4, 2003                 [Page 3]

Internet-Draft              WG IPR Guidelines               October 2002

   o  A draft is submitted that a different IETF participant feels is
      covered by their own IPR.

   o  A draft is submitted and IPR is noted, by the author or by a
      different IETF participant, that is claimed by an organization
      that does not participate in the IETF at all.

   The IETF does not have detailed rules for each situation.  The IETF
   does not force IPR-related behavior on anyone.  It only sets criteria
   for a technology document becoming an Internet standard.  Working
   groups have essentially only one rule they can invoke, (about not
   participating in activities related to a technology if you do not
   disclose known IPR).  Other than that a working group only has
   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

3. The Approach

   The IETF does not limit itself to IPR-free technology.  In fact, at
   this second you are using a number of IPR-encumbered technologies,
   just to fetch and read this memo.

   The organizing principle of this memo 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 (see the IPR
   Working Group charter page [1]) lay out what needs to be done once a
   particular piece of technology is selected as a working group draft.
   That doesn't help when a working group is trying to decide whether to
   select a technology or not in the first place.  Thus this third memo.
   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 to be learned and try to
   extract general principles.

4. Case Studies

   The best way to know what works is to look at past attempts at
   dealing with IPR.  The following are selected as cases from which

Brim                      Expires April 4, 2003                 [Page 4]

Internet-Draft              WG IPR Guidelines               October 2002

   general lessons might be extracted.

4.1 IPS WG (IP Storage)

   The IPS Working Group evaluated technology developed outside of the
   working group, "secure remote password" (SRP, RFC2945 [4]).  At the
   time, there was one known IPR assertion, 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 holders did not make a strong IPR assertion
   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.
   Also, in both cases it was difficult to obtain information on
   possible licensing terms, even though words like reasonable and non-
   discriminatory were used in IPR statements, and rumors of what they
   might be did like not sound good.  The working group took the
   assertions, potential and otherwise, very seriously, and decided not
   to use SRP after all, even though they had already chosen it based on
   other criteria.


   o  IPR assertions 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.2 PEM and PKI issues

   PEM (Privacy-Enhanced Mail) 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 encumbrance, one
   which could possibly interfere with the easy development of the
   Internet.  However, there was no alternative technology that came
   close to its capabilities.  Adopting an alternative would have
   damaged the Internet's health and flexibility even more than adopting
   a technology with IPR encumbrance.  The case was so compelling that
   the working group 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 impact might be significant to start with, it would not
   be in the long run.  This lowered the perceived risk of using the

Brim                      Expires April 4, 2003                 [Page 5]

Internet-Draft              WG IPR Guidelines               October 2002

   encumbered technology.


   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 encumbrance.

   o  The IPR's lifecycle phase can be a consideration.

4.3 CDI WG (Content Distribution Internetworking)

   The CDI Working Group laid out an overall architecture and found that
   a number of included technologies had IPR claims associated with
   them, based on work done before the working group was started.  The
   working group decided there was little chance of producing
   alternative technologies which were as useful and which did not run
   up against these IPR assertions.  As usual, there was no good way to
   evaluate assertions and possible licensing terms until after the
   technology had been completely specified (at the earliest).

   Working group participants generally thought they had a good idea
   what to expect from each other, and that the ultimate benefits of
   using the technologies outweighed their encumbrance.  The working
   group decided not to consider IPR as an issue at all in determining
   which technologies to adopt.


   o  Past experience can be used as a significant factor in evaluating
      the possible impact of IPR.

4.4 VRRP (Virtual Router Redundancy Protocol)

   The working group was standardizing VRRP based on a protocol
   developed outside the IETF.  The IPR holder 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 decided to go ahead and
   standardize its protocol anyway.  The IPR holder has only asserted
   its patent when someone else asserted a patent against it.  There is
   no evidence that the working group actually thought about the
   implications of the IPR when it went ahead with its choice of

Brim                      Expires April 4, 2003                 [Page 6]

Internet-Draft              WG IPR Guidelines               October 2002


   o  IPR assertions should never be disregarded without good cause.
      Due diligence should be done to understand the consequences of
      each assertion.

4.5 Secure Shell (SecSH)

   This was primarily a trademark issue, not a patent issue, since the
   patent issue had been worked out outside of the IETF.  The holder of
   a trademark wanted the IETF to stop using "SSH" in the names and text
   of its proposed standards.  The working group 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.
   This issue is still being worked through.


   o  The working group can evaluate IPR assertions 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

4.6 IDN (Internationalized Domain Name)

   The IDN working group dealt with a number of IPR assertions.  Several
   were made which did not overlap with the technology -- the IPR
   asserters 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, the working group
   participants investigated the claims themselves.  As a group, they
   concluded that it did not overlap.

   For a time, one of the working group chairs worked for a company that
   intended to assert a patent but had not done so yet.  He had to be
   very careful not to participate in discussions pertaining to that
   patent, or to guide the working group toward the technology he had an
   interest in.

   In one case, an IPR claimer 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 to ignore the
   claims.  This was reflected in the direction the group as a whole
   decided to take.

Brim                      Expires April 4, 2003                 [Page 7]

Internet-Draft              WG IPR Guidelines               October 2002

   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 holder they might just disband.  As a group and
   individually, participants corresponded with IPR holder in order to
   get an explicit statement of licensing terms, preferably royalty-
   free.  By doing so they gained at least some understanding of the IPR
   holder'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.  Slowly, 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.


   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  It's all right, and sometimes beneficial, to discuss IPR claims on
      the group list (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).

   o  Possibilities of prior art should be considered.

5. General Principles

   Given the case studies above, here are a few principles that working
   groups can start with in dealing with IPR.  Of course every working
   group needs to follow its own consensus, and actual treatments will
   vary as much as they have in the past.

5.1 Types of IPR

   A primer on the different types of IPR would be large, unreliable,
   and redundant with other Working Group documents [2][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:

Brim                      Expires April 4, 2003                 [Page 8]

Internet-Draft              WG IPR Guidelines               October 2002

   o  Trademarks indicate the sources of goods.  Servicemarks 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 asserters.  Rather, this memo is for working groups that are
   trying to decide what to do about IPR-encumbered technology
   contributions.  A working group as a whole (as opposed to individual
   contributors or IPR holders) 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

   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 encumbrances.

   At each of these times, the working group should solicit disclosure
   of IPR assertions and licensing terms.  A working group's job will be
   a lot easier if IPR details are discovered early.

5.3 IPR as a Technology Evaluation Factor

   How do you weigh IPR assertions 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

Brim                      Expires April 4, 2003                 [Page 9]

Internet-Draft              WG IPR Guidelines               October 2002

   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, a working group considers
   IPR claims on it.  The issue is not whether a particular piece of
   technology is "encumbered" -- we use encumbered technology every
   minute.  The question is how much an encumbrance 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 if so what are the terms under which the technology can be used?
   When technology is encumbrance-free the answer is easy.  When it is
   IPR-encumbered, some terms make the encumbrance insignificant
   compared to the engineering issues.  Other terms can make a
   technology unusable even if it is perfect otherwise.

5.4 Patents versus Pending Patents

   The IETF does not (cannot) expect IPR asserters 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, which will allow working group
   participants to explore details of the claims.  If a patent has not
   yet been granted, significantly less information is available.  In
   most countries patent applications are published 18 months after they
   are filed, but in the USA that is optional.  Details of pending
   patent claims can be modified at any time by the claim submitter
   before the patent is granted.  It is not known before then what
   rights will actually be granted.  Finally, rights can be contested in
   court, and nothing is final until the courts decide.  All the IETF
   can expect regarding a pending patent is disclosure that it exists
   and possibly some statement about licensing terms.

5.5 Applicability: It's Hard to Prove a Negative

   A working group needs to make its own decision about what level of
   confidence it needs as to whether IPR is applicable.  However,
   perfect knowledge is not a worthwhile goal.

   In general, a working group should strive to find out about all IPR
   claims related to technologies it is considering, and at least the
   general facts about licensing terms for each case -- for example
   whether the terms will be "reasonable and non-discriminatory".

Brim                      Expires April 4, 2003                [Page 10]

Internet-Draft              WG IPR Guidelines               October 2002

   Working group participants should also investigate possibilities of
   prior art which would counter the IPR claims.  However, even if the
   working group participants do exhaustive searches, both externally
   and internally to their employers, it is impossible to prove that a
   particular technology is not covered by a particular IPR claim, let
   alone proving that it is not covered by any IPR claim.  Anything a
   working group adopts may, in the future, turn out to be encumbered,
   years later.  Claims are open to interpretation even after rights are
   granted.  Drafts can be very fluid, even up to the time of last call,
   and IPR encumbrances may unknowingly be taken on at any time.

   The level of confidence needed to consider IPR when evaluating a
   technology is often not hard to get to.  There are cases where risk
   is high (e.g.  where licensing terms may be onerous) and thus a high
   level of confidence about applicability is needed, but history shows
   that most of the time "rough" confidence is good enough.  In any
   case, perfect confidence is usually impossible.

5.6 No Universal License Terms

   Licensing terms vary continuously across a range from prohibitive to
   no license at all.  In general there are four classes of situation
   which will be encountered.

   o  No license - licenses per se are not available.  Local
      regulations, if any, apply.

   o  Public domain - the technology is explicitly made available to
      all, without any IPR encumbrance.

   o  General "free" license - the technology is made available free of
      charge.  There is a form of this license which invokes
      "reciprocity", in which the technology may be used as long as the
      licensee allows the IPR holder to use the licensee's technology in
      the same area under comparable terms.  A requirement for general
      reciprocity is also possible, under which the technology is made
      available as long as the licensee does not enforce any IPR claims
      against the licenser.

   o  "Reasonable and non-discriminatory" (RAND) terms - the license is
      granted based on some terms which may include reciprocity.  The
      terms can vary tremendously.  Even when IPR assertions do use
      words such as "reasonable", "fair", and "non-discriminatory",
      working groups should keep in mind that these words have no
      objective legal definition, at least not in this context.

   Many IPR holders do not like to publish explicit, specific terms
   under which they will issue licenses.  They may use standard terms

Brim                      Expires April 4, 2003                [Page 11]

Internet-Draft              WG IPR Guidelines               October 2002

   for many licensees, but they prefer to negotiate terms for some.
   Therefore, do not expect any IPR claim to lay out detailed blanket
   terms for licensing.

   Vaguer terms are not necessarily better or worse than more specific
   terms.  If an IPR assertion lists only vague terms, that doesn't mean
   the terms that will be offered in individual licenses will be any
   worse than those offered in an IPR assertion that makes very specific
   statements.  Obviously, if an IPR claimant refuses to suggest any
   terms at all, the working group is going to have trouble evaluating
   the future utility of the technology.

   Recall that words such as "reasonable", "fair", and "non-
   discriminatory" have no objective legal definition.  The best way to
   find out what an IPR holder really means by those terms is to ask,
   explicitly.  It also helps to gather knowledge about licenses
   actually issued, for that technology or for others, and about other
   experiences with the IPR holder.

   Despite the fact that IPR holders often don't like to publish
   explicit terms, there are levels of vagueness, and individuals and
   even working groups can sometimes successfully push an IPR holder
   toward less vagueness.  The employers of IETF participants all know
   that that IETF prefers explicit terms, and do feel pressure to
   produce them.

   If a working group is dissatisfied with the confidence level it can
   obtain directly about licensing terms for a particular technology, it
   can possibly extrapolate from history.  As part of the standards
   process as described in RFC2026 [2], in order for licensed technology
   to become a draft standard, at least two independent licenses need to
   have been issued.  If the IPR holder for the technology the working
   group is considering has licensed other technology in the past, there
   is a record of the sorts of terms they are willing to grant, at least
   in those two specific cases.  This sort of thing is weak but if
   everything counts, it may be some indication.

6. Security Considerations

   This memo relates to IETF process, not any particular technology.
   There are security considerations when adopting any technology,
   whether IPR-encumbered 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 they are not issues of
   security with IPR procedures.

   There may be security issues with procedures for dealing with IPR,
   but those are not technical security issues.  They have more to do

Brim                      Expires April 4, 2003                [Page 12]

Internet-Draft              WG IPR Guidelines               October 2002

   with unintentionally revealing corporate intellectual property
   through human activity than risking anything when using a protocol.

References (Non-Normative)

   [1]  IETF, "IPR Working Group web page", 2002, <http://www.ietf.org/

   [2]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
        9, RFC 2026, October 1996.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [4]  Wu, T., "The SRP Authentication and Key Exchange System", RFC
        2945, September 2000.

   [5]  Bradner, S., "Intellectual Property Rights in IETF Technology",
        draft-bradner-ipr-technology-00 (work in progress), July 2002.

   [6]  Bradner, S., "IETF Rights in Submissions", draft-bradner-
        submission-rights-00 (work in progress), June 2002.

Author's Address

   Scott Brim
   Cisco Systems, Inc.
   146 Honness Lane
   Ithaca, NY  14850

   EMail: sbrim@cisco.com

Brim                      Expires April 4, 2003                [Page 13]

Internet-Draft              WG IPR Guidelines               October 2002

Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Brim                      Expires April 4, 2003                [Page 14]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/