idnits 2.17.1 draft-hallambaker-ipr-patent-harmonization-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 628. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 635. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 641. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 114 has weird spacing: '... Source a set...' == Line 118 has weird spacing: '...ntation a sof...' == Line 125 has weird spacing: '... Patent a set...' == Line 129 has weird spacing: '... Access terms...' == Line 132 has weird spacing: '...License a con...' == (1 more instance...) -- 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 (November 4, 2007) is 5989 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2560' is defined on line 587, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Hallam-Baker 3 Internet-Draft VeriSign Inc 4 Intended status: Informational D. Hallam-Baker 5 Expires: May 7, 2008 World Wide Web Consortium 6 November 4, 2007 8 IETF Patent Policy: A Quantum Approach 9 draft-hallambaker-ipr-patent-harmonization-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 7, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 Considerations for IETF patent policy are considered and proposals 43 made for reform. The particular objective of these proposals is to 44 reduce the amount of time spent in unproductive discussion of IPR 45 issues and to allow Working Groups to provide Patent Rights Holders 46 with clearly defined criteria that must be met in order for their 47 technology to be accepted. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 53 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Stakeholder Concerns . . . . . . . . . . . . . . . . . . . . . 5 55 2.1. Patent Rights Holders . . . . . . . . . . . . . . . . . . 5 56 2.1.1. License Revenue . . . . . . . . . . . . . . . . . . . 5 57 2.1.2. Monopoly Rights . . . . . . . . . . . . . . . . . . . 5 58 2.1.3. Defensive Use . . . . . . . . . . . . . . . . . . . . 5 59 2.1.4. Protecting Rights . . . . . . . . . . . . . . . . . . 5 60 2.1.5. Attribution . . . . . . . . . . . . . . . . . . . . . 6 61 2.1.6. Adoption . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.2. Implementors . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.2.1. Litigation Risk . . . . . . . . . . . . . . . . . . . 6 64 2.2.2. Damages Risk . . . . . . . . . . . . . . . . . . . . . 6 65 2.2.3. License Cost . . . . . . . . . . . . . . . . . . . . . 6 66 2.2.4. Encumberance . . . . . . . . . . . . . . . . . . . . . 7 67 2.2.5. Adoption . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.2.6. Patent Rights Holders . . . . . . . . . . . . . . . . 7 69 2.3. Users . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 2.3.1. Indeminity . . . . . . . . . . . . . . . . . . . . . . 8 71 3. Patents in the Standards Process . . . . . . . . . . . . . . . 8 72 3.1. Issues Arising from Current IETF Practice . . . . . . . . 8 73 3.1.1. Royalty Terms . . . . . . . . . . . . . . . . . . . . 8 74 3.1.2. Time Taken for Discussion . . . . . . . . . . . . . . 8 75 3.1.3. Weak Negotiating Position . . . . . . . . . . . . . . 9 76 3.1.3.1. No Decision Maker . . . . . . . . . . . . . . . . 9 77 3.1.3.2. Unequal Precedent . . . . . . . . . . . . . . . . 9 78 3.1.4. Unenforceable Patent Claims . . . . . . . . . . . . . 10 79 3.1.5. Uncertainty . . . . . . . . . . . . . . . . . . . . . 10 80 3.1.6. Access, not Licenses . . . . . . . . . . . . . . . . . 10 81 3.1.7. Non Participant Claims . . . . . . . . . . . . . . . . 11 82 3.2. Other Standards Bodies . . . . . . . . . . . . . . . . . . 11 83 3.2.1. World Wide Web Consortium . . . . . . . . . . . . . . 11 84 3.2.2. OASIS . . . . . . . . . . . . . . . . . . . . . . . . 11 85 3.2.3. Other . . . . . . . . . . . . . . . . . . . . . . . . 11 86 3.2.4. Stakeholder Concerns in IETF Process . . . . . . . . . 11 87 3.2.4.1. Disclosure . . . . . . . . . . . . . . . . . . . . 11 88 3.2.4.2. Predicatability . . . . . . . . . . . . . . . . . 12 89 3.2.4.3. Fairness . . . . . . . . . . . . . . . . . . . . . 12 90 4. Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 4.1. Increased NOTE WELL visibility . . . . . . . . . . . . . . 12 92 4.2. Specify IPR terms in chartering discussion . . . . . . . . 12 93 4.3. Reuse already existing IPR Policy terms . . . . . . . . . 13 94 4.4. Liase with in Discussion in Appropriate Venues . . . . . . 13 95 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 98 8. Normative References . . . . . . . . . . . . . . . . . . . . . 14 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 100 Intellectual Property and Copyright Statements . . . . . . . . . . 15 102 1. Introduction 104 1.1. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 1.2. Definitions 112 The following defined terms are used: 114 Open Source a set of principles and practices intended to promote 115 access to the design and production of goods and knowledge through 116 full disclosure of all relevant design materials. 118 Open Source Implementation a software or hardware implementation 119 that is licensed on terms compatible with Open Source principles. 121 Zero Cost Open Source Implementation An Open Source implementation 122 that is provided at no charge to any party and which may be 123 extended or adapted without restriction. 125 Patent a set of exclusive rights granted by a state to a patentee 126 for a fixed period of time in exchange for a disclosure of an 127 invention. 129 Patent Access terms that allows a party to practice the invention 130 covered by a patent without risk of a lawsuit. 132 Patent License a contract granting a Patent Access. 134 RAND Reasonable and Non Discriminatory terms 136 RANDZ Reasonable, Non Discriminatory and Zero cost terms 138 Royalty RAND Reasonable and Non Discriminatory terms in which a 139 royalty fee is required for some or all uses.. 141 Reciprocal Rights rights granted by one party to another on the 142 condition that the recipient grant terms that are equally 143 favorable to the granting party. 145 Certain definitions are adapted from text found in Wikipedia. 147 2. Stakeholder Concerns 149 2.1. Patent Rights Holders 151 2.1.1. License Revenue 153 A Patent Rights Holder may seek revenue in the form of license fees. 154 The terms offered for these rights may or may not be RAND. 156 In many instances a Patent Rights Holder seeking to obtain license 157 revenue will offer RANDZ terms for certain types of use (e.g. non- 158 commercial, educational) or certain uses of the patent (e.g. allow 159 free use of rights to decode content but charge fees for encoders). 160 Such terms are properly regarded as a business model rather than Zero 161 Cost terms. 163 2.1.2. Monopoly Rights 165 A Patent Rights Holder may seek to use patent rights to establish or 166 extend a dominant or otherwised advantageous market position. As 167 with a revenue exploitation model the Patent Rights Holder may offer 168 liberal terms in some areas while protecting others. 170 2.1.3. Defensive Use 172 As issue of Patent grants has increased Implementors and Users, 173 particularly those with deep pockets have become increasingly 174 concerned about their exposure to litigation and damages risks. 176 Defensive patent applications provide a degree of mitigation for this 177 risk. 179 Establish Prior Art A defensive patent application establishes prior 180 art for the invention(s) claimed. This MAY pre-empt subsequent 181 grant of a patent for the same claims by another party or allow 182 for a successful defense should a subequent patent be issued. 183 This is not certain however. 185 Obtain Reciprocal Access A defensive patent applicatiopn MAY be used 186 to obtain reciprocal rights from other patent rights holders. 188 2.1.4. Protecting Rights 190 A Patent Rights Holder may be subeject to limitations of their rights 191 or lose them entirely for certain specific types of inequiable 192 conduct. This has occurred in the US courts for failure to disclose 193 the existence of rights to an invention when the Patent Rights Holder 194 was under a specific obligation to do so. 196 2.1.5. Attribution 198 A Patent Rights Holder that has invested substantial resources in 199 developing an invention may desire credit for doing so. 201 2.1.6. Adoption 203 The value of a communication protocol is dependent on adoption. As 204 Nicholas Negroponte observed, the utility of the first fax machine 205 was nil until the second one was produce and has climbed steadily as 206 the number of faxes has increased. 208 The need for widespread adoption is the reason that standards play an 209 unusually critical role in the development of communication 210 technologies. Without standardization of features such as thread 211 pitch, nuts and bolts would be considerably more expensive. Without 212 standardization a communications protocol is no use whatsoever. 214 Without adoption, the value of a typical communications invention is 215 zero. It is thus in the interests of Patent Rights Holders to seek 216 adoption of the inventions they have rights to by promoting them in 217 standards process. 219 2.2. Implementors 221 2.2.1. Litigation Risk 223 The cost of defending a patent infringement lawsuit can be enormous. 225 Litigation risk is a particular concern in the US where costs cannot 226 be recovered from a losing plaintif and cases routinely cost 227 defendants with 'deep pockets' $2 million or more. 229 2.2.2. Damages Risk 231 Damages in patent lawsuits can be very high. Several recent awards 232 have exceeded a hundred million dollars. 234 US law allows for damages to be trebled in cases of willful 235 infringement. As a result some companies have policies which 236 prohibit engineers fro engaging in any patent searches or other 237 activities that might bring patents to their notice and thus provide 238 grounds for a treble damages claim. 240 2.2.3. License Cost 242 The cost of patent licenses is usually paid by implementors. 243 Although these costs will subsequently be passed onto users certain 244 types of implementors may be unable to meet these costs. In addition 245 to providers of Zero Cost Implementations, smaller implementors may 246 be unable to afford minimum license fees or meet other licensing 247 requirements. 249 2.2.4. Encumberance 251 Once a patent license is accepted, the licensee is bound by the terms 252 of the license. These terms may continue even after the original 253 patent term expires or the patent is found to be invalid. 255 A royalty-free license may still be regarded as an encumberance by an 256 implementor. For example a royalty-free license may require the 257 licensee to use a particular technology (e.g. programming language) 258 or support particular features (e.g. direct access to a particular 259 online store) that the implementor would not otherwise accept. 261 In particular 'royalty-free' license terms that require the 262 implementor to surrender patent rights to unrelated technologies or 263 to provide the implementation at zero cost are generally considered 264 an encumberance by the affected parties. 266 Sublicensing terms have proved problematic in this respect. 267 Commercial providers of middleware products have objected to license 268 terms which would require their customers to obtain a royalty-free 269 license from a Patent Rights Holder as requiring them to reveal their 270 customer list to a competitor. Sublicensing is also a concern with 271 certain open source licenses as a patent license obtained by the 272 developer may not transfer to another developer that modifies the 273 code. 275 2.2.5. Adoption 277 Adoption is also a concern for Implementors. Implementors will not 278 adopt a technology unless they beleive that they can access all 279 necessary and enforceable patents on acceptable terms. 281 2.2.6. Patent Rights Holders 283 Some Implementors are also Patent Rights Holders. Their interests in 284 one role may conflict with those in the other. In some cases this 285 conflict may lead to proloinged indecision and thus inaction which in 286 itself impedes the standards process. 288 A particular concern raised by some Implementors/Patent Rights 289 Holders is that the reciprocal rights clause of a Patent License may 290 not be enforceable against a party that obtains a patent grant 291 indirectly through a sublicense. While it has been argued that such 292 reciprocal rights are likely to be found enforceable by a court, in 293 the absence of binding precedent this argument does little to 294 convince a party concerned about litigation risk. 296 2.3. Users 298 A lawsuit for patent infringement may in certain circumstances be 299 brought against the user of an infringing article. Users with deep 300 pockets may thus be exposed to the same litigation and damages risks 301 as developers and all users can expect that licensing costs paid by 302 implementors will be passed onto them. 304 In some recent cases a plaintif who has been successful in a patent 305 infringement lawsuit against an implementor has subsequently brought 306 suit against users, effectivly claiming double damages for the same 307 infringement. 309 2.3.1. Indeminity 311 Users may seek an indemnity against these risks from a third party, 312 typically, but not necessarily, the implementor. 314 3. Patents in the Standards Process 316 3.1. Issues Arising from Current IETF Practice 318 3.1.1. Royalty Terms 320 Current IETF practice is that access to all essential claims 321 necessary to implement a specification MUST be available to all 322 parties on RAND terms. The IETF does not require Zero Cost access to 323 be available. 325 While it is clear that there is no IETF consensus to change this 326 policy, there is an even stronger preference for choosing technology 327 available on RANDZ terms unless an encumbered technology overs 328 exceptionally strong advantages. 330 3.1.2. Time Taken for Discussion 332 The most frequent complaint made of the IETF patent policy is the 333 amount of time spent dicussing it. Extended discussion of patent 334 access issues is particularly problematic when it occurs during 335 Working Group or IETF last call at a point where the Working Group 336 has invested considerable time and effort in developing the 337 specification. 339 At present each IETF Working Group is responsible for deciding its 340 own IPR policy within the constraint of meeting the IETF RAND 341 requirments. While this allows WGs great flexibility in chosing 342 their IPR criteria it leads to a great deal of unnecessarily 343 repetative discussion at both the Working Group and IETF level. 345 A particular problem here is the fact that most IETF participants are 346 engineers. Almost none are qualified lawyers. As a result 347 discussions tend to revolve around the twin poles of ideological 348 commitments and the concerns of those who have in the past become 349 involuntary participants in patent litigation. 351 3.1.3. Weak Negotiating Position 353 Allowing Working Groups to negotiate IPR terms with Patent Rights 354 Holders directly is unsatisfactory because they are placed in a weak 355 negotiating position. 357 3.1.3.1. No Decision Maker 359 Negotiating with a Working Group as a whole is entirely 360 unsatisfactory for the Patent Rights Holder as no party in the 361 Working Group has decision making power, either for the Working Group 362 itself or the IETF as a whole. Any concession made by one member of 363 the Working Group can be repudiated by the group as a whole and even 364 if the Working Group comes to agreement with the Patent Rights Holder 365 this agreement may be repudiated at the IETF level 367 The result is a negotiating posture similar to Axelrod's Prisoner's 368 Dilema in which the rules of the game cause the parties to choose an 369 outcome that is suboptimal for all concerned. 371 3.1.3.2. Unequal Precedent 373 Any concession made by a Patent Rights Holder to one Working Group 374 becomes an unequal precedent. Having revealled their bargaining 375 position, the Patent Rights Holder knows that in the future it will 376 be expected to provide terms that are at least as favorable to any 377 other Working Group. The precedent established is only one way 378 however, the Patent Rights Holder has no assurance that its 379 competitors will be required to provide equally favorable terms in 380 the same circumstance. 382 Unequal precedence encourages Patents Rights Holders to offer the 383 least favorable terms that are likely to be acceptable to the Working 384 Group and is thus counter to the spirit of mutuality on which the 385 IETF is based. 387 3.1.4. Unenforceable Patent Claims 389 The mere assertion of a patent claim does not by itself mean that the 390 claim is valid or enforceable. Patent applications are particularly 391 problematic in this respect as nobody knows if the application will 392 be granted. 394 Bad faith assertions of patent claims are far from unknown. The most 395 famous example being perhaps the notorious Selden 'automobile patent' 396 which prevented production of low cost volume automobiles until the 397 patent was disqualified in 1911 at the conclusion of a case brought 398 against Henry Ford. 400 A bad faith patent claim might be raised in a standards process in 401 the hope of receiving unjust royalty payments or to influence the 402 process itself. A rule against inclusion of any technology against 403 which a patent claim has been asserted would require the IETF to 404 either examine the validity of the patent claim or allow the Patent 405 Rights Holder to exercise a veto. 407 3.1.5. Uncertainty 409 Uncertainty imposes costs on all legitimate stakeholders. A Patent 410 Rights Holder seeking to fairly obtain royalties for use of their 411 technology has little incentive to invest in engagement in a 412 standards process if it is uncertain that Royalty RAND terms will be 413 acceptable. Equally an implementor is likely to object if having 414 engaged in a standards process under the expectation that the royalty 415 terms will be RANDZ and find that this is not the case at a late 416 stage. 418 The disadvantage created by uncertainty might be used to advantage by 419 a bad faith Patent Rights Holder, encouraging development of the 420 specification to proceed on the expectation that RANDZ terms will be 421 available without the intention of ever doing so. This is not as 422 great a concern in standards bodies where implementation and 423 deployment follow agreement of the specification. In the IETF and 424 other Internet standards bodies deployment and use is considered an 425 essential criterion for recognition of a standard. 427 3.1.6. Access, not Licenses 429 Conventional consideration of patent policy has centered on patent 430 license terms, this despite the fact that few parties have in fact 431 obtained licenses when offered. 433 In most cases the interest of the implementor is not to obtain a 434 patent license, it is to obtain an assurance that a lawsuit will not 435 be brought for infringement. Nor is it likely to be in the interests 436 of a Patent Rights Holder to litigate for infringement of a RANDZ 437 patent license except as a countersuit to an infringement case 438 brought by the alleged infringer. 440 The objectives of the parties is therefore to grant and obtain Patent 441 Access as opposed to a Patent License. In the Microsoft Open 442 Specification Promise this takes the form of an irrevocable promise 443 not to assert any Microsoft Necessary Claims in connection with an 444 implementation that conforms to a covered specification provided that 445 no similar claims are made against Microsoft. This approach meets 446 Microsoft's goal of ensuring the enforcability of the Reciprocal 447 Rights clause in the patent license while avoiding the need for any 448 party to actually obtain a license. 450 3.1.7. Non Participant Claims 452 Any changes made to the IETF patent policy must bear in mind the fact 453 that it is only binding on IETF participants. If the policy is 454 changed in ways that Patent Rights Holders who are also Implementors 455 consider to be too onerous, they may cease participating. 457 Patent claims by non-participants have in practice proved far more 458 problematic than those brought by participants. A Patent Rights 459 Holder who is also an Implementor has to consider both the 461 3.2. Other Standards Bodies 463 3.2.1. World Wide Web Consortium 465 3.2.2. OASIS 467 3.2.3. Other 469 Some standards bodies begin all proceedings, including face to face 470 meetings and conference calls with a formal recitation of the IPR 471 (and frequently anti-trust) requirements. 473 3.2.4. Stakeholder Concerns in IETF Process 475 3.2.4.1. Disclosure 477 All parties should have equal understanding of the consequences of a 478 decision. Effective disclosure of IPR claims is thus essential. 480 3.2.4.2. Predicatability 482 When a proposal is made the parties should be able to predict the 483 likely response. 485 3.2.4.3. Fairness 487 No party should be able to benefit from unfair practices such as 488 concealling the existence of IPR or bad-faith offers of Patent Access 489 on deliberately ambiguous terms. 491 4. Proposals 493 4.1. Increased NOTE WELL visibility 495 Display of NOTE WELL advice should be more prominent than is 496 currently the case. In particular ackinowledgement of NOTE WELL 497 notification should become a required element of subscription to all 498 IETF mailing lists, including lists discussing formation of BOFs. 500 4.2. Specify IPR terms in chartering discussion 502 The charter of a Working Group SHOULD specify the IPR terms which 503 proposals MUST meet in order to be accepted as Working Group work 504 items. In cases where the IPR situation is unclear the chater SHOULD 505 specify clarification of the IPR terms as a work item. 507 While a Working Group does not always meet the objectives set out in 508 its charter, the objectives should always be understood at the 509 outset. It is exceptionally unlikely that a Working Group that is 510 founded with the purpose of developing a RANDZ protocol is going to 511 subsequently choose a Royalty RAND alternative. 513 In some cases a Working Group will be chartered to create a protocol 514 for a technology that is subsequently discovered to be subject to 515 credible Patent claims. While this situation is unavoidable it does 516 not have to necessarily lead to the collapse of the Working Group as 517 has happened in the past. Stating the criteria for acceptable IPR 518 terms at the outset puts the Patent Rights Holder on notice of the 519 criteria they must meet for acceptance and provides them with an 520 assurance that the terms will be accepted if offered. 522 The purpose of a Working Group charter is to avoid unnecessary and 523 repetative discussions that are unproductive. Working Groups are 524 routinely chartered to rule out of scope discussions that would 525 duplicate the work of other Working Groups or have been found to be 526 unproductive in the past. These include definitions of SPAM, 527 development of PKIs in groups not charterted for that express 528 purpose, development of new cryptographic algorithms and the like. 529 The authors of Working Group Charters should be encouraged to add 530 discussion of IPR terms to this list. 532 4.3. Reuse already existing IPR Policy terms 534 Working Groups should be encouraged to require compliance with IPR 535 policy that has already been developed rather than develop new IPR 536 terms within IETF process. In particular requiring compliance with 537 the existing W3C policy requirements is recommended. 539 Reuse of existing IPR terms reduces the work that Implementors and 540 must perform to decide if the terms are acceptable and for Patent 541 Rights Holders to arrive at acceptable terms. 543 The less decision time required by the lawyers, the greater the 544 chance of a satisfactory result. Standardized terms transform a 545 legal question to be decided by the legal department into a business 546 question to be decided by the business unit. 548 Standardized terms have the further benefit of being more predictable 549 if the parties do end up in a potential litigation situation. 550 Standardized terms make it more likely that an applicable precedent 551 can be found. While precedent is not binding in all legal traditions 552 it is still informative in jurisdictions where it is not binding. 554 4.4. Liase with in Discussion in Appropriate Venues 556 Development of IPR policy terms is not core to the mission of the 557 IETF or any othe Internet Standards body. If extended discussion of 558 such issues is required this should be persued in a venue that has 559 the appropriate domain expertise. 561 In addition to developing the policy requirements themselves such a 562 forum might assist in the development of mutually acceptable support 563 materials such as standard Patent Access terms, standard Patent 564 License contracts, NOTE WELL and disclosure agreements for pre- 565 standards activity and the like. 567 Standardization of the legal layer of the Internet becomes 568 increasingly critical as the Internet becomes a social 569 infrastructure. 571 5. Acknowledgements 572 6. IANA Considerations 574 This draft does not require any action by IANA. 576 7. Security Considerations 578 IPR management rasies critical security issues for all the 579 stakeholders involved. IPR is an asset which stakeholders must 580 carefully consider in deciding to grant access 582 8. Normative References 584 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 585 Requirement Levels", BCP 14, RFC 2119, March 1997. 587 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 588 Adams, "X.509 Internet Public Key Infrastructure Online 589 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 591 Authors' Addresses 593 Phillip Hallam-Baker 594 VeriSign Inc 596 Email: pbaker@verisign.com 598 Daniel Weitzner 599 World Wide Web Consortium 601 Email: djweitzner@w3.org 603 Full Copyright Statement 605 Copyright (C) The IETF Trust (2007). 607 This document is subject to the rights, licenses and restrictions 608 contained in BCP 78, and except as set forth therein, the authors 609 retain all their rights. 611 This document and the information contained herein are provided on an 612 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 613 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 614 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 615 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 616 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 617 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 619 Intellectual Property 621 The IETF takes no position regarding the validity or scope of any 622 Intellectual Property Rights or other rights that might be claimed to 623 pertain to the implementation or use of the technology described in 624 this document or the extent to which any license under such rights 625 might or might not be available; nor does it represent that it has 626 made any independent effort to identify any such rights. Information 627 on the procedures with respect to rights in RFC documents can be 628 found in BCP 78 and BCP 79. 630 Copies of IPR disclosures made to the IETF Secretariat and any 631 assurances of licenses to be made available, or the result of an 632 attempt made to obtain a general license or permission for the use of 633 such proprietary rights by implementers or users of this 634 specification can be obtained from the IETF on-line IPR repository at 635 http://www.ietf.org/ipr. 637 The IETF invites any interested party to bring to its attention any 638 copyrights, patents or patent applications, or other proprietary 639 rights that may cover technology that may be required to implement 640 this standard. Please address the information to the IETF at 641 ietf-ipr@ietf.org. 643 Acknowledgment 645 Funding for the RFC Editor function is provided by the IETF 646 Administrative Support Activity (IASA).