Every question of this course

Q1.1 What reason does TR 21.900 give for needing strict and fast procedures?

• The documents are too long to review by hand
• The specifications are written by volunteers who come and go
• Industry implements the specifications almost in parallel with the writing of them

The Introduction says the specifications are or will be implemented by industry almost in parallel with the writing of them, and that this requires strict and fast procedures for handling changes. §Introduction

Q1.2 In one sentence, what does the IETF say its goal is?

• To replace vendor protocols with open ones
• To publish the largest possible number of standards
• To make the Internet work better

RFC 3935 opens with exactly that sentence, and everything else in the document hangs off it. RFC 3935, section 1

Q1.3 Why does the 3GPP Support Team register code points with outside bodies rather than a delegate doing it?

• 3GPP is not a legally constituted entity, so the registration is made in the name of an Organizational Partner
• Registration costs money that only the Support Team can spend
• Delegates are not allowed to contact other standards bodies

Clause 3.2 says registration should be entrusted to the Support Team, and that because 3GPP is not a legally constituted entity the Support Team registers in the name of one Organizational Partner on behalf of all of them. §3.2

Q1.4 Which of these does TR 21.900 say it does NOT cover?

• Version control mechanisms
• The details of the internal working of the TSG Sub-Groups
• Change Request procedures

The scope lists document management, updating, Change Requests, version control and status information, and then says the document does not stipulate the details of the internal working of the TSG Sub-Groups. §1

Q1.5 Which is the larger body of text on this machine?

• The 3GPP specification catalogue, at 3,928 documents
• The RFC archive, at 9,735 documents
• They are the same size

The catalogue holds 3,928 3GPP specifications; the archive holds 9,735 RFCs. The two counts measure output volume and nothing else. 9,735 RFCs in the local archive

Q2.1 What is a Working Group, in the words of the definitions clause?

• An official subgroup of a TSG, reporting to that TSG
• A group of member companies sponsoring a work item
• Any gathering of delegates working on one topic

Clause 2 defines a Working Group as an official subgroup of a TSG reporting to that TSG. The word "official" is doing real work — a sub-group below a Working Group is something else again. §2

Q2.2 Who must a specification have, according to the characteristics clause?

• A prime responsible TSG and a rapporteur
• A prime responsible TSG, a secondary TSG and a rapporteur
• A chair and a secretary

Clause 4.2 says the specification has a prime responsible TSG and shall have a rapporteur. The secondary responsible groups and the responsible Working Group are may-clauses, not shall-clauses. §4.2

Q2.3 What is the Mobile Competence Centre?

• The plenary that approves 5G specifications
• The permanent secretariat, or support team, of 3GPP
• The database of member companies

Clause 2 defines it in those words. Everywhere else in the document the same body is called the Support Team. §2

Q2.4 A delegate is appointed rapporteur of a work item. What does clause 6.7 require of them?

• Attendance at every meeting of the responsible group
• A support letter from their company
• Attendance at a 3GPP Compliance Training session, and again at least every two years

Clause 6.7 says a support letter is not required, but that appointed delegates shall attend a Compliance Training session as soon as possible after appointment and at least once every two years during the mandate. §6.7

Q2.5 The meeting calendar on this machine records 27 3GPP bodies with a meeting series of their own. What may you NOT conclude from it?

• That the earliest recorded meeting date is a group's founding date
• That some recorded meetings are in the future
• That SA, RAN and CT each hold their own plenary series

CT's first recorded meeting is 2005 and GERAN's is 2014, yet both are older than that. A first entry in a calendar is the start of the record, not the start of the group. 3GPP CT

Q3.1 How do you tell which Release a specification version belongs to?

• From the specification number
• From the first field of the version number
• From the date it was approved

Clause 4.0B says specifications pertaining to a given Release are distinguished by the first field of the version number, "x" in x.y.z. §4.0B

Q3.2 A serious error is found in a Release that is frozen but not closed. What happens?

• The correction waits until the Release is reopened
• Nothing; a frozen Release takes no more changes
• The correction is made in the frozen Release too, alongside the later ones

Clause 4.10.3.1 says essential changes to old functionality made in a new Release shall also be made to correct the same error in all previous, non-closed Releases. §4.10.3.1

Q3.3 What is a "FASMO" CR?

• A change request for a frequent and serious misoperation — an essential correction
• A change request that mirrors an earlier Release
• A change request that missed the freeze date

The note in clause 4.7 gives that nickname to a correction where a frequently occurring case is not handled properly because of an error or significant ambiguity. §4.7

Q3.4 What is the difference between a closed Release and a frozen one?

• A frozen Release takes essential corrections; a closed one takes no changes of any kind
• There is none; the two words are used interchangeably
• A closed Release is deleted; a frozen one stays available

Clause 2 defines frozen as permitting only essential corrections and closed as permitting no changes of any kind. Clause 4.8 adds that a closed specification stays available for reference. §4.8

Q3.5 A feature will miss the freeze date by one meeting cycle. What does the document offer?

• Automatic carry-over into the next Release
• A shortened approval route for the remaining change requests
• An exception sheet asking the TSG for a delay of one or two meetings

Clause 6.4.5 gives two options — abandon the work or move it to a later Release, or raise an exception sheet requesting a delay until the next or next-but-one TSG meeting. §6.4.5

Q3.6 When was Release 18 frozen?

• This course cannot say; freeze dates live in the 3GPP work plan, which was not read for it
• December 2023
• At the same plenary that approved the first 18.0.0 versions

Clause 4.10.3.4 says the work plan holds the estimated freeze date of forthcoming Releases. The work plan is not among the files read for this course, so no chapter here gives a date for any Release. §4.10.3.4

Q4.1 What version number does a brand new specification start at?

• 0.0.0
• 0.1.0
• 1.0.0

Clause 4.1.1 says that at creation a rapporteur is appointed and produces an initial draft, version 0.0.0, followed by 0.1.0, possibly 0.1.1 and so on. §4.1.1

Q4.2 A draft reaches version 1.0.0. What has just happened to it?

• The plenary approved it
• It was judged stable enough and presented to the plenary for information
• It was put under Working Group change control

Clause 4.1.1 says a sufficiently stable draft is converted to 1.0.0 by the Support Team and presented to the TSG for information. Table 3 in clause 4.0A gives the guideline as roughly 60% stable. §4.1.1

Q4.3 The plenary refuses to approve a version 2.0.0. What happens next?

• The document goes back to 1.y.z
• Further drafts numbered 2.y.z may be produced by the responsible group
• The work item is stopped

Clause 4.1.1 says in as many words that if the TSG does not approve the draft, further drafts version 2.y.z may be produced by the responsible group. §4.1.1

Q4.4 Who edits the text once a specification is under change control?

• Whoever wrote the change request
• The rapporteur
• The Support Team person responsible for the specification

Clause 4.6.1 says that following approval at TSG level the Support Team person responsible for the specification edits the original to incorporate the approved changes. Before change control, the rapporteur serves as editor. §4.6.1

Q4.5 An approved version appears on the 3GPP file server. Has it been published?

• Only if it is a Technical Specification rather than a Technical Report
• Yes, that is what publication means
• No — availability is not publication; the Organizational Partners that are standards bodies publish it as their own standards

Clause 5.1 says such availability does not constitute formal publication, and that under the partnership agreement the Organizational Partners which are standards development organisations publish approved specifications as their own standards. §5.1

Q5.1 Who may raise a Change Request?

• Any individual member, who brings it to the attention of the responsible group
• Any Working Group, by agreement in a meeting
• The rapporteur of the specification

Clause 4.6.1 says a CR may be raised by any individual member and brought to the attention of the responsible group. The rapporteur reviews it; they do not have to originate it. §4.6.1

Q5.2 A change request is rejected. What happens to its number?

• It is released and reused by the next change request
• It is never reused, and a revised proposal has to take a new number
• It is reused only if the specification has fewer than 100 change requests

Clause 4.6.1 says CR numbers shall not be re-used even if a CR is ultimately rejected, and clause 4.6.4 adds that a modified proposal shall get a new number rather than appear as a revision of the rejected one. §4.6.4

Q5.3 Which category letter is used for a change that mirrors one already made to an earlier Release?

• B
• F
• A

Table 4A gives category A for a change corresponding to a change to an earlier Release. B adds or deletes a feature, C modifies one functionally, D is editorial and F is a correction. §4.6.2

Q5.4 How must the proposed text changes be shown?

• As a plain description in the reason field
• As the affected clauses, attached, with the modifications marked in the word processor's revision mode
• As a complete replacement copy of the specification

Clause 4.6.3 requires the affected clauses to be attached, taken from the latest version of the major version, with the proposed modifications clearly marked in revision mode. §4.6.3

Q5.5 What is a pseudo Change Request for?

• A change that only fixes a typing error
• A change that has not yet been agreed by the working group
• New or revised text for a document that is not yet under change control

Clause 2 defines a pCR as similar to a CR but with no CR number, proposing text for documents still in the drafting phase. Some groups call it a text proposal. §2

Q5.6 Two change requests touch the same part of the same specification version. What does the document require?

• The responsible group checks for interaction, so that if both are approved each is implementable without contradicting the other
• The later one must be postponed
• Each must contain the other's proposed changes

Clause 4.6.1 requires that check. Clause 4.6.3 adds the other half — neither change request should contain the other's modifications, though any interaction should be resolved before presentation. §4.6.1

Q6.1 What does "Work Item" cover?

• Any change request with a category of B or C
• Only a feature and its building blocks
• A Study Item, a Feature, a Building Block and a Work Task

Clause 2 defines a Work Item as a description of an enhancement to a technical area which may be categorised as Study Item, Feature, Building Block or Work Task. Clause 6.0.2 works down that ladder. §2

Q6.2 What does every work item require, whatever its size?

• A scope, a schedule and approval by two TSGs
• A feasibility study and a named rapporteur
• A scope, a schedule, a named rapporteur and at least four supporting Member Organizations

Clause 6.0.2 lists exactly those four, and the fourth is the one that decides whether a proposal is real — four Member Organizations willing to offer active participation. §6.0.2

Q6.3 When may substantial work start in a Working Group?

• As soon as four member organisations support the proposal
• Only after the responsible TSG has decided
• As soon as the Working Group has refined the description sheet

Clause 6.1 says no substantial work shall commence in a TSG WG prior to a decision of the responsible TSG. The Working Group may study and refine the description first, but not build on it. §6.1

Q6.4 What does a Study Item produce?

• A Technical Report — a feasibility study, which may be followed by Feature work items
• A change request pack
• A Technical Specification

Clauses 6.0.2 and 6.4.2 both say so — the Study Item is realised as a new Technical Report, and if the results are positive one or more Feature-type work items may follow. §6.4.2

Q6.5 A work item is recorded as "Frozen" in the work plan. What does that mean?

• The item has been approved but not yet started
• Work has stopped without the item being completed
• Work is complete, and only essential changes are permitted using that code

Table 6.5a defines Frozen as approved, completed, 100% in the work plan, with only essential changes permitted under the code. "Stopped" is the state for work abandoned before completion. §6.5

Q6.6 What is a TEI work item code for?

• Items transferred from an earlier Release
• Test and evaluation items
• Technical enhancements and improvements that affect few documents and can be done in one plenary cycle

Clause 6.2 lets small modifications go straight to the plenary as change requests referring to the pseudo work item "Technical Enhancements and Improvements", tagged TEI plus the Release number. §6.2

Q7.1 In version x.y.z, what does the third digit record?

• That purely editorial changes have been incorporated
• Which meeting produced the version
• How many change requests have been approved

The Foreword says z is incremented when editorial only changes have been incorporated, and clause 4.0A adds that it resets to zero whenever the technical field is incremented or reset. §Foreword

Q7.2 A document is at version 0.4.1. What can you say about it?

• It is under Working Group change control
• It is a draft that has never been presented to the plenary for information
• It has been presented for information but not approved

Clause 4.4 says a 0.x.y version is a draft, TSG internal, with no version yet presented to the plenary for information and no major version yet under change control. §4.4

Q7.3 Which specification number range does the numbering scheme reserve for security?

• The 33-series
• The 35-series
• The 32-series

Table 1 of clause 4.0 puts security aspects in 33.bbb. The 32-series is charging and management, and 35.bbb is algorithms. §4.0

Q7.4 What is the difference between an aa.8bb and an aa.9bb Technical Report?

• 8bb reports are working documents not intended for publication; 9bb reports are intended for publication
• 8bb reports belong to GSM and 9bb to UMTS
• 8bb reports are older

Table 2 of clause 4.0 states exactly that. It is the quickest way to tell an internal study from one the partners will publish. §4.0

Q7.5 What does the file name 29341-420.zip mean?

• Specification 293.41, Release 20
• Specification 29.341, version 4.2.0, compressed
• Specification 29.341, the 420th change request

Clause 5A gives that as its first example. The three version characters are base-36 digits, so version 15.35.0 becomes fz0. §5A

Q8.1 What is a TDoc?

• A written contribution to a 3GPP meeting
• A draft of a Technical Specification
• The minutes of a meeting

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"?

• Approved means the deciding group has the final say; agreed means a higher body still has to confirm it
• Agreed applies to change requests, approved to everything else
• Approved is used at plenary level, agreed at working group level, and nothing else follows from it

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?

• Some change requests in it were approved; others may be revised, postponed or not pursued
• Only the cover sheet was approved
• The pack was approved but with amendments

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?

• Agreement is granted automatically
• The chair must ask each participant directly
• The item is postponed to the next meeting

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?

• One week, finishing on the first day of the plenary
• Two weeks, finishing one week before the relevant plenary
• Three weeks, finishing when the plenary opens

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

Q9.1 Which verb makes a 3GPP sentence a requirement from which no deviation is permitted?

• will
• must
• shall

The drafting rules reserve one set of verbal forms for requirements strictly to be followed, and in 3GPP practice that is "shall". "Must" is not used, so that a standard is not mistaken for a law. TR 21.801, Annex E

Q9.2 What does "should" carry in a 3GPP document?

• A statement of fact about how the system behaves
• A requirement expressed politely
• A recommendation — one possibility preferred among others, without excluding them

The drafting rules define the "should" forms as marking one possibility as particularly suitable without excluding others, or a course of action preferred but not required. TR 21.801, Annex E

Q9.3 Clause 4.5 of TR 21.900 reads "(void)". Why is it there at all?

• The clause is still being written
• The content was removed, and the number is kept empty rather than given to something else
• It is a printing error in the parsed copy

The document keeps emptied numbers as markers so that every other clause number stays where it was. Clause 4.9B.1 and table 5 are the same case, and change request category E is marked "not used" for the same reason. §4.5

Q9.4 Where are the rules for drafting a 3GPP specification, and the permitted software tools?

• In TR 21.900 itself
• In TR 21.801, the drafting rules
• In the 3GPP Working Procedures

Clause 4.1.1 points at TR 21.801 for the drafting rules, and clause 7.5 points at the same document for the permitted word processors. §7.5

Q9.5 A change moves only the third digit of the version number. What kind of change was it?

• A correction agreed by the working group
• A purely editorial fix made by the Support Team
• A mirror of a change made in another Release

Clause 4.6.6 lets the Support Team correct purely editorial defects, incrementing only the editorial field, and says such changes should normally be held over until the next technical change. §4.6.6

Q10.1 Who is a member of the IETF?

• Any company paying the annual fee
• Nobody — there is no formal membership, and participation is open to all
• Any organisation nominated by a national standards body

RFC 2418 states it in two sentences — there is no formal membership in the IETF, and participation is open to all. RFC 2418, section 1

Q10.2 What is the IESG?

• The area directors sitting as a body, along with the IETF Chair
• The editorial board of the RFC series
• The committee that allocates protocol numbers

RFC 2418 defines it that way, and RFC 2026 makes the IESG the body that approves IETF standards actions. RFC 2418, section 1

Q10.3 How is IETF work organised below the level of the whole body?

• Into per-protocol committees appointed by the IESG
• Into working groups, which are collected into areas, each run by one or two area directors
• Into technical specification groups with working groups beneath them

RFC 2418 describes that structure. It is the closest thing the IETF has to 3GPP's plenary-and-working-group ladder, and it is deliberately flatter. RFC 2418

Q10.4 How does a reader tell which of the four streams an RFC came from?

• From the IETF website
• From the RFC number range
• From the boilerplate in the document's own header block

RFC 7841 defines the headers and boilerplate that state the stream, so an independent submission can be told from an IETF standard without leaving the page. RFC 7841

Q10.5 Why does this course give no current count of IETF working groups or areas?

• The IETF does not publish them
• The numbers change too often to be useful
• No local file holds them; the only figures available here are from RFC 2418, written in 1998

RFC 2418 spoke of more than 100 working groups and 8 areas at the time it was written. Nothing read for this course gives today's figures, so the document is quoted as history and not as fact. The current list is on the IETF website. RFC 2418

Q11.1 What formal status does an Internet-Draft have?

• None; it may be changed or removed at any time and is not a publication
• The status of a draft standard until the IESG says otherwise
• The status its working group gives it

RFC 2026 says an Internet-Draft is not a means of publishing a specification, that drafts have no formal status, and that they are subject to change or removal at any time. RFC 2026, section 2.2

Q11.2 What happens to a draft that sits unchanged for more than six months and has not been recommended for publication?

• Its working group must vote to keep it
• It is archived as Historic
• It is simply removed from the Internet-Drafts directory

RFC 2026 sets that expiry. It is why a draft's file name carries a version number and why people speak of a draft "expiring". RFC 2026

Q11.3 Who may comment during an IETF-wide Last Call?

• Members of the working group that produced the document
• Anyone
• The IESG and the IAB

RFC 2026 says the IESG issues the Last Call by email and comments are accepted from anyone. That openness is the counterpart of having no formal membership. RFC 2026

Q11.4 What is the entry level of the IETF standards track?

• Internet Standard
• Draft Standard
• Proposed Standard, and a specific action by the IESG is required to put a document there

RFC 2026 says the entry-level maturity is Proposed Standard and that a specific IESG action is required to move a specification onto the track at that level. RFC 2026, section 4.1.1

Q11.5 How many maturity levels does the standards track have today?

• Three, as RFC 2026 defined them
• Two — RFC 6410 replaced the three-tier ladder with a two-tier one
• One, since the levels were abolished

RFC 6410 says in as many words that it replaces the three-tier maturity ladder defined in RFC 2026 with a two-tier ladder of Proposed Standard and Internet Standard. RFC 6410, section 2

Q11.6 A published RFC turns out to need a change. What happens?

• The RFC Editor issues a corrected version under the same number
• A new document goes through the whole process again, and the old one usually becomes Historic
• The working group publishes an erratum that amends the text

RFC 2026 says an RFC is never edited after publication, and that a new version of a standard must go through the full process as if it were new. RFC 2026

Q12.1 What does the IETF's best-known sentence say it rejects?

• Committees, chairs and minutes
• Vendors, patents and closed meetings
• Kings, presidents and voting

RFC 7282 quotes the credo in its first section, rejecting kings, presidents and voting in favour of rough consensus and running code. RFC 7282, section 1

Q12.2 Can a chair declare rough consensus while somebody is still objecting?

• Yes, if the objection has been truly considered and the group has made an informed decision that it has been answered or is not enough of a problem
• Only if the objector agrees to the declaration
• No; consensus means every objection has been withdrawn

RFC 7282 describes exactly that — the chair may declare rough consensus to go forward, the objection notwithstanding. RFC 7282, section 1

Q12.3 Does 51% of a working group count as rough consensus?

• No — RFC 2418 says 51% does not qualify and 99% is better than rough
• There is no stated threshold either way
• Yes, a simple majority is the threshold

RFC 2418 says both of those things in the same breath, and then says it is up to the chair to determine whether rough consensus has been reached. RFC 2418, section 3.3

Q12.4 Does IETF consensus require everybody to agree?

• No, although that is preferred
• Only for standards track documents
• Yes, that is what consensus means

RFC 2418 says working groups make decisions through a rough consensus process, and that IETF consensus does not require that all participants agree although this is, of course, preferred. RFC 2418, section 3.3

Q12.5 Why does a chair ask a room to hum?

• To speed up a decision when time is short
• So the sense of the room can be taken without a show of hands, which would look too much like a vote
• Because remote participants cannot see raised hands

That is the reason RFC 7282 gives. Humming registers a direction and a strength without producing a countable tally. RFC 7282

Q13.1 What does MUST mean in an RFC?

• A requirement, unless the implementer documents a reason not to
• The strongest recommendation the authors could make
• An absolute requirement of the specification

RFC 2119 says MUST, and the terms REQUIRED and SHALL, mean that the definition is an absolute requirement of the specification. RFC 2119, section 1

Q13.2 What does SHOULD allow?

• Ignoring the item with the working group's permission
• Ignoring the item freely
• Ignoring the item where there are valid reasons, once the full implications have been understood and carefully weighed

RFC 2119 defines SHOULD, and the adjective RECOMMENDED, in exactly those terms. The permission is real but it comes with an obligation to think. RFC 2119, section 3

Q13.3 A protocol document uses the word "must" in lower case. What does it carry?

• A requirement, but only for the reference implementation
• The same absolute requirement as MUST
• Nothing special; only the uppercase usage has the defined meaning

RFC 8174 updates RFC 2119 by clarifying that only UPPERCASE usage of the key words has the defined special meanings. RFC 8174, section 1

Q13.4 Which word does 3GPP ban outright, and which does the IETF make its strongest?

• Both ban "must"
• 3GPP bans "must"; in the IETF, MUST is the absolute requirement
• 3GPP bans "may"; the IETF makes MAY optional

3GPP uses "shall" for a requirement and "should" for a recommendation, and does not use "must", so a standard is not mistaken for a law. RFC 2119 makes MUST the absolute requirement and lists SHALL as one of its synonyms. RFC 2119, section 1

Q13.5 What is the relationship between REQUIRED, SHALL and MUST?

• REQUIRED applies to fields, SHALL to behaviour, MUST to both
• They are three different strengths, in that order
• They mean the same thing

RFC 2119 gives them in one breath — MUST, or the terms REQUIRED or SHALL, mean the definition is an absolute requirement. RECOMMENDED pairs with SHOULD and OPTIONAL with MAY in the same way. RFC 2119, section 1

Q14.1 Where do the two rulebooks touch directly?

• The IETF cites 3GPP's drafting rules for its style guide
• Both bodies share the IANA registry procedure document
• 3GPP's working methods require OpenAPI files to be stored in UTF-8 as specified in IETF RFC 3629

Clause 5B of TR 21.900 says the stand-alone file is made available in UTF-8 format as specified in IETF RFC 3629, which appears as reference 7 in TR 21.900's own reference list. §5B

Q14.2 How does each body settle a decision taken between meetings?

• Both require an explicit reply from every participant
• 3GPP grants agreement automatically if nobody comments; the IETF runs a Last Call open to anyone
• 3GPP uses a Last Call; the IETF requires a plenary

Clause 8.6 grants agreement automatically in the absence of comment. RFC 2026 has the IESG issue an IETF-wide Last Call by email with comments accepted from anyone. §8.6

Q14.3 What happens to a published document that needs changing, in each body?

• 3GPP issues a new version of the same document; the IETF publishes a new document and usually makes the old one Historic
• Both require the original authors to consent
• Both issue a corrected version under the same identifier

Clause 4.6.5 has the Support Team issue a new version of the same specification. RFC 2026 says an RFC is never edited after publication and a new version must go through the whole process as if it were new. §4.6.5

Q14.4 Which comparison does this course refuse to make, and why?

• Which body has more working groups, because the lists are in different formats
• Which requirement words are stronger, because the definitions differ
• Which body is faster, better or more open, because nothing in the data supports it

The counts here measure output volume and nothing else. No file read for this course says anything about speed, quality or openness, so no chapter here compares them. 3,928 3GPP specifications in the catalogue

Q14.5 What does each body require before a document reaches its highest status?

• Both require multiple independent implementations
• 3GPP requires plenary approval; the IETF's Internet Standard requires multiple independent interoperable implementations with operational experience
• Both require only a decision by the responsible body

Clause 4.1.1 makes approval a decision of the TSG. RFC 2026 makes implementation experience part of the definition of an Internet Standard. §4.1.1

Q15.1 Where does a 3GPP specification record which change requests changed it?

• In the portal only
• In its own change history annex, naming the change request, the meeting and the resulting version
• In the meeting report of the plenary that approved it

Clause 4.6.6 requires all such changes to be clearly explained in the change history annex of the specification, and TR 21.900's own Annex A is an example of one. §4.6.6

Q15.2 You have the file name 23501-k20.zip and nothing else. What have you got?

• Specification 235.01, part 20
• Change request 20 against specification 23.501
• Specification 23.501, version 20.2.0, compressed

Clause 5A packs the specification number and the three version characters into the name, base 36, so k is 20 and the version reads 20.2.0. §5A

Q15.3 Which of these does the Support Team maintain, according to clause 7?

• Only the change request database
• The specifications and the meeting minutes, but no databases
• The Status List of Specifications, the Work Item Status List and the change request database

Clause 7 lists all three, along with the membership databases, the permitted tools, the web and file services, and the email lists. §7

Q15.4 How do you tell what an RFC is before reading it?

• From its own header block, which gives the category, the stream, any BCP or STD number, and what it obsoletes or updates
• From the IETF website's index
• From the number range it falls in

RFC 7841 defines those headers and boilerplates. Reading them first is the fastest way to tell an Internet Standard from an independent Informational submission. RFC 7841

Q15.5 Every count on this site carries a method. What is that for?

• So the number can be dated for copyright purposes
• So the number can be recalculated by anybody who wants to check it
• So the site can be rebuilt from scratch

Each count entry in the register records the exact query that produced it and the day it was asked, so a reader can ask the same question again rather than trust the figure. 1,629,581 meeting documents recorded

Q16.1 Why does this course name no Organizational Partner?

• No file read for it lists them; the working methods mention the partners without naming any
• The list is confidential
• Naming them would date the course

TR 21.900 refers to the Organizational Partners in clauses 3.2 and 5.1 and the calendar records that they meet, but nothing read here says who they are. The 3GPP Working Procedures is where to look. §3.2

Q16.2 Where would a Release freeze date come from?

• The change history annex of any specification of that Release
• The 3GPP work plan, which was not among the files read for this course
• The version number of the first x.0.0 document

Clause 4.10.3.4 says the work plan shall indicate the estimated freeze date of forthcoming Releases and the functional content of each. No chapter here gives a date, because the work plan was not read. §4.10.3.4

Q16.3 The meeting calendar's latest entries are in 2028. What does that mean?

• The calendar holds scheduled meetings as well as held ones
• Some meetings are recorded years after they happen
• The record was generated with an error

The calendar carries future meetings, so the last date in a series is not the most recent meeting. It is also why a first recorded date is not a founding date. 4,371 of them are 3GPP meetings, from 1998-12-07 to 2028-06-13

Q16.4 Which working groups does TR 21.900 itself name?

• SA1, SA2 and SA3, in passing, while explaining the work item model, plus the TSGs CT and RAN
• None
• All of them, in the numbering scheme clause

Clause 6.6 uses TSG SA as its illustration and names those groups. Every other group name in this course comes from the meeting calendar, not from a specification. §6.6

Q16.5 Why does this course quote no sentence from RFC 8729 or RFC 9280?

• They are too recent to be settled
• They are in the local archive only as XML, so the course names them and takes no sentence from them
• They are not part of the standards process

The archive holds 8,457 RFCs as plain text and 1,278 as XML. Those two are in the XML half, so the register records them without a quotation. 1,278 of them are XML, numbered 8650 to 9953