[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-brim-ipr-wg-guidelines) 00 01 02 03 04 05 RFC 3669

IPR Working Group                                                S. Brim
Internet-Draft                                       Cisco Systems, Inc.
Expires: October 21, 2003                                 April 22, 2003


     Guidelines for Working Groups on Intellectual Property Issues
                    draft-ietf-ipr-wg-guidelines-03

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

   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://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 21, 2003.

Copyright Notice

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

Abstract

   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 October 21, 2003                [Page 1]


Internet-Draft             WG IPR Guidelines                  April 2003


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    The Problem  . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.    The Approach . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.    Case Studies . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.1   PPP CCP and ECP  . . . . . . . . . . . . . . . . . . . . . .  5
   4.2   IPS WG (IP Storage)  . . . . . . . . . . . . . . . . . . . .  5
   4.3   PEM and PKI issues . . . . . . . . . . . . . . . . . . . . .  6
   4.4   CDI WG (Content Distribution Internetworking)  . . . . . . .  7
   4.5   VRRP (Virtual Router Redundancy Protocol)  . . . . . . . . .  7
   4.6   Secure Shell (SecSH) . . . . . . . . . . . . . . . . . . . .  8
   4.7   IDN (Internationalized Domain Name)  . . . . . . . . . . . .  8
   5.    General Principles . . . . . . . . . . . . . . . . . . . . .  9
   5.1   Types of IPR . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.2   When to think about IPR  . . . . . . . . . . . . . . . . . . 10
   5.3   IPR as a Technology Evaluation Factor  . . . . . . . . . . . 10
   5.4   Patents versus Pending Patents Applied For . . . . . . . . . 11
   5.5   Applicability: It's Hard to Prove a Negative . . . . . . . . 12
   5.6   Licensing Terms  . . . . . . . . . . . . . . . . . . . . . . 13
   5.7   Third-Party Disclosure of IPR Claims . . . . . . . . . . . . 15
   5.7.1 Third-Party Disclosure Advice  . . . . . . . . . . . . . . . 15
   6.    Security Considerations  . . . . . . . . . . . . . . . . . . 16
   7.    Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 16
         Normative References . . . . . . . . . . . . . . . . . . . . 16
         Informative References . . . . . . . . . . . . . . . . . . . 17
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 17
         Intellectual Property and Copyright Statements . . . . . . . 18























Brim                    Expires October 21, 2003                [Page 2]


Internet-Draft             WG IPR Guidelines                  April 2003


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 the Internet 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 IPR in the
   IETF [3] and submission rights [4]. 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



Brim                    Expires October 21, 2003                [Page 3]


Internet-Draft             WG IPR Guidelines                  April 2003


   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 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 [3][4] 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 a number of "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



Brim                    Expires October 21, 2003                [Page 4]


Internet-Draft             WG IPR Guidelines                  April 2003


   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 all of 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 which it knew was patented.
   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 [5] (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 [1], in the case of PPP ECP and CCP, the IPR
   claimant balked at the requirement for specific assurances.

   Finally, with support from the working group, a variance was granted
   to the RFC 1602 procedures.  If it hadn't 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
   [6]).  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



Brim                    Expires October 21, 2003                [Page 5]


Internet-Draft             WG IPR Guidelines                  April 2003


   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

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



Brim                    Expires October 21, 2003                [Page 6]


Internet-Draft             WG IPR Guidelines                  April 2003


4.4 CDI WG (Content Distribution Internetworking)

   The CDI (Content Distribution Internetworking) 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 participants
   decided there was little chance of producing alternative technologies
   which were as useful and which did not run up against these IPR
   claims.  As usual, there was no good way to evaluate claims and
   possible licensing terms until after the technology had been
   completely specified (at the earliest).

   However, working group participants generally thought they had a good
   idea what to expect from each other with regard to licensing, and in
   fact expected few if any problems.  The expected risks were low
   enough that they thought the ultimate benefits of using the
   technologies outweighed the expected burden of the IPR issues.  The
   working group participants decided they did not need to consider IPR
   as an issue in determining which technologies to adopt.

   Lessons:

   o  Past experience with patent claimants can be used as a significant
      factor in evaluating the possible impact of IPR.  It can lead to
      enough mutual trust that concerns about licensing terms do not
      slow the working group down.


4.5 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 it went ahead with its 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.





Brim                    Expires October 21, 2003                [Page 7]


Internet-Draft             WG IPR Guidelines                  April 2003


4.6 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.7 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 WG discussion, rather than vice versa (or independent
   discovery).  The claimants were known to be following the WG'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 IPR claimant in order to



Brim                    Expires October 21, 2003                [Page 8]


Internet-Draft             WG IPR Guidelines                  April 2003


   get an explicit statement of licensing terms, preferably
   royalty-free.  By doing so they gained a better understanding of just
   which WG 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.  Of course 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 follow these
   general principles.

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][3][4].  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 October 21, 2003                [Page 9]


Internet-Draft             WG IPR Guidelines                  April 2003


   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 groups that 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.  Actual knowledge of IPR claims may therefore depend upon
   when a claimant steps forward during the course of a WG's
   deliberations.

5.3 IPR as a Technology Evaluation Factor




Brim                    Expires October 21, 2003               [Page 10]


Internet-Draft             WG IPR Guidelines                  April 2003


   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 if so 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 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 can take place under the auspices of the working group, in
   particular about relative risks of technology choices. Individual
   participants can 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



Brim                    Expires October 21, 2003               [Page 11]


Internet-Draft             WG IPR Guidelines                  April 2003


   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
   matter of public record, but details of pending 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 -- perhaps not even then.  All the IETF
   can expect regarding a pending patent is disclosure that it exists,
   the related IETF documents, and possibly the relevant IETF document
   sections and some statement about licensing terms.

5.5 Applicability: It's Hard to Prove a Negative

   Working group participants must make their own decisions about what
   level of confidence they need 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 royalty-free, or perhaps "reasonable and
   non-discriminatory".   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 prove that it is not
   covered by any IPR claim.  Anything a working group adopts may, in
   the future, turn out to be IPR-impacted, although the IPR claim may
   not be discovered until 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 issues may
   unknowingly be taken on at any time.  Absolute certainty about IPR
   claims is extremely rare.

   However, 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.




Brim                    Expires October 21, 2003               [Page 12]


Internet-Draft             WG IPR Guidelines                  April 2003


   In all cases, licensing terms are a more significant consideration
   than the validity of the IPR claims. licensing terms often do not
   limit the usefulness of the technology.  It is difficult to be sure
   about the validity of IPR claims.  If the licensing terms can be
   determined to be reasonable, then the IPR claims become much less
   important.

5.6 Licensing Terms

   Licensing terms vary across a range from no license required at all
   to prohibitive.  In general, working groups show a preference for
   technologies with IPR considerations in approximately the following
   order.  This list does not constitute a rule, and every working group
   needs to take its own circumstances into account.

   o  IPR disclosed and licensed with no restrictions.

   o  IPR licensed with no material restrictions, e.g. no trademark
      license required.

   o  IPR licensed for a particular field of use but with no other
      material restrictions, e.g. licensed solely for implementations
      complying with a standard.

   o  IPR licensed under royalty-free terms and reasonable and
      non-discriminatory restrictions.

   o  IPR licensed under reasonable and non-discriminatory restrictions.
      This may include payment of a royalty.

   o  IPR which is otherwise licensable.

   o  IPR which is not licensable, i.e. which is only available as an
      implementation.

   o  IPR which is not available under any conditions.

   Many IPR claimants do not like to publish specific terms under which
   they will issue licenses. They may use standard terms for many
   licensees, but they prefer to negotiate terms for some.  Therefore,
   do not expect any IPR disclosure statement to lay out detailed
   blanket terms for licensing.

   If an IPR disclosure statement 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 disclosure 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



Brim                    Expires October 21, 2003               [Page 13]


Internet-Draft             WG IPR Guidelines                  April 2003


   evaluating the future utility of the technology.

   There is a class of restriction which involves "reciprocity", in
   which the IPR claimant's patented technology may be used by an
   implementer of the IETF standard ("licensee") as long as the licensee
   allows the IPR claimant to use the licensee's own patented technology
   covering the standard under comparable terms (this could be called
   "bilateral" reciprocity). A "general" or "universal" reciprocity
   restriction is also possible, under which the technology is made
   available royalty-free as long as the licensee does not enforce any
   IPR claims against the licenser.

   Words such as "reasonable", "fair", and "non-discriminatory" have no
   objective legal or financial definition.  The actual licensing terms
   can vary tremendously.  Also, IPR claimants have occasionally
   asserted that there were already sufficient licenses for a particular
   technology to meet "reasonable" multisource and competitiveness
   requirements and, hence, that refusing to grant any licenses to new
   applicants was both fair and non-discriminatory.  The best way to
   find out what an IPR claimant 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 claimant.

   Despite the fact that IPR claimants 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 claimant
   toward less vagueness.  Many employers of IETF participants know that
   that IETF prefers explicit terms, and do feel pressure to produce
   them.

   If working group participants are dissatisfied with the confidence
   level they can obtain directly about licensing terms for a particular
   technology, they can possibly extrapolate from history.  In order for
   licensed technology to become a draft standard, at least two
   independent licenses need to have been issued.  If the IPR claimant
   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 everything counts, and it may be of
   some help.

   In many jurisdictions that issue patents, inventors are required to
   file patent applications within 12 months of public disclosure or use
   of a novel method or process. Since many of these jurisdictions also
   provide for publication of pending patent applications 18 months
   after a patent application is filed, the ability to determine whether
   or not claims have been made at all relating to a particular



Brim                    Expires October 21, 2003               [Page 14]


Internet-Draft             WG IPR Guidelines                  April 2003


   technology increases 30 months (12 + 18) after the public disclosure
   or use of that technology.

5.7 Third-Party Disclosure of IPR Claims

   Formal procedures for third-party disclosures are outlined in [3].
   However, anyone considering such a disclosure is encouraged to engage
   in some preliminary exploration with the affected working group(s)
   beforehand (see Section 5.7.1). third-party disclosure is a potential
   denial of service threat to the working group, and therefore it is
   good form to proceed slowly.

   Working group participants should be aware that third-party
   disclosure can be used, knowingly or unknowingly, to defocus and
   distract the working group and hinder its progress.  They should
   evaluate 3rd party disclosures accordingly.  WG chairs should be
   willing and able to discipline those they think are using the
   third-party disclosure system inappropriately. Those who think they
   are being unfairly blocked may take the matter up with the Area
   Directors and/or the IESG.

   All of the criteria for evaluating IPR claims discussed in the
   sections above apply in the case of third-party disclosures as well,
   to the extent they can be practiced.

5.7.1 Third-Party Disclosure Advice

   This subsection provides advice to those considering making
   third-party disclosures.  While not strictly required, the actions
   described here are encouraged to aid working groups in dealing with
   the possible implications of third-party disclosures. In evaluating
   what (if anything) to do in response to a third-party disclosure, a
   WG may consider the extent to which the discloser has followed this
   advice (for example, in considering whether a disclosure is intended
   primarily to defocus and distract the WG).

   In general a potential discloser should exchange mail with the
   working group chair(s) first, to open the way for discussion.  Also,
   if the potential discloser is not sure if the IPR claim applies, this
   is the time to reach some kind of agreement with the working group
   chair(s) before saying anything publicly.  After discussion with the
   working group chair(s), the potential discloser should bring the
   issue to the attention of the working group, and to the attention of
   the IPR claimant if doing so is not too difficult.  Such discussion
   should help the potential discloser to become more sure, one way or
   the other.  If the potential discloser is sure the discovered IPR
   claim applies, and the IPR claimant does not submit a first party
   disclosure itself, then the potential disclosure is encouraged to



Brim                    Expires October 21, 2003               [Page 15]


Internet-Draft             WG IPR Guidelines                  April 2003


   submit a third-party disclosure.

   Intellectual property often applies to more than one working group.
   A person thinking of making a third-party disclosure should consider
   what other working groups might be affected, and communicate with
   them in the same manner.

   Don't bring up IPR issues that are unrelated to the areas where the
   WG is focusing at that time.  Don't bring claims to the WG's
   attention just in case it might go there in a few months, only if it
   has implications for current work. Messages to the working group list
   should be substantive, and a single message should focus on a
   specific issue.  They can reference multiple claims or patents
   related to that issue.

6. Security Considerations

   This memo relates to IETF process, not any particular technology.
   There are security considerations when adopting any technology,
   whether IPR claims are asserted against it 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.

7. Acknowledgments

   The editor would like to acknowledge the help of the IETF IPR Working
   Group.  The editor would also like to thank the following for their
   extensive comments and suggestions: Robert Barr, David Black, Scott
   Bradner, Jorge Contreras, Paul Gleichauf, Keith Moore, Russell
   Nelson, Jon Peterson, Randy Presuhn, Pekka Savola, Valerie See, Bob
   Wyman, and Joe Zebarth.

Normative References

   [1]  Kastenholz, F., "Variance for The PPP Connection Control
        Protocol and The PPP Encryption Control Protocol", BCP 3, RFC
        1915, February 1996.

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

   [3]  Bradner, S., "Intellectual Property Rights in IETF Technology",
        draft-ietf-ipr-technology-rights-04 (work in progress), April
        2003.

   [4]  Bradner, S., "IETF Rights in Submissions",
        draft-ietf-ipr-submission-rights-04 (work in progress), April



Brim                    Expires October 21, 2003               [Page 16]


Internet-Draft             WG IPR Guidelines                  April 2003


        2003.

Informative References

   [5]  Huitema, C. and P. Gross, "The Internet Standards Process --
        Revision 2", RFC 1602, March 1994.

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


Author's Address

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

   EMail: sbrim@cisco.com































Brim                    Expires October 21, 2003               [Page 17]


Internet-Draft             WG IPR Guidelines                  April 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003). 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
   English.

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

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Brim                    Expires October 21, 2003               [Page 18]


Internet-Draft             WG IPR Guidelines                  April 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

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











































Brim                    Expires October 21, 2003               [Page 19]


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