3GPP 21.900 v20.0.0 — the document's own text
4.6.1 Change Requests
Taught in 5. The Change Request, field by field (How standards actually get made, in depth), 4. The change request and the release (How standards actually get made, overview), 6. Two ways of deciding (How standards actually get made, overview), 3. One idea, from proposal to published text (How standards actually get made, quick start).
Once a specification has been approved by the TSG and version x.0.0 (where x >= 3, corresponding to the Release - see table 4) has been produced, it shall be considered to be under change control. Any technical change which may be identified for inclusion in the specification from this point on shall be accomplished by means of a Change Request (CR).
A CR may be raised by any individual member and brought to the attention of the responsible Group.
A Change Request shall relate to a specific version of a specification. A unique (for that specification) reference number shall be allocated to the CR by the 3GPP portal or the Support Team. CR details shall be entered into a CR database maintained by the Support Team and made available on the 3GPP file server. CR numbers shall not be re-used, even if a CR is ultimately rejected by the TSG (see note). A CR may undergo one or more revisions before a final decision is made on it. The database shall show all revisions of each CR.
NOTE: The CR status "rejected", and indeed this status for any other TDoc type has become unacceptable in some groups, and is replaced by "not pursued". Unless evident from the context, in the present document, any reference to the status "rejected" applies equally to status "not pursued".
The TSG WG Secretary shall collate all CRs agreed by the WG and shall send them to the parent TSG for approval. For specifications which are directly under the control of a TSG, the CR shall be brought directly to the attention of the TSG.
Following approval at TSG level, the Support Team person responsible for the specification shall edit the original specification to incorporate the changes of all Change Requests approved by the TSG. The new version of the specification shall then be made available on the 3GPP file server.
The TSG should approve, reject or postpone a CR in its entirety (after revision, if necessary). That is, the modifications proposed by the CR should either be accepted without change, or unconditionally rejected. For ease of management, a single Change Request should therefore pertain to a single technical topic only. Each topic can thus be cleanly accepted or rejected by the TSG.
Where two or more CRs pertain to the same (version of a) specification, the responsible Group shall check for potential interaction amongst those CRs to ensure that, if all are approved by the TSG, each is implementable without contradicting any other.
The TSG Secretary shall record the TSG's decisions (see table 9.2-1) on each CR in the meeting report and those decisions shall be reflected in the CR database and on the 3GPP portal.