10 The shape of the IETF

10.1 A body with no members

3GPP is a partnership of organisations, and everything in it flows from that: member companies, delegates, Organizational Partners, a legal home in somebody else's articles.

The IETF starts from the opposite end.

There is no list to be on. People take part as individual technical contributors, not as formal representatives of the organisations that employ them RFC 2418.

That does not make the IETF shapeless. It has bodies, roles and written procedures, and this chapter is about them. What it does not have is a gate at the entrance.

10.2 Working groups and areas

The work is done in working groups. Working groups are collected into areas, and each area is run by one or two area directors RFC 2418.

That is two layers where 3GPP has three or four, and the difference is not cosmetic. A 3GPP working group hands its output upwards to a plenary that approves it §4.6.4. An IETF working group hands its output to its area director, who starts a process that runs across the whole organisation rather than inside a parent committee — which is The life of an RFC, from a draft nobody may cite to a number nobody may edit.

How a working group is formed, chartered, run and closed is a document in its own right RFC 2418, and it is the closest thing the IETF has to TR 21.900.

10.3 The steering group

The area directors do not only run their own areas.

The IESG is the body that approves IETF standards actions RFC 2026. It is the nearest structural equivalent of a 3GPP plenary — with the difference that it is a standing body of people who each also lead an area, rather than a meeting of everybody who turned up.

10.4 The other bodies in the picture

One document exists purely to say who the players are, and it is worth knowing it exists before you meet the acronyms in the wild RFC 2028. It names:

• the IETF and its working groups — where specifications are written;

• the IETF Secretariat — the administrative machinery;

• the Internet Society — the organisational and legal home;

• the IESG — which approves standards actions;

• the Internet Architecture Board — the architectural oversight body;

• IANA — which runs the registries of numbers and names;

• the IRTF — the research counterpart to the engineering work.

IANA is the one a reader meets soonest, because a document that creates a registry of numbers hands it over in a section of its own, written to a prescribed shape RFC 8126. That is the IETF's answer to the code-point registration 3GPP's Support Team does on the partnership's behalf §3.2.

Two more rules round out what a contributor is signed up to. Patent disclosure has its own document, setting out what a contributor must reveal about intellectual property in the technology being discussed RFC 8179. And the style of the published document is governed by a style guide, the IETF's counterpart to 3GPP's drafting rules RFC 7322, TR 21.801 v19.1.0.

10.5 The RFC series

The output goes into one series with one running number, and it has been running a long time: the RFC series is the official publication channel for IETF standards and began in 1969, as part of the ARPANET project RFC 2026.

What the series is, and who runs it, are two further documents RFC 8729, RFC 9280.

Two properties of the series catch people out. The first is that not everything in it is a standard. Experimental, Informational, Historic and Best Current Practice documents all live in the same numbered series as the standards RFC 2026, and The life of an RFC, from a draft nobody may cite to a number nobody may edit separates them.

The second is that documents arrive by more than one route. An RFC comes from one of the series' streams, and its own header block says which — so a reader can tell an IETF standard from an independent submission without leaving the page RFC 7841. The same header carries the document's category, its BCP or STD number if it has one, and what it obsoletes or updates.

10.6 The five principles

The mission statement names five things the IETF says it works by RFC 3935:

• an open process — anybody may take part;

• technical competence — the body works on what it is competent to judge;

• a volunteer core — the people doing the work are not employed to do it by the IETF;

• rough consensus and running code — decisions and implementations, in that order and each testing the other;

• protocol ownership — a protocol adopted by the IETF becomes the IETF's to maintain.

The fourth of those is the one with real machinery behind it, and it gets a chapter of its own Rough consensus, and why the room hums.

10.7 What the archive here holds, and what it does not

Everything in this half of the course is read from an archive of RFCs on this machine. It holds 9,735 of them ^[4] — 8,457 as plain text ^[5] and 1,278 as XML ^[6].

That archive has edges, and they matter for what this course can say:

• It is RFCs and nothing else. No working group charters, no meeting minutes, no mailing list archives, no Internet-Drafts. Anything about a particular IETF working group is out of reach from here.

• The plain-text range has gaps. The 8,457 plain-text files run from number 1 to number 8649 ^[5], so numbers are missing along the way. Some were never issued and some are held only among the 1,278 XML files ^[6]; the data does not say which is which.

• Two of the documents this course names are not quoted. RFC 8729 and RFC 9280 are in the archive only as XML, so this course names them and takes no sentence out of them RFC 8729, RFC 9280.

• Nothing here says who anybody is. No names, no attendance, no counts of participants, and nothing about what taking part costs.

10.8 Where this leads

The life of an RFC, from a draft nobody may cite to a number nobody may edit follows one document from a draft nobody may cite to a number that can never be edited. Rough consensus, and why the room hums is how the decision to publish it is reached, and MUST, SHOULD and MAY — three words, one short document is the vocabulary it will be written in.