The lifecycle of a GSM spec Or All you ever wanted to know about where little GSM specs come from.
The spec lived in a Directory with a lot of other specs. In fact, the spec lived a somewhat schizoid existence, because it had an alter-ego which was visible to ETSI members who came to call on Docbox.
We will forget about the “internal” copy of our spec for now, on the basis that it exactly mirrors what is visible on Docbox.
Our spec leads a tranquil existence until ... … along comes a delegate with a good idea.
He downloads the spec ... …. and creates a CR proposing some changes.
The CR is approved by the working group. And by the plenary TC or TSG.
The responsible MCC member then edits the original spec, changing it in accordance with the modifications shown in the agreed CR (or CRs). The specification gets a new version number... 7.5.0 7.6.0
7.6.0 The new offspring version of the spec then replaces its parent on the server.
7.5.0 The parent, its useful life over, is removed from the server and is sent for all eternity to the archive directory.
7.6.0 But there’s more ... The new version of the spec is sent for processing by the ETSI Secretariat. It now becomes necessary to distinguish between two manifestations of (the same version of) the spec...
Filename 0451-760 7.6.0 7.6.0 Consider spec number 04.51 version 7.6.0, as newly created by the MCC member. The file is processed by ETSI Secretariat (SMS Dept) and, within a few days, returned to MCC. It is identical except for its Foreword, its History box, and possibly some minor editorial clean up. Filename 0451_760 But it has a new filename!
7.6.0 0451_760 The new instance (of the same version) of the spec then replaces its elder sibling on the server.
7.6.0 0451-760 The elder sibling, its brief but possibly useful life over, is removed from the server and is sent for all eternity to the archive directory.
7.6.0 0451_760 7.6.0 0451-760 Because the ETSI-processed instance is technically and textually identical to the ex-MCC instance, it does not matter which instance is used by delegates to create the next round of CRs.
7.6.0 0451_760 7.6.1 0451_761 If the deliverable type of the ETSI instance is an EN (rather than a TS or a TR), it will be sent for approval by the National Standards Organizations (NSOs). At the end of the combined Public Enquiry and Vote (‘One-step Approval Procedure’), the document undergoes minor editorial modifications to its cover page, Foreword and History, and is published. The new instance is given a new version number by incrementing the last (editorial) field, and corresponding filename.
7.6.1 0451_761 As long as version 7.6.0 has not already been superseded by 7.7.0 during the four months of the national approval process, the new version of the spec again replaces its step-brother on the server.
7.6.0 0451_760 The foster brother, its four or five month life over, is removed from the server and is sent for all eternity to the archive directory.
0451_750 Original spec.
1 0451_750 Create CR.
1 2 0451_750 Approve CR.
2 1 3 0451_750 0451-760 Implement CR.
1 2 3 4 0451_750 0451-760 0451-760 New version to server.
1 2 3 4 5 0451_750 0451-760 0451-760 0451-760 Send to SMS Dept.
1 2 3 4 5 6 0451_750 0451-760 0451-760 0451-760 0451_760 Create ETSI instance.
1 2 3 4 5 6 7 0451_750 0451-760 0451-760 0451-760 0451_760 0451_760 New instance to server.
4 8 7 6 1 2 3 5 0451_761 0451-760 0451-760 0451_760 0451_750 0451_760 0451-760 OAP (4 months +)
4 1 9 3 2 6 7 8 5 0451_750 0451_761 0451-760 0451_760 0451-760 0451_760 0451-760 0451_761 New version to server.
0451_761 New original spec. And so the cycle continues from generation unto generation.