idnits 2.17.1 draft-ietf-ipr-wg-guidelines-00.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 (October 25, 2002) is 7855 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) -- Missing reference section? '5' on line 598 looks like a reference -- Missing reference section? '6' on line 601 looks like a reference -- Missing reference section? '1' on line 586 looks like a reference -- Missing reference section? '4' on line 595 looks like a reference -- Missing reference section? '2' on line 589 looks like a reference -- Missing reference section? '3' on line 592 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPR S. Brim 3 Internet-Draft Cisco Systems, Inc. 4 Expires: April 25, 2003 October 25, 2002 6 Guidelines for Working Groups on Intellectual Property Issues 7 draft-ietf-ipr-wg-guidelines-00 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 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on April 25, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 This memo lays out a conceptual framework and rules of thumb useful 39 for working groups dealing with IPR issues. It documents specific 40 examples of how IPR issues have been dealt with in the IETF. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 3. The Approach . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 4. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 5 48 4.1 IPS WG (IP Storage) . . . . . . . . . . . . . . . . . . . . . 5 49 4.2 PEM and PKI issues . . . . . . . . . . . . . . . . . . . . . . 5 50 4.3 CDI WG (Content Distribution Internetworking) . . . . . . . . 6 51 4.4 VRRP (Virtual Router Redundancy Protocol) . . . . . . . . . . 7 52 4.5 Secure Shell (SecSH) . . . . . . . . . . . . . . . . . . . . . 7 53 4.6 IDN (Internationalized Domain Name) . . . . . . . . . . . . . 7 54 5. General Principles . . . . . . . . . . . . . . . . . . . . . . 9 55 5.1 Types of IPR . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 5.2 When to think about IPR . . . . . . . . . . . . . . . . . . . 9 57 5.3 IPR as a Technology Evaluation Factor . . . . . . . . . . . . 10 58 5.4 Patents versus Pending Patents . . . . . . . . . . . . . . . . 11 59 5.5 Applicability: It's Hard to Prove a Negative . . . . . . . . . 11 60 5.6 No Universal License Terms . . . . . . . . . . . . . . . . . . 12 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 62 References (Non-Normative) . . . . . . . . . . . . . . . . . . 13 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 64 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 66 1. Introduction 68 This memo lays out a conceptual framework and rules of thumb for 69 working groups dealing with IPR issues. The goal is to achieve a 70 balance between the needs of IPR holders and the implementers of the 71 Internet which is appropriate to current times. As part of trying to 72 distill out principles for dealing with IPR in IETF working groups, 73 it provides case studies of treatments of IPR issues that have 74 already been worked out. In other words, it documents the running 75 code of the IETF process. 77 This memo does not describe IPR procedures for document authors or 78 IPR asserters. Those are covered in two other memos coming out of 79 the IPR working group, on IPR in the IETF [5] and submitters' rights 80 [6]. Rather, this memo is for working groups that are trying to 81 decide what to do about IPR-protected technology contributions. 83 2. The Problem 85 Traditionally the IETF has tried to avoid technologies which were 86 "protected" through IPR assertions. However, compromises have been 87 made since before the IETF was born. The "common knowledge" of the 88 IETF, that IPR-protected technology was anathema, has never dealt 89 with the fact that the Internet has run on IPR-protected technologies 90 from the beginning. Nowadays the majority of the useful technologies 91 brought to the IETF have some sort of IPR assertion associated with 92 them. 94 It will always be better for the Internet to develop standards based 95 on technology which can be used without concern about selective or 96 costly licensing. However, increasingly, choosing a technology which 97 is not protected by IPR over an alternative that is may produce a 98 weaker Internet. Sometimes there simply isn't any technology in an 99 area that is not IPR-protected. It is not always the wrong choice to 100 select IPR-protected technology, if the choice is made knowingly, 101 after considering the alternatives and taking the IPR issues into 102 account. 104 The IETF is not a membership organization. Other standards making 105 bodies may have membership agreements that member organizations must 106 sign and adhere to in order to participate. Membership agreements 107 may include strict procedures for dealing with IPR, or perhaps a 108 requirement that technology must be licensed royalty-free. This is 109 not possible in the IETF. 111 Even if the IETF had membership agreements, they would be difficult 112 to formulate in a way that covered IPR problems, because the IETF's 113 work includes technology from other sources and because the IETF 114 collaborates with organizations that work with different approaches 115 to intellectual property. The IETF can encounter four different IPR 116 situations, at almost any time during the life of a document: 118 o A draft submitter notes its IPR claim regarding the contents of 119 the draft. 121 o An IETF participant asserts that the contents of a draft is 122 covered by their own IPR. 124 o IPR is noted, by the author of a draft or by a different IETF 125 participant, that is claimed by an organization that does not 126 participate in the IETF at all. 128 o An organization that does not participate in the IETF, but that 129 monitors its activities, discovers that a draft intersects that 130 organization's established or pending intellectual property 131 claims. It may come forward right away, or wait and let the IETF 132 work progress. 134 The IETF does not have detailed rules for each situation. The IETF 135 does not force IPR-related behavior on anyone. It only sets criteria 136 for a technology document becoming an Internet standard. Working 137 groups have essentially only one rule they can invoke -- about 138 individuals not participating in activities related to a technology 139 if they do not disclose known IPR. Other than that a working group 140 only has 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 organizing principle of this memo is to give working groups as 151 much information as possible to make informed decisions, and then 152 step out of the way. The other IPR working group memos (see the IPR 153 Working Group charter page [1]) lay out what needs to be done once a 154 particular piece of technology is selected as a working group draft. 155 That doesn't help when a working group is trying to decide whether to 156 select a technology or not in the first place. Thus this third memo. 157 We want to build a conceptual framework, a new set of "common 158 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 to be learned and try to 165 extract general principles. 167 4. Case Studies 169 The best way to know what works is to look at past attempts at 170 dealing with IPR. The following are selected as cases from which 171 general lessons might be extracted. 173 4.1 IPS WG (IP Storage) 175 The IPS Working Group evaluated technology developed outside of the 176 working group, "secure remote password" (SRP, RFC2945 [4]). At the 177 time, there was one known IPR assertion, and the proposed licensing 178 terms were apparently reasonable. SRP had become a proposed standard 179 without going through any working group, so IETF participants may 180 have been less likely to notice it in order to make statements about 181 IPR. In any case, two more possible IPR claims were uncovered after 182 the IPS working group had already decided to make SRP required. One 183 of the possible IPR holders did not make a strong IPR assertion 184 itself, and did not want to take the time to determine whether it 185 actually had a claim, though it acknowledged it might have a claim. 186 Also, in both cases it was difficult to obtain information on 187 possible licensing terms, even though words like reasonable and non- 188 discriminatory were used in IPR statements, and rumors of what they 189 might be did like not sound good. The working group participants 190 took the assertions, potential and otherwise, very seriously, and 191 decided not to use SRP after all, even though they had already chosen 192 it based on other criteria. 194 Lessons: 196 o IPR assertions may appear at any time in the standards process. 198 o Take impreciseness seriously. Attempt to get clarification on 199 both IPR claims and licensing terms. 201 4.2 PEM and PKI issues 203 PEM (Privacy-Enhanced Mail) wanted to use public key technology. In 204 the mid-90s, the basic principles of public key infrastructure had 205 been patented for years. The patent holder had shown a tendency to 206 actively enforce its rights, and to prefer software sales to 207 licensing. This was seen as a significant potential issue, one which 208 could possibly interfere with the easy development of the Internet. 210 However, there was no alternative technology that came close to its 211 capabilities. Adopting an alternative would have damaged the 212 Internet's health and flexibility even more than adopting a 213 technology with IPR assertions. The case was so compelling that the 214 working group participants decided to move forward on standardizing 215 it and even requiring it. 217 One factor which was noted was that the patents were mature, and 218 would expire within a few years. That meant that although the impact 219 might be significant to start with, it would not be in the long run. 220 This lowered the perceived risk of using the IPR-protected 221 technology. 223 Lessons: 225 o IPR is just one issue in deciding whether to adopt a technology. 227 o IPR is not an all or nothing issue. There are different types and 228 levels of IPR protection. 230 o The IPR's lifecycle phase can be a consideration. 232 4.3 CDI WG (Content Distribution Internetworking) 234 The CDI Working Group laid out an overall architecture and found that 235 a number of included technologies had IPR claims associated with 236 them, based on work done before the working group was started. The 237 working group participants decided there was little chance of 238 producing alternative technologies which were as useful and which did 239 not run up against these IPR assertions. As usual, there was no good 240 way to evaluate assertions and possible licensing terms until after 241 the technology had been completely specified (at the earliest). 243 Working group participants generally thought they had a good idea 244 what to expect from each other, and that the ultimate benefits of 245 using the technologies outweighed the IPR issues. The working group 246 participants decided not to consider IPR as an issue at all in 247 determining which technologies to adopt. 249 Lessons: 251 o Past experience can be used as a significant factor in evaluating 252 the possible impact of IPR. 254 4.4 VRRP (Virtual Router Redundancy Protocol) 256 The working group was standardizing VRRP based on a protocol 257 developed outside the IETF. The IPR holder supported that protocol 258 and stated that it would license its IPR for that protocol if it 259 became the standard, but not for the similar protocol the working 260 group was developing. The working group participants decided to go 261 ahead and standardize its protocol anyway. The IPR holder has only 262 asserted its patent when someone else asserted a patent against it. 263 There is no evidence that the working group participants actually 264 thought about the implications of the IPR when it went ahead with its 265 choice of protocol. 267 Lessons: 269 o IPR assertions should never be disregarded without good cause. 270 Due diligence should be done to understand the consequences of 271 each assertion. 273 4.5 Secure Shell (SecSH) 275 This was primarily a trademark issue, not a patent issue, since the 276 patent issue had been worked out outside of the IETF. The holder of 277 a trademark wanted the IETF to stop using "SSH" in the names and text 278 of its proposed standards. The working group participants thought 279 through the details of the claims, and possible implications and 280 risks, and decided to go ahead and continue using the names as they 281 are now. This issue is still being worked through. 283 Lessons: 285 o Working group participants can evaluate IPR assertions not only 286 for their possible validity, but also for the risk of misjudging 287 that validity. The impact of honoring the IPR claim may be major 288 or minor. 290 4.6 IDN (Internationalized Domain Name) 292 The IDN working group dealt with a number of IPR assertions. Several 293 were made which did not overlap with the technology -- the IPR 294 asserters said the patents were being announced just in case the 295 working group decided to go that way. In one case, even though a 296 patent was announced as purely defensive, the working group 297 participants investigated the claims themselves. They concluded that 298 it did not overlap. 300 In one case, an IPR claimer asserted that the working group's 301 documents, and in fact the IETF as a whole, were infringing on its 302 rights. Individual working group participants consulted with their 303 legal advisers, concluded that the claims would not overlap the 304 working group's developing technology, and decided to ignore the 305 claims. This was reflected in the direction the group as a whole 306 decided to take. 308 In another case, patent claims were asserted that appeared to be 309 derived from WG discussion and impact, rather than vice versa (or 310 independent discovery). The claimants were known to be following the 311 WG's work when the ideas were proposed, and their patent filing was 312 considerably subsequent to that time. 314 In 2000 the IDN working group discovered a patent that some 315 participants thought might apply to one of their main drafts. If it 316 did, it could affect their work profoundly -- to the extent that some 317 suggested that if they could not work out reasonable licensing terms 318 with the IPR holder they might just disband. As a group and 319 individually, participants corresponded with IPR holder in order to 320 get an explicit statement of licensing terms, preferably royalty- 321 free. By doing so they gained a better understanding of just which 322 WG activities were seen as infringing on the patent, and at least 323 some understanding of the IPR holder's intentions and philosophy. 324 Since the patent holder seemed to have an interest in using the 325 patent for profit, the group discussed the issues on its mailing 326 list. They overtly talked about how they could change their proposed 327 technology to avoid having to contest the patent, and the extent to 328 which the patent might be countered by claims of prior art. 329 Meanwhile, individually they were talking to their legal advisors. 330 Gradually, a collective opinion formed that the working group 331 documents did not infringe on the patent. Since then, the patent has 332 been ignored. However, they are keeping a watchful eye out for 333 continuation patents which might have already been submitted. 335 Lessons: 337 o It's sometimes beneficial to push IPR claimants to find out what 338 they think their claims cover and what their licensing terms are. 340 o Possibilities of prior art should be considered. 342 o It's all right, and sometimes beneficial, to discuss IPR claims 343 and gather information about possible prior art on the group list 344 (but remember that neither the IETF nor any working group takes a 345 stand on such claims as a body, and the group is not the best 346 place to get legal advice). 348 o 350 5. General Principles 352 Given the case studies above, here are a few principles that working 353 groups can start with in dealing with IPR. Of course every working 354 group needs to follow its own consensus, and actual treatments will 355 vary as much as they have in the past. 357 5.1 Types of IPR 359 A primer on the different types of IPR would be large, unreliable, 360 and redundant with other Working Group documents [2][5][6]. For 361 informal exploration, see those documents and other relevant sources 362 on the web. Readers with more serious concerns should consult their 363 legal advisors. In the United States, briefly: 365 o Trademarks indicate the sources of goods. Servicemarks indicate 366 the sources of services. They protect the use of particular marks 367 or similar marks. 369 o Copyrights protect the expressions of ideas (not the ideas 370 themselves), in almost any form, and allow "fair use". Copyrights 371 expire but they can be renewed. 373 o Patents protect "inventions". They expire (utility patents expire 374 after 20 years), but follow-on patents can cover similar 375 technologies and can have nearly the same implications for use in 376 the Internet as the original patents. 378 5.2 When to think about IPR 380 This memo does not describe IPR procedures for document authors or 381 IPR asserters. Rather, this memo is for working groups that are 382 trying to decide what to do about IPR-protected technology 383 contributions. A working group as a whole (as opposed to individual 384 contributors or IPR holders) needs to think about IPR issues: 386 o when examining a technology, and deciding whether to initiate work 387 on it. 389 o when deciding whether to adopt a draft as a working group 390 document. 392 o when choosing between two or more working group drafts that use 393 different technologies. 395 o when deciding whether to depend on a technology developed outside 396 the working group. 398 o when comparing different kinds of IPR protection. 400 At each of these times, the working group should solicit disclosure 401 of IPR assertions and licensing terms. A working group's job will be 402 a lot easier if IPR details are discovered early, but it should 403 realize that IPR assertions may appear at any time. An IPR holder 404 which does not participate in the IETF may choose to wait, while the 405 relevant technology is being discussed and evaluated, perhaps 406 modifying its claims during this time. 408 5.3 IPR as a Technology Evaluation Factor 410 How do you weigh IPR assertions against other issues when deciding 411 whether to adopt a technology? 413 The ultimate goal of the IETF is to promote the overall health, 414 robustness, flexibility and utility of the Internet infrastructure. 415 We base architectural decisions on our long-term extrapolations of 416 requirements, by thinking in these terms. When considering a 417 particular technology, we compare it with other technologies not just 418 for its elegance of design in and of itself, but also for how it fits 419 in the bigger picture. This is done at multiple levels. It is 420 examined for how it fits into the overall design of the working 421 group's output, how it fits into the particular Internet 422 infrastructure area, how it fits with work going on in other areas, 423 and how it fits in the long view of the Internet architecture. 425 Similarly, when evaluating a technology, working group participants 426 consider IPR claims on it (including possible copyright issues with 427 text describing it). The issue is not whether a particular piece of 428 technology is IPR-protected -- we use IPR-protected technology every 429 minute. The question is how much the IPR protection will limit the 430 technology's usefulness in building a robust, highly useful Internet. 431 Thus, the only significant questions are: is the IPR claim relevant, 432 and if so what are the terms under which the technology can be used? 433 When technology is free from IPR protection the answer is easy. When 434 it is IPR-protected, some terms make the IPR issues insignificant 435 compared to the engineering issues. Other terms can make a 436 technology unusable even if it is perfect otherwise. 438 The problem with IPR as a technology evaluation factor is that it is 439 unlikely that a working group, as an entity, can ever claim to have 440 reached consensus on most IPR issues. The IETF as a whole, and a 441 working group as a whole, takes no stance on the validity of any IPR 442 claim. It would be inappropriate for a working group chair to 443 declare that consensus had been reached that, for example, a 444 company's patent was invalid. Individual participants will need to 445 use whatever legal advice resources they have access to to form their 446 own individual opinions, but discussions about the validity of IPR 447 should not take place under the auspices of the working group. 449 5.4 Patents versus Pending Patents 451 The IETF does not (cannot) expect IPR asserters to tell a working 452 group specifically how they think a particular patent applies. If a 453 patent has already been granted, the IETF can reasonably expect 454 disclosure of the patent number, which will allow working group 455 participants to explore details of the claims. If a patent has not 456 yet been granted, significantly less information is available. In 457 most countries patent applications are published 18 months after they 458 are filed, but in the USA that can be avoided if the applicant does 459 not also file outside the USA. Details of pending patent claims can 460 be modified at any time by the claim submitter before the patent is 461 granted. It is not known before then what rights will actually be 462 granted. Finally, rights can be contested in court, and nothing is 463 final until the courts decide. All the IETF can expect regarding a 464 pending patent is disclosure that it exists and possibly some 465 statement about licensing terms. 467 5.5 Applicability: It's Hard to Prove a Negative 469 Working group participants need to make their own decisions about 470 what level of confidence they need as to whether IPR is applicable. 471 However, perfect knowledge is not a worthwhile goal. 473 In general, a working group should strive to find out about all IPR 474 claims related to technologies it is considering, and at least the 475 general facts about licensing terms for each case -- for example 476 whether the terms will be "reasonable and non-discriminatory". 477 Working group participants should also investigate possibilities of 478 prior art which would counter the IPR claims. However, even if the 479 working group participants do exhaustive searches, both externally 480 and internally to their employers, it is impossible to prove that a 481 particular technology is not covered by a particular IPR claim, let 482 alone proving that it is not covered by any IPR claim. Anything a 483 working group adopts may, in the future, turn out to be IPR- 484 protected, although the IPR assertion may not be discovered until 485 years later. Claims are open to interpretation even after rights are 486 granted. Drafts can be very fluid, even up to the time of last call, 487 and IPR issues may unknowingly be taken on at any time. Absolute 488 certainty about IPR claims is extremely rare. 490 However, the level of confidence needed to consider IPR when 491 evaluating a technology is often not hard to get to. There are cases 492 where risk is high (e.g. where licensing terms may be onerous) and 493 thus a high level of confidence about applicability is needed, but 494 history shows that most of the time "rough" confidence is good 495 enough. In any case, perfect confidence is usually impossible. 497 5.6 No Universal License Terms 499 Licensing terms vary continuously across a range from prohibitive to 500 no license at all. In general there are four classes of situation 501 which will be encountered. 503 o No license - licenses per se are not available. Local 504 regulations, if any, apply. 506 o Public domain - the technology is explicitly made available to 507 all, without any IPR claims. 509 o General "free" license - the technology is made available free of 510 charge. There may be terms which specify conditions for use of 511 the technology, for example regarding redistribution. There is a 512 form of this license which invokes "reciprocity", in which the 513 technology may be used as long as the licensee allows the IPR 514 holder to use the licensee's technology in the same area under 515 comparable terms. A requirement for general reciprocity is also 516 possible, under which the technology is made available as long as 517 the licensee does not enforce any IPR claims against the licenser. 519 o "Reasonable and non-discriminatory" (RAND) terms - the license is 520 granted based on some terms which may include reciprocity. The 521 terms can vary tremendously. Even when IPR assertions do use 522 words such as "reasonable", "fair", and "non-discriminatory", 523 working groups should keep in mind that these words have no 524 objective legal definition, at least not in this context. 526 Many IPR holders do not like to publish explicit, specific terms 527 under which they will issue licenses. They may use standard terms 528 for many licensees, but they prefer to negotiate terms for some. 529 Therefore, do not expect any IPR claim to lay out detailed blanket 530 terms for licensing. 532 Vaguer terms are not necessarily better or worse than more specific 533 terms. If an IPR assertion lists only vague terms, that doesn't mean 534 the terms that will be offered in individual licenses will be any 535 worse than those offered in an IPR assertion that makes very specific 536 statements. Obviously, if an IPR claimant refuses to suggest any 537 terms at all, the working group is going to have trouble evaluating 538 the future utility of the technology. 540 Recall that words such as "reasonable", "fair", and "non- 541 discriminatory" have no objective legal or financial definition. 542 Also, IPR holders have occasionally asserted that there were already 543 sufficient licenses for a particular technology to meet "reasonable" 544 multisource and competitiveness requirements and, hence, that 545 refusing to grant any licenses to new applicants was both fair and 546 nondiscriminatory. The best way to find out what an IPR holder 547 really means by those terms is to ask, explicitly. It also helps to 548 gather knowledge about licenses actually issued, for that technology 549 or for others, and about other experiences with the IPR holder. 551 Despite the fact that IPR holders often don't like to publish 552 explicit terms, there are levels of vagueness, and individuals and 553 even working groups can sometimes successfully push an IPR holder 554 toward less vagueness. The employers of IETF participants all know 555 that that IETF prefers explicit terms, and do feel pressure to 556 produce them. 558 If working group participants are dissatisfied with the confidence 559 level they can obtain directly about licensing terms for a particular 560 technology, they can possibly extrapolate from history. As part of 561 the standards process as described in RFC2026 [2], in order for 562 licensed technology to become a draft standard, at least two 563 independent licenses need to have been issued. If the IPR holder for 564 the technology the working group is considering has licensed other 565 technology in the past, there is a record of the sorts of terms they 566 are willing to grant, at least in those two specific cases. This 567 sort of thing is weak but if everything counts, it may be some 568 indication. 570 6. Security Considerations 572 This memo relates to IETF process, not any particular technology. 573 There are security considerations when adopting any technology, 574 whether IPR-protected or not. A working group should take those 575 security considerations into account as one part of evaluating the 576 technology, just as IPR is one part, but they are not issues of 577 security with IPR procedures. 579 There may be security issues with procedures for dealing with IPR, 580 but they are not technical. They have more to do with 581 unintentionally revealing corporate intellectual property through 582 human activity than risking anything when using a protocol. 584 References (Non-Normative) 586 [1] IETF, "IPR Working Group web page", 2002, . 589 [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 590 9, RFC 2026, October 1996. 592 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 593 Levels", BCP 14, RFC 2119, March 1997. 595 [4] Wu, T., "The SRP Authentication and Key Exchange System", RFC 596 2945, September 2000. 598 [5] Bradner, S., "Intellectual Property Rights in IETF Technology", 599 draft-bradner-ipr-technology-00 (work in progress), July 2002. 601 [6] Bradner, S., "IETF Rights in Submissions", draft-bradner- 602 submission-rights-00 (work in progress), June 2002. 604 Author's Address 606 Scott Brim 607 Cisco Systems, Inc. 608 146 Honness Lane 609 Ithaca, NY 14850 610 USA 612 EMail: sbrim@cisco.com 614 Full Copyright Statement 616 Copyright (C) The Internet Society (2002). All Rights Reserved. 618 This document and translations of it may be copied and furnished to 619 others, and derivative works that comment on or otherwise explain it 620 or assist in its implementation may be prepared, copied, published 621 and distributed, in whole or in part, without restriction of any 622 kind, provided that the above copyright notice and this paragraph are 623 included on all such copies and derivative works. However, this 624 document itself may not be modified in any way, such as by removing 625 the copyright notice or references to the Internet Society or other 626 Internet organizations, except as needed for the purpose of 627 developing Internet standards in which case the procedures for 628 copyrights defined in the Internet Standards process must be 629 followed, or as required to translate it into languages other than 630 English. 632 The limited permissions granted above are perpetual and will not be 633 revoked by the Internet Society or its successors or assigns. 635 This document and the information contained herein is provided on an 636 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 637 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 638 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 639 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 640 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 642 Acknowledgement 644 Funding for the RFC Editor function is currently provided by the 645 Internet Society.