How a 3GPP document is made · chapter 8 of 16 · 9 minutes
8 How a 3GPP meeting decides, and the word it decides in
Everything in the room is a numbered document, every document ends with one status word from a fixed list, and between meetings the same decisions are taken by email under a rule where silence means yes.
8.1 Why nothing is decided out loud
A 3GPP meeting decides a great many things in a week, and every one of them has to survive being asked about years later. Speech does not survive. Documents do.
So the room does not decide topics; it decides documents. Each one arrives with a number, is discussed, and leaves with exactly one status word chosen from a published list. The meeting report records the word. That is the entire mechanism.
8.2 Everything in the room is a TDoc
The name is a fossil. The note under that sentence explains that TDoc is short for Temporary Document, left over from a time when contributions were on paper and were not meant to be kept after the meeting, in contrast with Permanent Documents which were. 3GPP now keeps every one of them electronically, so there is no need for a separate class — although some groups still keep documents they informally call permanent reference documents §9.1.
The record on this machine holds 1,629,581 of them [1].
Each contribution has to be one of a fixed list of types §9.1. The ones you meet constantly:
| Type | What it is |
|---|---|
| CR | a formal proposal to change a document under change control |
| CR Pack | change requests agreed at working group level, presented together to the plenary |
| pCR | the same for a document not yet under change control |
| draftCR | unnumbered, for a document already under change control; may become a real change request |
| WID new / WID revised | a work item description, new or changed |
| SID new / SID revised | the same, where the work item is a study |
| LS in / LS out | a liaison statement received from, or sent to, another group or body |
| WI status report | the rapporteur's report on how far a work item has got |
| WI exception request | a request to let a work item overrun its schedule |
| discussion | a paper meant to be argued about |
| report | the proceedings of a meeting |
| WI Summary | a plain-language account of what a finished work item delivered |
The rest — agendas, the work plan, terms of reference, draft documents and their cover sheets, responses, and a catch-all "other" — are in the same table §9.1.
Five of those types are counted in the register behind this course.
| Type | How many in the record |
|---|---|
| CR | 516,786 [2] |
| pCR | 159,031 [3] |
| LS out | 47,474 [4] |
| WID new | 11,595 [5] |
| SID new | 5,532 [6] |
8.3 The status words
Every contribution with a formally allocated number carries a status from table 9.2-1 §9.2. The two that matter most are neighbours, and confusing them is the commonest mistake a newcomer makes in a meeting report:
-
approved — a favourable conclusion where the group in question, plenary or working group, has the final say;
-
agreed — a favourable conclusion where the decision still has to be confirmed by a higher body, typically a working group decision going up to its plenary.
The rest of the table covers the other ways a document can end §9.2:
| Status | What it means |
|---|---|
| reserved | a number allocated, the document not yet available |
| available | present, not yet treated |
| noted | presented; no specific action follows |
| postponed | presented; no final decision; likely to come back |
| withdrawn | the author pulled it before discussion |
| treated | presented, but no other status fits — used mainly for packs |
| revised | it will come back as a new document |
| partially approved | for packs: some of the contents approved, others not |
| endorsed | judged valid, but short of agreed or approved |
| merged | folded into a new, composite document |
| reissued | for change requests in a pack that reappear unchanged in a new pack |
| replied to | for an incoming liaison that has been answered |
| conditionally agreed | agreed, subject to a decision on another document |
| conditionally approved | approved, subject to a decision on another document |
| not concluded | discussion started but not finished |
| not pursued | no further action to be taken |
| rejected | kept for old documents; identical in meaning to not pursued |
That last pair is a small piece of institutional manners. "Not pursued" is the replacement for "rejected", without the emotive weight some people inferred from it; the older word survives for groups that do not mind it and for historical records §9.2, §4.6.1. In the record, 97,521 documents ended as approved [7] and 16,137 as not pursued [8].
Two statuses are worth reading closely because they describe a document that is not there. "Reserved" means a number was allocated but the document never appeared; if that is still true at the end of the meeting, the report shows it as not available. "Available" means it turned up and was never reached, and the report shows it as not treated §9.2.
8.4 How a change request in particular is decided
The plenary shall consider and conclude on each change request independently, and the verdict on each shall be one of the values in that table §4.6.4. Independence matters: a pack is a delivery mechanism, not a single decision, which is exactly what "partially approved" exists to express.
Around the decision sits the paperwork that makes it checkable. The Support Team gives the plenary summary lists of everything presented, updated with each outcome. At the end of the meeting it issues detailed result lists including the new version numbers that follow, and those lists become an annex to the meeting report §4.6.4.
8.5 Deciding between meetings
Plenaries are quarterly, and not everything can wait. Working Groups may take decisions by email for anything they are entitled to decide — specifications, change requests, liaison statements §8.0.
Each group sets its own rules, but two conditions are fixed §8.0: the rules must be clearly defined and written down, and a delegate who attends plenary meetings must be able to tell that they may have missed an email that mattered.
Clauses 8.1 to 8.6 then describe one worked example of such a procedure:
-
M1. Drafting. A discussion is launched, either as a formal "cybermeeting" on a dedicated list or as an informal exchange. For a cybermeeting the chair issues an unambiguous guideline covering the objectives and agenda, the input documents, the start and end dates, and afterwards a summary of the results §8.1.
-
M2. Declaration. Authority for the decision should normally have been agreed at a plenary. If not, a clear notification goes to the main mailing lists saying an email decision will happen, naming the list it will happen on, and giving the target and timeframe. A permanent chair — the group's chair or vice chair — is nominated to run it §8.2.
-
M3. Status reporting. During the period there must be a clear message stating the status of every open item. A weekly summary is recommended, giving the item's name, the responsible delegate, the time left before the deadline, the current document, change request and revision numbers, and the state of play §8.3.
-
M4. Announcement. When a decision is made, a clear notification of what was agreed goes to the main mailing lists of the relevant groups §8.4.
-
M5. Timing. The procedure should start at the latest three weeks before the relevant plenary. The decision period is two weeks, requiring one status report, and the procedure shall be completed one week before the meeting §8.5.
The rule that makes the whole thing work is one line long.
Silence is agreement. The same clause asks for meaningful keywords in the subject line, so a delegate can spot a relevant message in a full inbox, and allows the chair to give clear notice in exceptional cases where the procedure cannot be followed §8.6.
8.6 One caution about the record
Meeting documents on this machine reach back to 1998 by meeting, but not by date. Of the 1,629,581 documents in the record [1], 1,543,057 carry an upload date at all, and those dates run from 2015 onward [9]. The rest can be placed by meeting but not by day.
8.7 Where this leads
Why the documents read the way they do is about the words that end up in the text once the decision has gone through. Reading either body's paper trail from a cold start shows how to walk back from a sentence in a live specification to the meeting that put it there.
Where the numbers in this chapter come from
- 1,629,581 meeting documents recorded rows in table `tdoc` of the pygppe meeting-document database, read from /var/www/whatthespec.net/data/database/api/api.sqlite on 2026-08-04
- 516,786 of them are change requests rows in table `tdoc` where tdoctype='CR', read from /var/www/whatthespec.net/data/database/api/api.sqlite on 2026-08-04
- 159,031 of them are pseudo change requests, for documents not yet under change control rows in table `tdoc` where tdoctype='pCR', read from /var/www/whatthespec.net/data/database/api/api.sqlite on 2026-08-04
- 47,474 of them are liaison statements sent to another group rows in table `tdoc` where tdoctype='LS out', read from /var/www/whatthespec.net/data/database/api/api.sqlite on 2026-08-04
- 11,595 of them are new work item descriptions rows in table `tdoc` where tdoctype='WID new', read from /var/www/whatthespec.net/data/database/api/api.sqlite on 2026-08-04
- 5,532 of them are new study item descriptions rows in table `tdoc` where tdoctype='SID new', read from /var/www/whatthespec.net/data/database/api/api.sqlite on 2026-08-04
- 97,521 meeting documents ended with the status "approved" rows in table `tdoc` where status='approved', read from /var/www/whatthespec.net/data/database/api/api.sqlite on 2026-08-04
- 16,137 meeting documents ended with the status "not pursued" rows in table `tdoc` where status='not pursued', read from /var/www/whatthespec.net/data/database/api/api.sqlite on 2026-08-04
- 1,543,057 of them carry an upload date, running from 2015 to 2026 rows in table `tdoc` whose `uploaded` field starts with a year; the span is the first and last year holding more than 100 rows, which leaves out two stray rows dated before 1910, read from /var/www/whatthespec.net/data/database/api/api.sqlite on 2026-08-04
Check yourself
Answers appear when you pick one, with where they come from.
Q8.1 What is a TDoc?
Clause 9.1 says written contributions to 3GPP meetings are called TDocs, and the note explains that the name is short for Temporary Document, left over from when they were on paper. §9.1
Q8.2 What is the difference between the statuses "approved" and "agreed"?
Table 9.2-1 defines them exactly that way. A working group decision that has to go up to the plenary is "agreed", not "approved". §9.2
Q8.3 A change request pack comes back with the status "partially approved". What does that tell you?
Table 9.2-1 reserves that status for change request packs and defines it in those words. "Treated" is the neighbouring case where nothing in the pack was approved at all. §9.2
Q8.4 In a 3GPP email decision procedure, what happens if nobody comments?
Clause 8.6 states it in one line — if there are no comments during the allowed period, agreement is granted automatically. §8.6
Q8.5 How long is the email decision period, and when must it finish?
Clause 8.5 says the procedure should start at the latest three weeks before the plenary, that the decision period is two weeks with one status report, and that it shall be completed one week before the meeting. §8.5
This chapter was written against TR 21.900 version 20.0.0, and built from a source register generated 2026-08-04. A newer version of the document may say something else.