4.6.4 Handling of the Change Requests

Entry to the TSG WG:

A proposed CR should be brought to the relevant Group primarily responsible for the specification concerned and discussed there, before presentation to the TSG. Comments from secondarily responsible Groups (if any) shall have been sought and comments shall have been taken into account before presentation to the TSG for approval.

To ease the work of the Group and of the Support Team , a proposed CR should be presented in a form suitable for TSG WG agreement and TSG approval. If a CR is not immediately accepted the originator shall update the CR taking into account comments and other guidelines from the relevant groups, including change of reference version if needed, and to re-present it to the Group.

All CRs shall be presented in electronic form.

CR identification:

During the course of its development, a CR may be modified, and the CR's progress shall be indicated by allocation of a revision number: rev. 1, 2, and so on. A given revision of a CR is uniquely defined by

• the specification to which it belongs, and
• the CR number (an alphanumeric string) and
• the revision number (default, i.e. the value if no number is given, is '-', i.e. the original, unrevised, CR).

A CR number shall be allocated by the 3GPP portal or the Support Team. For a given Specification, CR numbers shall be unique and shall never be reused (see clause 4.6.1). Numbers used for rejected CRs shall not be reused. If a CR is rejected, and the responsible Group considers it useful to bring a modification of the CR to a subsequent TSG for approval, the new CR shall be allocated a new CR number. That is, it shall not be presented as a revision of the same CR number previously rejected.

Impact on other specifications:

If the content of the CR is such that, in isolation, it makes the whole set of approved Specifications inconsistent, corresponding CRs shall also be considered and produced. This should be carried out by the originators of the CR (and their colleagues in other Groups) in advance. The Support Team is co-responsible for identifying and communicating cross-TSG and cross-TSG-WG impacts.

If a CR (or set of CRs) causes an inconsistency with an existing/approved test or O&M specification, the corresponding CRs should be presented together with the core specification CR in the same TSG cycle. Otherwise they may follow in a later TSG cycle.

Handling of the CR in the TSG:

When the TSG WG has agreed to a CR and comments from secondarily responsible Groups (if any) have been taken into account, the Support Team shall ensure that it is correctly formatted and assembled, and shall submit the CR to the primarily responsible TSG for formal approval.

The Support Team shall collate agreed CRs in CR packs.

The Support Team shall make available to the TSG summary lists of all CRs presented for decision. This list shall be updated to show the decision reached for each and every CR.

Decisions on CRs, and results:

The TSG shall consider and conclude on each CR independently; the verdict on each CR shall be one of the values listed in clause 9.2

Table 5: (void)

Control and notification of CR decisions:

At the end of each TSG meeting, the Support Team shall issue lists containing the detailed result of the CRs presented at the meeting, including information about the consequential new version numbers of the concerned specifications. These lists shall form an annex to the meeting report (and hence are part of a permanent document). These lists, being the evidence of which specifications have changed and how, are important management tools for both TSG delegates and the Support Team since it takes some time before the new versions of the specifications can be compiled and released.