Fact-checked by Grok 2 weeks ago

Request for Comments

A is a series of technical and organizational documents published by the and affiliated bodies, such as the Internet Research Task Force (IRTF) and the , that describe specifications, policies, research, and innovations essential to the development, operation, and management of the and connected systems. Originating in 1969 as informal memoranda within the project—the precursor to the modern —the RFC series began with RFC 1, authored by , to solicit feedback on host software interfaces for networked computers. Over time, the series evolved from casual "requests for comments" into a formal mechanism for establishing standards, with 9,890 RFCs published as of November 2025, sequentially numbered and freely available in multiple formats including , plain text, and PDF. RFCs are produced through five primary streams: the IETF stream for consensus-driven protocols and best practices; the IRTF stream for research-oriented insights; the IAB stream for architectural guidance; independent submissions for external contributions; and the editorial stream for procedural updates. Each RFC is assigned a status reflecting its intended use, such as Informational (for general guidance), Experimental (for testing new ideas), Proposed Standard or (for protocols in development or adoption), Best Current Practice (BCP) for operational recommendations, or Historic (for obsolete content). The significance of RFCs lies in their role as the foundational texts of , voluntarily adopted by developers, vendors, and network operators worldwide to ensure and innovation; subseries like Standards (STD) and BCPs further codify core protocols such as / and HTTP. Maintained under the IETF Trust's open license ( 2070-1721), the series continues to adapt, with recent emphases on , , and , reflecting the collaborative, open nature of Internet standardization.

Overview

Definition and Purpose

The series consists of technical documents originating from the and affiliated organizations, serving as a primary mechanism to propose, discuss, and document methods, behaviors, research, and innovations pertinent to the Internet's development and operation. These documents encapsulate specifications for network protocols, architectural principles, and operational guidelines, enabling collaborative refinement among engineers, researchers, and implementers worldwide. The concept of RFCs was introduced by in 1969 as informal "requests for comments" to solicit open feedback and foster egalitarian collaboration during the early development of the , the precursor to the modern . This approach emphasized discussion over authoritative decrees, encouraging participants to contribute ideas without hierarchical constraints, which laid the groundwork for the series' enduring role in technical discourse. RFCs are characterized by sequential numbering, beginning with RFC 1 published on April 7, 1969, and are made publicly available to promote transparency and widespread adoption. As of November 2025, 9,890 RFCs have been issued, focusing on ensuring among diverse network systems and guiding the evolution of protocols through voluntary implementation. Typical content includes detailed protocol specifications, such as those for TCP/ in foundational documents, best current practices for , and informational notes on emerging technologies or research findings.

Role in Internet Standards Development

The Request for Comments (RFC) series serves as the primary mechanism through which (IETF) working groups develop and advance Internet standards, facilitating iterative feedback from the broader community to refine technical specifications. Working groups, formed around specific technical areas, draft and revise documents as Internet-Drafts before submitting them for publication as RFCs, incorporating comments to achieve consensus on protocol designs that promote across diverse systems. This process ensures that standards evolve through collaborative input rather than top-down imposition, with 9,890 RFCs published since 1969 documenting foundational elements of Internet architecture. RFCs integrate deeply with IETF processes, advancing through structured reviews by , approval by the Internet Engineering Steering Group (IESG), and open discussion on public . Working group chairs coordinate peer reviews to address technical concerns, after which the document undergoes an IESG evaluation, including a "" period for community feedback—typically two weeks for working group outputs or four weeks otherwise—announced on the IETF to solicit final input. This multi-stage , as outlined in the IETF standards process, ensures rigorous scrutiny while maintaining transparency and inclusivity in . RFCs exert profound influence on the global by forming the basis for core protocols that enable widespread among vendors and operators. For instance, the Hypertext Transfer Protocol (HTTP) is defined in the RFC 9110 series, providing the semantics for web communication; the Domain Name System (DNS) is specified in RFCs 1034 and 1035, supporting hierarchical name resolution; and addressing is detailed in RFC 8200, addressing the limitations of IPv4 through expanded . These documents guide implementations in software, hardware, and networks worldwide, underpinning services from web browsing to global routing. While RFCs solicit comments to foster discussion, they are non-binding in a legal sense and derive their authority primarily through voluntary adoption and reference in real-world implementations rather than formal mandates. Publication as an RFC does not imply IETF endorsement or status; instead, their practical impact emerges when developers and organizations implement the specifications, leading to standards that drive evolution. This adoption-based legitimacy reinforces the open, consensus-driven nature of the IETF ecosystem.

History

Origins and Early RFCs

The Request for Comments (RFC) series originated in 1968 as a mechanism for the Network Working Group (NWG), a collaborative effort among graduate students and staff from UCLA, SRI International, the University of California Santa Barbara, and the University of Utah, under the auspices of the Advanced Research Projects Agency (ARPA)'s Information Processing Techniques Office (IPTO). The NWG formed following the first meeting in the summer of 1968 to coordinate the development of software and protocols for the nascent ARPANET, an experimental packet-switching network aimed at interconnecting research computers. Steve Crocker, a graduate student at UCLA, proposed the RFC format to document the group's discussions and decisions in an open, non-authoritative manner, avoiding the rigidity of formal specifications. The first RFC, titled "Host Software" and authored by Crocker, was published on April 7, 1969, outlining initial requirements for host-to-host communication, including message formats, error handling, and primitives for connections between ARPANET hosts and Interface Message Processors (IMPs). Early RFCs were produced as typewritten memos that were photocopied and physically mailed to a small group of approximately 15 key researchers across the four initial sites, managed through the Stanford Research Institute (SRI) (). This distribution method, detailed in 3 ("Documentation Conventions," also by Crocker in April 1969), emphasized an informal tone to encourage broad participation, stating that notes should be "timely rather than polished" and could consist of as little as one , including ideas, criticisms, or questions on network design. The goal was to foster collaborative dialogue without imposing official status, as Crocker noted in recollections that the format allowed "anyone [to] say anything" to solicit feedback and refine concepts iteratively. The initial RFCs primarily addressed ARPANET host-to-host protocols, such as software interfaces for data transmission, connection management, and early experiments like remote console control via a . Publication was rapid and , with 26 RFCs issued in 1969 alone, growing to over 100 by 1973 as the network expanded from four nodes to dozens. This evolution marked a transition from unstructured working notes to a more organized series, with , a UCLA colleague of Crocker's, beginning informal editing responsibilities in 1969 to assign numbers, archive documents, and ensure consistent distribution through the SRI .

Evolution of the RFC Editor

Jon Postel, a pioneering figure in Internet development, served as the de facto RFC Editor from the publication of RFC 1 in 1969 until his death in October 1998. Based at the University of Southern California's Information Sciences Institute (USC/ISI), Postel was responsible for collecting, editing, numbering, and distributing all RFCs, ensuring their timely dissemination to the growing network research community. His efforts, often assisted by Joyce K. Reynolds, established the foundational practices for the RFC series during its formative years. Following Postel's passing, the RFC Editor function transitioned under the oversight of the (IAB), which assumed responsibility for appointing the RFC Series Editor to maintain continuity and strategic direction. USC/ISI continued to handle publication duties as the operational publisher until early , when the production and publishing functions transitioned to the Association Management Solutions (AMS) as the new RFC Production Center and RFC Publisher, funded initially through contracts with the (DARPA) and later the . This period marked the shift from an informal, individual-led operation to a more structured model, formalized in 2009 with RFC 5620, which defined Version 1 of the RFC Editor Model. The model divided responsibilities among key roles, including the RFC Series Editor for overall governance and an Independent Submissions Editor for non-IETF documents, emphasizing community involvement while preserving editorial integrity. Subsequent refinements addressed evolving needs, culminating in Version 3 of the RFC Editor Model outlined in RFC 9280, published in June 2022. This iteration streamlined operations into two primary tasks—RFC Series Administration and RFC Production—enhancing efficiency and adaptability for the series' growth. In September 2022, Alexis Rossi was appointed as the RFC Series Consulting Editor, a senior role providing expert guidance on processes and policies to support the model's implementation. The RFC Editor's core responsibilities include upholding editorial consistency across all documents through standardized formatting, clarity, and style guidelines, while operating independently from the IETF to safeguard the series' neutrality and long-term archival value. This independence is governed by the RFC Series Approval Board and the , distinct from IETF streams. Annually, the function processes and publishes around 200 new RFCs from various streams, reflecting the sustained output of Internet technical specifications; by 2021, the series had surpassed RFC 9000. In January 2025, the IETF LLC took over direct management of the RFC Production Center from to better align with strategic goals and improve efficiency.

Publishing and Format Changes

In the early years of the RFC series, documents were published exclusively in format using the ASCII character set, facilitating simple electronic distribution and printing on teletypewriters or basic terminals. This format remained largely unchanged for decades, with RFC 1000 serving as a key milestone in 1987 by providing a comprehensive index and summary of all prior RFCs (1 through 999) to aid navigation of the growing series. The introduction of HTML versions in 1998 marked an initial step toward web-based accessibility, allowing RFCs to be rendered in browsers alongside the canonical plain-text files, though these early HTML renditions were non-normative and experimental. A more substantial evolution occurred with the adoption of XML as the source format, formalized in 7991 (December 2016), which defined the "xml2rfc" version 3 vocabulary for structuring RFC content. This XML foundation enabled automated generation of multiple output formats and was fully implemented in the RFC v3 schema by 2019. Additionally, the RFC series received its 2070-1721 in 2007, as documented in 4844, to establish it as a formal archival publication. The most significant publishing shift arrived in October 2019 with the rollout of the v3 format, fully live with 8651 on October 7, 2019; this introduced a reflowable text layout in both plain-text and HTML outputs, eliminating fixed-width monospaced fonts and to enhance across devices, including screens and assistive technologies compliant with WCAG 2.1 standards. The change addressed long-standing limitations in the fixed-format design, which had persisted since the series' origins despite growing digital consumption needs, and was driven by requirements outlined in 6949 (May 2013). By November 2025, all newly published RFCs adhere to this reflowable format, with the series exceeding 9,850 documents in total.

Production Process

Drafting and Review Procedures

The drafting of a Request for Comments (RFC) begins with the creation of an Internet-Draft (I-D), a working document that serves as the initial version of the specification. Individuals or IETF working groups initiate this process by authoring the draft, which reflects the authors' opinions and lacks formal status until further advancement. These drafts are submitted through the IETF Datatracker at datatracker.ietf.org, where they are made publicly available in the Internet-Drafts directory for broad access and informal review. If an I-D is not updated or advanced toward RFC publication within six months of submission, it is automatically removed from the directory to maintain currency and focus on active work. The review process emphasizes open community feedback, primarily conducted through IETF mailing lists associated with relevant working groups or general discussion forums. Working group charters, approved by the Internet Engineering Steering Group (IESG), explicitly define the scope of work, including deliverables, milestones, and boundaries to ensure alignment with IETF goals and prevent overlap with other efforts. During review, authors and reviewers employ normative language as specified in RFC 2119 to clearly indicate requirement levels, such as "MUST" for mandatory actions, "SHOULD" for recommendations, and "MAY" for optional elements, promoting unambiguous implementation. This feedback loop allows for iterative revisions, with working groups resolving technical issues through discussion before advancing the draft. Specific tools and conventions support precise specification drafting. For defining protocol syntax, the Augmented Backus-Naur Form (ABNF), outlined in RFC 5234, provides a standardized notation for formal grammars, including rules for repetition, alternatives, and value ranges to ensure interoperability. Additionally, since 1997, all RFCs have required a dedicated section on security considerations to address potential vulnerabilities, risks, and mitigation strategies, as guided by the principles in RFC 2196. For documents outside the core IETF consensus process, the Independent Submissions stream allows individuals to submit I-Ds directly to the Independent Submissions Editor (ISE) without undergoing full or IESG review. Under the RFC Editor Model Version 3, established in 2022 via 9280, this stream emphasizes technical soundness and relevance to the RFC Series while bypassing the structured IETF process, enabling faster publication of non-standards-track contributions.

Finalization and Numbering

Once the review process for an Internet-Draft is complete, approval for publication as an RFC follows distinct paths depending on the document's stream. For the IETF stream, which includes Standards Track, Best Current Practice (BCP), and certain Informational or Experimental documents, the Internet Engineering Steering Group (IESG) conducts a final review to ensure technical soundness, clarity, and alignment with IETF goals before approving publication. Non-IETF streams, such as the IAB stream, rely on approval from designated stream managers; for example, the Internet Architecture Board (IAB) approves documents in its stream per established procedures. Similarly, the IRTF stream and Independent Submissions are handled by their respective managers, with the latter requiring review by the Independent Submissions Editor (ISE) and a non-blocking IESG consultation for relevance and competence. Following stream approval, the RFC Editor performs an editorial review to prepare the document for publication. This includes verifying clarity, ensuring compliance with the RFC format (specifically the v3 XML vocabulary defined in ), checking consistency with IETF style guidelines, and validating references and authorship. The process involves conversion to canonical formats (TXT, PDF, HTML) and may require coordination with the (IANA) for parameter registrations. Authors then participate in the AUTH48 stage, a final phase where they review and approve edits, addressing any errors or clarifications; this step, named for an aspirational 48-hour turnaround but often extending to weeks, ensures the document's accuracy before proceeding. Upon author approval in AUTH48, the RFC Editor assigns a unique sequential number to the document, maintaining a continuous series without gaps since RFC 1 in 1969. As of November 2025, the series has reached RFC 9890, with numbers assigned in the order of publication to preserve chronological integrity. Errata, which correct post-publication issues, are tracked separately in the RFC Editor's database rather than altering the original numbering or content. The timeline from initial Internet-Draft submission to final publication typically spans 1-2 years, encompassing development, IESG review, and editorial processing, though this varies by document complexity and . Urgent cases, such as critical updates, can be expedited through fast-track procedures to reduce this period significantly.

Classification and Versioning

Publication Streams

Publication streams represent distinct, independent channels for approving and publishing documents in the RFC Series, formalized in RFC 4844 (2007) to organize the diverse origins of contributions while maintaining the series' archival role. These streams ensure that RFCs from various community sources undergo appropriate review before reaching the RFC Editor for final preparation and numbering. RFC 9280 (2022) updated this framework by refining management responsibilities, introducing the RFC Series Approval Board (RSAB) for policy oversight, and adding the Editorial Stream for series-specific guidelines. The IETF Stream forms the core publication path, encompassing the majority of RFCs—approximately 90%—and focusing on outputs from IETF working groups (WGs) as well as IESG-sponsored individual submissions. Managed by the Internet Engineering Steering Group (IESG), this stream supports the development of Internet standards, best current practices, and informational documents advancing specifications. For instance, 9000, which specifies the for secure, multiplexed transport over , exemplifies an IETF Stream publication resulting from WG consensus and IESG approval. Non-IETF Streams provide avenues for contributions outside the IETF's consensus-driven process, each with specialized approval mechanisms. The Independent Stream allows direct submission to the RFC Editor for documents on topics relevant to the but not requiring broad IETF agreement, such as clarifications or extensions to existing work; by 2025, it handles approximately 5-10% of publications, often addressing non-consensus areas. The IRTF Stream publishes research-oriented s from Internet Research Task Force (IRTF) research groups, emphasizing experimental ideas and long-term innovations, with approval by the IRTF chair and oversight from the (IAB). The IAB Stream covers architectural, programmatic, and liaison documents approved directly by the IAB to guide evolution. Finally, the Editorial Stream, established in 9280, is reserved for policies governing the RFC Series itself, ensuring consistency in publication practices. An example of an IAB Stream document is 9280, which outlines the updated RFC Editor model.

Sub-series and Status Categories

The RFC series includes several sub-series that provide specialized numbering for documents of particular significance within the Internet community. The sub-series designates documents that capture established practices or guidelines for the operations and processes, such as RFC 2026, which outlines the IETF standards process and is numbered as BCP 9. The Standards (STD) sub-series identifies documents that have achieved status, comprising one or more RFCs that define core protocols; for example, STD 7 encompasses the Transmission Control Protocol () specification in RFC 9293. The For Your Information () sub-series, introduced in 1990 via RFC 1150 to provide introductory or tutorial materials, was concluded in 2011 with no further assignments, as documented in RFC 6360, though existing FYI documents retain their numbers. Upon publication, RFCs are assigned one of several status categories that reflect their intended use and maturity level within the Internet standards ecosystem. Only the IETF Stream produces Standards Track or BCP RFCs. The Standards Track category applies to documents intended for eventual standardization and includes two maturity levels: Proposed Standard, which requires at least two running implementations demonstrating , stability, and community review but no widespread deployment; and , the highest level signifying broad deployment, proven reliability, and at least two independent interoperable implementations with no critical errata. Informational status is for documents providing general information or external specifications without seeking IETF consensus, such as overviews of non-IETF technologies. Experimental status covers proposals for research or testing new ideas without commitment to standardization. Historic status marks documents that are obsolete, superseded, or no longer relevant, as defined in the standards process guidelines. A rare Unknown status applies to a small number of early RFCs published before , when formal categorization was not consistently applied. Advancement along the Standards Track occurs through demonstrated implementation and operational success, as updated in RFC 6410 (2011), which streamlined the process to two primary maturity levels (Proposed Standard and ) while requiring evidence of at least two independent, interoperable implementations with no critical errata for progression to . For instance, the specification advanced to status (STD 7) after extensive deployment across the Internet. These categories, established primarily through RFC 2026 and refined in subsequent updates like RFC 6410, have remained unchanged since 2011, with Standards Track documents comprising a minority of the overall RFC series. Status assignment typically follows from the document's originating publication stream, such as the IETF stream for most Standards Track RFCs.

Access and Copyright

Obtaining RFC Documents

The primary repository for obtaining RFC documents is the RFC Editor website at rfc-editor.org, where all published RFCs are available in multiple formats including full text (), , PDF, and XML. Users can retrieve individual RFCs by number via URLs such as https://www.rfc-editor.org/rfc/rfcXXXX.txt or browse bulk archives organized in ranges of 500 documents for download in or files. The IETF Datatracker at datatracker.ietf.org complements this by providing metadata on RFC status, errata reports, and document history, with direct links to the RFC Editor's versions. Search and indexing tools facilitate discovery, including the RFC Index maintained by the RFC Editor, which updates the original RFC 1000 framework to list all RFCs numerically with citations, titles, authors, and publication dates. Additional tools on the RFC Editor site allow searching by author, keyword, title, or status categories like Standards Track or Informational, while the IETF site offers mirrors with similar functionality for streamlined access. These resources support both manual and bulk retrieval, with RSS feeds available for new publications. RFCs are archived indefinitely as part of the RFC Series, assigned the ISSN 2070-1721, ensuring long-term preservation of over 9,800 documents as of November 2025. Programmatic access is enabled through the IETF Datatracker's RESTful , which mirrors the database structure for querying RFC , documents, and related data without for public endpoints. Following the adoption of the new format defined in 7992, RFCs now feature mobile-optimized rendering with responsive design for better readability on devices.

Copyright and Licensing Policies

The copyright policies for Request for Comments (RFC) documents have evolved to balance author ownership with broad accessibility for the internet community. Prior to 2006, the (ISOC) held copyrights for many RFCs on behalf of the (IETF), particularly for contributions submitted before the establishment of a dedicated entity for management. In 2006, the IETF Trust was created by ISOC and the Corporation for National Research Initiatives to serve as the custodian of IETF-related copyrights and trademarks. In December 2023, the IETF Intellectual Property Management Corporation (IETF IPMC) was formed as the successor to the IETF Trust, continuing these responsibilities. This shift was further formalized through updates to IETF Best Current Practices (BCPs), culminating in RFC 5378 (BCP 78) in November 2008, which obsoleted earlier policies and established the current framework for rights in contributions. An update to RFC 5378 recognizing the IETF IPMC is in draft as of July 2025, maintaining the core policies. Under the current policy outlined in RFC 5378, individual contributors and authors retain ownership of their original works submitted as IETF contributions, which may become part of RFCs. However, by submitting materials, authors grant the IETF IPMC a perpetual, irrevocable, non-exclusive, , worldwide, and sublicensable to exercise all rights under and related laws. This permits the IPMC to copy, publish, display, distribute, prepare works (with certain restrictions on modifications that alter specifications), and translate contributions for use in IETF documents. The terms are modeled after a BSD-like open , emphasizing free reuse and modification while requiring attribution to the original authors and inclusion of a no-warranty , which states that the material is provided "as is" without any guarantees of accuracy or fitness for a particular purpose. RFC 5378 details the IETF IPMC model, ensuring these apply uniformly to all IETF publication streams, including those from the IETF, (IAB), Independent Submissions, and Experimental streams, as well as to errata reports and corrections for RFCs. The policy promotes , with the IPMC licensing RFCs under its legal provisions to allow unrestricted copying, distribution, and limited adaptation worldwide, subject to the noted conditions. The core framework has remained consistent since the 2023 transition to the IETF IPMC, resulting in approximately 100% of RFCs being freely distributable without additional permissions for most non-commercial and educational uses as of November 2025.

References

  1. [1]
    » RFC Editor
    ### Summary of RFC Series from https://www.rfc-editor.org/
  2. [2]
    About RFCs - IETF
    The IETF publishes its technical documentation as RFCs, an acronym for their historical title Requests for Comments. They describe the Internet's technical ...
  3. [3]
    RFC 8700: Fifty Years of RFCs
    This RFC marks the fiftieth anniversary for the RFC Series. It includes both retrospective material from individuals involved at key inflection points as well ...
  4. [4]
    Introduction to the IETF
    RFCs. The IETF publishes its technical documentation as RFCs, an acronym for their historical title Requests for Comments. They describe the Internet's ...
  5. [5]
    RFC 8700: Fifty Years of RFCs
    The RFC Series began in April 1969 with the publication of "Host Software" by Steve Crocker. The early RFCs were, in fact, requests for comments on ideas ...
  6. [6]
    RFC 2026: The Internet Standards Process -- Revision 3
    ### Summary of RFCs in IETF Standards Development (RFC 2026)
  7. [7]
    RFC 1034 - Domain names - concepts and facilities - IETF Datatracker
    This RFC introduces domain style names, their use for Internet mail and host address support, and the protocols and servers used to implement domain name ...
  8. [8]
    RFC 1035 - Domain names - implementation and specification
    This RFC describes the details of the domain system and protocol, and assumes that the reader is familiar with the concepts discussed in a companion RFC.
  9. [9]
    RFC 8200 - Internet Protocol, Version 6 (IPv6) Specification
    RFC 8200 specifies IPv6, the successor to IPv4, with expanded addressing, simplified header, and improved support for extensions.
  10. [10]
    RFC 2555: 30 Years of RFCs
    ... first RFC was published on April 7, 1969 by Steve Crocker. It was entitled "Host Software". The second RFC was published on April 9, 1969 by Bill Duvall of ...Missing: origins | Show results with:origins
  11. [11]
    RFC 1: Host Software
    **Title:** Host Software
  12. [12]
    RFC 3: Documentation conventions
    The Network Working Group (NWG) is concerned with the HOST software, the strategies for using the network, and initial experiments with the network.
  13. [13]
    Number of RFCs Published per Year - » RFC Editor
    Year index: Click the document count below to see the list of RFCs published in a given year. 1968, 1, 1969, 26. 1970, 57, 1971, 182, 1972, 134, 1973, 161, 1974 ...
  14. [14]
    RFC 5620: RFC Editor Model (Version 1)
    The RFC Editor model presented in this document divides the responsibilities for the RFC Series into four functions: The RFC Series Editor, the Independent ...
  15. [15]
    About Us - » RFC Editor
    For 28 years, this RFC series was managed and edited by the Internet pioneer Jon Postel. ... The RFC Editor was a project at the USC Information Sciences ...<|separator|>
  16. [16]
    RFC 9280: RFC Editor Model (Version 3)
    This document specifies version 3 of the RFC Editor Model. The model defines two high-level tasks related to the RFC Series.
  17. [17]
    Alexis Rossi appointed as RFC Series Consulting Editor - IETF
    Sep 1, 2022 · Alexis Rossi has been appointed as the RFC Series Consulting Editor (RSCE). As RSCE, she will provide expert advice on the processes and policies for the RFC ...
  18. [18]
    RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport
    This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, ...Missing: editorial | Show results with:editorial
  19. [19]
    RFC 1000 - Request For Comments reference guide
    This RFC is a reference guide for the Internet community which summarizes of all the Request for Comments issued between April 1969 and March 1987.
  20. [20]
    Information on RFC 7991 - » RFC Editor
    RFC 7991 defines the "xml2rfc" version 3 vocabulary, an XML-based language for writing RFCs and Internet-Drafts.Missing: reflowable 2019
  21. [21]
    RFC v3 Format – LIVE
    Oct 7, 2019 · Over the fifty-year history of the series, the publication format of RFCs had very limited changes. Originally, the documents were typed on ...
  22. [22]
    https://www.ietf.org/blog/rfc-production-center-management-transition/
  23. [23]
    RFC INDEX
    Oct 31, 2025 · The RFC index includes the RFC number, title, author list, publication date, format, obsoletes, obsoleted-by, updates, updated-by, status, ...
  24. [24]
    https://www.rfc-editor.org/info/rfc7991
  25. [25]
    Internet-Drafts - IETF
    During the development of a specification, draft versions of the document are made available for informal review and comment by submitting them to the IETF's ...
  26. [26]
    https://www.rfc-editor.org/info/rfc7990
  27. [27]
    Informal guide to IETF process documents
    IETF specifications are published as RFCs. The IETF standards process, related processes, and the groups that guide and oversee them are also defined in RFCs — ...
  28. [28]
    RFC 2418 - IETF Working Group Guidelines and Procedures
    This document describes the guidelines and procedures for formation and operation of IETF working groups.
  29. [29]
    RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels
    RFC 2119 defines keywords like MUST, MUST NOT, REQUIRED, SHALL, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL to indicate requirement levels in RFCs.
  30. [30]
    RFC 5234 - Augmented BNF for Syntax Specifications: ABNF
    The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.
  31. [31]
    RFC 2196 - Site Security Handbook - IETF Datatracker
    This handbook is a guide to developing computer security policies and procedures for sites that have systems on the Internet.
  32. [32]
    https://datatracker.ietf.org/doc/html/rfc2418
  33. [33]
    RFC 9280 - RFC Editor Model (Version 3) - IETF Datatracker
    This document specifies version 3 of the RFC Editor Model. The model defines two high-level tasks related to the RFC Series.
  34. [34]
    RFC 4844: The RFC Series and RFC Editor
    ### Definition of Publication Streams in RFCs
  35. [35]
    Submissions and Publications, by Stream and by Status - » RFC Editor
    2025. October. Submissions. IAB, IETF WG, IETF NWG, Indep, IRTF, Editorial ... Publications. IAB, IETF WG, IETF NWG, Indep, IRTF, Editorial, Total. IS, 0, 0, 0, 0 ...
  36. [36]
    Information on RFC 9000 - » RFC Editor
    RFC 9000 defines the core of the QUIC transport protocol, providing flow-controlled streams, low-latency connection, and network path migration.Missing: responsibilities consistency independence ~100 annually
  37. [37]
    RFC 2026: The Internet Standards Process -- Revision 3
    This memo documents the process used by the Internet community for the standardization of protocols and procedures.
  38. [38]
    RFC 6360: Conclusion of FYI RFC Sub-Series
    ### Summary of FYI Sub-Series Conclusion (RFC 6360)
  39. [39]
    RFC 6410: Reducing the Standards Track to Two Maturity Levels
    ### Summary of Standards Track Advancement Process and Requirements (RFC 6410)
  40. [40]
    Downloading RFCs - » RFC Editor
    Get TAR or ZIP files of RFCs ; RFC 9001 – 9500, TAR or ZIP, – ; RFC 8501 – 9000, TAR or ZIP, – ; RFC 8001 – 8500, TAR or ZIP · TAR or ZIP ; RFC 7501 – 8000, TAR or ...
  41. [41]
    IETF Datatracker
    The IETF Datatracker is the day-to-day front-end to the IETF database for people who work on IETF standards. It contains data about the documents, working ...Search · About · Active IETF working groups · System Status
  42. [42]
    https://www.rfc-editor.org/rfc/rfc2026.html
  43. [43]
    https://www.rfc-editor.org/rfc/rfc6360.html
  44. [44]
    API Notes - IETF Datatracker
    The datatracker API uses tastypie to generate an API which mirrors the Django ORM (Object Relational Mapping) for the database.
  45. [45]
    RFC 7992 - HTML Format for RFCs - IETF Datatracker
    RFC 7992 defines the HTML format for RFCs, a strict subset of HTML, as a non-canonical publication format, using a strict subset of HTML.Missing: 2019 optimized
  46. [46]
    Frequently Asked Questions - IETF Trust
    Oct 26, 2022 · Updated October 26, 2022. The Trust and its topic areas can be confusing, particularly if you are new to the world of copyrights and ...
  47. [47]
    The IETF Trust's Copyrights and Licenses
    The IETF Trust was created to hold and license the IETF's copyrights and trademarks. This is a summary of the copyrights and copyright licenses that the Trust ...
  48. [48]
    RFC 5378: Rights Contributors Provide to the IETF Trust
    This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet.
  49. [49]
    Copyrights and Patent Rights in RFCs - » RFC Editor
    The IETF Trustee License Information page summarizes the current rules governing RFC copyrights and disclaimers on intellectual property rights.