RFC 5744

Procedures for Rights Handling in the RFC Independent Submission Stream 🎀

okay bestie, this is RFC 5744 💖 It's from the Network Working Group, written by R. Braden (ISI) and J. Halpern (Ericsson), dated December 2009. It's Informational, so it's sharing info with the community, not setting a standard 🦋 It updates RFC 4846 ✨ and doesn't obsolete anything.

Abstract ✨

okay so this doc spells out how authors of RFC Independent Submission documents hand the community "incoming" rights to copy and use their text 📝 It also covers the "outgoing" rights the community gives readers and users of those docs, and it asks the IETF Trust to manage those outgoing rights so everything works out 💅

Status of This Memo 🌸

this memo gives information to the Internet community. it doesn't specify an Internet standard of any kind. distribution of this memo is unlimited 🫶

Copyright Notice 🔥

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

ok this one's important, bestie 🙈 this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date of publication. please read these carefully, because they describe your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the BSD License 💀

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.  Rules for Submission and Use of Material  . . . . . . . . . . . 4
5.  Procedures Requested of the IETF Trust  . . . . . . . . . . . . 4
6.  Patent and Trademark Rules for the Independent Submission
    Stream  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
  8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
  8.2.  Informative References  . . . . . . . . . . . . . . . . . . 6

1. Introduction 💖

as the IETF has grown, the process and the community have gotten way more careful about defining the copying rights that authors grant to the community, and the matching rights the community grants to readers and users of these docs 🦋

this document defines the copyright procedures for RFC Independent Submission documents. it parallels the procedures for IETF-produced documents defined in [RFC5377] and [RFC5378] ✨

the big picture: submissions in the Independent Submission stream use the same submission procedures and mechanisms defined in RFC 5378, so they need the same "incoming rights" as IETF-stream documents 🎀 this doc gives advice to the Trustees of the IETF Trust about the "outgoing" rights to be granted to readers and users of Independent Submission documents, and it explicitly asks the IETF Trust to manage those rights according to this advice 💅

it also sets out the policies on disclosing Patents and Trademarks that might matter for a submission meant for the Independent Submission stream 👑

2. Background 🌈

the concept of RFC streams in general, and the Independent Submission stream in particular, is described in Section 5 of [RFC4844] and in RFC 4846 [RFC4846] 📚 basically, the Independent Submission stream keeps up the long-running Internet tradition of allowing and encouraging the RFC Editor to publish docs that are relevant to the community but aren't products of the IETF process and don't conflict with it. these might be comments on IETF documents, or other work relevant to the Internet that the RFC Editor has historically chosen to publish 🌸

with the publication of [RFC5620], the IETF started a process shift, where responsibility for Independent Submission stream publication will move to an individual designated by the IAB as the Independent Submission Editor (ISE) ✨

Section 8 of RFC 4846 presented the copyright rules for the Independent Submission stream. this document is meant to be fully consistent with that section, and to update it by clarifying the formal procedures the IETF Trust will use to put those rules into effect 🫶

3. Goals 🍓

the goal of the RFC Independent Submission stream is to publish information meant to advance the state of the art and the interoperability of solutions for use with the Internet 💜 as specified in Section 8 of RFC 4846, the community decided this goal is best served by a liberal copyright policy on Independent Submission documents. so the policy is that any individual reading these docs can use the content in any manner. the only restriction is that proper credit ("attribution") must be given 🔥 lawyers describe this liberal policy by saying the stream normally permits "unlimited derivative works" 💅 (fun fact: this liberal policy was always followed by the original RFC Editor, Jon Postel. in a sense, this document formalizes a 30-year-old policy on RFC copyrights 👑)

however, for a small subset of documents published as Independent Submissions, unlimited derivative works aren't reasonable. examples are proprietary protocols and output from other standards bodies. in those cases, authors are allowed to request that the published Independent Submission documents permit no derivative works 🙈

also note that the unlimited derivative works policy applies to all parts of an Independent Submission document, including any code 🌈 so no separate licensing procedure is needed for extracting and adapting code that's in an Independent Submission document submitted under the (preferred) unlimited derivative works terms. on the other hand, code may not be extracted and adapted from Independent Submission documents submitted under the no derivative works terms 💀

4. Rules for Submission and Use of Material ✨

Independent Submission authors will submit their material as Internet-Drafts. these drafts get submitted to, and stored in, the IETF Internet-Drafts repository the same way as IETF Internet-Drafts 📝

during Internet-Draft submission, authors who intend to submit their document for publication in the Independent Submission stream will grant rights as described in [RFC5378]. to request that the contribution be published as an RFC that permits no derivative works, an author may use the form specified for use with RFC 5378 🎀

the IETF Trust will indicate that, in cooperation with the Independent Submission Editor, the Trust grants readers and users of material from Independent Submission documents the right to make unlimited derivative works, unless the document specifies that no derivative works are permitted 🦋 this lets anyone copy, extract, modify, or otherwise use material from Independent Submission documents, as long as suitable attribution is given 💖

contributors of Internet-Drafts intended for the Independent Submission stream will include suitable boilerplate defined by the IETF Trust. this boilerplate shall indicate compliance with RFC 5378, and shall explicitly indicate either that no derivative works can be based on the contribution or, as is preferred, that unlimited derivative works may be crafted from the contribution 🫶

it should be understood that the final publication decision for the Independent Submission stream rests with the Independent Submission Editor (ISE). compliance with these terms is not a guarantee of publication 😭 in particular, the ISE may question whether a "no derivative works" restriction requested by an author is appropriate. the appropriateness of such usage must be negotiated among the authors and the ISE 🌸

5. Procedures Requested of the IETF Trust 🧚

the Independent Submission Editor asks that the IETF Trust and its Trustees help meet the goals and procedures in this document 💅

the Trustees are asked to publicly confirm their willingness and ability to accept responsibility for the Intellectual Property Rights for the Independent Submission stream. they're also asked to indicate their willingness and intent to work according to the procedures and goals defined by the ISE 👑

specifically, the Trustees are asked to develop the boilerplate needed to mark documents so the IETF Trust receives the rights specified in RFC 5378. these procedures also need to allow documents to grant either no rights to make derivative works or, preferentially, the right to make unlimited derivative works from the documents ✨ it's left to the Trust to specify exactly how this is clearly indicated in each document 🌈

6. Patent and Trademark Rules for the Independent Submission Stream 🔥

as specified above, contributors of documents for the Independent Submission stream are expected to use the IETF Internet-Draft process, complying with the rules in the latest version of BCP 9, whose version at the time of writing was [RFC2026] 📚 this includes disclosing Patent and Trademark issues that are known, or can reasonably be expected to be known, by the contributor 🙈

disclosure of license terms for patents is also requested, as specified in the most recent version of BCP 79. the version of BCP 79 at the time of this writing was [RFC3979], updated by [RFC4879] 🎀 the Independent Submission stream chose to use the IETF's IPR disclosure mechanism, www.ietf.org/ipr/, for this 🦋 the Independent Submission Editor would prefer the most liberal terms possible be made available for specifications published as Independent Submission documents. terms that don't require fees or licensing are preferable, and non-discriminatory terms are strongly preferred over ones that discriminate among users 💖 however, even though disclosure is required, there are no specific requirements on the licensing terms for intellectual property related to Independent Submission publication 💅

7. Security Considerations 💀

the integrity and quality of the Independent Submission stream are the responsibility of the Independent Submission Editor. this document doesn't change those responsibilities 🫶

8. References 🌸

8.1. Normative References 💅

okay so these are the must-read docs, the ones you literally need in your back pocket before any of this makes sense 🫶

[RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
           3", BCP 9, RFC 2026, October 1996.

[RFC3979]  Bradner, S., "Intellectual Property Rights in IETF
           Technology", BCP 79, RFC 3979, March 2005.

[RFC4844]  Daigle, L. and Internet Architecture Board, "The RFC
           Series and RFC Editor", RFC 4844, July 2007.

[RFC4846]  Klensin, J. and D. Thaler, "Independent Submissions to the
           RFC Editor", RFC 4846, July 2007.

[RFC4879]  Narten, T., "Clarification of the Third Party Disclosure
           Procedure in RFC 3979", BCP 79, RFC 4879, April 2007.

[RFC5378]  Bradner, S. and J. Contreras, "Rights Contributors Provide
           to the IETF Trust", BCP 78, RFC 5378, November 2008.

[RFC5620]  Kolkman, O. and IAB, "RFC Editor Model (Version 1)",
           RFC 5620, August 2009.

8.2. Informative References 🌸

and then there's this one, which is more of a helpful read than a must-have 🧚

[RFC5377]  Halpern, J., "Advice to the Trustees of the IETF Trust on
           Rights to Be Granted in IETF Documents", RFC 5377,
           November 2008.

Authors' Addresses ✨

meet the two authors, the people behind the words 🎀

Robert Braden
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA  90292
US

EMail: braden@isi.edu


Joel M. Halpern
Ericsson
P. O. Box 6049
Leesburg, VA  20178
US

EMail: jhalpern@redback.com