RFC 4844

The RFC Series and RFC Editor

📅 published July 2007, from ietf

RFC 4844: The RFC Series and RFC Editor 🎀

okay bestie, this is RFC 4844, and it's giving governance drama 💅✨ The author is L. Daigle, Ed. (the "Ed." means she's the editor, so she's kind of the one holding the pen) 🖋️, and the document comes from the Internet Architecture Board (IAB) 🧚. It's an Informational doc, so it's not a standard, just a super important "here's how we're organizing things" memo, published July 2007 🌸. The title block doesn't list any Obsoletes or Updates entries, so this one doesn't replace or change any other RFC 🦋.

Status of This Memo 📜

this memo is here to give info to the Internet community 💖. it is NOT a standard of any kind, so nobody's getting in trouble for not following it 🙈. distribution is unlimited, so share it with your whole group chat 🫶

the IETF Trust holds the copyright, 2007 🌈

Abstract ✨

this doc describes a framework for the RFC Series and an RFC Editor function. the whole point is to bring in organized community involvement and accountability, because the Internet technical community has grown SO much that it's necessary now 🔥. the goal is for the RFC Series to keep doing its job for years to come 👑

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  RFC Series Mission . . . . . . . . . . . . . . . . . . . . . .  4
3.  Roles and Responsibilities . . . . . . . . . . . . . . . . . .  5
  3.1.  RFC Editor . . . . . . . . . . . . . . . . . . . . . . . .  5
  3.2.  IAB  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
  3.3.  Operational Oversight  . . . . . . . . . . . . . . . . . .  5
  3.4.  Policy Oversight . . . . . . . . . . . . . . . . . . . . .  6
4.  Framework  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
  4.1.  Document Approval  . . . . . . . . . . . . . . . . . . . .  7
    4.1.1.  Definition . . . . . . . . . . . . . . . . . . . . . .  7
    4.1.2.  Operational Implementation . . . . . . . . . . . . . .  7
    4.1.3.  Process Change . . . . . . . . . . . . . . . . . . . .  8
    4.1.4.  Existing Approval Process Documents  . . . . . . . . .  8
  4.2.  Editing, Processing, and Publication of Documents  . . . .  8
    4.2.1.  Definition . . . . . . . . . . . . . . . . . . . . . .  8
    4.2.2.  Operational Implementation . . . . . . . . . . . . . .  8
    4.2.3.  Process Change . . . . . . . . . . . . . . . . . . . .  9
    4.2.4.  Existing Process Documents . . . . . . . . . . . . . .  9
  4.3.  Archiving, Indexing, and Accessibility . . . . . . . . . .  9
    4.3.1.  Definition . . . . . . . . . . . . . . . . . . . . . .  9
    4.3.2.  Operational Implementation . . . . . . . . . . . . . .  9
    4.3.3.  Process Change . . . . . . . . . . . . . . . . . . . . 10
    4.3.4.  Existing Process Documents . . . . . . . . . . . . . . 10
  4.4.  Series-Wide Guidelines and Rules . . . . . . . . . . . . . 10
    4.4.1.  Definition . . . . . . . . . . . . . . . . . . . . . . 10
    4.4.2.  Operational Implementation . . . . . . . . . . . . . . 10
    4.4.3.  Process Change . . . . . . . . . . . . . . . . . . . . 10
    4.4.4.  Existing Process Documents . . . . . . . . . . . . . . 10
5.  RFC Streams  . . . . . . . . . . . . . . . . . . . . . . . . . 11
  5.1.  RFC Approval Processes . . . . . . . . . . . . . . . . . . 11
    5.1.1.  IETF Document Stream . . . . . . . . . . . . . . . . . 11
    5.1.2.  IAB Document Stream  . . . . . . . . . . . . . . . . . 12
    5.1.3.  IRTF Document Stream . . . . . . . . . . . . . . . . . 12
    5.1.4.  Independent Submission Stream  . . . . . . . . . . . . 12
  5.2.  RFC Technical Publication Requirements . . . . . . . . . . 13
    5.2.1.  IETF Documents . . . . . . . . . . . . . . . . . . . . 13
    5.2.2.  IAB Documents  . . . . . . . . . . . . . . . . . . . . 13
    5.2.3.  IRTF Documents . . . . . . . . . . . . . . . . . . . . 13
    5.2.4.  Independent Submissions  . . . . . . . . . . . . . . . 14
6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
7.  IAB Members at the Time of Approval  . . . . . . . . . . . . . 14
8.  Informative References . . . . . . . . . . . . . . . . . . . . 15
Appendix A.  A Retrospective of IAB Charters and RFC Editor  . . . 17
  A.1.  1992 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
  A.2.  1994 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
  A.3.  2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1. Introduction ✨

the first RFC was published in April 1969, as part of the effort to design and build what we now call the Internet 🧚. ever since then, the RFC Series has been the archive for Internet technical specs, covering both general contributions from the Internet research and engineering community and standards docs 📚

as the history of the first 30 years of RFCs explains ([RFC2555]), the RFC Series was created to capture the research and engineering thinking behind the design of (what we now know as) the Internet 💖. then the Internet Engineering Task Force (IETF) got formalized to carry out the discussion and documenting of Internet standards, and IETF docs became a huge part of the series (but not the whole thing) 🌸

the IETF has grown up and celebrated its own 20 years, and its archival publishing needs have changed and gotten way more rigorous 💅. most importantly, the IETF has to be able to define (based on its own open consensus discussion processes and leadership directions) and carry out changes to its publication processes 🔥

meanwhile, the Internet engineering and research community as a whole has grown, and it now needs more openness and accountability from every organization supporting it 🫶. honestly more than ever, this community needs an RFC Series that's supported (operationally and in terms of its principles) so there's a balance of:

  • expert implementation;
  • clear management and direction, for operations and evolution across the whole RFC Series (whether it started in the IETF or not); and
  • appropriate community input into and review of activities.

right now it's kind of messy 😭. there's confusion, and sometimes tension, about where and how to handle RFC issues that are specific to contributing groups (like the IETF, the Internet Architecture Board (IAB), or independent individuals). it isn't clear where community involvement should happen versus where RFC Editor control should happen 🙈. depending on the issue, there might be more or less involvement from the IAB, the Internet Engineering Steering Group (IESG), or the community at large. there are similar issues with series-wide stuff too: where do you discuss and resolve things in a way that's balanced across the whole series? 🤔

for example, there are current discussions about Intellectual Property Rights (IPR) for IETF-generated documents, but it's not clear when or how to pull out the parts of those talks that matter for the rest of the RFC Series 🍓. discussions about labeling (of RFCs in general, IETF docs in particular, or some mix of both) generally have to apply to the whole RFC Series or not at all. without an agreed-on framework for managing the series, it's really hard to have those conversations without getting polarized 😭. it's either the IETF dictating the reality of the rest of the series, or the series imposing undue restrictions on the IETF document series. not it 🙅‍♀️

as part of its charter (see Appendix A), the IAB has a responsibility for the RFC Editor 👑. recognizing the evolving needs of the IETF and the wider Internet engineering and research community, the IAB wants the RFC Series to keep meeting its original mandate: being the archive for the technical research and engineering docs that describe the Internet 🦋

so this document is the IAB's framework for the RFC Series and an RFC Editor function. the specific purpose is to make sure the series is maintained and supported in ways that match its stated purpose and the realities of today's Internet research and engineering community ✨. the framework describes the existing "streams" of RFCs, maps out the existing process documents that already define how things get implemented, and gives clear direction on how to evolve the framework and its pieces through discussion and future revisions 🌈

specifically, this document gives a short charter for the RFC Series, describes the roles of the RFC Editor, the IAB, and the IETF Administrative Support Activity (IASA) in a framework for managing the series, and talks about the streams of input to the series from the different groups it serves 💜

2. RFC Series Mission 🎀

the RFC Series is the archive dedicated to documenting Internet technical specifications. that includes general contributions from the Internet research and engineering community, as well as standards docs 🌸

RFCs are free for anyone to get over the Internet 🫶

3. Roles and Responsibilities 💅

this document sets out a revised framework for supporting the RFC Series mission, so this section goes over the updated roles and responsibilities of the entities that have been involved, and will keep being involved, in supporting that mission 👑

3.1. RFC Editor 🖋️

originally, one single person was the editor of the RFC Series (the RFC Editor). the job has grown, and now it needs the organized work of several experts, so there are RFC Editors, or an RFC Editor organization 🧚. over time there might be multiple organizations working together on what the RFC Series needs. to keep things simple, and without trying to predict how the role might get split up, this document calls this whole group of experts and organizations the "RFC Editor" 💖

the RFC Editor is an expert technical editor and series editor, working to support the RFC Series mission 🔥. so the RFC Editor is the implementer handling the editorial management of the series, following the defined processes. the RFC Editor is also expected to be the expert and the prime mover in discussions about policies for editing, publishing, and archiving RFCs 💅

3.2. IAB 🦋

in this model, the IAB's job is to make sure the RFC Series mission is being fulfilled properly for the whole community it was created for ✨. the IAB doesn't have comprehensive publishing or editorial expertise as an organization 🙈. so the IAB's role in this document is focused on making sure principles are met, that the right bodies and communities are informed and consulted, and that the RFC Editor has what it needs to carry out the work in its mandate 🫶

it's the IAB's responsibility to approve the appointment of the RFC Editor, and to approve the general policy the RFC Editor follows 👑

to be continued in part 2 🌈💜

3.3. Operational Oversight 🧚

okay so the IETF Administrative Support Activity (BCP 101, [BCP101]) exists to give admin support to the IETF, the IAB, and the Internet Research Task Force (IRTF) 💼. when it's supporting the IAB, the IASA is the one in charge of funding the RFC Editor and keeping an eye on how it runs 👀.

the IAOC (IETF Administrative Oversight Committee) is the oversight board of the IASA 👑, and the IAD (IETF Administrative Director) is the main boss of the IASA 💅.

the IAOC teams up with the IAB to find suitable persons or entities to take on the RFC Editor mandate 🔍.

the IAOC sets up contractual agreements with the chosen persons or entities so they can do the work that meets the technical publication requirements for the various RFC input streams (see Section 5.2) 📝. the IAOC MAY also define extra operational requirements and policies for management purposes, so the requirements of each community get met 🌈.

following BCP 101, the IAOC oversees how the RFC Editor activity runs, based on those agreements 🫶.

3.4. Policy Oversight 🦋

the IAB keeps watch on whether the policies in force are working and being put into practice, making sure the RFC Editor activity meets the editorial management and document publication needs referenced in this document ✨. if there's serious non-conformance, the IAB can, on its own or when the IAOC asks, require the IAOC to vary or terminate and renegotiate the arrangements for the RFC Editor activity 💀.

4. Framework ✨

with the RFC Series mission sorted out above, this document lays out a framework for supporting:

  • the operational implementation of the RFC Series,

based on:

  • public process and definition documents,

for which there are:

  • clear responsibilities and mechanisms for update and change 🔥.

generally speaking, the RFC Editor is responsible for the operational implementation of the RFC Series 💖. as Section 3.3 explains, the IAD provides oversight of this operational role 👑.

the process and definition documents are detailed below, including who is responsible for each individual process document (maintenance and update) 📚. the RFC Editor works with the right community to make sure the process documents reflect current requirements 🎀. the IAB has the job of checking that appropriate community input was sought and that any changes properly account for community requirements 🫶.

there are 3 categories of activity, plus a 4th category of series-wide rules and guidelines, that are described for implementing the RFC Series so it can do its mission 🌸:

  • Approval of documents.
  • Editing, processing, and publication of documents.
  • Archiving and indexing the documents and making them accessible.
  • Series rules and guidelines.

4.1. Document Approval 🌷

the RFC Series mission implicitly requires that documents get reviewed and approved before they're accepted into the series 🙈.

4.1.1. Definition 💜

Section 5.1 describes the different streams of documents that get handed to the RFC Editor for publication as RFCs today 🧚. there may be general policies for approving documents as RFCs (to keep the RFC Series coherent), but there are also policies defined for approving documents in each stream ✨. generally speaking, every stream has a different approving body 🌈. the current definitions are catalogued in Section 5.1 📋.

4.1.2. Operational Implementation 🎀

each stream has its own documented approval process 📝. the RFC Editor is responsible for approving documents in one of the streams (the Independent Submission stream, see Section 5.1.4) 💅, and it works with the other approving bodies to make sure approved documents move smoothly into the next phases, all the way to publication and archiving as an RFC 🚀.

4.1.3. Process Change 🦋

sometimes it might be necessary to change the approval processes for any given stream, or even to add or remove streams 🔄. this can happen when the RFC Editor, the IAB, the body responsible for a given stream, or the community decides there are issues to fix, either in general RFC approval or in per-stream approval processes 👀.

in this framework, the general approach is that the IAB works with the RFC Editor and other parties to get community input, and it verifies that any changes properly account for community requirements 🫶.

4.1.4. Existing Approval Process Documents 📚

the existing documents describing the approval processes for each stream are detailed in Section 5.1 💖.

4.2. Editing, Processing, and Publication of Documents ✏️

producing and maintaining a coherent, well-edited document series takes specialized skills and subject matter expertise 🧠. this is the domain of the RFC Editor 💅. still, the community served by the RFC Series, and the communities served by the individual streams of RFCs, have requirements that help define what the series is like 🌈.

4.2.1. Definition ⭐

the general and stream-specific requirements for the RFC Series are documented in community-approved documents (catalogued in Section 5.2 below) 📖.

any specific interfaces, numbers, or concrete values needed to make those requirements operational are the subject of agreements between the IASA and the RFC Editor (e.g., contracts, statements of work, service level agreements, etc) 📝🤝.

4.2.2. Operational Implementation 🌸

the RFC Editor is responsible for making sure that editing, processing, and publication of RFCs are carried out in a way that's consistent with the requirements laid out in the appropriate documents 💅. the RFC Editor works with the IASA to provide regular reporting and feedback on these operations 📊.

4.2.3. Process Change 🔁

sometimes it might be necessary to change the requirements for any given stream, or for the RFC Series in general 🦄. this can happen when the RFC Editor, the IAB, the approval body for a given stream, or the community decides there are issues to resolve in general for RFCs or for per-stream requirements 👀.

in this model, the general approach is that the IAB works with the RFC Editor to get community input, and it approves changes by validating that community requirements were appropriately considered 🫶.

4.2.4. Existing Process Documents 📚

the documents describing existing requirements for the streams are detailed in Section 5.2 💜.

4.3. Archiving, Indexing, and Accessibility 🗄️

the activities of archiving, indexing, and making the RFC Series accessible can be informed by specific subject matter expertise in general document series editing 🧐. it's also important that they're informed by requirements from the whole community 🌍. as long as the RFC Series is to stay coherent, there SHOULD be uniform archiving and indexing of RFCs across all streams, plus a common method of accessing the resulting documents 🔗.

the word SHOULD above is what it is, so don't go changing it. 🙈

4.3.1. Definition 📜

in principle, there should be a community consensus document describing the archiving, indexing, and accessibility requirements for the RFC Series 💭. in practice, we continue with the archive as built by the capable RFC Editors since the series' inception 🏛️.

any specific concrete requirements for the archive, index, and accessibility operations are the subject of agreements between the IASA and the RFC Editor (e.g., contracts, statements of work, service level agreements, etc) 📝.

4.3.2. Operational Implementation 🌷

the RFC Editor is responsible for making sure the RFC archive and index are maintained appropriately, and that the resulting documents are made available to anybody who wants to access them via the Internet 🌐. the RFC Editor works with the IASA for regular reporting and feedback 📊.

4.3.3. Process Change 🔄

should there be a community move to propose changes to the requirements for the RFC archive and index, or for accessibility, the IAB will work with the RFC Editor to get community input, and it will approve changes by validating that community requirements were appropriately considered 🫶.

4.3.4. Existing Process Documents 🙅

there are no applicable process documents 🤷‍♀️.

4.4. Series-Wide Guidelines and Rules 📏

the RFC Series style and content can be shaped by subject matter expertise in document series editing 🎨. they're also informed by requirements from the using community 💬. as long as the RFC Series is to stay coherent, there should be uniform style and content for RFCs across all streams 💖. this includes, but isn't limited to, acceptable language, use of references, and copyright rules 📚.

4.4.1. Definition 💜

in principle, there should be a community consensus document (or set of documents) describing the content requirements for the RFC Series 🧾. in practice, some do exist, though some need reviewing, and more may be needed over time ⏳.

4.4.2. Operational Implementation 🎀

the RFC Editor is responsible for making sure the RFC Series guidelines are upheld within the RFC Series 👑.

4.4.3. Process Change 🦋

when additions or changes are needed to series-wide definitions, the IAB will work with the RFC Editor and stream stakeholders to get community input and review 🗣️. the IAB will approve changes by validating that community requirements were appropriately considered 🫶.

4.4.4. Existing Process Documents 📚

existing series-wide rules and guidelines documents include:

5. RFC Streams 🌈

various contributors give input to the RFC Series 💌. these contributors come from several different communities, and each one has its own defined process for approving documents that the RFC Editor will publish 🏷️. this is nothing new 🙃, but over time the various communities and document requirements have grown and separated 🌱. to promote harmony when discussing the whole set of requirements, it's useful to recognize each one in its own space, and they're referred to here as "streams" 🦋.

note that by identifying separate streams, there's no intention of dividing them or undermining their management as one series 🙅‍♀️. it's actually the opposite: by clarifying the parts, it gets easier to make them work together without the friction that sometimes shows up when people discuss various requirements 💕.

the subsections below identify the streams that exist today 📋. there's no immediate expectation of new streams being created, and it is preferable that new streams NOT be created 🙏. creation of streams, and all policies surrounding general changes to the RFC Series, are discussed above in Section 4 🔍.

5.1. RFC Approval Processes 🛂

processes for approving documents (or requirements) for each stream are defined by the community that defines the stream 🏘️. the IAB has the job of checking that appropriate community input was sought and that the changes are consistent with the RFC Series mission and this overall framework 🫶.

the RFC Editor is expected to publish all documents passed to it after appropriate review and approval in one of the identified streams 🎉✨

5.1.1. IETF Document Stream 🌸

okay so the IETF document stream is where IETF WG documents live, plus "individual submissions" that an IESG area director sponsors 🫶. If something is being published as part of the IETF standards process, it has to go through this stream. No other stream can approve Standards-Track or Best Current Practice (BCP) RFCs. Not one! 💅

Approval for this stream is defined by:

  • the IETF standards process (RFC 2026 [RFC2026] and its successors).
  • the IESG process for sponsoring individual submissions [SPONSOR]).

If you want to change how approval works here, you update the IETF standards process documents. Simple as that ✨

5.1.2. IAB Document Stream 🦋

The IAB decides how it approves documents in its own stream. Same energy as above, though: any documents the IAB wants to publish as part of the IETF Standards Track (Standards or BCPs) are subject to the approval processes from Section 5.1.1.

The review and approval process for the IAB stream is described in:

  • the IAB process for review and approval of its documents (RFC 4845 [RFC4845]).

5.1.3. IRTF Document Stream 🧚

The IRTF is chartered as an activity of the IAB, so it's kinda part of the family 🌈 With the IAB's approval, the IRTF can publish and update its own process for publishing its own non-IETF Standards-Track documents.

The review and approval process for the IRTF stream is described in:

  • IRTF Research Group RFCs [IRTF-DOCS].

5.1.4. Independent Submission Stream 🍓

The RFC Series has always served a broader Internet technical community than just the IETF, and that's iconic 👑 The "Independent Submission" stream exists to review and (possibly) approve documents that fall outside the streams we just talked about.

Generally speaking, approval in this stream is under the purview of the RFC Editor, and the RFC Editor asks the IESG for input on its review ✨

The process for reviewing and approving Independent Submission stream documents is defined by:

5.2. RFC Technical Publication Requirements 💖

The Internet engineering and research community has grown, and it's gotten more diverse and, honestly, more demanding 😭 The IETF is a standards-developing organization, so its publication requirements go beyond what an academic journal would ask for. The IAB doesn't have the same interdependence with IANA assignments that the IETF stream does. So there's a need to write down the publishing requirements for each stream, and to try to harmonize them as much as is reasonable 🎀

So each document stream's community is expected to outline its own technical publication requirements.

As part of RFC Editor oversight, the IAB must agree that those requirements are consistent with, and implementable as part of, the RFC Editor activity.

5.2.1. IETF Documents 💜

The requirements for this stream are defined in RFC 4714 [RFC4714].

5.2.2. IAB Documents 🌷

Even though they were developed for the IETF standards process, the IAB will identify the applicable requirements in RFC 4714 for its stream.

If the IAB chooses to define other requirements, they should deviate minimally from those. The goal is to keep the collective technical publication requirements reasonably managed by one technical publisher 🧠

5.2.3. IRTF Documents 🍒

Even though they were developed for the IETF standards process, the IRTF will identify the applicable requirements in RFC 4714 for its stream.

If the IRTF chooses to define other requirements, they should deviate minimally from those, same as above. The goal is still one technical publisher managing everything reasonably 🫧

5.2.4. Independent Submissions 🎈

Even though they were developed for the IETF standards process, the RFC Editor will identify the applicable requirements in RFC 4714 for its stream.

If the RFC Editor chooses to define other requirements, they should deviate minimally from those, so the collective technical publication requirements stay reasonably managed by one technical publisher 💅

6. Security Considerations 🚨

Okay, this part is SERIOUS bestie 😭 The publication processes must prevent unapproved changes from getting in. The RFC Editor maintains the index of publications, so there has to be enough security to stop external parties from changing these published documents. The archive of RFC documents, any source documents needed to recreate the RFC documents, and any associated original documents (like lists of errata, tools, and, for some early items, non-machine-readable originals) all need to be secured against failure of the storage medium and other similar disasters. Losing the archive would be an actual catastrophe 💀

7. IAB Members at the Time of Approval 👑

These were the IAB members when this was approved, all iconic:

  • Bernard Aboba
  • Loa Andersson
  • Brian Carpenter
  • Leslie Daigle
  • Elwyn Davies
  • Kevin Fall
  • Olaf Kolkman
  • Kurtis Lindqvist
  • David Meyer
  • David Oran
  • Eric Rescorla
  • Dave Thaler
  • Lixia Zhang

8. Informative References 📚

[BCP101]      Austein, R. and B. Wijnen, "Structure of the IETF
              Administrative Support Activity (IASA)", RFC 4071,
              BCP 101, April 2005.

[IABCHARTER]  Carpenter, B., "Charter of the Internet Architecture
              Board (IAB)", RFC 2850, May 2000.

[IRTF-DOCS]   Falk, A., "IRTF Research Group RFCs", Work in Progress,
              February 2006.

[RFC1358]     Chapin, L., "Charter of the Internet Architecture
              Board (IAB)", RFC 1358, August 1992.

[RFC1601]     Huitema, C., "Charter of the Internet Architecture
              Board (IAB)", RFC 1601, March 1994.

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

[RFC2223]     Postel, J. and J. Reynolds, "Instructions to
              RFC Authors", RFC 2223, October 1997.

[RFC2223BIS]  Reynolds, J., Ed. and R. Braden, Ed., "Instructions to
              Request for Comments (RFC) Authors", Work in Progress,
              August 2004.

[RFC2555]     Editor, RFC., "30 Years of RFCs", RFC 2555, April 1999.

[RFC3932]     Alvestrand, H., "The IESG and RFC Editor Documents:
              Procedures", RFC 3932, October 2004.

[RFC3967]     Bush, R. and T. Narten, "Clarifying when Standards
              Track Documents may Refer Normatively to Documents at a
              Lower Level", RFC 3967, December 2004.

[RFC3978]     Bradner, S., Ed., "IETF Rights in Contributions",
              RFC 3978, March 2005.

[RFC4693]     Alvestrand, H., "IETF Operational Notes", RFC 4693,
              October 2006.

[RFC4714]     Mankin, A. and S. Hayes, "Requirements for IETF
              Technical Publication Service", RFC 4714, October 2006.

[RFC4748]     Bradner, S., Ed., "RFC 3978 Update to Recognize the
              IETF Trust", RFC 4748, October 2006.

[RFC4845]     Daigle, L., "Process for Publication of IAB RFCs",
              RFC 4845, July 2007.

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

[RFC4897]     Klensin, J., "Handling Normative References to
              Standards Track Documents", BCP 97, RFC 4897,
              June 2007.

[SPONSOR]     Arkko, J., "Guidance on Area Director Sponsoring of
              Documents", ION, October 2006.

Appendix A. A Retrospective of IAB Charters and RFC Editor 🕰️

With this document, the IAB's role with respect to the RFC Series and the RFC Editor is being adjusted. The IAB will work more directly with the RFC Editor and provide oversight, so the RFC Series mission principles and the communities' input get addressed properly ✨

This appendix gives an overview of the IAB's role with respect to the RFC Editor, as it's been laid out in IAB Charter RFCs going back to 1992. The point is that the IAB's role has historically been substantive. It's either supposed to be directly responsible for the RFC Series' editorial management (circa 1992, Appendix A.1), or it's about appointing the RFC Editor organization and approving general policy (circa 2000, Appendix A.3) 🫶

A.1. 1992 🎀

[RFC1358] says:

[The IAB's] responsibilities shall include:
[...]
    (2)  The editorial management and publication of the Request for
         Comments (RFC) document series, which constitutes the
         archival publication series for Internet Standards and
         related contributions by the Internet research and
         engineering community.

A.2. 1994 🌸

[RFC1601] says:

[The IAB's] responsibilities under this charter include:

(d) RFC Series and IANA

   The IAB is responsible for editorial management and publication of
   the Request for Comments (RFC) document series, and for
   administration of the various Internet assigned numbers.

which it elaborates as:

2.4 RFC Series and Assigned Numbers

   The RFC Series constitutes the archival publication channel for
   Internet Standards and for other contributions by the Internet
   research and engineering community.  The IAB shall select an RFC
   Editor, who shall be responsible for the editorial management and
   publication of the RFC Series.

A.3. 2000 🦋

[IABCHARTER], which is the most recent IAB Charter document, says:

(d) RFC Series and IANA

The RFC Editor executes editorial management and publication of the
IETF "Request for Comment" (RFC) document series, which is the
permanent document repository of the IETF.  The RFC Series
constitutes the archival publication channel for Internet Standards
and for other contributions by the Internet research and engineering
community.  RFCs are available free of charge to anyone via the
Internet.  The IAB must approve the appointment of an organization to
act as RFC Editor and the general policy followed by the RFC Editor.

Authors' Addresses 💌

Leslie L. Daigle (editor)

EMail: ledaigle@cisco.com, leslie@thinkingcat.com


IAB

EMail: iab@iab.org
URI:   http://www.iab.org/

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property ✨

okay so the IETF is being very upfront here 💅 It takes no position on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or in scope, and it doesn't say whether any license under those rights is or isn't available. It also hasn't made any independent effort to hunt down those rights, so bestie, don't assume it has checked. 🙈 If you want to know how rights work for RFC documents, the answer lives in BCP 78 and BCP 79 📚

Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses that will be made available, can be found in the IETF online IPR repository at http://www.ietf.org/ipr. The same goes for the result of an attempt to get a general license or permission for implementers or users of this specification to use proprietary rights. 🦋

The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society 🌈

📦 where this page comes from