idnits 2.17.1 draft-brim-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 == Line 79 has weird spacing: '... IPR in the I...' -- 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 4, 2002) is 7874 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 559 looks like a reference -- Missing reference section? '6' on line 562 looks like a reference -- Missing reference section? '1' on line 547 looks like a reference -- Missing reference section? '4' on line 556 looks like a reference -- Missing reference section? '2' on line 550 looks like a reference -- Missing reference section? '3' on line 553 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 3 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 4, 2003 October 4, 2002 6 Guidelines for Working Groups on Intellectual Property Issues 7 draft-brim-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 4, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 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) . . . . . . . . . . 6 52 4.5 Secure Shell (SecSH) . . . . . . . . . . . . . . . . . . . . . 7 53 4.6 IDN (Internationalized Domain Name) . . . . . . . . . . . . . 7 54 5. General Principles . . . . . . . . . . . . . . . . . . . . . . 8 55 5.1 Types of IPR . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 5.2 When to think about IPR . . . . . . . . . . . . . . . . . . . 9 57 5.3 IPR as a Technology Evaluation Factor . . . . . . . . . . . . 9 58 5.4 Patents versus Pending Patents . . . . . . . . . . . . . . . . 10 59 5.5 Applicability: It's Hard to Prove a Negative . . . . . . . . . 10 60 5.6 No Universal License Terms . . . . . . . . . . . . . . . . . . 11 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 62 References (Non-Normative) . . . . . . . . . . . . . . . . . . 13 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 64 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14 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 assertions in the IETF, 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-encumbered technology contributions. 83 2. The Problem 85 Traditionally the IETF has avoided technologies which were 86 "encumbered" through IPR assertions. However, compromises have been 87 made since before the IETF was born. The "common knowledge" of the 88 IETF, that IPR-encumbered technology was anathema, has never dealt 89 with the fact that the Internet has run on encumbered technologies 90 from the beginning. Nowadays the majority of the useful technologies 91 brought to the IETF have some sort of IPR encumbrance 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 an unencumbered 97 technology over an encumbered alternative may produce a significantly 98 weaker Internet. Sometimes there simply isn't any unencumbered 99 technology in an area. 101 The IETF is not a membership organization. Other standards making 102 bodies may have membership agreements that member organizations must 103 sign and adhere to in order to participate. Membership agreements 104 may include strict procedures for dealing with IPR, or perhaps a 105 requirement that technology must be licensed royalty-free. This is 106 not possible in the IETF. 108 Even if the IETF had membership agreements, they would be difficult 109 to formulate in a way that covered IPR problems, because the IETF's 110 work includes technology from other sources. The IETF can encounter 111 three different IPR situations: 113 o A draft is submitted noting the submitter's IPR claim. 115 o A draft is submitted that a different IETF participant feels is 116 covered by their own IPR. 118 o A draft is submitted and IPR is noted, by the author or by a 119 different IETF participant, that is claimed by an organization 120 that does not participate in the IETF at all. 122 The IETF does not have detailed rules for each situation. The IETF 123 does not force IPR-related behavior on anyone. It only sets criteria 124 for a technology document becoming an Internet standard. Working 125 groups have essentially only one rule they can invoke, (about not 126 participating in activities related to a technology if you do not 127 disclose known IPR). Other than that a working group only has 128 recommendations and requests. 130 Since every case is unique, and there are close to no general rules, 131 working groups need a great deal of freedom in dealing with IPR 132 issues. However, some amount of consistency is important so that 133 both contributors and users of eventual standards can know what to 134 expect. 136 3. The Approach 138 The IETF does not limit itself to IPR-free technology. In fact, at 139 this second you are using a number of IPR-encumbered technologies, 140 just to fetch and read this memo. 142 The organizing principle of this memo is to give working groups as 143 much information as possible to make informed decisions, and then 144 step out of the way. The other IPR working group memos (see the IPR 145 Working Group charter page [1]) lay out what needs to be done once a 146 particular piece of technology is selected as a working group draft. 147 That doesn't help when a working group is trying to decide whether to 148 select a technology or not in the first place. Thus this third memo. 149 We want to build a conceptual framework, a new set of "common 150 knowledge", to make it easier for working groups to deal with 151 intellectual property issues. 153 To do so, we first present "case studies" in Section 4 -- real events 154 that have happened in recent years, and how different working groups 155 dealt with them -- plus notes on possible lessons to be learned. In 156 Section 5, we expand on these lessons to be learned and try to 157 extract general principles. 159 4. Case Studies 161 The best way to know what works is to look at past attempts at 162 dealing with IPR. The following are selected as cases from which 163 general lessons might be extracted. 165 4.1 IPS WG (IP Storage) 167 The IPS Working Group evaluated technology developed outside of the 168 working group, "secure remote password" (SRP, RFC2945 [4]). At the 169 time, there was one known IPR assertion, and the proposed licensing 170 terms were apparently reasonable. SRP had become a proposed standard 171 without going through any working group, so IETF participants may 172 have been less likely to notice it in order to make statements about 173 IPR. In any case, two more possible IPR claims were uncovered after 174 the IPS working group had already decided to make SRP required. One 175 of the possible IPR holders did not make a strong IPR assertion 176 itself, and did not want to take the time to determine whether it 177 actually had a claim, though it acknowledged it might have a claim. 178 Also, in both cases it was difficult to obtain information on 179 possible licensing terms, even though words like reasonable and non- 180 discriminatory were used in IPR statements, and rumors of what they 181 might be did like not sound good. The working group took the 182 assertions, potential and otherwise, very seriously, and decided not 183 to use SRP after all, even though they had already chosen it based on 184 other criteria. 186 Lessons: 188 o IPR assertions may appear at any time in the standards process. 190 o Take impreciseness seriously. Attempt to get clarification on 191 both IPR claims and licensing terms. 193 4.2 PEM and PKI issues 195 PEM (Privacy-Enhanced Mail) wanted to use public key technology. In 196 the mid-90s, the basic principles of public key infrastructure had 197 been patented for years. The patent holder had shown a tendency to 198 actively enforce its rights, and to prefer software sales to 199 licensing. This was seen as a significant potential encumbrance, one 200 which could possibly interfere with the easy development of the 201 Internet. However, there was no alternative technology that came 202 close to its capabilities. Adopting an alternative would have 203 damaged the Internet's health and flexibility even more than adopting 204 a technology with IPR encumbrance. The case was so compelling that 205 the working group decided to move forward on standardizing it and 206 even requiring it. One factor which was noted was that the patents 207 were mature, and would expire within a few years. That meant that 208 although the impact might be significant to start with, it would not 209 be in the long run. This lowered the perceived risk of using the 210 encumbered technology. 212 Lessons: 214 o IPR is just one issue in deciding whether to adopt a technology. 216 o IPR is not an all or nothing issue. There are different types and 217 levels of encumbrance. 219 o The IPR's lifecycle phase can be a consideration. 221 4.3 CDI WG (Content Distribution Internetworking) 223 The CDI Working Group laid out an overall architecture and found that 224 a number of included technologies had IPR claims associated with 225 them, based on work done before the working group was started. The 226 working group decided there was little chance of producing 227 alternative technologies which were as useful and which did not run 228 up against these IPR assertions. As usual, there was no good way to 229 evaluate assertions and possible licensing terms until after the 230 technology had been completely specified (at the earliest). 232 Working group participants generally thought they had a good idea 233 what to expect from each other, and that the ultimate benefits of 234 using the technologies outweighed their encumbrance. The working 235 group decided not to consider IPR as an issue at all in determining 236 which technologies to adopt. 238 Lessons: 240 o Past experience can be used as a significant factor in evaluating 241 the possible impact of IPR. 243 4.4 VRRP (Virtual Router Redundancy Protocol) 245 The working group was standardizing VRRP based on a protocol 246 developed outside the IETF. The IPR holder supported that protocol 247 and stated that it would license its IPR for that protocol if it 248 became the standard, but not for the similar protocol the working 249 group was developing. The working group decided to go ahead and 250 standardize its protocol anyway. The IPR holder has only asserted 251 its patent when someone else asserted a patent against it. There is 252 no evidence that the working group actually thought about the 253 implications of the IPR when it went ahead with its choice of 254 protocol. 256 Lessons: 258 o IPR assertions should never be disregarded without good cause. 259 Due diligence should be done to understand the consequences of 260 each assertion. 262 4.5 Secure Shell (SecSH) 264 This was primarily a trademark issue, not a patent issue, since the 265 patent issue had been worked out outside of the IETF. The holder of 266 a trademark wanted the IETF to stop using "SSH" in the names and text 267 of its proposed standards. The working group thought through the 268 details of the claims, and possible implications and risks, and 269 decided to go ahead and continue using the names as they are now. 270 This issue is still being worked through. 272 Lessons: 274 o The working group can evaluate IPR assertions not only for their 275 possible validity, but also for the risk of misjudging that 276 validity. The impact of honoring the IPR claim may be major or 277 minor. 279 4.6 IDN (Internationalized Domain Name) 281 The IDN working group dealt with a number of IPR assertions. Several 282 were made which did not overlap with the technology -- the IPR 283 asserters said the patents were being announced just in case the 284 working group decided to go that way. In one case, even though a 285 patent was announced as purely defensive, the working group 286 participants investigated the claims themselves. As a group, they 287 concluded that it did not overlap. 289 For a time, one of the working group chairs worked for a company that 290 intended to assert a patent but had not done so yet. He had to be 291 very careful not to participate in discussions pertaining to that 292 patent, or to guide the working group toward the technology he had an 293 interest in. 295 In one case, an IPR claimer asserted that the working group's 296 documents, and in fact the IETF as a whole, were infringing on its 297 rights. Individual working group participants consulted with their 298 legal advisers, concluded that the claims would not overlap the 299 working group's developing technology, and decided to ignore the 300 claims. This was reflected in the direction the group as a whole 301 decided to take. 303 In 2000 the IDN working group discovered a patent that some 304 participants thought might apply to one of their main drafts. If it 305 did, it could affect their work profoundly -- to the extent that some 306 suggested that if they could not work out reasonable licensing terms 307 with the IPR holder they might just disband. As a group and 308 individually, participants corresponded with IPR holder in order to 309 get an explicit statement of licensing terms, preferably royalty- 310 free. By doing so they gained at least some understanding of the IPR 311 holder's intentions and philosophy. Since the patent holder seemed 312 to have an interest in using the patent for profit, the group 313 discussed the issues on its mailing list. They overtly talked about 314 how they could change their proposed technology to avoid having to 315 contest the patent, and the extent to which the patent might be 316 countered by claims of prior art. Meanwhile, individually they were 317 talking to their legal advisors. Slowly, a collective opinion formed 318 that the working group documents did not infringe on the patent. 319 Since then, the patent has been ignored. However, they are keeping a 320 watchful eye out for continuation patents which might have already 321 been submitted. 323 Lessons: 325 o It's sometimes beneficial to push IPR claimants to find out what 326 they think their claims cover and what their licensing terms are. 328 o It's all right, and sometimes beneficial, to discuss IPR claims on 329 the group list (but remember that neither the IETF nor any working 330 group takes a stand on such claims as a body, and the group is not 331 the best place to get legal advice). 333 o Possibilities of prior art should be considered. 335 5. General Principles 337 Given the case studies above, here are a few principles that working 338 groups can start with in dealing with IPR. Of course every working 339 group needs to follow its own consensus, and actual treatments will 340 vary as much as they have in the past. 342 5.1 Types of IPR 344 A primer on the different types of IPR would be large, unreliable, 345 and redundant with other Working Group documents [2][5][6]. For 346 informal exploration, see those documents and other relevant sources 347 on the web. Readers with more serious concerns should consult their 348 legal advisors. In the United States, briefly: 350 o Trademarks indicate the sources of goods. Servicemarks indicate 351 the sources of services. They protect the use of particular marks 352 or similar marks. 354 o Copyrights protect the expressions of ideas (not the ideas 355 themselves), in almost any form, and allow "fair use". Copyrights 356 expire but they can be renewed. 358 o Patents protect "inventions". They expire (utility patents expire 359 after 20 years), but follow-on patents can cover similar 360 technologies and can have nearly the same implications for use in 361 the Internet as the original patents. 363 5.2 When to think about IPR 365 This memo does not describe IPR procedures for document authors or 366 IPR asserters. Rather, this memo is for working groups that are 367 trying to decide what to do about IPR-encumbered technology 368 contributions. A working group as a whole (as opposed to individual 369 contributors or IPR holders) needs to think about IPR issues: 371 o when examining a technology, and deciding whether to initiate work 372 on it. 374 o when deciding whether to adopt a draft as a working group 375 document. 377 o when choosing between two or more working group drafts that use 378 different technologies. 380 o when deciding whether to depend on a technology developed outside 381 the working group. 383 o when comparing different kinds of IPR encumbrances. 385 At each of these times, the working group should solicit disclosure 386 of IPR assertions and licensing terms. A working group's job will be 387 a lot easier if IPR details are discovered early. 389 5.3 IPR as a Technology Evaluation Factor 391 How do you weigh IPR assertions against other issues when deciding 392 whether to adopt a technology? 394 The ultimate goal of the IETF is to promote the overall health, 395 robustness, flexibility and utility of the Internet infrastructure. 396 We base architectural decisions on our long-term extrapolations of 397 requirements, by thinking in these terms. When considering a 398 particular technology, we compare it with other technologies not just 399 for its elegance of design in and of itself, but also for how it fits 400 in the bigger picture. This is done at multiple levels. It is 401 examined for how it fits into the overall design of the working 402 group's output, how it fits into the particular Internet 403 infrastructure area, how it fits with work going on in other areas, 404 and how it fits in the long view of the Internet architecture. 406 Similarly, when evaluating a technology, a working group considers 407 IPR claims on it. The issue is not whether a particular piece of 408 technology is "encumbered" -- we use encumbered technology every 409 minute. The question is how much an encumbrance will limit the 410 technology's usefulness in building a robust, highly useful Internet. 411 Thus, the only significant questions are: is the IPR claim relevant, 412 and if so what are the terms under which the technology can be used? 413 When technology is encumbrance-free the answer is easy. When it is 414 IPR-encumbered, some terms make the encumbrance insignificant 415 compared to the engineering issues. Other terms can make a 416 technology unusable even if it is perfect otherwise. 418 5.4 Patents versus Pending Patents 420 The IETF does not (cannot) expect IPR asserters to tell a working 421 group specifically how they think a particular patent applies. If a 422 patent has already been granted, the IETF can reasonably expect 423 disclosure of the patent number, which will allow working group 424 participants to explore details of the claims. If a patent has not 425 yet been granted, significantly less information is available. In 426 most countries patent applications are published 18 months after they 427 are filed, but in the USA that is optional. Details of pending 428 patent claims can be modified at any time by the claim submitter 429 before the patent is granted. It is not known before then what 430 rights will actually be granted. Finally, rights can be contested in 431 court, and nothing is final until the courts decide. All the IETF 432 can expect regarding a pending patent is disclosure that it exists 433 and possibly some statement about licensing terms. 435 5.5 Applicability: It's Hard to Prove a Negative 437 A working group needs to make its own decision about what level of 438 confidence it needs as to whether IPR is applicable. However, 439 perfect knowledge is not a worthwhile goal. 441 In general, a working group should strive to find out about all IPR 442 claims related to technologies it is considering, and at least the 443 general facts about licensing terms for each case -- for example 444 whether the terms will be "reasonable and non-discriminatory". 446 Working group participants should also investigate possibilities of 447 prior art which would counter the IPR claims. However, even if the 448 working group participants do exhaustive searches, both externally 449 and internally to their employers, it is impossible to prove that a 450 particular technology is not covered by a particular IPR claim, let 451 alone proving that it is not covered by any IPR claim. Anything a 452 working group adopts may, in the future, turn out to be encumbered, 453 years later. Claims are open to interpretation even after rights are 454 granted. Drafts can be very fluid, even up to the time of last call, 455 and IPR encumbrances may unknowingly be taken on at any time. 457 The level of confidence needed to consider IPR when evaluating a 458 technology is often not hard to get to. There are cases where risk 459 is high (e.g. where licensing terms may be onerous) and thus a high 460 level of confidence about applicability is needed, but history shows 461 that most of the time "rough" confidence is good enough. In any 462 case, perfect confidence is usually impossible. 464 5.6 No Universal License Terms 466 Licensing terms vary continuously across a range from prohibitive to 467 no license at all. In general there are four classes of situation 468 which will be encountered. 470 o No license - licenses per se are not available. Local 471 regulations, if any, apply. 473 o Public domain - the technology is explicitly made available to 474 all, without any IPR encumbrance. 476 o General "free" license - the technology is made available free of 477 charge. There is a form of this license which invokes 478 "reciprocity", in which the technology may be used as long as the 479 licensee allows the IPR holder to use the licensee's technology in 480 the same area under comparable terms. A requirement for general 481 reciprocity is also possible, under which the technology is made 482 available as long as the licensee does not enforce any IPR claims 483 against the licenser. 485 o "Reasonable and non-discriminatory" (RAND) terms - the license is 486 granted based on some terms which may include reciprocity. The 487 terms can vary tremendously. Even when IPR assertions do use 488 words such as "reasonable", "fair", and "non-discriminatory", 489 working groups should keep in mind that these words have no 490 objective legal definition, at least not in this context. 492 Many IPR holders do not like to publish explicit, specific terms 493 under which they will issue licenses. They may use standard terms 494 for many licensees, but they prefer to negotiate terms for some. 495 Therefore, do not expect any IPR claim to lay out detailed blanket 496 terms for licensing. 498 Vaguer terms are not necessarily better or worse than more specific 499 terms. If an IPR assertion lists only vague terms, that doesn't mean 500 the terms that will be offered in individual licenses will be any 501 worse than those offered in an IPR assertion that makes very specific 502 statements. Obviously, if an IPR claimant refuses to suggest any 503 terms at all, the working group is going to have trouble evaluating 504 the future utility of the technology. 506 Recall that words such as "reasonable", "fair", and "non- 507 discriminatory" have no objective legal definition. The best way to 508 find out what an IPR holder really means by those terms is to ask, 509 explicitly. It also helps to gather knowledge about licenses 510 actually issued, for that technology or for others, and about other 511 experiences with the IPR holder. 513 Despite the fact that IPR holders often don't like to publish 514 explicit terms, there are levels of vagueness, and individuals and 515 even working groups can sometimes successfully push an IPR holder 516 toward less vagueness. The employers of IETF participants all know 517 that that IETF prefers explicit terms, and do feel pressure to 518 produce them. 520 If a working group is dissatisfied with the confidence level it can 521 obtain directly about licensing terms for a particular technology, it 522 can possibly extrapolate from history. As part of the standards 523 process as described in RFC2026 [2], in order for licensed technology 524 to become a draft standard, at least two independent licenses need to 525 have been issued. If the IPR holder for the technology the working 526 group is considering has licensed other technology in the past, there 527 is a record of the sorts of terms they are willing to grant, at least 528 in those two specific cases. This sort of thing is weak but if 529 everything counts, it may be some indication. 531 6. Security Considerations 533 This memo relates to IETF process, not any particular technology. 534 There are security considerations when adopting any technology, 535 whether IPR-encumbered or not. A working group should take those 536 security considerations into account as one part of evaluating the 537 technology, just as IPR is one part, but they are not issues of 538 security with IPR procedures. 540 There may be security issues with procedures for dealing with IPR, 541 but those are not technical security issues. They have more to do 542 with unintentionally revealing corporate intellectual property 543 through human activity than risking anything when using a protocol. 545 References (Non-Normative) 547 [1] IETF, "IPR Working Group web page", 2002, . 550 [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 551 9, RFC 2026, October 1996. 553 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 554 Levels", BCP 14, RFC 2119, March 1997. 556 [4] Wu, T., "The SRP Authentication and Key Exchange System", RFC 557 2945, September 2000. 559 [5] Bradner, S., "Intellectual Property Rights in IETF Technology", 560 draft-bradner-ipr-technology-00 (work in progress), July 2002. 562 [6] Bradner, S., "IETF Rights in Submissions", draft-bradner- 563 submission-rights-00 (work in progress), June 2002. 565 Author's Address 567 Scott Brim 568 Cisco Systems, Inc. 569 146 Honness Lane 570 Ithaca, NY 14850 571 USA 573 EMail: sbrim@cisco.com 575 Full Copyright Statement 577 Copyright (C) The Internet Society (2002). All Rights Reserved. 579 This document and translations of it may be copied and furnished to 580 others, and derivative works that comment on or otherwise explain it 581 or assist in its implementation may be prepared, copied, published 582 and distributed, in whole or in part, without restriction of any 583 kind, provided that the above copyright notice and this paragraph are 584 included on all such copies and derivative works. However, this 585 document itself may not be modified in any way, such as by removing 586 the copyright notice or references to the Internet Society or other 587 Internet organizations, except as needed for the purpose of 588 developing Internet standards in which case the procedures for 589 copyrights defined in the Internet Standards process must be 590 followed, or as required to translate it into languages other than 591 English. 593 The limited permissions granted above are perpetual and will not be 594 revoked by the Internet Society or its successors or assigns. 596 This document and the information contained herein is provided on an 597 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 598 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 599 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 600 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 601 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 603 Acknowledgement 605 Funding for the RFC Editor function is currently provided by the 606 Internet Society.