Community hub
0 subscribers7 pages, 0 posts
Recent from talks
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Internet Draft.
Nothing was collected or created yet.
Internet Draft
View on Wikipediafrom Wikipedia
An Internet Draft (I-D) is a document published by the Internet Engineering Task Force (IETF) containing preliminary technical specifications, results of networking-related research, or other technical information. Often, Internet Drafts are intended to be work-in-progress documents for work that is eventually to be published as a Request for Comments (RFC) and potentially leading to an Internet Standard.
It is considered inappropriate to rely on Internet Drafts for reference purposes. I-D citations should indicate the I-D is a work in progress.[1]
An Internet Draft is expected to adhere to the basic requirements imposed on any RFC.[2]
An Internet Draft is only valid for six months unless it is replaced by an updated version. An otherwise expired draft remains valid while it is under official review by the Internet Engineering Steering Group (IESG) when a request to publish it as an RFC has been submitted. Expired drafts are replaced with a "tombstone" version and remain available for reference.[2]
Naming conventions
[edit]Internet Drafts produced by the IETF working groups follow the naming convention: draft-ietf-<wg>-<name>-<version number>.txt.
Internet Drafts produced by IRTF research groups following the naming convention: draft-irtf-<rg>-<name>-<version number>.txt.
Drafts produced by individuals following the naming convention: draft-<individual>-<name>-<version number>.txt
The IAB, RFC Editor, and other organizations associated with the IETF may also produce Internet Drafts. They follow the naming convention: draft-<org>-<name>-<version number>.txt.
The initial version number is represented as 00. The second version, i.e. the first revision is represented as 01, and incremented for all following revisions.
References
[edit]- ^ "Internet Standards and the Request For Comment (RFC) Process", The TCP/IP Guide, p. 3, retrieved 2015-11-10
- ^ a b R. Housley (2010-12-07). Guidelines to Authors of Internet-Drafts. Retrieved 2018-03-18.
External links
[edit]Internet Draft
View on Grokipediafrom Grokipedia
An Internet Draft (I-D), also known as an Internet-Draft, is a working document produced by the Internet Engineering Task Force (IETF), its Areas, and its Working Groups to facilitate the development, discussion, and informal review of technical specifications for Internet protocols and related technologies.[1] These drafts serve as the primary mechanism for structured communication within the IETF and are the foundational inputs that may eventually evolve into published Requests for Comments (RFCs) if adopted and approved through the IETF's consensus-driven process.[2]
Internet-Drafts have no formal status and are explicitly subject to change, replacement, or removal at any time, emphasizing their role as preliminary and evolving documents rather than final publications.[1] They must not be cited or quoted as references to established standards, as they represent the individual opinions of their authors and do not carry the authority of an official IETF endorsement.[1] Authorship is open to anyone, including individuals or groups outside the IETF, though submissions are typically tied to working group activities or individual proposals.[2]
The lifecycle of an Internet-Draft begins with submission via the IETF Datatracker tool, where it is assigned a unique name in the format
draft-{source}-{group}-{title}-{version} and posted publicly for review.[2] Drafts are required to include standard sections such as an Abstract, Introduction, Security Considerations, and References, formatted using the XML vocabulary described in RFC 7991 to ensure consistency and readability.[3] Unless placed in a non-expiring state (e.g., during IESG review), Internet-Drafts automatically expire 185 days after posting to encourage timely updates and prevent outdated information from lingering in the repository.[2] If a draft progresses successfully—through working group adoption, multiple revisions, and IETF-wide review—it can be advanced to RFC status, becoming part of the official Internet standards track; otherwise, it remains an informal working document.[1]
Overview
Definition
An Internet Draft is a working document of the Internet Engineering Task Force (IETF), submitted for discussion, review, and potential advancement toward standardization within the IETF's standards development process.[4] These documents represent draft versions of technical specifications for Internet protocols, architectures, or procedures, placed in the IETF's public Internet-Drafts directory to facilitate informal community feedback and iteration.[4] Unlike Requests for Comments (RFCs), which serve as the formal publications of IETF standards or informational resources, an Internet Draft does not constitute an official standard and carries no binding authority until it progresses to RFC status through the IETF's review and approval mechanisms.[4] Key characteristics of Internet Drafts emphasize their provisional nature: they are explicitly non-authoritative, subject to revision, replacement, or removal at any time, and are not intended as a mechanism for publishing specifications.[4] To maintain relevance and encourage active development, Internet Drafts automatically expire after six months if not updated or recommended for RFC publication by the Internet Engineering Steering Group (IESG).[4] Additionally, they are designed for open access, freely available to the public without copyright restrictions on copying, distribution, or creation of derivative works, as contributors grant the IETF Trust broad, irrevocable rights to promote collaborative use in the standards process.[5] This structure ensures Internet Drafts function solely as tools for ongoing discourse rather than final or citable references.[4]Purpose in IETF Standards Development
Internet-Drafts serve as the primary mechanism for proposing new protocols, extensions to existing standards, or clarifications to technical specifications within the IETF's standards development process. These working documents allow authors to outline innovative ideas or refinements that address emerging needs in internet technologies, enabling the community to evaluate and iterate on them before any formal standardization.[6] By providing a structured yet flexible format for initial proposals, Internet-Drafts ensure that technical contributions are documented and shared early, preventing redundant efforts and promoting focused development.[1] A core objective of Internet-Drafts is to facilitate community review and iterative improvement, which is essential for refining proposals into robust standards. Once submitted, drafts are made publicly available in the IETF's Internet-Drafts repository, where they undergo informal scrutiny by working groups, area directors, and the wider internet engineering community. This process encourages feedback loops that enhance clarity, interoperability, and security, with revisions incorporated based on collective input until the document matures sufficiently for potential advancement.[6] Unlike final standards, these drafts hold no formal status and can evolve or expire after six months of inactivity, underscoring their role in agile, pre-adoption experimentation.[1] Internet-Drafts play a vital role in fostering open collaboration by democratizing access to draft proposals, allowing diverse contributors—from individual experts to organizational teams—to engage without barriers. This dissemination model supports rapid idea exchange across global participants, including working groups focused on specific protocol areas, thereby building consensus through transparent discussion.[1] The emphasis on openness aligns with the IETF's ethos, where anyone can submit a draft, and its adoption by a working group can elevate it toward broader influence.[7] In contributing to the internet's evolution, Internet-Drafts document experimental concepts that often shape foundational protocol designs, such as enhancements to TCP/IP mechanisms for improved performance and reliability. These drafts capture innovative approaches to challenges like congestion control or routing efficiency, providing a historical record of ideas that may inform future RFCs and drive incremental advancements in internet infrastructure.[8] Through this, they ensure that the standards process remains adaptive to technological shifts, prioritizing practical, community-vetted solutions over static prescriptions.[9]History
Origins in the 1980s
The concept of Internet Drafts traces its roots to the late 1970s and early 1980s, amid the ARPANET project and the initial development of TCP/IP protocols, where informal memos functioned as preliminary documents for community feedback before formal RFC publication. These memos, including the Internet Experiment Notes (IENs) series edited by Jon Postel from March 1977 to September 1982, enabled researchers to share evolving technical ideas on networking protocols without the rigidity of finalized standards. A total of 204 IENs were produced, covering topics such as file transfer and remote login, and they complemented the RFC series by providing a venue for experimental and unpublished work during the transition from ARPANET to the broader Internet.[10][11] The formal introduction of Internet Drafts as a distinct series occurred in July 1988, when the Internet Activities Board (IAB)—precursor to the modern IETF oversight bodies—approved their creation to address limitations in the RFC process, such as slow publication and lack of mechanisms for rapid iteration on evolving specifications. This built on early efforts by the Internet Research Task Force (IRTF), formed in 1986 to coordinate long-term networking research, and the nascent IETF meetings starting in 1986, where participants needed a lightweight way to circulate drafts for quick review among engineers and researchers. The IAB meeting minutes from July 12, 1988, highlight discussions on establishing a non-refereed draft series to support working groups, with Postel tasked to develop related processes, marking the shift from ad hoc memos to a structured repository for unpublished protocol proposals.[12][13] Jon Postel, as the inaugural RFC Editor since 1971 and a central figure in Internet governance at the University of Southern California's Information Sciences Institute, significantly influenced the early practices surrounding Internet Drafts through his management of unpublished works. He established the "internet-drafts" directory as a dedicated FTP-accessible repository for these documents, initially hosted at sites like nic.ddn.mil, to enable anonymous distribution and community access without formal endorsement. This directory, emerging in the late 1980s, allowed drafts to be posted for a limited period—typically six months—before expiration, preventing archival clutter while encouraging timely revisions, and it directly supported the IETF's collaborative model during its formative years.[11][14]Evolution with IETF Formation
The formation of the Internet Engineering Task Force (IETF) in 1986 marked a pivotal institutional shift for Internet Drafts, transitioning them from ad-hoc technical notes into structured working documents integral to the IETF's collaborative standards development process. The IETF's inaugural meeting in January 1986 brought together U.S. government-funded researchers and industry representatives to address Internet engineering challenges, establishing a framework where drafts served as preliminary proposals for discussion and refinement within working groups. This formalization emphasized open participation and consensus-building, laying the groundwork for standardized handling of drafts as the organization grew.[15] By the early 1990s, as the IETF matured, Internet Drafts received more defined guidelines through key publications, culminating in RFC 1543 in 1993, which outlined instructions for authors preparing documents for potential RFC publication, including review procedures for drafts by the Internet Engineering Steering Group (IESG). This document stressed the need for clear, accessible submissions to facilitate community feedback, reflecting the IETF's emphasis on transparency and iterative improvement. A significant milestone came in 1996 with RFC 2026, which revised the Internet Standards Process and explicitly introduced the six-month expiration policy for drafts to encourage timely updates and prevent outdated documents from lingering in the repository.[16][17] In the 2000s, the increasing complexity and volume of Internet Drafts prompted adaptations for better automation and scalability, including the shift to XML-based authoring tools. RFC 2629 in 1999 introduced an XML vocabulary for writing drafts and RFCs, enabling the xml2rfc tool to automate formatting into multiple output types like text, HTML, and nroff, which improved efficiency for authors and the RFC Editor. To manage the surge in submissions—from dozens annually in the early IETF years to thousands by the mid-2000s—the IETF introduced the Datatracker system in 2002, a web-based platform for tracking draft status, reviews, and progress, supporting the organization's expansion amid rapid Internet growth.[18][19]Creation and Submission
Authoring Requirements
Internet-Drafts require specific core elements to facilitate effective review and standardization within the IETF. An abstract must be included, offering a concise summary of the document's purpose, scope, and contributions, typically comprising 50 to 150 words without citations or references.[20] The status of the memo must be explicitly stated on the first page, distinguishing between individual submissions and working group contributions, while indicating the intended publication track such as standards track, informational, or experimental.[21] Standard boilerplate sections, including the copyright notice, Internet-Draft disclaimer, and intellectual property statements, are mandatory to ensure legal compliance and procedural transparency.[21] Authors must follow the principles outlined in BCP 9 (RFC 2026) to maintain clarity and neutrality throughout the document.[22] This adherence promotes unbiased, accessible writing that supports broad community participation and avoids favoring any particular interests in the standards development process.[22] Content standards prioritize technical accuracy, ensuring descriptions of protocols, algorithms, and behaviors are precise and verifiable to enable reliable implementations.[23] Vendor-specific language must be avoided to foster interoperability and prevent proprietary bias, with general networking terminology used instead to address a diverse audience of implementers and reviewers.[23] A dedicated Security Considerations section is required in every Internet-Draft, analyzing relevant threats such as eavesdropping, replay attacks, or denial of service; specifying protections like confidentiality or authentication mechanisms; and discussing residual risks, implementation vulnerabilities, and assumptions about the threat environment, in line with RFC 3552.[24] Style guidelines emphasize conciseness and readability, separating normative requirements from explanatory material while using diagrams, tables, or formal notations where they enhance understanding without overwhelming the text.[23] Precise, consistent terminology is essential, with abbreviations expanded on first use and American or British English spelling maintained uniformly.[21] When expressing requirements, authors must employ the uppercase keywords defined in RFC 2119—such as MUST for absolute obligations, SHOULD for strong recommendations, and MAY for optional elements—to clearly delineate conformance levels and interoperability expectations.[25]Submission Procedures
The submission of an Internet Draft to the IETF begins with authors accessing the IETF Datatracker's submission tool at datatracker.ietf.org/submit, where no login is required but is recommended for verification purposes.[26] Authors must upload the draft in the required format, preferably as RFCXML version 3 (with version 2 also accepted and automatically converted), or alternatively as plain text (.txt) if XML is not feasible; the XML source is considered authoritative.[2][27] Upon successful upload and validation, the tool assigns a unique draft identifier in the formatdraft-{source}-{wgname}-{short-doc-title}-{version}, such as draft-ietf-wgname-specific-subject-00 for the initial version, where the source is typically "ietf" for IETF stream drafts, the version starts at "00", and increments sequentially for revisions.[2][26]
Authors play a central role in initiating the submission, ensuring the document adheres to basic authoring standards like using the xml2rfc tool for preparation, and verifying the draft via an email confirmation link sent after upload.[26] For working group drafts, particularly the initial -00 version, authors must notify the relevant working group chairs, who are required to approve the submission before it is posted to the Internet-Draft repository at www.ietf.org/id; this approval is handled through email notifications from the Datatracker.[27][2] Area directors may review submissions for relevance, especially in the IESG stream, to ensure alignment with IETF processes, though this is not a mandatory step in the initial upload.[26]
Subsequent revisions follow the same upload process via the Datatracker, using the existing draft identifier with an incremented version number (e.g., -01, -02), and must include a change log—often titled "Changes from [previous version]"—detailing modifications to facilitate community tracking.[2][26] The tool validates the revised content and metadata before posting, replacing the prior version in the repository, with chairs again notified for working group drafts to confirm the update.[27] In cases where the Datatracker is unavailable, manual submissions can be sent to [email protected], but the standard procedure emphasizes use of the online tool for efficiency and automation.[26]