idnits 2.17.1 draft-ietf-ipr-wg-guidelines-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1, 2003) is 7726 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 678, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-12) exists of draft-ietf-ipr-technology-rights-01 == Outdated reference: A later version (-08) exists of draft-ietf-ipr-submission-rights-01 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPR Working Group S. Brim 3 Internet-Draft Cisco Systems, Inc. 4 Expires: August 30, 2003 March 1, 2003 6 Guidelines for Working Groups on Intellectual Property Issues 7 draft-ietf-ipr-wg-guidelines-02 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on August 30, 2003. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This memo lays out a conceptual framework and rules of thumb useful 38 for working groups dealing with IPR issues. It documents specific 39 examples of how IPR issues have been dealt with in the IETF. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 44 2. The Problem . . . . . . . . . . . . . . . . . . . . . . . . 3 45 3. The Approach . . . . . . . . . . . . . . . . . . . . . . . . 4 46 4. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . 5 47 4.1 IPS WG (IP Storage) . . . . . . . . . . . . . . . . . . . . 5 48 4.2 PEM and PKI issues . . . . . . . . . . . . . . . . . . . . . 5 49 4.3 CDI WG (Content Distribution Internetworking) . . . . . . . 6 50 4.4 VRRP (Virtual Router Redundancy Protocol) . . . . . . . . . 7 51 4.5 Secure Shell (SecSH) . . . . . . . . . . . . . . . . . . . . 7 52 4.6 IDN (Internationalized Domain Name) . . . . . . . . . . . . 7 53 5. General Principles . . . . . . . . . . . . . . . . . . . . . 9 54 5.1 Types of IPR . . . . . . . . . . . . . . . . . . . . . . . . 9 55 5.2 When to think about IPR . . . . . . . . . . . . . . . . . . 9 56 5.3 IPR as a Technology Evaluation Factor . . . . . . . . . . . 10 57 5.4 Patents versus Pending Patents Applied For . . . . . . . . . 11 58 5.5 Applicability: It's Hard to Prove a Negative . . . . . . . . 11 59 5.6 Licensing Terms . . . . . . . . . . . . . . . . . . . . . . 12 60 5.7 Third Party Disclosure . . . . . . . . . . . . . . . . . . . 14 61 5.7.1 Third Party Disclosure Advice . . . . . . . . . . . . . . . 14 62 6. Security Considerations . . . . . . . . . . . . . . . . . . 15 63 Normative References . . . . . . . . . . . . . . . . . . . . 15 64 Informative References . . . . . . . . . . . . . . . . . . . 16 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . 16 66 Intellectual Property and Copyright Statements . . . . . . . 17 68 1. Introduction 70 This memo lays out a conceptual framework and rules of thumb for 71 working groups dealing with IPR issues. The goal is to achieve a 72 balance between the needs of IPR claimants and the implementers of 73 the Internet which is appropriate to current times. As part of 74 trying to distill out principles for dealing with IPR in IETF working 75 groups, it provides case studies of treatments of IPR issues that 76 have already been worked out. In other words, it documents the 77 running code of the IETF process. 79 This memo does not describe IPR procedures for document authors or 80 IPR claimants. Those are covered in two other memos, on IPR in the 81 IETF [4] and submitters' rights [5]. Rather, this memo is for working 82 groups that are trying to decide what to do about IPR-protected 83 technology contributions. 85 2. The Problem 87 Traditionally the IETF has tried to avoid technologies which were 88 "protected" through IPR claims. However, compromises have been made 89 since before the IETF was born. The "common knowledge" of the IETF, 90 that IPR-protected technology was anathema, has never dealt with the 91 fact that the Internet has run on IPR-protected technologies from the 92 beginning. Nowadays the majority of the useful technologies brought 93 to the IETF have some sort of IPR claim associated with them. 95 It will always be better for the Internet to develop standards based 96 on technology which can be used without concern about selective or 97 costly licensing. However, increasingly, choosing a technology which 98 is not protected by IPR over an alternative that is may produce a 99 weaker Internet. Sometimes there simply isn't any technology in an 100 area that is not IPR-protected. It is not always the wrong choice to 101 select IPR-protected technology, if the choice is made knowingly, 102 after considering the alternatives and taking the IPR issues into 103 account. 105 The IETF is not a membership organization. Other standards making 106 bodies may have membership agreements that member organizations must 107 sign and adhere to in order to participate. Membership agreements 108 may include strict procedures for dealing with IPR, or perhaps a 109 requirement that technology must be licensed royalty-free. This is 110 currently not possible in the IETF. 112 Even if the IETF had membership agreements, they would be difficult 113 to formulate in a way that covered IPR problems, because the IETF's 114 work includes technology from other sources and because the IETF 115 collaborates with organizations that work with different approaches 116 to intellectual property. The IETF can encounter four different IPR 117 situations, at almost any time during the life of a document: 119 o A document submitter notes its IPR claim regarding the contents of 120 the document. 122 o An IETF participant claims that the contents of a document are 123 covered by their own IPR. 125 o IPR is noted, by the author of a document or by a different IETF 126 participant, that is claimed by an individual or organization with 127 which neither an author of the document nor the participant noting 128 the IPR have an affiliation. 130 o An individual or organization that does not participate in the 131 IETF, but that monitors its activities, discovers that a document 132 intersects that individual's or organization's established or 133 pending intellectual property claims. It may come forward right 134 away, or wait and let the IETF work progress. 136 In working group activites, the IETF does not have detailed rules for 137 each situation. Working groups have essentially only one rule they 138 can invoke -- about individuals not participating in activities 139 related to a technology if they do not disclose known IPR. Beyond 140 that a working group can only make recommendations and requests. 142 Since every case is unique, and there are close to no general rules, 143 working groups need a great deal of freedom in dealing with IPR 144 issues. However, some amount of consistency is important so that 145 both contributors and users of eventual standards can know what to 146 expect. 148 3. The Approach 150 The goal of this memo is not to make rules. It is to give working 151 groups as much information as possible to make informed decisions, 152 and then step out of the way. The other IPR working group memos (see 153 the IPR Working Group charter page [1]) lay out what needs to be done 154 once a particular piece of technology is selected as a working group 155 draft. That doesn't help when a working group is trying to decide 156 whether to select a technology or not in the first place. Thus this 157 third memo. We want to build a conceptual framework, a new set of 158 "common knowledge", to make it easier for working groups to deal with 159 intellectual property issues. 161 To do so, we first present "case studies" in Section 4 -- real events 162 that have happened in recent years, and how different working groups 163 dealt with them -- plus notes on possible lessons to be learned. In 164 Section 5, we expand on these lessons and try to extract general 165 principles. 167 4. Case Studies 169 The best way to know what works in dealing with IPR is to look at 170 past attempts to do so. The following are selected as cases from 171 which general lessons might be extracted. Other lessons might be 172 extracted from other cases, but the cases below cover all of the 173 important ones. 175 4.1 IPS WG (IP Storage) 177 The IPS Working Group evaluated technology developed outside of the 178 working group, "secure remote password" (SRP, RFC2945 [6]). At the 179 time, there was one known IPR claim, and the proposed licensing terms 180 were apparently reasonable. SRP had become a proposed standard 181 without going through any working group, so IETF participants may 182 have been less likely to notice it in order to make statements about 183 IPR. In any case, two more possible IPR claims were uncovered after 184 the IPS working group had already decided to make SRP required. One 185 of the possible IPR claimants did not make a strong IPR claim itself, 186 and did not want to take the time to determine whether it actually 187 had a claim, though it acknowledged it might have a claim. In both 188 cases it was difficult to obtain concrete information on possible 189 licensing terms, even though words like "reasonable" and 190 "non-discriminatory" were used in the IPR statements. Rumors of what 191 they might be like did not sound good. The working group 192 participants took the claims, potential and otherwise, very 193 seriously, and decided not to use SRP after all, even though they had 194 already chosen it based on other criteria. 196 Lessons: 198 o IPR claims may appear at any time in the standards process. 200 o Take impreciseness seriously. Attempt to get clarification on 201 both IPR claims and licensing terms. 203 4.2 PEM and PKI issues 205 PEM (Privacy-Enhanced Mail) wanted to use public key technology. In 206 the mid-90s, the basic principles of public key infrastructure had 207 been patented for years. The patent holder had shown a tendency to 208 actively enforce its rights, and to prefer software sales to 209 licensing. This was seen as a significant potential issue, one which 210 could possibly interfere with the easy development of the Internet. 212 However, there was no alternative technology that came close to its 213 capabilities. Adopting an alternative would have damaged the 214 Internet's health and flexibility even more than adopting a 215 technology with IPR claims. The case was so compelling that the 216 working group participants decided to move forward on standardizing 217 it and even requiring it. 219 One factor which was noted was that the patents were mature, and 220 would expire within a few years. That meant that although the impact 221 might be significant to start with, it would not be in the long run. 222 This lowered the perceived risk of using the IPR-protected 223 technology. 225 Lessons: 227 o IPR is just one issue in deciding whether to adopt a technology. 229 o IPR is not an all or nothing issue. There are different types and 230 levels of IPR protection. 232 o The IPR's lifecycle phase can be a consideration. 234 4.3 CDI WG (Content Distribution Internetworking) 236 The CDI Working Group laid out an overall architecture and found that 237 a number of included technologies had IPR claims associated with 238 them, based on work done before the working group was started. The 239 working group participants decided there was little chance of 240 producing alternative technologies which were as useful and which did 241 not run up against these IPR claims. As usual, there was no good way 242 to evaluate claims and possible licensing terms until after the 243 technology had been completely specified (at the earliest). 245 Working group participants generally thought they had a good idea 246 what to expect from each other, and that the ultimate benefits of 247 using the technologies outweighed the IPR issues. The working group 248 participants decided not to consider IPR as an issue at all in 249 determining which technologies to adopt. 251 Lessons: 253 o Past experience can be used as a significant factor in evaluating 254 the possible impact of IPR. 256 4.4 VRRP (Virtual Router Redundancy Protocol) 258 The working group was standardizing VRRP based on a protocol 259 developed outside the IETF. The IPR claimant supported that protocol 260 and stated that it would license its IPR for that protocol if it 261 became the standard, but not for the similar protocol the working 262 group was developing. The working group participants decided to go 263 ahead and standardize the protocol developed in the working group 264 anyway. The IPR claimant has only claimed its patent when someone 265 else claimed a patent against it. There is no evidence that the 266 working group participants actually thought about the implications of 267 the IPR claim when it went ahead with its choice of protocol. 269 Lessons: 271 o IPR claims should never be disregarded without good cause. Due 272 diligence should be done to understand the consequences of each 273 claim. 275 4.5 Secure Shell (SecSH) 277 This was primarily a trademark issue, not a patent issue, since the 278 patent issue had been worked out outside of the IETF. The holder of 279 a trademark wanted the IETF to stop using "SSH" in the names and 280 bodies of its proposed standards. The working group participants 281 thought through the details of the claims, and possible implications 282 and risks, and decided to go ahead and continue using the names as 283 they are now. This issue is still being worked through. 285 Lessons: 287 o Working group participants can evaluate IPR claims not only for 288 their possible validity, but also for the risk of misjudging that 289 validity. The impact of honoring the IPR claim may be major or 290 minor. 292 4.6 IDN (Internationalized Domain Name) 294 The IDN working group dealt with a number of IPR claims. Several were 295 made which did not overlap with the technology -- the IPR claimants 296 said the patents were being announced just in case the working group 297 decided to go that way. In one case, even though a patent was 298 announced as purely defensive, many working group participants 299 investigated the claims themselves. They concluded that it did not 300 overlap. 302 In one case, an IPR claimer asserted that the working group's 303 documents, and in fact the IETF as a whole, were infringing on its 304 rights. Individual working group participants consulted with their 305 legal advisers, concluded that the claims would not overlap the 306 working group's developing technology, and decided to ignore the 307 claims. This was reflected in the direction the group as a whole 308 decided to take. 310 In another case, patent claims were asserted that appeared to be 311 derived from WG discussion and impact, rather than vice versa (or 312 independent discovery). The claimants were known to be following the 313 WG's work when the ideas were proposed, and their patent filing was 314 considerably subsequent to that time. 316 In 2000 the IDN working group discovered a patent that some 317 participants thought might apply to one of their main drafts. If it 318 did, it could affect their work profoundly -- to the extent that some 319 suggested that if they could not work out reasonable licensing terms 320 with the IPR claimant they might just disband. As a group and 321 individually, participants corresponded with IPR claimant in order to 322 get an explicit statement of licensing terms, preferably 323 royalty-free. By doing so they gained a better understanding of just 324 which WG activities were seen as infringing on the patent, and at 325 least some understanding of the IPR claimant's intentions and 326 philosophy. Since the patent holder seemed to have an interest in 327 using the patent for profit, the group discussed the issues on its 328 mailing list. They overtly talked about how they could change their 329 proposed technology to avoid having to contest the patent, and the 330 extent to which the patent might be countered by claims of prior art. 331 Meanwhile, individually they were talking to their legal advisors. 332 Gradually, a collective opinion formed that the working group 333 documents did not infringe on the patent. Since then, the patent has 334 been ignored. However, they are keeping a watchful eye out for 335 continuation patents which might have already been submitted. 337 Lessons: 339 o It's sometimes beneficial to push IPR claimants to find out what 340 they think their claims cover and what their licensing terms are. 342 o Possibilities of prior art should be considered. 344 o It's all right, and sometimes beneficial, to discuss IPR claims 345 and gather information about possible prior art on the group list. 346 The results of such discussion can be considered when deciding 347 whether to develop a technology (but remember that neither the 348 IETF nor any working group takes a stand on such claims as a body, 349 and the group is not the best place to get legal advice). 351 5. General Principles 353 Given the case studies above, here are a few principles that working 354 groups can start with in dealing with IPR. Of course every working 355 group needs to follow its own consensus, and actual treatments will 356 vary as much as they have in the past. However, every working group 357 also needs to take IPR seriously, and follow these general 358 principles. 360 5.1 Types of IPR 362 A primer on the different types of IPR would be large, unreliable, 363 and redundant with other Working Group documents [2][4][5]. For 364 informal exploration, see those documents and other relevant sources 365 on the web. Readers with more serious concerns should consult their 366 legal advisors. In the United States, briefly: 368 o Trademarks indicate the sources of goods. Servicemarks indicate 369 the sources of services. They protect the use of particular marks 370 or similar marks. 372 o Copyrights protect the expressions of ideas (not the ideas 373 themselves), in almost any form, and allow "fair use". Copyrights 374 expire but they can be renewed. 376 o Patents protect "inventions". They expire (utility patents expire 377 after 20 years), but follow-on patents can cover similar 378 technologies and can have nearly the same implications for use in 379 the Internet as the original patents. 381 5.2 When to think about IPR 383 This memo does not describe IPR procedures for document authors or 384 IPR claimants. Rather, this memo is for working groups that are 385 trying to decide what to do about IPR claims related to their work. 386 A working group as a whole needs to think about IPR issues: 388 o when examining a technology, and deciding whether to initiate work 389 on it. 391 o when deciding whether to adopt a draft as a working group 392 document. 394 o when choosing between two or more working group drafts that use 395 different technologies. 397 o when deciding whether to depend on a technology developed outside 398 the working group. 400 o when comparing different kinds of IPR protection. 402 At each of these times, the working group is strongly encouraged to 403 solicit disclosure of IPR claims and licensing terms. A working 404 group's job will be a lot easier if IPR details are discovered early, 405 but it should realize that IPR claims may appear at any time. 406 Working groups should anticipate that an IPR claimant might choose 407 not to participate in the IETF, but instead to monitor from a 408 distance while the relevant technology is being discussed and 409 evaluated. Actual IPR claims may therefore depend upon when a 410 claimant steps forward during the course of a WG's deliberations. 412 5.3 IPR as a Technology Evaluation Factor 414 How do you weigh IPR claims against other issues when deciding 415 whether to adopt a technology? 417 The ultimate goal of the IETF is to promote the overall health, 418 robustness, flexibility and utility of the Internet infrastructure. 419 We base architectural decisions on our long-term extrapolations of 420 requirements by thinking in these terms. When considering a 421 particular technology, we compare it with other technologies not just 422 for its elegance of design in and of itself, but also for how it fits 423 in the bigger picture. This is done at multiple levels. It is 424 examined for how it fits into the overall design of the working 425 group's output, how it fits into the particular Internet 426 infrastructure area, how it fits with work going on in other areas, 427 and how it fits in the long view of the Internet architecture. 429 Similarly, when evaluating a technology, working group participants 430 consider IPR claims on it (including possible copyright issues with 431 text describing it). The issue is not whether a particular piece of 432 technology is IPR-protected -- we use IPR-protected technology every 433 minute. The question is how much the IPR protection will limit the 434 technology's usefulness in building a robust, highly useful Internet. 435 Thus, the only significant questions are: is the IPR claim relevant, 436 and if so what are the terms under which the technology can be used? 437 When technology is free from IPR protection the answer is easy. When 438 it is IPR-protected, some terms make the IPR issues insignificant 439 compared to the engineering issues. Other terms can make a 440 technology unusable even if it is perfect otherwise. 442 The problem with IPR as a technology evaluation factor is that it is 443 unlikely that a working group, as an entity, can ever claim to have 444 reached consensus on most IPR issues. The IETF as a whole, and a 445 working group as a whole, takes no stance on the validity of any IPR 446 claim. It would be inappropriate for a working group chair to 447 declare that consensus had been reached that, for example, a 448 company's patent was invalid. Individual participants will need to 449 use whatever legal advice resources they have access to to form their 450 own individual opinions. Discussions about the validity of IPR can 451 take place under the auspices of the working group, in particular 452 about relative risks of technology choices. Individual participants 453 can take these discussions into account. The working group as a body 454 may not take a stance on validity, but it may make choices based on 455 perceived risk. 457 5.4 Patents versus Pending Patents Applied For 459 The IETF does not (cannot) expect IPR claimants to tell a working 460 group specifically how they think a particular patent applies. If a 461 patent has already been granted, the IETF can reasonably expect 462 disclosure of the patent number and possibly the relevant document 463 sections, which will allow working group participants to explore 464 details of the claims. If a patent has not yet been granted (or if 465 knowledge of the patent is restricted, e.g. for security reasons), 466 significantly less information is available. In most countries 467 patent applications are published 18 months after they are filed, but 468 in the USA that can be avoided if the applicant does not also file 469 outside the USA. In some countries applications are a matter of 470 public record, but details of pending claims can be modified at any 471 time by the claim submitter before the patent is granted. It is not 472 known before then what rights will actually be granted. Finally, 473 rights can be contested in court, and nothing is final until the 474 courts decide -- perhaps not even then. All the IETF can expect 475 regarding a pending patent is disclosure that it exists, the related 476 documents, and possibly specific section numbers and some statement 477 about licensing terms. 479 5.5 Applicability: It's Hard to Prove a Negative 481 Working group participants must make their own decisions about what 482 level of confidence they need as to whether IPR is applicable. 483 However, perfect knowledge is not a worthwhile goal. 485 In general, a working group should strive to find out about all IPR 486 claims related to technologies it is considering, and at least the 487 general facts about licensing terms for each case -- for example 488 whether the terms will be royalty-free, or perhaps "reasonable and 489 non-discriminatory". Working group participants should also 490 investigate possibilities of prior art which would counter the IPR 491 claims. However, even if the working group participants do 492 exhaustive searches, both externally and internally to their 493 employers, it is impossible to prove that a particular technology is 494 not covered by a particular IPR claim, let alone proving that it is 495 not covered by any IPR claim. Anything a working group adopts may, 496 in the future, turn out to be IPR-protected, although the IPR claim 497 may not be discovered until years later. Claims are open to 498 interpretation even after rights are granted. Drafts can be very 499 fluid, even up to the time of last call, and IPR issues may 500 unknowingly be taken on at any time. Absolute certainty about IPR 501 claims is extremely rare. 503 However, the level of confidence needed to consider IPR when 504 evaluating a technology is often not hard to get to. There are cases 505 where risk is high (e.g. where licensing terms may be onerous) and 506 thus a high level of confidence about applicability is needed, but 507 history shows that most of the time "rough" confidence is good 508 enough. In any case, perfect confidence is usually impossible. 510 In all cases, licensing terms are a more significant consideration 511 than the validity of the IPR claims. Often, licensing terms are 512 reasonable and do not limit the usefulness of the technology. It is 513 difficult to be sure about the validity of IPR claims. If the 514 licensing terms can be determined to be reasonable, then the IPR 515 claims become much less important. 517 5.6 Licensing Terms 519 Licensing terms vary across a range from no license required at all 520 to prohibitive. In general, working groups show a preference for 521 technologies with IPR considerations in approximately the following 522 order. This list does not constitute a rule, and every working group 523 needs to take its own circumstances into account. 525 o Technology which has been publicly disclosed for more than one 526 year, with no known IPR claims. 528 o Technology which has been publicly disclosed, with no known IPR 529 claims. 531 o IPR disclosed and licensed with no restrictions. 533 o IPR licensed with no material restrictions, e.g. no trademark 534 license required. 536 o IPR licensed for a particular field of use but no other material 537 restrictions, e.g. licensed solely for implementations complying 538 with a standard. 540 o IPR licensed under openly-specified reasonable and 541 non-discriminatory restrictions. This may include payment of a 542 royalty. 544 o IPR which is otherwise licensable. 546 o IPR which is not licensable, i.e. which is only available as an 547 implementation. 549 o IPR which is not available under any conditions. 551 Many IPR claimants do not like to publish specific terms under which 552 they will issue licenses. They may use standard terms for many 553 licensees, but they prefer to negotiate terms for some. Therefore, 554 do not expect any IPR disclosure statement to lay out detailed 555 blanket terms for licensing. 557 If an IPR disclosure statement lists only vague terms, that doesn't 558 mean the terms that will be offered in individual licenses will be 559 any worse than those offered in an IPR disclosure that makes very 560 specific statements. Obviously, if an IPR claimant refuses to suggest 561 any terms at all, the working group is going to have trouble 562 evaluating the future utility of the technology. 564 There is class of restriction which involves "reciprocity", in which 565 the technology may be used as long as the licensee allows the IPR 566 claimant to use the licensee's technology in the same area under 567 comparable terms. A requirement for general reciprocity is also 568 possible, under which the technology is made available for free as 569 long as the licensee does not enforce any IPR claims against the 570 licenser. 572 Words such as "reasonable", "fair", and "non-discriminatory" have no 573 objective legal or financial definition. The actual licensing terms 574 can vary tremendously. Also, IPR claimants have occasionally 575 asserted that there were already sufficient licenses for a particular 576 technology to meet "reasonable" multisource and competitiveness 577 requirements and, hence, that refusing to grant any licenses to new 578 applicants was both fair and nondiscriminatory. The best way to find 579 out what an IPR claimant really means by those terms is to ask, 580 explicitly. It also helps to gather knowledge about licenses actually 581 issued, for that technology or for others, and about other 582 experiences with the IPR claimant. 584 Despite the fact that IPR claimants often don't like to publish 585 explicit terms, there are levels of vagueness, and individuals and 586 even working groups can sometimes successfully push an IPR claimant 587 toward less vagueness. Many employers of IETF participants know that 588 that IETF prefers explicit terms, and do feel pressure to produce 589 them. 591 If working group participants are dissatisfied with the confidence 592 level they can obtain directly about licensing terms for a particular 593 technology, they can possibly extrapolate from history. In order for 594 licensed technology to become a draft standard, at least two 595 independent licenses need to have been issued. If the IPR claimant 596 for the technology the working group is considering has licensed 597 other technology in the past, there is a record of the sorts of terms 598 they are willing to grant, at least in those two specific cases. 599 This sort of thing is weak but everything counts, and it may be of 600 some help. 602 5.7 Third Party Disclosure 604 Formal procedures for third party disclosures are the same as those 605 outlined in [4]. However, anyone considering such a disclosure is 606 encouraged to engage in some preliminary exploration with the 607 affected working group(s) beforehand (see Section 5.7.1). Third party 608 disclosure is a potential denial of service threat to the working 609 group, and therefore it is good form to proceed slowly. 611 Working group participants should be aware that third party 612 disclosure can be used, knowingly or unknowingly, to defocus and 613 distract the working group and hinder its progress. They should 614 evaluate 3rd party disclosures accordingly. WG chairs should be 615 willing and able to discipline those they think are using the third 616 party disclosure system inappropriately. Those who think they are 617 being unfairly blocked may take the matter up with the Area Directors 618 and/or the IESG. 620 All of the criteria for evaluating IPR claims discussed in the 621 sections above apply in the case of third party disclosures as well, 622 to the extent they can be practiced. 624 5.7.1 Third Party Disclosure Advice 626 This subsection provides advice to those considering making third 627 party disclosures. While not strictly required, the actions 628 described here are encouraged to aid working groups in dealing with 629 the possible implications of third party disclosures. In evaluating 630 what (if anything) to do in response to a third party disclosure, a 631 WG may consider the extent to which the discloser has followed this 632 advice (for example, in considering whether a disclosure is intended 633 primarily to defocus and distract the WG). 635 In general a potential discloser should exchange mail with the 636 working group chair(s) first, to open the way for discussion. Also, 637 if the potential discloser is not sure if the IPR claim applies, this 638 is the time to reach some kind of agreement with the working group 639 chairs before saying anything publicly. After discussion with the 640 working group chairs, they should bring the issue to the attention of 641 the working group, and to the attention of the IPR claimant if doing 642 so is not too difficult. Such discussion should help the potential 643 discloser to become more sure, one way or the other. If they are 644 sure the discovered IPR claim applies, and the IPR claimant does not 645 submit a first party disclosure itself, then they are encouraged to 646 submit a third party disclosure. 648 Intellectual property often applies to more than one working group. 649 A person thinking of third party disclosure should consider what 650 other working groups might be affected, and communicate with them in 651 the same manner. 653 Don't bring up IPR issues that are unrelated to the areas where the 654 WG is focusing at that time. Don't bring claims to the WG's 655 attention just in case it might go there in a few months, only if it 656 has implications for current work. Messages to the working group list 657 should be substantive and a single message should focus on a specific 658 issue. They can reference multiple claims or patents related to that 659 issue. 661 6. Security Considerations 663 This memo relates to IETF process, not any particular technology. 664 There are security considerations when adopting any technology, 665 whether IPR-protected or not. A working group should take those 666 security considerations into account as one part of evaluating the 667 technology, just as IPR is one part, but they are not issues of 668 security with IPR procedures. 670 Normative References 672 [1] IETF, "IPR Working Group web page", 2002, . 675 [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 676 9, RFC 2026, October 1996. 678 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 679 Levels", BCP 14, RFC 2119, March 1997. 681 [4] Bradner, S., "Intellectual Property Rights in IETF Technology", 682 draft-ietf-ipr-technology-rights-01 (work in progress), February 683 2003. 685 [5] Bradner, S., "IETF Rights in Submissions", 686 draft-ietf-ipr-submission-rights-01 (work in progress), February 687 2003. 689 Informative References 691 [6] Wu, T., "The SRP Authentication and Key Exchange System", RFC 692 2945, September 2000. 694 Author's Address 696 Scott Brim 697 Cisco Systems, Inc. 698 146 Honness Lane 699 Ithaca, NY 14850 700 USA 702 EMail: sbrim@cisco.com 704 Intellectual Property Statement 706 The IETF takes no position regarding the validity or scope of any 707 intellectual property or other rights that might be claimed to 708 pertain to the implementation or use of the technology described in 709 this document or the extent to which any license under such rights 710 might or might not be available; neither does it represent that it 711 has made any effort to identify any such rights. Information on the 712 IETF's procedures with respect to rights in standards-track and 713 standards-related documentation can be found in BCP-11. Copies of 714 claims of rights made available for publication and any assurances of 715 licenses to be made available, or the result of an attempt made to 716 obtain a general license or permission for the use of such 717 proprietary rights by implementors or users of this specification can 718 be obtained from the IETF Secretariat. 720 The IETF invites any interested party to bring to its attention any 721 copyrights, patents or patent applications, or other proprietary 722 rights which may cover technology that may be required to practice 723 this standard. Please address the information to the IETF Executive 724 Director. 726 Full Copyright Statement 728 Copyright (C) The Internet Society (2003). All Rights Reserved. 730 This document and translations of it may be copied and furnished to 731 others, and derivative works that comment on or otherwise explain it 732 or assist in its implementation may be prepared, copied, published 733 and distributed, in whole or in part, without restriction of any 734 kind, provided that the above copyright notice and this paragraph are 735 included on all such copies and derivative works. However, this 736 document itself may not be modified in any way, such as by removing 737 the copyright notice or references to the Internet Society or other 738 Internet organizations, except as needed for the purpose of 739 developing Internet standards in which case the procedures for 740 copyrights defined in the Internet Standards process must be 741 followed, or as required to translate it into languages other than 742 English. 744 The limited permissions granted above are perpetual and will not be 745 revoked by the Internet Society or its successors or assignees. 747 This document and the information contained herein is provided on an 748 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 749 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 750 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 751 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 752 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 754 Acknowledgement 756 Funding for the RFC Editor function is currently provided by the 757 Internet Society.