RFC 5378

Rights Contributors Provide to the IETF Trust

📅 published November 2008, from ietf

RFC 5378: Rights Contributors Provide to the IETF Trust 💖

okay bestie, this is RFC 5378 🎀 It's a Best Current Practice (that's BCP 78 🌸), published in November 2008 under the Network Working Group. The editors are S. Bradner, Ed. from Harvard University and J. Contreras, Ed. from WilmerHale 🦋 It obsoletes RFCs 3978 and 4748 (so those are kinda retired now 💅) and it updates RFC 2026 (the header lists it as Updates: 2026). In the Abstract it's described as replacing Section 10 of RFC 2026, together with BCP 79 and RFC 5377 ✨

Status of This Memo

This document is a Best Current Practice for the Internet Community 🫶 It's literally asking for discussion and suggestions for improvements. Distribution of this memo is unlimited ✨

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document 🙈

Abstract

The IETF policies about rights in Contributions to the IETF are designed so that those Contributions can be made available to the IETF and Internet communities, while letting the authors keep as many rights as possible 🌈 This memo breaks down those IETF policies on rights in Contributions. It also explains the goals the policies are meant to hit. This memo obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces Section 10 of RFC 2026 🦋

Table of Contents

   1. Definitions .....................................................3
   2. Introduction ....................................................5
      2.1. No Retroactive Effect ......................................5
   3. Exposition of Why These Procedures Are the Way They Are .........6
      3.1. Rights Granted in Contributions ............................6
      3.2. Rights to Use Contributions ................................6
      3.3. Right to Produce Derivative Works ..........................6
      3.4. Rights to Use Trademarks ...................................8
      3.5. Contributions Not Subject to Copyright .....................8
      3.6. Copyright in RFCs ..........................................9
   4. Non-IETF Documents ..............................................9
   5. Rights in Contributions .........................................9
      5.1. General Policy .............................................9
      5.2. Confidentiality Obligations ...............................10
      5.3. Rights Granted by Contributors to the IETF Trust ..........10
      5.4. Sublicenses by the IETF Trust .............................11
      5.5. No Patent License .........................................11
      5.6. Representations and Warranties ............................11
      5.7. No Duty to Publish ........................................12
      5.8. Trademarks ................................................12
      5.9. Copyright in RFCs .........................................12
      5.10. Contributors' Retention of Rights ........................12
   6. Legends, Notices and Other Standardized Text in IETF
      Documents ......................................................13
   7. Security Considerations ........................................13
   8. References .....................................................14
      8.1. Normative References ......................................14
      8.2. Informative References ....................................14
   9. Acknowledgments ................................................15
   10. Changes since RFC 3978 ........................................15
   11. Declaration from the IAB ......................................16

1. Definitions ✨

The following definitions are for terms used in this doc. Other terms, including "IESG", "ISOC", "IAB", and "RFC Editor" are defined in [RFC2028] 💅

a. "Contribution": any submission to the IETF that the Contributor intends for publication as all or part of an Internet-Draft or RFC (except for RFC Editor Contributions described in Section 4 below), and any statement made within the context of an IETF activity. Those statements include oral statements in IETF sessions, plus written and electronic communications, made at any time or place, that are addressed to:

  • the IETF plenary session,
  • any IETF working group or portion thereof,
  • any Birds of a Feather (BOF) session,
  • the IESG, or any member thereof on behalf of the IESG,
  • the IAB, or any member thereof on behalf of the IAB,
  • any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices,
  • the RFC Editor or the Internet-Drafts function (except for RFC Editor Contributions, as described in Section 4 below).

Statements made outside of an IETF session, mailing list, or other function, that are clearly not meant to be input to an IETF activity, group, or function, are not IETF Contributions in the context of this document 🙈

b. "Contributor": an individual submitting a Contribution 🌸

c. "Indirect Contributor": any person who has materially or substantially contributed to a Contribution without being personally involved in its submission to the IETF 🫶

d. "Copyright": the legal right granted to an author in a document or other work of authorship under applicable law. A "copyright" is not the same thing as a "right to copy" 😭 A copyright covers all of the exclusive rights an author has in a work, like the rights to copy, publish, distribute, and create derivative works of it. Authors often hand these rights over to their employer or other parties as a condition of employment or compensation 💼

e. "IETF": in the context of this document, the IETF includes all individuals who take part in meetings, working groups, mailing lists, functions, and other activities that are organized or started by ISOC, the IESG, or the IAB under the general name of the Internet Engineering Task Force (IETF), but only to the extent of that participation 🌈

f. "IETF Documents": RFCs and Internet-Drafts that are used in the IETF Standards Process as defined in 1(g). This is identical to the "IETF stream" defined in [RFC4844] ✨

g. "IETF Standards Process": the activities the IETF undertakes in any of the settings described in 1(a) above 🦋

h. "IETF Trust": a trust established under the laws of the Commonwealth of Virginia, USA, to hold and administer intellectual property rights for the benefit of the IETF 👑

i. "Internet-Draft": temporary documents used in the IETF Standards Process. Internet-Drafts are posted on the IETF web site by the IETF Secretariat. As noted in Section 2.2 of RFC 2026, Internet-Drafts have a nominal maximum lifetime of six months in the IETF Secretariat's public directory ⏳

j. "Legend Instructions": the standardized text that the IETF Trust maintains and includes in IETF Documents, plus the instructions and requirements for including that standardized text in IETF Documents. The text and instructions are posted from time to time at http://trustee.ietf.org/license-info 📜

k. "RFC": the publication series used by the IETF, among others. RFCs are published by the RFC Editor. Although RFCs may be superseded in whole or in part by later RFCs, the text of an RFC is not altered once it's published in RFC form. (See [RFC2026] Section 2.1.) 🍓

l. "Reasonably and personally known": something an individual knows personally or, because of the job they hold, would reasonably be expected to know. This wording is used to show that an organization can't purposely keep an individual in the dark about certain information just to dodge the disclosure requirement 🙅‍♀️

m. "Non-IETF documents": Internet-Drafts that are submitted to the RFC Editor independently of the IETF Standards Process. (See Section 4.) 🧚

2. Introduction 🌷

In all matters of copyright and document procedures, the goal is to benefit the Internet community and the public at large, while respecting the legitimate rights of others 💖

Under the laws of most countries and current international treaties (for example the "Berne Convention for the Protection of Literary and Artistic Work" [Berne]), authors automatically obtain numerous rights in the works they produce as soon as they produce them. These rights include copyrights, moral rights, and other rights 🎀 In many cases, if the author produces a work within the scope of their employment, most of those rights are usually assigned to the employer, either by operation of law or, in many cases, under contract. (The Berne Convention names some rights as "inalienable", which means the author keeps them in all cases 🫶)

For Contributions to be used within the IETF Standards Process, including when they're published as Internet-Drafts or RFCs, certain limited rights must be granted to the IETF Trust, which then grants the necessary rights to the IETF. On top of that, Contributors must make representations to the IETF Trust and the IETF about their ability to grant these rights 💅

Section 1 provides the definitions used in these policies. Sections 3 and 4 of this document explain the rationale for these provisions. Sections 1, 2, 5, and 6 of this document are normative, and the other sections are informative. RFC 3979 (BCP 79) [RFC3979] deals with rights, including possible patent rights, in technologies developed or specified as part of the IETF Standards Process. This document is not meant to address those issues. This memo obsoletes RFCs 3978 [RFC3978] and 4748 [RFC4748] and, with RFC 3979 (BCP 79) and [RFC5377], replaces Section 10 of RFC 2026 [RFC2026] 🧠

This document is not legal advice. Readers are advised to consult their own legal advisors if they'd like a legal interpretation of their rights, or the rights of the IETF Trust [RFC4371], in any Contributions they make ⚖️

2.1. No Retroactive Effect ⏪

This memo does not retroactively obtain additional rights from Contributions that predate the date on which the IETF Trust announces the adoption of these procedures 🦋

3. Exposition of Why These Procedures Are the Way They Are ✨

3.1. Rights Granted in Contributions ✨

okay so the IETF Trust and the IETF have to get the right to publish an IETF Contribution as an RFC or an Internet-Draft from the Contributors 📜

the big goal here is to only grab the non-exclusive rights that are actually needed to develop and publish IETF Documents, and to use IETF Contributions in the IETF Standards Process and potentially elsewhere 🫶

the authors keep every other right 🎀 but they can't take back the rights above from the IETF Trust and the IETF 🙅‍♀️

ngl this part is kinda important 💜 Contributors are required to grant certain rights to the IETF Trust (see Section 5.3.), and the IETF Trust holds all IETF-related intellectual property on behalf of the IETF community 👑 then the IETF Trust grants a sublicense of these rights to all IETF participants for use in the IETF Standards Process (see Section 5.4.) ✨ that sublicense is what keeps the IETF's standards work going, so it's lowkey essential 💖

the IETF Trust can also grant certain other sublicenses of the rights it gets under this document 🦋 and when it does, it will be guided and bound by documents like [RFC5377] 🧚

3.2. Rights to Use Contributions 🌸

the IETF needs assurances from every Contributor that they actually have the authority to grant the rights they're claiming to grant 🙈 because under the laws of most countries and applicable international treaties, copyright rights come into existence the moment a work of authorship is created (but see Section 3.5 below for public domain documents) 📜 and if the IETF doesn't have enough rights in those copyrights, it just can't use the IETF Contribution 💀

without that assurance, the IETF and its participants would run a bigger risk of liability to the owners of those rights 😭 so the IETF asks Contributors to give the assurances in Section 5.6 below 🫶 but these are only requested to the extent of the Contributor's reasonable and personal knowledge (See Section 1(l).) ✨

3.3. Right to Produce Derivative Works 🦋

the IETF has to be able to evolve IETF Documents as people learn from deploying the technologies in them, bring in new research, and keep up with changing conditions on the Internet and other IP networks 🌈 the IETF may also decide to let others build derivative works based on Contributions 🎀 so the IETF needs the right from Contributors to produce derivative works of its documents, full stop 💅

quick note: the right to produce translations is required before any Contribution can be published as an RFC, so the material can reach the widest possible audience 🌍 the right to produce derivative works (on top of translations) is required for all IETF Standards Track documents and for most IETF non-Standards Track documents 💖 there are two exceptions: documents describing proprietary technologies, and documents that republish the work of other standards organizations 🙈

the right to produce derivative works must be granted for an IETF working group to accept a Contribution as a working group document or otherwise work on it 🔥 for non-working group Contributions where the Contributor asks for publication as a Standards Track RFC, that right must be granted before the IESG will issue an IETF Last Call 👑 and for most non-Standards Track, non-working group Contributions, it has to be granted before the IESG will consider the Internet-Draft for publication 🫶

sometimes a Contributor doesn't want to grant publication rights or the right to produce derivative works until they know if the Contribution has been accepted for development in the IETF Standards Process 😭 in that case, they can put a limitation on the right to make derivative works, in the form specified in the Legend Instructions ✨ a working group can still talk through the Contribution to decide if it should become a working group document, even if those rights haven't been granted yet 🌸 but if it does get accepted for development, the Contributor must resubmit it without the limitation notices before a working group can formally adopt it as a working group document 📜

the IETF Trust can set different sublicensing policies for different types of Contributions and for different content inside them (like executable code versus descriptive text or references to third-party materials) 🧚 and its policies on sublicenses to make derivative works will be guided by RFC [RFC5377] 💜

the IETF has historically encouraged organizations to publish details of their technologies, even proprietary ones 🌈 because knowing how existing technology is being used helps when people are building new technology 🙌 but orgs that publish about proprietary technologies are often not up for the IETF revising their technology and then maybe claiming the IETF version is the "new version" of their technology 🙅‍♀️ so an organization that feels this way can specify that a Contribution be published with the other rights granted under this document, but withhold the right to produce derivative works other than translations 🎀

also, IETF Documents often make normative references to standards or recommendations from other standards organizations 📚 some of those publications aren't public, so it can really help the IETF to republish some of them as RFCs, with that organization's permission, so the IETF community can openly access them and understand what they're referring to ✨ in these cases, the RFCs can be published without the right for the IETF to produce derivative works 💅 for both situations where derivative works are excluded, the Contributor must include a special legend in the Contribution, as specified in the Legend Instructions, to tell IETF participants about the restriction 🚨

3.4. Rights to Use Trademarks 💖

Contributors may want to seek trademark or service mark protection for any terms they coin or use in their Contributions 🏷️ the IETF doesn't judge whether any of those trademark rights are valid 🤷‍♀️ but under the licenses described in Section 5.3 below, the IETF requires each Contributor to grant the IETF Trust a perpetual license to use those trademarks or service marks, but only for exercising rights to reproduce, publish, discuss, and modify the IETF Contribution 🫶 this license does not let the IETF or anyone else use a trademark or service mark in connection with any product or service offering 🙅‍♀️

some documents, like those produced by the U.S. government and those in the public domain, may not be protected by the same copyright and other legal rights as other documents 📜 even so, we ask each Contributor to grant the IETF the same rights, and make the same representations, as they would if the IETF Contribution were protected by the same legal rights as other documents, and as though the Contributor could grant those rights 🫶 we only ask for these grants and representations to the extent that the Contribution may be protected 🌸

we think they're necessary to protect the ISOC, the IETF Trust, the IETF, the IETF Standards Process, and all IETF participants 🛡️ also, the IETF doesn't have the resources or wherewithal to independently investigate the actual proprietary status of every document submitted to it 😭

as noted above, Contributors to the IETF (or their employers) keep ownership of the copyright in their Contributions 💅 that includes Internet-Drafts and all other Contributions made within the IETF Standards Process (e.g., via e-mail, oral comment, and otherwise) ✨ but it's important that the IETF (through the IETF Trust) owns the copyright in documents published as RFCs (other than Informational RFCs and RFCs submitted as RFC Editor Contributions) 🎀

owning the copyright in an RFC doesn't shrink the Contributors' rights in their underlying contributions 🦋 what it does do is stop anyone other than the IETF Trust (and its licensees) from republishing or modifying an RFC in RFC format 🙈 in this respect, Contributors are treated just like anybody else: they can extract and republish their own Contributions without limitation, but they can't do it in the RFC format the IETF uses 💜

this principle (which is included in Section 5.9 below) might look new to the IETF, but it actually reflects historical practice 📚 it's been followed for years, because every RFC has carried an ISOC or IETF Trust copyright notice since the publication of RFC 2026 🌟

4. Non-IETF Documents 🌸

this document only covers Contributions made as part of the IETF Processes 🎯 other documents, referred to as Internet-Drafts and RFCs, can be submitted to and published by the RFC Editor independently of the IETF Standards Process 🧚 those aren't covered by this document, unless the controlling entity for that document stream, as described in [RFC4844], chooses to apply these rules 💅 Non-IETF Contributions must be marked appropriately as described in the Legend Instructions 🏷️ for policies on rights in RFC Editor Documents, check the RFC Editor web page, and for other document streams, you have to contact the controlling entity 📬 see Section 11 for a declaration from the IAB on this matter 👑

5. Rights in Contributions 💅

5.1. General Policy 🫶

by submitting a Contribution, each person who actually submits it and each named co-Contributor is deemed to have read and understood the rules and requirements in this document 📖 by the act of submitting a Contribution, each Contributor is deemed to enter into a legally-binding agreement to comply with the terms and conditions in this document 🔥

the Contributor is also deemed to have agreed that they've got the necessary permissions to enter into that agreement from any party the Contributor reasonably and personally knows may have rights in the Contribution, including (but not limited to) the Contributor's sponsor or employer 🌈

no further acknowledgment, signature, or other action is needed to bind a Contributor to these terms and conditions ✨ the operation of the IETF and the work done by its many participants depends on that agreement from each Contributor, and each IETF participant expressly relies on each Contributor's agreement to the terms and conditions in this document 💖

5.2. Confidentiality Obligations 🔒

okay bestie, this one is a hard no on secrets 🙅‍♀️. No information or document that has any confidentiality requirement or any restriction on sharing can be submitted as a Contribution or otherwise considered in any part of the IETF Standards Process. And there must be no assumption of any confidentiality obligation for any Contribution. Each Contributor agrees that any statement in a Contribution, whether it's generated automatically or written by hand, that says or hints the Contribution is confidential or privileged can be ignored for all purposes and has no force or effect. Main character energy is being open 🌸

5.3. Rights Granted by Contributors to the IETF Trust 🎀

so here's the big one. If a Contribution (or any part of it) is covered by copyright or other authorship rights, the Contributor and each named co-Contributor grant the IETF Trust a perpetual, irrevocable, non-exclusive, royalty-free, world-wide, sublicensable right and license under all of those copyrights and other rights in the Contribution. Here's what that covers:

  • a. copying, publishing, displaying, and distributing the Contribution, in whole or in part,
  • b. preparing translations of the Contribution into languages other than English, in whole or in part, and copying, publishing, displaying, and distributing those translations or portions of them,
  • c. modifying or preparing derivative works (in addition to translations) that are based on or include all or part of the Contribution, and copying, publishing, displaying, and distributing those derivative works or portions of them, unless they're explicitly disallowed in the notices in a Contribution (in the form specified by the Legend Instructions), and
  • d. reproducing any trademarks, service marks, or trade names included in the Contribution, solely in connection with reproducing, distributing, or publishing the Contribution and its derivative works as permitted by this Section 5.3. When Contributions are reproduced, trademark and service mark identifiers used in the Contribution, including TM and (R), must be preserved. 💅

5.4. Sublicenses by the IETF Trust 🧚

the IETF Trust will sublicense the rights it got under Section 5.3 to all IETF participants for use within the IETF Standards Process. This license is expressly granted under a license agreement issued by the IETF Trust, which you can find at http://trustee.ietf.org/license-info.

This license is expressly granted under a license agreement issued by the IETF Trust and must contain a pointer to the full IETF Trust agreement.

The IETF Trust can also grant additional sublicenses of the licenses it got under this document. When it does, the IETF Trust will follow the guidance given in RFC 5377 [RFC5377]. 📜

5.5. No Patent License 🚫

the licenses granted in Section 5.3 shall not be deemed to grant any right under any patent, patent application, or other similar intellectual property right disclosed by the Contributor under BCP 79 [RFC3979] or otherwise. Patents are a whole separate vibe, not this one 🙈

5.6. Representations and Warranties 💖

for each Contribution, each Contributor represents that, to the best of their knowledge and ability:

  • a. The Contribution properly acknowledges all Contributors, including Indirect Contributors.
  • b. No information in the Contribution is confidential, and the IETF, IETF Trust, ISOC, and its affiliated organizations may freely disclose any information in the Contribution.
  • c. There are no limits on the Contributor's ability to make the grants, acknowledgments, and agreements in this document that are reasonably and personally known to the Contributor.
  • d. The Contributor has not intentionally included any material in the Contribution that is defamatory or untrue, or that is illegal under the laws of the jurisdiction where the Contributor has their principal place of business or residence.
  • e. All trademarks, trade names, service marks, and other proprietary names used in the Contribution that are reasonably and personally known to the Contributor are clearly designated as such where reasonable.

5.7. No Duty to Publish 🌙

the Contributor, and each named co-Contributor, acknowledges that the IETF has no duty to publish or otherwise use or distribute any Contribution. The IETF reserves the right to withdraw or stop using any Contribution that doesn't comply with the requirements of this Section 5. Not everything gets the spotlight, and that's okay ✨

5.8. Trademarks 🏷️

Contributors who claim trademark rights in terms used in their IETF Contributions are requested to state specifically what conditions apply to implementers of the technology relative to the use of those trademarks. Such statements should be submitted in the same way as other intellectual property claims are. (See [RFC3979] Section 6.)

subject to each Contributor's (or its sponsor's) ownership of its underlying Contributions as described in Section 5.6 (which ownership is qualified by the irrevocable licenses granted under Section 5.3), each Contributor acknowledges that the copyright in any RFC that includes such a Contribution, other than an RFC that is an RFC Editor Contribution, shall be owned by the IETF Trust. Such Contributor is deemed to assign to the IETF Trust their copyright interest in the collective work that makes up such RFC when the RFC is submitted for publication. The Contributor also acknowledges that a copyright notice recognizing the IETF Trust's ownership of the copyright in such RFC will be included in the published RFC. 🦋

5.10. Contributors' Retention of Rights 🌈

even though Contributors give specific rights to the IETF, that isn't meant to take away their right to use their Contributions. To underline this, the IETF Trust is directed to issue a license or assurance to Contributors confirming that each of them may use their Contributions as published in an RFC in any way they like. The only restriction is that no Contributor may represent any document as an RFC, or as the equivalent of an RFC, unless it's a full and complete copy or translation of the published RFC. 👑

6. Legends, Notices and Other Standardized Text in IETF Documents 📝

the IETF requires that certain standardized text be reproduced verbatim in certain IETF Documents (including copies, derivative works, and translations of IETF Documents). Some of this standardized text may be mandatory (for example, copyright notices and disclaimers that must be included in all RFCs), and some may be optional (for example, limitations on the right to make derivative works). The text itself, along with the rules that explain when and how it must be used, is in the Legend Instructions. The Legend Instructions may be updated from time to time, and the version of the standardized text that must be included in IETF Documents is the one posted in the Legend Instructions on the date of publication.

The IETF reserves the right to refuse to publish Contributions that don't include the legends and notices required by the Legend Instructions.

It's important to note that each Contributor grants the IETF Trust rights under this document and the policies described in it. The legends and notices included in certain written Contributions, such as Internet-Drafts, don't convey any rights by themselves. They're just there to inform the reader (whether or not they're part of the IETF) about certain legal rights and limitations that apply to those documents. 🔍

It's also important to note that additional copyright notices aren't permitted in IETF Documents, except where the document is the product of a joint development effort between the IETF and another standards development organization, or is a republication of the work of another standards development organization. Those exceptions must be approved on an individual basis by the IAB. 💜

7. Security Considerations 🔐

this memo is about the IETF process, not any particular technology. There are security considerations when adopting any technology, but there are no known security issues with IETF Contribution rights policies. Phew 😌

8. References 📖

8.1. Normative References

  • [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
  • [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
  • [RFC3979] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
  • [RFC4371] Carpenter, B., Ed., and L. Lynch, Ed., "BCP 101 Update for IPR Trust", BCP 101, RFC 4371, January 2006.

8.2. Informative References

9. Acknowledgments 🙌

the editors want to thank the IETF IPR Working Group for the help they gave during the development of the document. Love that for them 🫶

10. Changes since RFC 3978 🔄

this document is a big reorganization and rewording of RFC 3978, along with a bunch of substantive changes.

The biggest change is that this document now only covers the rights a Contributor grants to the IETF Trust when making a Contribution. All sublicenses of rights for the use of IETF Documents must come from the IETF Trust. (See Section 5.4.)

Material from RFC 4748 that recognized the IETF Trust was added.

Most of the material about RFC Editor documents was removed, since the RFC Editor keeps its own rules and processes for those. These documents were renamed "non-IETF documents," and Section 11 from the IAB about this topic was added.

Changes to the definitions section include defining the terms "Contribution", "Indirect Contributor", "Copyright", "IETF Trust", and "Legend Instructions", plus some minor tweaks to other definitions.

Responsibility for the text of notices was given to the IETF Trust and removed from this document. (See Section 6.)

It was clarified that Contributors enter into a legally binding contract when they submit a Contribution. (See Section 5.1.)

The right to produce derivative works that the Contributor provides to the IETF Trust is no longer limited to the IETF Standards Process.

It was made clear that this document doesn't deal with patent licenses. (See Section 5.5.)

The ownership of the copyrights in IETF Documents was clarified. (See Section 5.9.)

The rights that authors of IETF Contributions keep were clarified. (See Section 5.10.)

11. Declaration from the IAB ✨

okay so the IAB talked about the IPR documents on their most recent call, and it was unanimous 🫶 they decided the IAB stream is going to be covered by the incoming IPR document. 💅 the lowkey clever part is that IAB stream documents' IPR then gets automatically covered by the outbound rights the IETF Trust will set up, based on the advice in [RFC5377]. no extra paperwork, it just rolls right in 🦋

but the IAB also wanted to stress something important, ngl 🙈 for any change to the inbound rights for streams other than the IETF and IAB streams, there needs to be a stream-dependent discussion and approval process. this is the same thing described in RFC 4844, "The RFC Series and RFC Editor" [RFC4844], section 4.2.3. it's giving "every stream gets its own vibe check" 🌈

so, to that extent, section 4 of the document should explicitly mention that the IRTF, the Independent, and any possible future streams are not covered by the document. 🚨 say it out loud so nobody gets confused 📣

For the IAB,

Olaf Kolkman

April 4, 2008

Editors' Addresses 🎀

   Scott Bradner
   Harvard University
   29 Oxford St.
   Cambridge MA, 02138 USA

   Phone: +1 617 495 3864
   EMail: sob@harvard.edu


   Jorge L. Contreras
   WilmerHale
   1875 Pennsylvania Avenue NW
   Washington, DC 20006 USA

   Phone: +1 202 663 6872
   EMail: jorge.contreras@wilmerhale.com
📦 where this page comes from