Fact-checked by Grok 2 weeks ago

Internet Standard

An Internet Standard is a specification that is stable and well-understood, technically competent, has multiple independent interoperable implementations with substantial operational experience, enjoys significant public support, and is recognizably useful in some or all parts of the Internet. Internet Standards are developed by the , an open international community of network designers, operators, vendors, and researchers founded in 1986 to produce high-quality technical documents that enhance Internet functionality. The IETF's standardization process, outlined in RFC 2026 (Best Current Practice 9), emphasizes principles such as technical excellence, prior implementation and testing, clear and precise documentation, openness, fairness, and timeliness to foster broad community consensus. This process has evolved through amendments, including separations of intellectual property rules into BCP 78 and BCP 79, and the reduction of maturity levels to two in RFC 6410 (2011), ensuring adaptability while maintaining core goals. Documents advance through a two-stage track: Proposed Standard, the entry level requiring stability and significant community review without mandatory implementations; advancing to Internet Standard upon demonstrating at least two independent, interoperable implementations with substantial operational experience, representing the final stage of high technical maturity, assigned an STD number for official recognition. All such standards are published as in ASCII text format, serving as the definitive reference, and may reference external standards if they are publicly accessible online. This rigorous, consensus-driven approach has enabled the interoperability of diverse technologies since the IETF's early contributions to protocols like TCP/IP.

Definition and Fundamentals

Core Definition

An Internet Standard is defined as a specification that is stable and well-understood, technically competent, has multiple, independent, and interoperable implementations with substantial operational experience, enjoys significant public support, and is recognizably useful in some or all parts of the Internet. These specifications are published as Request for Comments (RFC) documents on the Internet Standards Track and achieve full maturity after progressing through defined stages of review and implementation testing. Full Internet Standards differ from earlier stages on the track, such as Proposed Standards—which serve as entry-level documents requiring review but no mandatory implementations—and Draft Standards, which necessitate at least two , interoperable implementations along with documented operational experience. In contrast, full standards must demonstrate widespread adoption without requiring changes for a minimum of two years, ensuring long-term reliability and minimal risk of disruption to existing deployments. Central attributes of Internet Standards emphasize to enable seamless communication across diverse systems, to support consistent operation over time, and formal endorsement by the Internet Engineering Steering Group (IESG), which oversees approval following broad community consensus and last-call reviews. The IESG's role ensures that only specifications meeting these rigorous criteria advance to full standard status.

Purpose and Role in the Internet Ecosystem

Internet Standards primarily aim to ensure among diverse hardware, software, and network systems, enabling seamless data exchange and communication across heterogeneous environments worldwide. They promote by providing freely accessible specifications that allow developers, researchers, and organizations to contribute to and build upon established protocols without needing permissions or licenses. Furthermore, these standards prevent by avoiding dependence on single providers' technologies, thereby encouraging competition, reducing switching costs, and enhancing long-term system flexibility. Within the broader Internet ecosystem, Standards play a foundational role by defining essential protocols such as /, which enable reliable global connectivity, packet routing, and application-layer services that power everything from web browsing to . Their role extends to economic impacts, as widespread adoption of interoperable standards lowers development and deployment costs for , accelerates market entry for new technologies, and supports scalable growth in the . For instance, by standardizing core networking elements, they have facilitated the interconnection of billions of devices, driving efficiency and innovation across industries. The development of Standards is guided by the principle of "rough consensus and running code," which prioritizes practical, working implementations and informal agreement among participants over rigid procedures or untested ideas. This ethos ensures standards are deployable and effective in real networks, balancing technical rigor with community input. As of November 2025, over 9,000 Requests for Comments (RFCs) have been published, serving as the documented repository of Internet specifications, with approximately 100 designated as full Standards that represent the most mature and widely implemented protocols.

Historical Development

Origins in ARPANET

The , launched in 1969 by the , served as the foundational precursor to the modern , enabling the interconnection of research computers across the through packet-switching technology. Initially comprising four nodes—at UCLA, Stanford Research Institute (SRI), the , and the —the network's first successful connection occurred on October 29, 1969, when a message was transmitted between UCLA and SRI. This experimental system, designed to enhance resource sharing and resilience in communication, laid the groundwork for standardized protocols by demonstrating the feasibility of distributed networking. Early standardization efforts in were informal and evolved organically, beginning with the Network Control Protocol (NCP) introduced in 1970 to manage host-to-host communications. NCP provided the functionality for data exchange, allowing applications like and remote to operate across connected hosts, though it lacked robust error handling for diverse topologies. Implementation of NCP progressed through 1971-1972 as sites adopted it, marking the first de facto standard for ARPANET operations and enabling practical use by researchers. By the late 1970s, limitations in NCP's design prompted the development of more scalable protocols, culminating in the replacement of NCP with on January 1, 1983, as outlined in RFC 801. This transition, known as "," standardized by adopting the for reliable end-to-end delivery and the for addressing and routing, forming the core of what would become the internet's foundational standards. Key contributors Vinton Cerf and Robert Kahn developed through their seminal 1974 paper, which proposed a gateway-based architecture for interconnecting heterogeneous packet networks, establishing these protocols as the first widely adopted standards for open networking. Supporting these developments, the at SRI facilitated early protocol documentation through the formation of the Network Working Group (NWG) in 1969. Led by figures like , the NWG produced the initial , starting with RFC 1 in April 1969, to collaboratively document and refine protocols in an open, iterative manner. The served as the central repository for these documents, coordinating information dissemination and fostering consensus among ARPANET participants on technical specifications.

Evolution Through IETF Formation

The (IETF) emerged in 1986 as an informal collaborative group aimed at addressing technical challenges in the evolving , beginning with its first meeting in of that year in , , attended by 21 participants primarily from and academic backgrounds. This gathering marked a shift toward structured discussions on engineering, building on earlier developments but focusing on practical implementation rather than initial research. The group's informal nature allowed for rapid, consensus-driven progress without rigid hierarchies, contrasting with more bureaucratic standardization efforts like those in the . A pivotal milestone came in 1987 with RFC 1011, which outlined the official Internet protocols and implicitly structured the IETF's role in maintaining them, emphasizing a transition from ad-hoc, vendor-influenced developments to an open, community-led process accessible to non-vendors. This document highlighted the IETF's growing emphasis on through voluntary adoption, as attendance at meetings expanded beyond initial dozens to include broader industry input by the late . Concurrently, the Internet Activities Board (IAB), restructured in 1986 from prior advisory bodies, provided architectural oversight to guide the IETF's technical directions, ensuring long-term coherence in protocol evolution. By 1993, the IETF formalized its operations under the auspices of the newly established (ISOC), a non-profit organization founded in 1992 to support open development, which began providing financial and administrative backing—including $225,000 for the IETF secretariat that year. This affiliation marked a key institutional maturation, enabling sustained growth as participant numbers swelled into the thousands by the mid- through thrice-yearly meetings and discussions. The IETF's expansion facilitated the integration of emerging technologies, such as Web-related standards like HTTP following 's dominance in the early 1990s, solidifying its role as the central forum for advancement.

Governing Organizations

Internet Engineering Task Force (IETF)

The (IETF) operates as an open, volunteer-based organization dedicated to the evolution of standards through collaborative technical work. Its structure is decentralized, centered on working groups (WGs) that serve as the primary venues for developing specifications on specific topics within the Internet architecture. These WGs are organized into seven areas—such as Applications, , and —each managed by two area directors () who oversee progress, charter new groups, and ensure alignment with broader goals. The Internet Engineering Steering Group (IESG), composed of the ADs and the IETF Chair, provides overall technical oversight, reviews outputs for advancement, and manages the standards process. This volunteer-driven model relies on individual contributions from participants worldwide, with no formal corporate hierarchy or paid staff directing the core technical efforts. IETF operations emphasize accessibility and inclusivity, with most work conducted asynchronously via public dedicated to WGs and broader discussions. These facilitate ongoing collaboration, where participants propose ideas, review drafts, and refine protocols through threaded conversations archived for transparency. The organization holds three week-long meetings annually in rotating global locations, supplemented by remote participation options to accommodate diverse time zones and reduce barriers. Decision-making follows a -driven approach, relying on "rough " rather than formal votes, where the goal is to achieve broad agreement among active contributors while addressing objections. Recent meetings, such as IETF 123 in July 2025, have attracted over 1,500 participants combining onsite and remote attendees, reflecting the community's scale and commitment. Leadership within the IETF is appointed through a structured, community-nominated process to maintain impartiality and expertise. The IETF Chair, currently Roman Danyliw as of November 2025, coordinates overall activities, chairs the IESG, and represents the organization externally. Appointments for the Chair, ADs, and other key roles are handled by the annual IETF Nominating Committee (NomCom), a randomly selected group of volunteers from the community who solicit nominations, interview candidates, and recommend selections based on merit and diversity. This process, outlined in IETF procedures, ensures rotational leadership without formal dues or membership requirements, allowing anyone to participate by subscribing to lists or attending meetings upon registration.

Related Bodies and Their Roles

The (ISOC), founded in 1992, provides oversight and funding support for the (IETF), enabling the open development of Internet standards and protocols. ISOC also promotes global Internet policy by advocating for an open, secure, and trustworthy through international cooperation and initiatives. The (IAB) offers architectural oversight for protocols and procedures, ensuring long-range technical direction and consistency in standards development. It serves as an appeals body for complaints regarding the Internet Engineering Steering Group's (IESG) standards decisions and appoints the liaison to the (IANA) for managing protocol parameter assignments. The Engineering Steering Group (IESG), comprising area directors selected by the IETF Nominations Committee for two-year terms, reviews and approves specifications for advancement on the standards track, holding final authority over their publication as standards. Within the IETF's structure, the IESG manages activities and can veto proposed advancements to maintain technical quality and alignment with Internet architecture. Beyond core IETF components, the (W3C) develops open web standards, such as those for , , and , in close coordination with the IETF to ensure between web technologies and broader Internet protocols. Similarly, the (IANA) assigns and maintains protocol parameters essential for Internet operation, including port numbers for transport protocols like and , in collaboration with the IETF and its bodies.

Standardization Process

As of November 2025, the IETF is revising the standards process (draft-ietf-procon-2026bis), which may update some details described here.

Initial Proposal and Review

The standardization process for Internet Standards begins with the submission of a proposal in the form of an to an appropriate . This submission requires no prior permission and serves as the entry point for new work, where the draft must articulate a clear , propose a specific solution, provide relevant references, and outline the intended goals to facilitate community evaluation. Upon submission, the WG initiates review through its discussions and meetings, assessing whether the proposal warrants adoption as a WG document. For proposals targeting an existing WG, chairs first verify any rights (IPR) disclosures; adoption then proceeds if rough consensus emerges among WG participants, without requiring . If no suitable WG exists, the proposer may submit to the WG for routing or organize a (BoF) session to establish a new WG, whose must be approved by the relevant Area Directors () to ensure alignment with IETF priorities. A designated reviewer, often termed a document shepherd and selected by WG chairs, is assigned early to guide the draft, incorporate feedback, and verify adherence to WG processes. Proposals are evaluated against key criteria: they must demonstrate a genuine need within the Internet ecosystem, exhibit technical soundness through rigorous analysis, and conform to the broader principles, such as and . The draft must also fit within the WG's chartered and show potential for timely completion with community support. Internet-Drafts are publicly available for at least two weeks prior to any formal action, allowing initial feedback. The initial review phase typically concludes within six months, coinciding with the maximum validity period of an Internet-Draft before expiration; if the WG fails to achieve on adoption or relevance, the proposal is rejected, reverting to individual status or abandonment, preventing progression to later stages.

Advancement Stages

The Internet Standards Process outlines a series of maturity levels for documents on the standards track, ensuring protocols evolve through stages of , , and deployment before achieving full status. Originally comprising three levels—Proposed Standard, Draft Standard, and Internet Standard—the process was revised in to streamline it into two primary levels: Proposed Standard and Internet Standard, with the Draft Standard level retained only for pre-existing documents. This reduction aims to accelerate advancement while maintaining rigor, requiring demonstrated stability and at each step. A Proposed Standard represents the initial publication of a standards-track RFC following consensus within the relevant (IETF) working group and approval by the Internet Engineering Steering Group (IESG). It indicates a stable specification with resolved design choices and significant community review, though no implementations are required for initial publication—unlike earlier expectations, where they were merely desirable. To progress beyond this level, the document must demonstrate practical viability, including at least two independent implementations from separate code bases that interoperate successfully. Existing Draft Standards, classified before the revision, require similar evidence of operational experience and issue resolution but may be reclassified as Proposed Standards after two years if not advanced. Advancement to Internet Standard, the highest maturity level, is uncommon and demands extensive evidence of technical stability and broad adoption. This stage requires widespread deployment, successful operational experience across diverse environments, resolution of all known errata without interoperability impacts, and implementation of all specified features without unused complexities. The IESG conducts an IETF-wide Last Call to confirm consensus before approval, at which point the document receives a Standards (STD) number. For instance, the IPv6 protocol specification advanced to this level in 2017 via RFC 8200 (STD 86), incorporating updates from the original RFC 2460 after years of testing and deployment. Standards are assigned unique STD numbers upon advancement to Internet Standard; for example, the IPv6 specification is STD 86 (RFC 8200). Standards may also be updated, downgraded, or retired to reflect evolving needs. Minor corrections are handled through errata published by the Editor without altering the maturity level or resetting advancement timelines. Significant changes require a new , which may obsolete the original via an "Updates" or "Obsoletes" designation. For obsolescence, the IESG can designate a standard as Historic—effectively retiring it—following a Last-Call review, as seen in cases where superseded protocols no longer meet current requirements. This process ensures the standards remain relevant without unnecessary proliferation.

Final Approval and Maintenance

The final stage of the IETF standardization process involves the Internet Engineering Steering Group (IESG) conducting a for comments and subsequent approval to advance a to full standards track status. This solicits public input from the broader IETF community via the IETF Announce , typically lasting four weeks for individual submissions or two weeks for documents, though it may be extended if significant issues arise. Following the , the IESG reviews all feedback and holds an internal to determine whether the meets the criteria for advancement, such as technical soundness and community consensus; approval requires a majority vote among area directors, with any unresolved concerns addressed through revisions or holds. Upon IESG approval, the document is published by the RFC Editor as a Standards-Track , marking its formal adoption as an Internet Standard or progression to a higher maturity level. Each such standard is assigned a unique STD number for reference, separate from its number. This publication removes the document from the Internet-Drafts repository and ensures its archival stability, while the STD designation facilitates tracking of protocol families or related specifications. Maintenance of approved standards occurs through structured mechanisms to address issues without undermining stability. Minor corrections, such as bug fixes or clarifications, are handled via the RFC errata system, where verified reports are published online by the RFC Editor without republishing the entire RFC or resetting maturity timelines. Significant updates require a new RFC that progresses through the full standards process, potentially obsoleting or superseding the original; obsolete standards may be reclassified as Historic if they are no longer recommended. Additionally, the (IANA) maintains protocol parameter registries, assigning and tracking values like numbers or error codes as specified in the RFC, ensuring consistent implementation across the ecosystem. Success of a standard is evaluated through requirements for demonstrated viability, including at least two independent, implementations in widespread use, supported by implementation reports and interoperability testing to confirm operational stability and community adoption. These metrics, verified during the IESG review, help ensure that only robust specifications advance to Internet Standard status, emphasizing practical deployment over theoretical design.

Key Documents and Mechanisms

Request for Comments (RFCs)

The (RFC) series serves as the foundational documentation mechanism for standards, originating as informal memos among early network researchers and evolving into a structured repository of technical specifications, best practices, and informational publications. Initiated on April 7, 1969, with RFC 1, titled "Host Software," authored by of the (UCLA), the series began as a means to solicit feedback on host-to-host protocol designs during Network Working Group meetings. Crocker's document outlined initial software considerations for host connections, marking the start of a collaborative tradition that emphasized open discussion over authoritative pronouncements. By November 2025, the RFC series has grown to over 9,000 documents, reflecting the expansive development of protocols and practices. RFC documents follow a standardized structure to ensure clarity and consistency, beginning with a front-page header that includes the RFC number, title, authors, and publication date, followed by an abstract summarizing the document's purpose and scope. The status section specifies the document's category—such as Standards Track, Informational, Experimental, or Best Current Practice (BCP)—along with any updates, obsoletions, or errata references. The main body presents the technical content, often including introductions, detailed specifications, security considerations, and implementation notes, concluding with a references section listing normative and informative sources, and authors' addresses. This format has been refined over time to support machine-readable processing while maintaining readability. RFCs are categorized by their intended role in Internet development, with Standards Track documents forming the core pathway for protocol standardization. These progress through maturity levels: Proposed Standard (initial review and implementation testing), Draft Standard (demonstrated interoperability), and full Internet Standard (widespread adoption and stability). Informational RFCs provide general guidance or background without advancing standards, Experimental RFCs test novel ideas under controlled conditions, and BCP RFCs document operational best practices, such as BCP 14, which defines key normative terminology like "MUST," "SHOULD," and "MAY" for consistent interpretation across specifications. For instance, BCP documents often address administrative or procedural norms, separate from technical protocols. The series has evolved from simple, handwritten or typewritten memos in the late 1960s to formalized, digitally authored publications, with significant advancements in the introducing XML-based source formats for enhanced automation and accessibility. Early RFCs were distributed via or physical copies, but by the , they adopted a more rigid editorial process under Jon Postel's guidance as RFC Editor. The transition to XML, formalized in RFC 7990 (2016) and mandatorily applied starting with RFC 8650 (2019), enables tools for rendering into multiple formats (e.g., , PDF) and supports semantic searching, ensuring the series remains adaptable to modern publishing needs while preserving its archival integrity. This evolution underscores RFCs' role as the enduring vehicle for proposing, refining, and codifying standards through community consensus.

Internet Drafts and Their Lifecycle

Internet-Drafts serve as the primary working documents within the (IETF) for developing and iterating technical specifications prior to their potential publication as (RFCs). These drafts enable authors and working groups to propose ideas, solicit feedback, and refine protocols through collaborative discussion, ensuring that concepts evolve based on community input without conferring any formal status on the document itself. Authors create and submit Internet-Drafts to the IETF Datatracker at datatracker.ietf.org, where the documents are automatically versioned to track revisions, beginning with a such as -00 (e.g., draft-ietf-wg-name-00 for a draft). Submissions must adhere to specific formatting guidelines, including the use of RFCXML as the authoritative format, and are validated for before posting to the public repository. Every Internet-Draft is required to include a mandatory IETF note stating that it represents the authors' opinions only, is a work in progress valid for a maximum of six months, and carries no binding or archival status, thereby emphasizing its transient and non-official nature. The lifecycle of an Internet-Draft is inherently temporary and iterative, designed to facilitate active development rather than permanence. Once posted, a draft remains active in the IETF repository for up to 185 days (approximately six months) unless it is updated with a new version, replaced, advanced toward publication, or explicitly withdrawn; upon expiration, it is automatically removed from circulation to prevent outdated from persisting. This expiration ensures that drafts are regularly refreshed to reflect ongoing , while limiting their distribution to the IETF community and preventing citation in formal contexts. Only those drafts adopted by a and successfully progressing through review stages may advance to status, with the majority lapsing without further action. Annually, IETF participants submit thousands of Internet-Drafts to support diverse standardization efforts across working groups. Of these, approximately 20% ultimately advance to become , highlighting the selective nature of the process where rigorous community scrutiny determines viability.

Publication and Accessibility

The RFC Editor serves as the primary organization responsible for publishing and maintaining the RFC series, operating independently from the IETF's administrative functions since 2012, when significant structural changes, including the establishment of the RFC Series Working Group, enhanced its autonomy under the IETF Trust. Since then, the RFC Editor has handled the editing, production, and dissemination of documents from various streams, ensuring consistency and adherence to series policies. RFCs are published in multiple formats to facilitate broad access, including (ASCII/TXT) as the canonical version, along with , PDF, and XML derivatives. The official repository for RFCs is hosted at the RFC Editor's website (rfc-editor.org/rfc), where all documents are archived and freely available without restrictions. This central hub includes an RFC Index that lists all publications with such as titles, authors, publication dates, statuses, and streams, enabling easy navigation. Mirror sites, such as those maintained by independent organizations like faqs.org and muonics.com, replicate the full collection to improve global availability and redundancy, updated periodically to reflect new publications. Search tools on the RFC Editor site allow users to query by number, title, keyword, status, or other criteria, supporting efficient retrieval across the over 9,000 RFCs. To enhance accessibility, the RFC Editor supports community-driven translations of select RFCs into languages such as and , available through dedicated platforms like rfc2cn.com, though these are not official versions and users are advised to reference the English originals for accuracy. While no official audio versions of RFCs exist, the and PDF formats incorporate web standards for compatibility, promoting inclusivity for users with visual impairments in line with broader IETF goals. RFCs are maintained as permanent archival records, never deleted but potentially obsoleted or updated through designated fields in subsequent documents, as outlined in the RFC Style Guide (RFC 7322). For citability, all RFCs have been assigned Digital Object Identifiers (DOIs) since the mid-2010s, following the policy in RFC 7669, which structures DOIs as 10.17487/RFCnnnn for stable referencing in academic and technical contexts. This ensures long-term preservation and discoverability, with errata and status changes tracked separately to maintain document integrity without altering originals.

Types and Categories

Technical Protocol Standards

Technical Protocol Standards are specifications developed by the (IETF) that define core protocols essential for the operation and of the Internet, advancing through defined stages from Proposed Standard to full Internet Standard status. These standards provide precise, implementable rules for data transmission, , and , ensuring that diverse network devices and software can communicate reliably across global infrastructures. A defining characteristic of technical protocol standards is their alignment with a layered protocol model, akin to the OSI reference model, which organizes functionality into levels such as physical, data link, network, transport, and application layers to promote modularity and interoperability. This structure mandates consistent behavior at each layer, making compliance essential for end-to-end connectivity; for instance, protocols at the network layer handle addressing and routing, while transport layer protocols manage reliable delivery. As of 2025, approximately 101 such full standards exist, each rigorously tested for stability and widespread adoption before ratification. Prominent examples illustrate their scope across network functions. The (IPv4), specified in RFC 791 (STD 5), defines the foundational packet format and addressing scheme for routing data across networks. In the , the (TCP), originally in RFC 793 and updated in RFC 9293 (STD 7), ensures reliable, ordered delivery of data streams. Routing protocols like Border Gateway Protocol version 4 (BGP) in RFC 4271 (Draft Standard) facilitate scalable path selection among autonomous systems. For security, Transport Layer Security version 1.3 (TLS 1.3) in RFC 8446 (Proposed Standard) provides encrypted communication channels to protect data integrity and confidentiality. Similarly, the Hypertext Transfer Protocol version 1.1 (HTTP/1.1) in RFC 7230 (Proposed Standard) standardizes web data exchange at the . These standards collectively enable seamless end-to-end connectivity by standardizing interactions that underpin the Internet's decentralized , allowing billions of devices to interoperate without barriers and supporting the global exchange of information. Their mandatory nature for core operations ensures robustness, with ongoing updates addressing evolving threats and efficiencies while maintaining where possible.

Experimental and Informational RFCs

In addition to standards-track RFCs, the IETF publishes non-standards-track documents to facilitate , provide guidance, and historical material without implying requirements or for adoption as protocols. These include Experimental, Informational, and Historic categories, each serving distinct roles in the evolution of Internet technologies. Experimental RFCs document specifications intended for trial and evaluation in controlled environments, often stemming from efforts by IRTF groups, IETF working groups, or individuals. They are published to inform the and preserve records but are not meant for widespread production deployment due to limited review and potential instability. For instance, RFC 7974 proposes an experimental option for host identification to enable detection, emphasizing privacy considerations during testing. These documents typically carry a two-year validity period, after which the IESG may reclassify them as Historic if they fail to advance or gain traction, preventing indefinite experimental status. Informational RFCs offer general guidance, external specifications, or non-IETF perspectives without any intent to standardize protocols or reflect IETF consensus. They support education, best practices, or historical context, drawing from diverse sources like vendors or other organizations. An example is RFC 1087, which outlines ethical principles for resource use, stressing responsible access and respect for system integrity as articulated by the Internet Activities Board. Unlike standards-track documents, these do not undergo rigorous interoperability validation and serve primarily archival or advisory purposes. Historic RFCs designate specifications that are obsolete, superseded, or no longer recommended for use, signaling their retirement from active consideration. The IESG moves documents to this status through formal action when newer standards replace them or when continued relevance wanes. For example, certain IPv4 options detailed in 1812, such as those for and record route, have been deprecated in favor of modern alternatives, rendering them historic via subsequent updates like RFC 6814. This category ensures clarity by archiving outdated material without confusing it for current practice. Collectively, Experimental, Informational, and Historic RFCs constitute approximately 40% of the RFC series, with over 2,979 Informational, 551 Experimental, and 351 Historic documents as of November 2025. This substantial portion underscores their role in fostering innovation, documenting , and avoiding premature commitment to unproven standards, thereby complementing the more rigorous standards-track process.

Examples in Web and Network Domains

In the web domain, HTML5 serves as a foundational standard for structuring and presenting content on the World Wide Web, developed through collaboration between the Web Hypertext Application Technology Working Group (WHATWG) and the World Wide Web Consortium (W3C), with IETF support for related media types such as text/html defined in RFC 2854 (Proposed Standard). This standard enables semantic markup, multimedia integration, and interactive features without plugins, powering the majority of modern web applications. Uniform Resource Identifiers (URIs), specified in RFC 3986 (STD 66), provide a standardized syntax for identifying resources on the Internet, facilitating consistent referencing in hyperlinks, APIs, and data exchange across web services. HTTPS enforcement, particularly through HTTP Strict Transport Security (HSTS) outlined in RFC 6797 (Proposed Standard), mandates secure connections for web traffic, preventing downgrade attacks and ensuring encrypted communication between browsers and servers. In network domains, the (DNS) enables the translation of human-readable domain names to IP addresses, as detailed in RFC 1035 (STD 13), which defines the core protocol for queries, responses, and resource records essential for Internet navigation. Simple Mail Transfer Protocol (SMTP), updated in RFC 5321 (STD 10), governs the transmission of electronic mail across networks, specifying message envelope formats, relay rules, and error handling to ensure reliable delivery in distributed email systems. Simple Network Management Protocol (SNMP), architected in RFC 3411 (STD 62), facilitates the monitoring and management of network devices by defining a framework for agents, managers, and management information bases (MIBs), allowing administrators to configure and troubleshoot infrastructure remotely. Cross-domain examples highlight the integration of and standards, such as the transition to version 6 () specified in RFC 8200 (STD 86), which expands the address space to accommodate growing Internet-connected devices and replaces the depleting IPv4 pool through mechanisms like dual-stack operation and tunneling. As of November 2025, global adoption has reached approximately 45%, reflecting steady progress in deployment by major providers and regions, though challenges in full transition persist. A notable is , defined in 9113 (Proposed Standard; obsoletes RFC 7540), which enhances over HTTP/1.1 by introducing binary framing, header compression, server push, and on a single connection, reducing latency and improving resource utilization for faster page loads in bandwidth-constrained environments.

Intellectual Property Considerations

IETF IPR Policies

The IETF Intellectual Property Rights (IPR) policies establish a framework to promote transparency and openness in the development of Internet standards by requiring disclosures of relevant patents and encouraging reasonable licensing terms. These policies are primarily outlined in 3979, published in 2005, which was updated and obsoleted by 8179 in 2017 to clarify definitions, incorporate rules for oral contributions, and make licensing declarations irrevocable. The objectives include ensuring early awareness of potential IPR constraints to allow working groups to evaluate technologies effectively while respecting the rights of IPR holders. A key element is the "Note Well" statement, which serves as a reminder displayed at IETF meetings, on mailing lists, and in related documents, binding all participants upon involvement in IETF activities. It requires that if a participant is aware of any s or patent applications owned or controlled by themselves, their employer, or sponsor that cover an IETF contribution—defined broadly to include documents, presentations, and discussions—they must disclose this fact or refrain from participating in the relevant discussion. This obligation applies to all contributions, including those submitted as Internet-Drafts, to foster an environment of informed decision-making. Disclosures encompass several types to address potential IPR issues comprehensively. Participants must reveal their own known IPR related to their contributions, as well as any IPR they become aware of covering others' contributions within the IETF's scope. Third-party IPR claims are encouraged on a voluntary basis to provide additional context, while disclosures specifically target essential patents—those that would be necessary to implement the described in an IETF document. Importantly, these policies provide no or of freedom-to-operate, leaving implementation risks to adopters. The policies encourage, but do not mandate, licensing on reasonable and non-discriminatory (RAND) terms, which may include royalty-free options, to support widespread adoption of standards. Enforcement is overseen by working group (WG) chairs, who monitor disclosures, gather facts on potential violations, and may initiate sanctions ranging from warnings to temporary bans on participation, in consultation with area directors. Appeals against such sanctions follow the IETF's general appeals process, ultimately reviewable by the Internet Architecture Board (IAB).

Licensing and Disclosure Requirements

Participants in the IETF process are required to disclose any rights (IPR), such as , that they reasonably believe may cover contributions to IETF documents or technologies. Disclosures must be made as soon as practicable after becoming aware of the IPR, using the official online submission mechanism provided by the IETF at https://www.ietf.org/ipr-instructions.[](https://datatracker.ietf.org/doc/html/rfc8179#section-5.3) Alternatively, disclosures can be included directly in Internet-Drafts via a or sent via to the relevant or the IPR disclosure list. Each disclosure must specify the relevant IETF document(s), details (including numbers, inventors, and jurisdictions), and any licensing terms; blanket disclosures are permitted only if they include a licensing commitment for all potentially essential . Licensing commitments associated with disclosed IPR are voluntary but strongly encouraged to facilitate adoption of IETF standards. The IETF provides three primary options for such commitments: Option A offers a license under reasonable and non-discriminatory () terms; Option B provides a license that may include royalties or other payments; and Option C involves a defensive commitment, such as a not to sue under the for implementing the . The IETF prefers licensing (Option A) to promote widespread, unencumbered of standards, as it aligns with the organization's goal of open interoperability. Once made, these commitments are irrevocable and binding on successors. Regarding copyright, contributors to IETF documents grant the IETF Trust perpetual, irrevocable, non-exclusive, rights to copy, publish, distribute, and create works of their contributions. The IETF Trust holds the copyright for published s, ensuring they are available under a BSD-like that permits free use, modification, and distribution with minimal restrictions, such as attribution. This licensing model, formalized in RFC 5378, allows contributors to retain ownership of their original works while enabling broad dissemination and reuse within the IETF standards ecosystem. Despite these mechanisms, challenges persist in IPR management, particularly around patent ambiguity, where determining whether a is essential to a standard can be complex and subjective, leading to incomplete or overly broad disclosures. For instance, in the early 2000s, disputes over patents (related to standards, which interface with IETF protocols) highlighted risks of hold-up, as patent holders like the pursued litigation and settlements totaling hundreds of millions against implementers, underscoring the need for clearer disclosure and licensing in interconnected standards environments.

Current Challenges and Future Outlook

Emerging Technologies and Adaptations

The protocol, standardized as 9000 in May 2021, represents a significant adaptation of Internet Standards to enhance performance in modern web applications. provides a UDP-based, multiplexed, and secure that reduces latency and improves reliability over traditional , particularly for lossy networks. It underpins , defined in 9114, enabling faster page loads and better handling of concurrent streams without . Internet Standards are also evolving to support and emerging networks through IETF efforts focused on integration and optimization. For instance, working groups are developing protocols for agents in systems, as outlined in drafts like draft-stephan-ai-agent-6g, which extrapolate requirements from specifications to ensure seamless between cellular and IP-based networks. These adaptations aim to facilitate low-latency, high-reliability communications essential for applications like autonomous systems and . In emerging areas, have been incorporated into standards, such as 6973, which provides guidelines for protocol designers to mitigate tracking risks through mechanisms like ephemeral keys and identifiers. This emphasizes the use of temporary, non-reusable values to obscure user correlations across sessions, influencing subsequent protocols in and web contexts. Additionally, IETF explorations into and IPFS interoperability, including discussions in interim meetings and drafts like draft-hardjono-blockchain-interop-arch, seek to enable secure, decentralized data exchange while maintaining compatibility with core protocols. IETF working groups are actively addressing transport needs, with the Preferences (AIPREF) group chartered in 2025 to standardize how models interact with Internet content, and the proposed Network Research Group (NMLRG) investigating applications in network operations. Drafts on -related traffic, such as draft-aft-ai-traffic, further explore handling inter-data-center flows for workloads. To extend global reach, standards like RFC 8376 for Low-Power Wide Area Networks (LPWAN) optimize protocols for low-bandwidth regions, supporting deployments in underserved areas and aligning with UN for inclusive infrastructure (SDG 9). These efforts prioritize energy-efficient, accessible connectivity in resource-constrained environments.

Ongoing Issues in Standardization

One persistent challenge in Internet standardization is scalability, as the explosive growth of the has strained existing protocols, particularly evident in the exhaustion of IPv4 addresses that began in , prompting ongoing efforts to maintain and transition protocols like IPv4 alongside adoption. This issue is compounded by the IETF's consensus-driven process, which, while ensuring broad agreement, often introduces ; for instance, advancing a specification from Proposed to Draft requires at least six months of community review and testing, and significant revisions can reset the timeline, slowing responses to rapid network expansion. Such have been noted in analyses of IETF operations, where lengthy technical debates contribute to a perceived slowdown in standards development compared to earlier decades. Inclusivity remains a critical barrier, with underrepresentation of participants from the Global South limiting diverse perspectives in standard-setting; and experts from regions like and face geographic and financial hurdles, as IETF meetings are rarely held in those areas, exacerbating exclusion from in-person deliberations. Language barriers further hinder contributions, as IETF work occurs almost exclusively in English, involving fast-paced, jargon-laden discussions that disadvantage non-native speakers and those from non-English-dominant regions. Recent IETF drafts emphasize the need for equitable participation to address these gaps, affirming that governance must be accessible and safe for all, yet implementation challenges persist. Security standardization faces ongoing difficulties in retroactively addressing vulnerabilities, such as those exposed by the and Meltdown hardware flaws discovered in , which necessitated updates to threat models in IETF best current practices like RFC 3552 to incorporate side-channel risks into protocol designs. This retrofitting highlights the tension between rapid innovation and rigorous security; the IETF's emphasis on thorough review and consensus ensures robust standards but can delay deployment, as seen in the extended timelines for updating protocols like TLS to mitigate emerging threats while maintaining . Balancing these elements requires continuous evolution of security considerations, yet the process often prioritizes long-term stability over immediate fixes. External pressures from geopolitical tensions increasingly affect standards adoption, particularly the US-China tech divide, which by has intensified scrutiny of Chinese proposals in forums like the IETF, leading to fragmented risks; for example, Huawei's New IP initiative was rejected in amid concerns over and , reflecting broader rivalries that challenge . This rivalry, driven by competing visions for digital governance, has resulted in US dominance in IETF chairs (56%) contrasting with China's rising document authorship, potentially slowing adoption of standards perceived as aligned with one side's interests. Such dynamics underscore the need for neutral processes, though they continue to influence participation and outcomes.

References

  1. [1]
    IETF "RFC 2026: The Internet Standards Process
    It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process.
  2. [2]
    Introduction to the IETF
    The Internet Engineering Task Force (IETF), founded in 1986, is the premier standards development organization (SDO) for the Internet.
  3. [3]
    Internet standards process - IETF
    The basic formal definition of the IETF standards process is RFC 2026 (BCP 9). ... In outline, the process of creating an Internet Standard is ...Guide to IETF Working Groups · Informal guide to IETF process · BCP 79 · Process
  4. [4]
    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.
  5. [5]
    RFC 790 - Assigned numbers - IETF Datatracker
    This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations.
  6. [6]
    Policy Brief: Open Internet Standards
    Oct 29, 2025 · Open standards let people and organizations set up new services and make them available across the rest of the Internet without permission.
  7. [7]
    RFC 7282: On Consensus and Humming in the IETF
    We believe in: rough consensus and running code. That is, our credo is that we don't let a single individual dictate decisions (a king or president), nor ...
  8. [8]
    RFC-Editor.org
    The RFC Series contains technical and organizational documents about the Internet, including specifications and policy documents.Document Retrieval · Rfc index · RFC Search Detail · RFC SearchMissing: repositories mirror
  9. [9]
    Official Internet Protocol Standards - » RFC Editor
    Official Internet Protocol Standards. This page contains the current lists of Draft Standards. Note: This maturity level was retired by RFC 6410.
  10. [10]
    ARPANET | DARPA
    Evolution of ARPANET. The foundation of the current internet started taking shape in 1969 with the activation of the four-node network, known as ARPANET, and ...Need And Opportunity · Programs · Darpa Solution
  11. [11]
    ARPANET launches the world's first packet-switched wide area ...
    At 10:30 pm on October 29th 1969, two computers connected and launched the worlds first packetswitched wide area computer network: the ARPANET.
  12. [12]
    A Brief History of the Internet - Internet Society
    In late 1966 Roberts went to DARPA to develop the computer network concept and quickly put together his plan for the “ARPANET”, publishing it in 1967. At the ...
  13. [13]
    RFC 801 - NCP/TCP transition plan - IETF Datatracker
    This RFC is not endorsed by the IETF and has no formal standing in the IETF standards process.
  14. [14]
    RFC 1011 - Official Internet protocols - IETF Datatracker
    This RFC identifies the documents specifying the official protocols used in the Internet. Comments indicate any revisions or changes planned.
  15. [15]
    A Brief History of the Internet Advisory / Activities / Architecture ... - IAB
    The IAB originated from the ICCB in 1979, became the IAB in 1984, then the Internet Activities Board in 1986, and later the Internet Architecture Board.
  16. [16]
    IETF and the Internet Society
    Jul 18, 1995 · Starting in 1993, the Internet Society assumed its responsibilities under RFC 1602, and participated in various reviews of that process. The ...
  17. [17]
    Groups
    ### Summary of IETF Organizational Structure
  18. [18]
    Internet Engineering Steering Group
    ### Summary of IESG Role, Composition, and Veto Powers
  19. [19]
    Mailing lists - IETF
    This page describes many of the IETF mailing lists, where most of the daily work of the IETF is conducted.Missing: consensus | Show results with:consensus
  20. [20]
    Internet Engineering Task Force - IETF - Facebook
    Jul 21, 2025 · More than 1500 participants around the world—in Madrid and online—are working on emerging Internet technologies through 25 July 2025. Thanks to ...
  21. [21]
    NomCom 2025 - Home - IETF Datatracker
    Chair: Benno Overeinder · Past chair: Dean Bogdanovic · IAB Liaison: Alvaro Retana · IESG Liaison: Mike Bishop · ISOC Board Liaison: Russ Housley · IETF LLC Board ...Missing: appointments leadership
  22. [22]
    https://www.internetsociety.org/who-we-are/mission/
  23. [23]
    Internet Architecture Board - IETF
    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 ...
  24. [24]
    About us
    ### Summary of W3C's Role in Web Standards and Relation to Internet Standardization/IETF
  25. [25]
    About us
    ### Summary of IANA's Role in Protocol Parameter Assignment
  26. [26]
    Service Name and Transport Protocol Port Number Registry
    User Ports are assigned by IANA using the "IETF Review" process, the "IESG Approval" process, or the "Expert Review" process, as per [RFC6335]. Dynamic ...Missing: parameter | Show results with:parameter
  27. [27]
    Bringing new work to the IETF
    If you want to bring an idea to the IETF then you should to write it up as an Internet-Draft ([I-D])(https://www.ietf.org/participate/ids/) and submit it to the ...
  28. [28]
    RFC 7221: Handling of Internet-Drafts by IETF Working Groups
    This document discusses how a working group typically handles the formal documents that it targets for publication.
  29. [29]
    The Internet Standards Process
    ### Summary of Initial Stages of Standardization Process (draft-ietf-procon-2026bis)
  30. [30]
    RFC 6410 - Reducing the Standards Track to Two Maturity Levels
    This document updates the Internet Engineering Task Force (IETF) Standards Process defined in RFC 2026. Primarily, it reduces the Standards Process from three ...
  31. [31]
    IPv6 is an Internet Standard - IETF
    The Internet Standard designation represents the highest level of technical maturity and usefulness in the IETF standardization process.
  32. [32]
    https://www.ietf.org/blog/ipv6-internet-standard/
  33. [33]
    Last Call Details - IETF Community Wiki
    To request a Last Call,. Pull up the document in the Tracker; Click "Prepare for Last Call"; Make sure the version number in the Last Call Announcement Text ...Missing: process | Show results with:process
  34. [34]
    DISCUSS Criteria in IESG Review - IETF Datatracker
    May 7, 2014 · This document describes the role of the 'DISCUSS' position in the IESG review process. It gives some guidance on when a DISCUSS should and should not be issued.
  35. [35]
    https://datatracker.ietf.org/doc/statement-iesg-discuss-criteria-in-iesg-review-20140507/
  36. [36]
    https://datatracker.ietf.org/doc/html/rfc2026#section-6.1.3
  37. [37]
    https://datatracker.ietf.org/doc/html/rfc2026#section-4.1.3
  38. [38]
    https://datatracker.ietf.org/doc/html/rfc2026#section-6.2
  39. [39]
    Protocol registries (IANA) - IETF
    Corrections and errata · Reporting ... IANA allocates and maintains unique codes and numbering systems (parameters) used in the IETF technical standards.Missing: maintenance | Show results with:maintenance
  40. [40]
    https://www.ietf.org/process/iana/
  41. [41]
    RFC 1: Host Software
    Network Working Group Steve Crocker Request for Comments: 1 UCLA 7 April 1969 Title: Host Software Author: Steve Crocker Installation: UCLA Date: 7 April ...
  42. [42]
    46 Years of RFCs (Celebrating The Anniversary of RFC 1)
    Apr 7, 2015 · It was 46 years ago today, on April 7, 1969, when the very first “Request for Comments” or “RFC” was issued by Steve Crocker.
  43. [43]
    Number of RFCs Published per Year - » RFC Editor
    Number of RFCs Published per Year ; 2010, 363, 2011, 390, 2012 ; 2015, 300, 2016, 310, 2017 ; 2020, 209, 2021, 240, 2022 ...Missing: November 2025
  44. [44]
    IETF document statistics (all RFCs) - Jari Arkko
    Aug 11, 2024 · Total number of RFCs is 9164. The distribution of RFC and according to number of authors here, RFC page count distribution looks like this.Missing: November 2025
  45. [45]
    RFC Style Guide - IETF
    Apr 7, 2021 · This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series.Table of Contents · Introduction · RFC Style Conventions · Structure of an RFC
  46. [46]
    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.
  47. [47]
    About RFCs - IETF
    RFC documents contain technical specifications and organizational notes for the Internet and are the core output of the IETF.
  48. [48]
    A brief history of the RFC format - APNIC Blog
    Aug 26, 2021 · This textual format has deep roots in RFCs. It goes all the way back to RFC 825 in 1982, which was authored by Jon Postel, who was basically the original ...
  49. [49]
    RFCXML overview and background - Internet-Draft Author Resources
    RFCXML is an XML language, used as the preferred format for Internet-Drafts and the canonical format for published RFCs since RFC 8650 in November 2019.
  50. [50]
    Internet-Drafts - IETF
    Submitting an I-D via the IETF Datatracker submission tool places it in the IETF's Internet-Drafts directory. This makes the I-D readily available to a wide ...
  51. [51]
    Submitting your Internet-Draft
    ### Summary of Internet-Draft Submission Process
  52. [52]
    RFC 4228 - Requirements for an IETF Draft Submission Toolset
    1. All available meta-data entries must match across all submitted draft formats (R18/a). · 2. Version 00 of a Working Group draft has a corresponding Working ...Missing: lifecycle | Show results with:lifecycle
  53. [53]
    [PDF] Making an RFC in Today's IETF - APNIC Labs
    Mar 19, 2024 · What's the “success rate” for Internet drafts? Around 20%, or 1 in 5. Page 16. See also. RFC8963 - Evaluation of a Sample of RFCs Produced in ...
  54. [54]
    RFC Editor News Archive
    2012 was a intense year of progress and change for the RFC Editor. With a new RFC Series Editor, a revival of the RFC Format discussion, several changes to the ...
  55. [55]
    RFC 9280: RFC Editor Model (Version 3)
    ### RFC Editor Independence and Role Summary
  56. [56]
    RFC INDEX
    The RFC index includes the RFC number, title, author list, publication date, format, obsoletes, obsoleted-by, updates, updated-by, status, stream, and DOI.
  57. [57]
    RFC Mirror | Muonics, Inc.
    Browse by area and working group, jump directly a specified RFC number, or use the full site search above. This mirror is updated monthly.
  58. [58]
    RFC Search - » RFC Editor
    Publication Date: Any, Range (inclusive), This Month, This Year. From. Month, January, February, March, April, May, June, July, August, September, October ...
  59. [59]
    Open records - IETF
    RFC Editor website. This provides access to all RFCs in a variety of formats through a number of mechanisms. Direct access to documents, records and raw ...Missing: mirror | Show results with:mirror
  60. [60]
    RFC 7322 - RFC Style Guide - IETF Datatracker
    This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series.
  61. [61]
    RFC Status Changes - » RFC Editor
    This page lists the RFCs whose statuses have changed since publication. The process for how documents' statuses are updated has changed over time.
  62. [62]
    How Standard Setters Run the Internet - Internet Society
    Jul 15, 2025 · Internet standards are voluntary rules that people (networks, Internet users, etc.) agree to use to make the Internet operate efficiently.
  63. [63]
    RFC 7974: An Experimental TCP Option for Host Identification
    This memo describes the design, deployment, and privacy considerations for one such solution in operational use on the Internet today that uses a TCP option to ...
  64. [64]
    RFC 1087: Ethics and the Internet
    This memo is a statement of policy by the Internet Activities Board (IAB) concerning the proper use of the resources of the Internet.Missing: informational | Show results with:informational
  65. [65]
    RFC 6814: Formally Deprecating Some IPv4 Options
    This document deprecates such IPv4 options, thus cleaning up the corresponding IANA registry. Additionally, it obsoletes RFCs 1385, 1393, 1475, and 1770.
  66. [66]
    RFC 3979 - Intellectual Property Rights in IETF Technology
    This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are ...
  67. [67]
    RFC 8179: Intellectual Property Rights in IETF Technology
    This document sets out the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are ...
  68. [68]
    Note Well - A reminder of IETF policies
    By participating in the IETF you agree to follow IETF processes and policies. This Note Well is a reminder of some of those policies.Missing: 3979 | Show results with:3979
  69. [69]
    RFC 6701: Sanctions Available for Application to Violators of IETF ...
    It is important to note that each individual IETF participant has a choice under the IETF's IPR policy. ... Additionally, the Note Well statement is accepted by ...
  70. [70]
    RFC 8179: Intellectual Property Rights in IETF Technology
    ### Summary of RFC 8179: Intellectual Property Rights in IETF Technology
  71. [71]
    https://datatracker.ietf.org/doc/html/rfc1035
  72. [72]
    RFC 3905 - A Template for IETF Patent Disclosures and Licensing ...
    This document describes a proposal for one form of a template for IETF patent disclosures and licensing declarations.
  73. [73]
    https://datatracker.ietf.org/doc/html/rfc3411
  74. [74]
    https://datatracker.ietf.org/doc/html/rfc8200
  75. [75]
    https://www.google.com/intl/en/ipv6/
  76. [76]
    https://datatracker.ietf.org/doc/html/rfc9113
  77. [77]
    https://datatracker.ietf.org/doc/html/rfc3979
  78. [78]
    https://www.rfc-editor.org/rfc/rfc8179.html
  79. [79]
    https://www.ietf.org/about/note-well/
  80. [80]
    https://www.rfc-editor.org/rfc/rfc6701.html
  81. [81]
    (PDF) Patent challenges for standard-setting in the global economy
    The IETF's standards development work is organized. into eight areas ... essential patent claims, ambiguity over differences between patent declarations.
  82. [82]
    How the Aussie government “invented WiFi” and sued its way to ...
    Apr 4, 2012 · CSIRO has now scored a $229 million settlement from a group of nine companies that make a variety of wireless devices and chips.
  83. [83]
    IETF March 2000 Proceedings
    Bob Fink related the background and current status of the BT patent issue. 1. BT notified the IETF Secretariat on Nov 5, 1999 that: "In accordance with the IETF ...
  84. [84]
    RFC 9000 - QUIC: A UDP-Based Multiplexed and Secure Transport
    QUIC is a secure general-purpose transport protocol. · QUIC is a connection-oriented protocol that creates a stateful interaction between a client and server.
  85. [85]
    draft-stephan-ai-agent-6g-02 - AI Agent protocols for 6G systems
    This document provides examples of use cases and service requirements contained in the 3GPP TR 22.870 and extrapolates possible requirements related to agent ...
  86. [86]
    draft-sarischo-6gip-aiagent-requirements-00 - AI Agents for 6G ...
    Sep 11, 2025 · ... AI/ML Agents requirements September 2025 2.1. AI Agents collaboration with third-party AI using LLM A third-party application (e.g. a smart ...
  87. [87]
    RFC 6973 - Privacy Considerations for Internet Protocols
    This document offers guidance for developing privacy considerations for inclusion in protocol specifications.
  88. [88]
    [PDF] How IPFS Works - IETF Datatracker
    IPFS is a decentralized storage network using P2P networking, content-based addressing, libp2p, IPLD, and Multiformats for content-addressed storage.
  89. [89]
    draft-hardjono-blockchain-interop-arch-03 - IETF Datatracker
    Nov 6, 2021 · This document proposes an interoperability architecture based on DLT Gateways, which are points of interconnection between networks.Missing: IPFS | Show results with:IPFS
  90. [90]
    Proposed Network Machine Learning Research Group (nmlrg)
    Charter for Research Group. Proposed Network Machine Learning Research Group. Machine learning technologies can learn from historical data, and make
  91. [91]
    RFC 8376 - Low-Power Wide Area Network (LPWAN) Overview
    The FAN profile is based on various open standards developed by the IETF (including [RFC768], [RFC2460], [RFC4443], and [RFC6282]). Related IEEE 802 standards ...
  92. [92]
    RFC 2026: The Internet Standards Process -- Revision 3
    ### Summary of RFC 2026 Sections
  93. [93]
    Delay and de jure standardization - Internet - ResearchGate
    ... Most notably, the speed of standardization at IETF has flagged, and the organization has become notorious for lengthy technical debates and delays. 80 As ...
  94. [94]
    [PDF] Internet Engineering Task Force (IETF) for Public Interest Advocates
    Global South civil society and other underrepresented groups are further disadvantaged for the following reasons: • Geographic: In-person meetings are never.
  95. [95]
    Toward Inclusive and Equitable Participation in Internet Governance
    Apr 8, 2025 · This document affirms that the governance and activities of the IETF must be inclusive, accessible, and safe for all individuals, ...
  96. [96]
    Security & privacy - IETF
    Technical standards and Best Current Practice documents developed in the IETF provide important foundational elements for security and privacy on the Internet.
  97. [97]
    https://datatracker.ietf.org/meeting/interim-2020-dinrg-01/materials/slides-interim-2020-dinrg-01-sessa-an-overview-of-the-interplanetary-file-system-ipfs.pdf
  98. [98]
    [PDF] Report |The Geopolitics of Global Technology Standards: Key Issues ...
    Nov 2, 2022 · The current geopolitical tensions around technology standards are mostly driven by the US-China rivalry and the. West's emphasis on ...