diff options
Diffstat (limited to 'doc/rfc/rfc3669.txt')
| -rw-r--r-- | doc/rfc/rfc3669.txt | 955 |
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] + |