Summary
- RFC 2028 separated the people who ran a working-group process from the people who recorded its result, then assigned administrative, publication, standards, architectural and registry duties to different institutions.
- That public allocation created addresses for accountability. It was not a transaction log: it could not prove who made a particular decision, whether participation was representative, whether records were complete, whether duties were performed or whether a standard was deployed.
- RFC 9281 replaced the document in 2022 after the IETF’s structure changed. Every institutional map therefore needs a date as well as a title.
A seven-page document can look too slight to be constitutional. RFC 2028 contained no voting system, budget or protocol. Its most consequential move was simpler: it named where different kinds of responsibility were supposed to sit.
The Working Group Chair directed activity, presided over meetings and served as the group’s formal contact toward the IESG through an Area Director. The Document Editor had a different task: make the document accurately reflect decisions already made by the group. The Secretariat supported the institution and maintained the formal public record. The RFC Editor managed publication. The IESG advanced technical specifications through the standards process. The IAB watched architecture and process. IANA assigned unique protocol parameters. ISOC’s Board held a defined procedural role in the arrangement described at the time.
The list is useful because it prevents every institutional act from collapsing into the word “IETF”. It is limited because a role description is not evidence that the role was correctly performed.
The chair and the editor did not own the same fact
RFC 2028 described separation between a Working Group Chair and a Document Editor as general practice. The Chair was responsible for the group’s activity and procedural commitments. The Editor was responsible for the fidelity of the resulting text. Giving those positions to different people could make it harder for one person both to manage a decision and to control its surviving record.
That is an internal control, not a certificate. Two names in two roles do not prove that objections were heard, that a consensus call was sound, or that an edit matched the decision it purported to record. Those claims require a dated chain: versions of the draft, meeting and mailing-list records, the proposition put to the group, unresolved objections, the chair’s reasoning and the edit that followed.
The later RFC 9281 makes the historical character of the 1996 rule visible. It keeps the editor’s duty to reflect the working group’s decisions, but deals explicitly with a chair who is also an editor: another chair should manage that document; if none is available, the group and Area Director must monitor the process especially carefully. The control was refined rather than frozen.
Administration, publication and approval were separate receipts
RFC 2028 gave the IETF Secretariat responsibility for administrative support and the formal public record. It gave the RFC Editor the mechanics of publication and the standards of the RFC series. Those sentences create two different proof obligations.
A Secretariat record can show that a meeting, submission or procedural step was registered. It does not establish that every relevant message was captured, that a link remained reachable, or that the underlying decision was correct. Publication can show that a particular text entered the RFC series. It does not establish implementation, interoperability, deployment or operational success.
The distinction is easy to lose because both functions leave documents behind. One maintains the process record; the other prepares and publishes an output. Neither can silently certify the work of the other.
Technical authority was distributed, not converted into one command
The RFC placed technical work in working groups organized into Areas. It described the IESG as managing IETF technical activity and handling the progression of specifications, including approval of new working groups and final approval of Internet Standards. The IAB received architectural and process oversight, charter review, advice and an appeal role. IANA assigned values needed by extensible protocols and published the resulting tables. ISOC occupied the procedural and organizational position recorded in the 1996 settlement.
These roles touch one another, but they do not create interchangeable authority. An IANA assignment is not an IESG approval. An IESG approval is not an IAB finding. An IAB opinion is not a working-group decision. An ISOC institutional role is not authorship of protocol text. The map tells a reader which additional record to seek.
It also distinguishes participation from representation. RFC 2028 described IETF membership as arising from individual participation, not from formal representation of employers or other organizations. That rule identifies the capacity in which people take part. It does not prove that access was equally affordable, that employer resources had no influence, or that absent operators and users were represented.
Some boxes had no finished charter behind them
The document is unusually candid about its own incompleteness. In the IESG section, the referenced IESG charter was marked as not yet existing. Its references called both the IANA Charter and the RFC Editor Charter works in progress.
That does not make the map worthless. It shows exactly how the map should be read. RFC 2028 was a public index of assigned responsibility at a moment of institutional construction, not a single closed instrument from which every power could be derived. A role could be named while the detailed charter, selection method, remedy or execution evidence still lived elsewhere—or remained unfinished.
The gap creates a practical test. When someone cites the map as authority for an action, ask for the next record: the applicable charter, the decision, the named actor, the date, the reasons, the implementation and the review path. If those records are absent, the organization name cannot fill the space.
RFC 9281 put a date on the old map
RFC 9281 replaced RFC 2028 in June 2022 because the IETF’s structure had changed. It added the responsible Area Director, the IETF Trust and the IETF Administration LLC, replaced the old RFC Editor label with the RFC Production Center, and rearranged the individual roles to follow a typical workflow. It retained several familiar responsibilities while changing the institutions around them.
Obsolescence does not erase the 1996 record. It limits its tense. RFC 2028 remains evidence of how responsibilities were publicly described then. It is not current proof that the same legal relationships, publication model or organizational interfaces still govern today.
The durable value of the old map is therefore modest and important. It makes institutional claims falsifiable. If one actor said it represented the working group, maintained the record, approved the standard or assigned the parameter, the document gave observers a baseline against which to ask whether that claim belonged to the actor’s role.
But accountability begins where the chart ends. A responsibility entry identifies whom to question. Only the decision trail, record integrity, execution evidence and observed outcome can show what happened.
Sources
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
