| name | ietf-interpreting |
| description | Interpretive norms for reading the record of an IETF/IRTF effort. Use BEFORE characterising what a working group decided, whether there is consensus, who supports or opposes a proposal, or where the group stands — any sentence asserting a collective outcome (settled, decided, agreed, rejected, consensus, "the WG thinks/wants"). Covers consensus is chair-declared not vote-counted, decisions happen on the mailing list not in meetings, positions belong to individuals not their employers, and what Internet-Draft names and RFC streams do and don't imply. Reporting what a named individual said does not require this; any claim about where the group landed does. For drafting a contribution, use ietf-contributing instead. |
| license | CC-BY-4.0 |
Reading the IETF record
The trigger is grammatical, not a self-assessment: before you write any
sentence asserting a collective outcome — settled, decided, agreed,
rejected, "there is consensus," or "the WG thinks/wants" — you should have read
these norms. Reporting what a named individual said is free; any claim about
where the group landed is gated. Not enforced — the point is to make skipping
the check something you notice choosing, not ordinary efficient judgment. For
the write side — drafting contributions — see the ietf-contributing skill.
The trap is what you already know
You know the headlines — consensus is chair-declared, not vote-counted;
decisions are confirmed on the list, not made in meetings; participants speak
as individuals, not their employers. That is the trap. The rule that gets lost
isn't a fact you're missing — it's that a discussion feeling resolved is not
resolution. When prominent participants converge and the tone goes calm, no one
has decided until a chair declares it on-list or a closed issue records it.
Convergence among vocal participants — even unanimous-sounding — is signal, not
outcome. A session poll (28-4) is a tool to gauge the room, not a decision.
Confidence that the matter is closed is the cue to verify the chair's words,
not to skip the check.
Worked example. A draft author raises an objection; a respected
cryptographer posts an analysis answering it; three well-known participants
reply approvingly. Tempting: "the objection was settled." Earned: "the
objection appears answered to the satisfaction of several vocal participants;
no chair has declared it closed, and the draft author was still pressing open
points." Even a chair's summary is weaker evidence than the chair's actual
procedural message — chair characterisations get disputed on-list too. Look for
the chair's actual procedural messages for a thread — the consensus call, WGLC,
or closure — rather than relying on a summary of them.
Not every decision is called, and none is final until Last Call
Two symmetric mistakes about finality. First, the absence of a consensus
call isn't an open issue: chairs don't poll every point, leaving many formally
open as the work proceeds and sweeping them up at Working Group Last Call
(WGLC) — the wrap-up that confirms the document whole. Second, a consensus
already declared isn't a closed door — new relevant information (a fresh
implementation report, a security analysis, a use case nobody weighed) can
reopen it at the chair's discretion. Report a past consensus as the current
state of play, not a permanent fact.
And WGLC itself isn't the last word. WG agreement only earns the draft an
IETF Last Call, where the whole community — not just WG participants —
weighs in, then IESG review. A group can agree among themselves and still see
the work reshaped or blocked from outside. "The WG agreed" is not "the IETF
agreed"; a document past WGLC but not yet an RFC is still open to wider
scrutiny.
Affiliation: aggregate, don't attribute
Don't pin a position on a company ("Cloudflare opposes X") from an author's
affiliation — only when they frame it that way ("speaking for X…"). But
implementer signal is real ("rough consensus and running code"), so
aggregate instead: "8 of 12 stated supporters ship TLS stacks" is fine;
"Cloudflare supports X" is not, unless they said so. One non-obvious bit:
Email domain ≠ affiliation. Participants use personal email and may hold
several affiliations. Rely on stated affiliation data where you have it, never
on the From-header domain.
Draft names carry structure, not gravity
The prefix is the draft's posture in the process, not its weight:
draft-ietf-<wg>-… — adopted by an IETF WG (the segment after ietf- is
the WG shortname). draft-irtf-<rg>-… — adopted by an IRTF Research Group
(research, not standards).draft-<author-id>-… — an individual submission. The author-id is
arbitrary, and a hint after it (draft-rescorla-tls-…) is unreliable — don't
infer authorship or WG membership from the filename; check the draft's
metadata.
Unadopted drafts have no IETF status — not a WG document, not
standards-track, no community endorsement. Don't say "the IETF is working on X"
when X is one person's draft-author-….
Not every RFC is a consensus standard
The stream the draft took determines the endorsement the RFC carries:
- IETF stream — WG-adopted, or AD-sponsored for an individual draft: the
consensus standards track.
- IRTF stream — research output, not a standard.
- Independent Stream (ISE) — lightweight editorial review, explicitly not
a consensus standard; reading one as "the IETF says…" is wrong.
- IAB / Editorial streams — architectural statements / RFC-series process;
both non-standards.
An RFC number alone doesn't tell you — check the stream and the WG provenance.
DISPATCH and BoFs are "being considered," not "being worked on"
Proposals rarely land straight in a WG. New work is triaged through the
DISPATCH WG (or a domain equivalent that runs its own triage — httpbis
for HTTP, tls for TLS, dnsop for DNS) and explored in one or two BoF
sessions before a WG is chartered. A BoF is not a WG — no documents, no
consensus authority. So a topic at DISPATCH or a BoF is being considered, not
being worked on.
