idnits 2.17.1 draft-ietf-ipr-submission-rights-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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.) -- The abstract seems to indicate that this document obsoletes RFC10, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document updates RFC2026, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 51 has weird spacing: '...usually assig...' == Line 240 has weird spacing: '...for the purpo...' == Line 595 has weird spacing: '...for the purpo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2003) is 7713 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: 'IETF-IPR' is mentioned on line 310, but not defined -- No information found for draft-iprwg-technology - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IETF IPR' Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bradner 3 Internet-Draft Harvard University 4 Editor 5 March 2003 7 IETF Rights in Submissions 9 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC 2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 33 The IETF policies about rights in submissions to the IETF are 34 designed to ensure that IETF contributions can be made available to 35 the IETF and Internet communities while permitting the authors to 36 retain as many rights in the document as possible. This memo details 37 the IETF policies on rights in submissions to the IETF. It also 38 describes the objectives that the policies are designed to meet. This 39 memo updates RFC 2026 and with RFC XXXY, replaces RFC 10 of RFC 2026. 40 [ note to RFC editor - replace XXXY with number of IETF IPR ] 42 Copyright (C) The Internet Society. (2002) 44 1. Introduction 45 Under the laws of most countries and current international treaties 46 (for example the "Berne Convention for the Protection of Literary and 47 Artistic Work" [Berne]), authors obtain numerous rights in the works 48 they produce automatically upon producing them. These rights include 49 copyrights, moral rights and other rights. In many cases, if the 50 author produces a work within the scope of his or her employment, 51 most of those rights are usually assigned (The Berne convention says 52 some rights are "inalienable") to the employer, either by operation 53 of law or, in many cases, under contract. 55 In order for works to be used within the IETF process, certain 56 limited rights in all contributions must be granted to the IETF and 57 Internet Society (ISOC). In addition, contributors must make 58 representations to IETF and ISOC regarding their ability to grant 59 these rights. These necessary rights and representations have until 60 now been laid out in Section 10 of [RFC 2026]. In the years since 61 [RFC 2026] was published there have been a number of times when the 62 exact intent of Section 10 has been the subject of vigorous debate 63 within the IETF community. The aim of this document is to clarify 64 various ambiguities in Section 10 of [RFC 2026] that led to these 65 debates and to amplify the policy in order to clarify what the IETF 66 is currently doing. 68 Sections 2 and 3 of this document address the rights in submissions 69 to the IETF previously covered by Section 10 of [RFC 2026] and the 70 "Note Well" explanatory text presented at many IETF activities. 71 Section 4 gives definitions used in describing these policies. 72 Section 5, 6 and 7 then explain the rationale for these provisions, 73 including some of the clarifications that have become understood 74 since the adoption of [RFC 2026]. The rules and procedures set out 75 in this document are not intended to substantially modify or alter 76 IETF's or ISOC's current policy toward contributions and submissions 77 made to the IETF. 79 A companion document [IETF IPR] will deal with rights in technologies 80 developed or specified as part of the IETF process. This document is 81 not intended to address those issues. 83 The rights addressed in this document fall into the following 84 categories: 86 o rights to make use of contributed material 87 o copyrights in IETF documents 88 o rights to produce derivative works 89 o rights to use trademarks 91 This document is not intended as legal advice. If you would like a 92 legal interpretation of your rights or the rights of the IETF in any 93 contributions you make, you are advised to consult your own legal 94 advisor. 96 2. Rights in IETF Submissions 97 2.1. General Policy 99 In all matters of copyright and document procedures, the intent is to 100 benefit the Internet community and the public at large, while 101 respecting the legitimate rights of others. 103 2.2 Confidentiality Obligations 105 No contribution that is subject to any requirement of confidentiality 106 or any restriction on its dissemination may be considered in any part 107 of the Internet Standards Process, and there must be no assumption of 108 any confidentiality obligation with respect to any such contribution. 109 Each contributor hereby agrees that any statement in a contribution, 110 whether generated automatically or otherwise, that states or implies 111 that the contribution is confidential or subject to any privilege, 112 can be disregarded for all purposes, and will be of no force or 113 effect. 115 2.3. Granting of Rights and Permissions 117 By submission of a contribution, each person actually submitting the 118 contribution is deemed to agree to the following terms and 119 conditions, and to grant the following rights, on his or her own 120 behalf, on behalf of the organization (if any) the contributor 121 represents and on behalf of the owners of any proprietary rights in 122 the contribution. 124 a. To the extent that the contribution or any portion thereof is 125 protected by copyright and other rights of authorship, the 126 contributor, the organization he or she represents or is sponsored 127 by (if any) and the owners of any such proprietary rights in the 128 contribution, grant an perpetual, irrevocable, non-exclusive, 129 royalty-free, world-wide right and license to the ISOC and the 130 IETF under all intellectual property rights in the contribution: 132 (A) to copy, publish, display and distribute the contribution as 133 part of the IETF standards process, 135 (B) unless explicitly disallowed in the written terms of the 136 contribution [pursuant to one of the notices contained in 137 Section 3.3 below], to prepare derivative works that are based 138 on or incorporate all or part of the contribution within the 139 IETF standards process, the license to such derivative works to 140 be of a scope no wider than the license to the original 141 contribution, and 143 (C) to reproduce any trademarks, service marks or trade names 144 which are included in the contribution solely in connection 145 with the reproduction, distribution or publication of the 146 contribution and derivative works thereof as permitted by this 147 paragraph, and in all cases reproducing any trademark or 148 service mark identifiers used by the contributor of the 149 contribution. 151 b. The contributor grants the IETF and ISOC permission to reference 152 the name(s) and address(es) of the contributor(s) and of the 153 organization(s) s/he represents or is sponsored by (if any). 155 c. Every copy of a IETF document made pursuant to the licenses 156 granted under paragraph (a)(A) above, and all derivative works 157 made pursuant to the licenses granted under paragraph (a)(B) 158 above, must include, in unaltered form, the notices included in 159 such contribution pursuant to Section 3 below. 161 2.4 Representations and Warranties. With respect to each contribution, 162 each contributor represents that to the best of his or her knowledge 163 and ability: 165 a. The contribution properly acknowledges all major contributors. A 166 major contributor is any person who has materially or 167 substantially contributed to the contribution. 169 b. No information in the contribution is confidential and the IETF, 170 ISOC, and its affiliated organizations may freely disclose any 171 information in the contribution. 173 c. There are no limits to the contributor's ability to make the 174 grants acknowledgments and agreements herein that are personally 175 and reasonably known to the contributor. 177 d. The contributor has not intentionally included in the 178 contribution any material which is defamatory or untrue or which 179 is illegal under the laws of the jurisdiction in which the 180 contributor has his or her principal place of business or 181 residence. 183 e. All trademarks, trade names, service marks and other proprietary 184 names used in the contribution and personally and reasonably known 185 to the contributor are clearly designated as such where 186 reasonable. 188 2.5 The contributor acknowledges that the ISOC and IETF have no duty to 189 publish or otherwise use or disseminate any contribution. The ISOC 190 and the IETF reserve the right to withdraw or cease using any 191 contribution that does not comply with the requirements of Sections 192 2.3 and 2.4 above. 194 2.6 Contributors who claim trademark rights to terms in their 195 contributions are requested to specifically state what conditions 196 apply to implementers of the technology relative to the use of any 197 claimed trademarks. Such statements should be submitted in the same 198 way as is done for other intellectual property claims. (see [IETF 199 IPR] sec 6) 201 3. Copyright notice required in IETF Documents 203 The IETF requires that a copyright notice and disclaimer be 204 reproduced verbatim in all IETF Documents. This requirement protects 205 IETF and its participants from liabilities connected with these 206 documents. The copyright notice also alerts readers that the 207 document is an IETF document, and that ISOC claims copyright rights 208 in certain aspects of the document, such as its layout, the RFC 209 numbering convention and the prefatory language of the document. 210 This legend is not intended to imply that ISOC has obtained ownership 211 of the contribution itself, which is retained by the author(s) or 212 remains in the public domain, as applicable. 214 Additional copyright notices are not permitted in IETF documents 215 except in the case where the document is the product of a joint 216 development effort between the IETF and another standards development 217 organization. Such exceptions must be approved on an individual 218 basis by the IAB. 220 3.1 Copyright notice and disclaimer 222 One of the following two copyright notice and disclaimers shall be 223 included at the end of all IETF documents. 225 3.1.1 Notice for documents where the right to produce derivative works 226 has not been withheld. (See sec 5.3 for a discussion on derivative 227 works.) 229 "Copyright (C) The Internet Society (year). Except as set forth 230 below, authors retain all their rights. 232 This document and translations of it may be copied and furnished to 233 others, and derivative works that comment on or otherwise explain it 234 or assist in its implementation may be prepared, copied, published 235 and distributed, in whole or in part, without restriction of any 236 kind, provided that the above copyright notice and this paragraph are 237 included on all such copies and derivative works. However, this 238 document itself may not be modified in any way, such as by removing 239 the copyright notice or references to the Internet Society or other 240 Internet organizations, except as needed for the purpose of 241 developing Internet standards in which case the procedures for rights 242 in submissions defined in the IETF Standards Process must be 243 followed, or as required to translate it into languages other than 244 English. 246 The limited permissions granted above are perpetual and will not be 247 revoked by the Internet Society or its successors or assigns. 249 This document and the information contained herein is provided on an 250 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE 251 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 252 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 253 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 254 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 255 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 257 3.1.2 Notice for documents where the right to produce derivative works 258 has been withheld. (See sec 5.3 for a discussion on derivative 259 works.) 261 "Copyright (C) The Internet Society (year). Except as set forth 262 below, authors retain all their rights. 264 This document and translations of it may be copied and furnished to 265 others provided that the above copyright notice and this paragraph 266 are included on all such copies. However, this document itself may 267 not be modified in any way, such as by removing the copyright notice 268 or references to the Internet Society or other Internet 269 organizations, except as required to translate it into languages 270 other than English. 272 The limited permissions granted above are perpetual and will not be 273 revoked by the Internet Society or its successors or assigns. 275 This document and the information contained herein is provided on an 276 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE 277 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 278 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 279 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 280 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 281 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 283 3.2 Notices re. Derivative Works and publication rights. 285 In addition to the foregoing, each IETF Internet Draft must contain 286 one of the following three notices regarding derivative works and 287 publication rights on it's first page: (See sec 5.3 for a discussion 288 on derivative works.) 290 a. This document is an Internet-Draft and is subject to all 291 provisions of section 2 of RFC XXXX. By submitting this Internet- 292 Draft, I certify that any applicable patent or other IPR claims of 293 which I am aware have been disclosed in accordance with RFC XXXY. 295 b. This document is an Internet-Draft and is subject to all 296 provisions of Section 2 of RFC XXXX except that the right to 297 prepare revised versions of this specification is not granted. By 298 submitting this Internet-Draft, I certify that any applicable 299 patent or other IPR claims of which I am aware have been disclosed 300 in accordance with RFC XXXY. 302 c. This document is an Internet-Draft and is subject to all 303 provisions of Section 2 RFC XXXX, but the author does not provide 304 the IETF with any rights other than to publish as an Internet- 305 Draft. By submitting this Internet-Draft, I certify that any 306 applicable patent or other IPR claims of which I am aware have 307 been disclosed in accordance with RFC XXXY. 309 [ note to the RFC Editor - XXXX above to be replaced with the number 310 of this document and XXXY to be replaced the number of [IETF-IPR] ] 312 The first statement is required for all documents that might be 313 submitted for Standards Track publication. The primary motivation is 314 the IETF retains change control, thus permitting augmenting the 315 original document to clarify or enhance the protocol defined by the 316 document. 318 The second statement is used when "republishing" standards produced 319 by other (non-IETF) standards organizations, industry consortia or 320 individual companies. These are typically published as Informational 321 RFCs, and does not require change control being ceded to the IETF. 322 Basically, these documents convey information for the Internet 323 community. 325 The third statement is used when the documents purpose is to provide 326 background information to educate and to facilitate discussions 327 within IETF groups and the document is not intended to be published 328 as an RFC. 330 4. Definitions 331 4.1 contribution: in the context of this memo, a contribution to the 332 IETF is any submission intended by the contributor for publication as 333 an Internet Draft or RFC and any statements made within the context 334 of an IETF process. Such statements include verbal statements in IETF 335 meetings, as well as written and electronic communications made at 336 any time or place, which are addressed to 337 o the IETF plenary session, 338 o any IETF working group or portion thereof, 339 o the IESG, or any member thereof on behalf of the IESG, 340 o the IAB or any member thereof on behalf of the IAB, 341 o any IETF mailing list, including the IETF list itself, any working 342 group or design team list, or any other list functioning under 343 IETF auspices, 344 o the RFC Editor or the Internet-Drafts function 346 Statements made outside of an IETF meeting, mailing list or other 347 function, that are clearly not intended to be input to an IETF 348 activity, group or function, are not contributions in the context of 349 this memo. 351 4.2 IETF Standards Process: the activities undertaken by the IETF in any 352 of the settings described in 4.1 above. 354 4.3 contributors: individuals making contributions 356 4.4 IETF documents: RFCs and Internet Drafts. 358 4.5 RFC: the basic publication series for the IETF. RFCs are published 359 by the RFC Editor and once published are never modified. (See [RFC 360 2026] sec 2.1) 362 4.6 Internet Draft: temporary documents used in the IETF process. 363 Internet Drafts are published by the IETF Secretariat and have a 364 nominal maximum lifetime in the Secretariat's public directory of 6 365 months after which they are removed. Since Internet Drafts are 366 archived many places on the Internet there is no effective limit on 367 their actual lifetime. Internet Drafts that are under active 368 consideration by the IESG are not removed from the Secretariat's 369 public directory until that consideration is complete, in addition, 370 the author of an Internet Draft can request that the lifetime in the 371 Secretariat's public directory be extended before the expiration. 372 (See [RFC 2026] sections 2.2 and 8) 374 4.7 IETF: In the context of this document, the IETF includes all 375 individuals who participate in meetings, working groups, mailing 376 lists, functions and other activities which are organized or 377 initiated by ISOC, the IESG or the IAB under the general designation 378 of the Internet Engineering Task Force or IETF, but solely to the 379 extent of such participation. 381 4.8 "personally and reasonably known": is used in section two above. 382 It should be read to refer to something the individual knows 383 personally or, because of the job the individual holds, would 384 reasonably be expected to know. This wording is used to indicate 385 that an organization cannot purposely keep an individual in the dark 386 about patents or patent applications just to avoid the notification 387 requirement. But this requirement should not be interpreted as 388 requiring an organization to perform a patent or other IPR search 389 every time one of its employees submits an Internet Draft or reads an 390 Internet Draft submitted by someone else. 392 5. Exposition of why these procedures are the way they are 394 5.1 Rights Granted in Contributions 396 The IETF/ISOC must obtain the right to publish a contribution as an 397 RFC or an Internet Draft from the contributors. 399 A primary objective of this policy is to obtain from the document 400 authors only the non-exclusive rights that are needed to develop and 401 publish IETF documents and to use the contributions in the IETF 402 standards process while leaving all other rights with the authors. 404 The non-exclusive rights that the IETF needs are: 406 a. the right to publish the document 407 b. the right to let the document be freely reproduced in the formats 408 that the IETF publishes it in 409 c. the right to let 3rd parties translate it into languages other 410 than English 411 d. except where explicitly excluded (see sec 3.2), the right to make 412 derivative works within the IETF process. 414 The authors retain all other rights, but cannot withdraw the above 415 rights from the IETF/ISOC. 417 5.2 Rights to use Contributed Material 419 Because, under the laws of most countries and applicable 420 international treaties, copyright rights come into existence whenever 421 a work of authorship is created (but see Section 6 below regarding 422 public domain documents), and IETF cannot make use of contributions 423 if it does not have sufficient rights with respect to these copyright 424 rights, it is important that the IETF receive assurances from all 425 contributors that they have the authority to grant the IETF the 426 rights that they claim to grant. Without this assurance, IETF and 427 its participants would run a greater risk of liability to the owners 428 of these rights. 430 To this end, IETF asks contributors to give the assurances in Section 431 2.4 above. These assurances are requested, however, only to the 432 extent of the contributor's reasonable and personal knowledge. (See 433 sec 4.8) 435 5.3 Right to produce derivative works 437 The IETF needs to be able to evolve its documents in response to 438 experience gained in the deployment of the technologies described in 439 the documents, to incorporate developments in research and to react 440 to changing conditions on the Internet and other IP networks. In 441 order to do this the IETF must be able to produce derivatives of its 442 documents; thus the IETF must obtain the right from contributors to 443 produce derivative works. Note though that the IETF only requires 444 this right for the production of derivative works within the IETF 445 standards process. The IETF does not need, nor does it obtain, the 446 right to let derivative works be created outside of the IETF process. 448 The right to produce derivative works is required for all IETF 449 standards track documents and for most non-standards track documents. 450 There are two exceptions to this requirement: documents describing 451 proprietary technologies and documents that are republications of the 452 work of other standards organizations. 454 The right to produce derivative works must be granted (i.e., an 455 Internet Draft must be published with boilerplate "a" from sec 3.2) 456 before an IETF working group can accept a document as a working group 457 document or otherwise work on it. Note: a working group can discuss 458 any Internet Draft with the aim to decide if it should become a 459 working group document, whether or not the right to produce 460 derivative works has been yet granted. For independent submissions, 461 the right to produce derivative works must be granted for all 462 standards track documents before the IESG will issue an IETF Last- 463 Call and, for most non-standards track documents, before the IESG 464 will consider the Internet Draft for publication. 466 The IETF has historically encouraged organizations to publish details 467 of their technologies, even where the technologies are proprietary 468 ones, because understanding how existing technology is being used 469 helps when developing new technology. But organizations that publish 470 information about proprietary technologies are frequently not willing 471 to have the IETF produce revisions of the technologies and then claim 472 that the IETF version is the "new version" of the organization's 473 technology. Organizations which feel this way can specify that the 474 document can be published following the other provisions of this 475 section but withhold the right to produce derivative works. 477 In addition, IETF documents frequently make normative references to 478 standards or recommendations developed by other standards 479 organizations. Since the publications of some standards 480 organizations are not public documents it can be quite helpful to the 481 IETF to republish, with the permission of the other standards 482 organization, some of these documents as IETF documents so that the 483 IETF community can have open access to them to better understand what 484 they are referring to. In these cases the IETF documents can be 485 published without the right for the IETF to produce derivative works. 487 In both of the above cases in which the production of derivative 488 works is excluded, the contributor must include a special legend in 489 the contribution, as specified in section 3.2, in order to notify 490 IETF participants about this restriction. 492 5.4 Rights to use trademarks 494 Contributors may wish to seek trademark or service mark protection on 495 any terms that are coined or used in their contributions. IETF makes 496 no judgment about the validity of any such trademark rights. 497 However, the IETF requires each contributor, under the licenses 498 described in Section 2.3.a above, to grant IETF a perpetual license 499 to use any such trademarks or service marks solely in exercising its 500 rights to reproduce, publish and modify the contribution. This 501 license does not authorize any IETF participant to use any trademark 502 or service mark in connection with any product or service offering, 503 but only in the context of IETF documents and discussions. 505 5.5 Who does this apply to? 507 Rights and licenses granted to the IETF are granted to all 508 individuals noted in section 4.7, irrespective of their employment or 509 institutional affiliation. However, these licenses do not extend 510 broadly to the employers, sponsors or institutions of such 511 individuals, nor do they authorize the individuals to exercise any 512 rights outside the specific context of the IETF standards process. 514 6. Contributions Not Subject to Copyright 516 Certain documents, including those produced by the U.S. government 517 and those which are in the public domain, may not be protected by the 518 same copyright and other legal rights as other documents. 519 Nevertheless, we ask each contributor to grant to the IETF the same 520 rights as he or she would grant, and to make the same 521 representations, as though the contribution were a proprietary 522 document. We ask for these grants and representations only to the 523 extent that the contribution may be protected. We believe they are 524 necessary to protect the IETF, the standards process and all IETF 525 participants, and also because the IETF does not have the resources 526 or wherewithal to make any independent investigation as to the actual 527 proprietary status of any document submitted to it. 529 7. Inclusion of legal notice 531 Section three above defines a copyright notice to be included on IETF 532 documents and in derivative works. The full copyright notice does 533 not need to be included in some specific types of derivative works. 535 a/ in MIBs, PIBs and similar material commonly extracted from IETF 536 documents, the following copyright notice should be included in 537 the body of the material that will be extracted "Copyright (C) 538 The Internet Society. This version of this MIB module is 539 part of RFC xxxx; see the RFC itself for the full legal notices." 540 (Substitute "PIB" for "MIB" in the statement for PIBs.) In the 541 case of MIBs and PIBs this statement should be placed in the 542 DESCRIPTION clause of the MODULE-IDENTITY macro. 544 b/ short excerpts of IETF documents presented in electronic help 545 systems, for example, the DESCRIPTION clauses for MIB variables, 546 do not need to include a copyright notice. 548 8 Security Considerations 550 This memo relates to IETF process, not any particular technology. 551 There are security considerations when adopting any technology, 552 whether IPR- protected or not. A working group should take those 553 security considerations into account as one part of evaluating the 554 technology, just as IPR is one part, but they are not issues of 555 security with IPR procedures. 557 9. References 559 9.1 Normative references 561 [RFC 2026] Bradner, S.[ed], "The Internet Standards Process -- 562 Revision 3", RFC 2026, October 1996 564 [IETF IPR] Bradner, S.[ed] "Intellectual Property Rights in IETF 565 Technology", work in progress: draft-iprwg-technology-00.txt 567 9.2 Informative references 569 [Berne] "Berne Convention for the Protection of Literary and Artistic 570 Work", http://www.wipo.int/treaties/ip/berne/index.html 572 10. Editor's Address 574 Scott Bradner 575 Harvard University 576 29 Oxford St. 577 Cambridge MA, 02138 579 sob@harvard.edu 580 +1 617 495 3864 582 11. Full copyright statement 584 Copyright (C) The Internet Society (2002). Except as set forth 585 below, authors retain all their rights. 587 This document and translations of it may be copied and furnished to 588 others, and derivative works that comment on or otherwise explain it 589 or assist in its implementation may be prepared, copied, published 590 and distributed, in whole or in part, without restriction of any 591 kind, provided that the above copyright notice and this paragraph are 592 included on all such copies and derivative works. However, this 593 document itself may not be modified in any way, such as by removing 594 the copyright notice or references to the Internet Society or other 595 Internet organizations, except as needed for the purpose of 596 developing Internet standards in which case the procedures for rights 597 in submissions defined in the Internet Standards process must be 598 followed, or as required to translate it into languages other than 599 English. 601 The limited permissions granted above are perpetual and will not be 602 revoked by the Internet Society or its successors or assigns. 604 This document and the information contained herein is provided on an 605 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE 606 REPRESENTS (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 607 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 608 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 609 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 610 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 612 12. change log 614 note to RFC Editor - remove this section before publication 616 ver 00 to ver 01 617 misc grammar changes throughout text 618 sec 2.2 - add note about automatic disclaimers 619 sec 2.3a - add "or is sponsored by" remove "unlimited" 620 sec 2.3 B - reword to 'of a scope no wider than the license" 621 sec 2.4a - add deff of major contributor 622 sec 2.6 - 2nd paragraph from sec 5.4 moved here 623 sec 3 - truncate heading 624 sec 3.1 5th pp - add OR IS SPONSORED BY 625 sec 3.1.2 - new section with copyright notice for use where 626 derivative works right are withheld 627 sec 3.2 - added usage guidelines for boilerplates 628 sec 4.1 - add "intended by the contributor" 629 sec 4.6 - add "actual" before lifetime 630 sec 4.8 - reword 631 sec 5.3 - insert "standards" in front of "process" last pp - add 632 "with permission" phrase after "republish" 633 sec 5.4 - change "we require" to "the IETF requires" 634 sec 7/a - add PIBs 635 sec 8 - redo security considerations 636 sec 9.1 - remove IPR ID as normative reference 637 sec 9.2 - add IPR ID as informative reference 638 sec 12 - add changes section 640 ver 01 to 02 swap personally and reasonably 641 abstract - add note about updating 2026 642 sec 3.2 - add patent pledge