doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc3669.txt b/doc/rfc/rfc3669.txt
new file mode 100644
index 0000000..2320c07
--- /dev/null
+++ b/doc/rfc/rfc3669.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                            S. Brim
+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
+
+
+
+Brim                         Informational                      [Page 1]
+
+RFC 3669                   WG IPR Guidelines               February 2004
+
+
+   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
+
+
+
+
+Brim                         Informational                      [Page 2]
+
+RFC 3669                   WG IPR Guidelines               February 2004
+
+
+   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
+
+
+
+Brim                         Informational                      [Page 3]
+
+RFC 3669                   WG IPR Guidelines               February 2004
+
+
+   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.
+
+
+
+
+
+Brim                         Informational                      [Page 4]
+
+RFC 3669                   WG IPR Guidelines               February 2004
+
+
+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.
+
+
+
+Brim                         Informational                      [Page 5]
+
+RFC 3669                   WG IPR Guidelines               February 2004
+
+
+   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.
+
+
+
+
+
+
+
+Brim                         Informational                      [Page 6]
+
+RFC 3669                   WG IPR Guidelines               February 2004
+
+
+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.
+
+
+
+
+
+
+
+Brim                         Informational                      [Page 7]
+
+RFC 3669                   WG IPR Guidelines               February 2004
+
+
+   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.
+
+
+
+
+
+
+Brim                         Informational                      [Page 8]
+
+RFC 3669                   WG IPR Guidelines               February 2004
+
+
+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.
+
+
+
+Brim                         Informational                      [Page 9]
+
+RFC 3669                   WG IPR Guidelines               February 2004
+
+
+   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
+   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
+
+
+
+
+
+Brim                         Informational                     [Page 10]
+
+RFC 3669                   WG IPR Guidelines               February 2004
+
+
+   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 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 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.
+
+
+
+
+
+
+
+
+
+
+Brim                         Informational                     [Page 11]
+
+RFC 3669                   WG IPR Guidelines               February 2004
+
+
+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  License not required.
+
+   o  IPR 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 if an IPR disclosure 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.
+
+   There is a class of restriction which involves "reciprocity", in
+   which intellectual property may be licensed if the licensee is
+   willing to license its intellectual property in return.  The
+
+
+
+Brim                         Informational                     [Page 12]
+
+RFC 3669                   WG IPR Guidelines               February 2004
+
+
+   specificity of such agreements can vary, and the same or similar
+   terms may be required.  Another potential licensing restriction is
+   defensive suspension, where a licensor may revoke or suspend the
+   license if the licensee asserts a patent claim against the licensor.
+   For interpretation of any particular reciprocity or related issue,
+   consult your legal adviser.
+
+   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
+   the 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 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
+   technology increases 30 months (12 + 18) after the public disclosure
+   or use of that technology.
+
+
+
+
+
+
+Brim                         Informational                     [Page 13]
+
+RFC 3669                   WG IPR Guidelines               February 2004
+
+
+5.7.  Third-Party Disclosure of IPR Claims
+
+   It is good to notify the IETF of relevant IPR claims even when they
+   are not one's own, and [6] says to do so "as soon as possible".
+   However, anyone considering such a disclosure should do 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 at first.
+
+   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 third-party disclosures accordingly.  Working group 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 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
+   working group 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 working
+   group).
+
+   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 discloser is encouraged to
+   submit a third-party disclosure.
+
+
+
+Brim                         Informational                     [Page 14]
+
+RFC 3669                   WG IPR Guidelines               February 2004
+
+
+   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
+   working group is focusing at that time.  Don't bring IPR claims to
+   the working group's attention just in case they might be relevant in
+   a few months, but only if they have 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 author would like to acknowledge the help of the IETF IPR Working
+   Group.  The author 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.
+
+8.  References
+
+8.1.  Normative References
+
+   [1]  Huitema, C. and P. Gross, "The Internet Standards Process --
+        Revision 2", RFC 1602, March 1994.
+
+   [2]  Postel, J., "Addendum to RFC 1602 -- Variance Procedure", BCP 2,
+        RFC 1871, November 1995.
+
+   [3]  Kastenholz, F., "Variance for The PPP Connection Control
+        Protocol and The PPP Encryption Control Protocol", BCP 3, RFC
+        1915, February 1996.
+
+   [4]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+        9, RFC 2026, October 1996.
+
+
+
+
+Brim                         Informational                     [Page 15]
+
+RFC 3669                   WG IPR Guidelines               February 2004
+
+
+   [5]  Bradner, S., Ed.,  "IETF Rights in Contributions", BCP 78, RFC
+        3667, February 2004.
+
+   [6]  Bradner, S., Ed., "Intellectual Property Rights in IETF
+        Technology", BCP 79, RFC 3668, February 2004.
+
+8.2.  Informative References
+
+   [7]  Wu, T., "The SRP Authentication and Key Exchange System", RFC
+        2945, September 2000.
+
+9.  Author's Address
+
+   Scott Brim
+   Cisco Systems, Inc.
+   146 Honness Lane
+   Ithaca, NY  14850
+   USA
+
+   EMail: sbrim@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brim                         Informational                     [Page 16]
+
+RFC 3669                   WG IPR Guidelines               February 2004
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78 and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it
+   represent that it has made any independent effort to identify any
+   such rights.  Information on the procedures with respect to
+   rights in RFC documents can be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use
+   of such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository
+   at http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention
+   any copyrights, patents or patent applications, or other
+   proprietary rights that may cover technology that may be required
+   to implement this standard.  Please address the information to the
+   IETF at ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Brim                         Informational                     [Page 17]
+