Summary

  • The RFC Series is one permanent archive fed by four publication streams: IETF, IAB, IRTF and Independent Submission. A shared numbering sequence does not erase their different approving bodies or review processes.
  • Stream and category answer different questions. Only the IETF stream can produce Standards Track and Best Current Practice RFCs, but the IETF stream also produces Informational, Experimental and Historic documents.
  • IESG review of an IRTF or Independent submission is chiefly a conflict check against IETF work. A finding of no conflict is not IETF endorsement of the document’s technical merits or fitness for deployment.
  • Anyone citing an RFC in procurement, audit, architecture or public policy should attach a publication receipt: stream, category, approval statement, review perimeter, current status, lineage, scope, implementation evidence and the identity of the actual adopter.

The column that erased three institutions

Imagine four documents entered in an assurance register. One is a Standards Track protocol approved through the IETF stream. One records the consensus of the Internet Architecture Board. One reports work approved for publication through the Internet Research Steering Group. One was selected by the Independent Submission Editor. The register records each as RFC #### and labels the column “IETF standard”.

Nothing in the number supports that label. The number is doing valuable work: it points to a stable item in the RFC Series, where readers can retrieve the document and its current record. But it is an accession number, not a seal that compresses four chains of approval into one.

This error survives because the archive is coherent. RFCs share presentation conventions, durable URLs and a familiar numerical form. That coherence is an achievement. It also makes provenance easy to overlook. A polished common cover can tempt a hurried reader to assume a common legislature.

The remedy is not to distrust RFCs. It is to read the publication receipt that the Series already supplies.

One archive, four streams

RFC 8729 describes the RFC Series as the archival series for Internet technical specifications. Its contents include standards documents and broader contributions from the Internet research and engineering community. IETF documents are a large part of the Series, the RFC says, but not its entirety.

The Series receives documents through four streams. The IETF stream includes working-group documents and submissions sponsored by an IESG area director. The IAB stream carries documents approved under the IAB’s own process. The IRTF stream publishes research-group work reviewed through the IRSG. The Independent Submission stream provides a route for material outside the other three.

Each stream answers “who approved this for publication, under which process?” The RFC Editor gives the results one archival home. Common custody does not retroactively make the IAB an IETF working group, the IRSG the IESG, or an Independent Submission an IETF product.

This is a useful institutional design. An Internet archive can preserve research, architectural statements, standards work, dissent, vendor-specific material and historical records without pretending they all carry the same mandate. Diversity at intake and consistency in preservation are compatible only if the intake label remains visible.

Stream is not category

A second mistake begins after the stream is found. Readers often treat “IETF stream” as synonymous with “Internet Standard”. RFC 7841 makes the distinction explicit. RFC categories include Standards Track, Best Current Practice, Experimental, Informational and Historic. The IETF stream produces documents in several of these categories.

Only the IETF stream can approve Standards Track or BCP RFCs. The converse does not follow: not every RFC in the IETF stream is Standards Track or BCP, and not every document approved by the IESG is a candidate for Internet Standard status.

Stream and category are therefore two coordinates. Stream identifies institutional origin and approval path. Category describes the document’s publication status or type. Neither coordinate alone tells a user whether a particular mechanism is current, appropriate to a system, implemented by a vendor, required by a contract or enforceable under law.

The Status of This Memo section is not ornamental boilerplate. RFC 7841 says it identifies stream-specific status and describes the review the material received. It tells a reader how broadly and deeply to consider the text. Skipping it is the documentary equivalent of citing a judgment while omitting the court and procedural posture.

Approval belongs to a named community

The IAB stream demonstrates why “approved” needs a subject. An IAB document can represent IAB consensus and be valuable enough for permanent record. That is a real institutional statement. It is not thereby IETF community consensus, and an IAB-stream document is not a candidate for an Internet Standard merely because it bears an RFC number.

The IRTF stream makes the boundary even more instructive. RFC 5743 requires a research-group document to describe its level of support and the breadth of review. It may represent research-group consensus, or it may record controversial views that the group nevertheless agrees should be published. IRSG review works like an editorial review board and checks technical clarity, editorial quality and adequacy of prior review. The document must remain clear that it is not an IETF product and not a standard.

These disclosures are strengths, not disclaimers of worth. Research advances by publishing results and disagreements before every question is ready for standardisation. The mistake is to inflate a carefully stated research approval into a different institution’s standards decision.

Independent Submissions are also not a back door for unreviewed text. RFC 4846 describes a tradition older than the IETF and a route serving technical ideas outside the IETF agenda, bridge work between academia and engineering, vendor-specific protocols, critiques, historical material and other contributions.

In the older procedure described there, the RFC Editor obtains reviews. RFC 8729 points to the current Independent Submission Editor model, in which that editor makes the stream-specific judgment about suitability. Common publication by the RFC Editor does not turn that judgment into an IETF decision. Independence identifies the approval route; it does not mean absence of judgment.

A conflict check is not an endorsement

One especially persistent error concerns the IESG’s role. IRTF and Independent submissions are sent to the IESG for review against IETF standards work. That sounds like approval when abbreviated in a memo: “IESG reviewed.” The verb hides the question the review was asked to answer.

RFC 5742 specifies a conflict review. The IESG considers whether publication conflicts with an existing or expected IETF activity and may request a note explaining the relationship. If no conflict is found, the Independent Submission Editor remains responsible for judging the technical merits of an Independent Submission; the IRSG remains responsible for an IRTF submission.

“No conflict” therefore has a narrow and important meaning. It protects the standards process from harmful ambiguity while allowing other streams to publish. It does not mean “the IETF endorses this design”, “the IETF completed a security review”, or “the IESG certifies deployment fitness”. Turning a jurisdictional clearance into a technical blessing borrows authority from the reviewer while discarding the review’s scope.

The reverse shortcut is equally wrong. A non-IETF-stream document is not worthless because the IESG did not approve its merits. It may contain excellent research, operational experience or a valuable critique. Correct provenance helps a reader assess the actual evidence instead of ranking documents by a false institutional hierarchy.

The number proves less—and more—than it appears

An RFC number proves less than an approval stamp, but more than a casual citation. It identifies a publication accepted into a permanent, edited and indexed series. The record preserves authorship, date, stream, initial category and links to later status information, errata, updates and obsolescence.

That durability matters. Engineers can cite the same text decades later. Disputes can be resolved against a stable record rather than a mutable webpage. A research claim, architectural position or independent critique does not disappear merely because it lacks Standards Track status.

The limit is equally important. Archival inclusion does not establish current technical applicability. Boilerplate records initial status; a later change to Historic status cannot rewrite the old document. Readers must consult the current RFC Editor record. They must also identify the relevant section, because an RFC can mix normative requirements, explanatory material, examples and scoped recommendations.

Nor does publication demonstrate running code. A standards-track requirement may lack deployment in a particular fleet. An Informational RFC may accurately describe a widely deployed system. An Independent Submission may document a proprietary protocol already in use. Stream and category organise the claim; implementation evidence tests the world.

How a bare citation acquires borrowed authority

The bare number travels well. A procurement team inserts it into a tender. An auditor copies it into a control. A ministry cites the auditor. A vendor then markets “RFC compliance” without naming sections, options or test results. At each handoff, the citation grows more authoritative while its provenance and scope shrink.

This is not merely semantic. A purchaser may reject a product against a research document that was never an IETF standard. A regulator may treat an experimental mechanism as settled industry practice. A security team may accept an IETF-stream Informational document as proof that a product received a complete IETF security assessment. A vendor may hide behind an RFC number that describes a protocol but does not establish its implementation’s behavior.

The error also distorts representation. Open participation in technical work is valuable, but it does not make every participant an agent of every person affected by the Internet. Rough consensus is an engineering method for producing interoperable specifications, not a referendum that grants a universal political mandate. Naming the stream and approving body prevents a technical institution’s legitimate remit from being inflated by downstream users.

Build a publication receipt

A defensible citation needs one page of provenance, not a longer incantation of numbers.

Record the document: RFC number, title, date and the section being relied upon. Record the stream and the named approving body. Record the category and quote or accurately paraphrase the Status of This Memo description of support and review. For an IRTF or Independent item, distinguish the IESG’s conflict review from the merit decision made in that stream.

Then record currency: current status, errata and the later documents that update or replace it. Record scope: protocol version, deployment context, optional features and applicability conditions. Record evidence: interoperable implementations, tests, observed use and known limitations. Finally, record adoption authority: the operator, contract, regulator or policy owner that chose to make the document relevant in this setting.

This receipt does not weaken standards. It prevents an organisation from claiming more than the evidence supports. A Standards Track RFC can then be cited for the authority it genuinely has within the standards process. An IRTF paper can be valued for research evidence. An IAB statement can be understood as an architectural position. An Independent Submission can be judged on its actual review and content.

Read the stream before citing the number

The RFC Series is a library with disciplined admissions, not a parliament with one vote. Its strength comes from preserving different kinds of technical work without erasing their origins.

When a document appears in a policy or assurance register, ask five questions. Which stream carried it? What category does it have? Who approved publication and for what purpose? What review was actually performed? Who, outside the archive, decided that the document applies here?

If those answers are missing, the RFC number is being asked to impersonate an institution. Restore the publication receipt and the number becomes useful again: a precise address for evidence, not a counterfeit mandate.

Sources