IETF RFC Process for Internet-Drafts

This page explains the usual IETF path from an Internet-Draft to an RFC. It focuses on the IETF Stream and Standards Track, because draft-thain-ipv8-02 lists an intended status of Standards Track.

Short Version

An Internet-Draft is a public working document. Anyone may write and submit one. That does not make it an IETF standard, an IETF work item, or an RFC.

For a draft to become a Standards Track RFC, it normally needs:

A suitable IETF home, usually a Working Group.
Active technical discussion and revision.
Working Group adoption, if the work belongs in a WG.
Working Group consensus that the document is ready.
IETF Last Call.
IESG review and approval.
RFC Editor editing, author final review, and publication.
IANA registry actions, if the RFC creates or changes protocol parameters.

Who Can Propose?

Anyone can write and submit an Internet-Draft. No membership, employer, national standards body, or prior permission is required.

Submitting a draft grants rights to the IETF Trust under the IETF contribution rules. Authors also need to follow IETF policies on copyright, patents, and disclosure.

How To Submit A Draft

The usual submission path is the IETF Datatracker Internet-Draft submission tool.

The Datatracker submission page recommends:

Checking the draft with the idnits tool before submission.
Submitting xml2rfc version 3 XML source when possible.
Letting the system generate TXT output from XML, or providing TXT when XML is not possible.
Using manual posting only if the submission tool cannot be used.

After posting, the draft appears publicly as an Internet-Draft. It can expire after six months unless updated, replaced, or already under official publication review.

Paths After Submission

Path	When it applies	Possible result
Individual draft only	Author wants public review or archival discussion.	May expire without further action.
Existing Working Group	The topic fits an active WG charter.	WG may discuss, adopt, revise, and progress it.
DISPATCH or BOF	No obvious WG exists, or the scope needs community routing.	Work may be directed to an existing WG, a new WG, AD sponsorship, more discussion, or no IETF action.
AD-sponsored	An Area Director agrees to sponsor an individual document.	Can proceed through IETF review without WG adoption.
Independent Submission Stream	Work is outside IETF/IAB/IRTF official process.	May become Informational, Experimental, or Historic RFC, but not a Standards Track RFC.

Working Group Stage

Most IETF standards work happens in Working Groups. A WG is mainly a public mailing list with a charter, chairs, and Area Director oversight.

Important points:

Anyone can join a WG mailing list and post to it.
A WG works only within its charter.
WG chairs manage discussion, calls for adoption, consensus calls, Working Group Last Call, and document progress.
A WG draft reflects WG consensus, not only the original authors’ view.
Authors or editors update the draft based on WG decisions.
If editors do not follow WG consensus, chairs can replace them.

WG decisions use rough consensus, not majority voting. Chairs judge whether the objections have been heard and whether the group has enough agreement to proceed.

Review And Approval

When a WG document is ready, the WG chairs normally send it forward with a document shepherd write-up. The responsible Area Director reviews it and places it into the IESG process.

The IESG then manages IETF-wide review:

IETF Last Call: The wider IETF community gets a final review period. Comments can come from anyone.
IESG Evaluation: Area Directors review the document. They can approve, raise blocking issues, request changes, or send the document back for more work.
Final IESG decision: The IESG decides whether the document should be approved for publication and at what status.

The IESG is responsible for entry into and movement along the Standards Track, including final approval of Internet Standards.

RFC Editor Stage

After approval, the document enters the RFC Editor publication queue.

The RFC Editor process includes:

Editorial review and formatting.
Reference checks.
Coordination with IANA when registry actions are needed.
Resolution of publication-blocking issues.
AUTH48, the authors’ final review before publication.
Final publication as an RFC.

Once an RFC is published, it is archival. The RFC text is generally not changed; later corrections are handled through errata or by publishing a new RFC that updates or obsoletes the older one.

IANA Role

IANA maintains protocol parameter registries used by IETF standards, such as code points, number assignments, DNS-related parameters, and many other protocol registries.

If a draft requests new protocol parameters, the draft’s IANA Considerations section tells IANA what registry action is needed. IANA processing usually happens during the RFC Editor stage, often in parallel with editing.

IANA executes approved registry actions; it does not decide whether a draft should become a standard.

Standards Track Maturity

Modern IETF Standards Track has two maturity levels:

Level	Meaning
Proposed Standard	First official Standards Track level. Many standards remain here.
Internet Standard	Final maturity level, used when the specification has strong maturity, interoperable implementations, deployment, and operational experience.

RFC 6410 removed the old three-level ladder for new standards and reduced the Standards Track to Proposed Standard and Internet Standard.

Who Does What?

Actor	Main role
Authors	Write the draft, respond to review, revise text.
Individual participants	Review, implement, test, object, suggest changes, and discuss on mailing lists.
Working Group	Builds rough consensus around the technical content.
WG chairs	Manage process, judge WG consensus, run calls, and move documents forward.
Document shepherd	Summarizes document history, reviews status, and helps the Area Director.
Area Director	Oversees the relevant area, reviews the work, and brings it to IESG.
IESG	Performs IETF-wide review and decides whether to approve publication in the IETF Stream.
RFC Editor	Edits, formats, queues, and publishes the RFC.
IANA	Performs approved protocol registry actions.
IETF Trust	Holds rights and licensing framework for IETF contributions and RFC text.

What This Means For IPv8

draft-thain-ipv8-02 is currently an Internet-Draft. Its intended status is Standards Track, but that is an author-supplied target, not an approval.

For IPv8 to become a Standards Track RFC, it would need to pass through the IETF process above. For a proposal that changes core Internet-layer behavior, practical review would likely focus heavily on interoperability, deployment impact, IANA code points, compatibility claims, operational safety, security, and whether there is broad implementer and operator support.