School of Specs Inside one plenary: TSG SA#112Quick start

Reading it yourself · chapter 3 of 4 · 3 minutes

3 How to read one document of it, end to end

Four things to read about any document at a plenary, worked through on the most argued-over paper of this meeting, plus the two traps that catch everybody.

3.1 Four things to read

The meeting keeps a list of every document, and for each one it records the same four facts [3]:

  • Which agenda item it was filed under — that is where in the meeting it belongs

  • What type it is — a change request, a proposal to start work, a report, a letter

  • Who sent it — a working group, a company, or a body outside 3GPP

  • What the result was — one of the ten status words

Read those four and you know what was asked and what was answered. Everything else is detail.

3.2 One document, worked through

Take the meeting's long argument: a new work item on an AI-based speech codec for voice over satellite.

It has two document numbers, and that is the first thing to notice. The first version was revised — meaning it was replaced by a new number SP-260417. The replacement was approved SP-260696.

The report puts it in four words.

WID is 3GPP's short form for a work item description — the paper that proposes a piece of work and asks for it to be started.

3.3 What approval did not settle

The approval is not the whole story, and the record says so in the next sentence. The question of where the data to train the model may come from was not answered in the room.

PCG is the Project Co-ordination Group — a body above this meeting. The work was approved and the hard question was sent upstairs, both at once.

3.4 Two traps

A document number can hold many changes. SP-260379 is a single number carrying 23 separate change requests SP-260379. 120 of this meeting's documents were packs like that [4], which is why 346 documents contain 689 individual changes [5].

A pack can be split. SP-260387 came out partially approved: some of the changes inside it went through and some did not SP-260387. Four documents at this meeting ended that way [6].

Between them these two traps account for most wrong statements about what a plenary approved.

3.5 A second document, read the same way

Letters work the same way, and they are the easiest thing in a plenary to follow from end to end.

ETSI TC EMTEL — a group outside 3GPP — wrote in about accessibility parameters in emergency communications. That incoming letter ended the meeting "replied to", the only document of the 346 to do so SP-260363, [7].

The reply is its own document, and it was approved SP-260655.

A second draft of the same reply had also been written, by a different company. It ended merged — folded into the one that went out SP-260613.

Three documents, three different result words, one exchange of post. Almost every other incoming letter that week was simply noted — one of the 68 documents that ended the meeting on that word [8].

3.6 Reading the outcome honestly

Three sentences are safe to build from a document's row in the list:

  • "SP-260696, a new work item description, was approved at SA#112."

  • "SP-260417, the earlier version of the same work item, was revised."

  • "The draft report of the meeting records that the training-data question was passed to the Project Co-ordination Group."

The third one names its source for a reason. The report this all comes from is version 0.0.5 and its cover reads "Status: Draft - for comment" [9].

Where the numbers in this chapter come from

  1. 'This new WID was approved.' found character for character in SP-112_Draft_Report_v005.md, which is a draft and says so on its cover, read 2026-08-04
  2. 'TSG SA Chair to inform PCG on this issue of 3GPP involvement and legal requirements related to the dataset needed to train the AI model specific to 3GPP work.' found character for character in SP-112_Draft_Report_v005.md, which is a draft and says so on its cover, read 2026-08-04
  3. TdocsByAgenda, the SA#112 document list
  4. 120 documents of type 'CR pack' sqlite3 /var/www/whatthespec.net/data/database/api/api.sqlite "select count(*) from tdoc where meeting='SP-112' and tdoctype='CR pack';", read 2026-08-04
  5. 689 individual change requests the crspec column of every CR and CR pack row of tdoc for meeting='SP-112', split on spaces and counted. Each token is one change request against one specification, read 2026-08-04
  6. 4 documents ended the meeting 'partially approved' sqlite3 /var/www/whatthespec.net/data/database/api/api.sqlite "select count(*) from tdoc where meeting='SP-112' and status='partially approved';", read 2026-08-04
  7. 1 document ended the meeting 'replied to' sqlite3 /var/www/whatthespec.net/data/database/api/api.sqlite "select count(*) from tdoc where meeting='SP-112' and status='replied to';", read 2026-08-04
  8. 68 documents ended the meeting 'noted' sqlite3 /var/www/whatthespec.net/data/database/api/api.sqlite "select count(*) from tdoc where meeting='SP-112' and status='noted';", read 2026-08-04
  9. SP-112 draft meeting report, version 0.0.5

Every source this course is built on

Check yourself

Answers appear when you pick one, with where they come from.

Q3.1 What are the four things to read about a document at a plenary?

Q3.2 SP-260417 was revised and SP-260696 was approved. What is the relationship?

Q3.3 SP-260379 is one document number. How many change requests does it carry?

Q3.4 A pack ends the meeting "partially approved". What does that tell you?

This chapter was built from a source register generated 2026-08-04. A fresher build of the register may hold different numbers.