idnits 2.17.1 draft-ietf-ipr-3978-incoming-02.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 17. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 619. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 619. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 619. ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. 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.) -- The abstract seems to indicate that this document obsoletes RFC3978, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (17 October 2007) is 6034 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: '-outbound' is mentioned on line 432, but not defined == Unused Reference: 'Trust' is defined on line 563, but no explicit reference was found in the text == Unused Reference: 'RFC3978' is defined on line 566, but no explicit reference was found in the text == Unused Reference: 'Berne' is defined on line 568, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2028 (Obsoleted by RFC 9281) ** Obsolete normative reference: RFC 3979 (Obsoleted by RFC 8179) -- Possible downref: Non-RFC (?) normative reference: ref. 'Trust' -- Obsolete informational reference (is this intentional?): RFC 3978 (Obsoleted by RFC 5378) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 9 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 Jorge Contreras 5 WilmerHale 6 Editors 7 17 October 2007 9 Rights Contributors provide to the IETF Trust 11 13 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 17, 2008. 37 Copyright (C) IETF Trust (2007). 39 Abstract 40 The IETF policies about rights in Contributions to the IETF are 41 designed to ensure that such Contributions can be made available to 42 the IETF and Internet communities while permitting the authors to 43 retain as many rights as possible. This memo details the IETF 44 policies on rights in Contributions to the IETF. It also describes 45 the objectives that the policies are designed to meet. This memo 46 obsoletes RFC 3978 and 4748 and, with RFC 3979 and RFC xxx 47 (-outgoing), replaces Section 10 of RFC 2026. 49 Table of Contents 50 1. Definitions 51 2. Introduction 52 2.1 No Retroactive Effect 53 3. Exposition of why these procedures are the way they are 54 3.1. Rights Granted in Contributions 55 3.2. Rights to use Contributions 56 3.3. Right to Produce Derivative Works 57 3.4. Rights to use Trademarks 58 3.5. Contributions Not Subject to Copyright 59 3.6. Copyright in RFCs 60 4. RFC Editor Documents 61 5. Rights in Contributions 62 5.1. General Policy 63 5.2. Confidentiality Obligations 64 5.3. Rights Granted by Contributors to the IETF Trust 65 5.4. Sublicenses by IETF Trust 66 5.5. No Patent License 67 5.6. Representations and Warranties 68 5.7. No Duty to Publish 69 5.8. Trademarks 70 5.9. Copyright in RFCs 71 6. Legends, Notices and Other Standardized Text in IETF Documents 72 7. Security Considerations 73 8. References 74 8.1. Normative References 75 8.2. Informative References 76 9. Acknowledgements 77 10. Editors' Addresses 78 Full Copyright Statement 80 1. Definitions 81 The following definitions are for terms used in the context of 82 thisdocument. Other terms, including "IESG," "ISOC," "IAB," and 83 "RFCEditor," are defined in [RFC2028]. 85 a. "Contribution": any submission to the IETF intended by the 86 Contributor for publication as all or part of an Internet-Draft or 87 RFC (except for RFC Editor Contributions described in Section 4 88 below) and any statement made within the context of an IETF 89 activity. Such statements include oral statements in IETF 90 sessions, as well as written and electronic communications made at 91 any time or place, which are addressed to: 92 o the IETF plenary session, 93 o any IETF working group or portion thereof, 94 o any Birds of a Feather (BOF) session, 95 o the IESG, or any member thereof on behalf of the IESG, 96 o the IAB or any member thereof on behalf of the IAB, 97 o any IETF mailing list, including the IETF list itself, any 98 working group or design team list, or any other list 99 functioning under IETF auspices, 100 o the RFC Editor or the Internet-Drafts function (except for RFC 101 Editor Contributions described in Section 4 below). 103 Statements made outside of an IETF session, mailing list or other 104 function, that are clearly not intended to be input to an IETF 105 activity, group or function, are not IETF Contributions in the 106 context of this document. 107 b. "Contributor": an individual submitting a Contribution. 108 c. "Copyright" means the legal right granted to an author in a 109 document or other work of authorship under applicable law. A 110 "copyright" is not equivalent to a "right to copy". Rather a 111 copyright encompasses all of the exclusive rights that an author 112 has in a work, such as the rights to copy, publish, distribute and 113 create derivative works of the work. An author often cedes these 114 rights to his or her employer or other parties as a condition of 115 employment or compensation. 116 d. "IETF": In the context of this document, the IETF includes all 117 individuals who participate in meetings, working groups, mailing 118 lists, functions and other activities which are organized or 119 initiated by ISOC, the IESG or the IAB under the general 120 designation of the Internet Engineering Task Force or IETF, but 121 solely to the extent of such participation. 122 e. "IETF Documents": RFCs and Internet-Drafts. 123 f. "IETF Standards Process": the activities undertaken by the IETF in 124 any of the settings described in 1(c) below. 125 g. "IETF Trust": A trust established under the laws of the 126 Commonwealth of Virginia, USA, in order to hold and administer 127 intellectual property rights for the benefit of the IETF. 128 h. "Internet-Draft": temporary documents used in the IETF Standards 129 Process. Internet-Drafts are posted on the IETF web site by the 130 IETF Secretariat. As noted in Section 2.2 of RFC 2026, Internet- 131 Drafts have a nominal maximum lifetime of six months in the IETF 132 Secretariat's public directory. 133 i. "Legend Instructions" means the standardized text that is 134 included in IETF Documents and the instructions and requirements 135 for including that standardized text in IETF Documents, each as 136 posted from time to time at http://www.ietf.org/legends. 137 j. "RFC": the basic publication series for the IETF. RFCs are 138 published by the RFC Editor. Although RFCs may be superseded in 139 whole or in part by subsequent RFCs, the text of an RFC is not 140 altered once published in RFC form. (See [RFC2026] Section 2.1) 141 k. "Reasonably and personally known": means something an individual 142 knows personally or, because of the job the individual holds, 143 would reasonably be expected to know. This wording is used to 144 indicate that an organization cannot purposely keep an individual 145 in the dark about patents or patent applications just to avoid the 146 disclosure requirement. But this requirement should not be 147 interpreted as requiring the IETF Contributor or participant (or 148 his or her represented organization, if any) to perform a patent 149 search in an attempt to find applicable IPR. 150 l. "RFC Editor Documents": means Internet-Drafts that are submitted t 151 the RFC Editor independently of the IETF Standards Process. (See 152 section4.) 154 2. Introduction 155 In all matters of copyright and document procedures, the intent is to 156 benefit the Internet community and the public at large, while 157 respecting the legitimate rights of others. 159 Under the laws of most countries and current international treaties 160 (for example the "Berne Convention for the Protection of Literary and 161 Artistic Work" [Berne Convention]), authors obtain numerous rights in 162 the works they produce automatically upon producing them. These 163 rights include copyrights, moral rights and other rights. In many 164 cases, if the author produces a work within the scope of his or her 165 employment, most of those rights are usually assigned to the 166 employer, either by operation of law or, in many cases, under 167 contract. (The Berne Convention names some rights as "inalienable", 168 which means that the author retains them in all cases.) 170 In order for Contributions to be used within the IETF Standards 171 Process, including when they are published as Internet-Drafts or 172 RFCs, certain limited rights must be granted to the IETF Trust, which 173 then grants the necessary rights to the IETF. In addition, 174 Contributors must make representations to the IETF Trust and the IETF 175 regarding their ability to grant these rights. 177 Section 1 provides definitions used in these policies. Sections 3 178 and 4 of this document explain the rationale for these provisions. 179 Only sections 5 and 6 of this document are normative, the other 180 sections are informative. A companion document RFC 3979 [RFC3979] 181 deals with rights, including possible patent rights, in technologies 182 developed or specified as part of the IETF Standards Process. This 183 document is not intended to address those issues. This memo 184 obsoletes RFC 3978 and 4748 and, with RFC 3979 and RFC 185 xxx(-outgoing), replaces Section 10 of RFC 2026. 187 This document is not intended as legal advice. Readers are advised to 188 consult their own legal advisors if they would like a legal 189 interpretation of their rights or the rights of the IETF Trust in any 190 Contributions they make. 192 2.1 No Retroactive Effect 193 This memo does not retroactively obtain additional rights from 194 Contributions that predate the date that the IETF Trust announces the 195 adoption of these procedures. 197 3. Exposition of Why These Procedures Are the Way They Are 199 3.1. Rights Granted in Contributions 200 The IETF Trust and IETF must obtain the right to publish an IETF 201 Contribution as an RFC or an Internet-Draft from the Contributors. 203 A primary objective of this policy is to obtain from the document 204 authors only the non-exclusive rights that are needed to develop and 205 publish IETF Documents and to use IETF Contributions in the IETF 206 Standards Process and potentially elsewhere. 208 The authors retain all other rights, but cannot withdraw the above 209 rights from the IETF Trust and IETF. 211 It is important to note that under this document Contributors are 212 required to grant certain rights to the IETF Trust, (See Section 213 5.3.) which holds all IETF-related intellectual property on behalf of 214 the IETF community. The IETF Trust will, in turn, grant a sublicense 215 of these rights to all IETF participants for use in the IETF 216 Standards Process. (See Section 5.4.) This sublicense is necessary 217 for the standards development work of the IETF to continue. In 218 addition, the IETF Trust may grant certain other sublicenses of the 219 rights that it is granted under this document. In granting such 220 other sublicenses, the IETF Trust will be guided and bound by 221 documents such as [-outbound]. 223 3.2. Rights to use Contributions 224 It is important that the IETF receive assurances from all 225 Contributors that they have the authority to grant the IETF the 226 rights that they claim to grant because, under the laws of most 227 countries and applicable international treaties, copyright rights 228 come into existence when a work of authorship is created (but see 229 Section 3.5 below regarding public domain documents), and the IETF 230 cannot make use of IETF Contributions if it does not have sufficient 231 rights with respect to these copyright rights. IETF and its 232 participants would run a greater risk of liability to the owners of 233 these rights without this assurance. To this end, IETF asks 234 Contributors to give the assurances in Section 5.6 below. These 235 assurances are requested, however, only to the extent of the 236 Contributor's reasonable and personal knowledge. (See Section 1(k)) 238 3.3. Right to Produce Derivative Works 239 The IETF needs to be able to evolve IETF Documents in response to 240 experience gained in the deployment of the technologies described in 241 such IETF Documents, to incorporate developments in research and to 242 react to changing conditions on the Internet and other IP networks. 243 The IETF may also decide to permit others to develop derivative works 244 based on Contributions. In order to do this, the IETF must be able 245 to produce derivatives of its documents; thus the IETF must obtain 246 the right from Contributors to produce derivative works. Note that 247 the right to produce translations is required before any Contribution 248 can be published as an RFC to ensure the widest possible distribution 249 of the material in RFCs. The right to produce derivative works, in 250 addition to translations, is required for all IETF standards track 251 documents and for most IETF non-standards track documents. There are 252 two exceptions to this requirement: documents describing proprietary 253 technologies and documents that are republications of the work of 254 other standards organizations. 256 The right to produce derivative works must be granted in order for an 257 IETF working group to accept a Contribution as a working group 258 document or otherwise work on it. For non-working group Contributions 259 where the Contributor requests publication as a standards track RFC, 260 the right to produce derivative works must be granted before the IESG 261 will issue an IETF Last-Call and, for most non-standards track non- 262 working group Contributions, before the IESG will consider the 263 Internet-Draft for publication. Occasionally a Contributor may not 264 want to grant publication rights or the right to produce derivative 265 works before finding out if a Contribution has been accepted for 266 development in the IETF Standards Process. In these cases the 267 Contributor may include a limitation on the right to make derivative 268 works in the form specified in the Legend Instructions. A working 269 group can discuss the Contribution with the aim to decide if it 270 should become a working group document, even though the right to 271 produce derivative works or to publish the Contribution as an RFC has 272 not yet been granted. However, if the Contribution is accepted for 273 development, the Contributor must resubmit the Contribution without 274 the limitation notices before a working group can formally adopt the 275 Contribution as a working group document. The IETF Trust may 276 establish different policies for granting sublicenses with respect to 277 different types of Contributions and content within Contributions 278 (such as executable code versus descriptive text or references to 279 third party materials). The IETF Trust's policies concerning the 280 granting of sublicenses to make derivative works will be guided by 281 RFC [-outbound]. 283 The IETF has historically encouraged organizations to publish details 284 of their technologies, even when the technologies are proprietary, 285 because understanding how existing technology is being used helps 286 when developing new technology. But organizations that publish 287 information about proprietary technologies are frequently not willing 288 to have the IETF produce revisions of the technologies and then 289 possibly claim that the IETF version is the "new version" of the 290 organization's technology. Organizations that feel this way can 291 specify that a Contribution be published with the other rights 292 granted under this document but may withhold the right to produce 293 derivative works other than translations. 295 In addition, IETF Documents frequently make normative references to 296 standards or recommendations developed by other standards 297 organizations. Since the publications of some standards organizations 298 are not public documents, it can be quite helpful to the IETF to 299 republish, with the permission of the other standards organization, 300 some of these documents as RFCs so that the IETF community can have 301 open access to them to better understand what they are referring to. 302 In these cases the RFCs can be published without the right for the 303 IETF to produce derivative works. In both of the above cases in 304 which the production of derivative works is excluded, the Contributor 305 must include a special legend in the Contribution, as specified in 306 the Legend Instructions, in order to notify IETF participants about 307 this restriction. 309 3.4. Rights to Use Trademarks 310 Contributors may wish to seek trademark or service mark protection on 311 any terms that are coined or used in their Contributions. IETF makes 312 no judgment about the validity of any such trademark rights. 313 However, the IETF requires each Contributor, under the licenses 314 described in Section 5.3 below, to grant IETF Trust a perpetual 315 license to use any such trademarks or service marks solely in 316 exercising rights to reproduce, publish, discuss and modify the IETF 317 Contribution. This license does not authorize IETF or others to use 318 any trademark or service mark in connection with any product or 319 service offering. 321 3.5. Contributions Not Subject to Copyright 322 Certain documents, including those produced by the U.S. government 323 and those which are in the public domain, may not be protected by the 324 same copyright and other legal rights as other documents. 325 Nevertheless, we ask each Contributor to grant to the IETF the same 326 rights as he or she would grant, and to make the same 327 representations, as though the IETF Contribution were protected by 328 the same legal rights as other documents, and as though the 329 Contributor could be able to grant these rights. We ask for these 330 grants and representations only to the extent that the Contribution 331 may be protected. We believe they are necessary to protect the ISOC, 332 the IETF Trust, the IETF, the IETF Standards Process and all IETF 333 participants, and also because the IETF does not have the resources 334 or wherewithal to make any independent investigation as to the actual 335 proprietary status of any document submitted to it. 337 3.6. Copyright in RFCs. 338 As noted above, Contributors to the IETF (or their employers) retain 339 ownership of the copyright in their Contributions. This includes 340 Internet-Drafts and all other Contributions made within the IETF 341 Standards Process (e.g., via e-mail, oral comment and otherwise). 342 However, it is important that the IETF (through the IETF Trust) own 343 the copyright in documents that are published as RFCs (other than 344 Informational RFCs and RFCs that are submitted as RFC Editor 345 Contributions). Ownership of the copyright in an RFC does not 346 diminish the Contributors' rights in their underlying contributions, 347 but it does prevent anyone other than the IETF Trust (and its 348 licensees) from republishing or modifying an RFC in RFC format. In 349 this respect, Contributors are treated the same as anybody else: 350 though they may extract and republish their own Contributions without 351 limitation, they may not do so in the IETF's RFC format. And while 352 this principle (which is included in Section 5.9 below) may appear to 353 be new to IETF, it actually reflects historical practice and has been 354 observed for many years through the inclusion of an ISOC or IETF 355 Trust copyright notice on all RFC documents since the publication of 356 RFC 2026. 358 4. RFC Editor Documents 359 This document only relates to Contributions made as part of the IETF 360 Standards Process. Other documents that are referred to as Internet- 361 Drafts and RFCs may be submitted to and published by the RFC Editor 362 independently of the IETF Standards Process. Such "RFC Editor 363 Documents" are not covered by this document. RFC Editor 364 Contributions must be marked appropriately as described in the Legend 365 Instructions. See the RFC Editor web page for information about the 366 policies concerning rights in RFC Editor Documents. 368 5. Rights in Contributions 370 5.1. General Policy 371 By submission of a Contribution, each person actually submitting the 372 Contribution, and each named co-Contributor, is deemed to have read 373 and understood the rules and requirements set forth in this document. 374 Each Contributor is deemed, by the act of submitting a Contribution, 375 to enter into a legally-binding agreement to comply with the terms 376 and conditions set forth in this document, on his or her own behalf 377 and on behalf of the organization the Contributor represents or is 378 sponsored by (if any), when submitting the Contribution. No further 379 acknowledgement, signature or other action is required to bind a 380 Contributor to these terms and conditions. The operation of the IETF 381 and the work conducted by its many participants is dependent on such 382 agreement by each Contributor, and each IETF participant expressly 383 relies on the agreement of each Contributor to the terms and 384 conditions set forth in this document. 386 5.2. Confidentiality Obligations 387 No information or document that is subject to any requirement of 388 confidentiality or any restriction on its dissemination may be 389 submitted as a Contribution or otherwise considered in any part of 390 the IETF Standards Process, and there must be no assumption of any 391 confidentiality obligation with respect to any Contribution. Each 392 Contributor agrees that any statement in a Contribution, whether 393 generated automatically or otherwise, that states or implies that the 394 Contribution is confidential or subject to any privilege, can be 395 disregarded for all purposes, and will be of no force or effect. 397 5.3. Rights Granted by Contributors to the IETF Trust 398 To the extent that a Contribution or any portion thereof is protected 399 by copyright or other rights of authorship, the Contributor, and each 400 named co-Contributor, and the organization he or she represents or is 401 sponsored by (if any) grant a perpetual, irrevocable, non-exclusive, 402 royalty-free, world-wide right and license to the IETF Trust under 403 all such copyrights and other rights in the Contribution: 405 (A) to copy, publish, display, and distribute the Contribution, in 406 whole or in part, 407 (B) to prepare translations of the Contribution into languages other 408 than English, in whole or in part, and to copy, publish, display, 409 and distribute such translations or portions thereof, 410 (C) to modify or prepare derivative works (in addition to 411 translations) that are based on or incorporate all or part of the 412 Contribution, and to copy, publish, display, and distribute such 413 derivative works, or portions thereof unless explicitly disallowed 414 in the notices contained in a Contribution [in the form specified 415 by the Legend Instructions], and 416 (D) to reproduce any trademarks, service marks or trade names which 417 are included in the Contribution solely in connection with the 418 reproduction, distribution or publication of the Contribution and 419 derivative works thereof as permitted by this Section 5.3, 420 provided that when reproducing Contributions, trademark and 421 service mark identifiers used in the Contribution, including TM 422 and (R), will be preserved. 424 5.4. Sublicenses by IETF Trust 425 The IETF Trust will sublicense the rights granted to it under Section 426 5.3 to all IETF participants for use within the IETF Standards 427 Process. This license is expressly granted under [TRUST LICENSE 428 DOCUMENT]. 430 In addition, the IETF Trust may grant additional sublicenses of the 431 licenses granted to it hereunder. In doing so, the IETF Trust will 432 comply with the guidance provided under RFC xxx [-outbound]. 434 5.5. No Patent License 435 The licenses granted in Section 5.3 shall not be deemed to grant any 436 right under any patent, patent application or other similar 437 intellectual property right disclosed by the Contributor under BCP 79 438 or otherwise. 440 5.6. Representations and Warranties 441 With respect to each Contribution, each Contributor represents that 442 to the best of his or her knowledge and ability: 444 a. The Contribution properly acknowledges all major Contributors. A 445 major Contributor is any person who has materially or 446 substantially contributed to the Contribution. 447 b. No information in the Contribution is confidential and the IETF, 448 IETF Trust, ISOC, and its affiliated organizations may freely 449 disclose any information in the Contribution. 450 c. There are no limits to the Contributor's ability to make the 451 grants, acknowledgments and agreements herein that are reasonably 452 and personally known to the Contributor. 453 d. The Contributor has not intentionally included in the Contribution 454 any material which is defamatory or untrue or which is illegal 455 under the laws of the jurisdiction in which the Contributor has 456 his or her principal place of business or residence. 457 e. All trademarks, trade names, service marks and other proprietary 458 names used in the Contribution that are reasonably and personally 459 known to the Contributor are clearly designated as such where 460 reasonable. 462 5.7. No Duty to Publish 463 The Contributor, and each named co-Contributor, acknowledges that the 464 IETF has no duty to publish or otherwise use or disseminate any 465 Contribution. The IETF reserves the right to withdraw or cease using 466 any Contribution that does not comply with the requirements of 467 Section 5.3 and Section 5.4 or 5.6. 469 5.8. Trademarks 470 Contributors who claim trademark rights in terms used in their IETF 471 Contributions are requested to state specifically what conditions 472 apply to implementers of the technology relative to the use of such 473 trademarks. Such statements should be submitted in the same way as is 474 done for other intellectual property claims. (See [RFC3979] Section 475 6.) 477 5.9. Copyright in RFCs 478 Subject to each Contributor's (or its sponsor's) ownership of its 479 underlying Contributions (which ownership is qualified by the 480 irrevocable licenses granted under Section 5.3), each Contributor 481 hereby acknowledges that the copyright in any RFC in which such 482 Contribution is included, other than an RFC that is an RFC Editor 483 Contribution, shall be owned by the IETF Trust. Such Contributor 484 shall be deemed to assign to the IETF Trust such Contributor's 485 copyright interest in the collective work constituting such RFC upon 486 the submission of such RFC for publication, and acknowledges that a 487 copyright notice acknowledging the IETF Trust's ownership of the 488 copyright in such RFC will be included in the published RFC. 490 5.10. Contributors retention of rights 491 [THIS SECTION IS STILL UNDER DISCUSSION] Notwithstanding any terms in 492 this document to the contrary, in addition to any rights under 493 copyright retained by Contributor and in addition to any rights 494 generally granted by the IETF trust, Contributor retains, and grants 495 to each Co-Contributor to an RFC in which such Contributor's 496 Contribution, or a derivative work thereof may appear, the right: 497 (A) to copy, publish, display, and distribute any RFC that includes 498 the Contribution, in whole or in part, 499 (B) to prepare translations of such RFCs into languages other than 500 English, in whole or in part, and to copy, publish, display, and 501 distribute such translations or portions thereof, 502 (C) to make derivative works from such RFCs, and to copy, publish, 503 display, and distribute such derivative works thereof, and 504 (D) to reproduce any trademarks, service marks or trade names which 505 are included in such RFCs solely in connection with the 506 reproduction, distribution or publication of the RFC thereof as 507 permitted by this Section 5.10, provided that when reproducing 508 RFCs, trademark and service mark identifiers used in the RFC, 509 including TM and (R), will be preserved. 511 Notwithstanding the above rights, the Contributor does not have the 512 right to represent any document as an RFC, or equivalent to an RFC, 513 if it is not a full and complete copy or translation of the published 514 RFC. 516 6. Legends, Notices and Other Standardized Text in IETF Documents 517 The IETF requires that certain standardized text be reproduced 518 verbatim in certain IETF Documents (including copies, derivative 519 works and translations of IETF Documents). Some of this standardized 520 text may be mandatory (e.g., copyright notices and disclaimers that 521 must be included in all RFCs) and some may be optional (e.g., 522 limitations on the right to make derivative works). The text itself, 523 as well as the rules that explain when and how it must be used, are 524 contained in the Legend Instructions. The Legend Instructions may be 525 updated from time to time, and the version of the standardized text 526 that must be included in IETF Documents is that which was posted in 527 the Legend Instructions on the date of publication. 529 The IETF reserves the right to refuse to publish Contributions that 530 do not include the legends and notices required by the Legend 531 Instructions. 533 It is important to note that each Contributor grants the IETF Trust 534 rights pursuant to this document and the policies described herein. 535 The legends and notices included in certain written Contributions 536 such as Internet-Drafts do not themselves convey any rights. They 537 are simply included to inform the reader (whether or not part of the 538 IETF) about certain legal rights and limitations associated with such 539 documents. 541 It is also important to note that additional copyright notices are 542 not permitted in IETF Documents except in the case where such 543 document is the product of a joint development effort between the 544 IETF and another standards development organization or the document 545 is a republication of the work of another standards organization. 546 Such exceptions must be approved on an individual basis by the IAB. 548 7. Security Considerations 549 This memo relates to IETF process, not any particular technology. 550 There are security considerations when adopting any technology, but 551 there are no known issues of security with IETF Contribution rights 552 policies. 554 8. References 556 8.1. Normative References 557 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 558 3", BCP 9, RFC 2026, October 1996. 559 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 560 the IETF Standards Process", BCP 11, RFC 2028, October 1996. 561 [RFC3979] Bradner, S., Ed, "Intellectual Property Rights in IETF 562 Technology", BCP 79, RFC 3979, March 2005. 563 [Trust] IETF Trust Agreement - http://trustee.ietf.org/xxx 565 8.2. Informative References 566 [RFC3978] Bradner, S. Ed., "IETF Rights in Contributions", RFC 3978, 567 March 2005. 568 [Berne] "Berne Convention for the Protection of Literary and Artistic 569 Work", http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html 571 9. Acknowledgements 572 The editors would like to acknowledge the help of the IETF IPR 573 Working Group provided during the development of the document. 575 10. Editors' Addresses 576 Scott Bradner 577 Harvard University 578 29 Oxford St. 579 Cambridge MA, 02138 USA 580 Phone: +1 617 495 3864 581 EMail: sob@harvard.edu 583 Jorge L. Contreras 584 WilmerHale 585 1875 Pennsylvania Avenue NW 586 Washington, DC 20006 USA 587 Phone: +1 202 663 6872 588 Email: jorge.contreras@wilmerhale.com 590 Full Copyright Statement 591 Copyright (C) IETF Trust (2007). This document is subject to the 592 rights, licenses and restrictions contained in BCP 78, and except as 593 set forth therein, the authors retain all their rights. This 594 document and the information contained herein are provided on an "AS 595 IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTSOR 596 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 597 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 598 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 599 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 600 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 602 Intellectual Property 603 The IETF takes no position regarding the validity or scope of any 604 Intellectual Property Rights or other rights that might be claimed to 605 pertain to the implementation or use of the technology described in 606 this document or the extent to which any license under such rights 607 might or might not be available; nor does it represent that it has 608 made any independent effort to identify any such rights. Information 609 on the procedures with respect to rights in RFC documents can be 610 found in BCP 78 and BCP 79. Copies of IPR disclosures made to the 611 IETF Secretariat and any assurances of licenses to be made available, 612 or the result of an attempt made to obtain a general license or 613 permission for the use of such proprietary rights by implementers or 614 users of this specification can be obtained from the IETF on-line IPR 615 repository at http://www.ietf.org/ipr. The IETF invites any 616 interested party to bring to its attention any copyrights, patents or 617 patent applications, or other proprietary rights that may cover 618 technology that may be required to implement this standard. Please 619 address the information to the IETF at ietf-ipr@ietf.org. 621 Acknowledgement 622 Funding for the RFC Editor function is currently provided by the 623 Internet Society. 625 changes 626 version 01 ->02 627 misc grammar fixes 628 added BOF to sec 1(a) 629 added 1(l) 630 reorder 3.2 631 moved sentence about translations within sec 3.3 632 reorder 5.3 (C) 633 added section 5.10 634 removed "an Informational RFC" from section 5.9 635 added text about assigning rights and acknowledging that a 636 copyright notice will be added to section 5.9 637 added 2nd pp to section 3.6 from RFC 3978 638 added pp on multiple copyright notices to sec 6 640 ?? 642 ?? 644 ?? 646 ?? 648 US1DOCS 6241323v2