GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-11+1


rfc:rfc3669

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3669.txt · Last modified: 2004/02/12 20:29 (external edit)