Guide to IETF Internet-Drafts

The Internet Engineering Task Force (IETF) drives the evolution of internet protocols through its working documents called Internet-Drafts (I-Ds). These drafts serve as the foundation for RFCs – the official standards documents that define how the internet operates. Understanding how to create, submit, and advance an Internet-Draft is essential for anyone contributing to internet standards development.

Understanding the Role of Internet-Drafts

Internet-Drafts represent working specifications that are openly available for review and comment. Unlike RFCs, which are published standards, I-Ds have a limited lifetime of 185 days and can be updated or replaced multiple times. They enable rapid iteration and community feedback before formal standardization.

The IETF maintains multiple streams of Internet-Drafts:

• IETF Stream: Working Group developed documents intended for standards track RFCs
• Independent Submission Stream: Individual submissions reviewed by ISE
• IRTF Stream: Research group outputs
• IAB Stream: Internet Architecture Board documents

Each stream has specific submission and review processes, but all follow core formatting and submission guidelines.

Planning Your Internet-Draft

Before writing, identify the appropriate working group or area. The IETF Working Groups directory lists active groups by technical area. Review the charter to ensure your proposal fits within scope.

Choosing the Right Filename Convention

Internet-Draft filenames follow strict conventions:

Key Rule: When a working group adopts an individual draft, it always restarts at version 00 with the draft-ietf-wgname- prefix.

Technical Requirements for Draft Formatting

Modern Internet-Drafts must use RFCXML v3 (xml2rfc version 3) as the authoritative source format. The IETF Datatracker automatically generates plaintext and HTML versions from your XML source.

Essential xml2rfc Structure

Required Sections:

• Clear, descriptive title (under 80 characters)
• Abstract: 150-200 word summary of purpose, scope, and key features
• Status of This Memo: Generated automatically
• Copyright Notice: IETF Trust boilerplate required

Author Information Best Practices

List all significant contributors as authors. Use full names and complete contact information. Multiple authors from the same organization should still be listed separately.

Pro Tip: Log into Datatracker before submitting to automatically associate authorship and bypass email verification.

Writing Quality Internet-Draft Content

Effective I-Ds balance technical precision with accessibility. Follow these content guidelines:

Core Documentation Elements

1. Problem Statement: Clearly articulate the problem being solved
2. Requirements Analysis: List functional and non-functional requirements
3. Protocol Design: Detailed specification with state machines, message formats
4. Security Considerations: Comprehensive threat model and mitigations
5. IANA Considerations: Registry requests with clear allocation policies

Specification Language Precision

Use RFC 2119 keywords appropriately:

• MUST: Absolute requirement
• SHOULD: Recommended but not mandatory
• MAY: Truly optional

Include normative and informative references. Verify all citations exist in the RFC repository.

Submission Process via IETF Datatracker

All submissions use the centralized Datatracker submission tool.

Step-by-Step Submission

1. Prepare Files: RFCXML v3 (.xml) as primary, optional plaintext (.txt)
2. Access Tool: datatracker.ietf.org/submit/
3. Upload Files: Specify if replaces existing draft
4. Review Preview: Check generated text/HTML versions
5. Submit: Receive verification email (bypassed if logged in)

Working Group Adoption Process

Individual drafts become WG documents through formal adoption. This requires:

• Demonstrated WG interest and support
• Chairs’ approval
• Restart at version -00 with draft-ietf- prefix

WG chairs must explicitly authorize publication of new WG drafts.

Internet-Draft Lifecycle Management

Version Progression

Drafts progress through version numbers (-00, -01, -02…). Major revisions often restart counting. The Datatracker tracks all versions and relationships.

Expiration Policy

I-Ds automatically expire after 185 days unless:

• Submitted new version before expiration
• In IESG processing for RFC publication
• Under ISE review (Independent stream)

Path to RFC Publication

Successful WG documents advance through:

1. WG Last Call: Internal WG review (2-4 weeks)
2. IESG Review: Area director and AD expert review
3. IETF Last Call: Community review (2 weeks minimum)
4. RFC Editor: Final formatting and publication

Common Pitfalls and Best Practices

Tools and Resources

• xml2rfc: pip install xml2rfc
• idnits: Online nit checker
• Datatracker: Submission and tracking
• WG Mailing Lists: Primary discussion venue

Frequently Asked Questions

Can I submit without being an IETF member?

Yes, anyone can submit Internet-Drafts. No membership required.

What happens if my draft expires?

Expired drafts remain in the archive but lose repository visibility. Submit a new version to revive.

How do I get my draft adopted by a WG?

Present on mailing list, demonstrate support, gain chair approval.

Can I submit plain text instead of XML?

XML v3 is authoritative. Plain text is deprecated but temporarily accepted.

Advanced Topics

Multiple Authors: All significant contributors should be listed. Use editor for maintainers of informational documents.

Replaces/Obsoletes: Use and tags in XML header.

Similar Articles

IPv6 Email Servers: Secure Deployment Guide

IPv6 Revolution: 2026 Tipping Point

IPv6 at IETF 103: Key Sessions Guide

IPv6 Evolution: 14 Years Post-Launch

Remote IETF Participation Guide

Understanding the IETF’s Role in Internet Governance

Author

medha deb

 

Medha Deb is an editor with a master's degree in Applied Linguistics from the University of Hyderabad. She believes that her qualification has helped her develop a deep understanding of language and its application in various contexts.

Read full bio of medha deb