what is internet research task force

IRTF -- Internet Research Task Force

• Living Internet
• IRTF, Internet Research Task Force

The mission of the Internet Research Task Force (IRTF) is to conduct research into the long term future of the Internet . The IRTF is guided by the Internet Research Steering Group, and is composed of a number of small research groups that work on the development of the Internet protocols, applications, architecture, and technology. Befitting its long term focus, it is composed of members that serve for extended periods, but as individuals, and not as representatives of organizations.

The role of the IRTF is not to set Internet standards, but to take the long view of the future of the Internet, to research this future within its various research groups, and document the results in journals, white papers, and at conferences. Any technologies created as a result are brought to the Internet Engineering Task Force working groups.

The chair of the IRTF is appointed by the Internet Architecture Board. The Internet Research Steering Group is composed of the chairs of the IRTF research groups.

The Internet Research Steering Group (IRSG) manages the IRTF research groups, and holds workshops focused on various Internet research areas.

RFC’s . Request For Comments that provide information about the IRTF are listed below:

• The IRTF Research Groups are described in Request For Comments 2014 .

• Application development

Internet Engineering Task Force (IETF)

• Katie Terrell Hanna

What is the Internet Engineering Task Force (IETF)?

The Internet Engineering Task Force (IETF) is the body that defines standard operating internet protocols such as TCP/IP .

The IETF is an open standards organization supervised by the Internet Society's Internet Architecture Board (IAB). However, prior to 1993, the IETF was supported by the United States federal government.

IETF organizational structure

IETF members are volunteers, drawn from the Internet Society's individual and organization membership . Members form working groups and area directors appoint a chairperson (or co-chairs) to deal with a particular area discussed in IETF meetings.

Ultimately, the area directors, working groups and chairs form the Internet Engineering Steering Group (IESG), which is responsible for creating internet standards expressed in the form of Requests for Comments ( RFCs ).

Decisions on a standards track are made by rough consensus instead of formal voting protocols.

As part of overseeing the work of the IETF, the IAB supervises the RFC editor and offers technical direction to ensure the smooth operation of the internet.

They are also responsible for the Internet Research Task Force (IRTF), an organization parallel to the IETF that focuses on long-term research on issues relevant to the evolution of the internet.

Additionally, the Internet Assigned Numbers Authority (IANA), an organization responsible for overseeing global IP address allocation, root zone management in the Domain Name System ( DNS ), autonomous system number allocation, and other Internet Protocol-related symbols and numbers, also works closely with the IETF.

Funding for IETF activities is provided by meeting dues, sponsors and proceeds provided by organizational membership to the Public Interest Registry.

IETF areas of focus

The common areas of focus for the IETF include:

• applications
• infrastructure
• operations and management
• real-time applications

The internet standards process includes proposing specifications, developing standards based on agreed-upon specifications, coordinating independent testing and revising proposals based on testing results.

Before proposals become official standards, multiple interoperable implementations must be successful. In fact, protocols can be used in many different systems or as running code used to flesh out system architectures.

IETF notable projects

In addition to the IETF standards process, the group also coordinates a number of other activities.

One such example is hackathons hosted by the IETF which are geared toward improving the interoperability and quality of the internet.

Internet of things (IoT)

The IoT is a network of software, electronics and sensors that facilitate data exchange and communication for manufacturers, operators and their connected devices. Multiple IETF working groups have developed the internet governance standards that regulate the IoT.

Legislation

The IETF also cooperates with a number of standards bodies that seek to regulate the internet and make it safer. Some examples include the International Standards Organization ( ISO ), the International Telecommunication Union (ITU) and the World Wide Web Consortium ( W3C ).

Continue Reading About Internet Engineering Task Force (IETF)

• Opportunistic encryption: The IETF's 50 shades of protection
• 12 common network protocols and their functions explained
• Common application layer protocols in IoT explained
• The future of trust will be built on data transparency
• The 3 types of DNS servers and how they work

Related Terms

A URL (Uniform Resource Locator) is a unique identifier used to locate a resource on the internet.

File Transfer Protocol (FTP) is a network protocol for transmitting files between computers over TCP/IP connections.

A virtual private network (VPN) is a service that creates a safe, encrypted online connection.

Cybercrime is any criminal activity that involves a computer, network or networked device.

Cloud computing requires a security approach that is different than traditional protections. Where does cloud detection and ...

An endpoint protection platform (EPP) is a security technology that safeguards endpoint devices.

Demand shaping is an operational supply chain management (SCM) strategy where a company uses tactics such as price incentives, ...

Data monetization is the process of measuring the economic benefit of corporate data.

C-level, also called the C-suite, is a term used to describe high-ranking executive titles in an organization.

Employee self-service (ESS) is a widely used human resources technology that enables employees to perform many job-related ...

Diversity, equity and inclusion is a term used to describe policies and programs that promote the representation and ...

Payroll software automates the process of paying salaried, hourly and contingent employees.

A contact center is a central point from which organizations manage all customer interactions across various channels.

Voice or speaker recognition is the ability of a machine or program to receive and interpret dictation or to understand and ...

Customer segmentation is the practice of dividing a customer base into groups of individuals that have similar characteristics ...

Policies and Procedures

The IRTF is managed by the IRTF Chair in consultation with the Internet Research Steering Group (IRSG). The IRSG membership includes the IRTF Chair, the chairs of the various Research Groups, and other individuals (“members at large”) from the research community selected by the IRTF Chair.

RFCs Relating to Organisation and Operation of the IRTF

Conduct, diversity, and inclusion, other policies.

An official website of the United States government

Here’s how you know

Official websites use .gov A .gov website belongs to an official government organization in the United States.

Secure .gov websites use HTTPS A lock ( Lock A locked padlock ) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

https://www.nist.gov/ctl/wireless-networks-division/internet-technologies-research-group

Internet Technologies Research Group

Works with industry to improve the quality and timeliness of emerging technical specifications for next-generation Internet technologies and distributed information systems and to foster their adoption and deployment in operational networks. The emphasis of the group is on innovating and applying advanced measurement science to increase the security and resilience and expand the applicability of new, potentially disruptive, Internet technologies.

Evolving the Technical Infrastructure of the Internet

Internet technologies    provide a technical infrastructure for most of the systems (information, transportation, manufacturing, communications, defense, Government,  education, entertainment, etc) that underlie our lives.

• The global Internet is at a crossroads as the viability of several of its most basic infrastructural technologies  (routing, naming and addressing) are threatened by inherent  vulnerabilities and robustness problems.
• Internet technologies provide the basis for networks of the future - including the Internet of Things, industrial control systems, advanced mobile broadband, cloud computing, etc.   The pace of innovation in Internet technologies to address these new and disruptive use cases is rapid.

ITRG Mission:

• Fostering New Network Technology - The ITRG works with industry to improve the quality and timeliness of emerging specifications and to foster industry adoption  of next-generation Internet technologies and distributed information systems. 
• Advancing Network Metrology - The emphasis of the group is on innovating and applying advanced measurement science to increase the robustness and expand the applicability of potentially disruptive Internet technologies. 
• Competencies of the group include: leadership in industry consensus standards, modeling and analysis of emerging Internet technologies, measurement science for scalable information systems, design and evaluation of advanced network test and measurement techniques, and rapid prototyping and empirical measurement of early protocol designs.
• Our efforts focuses on Internet Scale problems, solutions and measurement techniques .

ITRG Techniques / Competencies:

• Internet scale modeling for performance, scalability, vulnerability, robustness.
• Internet Engineering Task Force (IETF), Internet Research Task Force (IRTF), North American Network Operators Group (NANOG), WiFi Alliance.
• Measurement and monitoring of Internet infrastructure.
• Collaboration with various large scale measurement activities.
• Open source reference implementations of emerging specifications.
• Fostering commercial adoption and deployment
• Test tools designed to assist implementers and early adopters.
• Accredited testing laboratories for formal product interoperability and conformance.

ITRG Current Focus Areas:

ITRG's primary focus is upon  Trustworthy Networks  Research , where we  work to establish the technical basis necessary to improve the security, resilience and performance of the communication infrastructures that underlie our network-centric society. Our research cultivates trust in current and emerging network technologies by developing and applying innovative measurement techniques, improving the quality and timeliness of consensus standards, and providing tools and guidance necessary to expedite adoption of advanced network technologies.  ITRG collaborates directly with leading industry research ( Internet Research Task Force ), standards ( Internet Engineering Task Force ,  O-RAN Alliance ,  ATIS ) and network operations ( North American Network Operators Group ) communities to leverage NIST contributions and  foster the design, standardization and commercial deployment of solutions to systemic vulnerabilities and robustness issues in existing and emerging core network infrastructure.

Current project areas within this program include:

• The  Advanced Security Architectures for Next Generation Wireless  project works with mobile wireless, internet and virtual computing industry to improve the security and resilience of emerging designs for 56 / 6G core networks and radio access networks (RANs).  Our current work focuses on enhancing the security properties of emerging O-RAN Alliance standards for 5G Open-RAN and disaggregated virtualize core networks.
• The Zero Trust Networks project seeks to define the basic principles of zero trust architectures and to develop standards and guidance for their implementation in modern enterprise environments and in the core infrastructure of next generation wireless networks.
• The  Robust Inter-Domain Routing  project includes collaborative research with leading Internet companies to design and standardize technologies to improve the resilience and security of the Internet’s global routing system. It focuses on developing and fostering deployment of mitigation techniques for attacks and misconfigurations that result in large-scale Internet outages.
• The  Trustworthy Intelligent Networks   project   works with industry and academia to improve the trustworthiness and applicability of artificial intelligence and machine learning technologies to future networks and distributed systems.  Our research focuses on applications of AI/ML to address security and robustness issues today's networks and developing means to test and measure the robustness of AI/ML techniques necessary for future autonomic networks.
• The  High Assurance Domains   project works with the IETF, Messaging Malware Mobile and Anti-Abuse Working Group (MAAWG), Department of Defense and the Federal CIO Council to research and develop new technologies to address key trust and security issues in enterprise networks. The current focus of this effort is on the development of a reference architecture and evaluation techniques for emerging  Zero Trust Networks.
• The  Software Defined and Virtual Networks  project works to develop test and measurement techniques to advance the state of the art in network virtualization, network service function chaining, software defined networks, technologies and techniques to address robustness and security of virtualized network services.  Our work explores novel applications of NFV/SDN to domains such as network security and intrusion detection,  support of machine to machine communications, support of advanced mobility and cloud computing.  A key component of this research is the development of enabling programmable measurement techniques that can efficiently operate at the scale and speed of advanced networks.
• The  Trustworthy Network of Things   project works with industry to design, standardize, test and foster adoption of network-centric approaches to protect IoT devices from the Internet and to protect the Internet from IoT devices.  Our current efforts focus on the research and development manufacturer usage description (MUD) and secure device onboardings technologies.
• The  USGv6 Program  works with the IETF and Federal CIO community to provide technical leadership in standards profiles, product testing programs, and deployment guidance to foster the global transition to the next generation Internet Protocol (IPv6).
• The  Measurement Science for Complex Information Systems  project aims to develop and evaluate a coherent set of methods to understand behavior in complex information systems, such as the Internet, computational grids and computing clouds. Such large distributed systems exhibit global behavior arising from independent decisions made by many simultaneous actors, which adapt their behavior based on local measurements of system state. Actor adaptations shift the global system state, influencing subsequent measurements, leading to further adaptations. This continuous cycle of measurement and adaptation drives a time-varying global behavior. For this reason, proposed changes in actor decision algorithms must be examined at large spatiotemporal scale in order to predict system behavior. 

Please see each project for details of our contributions including research publications, standards specifications, software tools, guidance documents, workshops, etc.

News and Updates

NIST Releases Measurement Tool for Emerging BGP Security Technologies

Zero trust architecture: nist publishes sp 800-207, nist publishes sp 800-189, resilient interdomain traffic exchange: bgp security and ddos mitigation, nist updates usgv6 program in support of new federal ipv6 initiatives.

New Network Security Standards Will Protect Internet’s Routing

Recent select publications, zero trust architecture, accupipe: accurate heavy flow detection in the data plane using programmable switches, resilient interdomain traffic exchange: bgp security and ddos mitigation, software defined networking (sdn) enhanced edge computing: a network centric survey, soft mud: implementing manufacturer usage descriptions on openflow sdn switches, botsifter: a sdn-based online bot detection framework in data centers, evaluating predictors of congestion collapse in communication networks, selected software, bgp secure routing extension (bgp‑srx) software suite.

NIST RPKI Deployment Monitor

BRITE - BGPSEC / RPKI Interoperability Test & Evaluation System

Nist ipv6 deployment monitor and test system, awards and recognition.

2019 - Bronze Medal Award---Oliver Borchert, William Haag Jr., Tim McBride, Douglas Montgomery, Scott Rose, Murugiah Souppaya, Kotikalapudi Sriram

ITRG Quick Links

• NIST IPv6 Deployment Monitor and Test Tool. - http://fedv6-deployment.antd.nist.gov /
• NIST RPKI Monitor - http://rpki-monitor.antd.nist.gov /
• NIST BGP Secure Routing Extension (BGP‑SRx) Software Suite -  https://www.nist.gov/services-resources/software/bgp-secure-routing-extension-bgp-srx-software-suite

ITRG Additional Information

• D. Montgomery; Internet and Scalable Systems Research: Addressing Systemic Challenges to Our Network Centric Society ; presentation.
• Current Opportunities for Collaboration with ITRG .

ITRG Information Contact:

• Doug Montgomery [email protected] (301) 975-3630
• ITRG Contact [email protected]

IETF and the Internet Society

Vint Cerf, 18 July, 1995 A bit of history :

Read more about the IETF and the Internet Society.

The Internet Society was formed by a number of people with long-term involvement in the Internet Engineering Task Force (IETF) . As a result, one of its principal rationales was to provide an institutional home for and financial support for the Internet Standards process. This rationale still exists today. In 1990, it appeared that long-term support for the standards-making activity of the IETF which had come primarily from research supporting agencies of the US Government (notably ARPA, NSF, NASA and DOE) might need to be supplemented in the future, either because such support would diminish or that requirements would exceed the limits of available support. Even at that time, attendance fees were used in part to offset on-site costs which otherwise would have had to be borne by US Federal funding.

In contemplation of the need for a mechanism for aggregating funding from many sources, it was proposed to form an Internet Society and to use its resources, in part, to provide funds in support of IETF. The plan was for the Society to engage in a variety of activities including conferences, workshops, and raise funds from industry and other institutional sources. It does so on an international basis, and acts as a neutral and internationally recognized body, devoted to the support of Internet administrative infrastructure, including, for example, IAB, IETF, IRTF and IANA. Ideas for the formation of this organization were discussed in IAB and IETF meetings early in 1991 and plans were announced at the INET Conference in June 1991 in Copenhagen. The Internet Society was officially formed in January 1992. In June, 1992, at the annual meeting of the Internet Society, INET’92, in Kobe, Japan, the Internet Activities Board proposed to associate its activities with the Internet Society and was renamed the Internet Architecture Board (IAB). Historically, the IETF and its sister organization, the Internet Research Task Force  (IRTF), had been considered two arms of the IAB.

During the last half of 1992, the relationship between the IAB and the IETF came under scrutiny through the first POISED Working Group which reallocated responsibilities for standards decision making and established the framework around which the current practices for populating IAB and IETF are conducted. The POISED Working Group presented its conclusions and recommendations to the  Internet Society Board of Trustees in December 1992  and these were accepted as the working basis for the relationships among IAB, IESG, the Internet Society and IETF participants. Subsequently, RFC 1310 was prepared by the IETF in an attempt to codify these working principles (RFC 1602 is the current version of this document).

Starting in 1993 , the Internet Society assumed its responsibilities under RFC 1602, and participated in various reviews of that process. The Internet Society provided financial support for the IETF secretariat in the amount of $225K during 1993. Financial support was not provided during 1994 because of the uncertainty of the fiscal results of the Internet Society’s other activities, notably INET’94 and the associated Developing Countries Workshop.

At the June 1995  Internet Society Board of Trustees meeting, the trustees confirmed that the highest the Internet Society’s goal was to “keep the Internet going.” It was agreed that among the high priority activities associated with that goal was to provide support for the Internet Standards process carried out by the Internet Engineering Task Force. “Support” was taken in a large sense to mean provision of service or other measures which would facilitate the work of the IETF.

The Board has taken several actions in 1995 in support of IETF:

• Funded legal counsel for the Internet Engineering Steering Group, specifically in aid of intellectual property rights issues in relation to standards making. Counsel is Geoff Stewart of Hale and Dorr. Mr. Stewart attended the Danvers IETF meeting and his subsequent invoice to the Internet Society (under $4000) benefitted from considerable pro bono contribution to IETF by Hale and Dorr in connection with this work.
• The Board of Trustees established a  1995 budget line item  for funding of IETF activities (provided they fall within the scope of activities permitted under the Internet Societys 501(c)(3) non-profit status). The line item amounts to a $250K per year level of support  starting in July 1995 . The funds are to be spent in accordance with IETF and IESG direction as conveyed to the Internet Society by the IETF chair.
• The President of the Internet Society appointed the Nominating Committee chairman to carry out the task of nominating slates of appointees for IAB and IESG and, subsequently, the Board of Trustees approved the IAB slate, in accordance with the procedures of RFC 1602.
• At the Internet Society’s request, the insurers of the Internet Society extended its Directors and Officers liability coverage explicitly to include coverage for the members of the IESG and IAB. It did not prove possible to extend this coverage to Working Group chairs since the theory which allowed the extension of Directors and Officers liability to include IAB and IESG was not considered adequate to cover Working Group chairs.
• The Internet society successfully established a membership relationship between the Internet Society and the ITU which forms a basis for any desired coordination between activities of the Internet Society and various activities of the ITU, notably the ITU- Standardization Sector (ITU-T), the ITU-Radio Sector (ITU-R) and the ITU Development Sector. The activities of the IETF are most closely related to those in ITU-T, so exchange of information, joint meetings or other coordinating efforts, if any are desired, would presumably take place between IETF and ITU-T. There is no requirement for any particular interaction between these groups, only the potential should it be deemed mutually beneficial.
• The Board of Trustees also appointed a  Vice President for Standards , Scott Bradner, to serve as liaison with the IETF. A key responsibility of this position is to convey to the Board of Trustees advice and guidance for additional facilitating actions that the Internet Society might take in support of the IETF work. Bradner is an elected Trustee of the Internet Society and a member of the Internet Engineering Steering Group.
• At the request of the IETF, the Internet Society signed an agreement with SUN Microsystems transferring responsibility for further evolution of the ONC RPC and XDR technical specifications to the IETF. The agreement included reference to licensing arrangements for implementors of this technology. This agreement took an inordinate amount of time to conclude and that has become grounds for re-examination of the intellectual property aspects of RFC 1602.
• Christian Huitema current chair of the IAB and an elected the Internet Society trustee was appointed chair of a committee to address the relationship between IETF and the Internet Society.

The POISED Working Group has a number of topics to cover, one of which is to discuss the relationship between IETF and the Internet Society. There are a number of possible outcomes of this discussion. IETF could choose to dissociate itself from any connection with the Internet Society. Or it could formally propose a relationship under the neutral, international auspices of the Internet Society. I believe there is far more to be gained by maintaining and augmenting the existing framework in which the Internet Society supports the work of the IETF, but ultimately this must be a choice made by the participants in the IETF and the members of the IESG who lead it. Regardless of the outcome, I believe that the  Internet Society should continue to provide support for the IETF   where possible because of the importance of its work to the continued well-being of the Internet.

Role of the IAB

The IAB is chartered both as a committee of the Internet Engineering Task Force (IETF) and as an advisory body of the Internet Society (ISOC) . Its responsibilities include:

IESG Confirmation : The IAB confirms the IETF Chair and Internet Engineering Steering Group ( IESG ) Area Directors, from nominations provided by the IETF Nominating Committee .

Architectural Oversight : The IAB provides oversight of, and occasional commentary on, aspects of the architecture for the protocols and procedures used by the Internet. As part of its technical work and architectural oversight role, the IAB convenes workshops , initiates and executes technical work programs , and writes documents that lead to comprehensive technical analyses of matters of interest or provide guidance about protocol design and considerations to the community.

Standards Process Oversight and Appeal : The IAB provides oversight of the process used to create Internet Standards . The IAB serves as an appeal board for complaints of improper execution of the standards process through acting as an appeal body in respect of an IESG standards decision.

IANA : The IAB is responsible for administration of the assignment of IETF Protocol parameter values by the IETF Internet Assigned Numbers Authority ( IANA ). The IAB maintains an administrative support group in collaboration with IANA.

External Liaison : The IAB acts as representative of the interests of the IETF in liaison relationships with other organizations concerned with standards and other technical and organizational issues relevant to the world-wide Internet. The IAB Liaison Coordinators serve as contact point with the IAB for liaison management.

Advice to ISOC : The IAB acts as a source of advice and guidance to the Board of Trustees and Officers of the Internet Society ( ISOC ) concerning technical, architectural, procedural, and (where appropriate) policy matters pertaining to the Internet and its enabling technologies. The IAB maintains an administrative support group for policy coordination with ISOC.

IRTF Chair : The IAB selects a chair of the Internet Research Task Force ( IRTF ) for a renewable two year term.

Related documents:

• RFC 2850: Charter of the Internet Architecture Board (IAB)
• New Work and BOF Shepherding
• Appointments & Confirmations
• Liaison Coordination

This is a potential security issue, you are being redirected to https://csrc.nist.gov .

You have JavaScript disabled. This site requires JavaScript to be enabled for complete site functionality.

An official website of the United States government

Here’s how you know

Official websites use .gov A .gov website belongs to an official government organization in the United States.

Secure .gov websites use HTTPS A lock ( Lock Locked padlock icon ) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

• Drafts for Public Comment
• All Public Drafts
• NIST Special Publications (SPs)
• NIST interagency/internal reports (NISTIRs)
• ITL Bulletins
• White Papers
• Journal Articles
• Conference Papers
• Security & Privacy
• Applications
• Technologies
• Laws & Regulations
• Activities & Products
• News & Updates
• Cryptographic Technology
• Secure Systems and Applications
• Security Components and Mechanisms
• Security Engineering and Risk Management
• Security Testing, Validation, and Measurement
• Cybersecurity and Privacy Applications
• National Cybersecurity Center of Excellence (NCCoE)
• National Initiative for Cybersecurity Education (NICE)

Internet Research Task Force

IRTF show sources hide sources NIST SP 800-208

Glossary Comments

Comments about specific definitions should be sent to the authors of the linked Source publication. For NIST publications, an email is usually found within the document.

Comments about the glossary's presentation and functionality should be sent to [email protected] .

See NISTIR 7298 Rev. 3 for additional details.

RFCs are the core output of the IETF.

Introduction

Structure of the series, availability and use, publication formats, publication streams, obsoleting and updating, corrections and errata, reporting vulnerabilities in rfcs.

The IETF publishes its technical documentation as RFCs, an acronym for their historical title Requests for Comments . They describe the Internet's technical foundations, such as addressing, routing, and transport technologies. RFCs also specify protocols like TLS 1.3, QUIC, and WebRTC that are used to deliver services used by billions of people every day, such as real-time collaboration, email, and the domain name system.

Software developers, hardware manufacturers, and network operators around the world voluntarily implement and adopt the technical specifications and best practices described by RFCs.

The RFC Editor website is the authoritative site for RFCs. The IETF Datatracker provides transparency on the process that resulted in the publication of each RFC.

RFCs are sequentially numbered, starting with RFC 1 published in 1969 (the RFC series predates the IETF). Today, there are more than 9000 documents in the series.

The RFC series has two subseries, STDs and BCPs, with each numbered STD and BCP comprising one or more RFCs. STDs are 'Internet Standard' RFCs, and BCPs are RFCs that describe 'Best Current Practices' for the Internet, some of which are administrative processes for the IETF.

RFCs are freely available to download, copy, publish, display and distribute, in a variety of formats, under a license granted by the IETF Trust . This license, the Trust Legal Provisions , has some important restrictions, including a prohibition on modification of RFCs outside of the IETF Standards Process.

RFCs are not guaranteed to be patent-free and anyone interested in the Intellectual Property Rights (IPR) constraints on a specific document should consult the IETF's IPR disclosure database , though this is not guaranteed to be a complete record of applicable patents.

RFCs are published in the following formats:

HTML . This is the most flexible format for reading an RFC: the page layout adapts to the window size; if SVG diagrams are supplied, they are displayed; and the text is accompanied by a header showing important metadata, including the details of any RFCs that this RFC updates or obsoletes, and vice versa, as well as indicating the existence of errata and linking to those. For RFCs before RFC 8650, the HTMLised (see below) format is used in place of the HTML.

Plain Text . RFCs were originally produced on typewriters, and a plain text format that looks very similar to those original RFCs is still available. The main limitations of the plain text format are that the metadata cannot change, only ASCII diagrams can be displayed, links in the text are shown as annotations, the line width is fixed so may be difficult to read on a mobile device, and there is no indication of the existence of errata.

HTMLised . This format displays the Plain Text format as an HTML page with working links and the same metadata as the HTML version; however, it shares the rest of the limitations as the plain text format. This format is available for RFCs before RFC 8650.

PDF . This is a PDF of an HTML rendering of the RFC, so it can display any SVG diagrams and it provides working links. However, the metadata is limited. PDFs are the only paginated RFC format.

RFCXML . This is the raw source of RFCs, not a publication format. RFCXML is an XML language fully documented on the I-D Authors Resource Site and has been used as the source format since RFC 8650.

Most RFCs and all new RFCs have one of the following statuses. Statuses may change over time.

Informational . An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. RFC 2026, Section 4.2.2

Experimental . The "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work RFC 2026, Section 4.2.1

Standards have one of the following statuses:

Proposed Standard (PS) . The first official stage. Many standards never progress beyond this level.

Draft Standard . An intermediate stage that is no longer used for new standards.

Internet Standard . The final stage, when the standard is shown to be interoperable and widely deployed.

Best Current Practice (BCP) . BCPs have a dual role. One is to document IETF processes as agreed by the IETF community, and the other is explained in RFC 2026, Section 5 as: since the Internet itself is composed of networks operated by a great variety of organizations, with diverse goals and rules, good user service requires that the operators and administrators of the Internet follow some common guidelines for policies and operations.

Historic . A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level. RFC 2026, Section 4.2.4

RFCs that were published before statuses were introduced (before RFC 1128) are mostly considered to have an Unknown status, with a handful having had statuses retroactively applied.

There are five streams that can publish an RFC.

THE IETF Stream is the only stream that can publish standards and by far the largest. All RFCs published in the IETF Stream must have community rough consensus, whatever their status.

The IAB Stream and IRTF Stream can also publish technical and process RFCs related to their role.

The Editorial Stream, as described by RFC 9280 publishes policies governing the RFC Series as a whole.

The Independent Submissions Stream publishes RFCs that are outside the official processes of the IETF, IAB, and IRTF but are relevant to the Internet community and achieve reasonable levels of technical and editorial quality.

An RFC can be entirely obsoleted by a new RFC or have parts of it updated by other RFCs. A new RFC can update parts of multiple RFCs, and can obsolete multiple RFCs.

Most of the publication formats note if an RFC has been obsoleted or updated and lists the RFCs responsible.

With one exception, once an RFC is published, it is never changed, which is why the RFC series is often described as "archival" in nature. The one exception to this rule is if an RFC is rendered incorrectly, such as some text cut off, in which case the specific publication format with the problem may be replaced.

If a technical or editorial error in an RFC is reported, an erratum may be created that documents the error and optionally provides a correction. Newly Reported errata are checked and either Verified, Rejected or Held for Document Update. For Technical errata, this decision is made by the appropriate stream-specific party, and for Editorial errata, by the RFC Editor.

The RFC Editor site has more details on these statuses and a searchable errata database .

Verified errata are linked to the RFC, but the RFC is not republished with the errata incorporated. There is ongoing work to provide a good way of displaying an RFC with the errata incorporated.

The IETF recognizes that security vulnerabilities will be discovered in IETF protocols and welcomes their critical evaluation by researchers. If you believe that you have discovered a vulnerability in an IETF protocol then please follow our guidance on how to report vulnerabilities .

you might be interested in

RFC Editor website

How to Read an RFC

RFC 8700: Fifty Years of RFCs

Key moments in RFC History (from RFC 8700)