1. The lifecycle of a GSM spec Or All you ever wanted to know about where little GSM specs come from.

2. In the beginning was a GSM spec.

3. 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.

4. We will forget about the “internal” copy of our spec for now, on the basis that it exactly mirrors what is visible on Docbox.

5. Our spec leads a tranquil existence until... … along comes a delegate with a good idea.

6. He downloads the spec... …. and creates a CR proposing some changes.

7. The CR is approved by the working group. And by the plenary TC or TSG.

8. 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

9. The new offspring version of the spec then replaces its parent on the server.

10. 7.5.0 The parent, its useful life over, is removed from the server and is sent for all eternity to the archive directory.

11. But there’s more... 7.6.0 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...

12. Consider spec number 04.51 version 7.6.0, as newly created by the MCC member. 7.6.0 Filename 0451-760 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. 7.6.0 Filename 0451_760 But it has a new filename!

13. 7.6.0 0451_760 The new instance (of the same version) of the spec then replaces its elder sibling on the server.

14. 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.

15. 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.0 0451_760

16. 7.6.0 0451_760 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

17. 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.

18. 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.

19. So, the process in summary...

20. 0451_750 Original spec.

21. 0451_750 Create CR. 1

22. Approve CR. 0451_750 12

23. Implement CR. 0451_7500451-760 213

24. 0451_7500451-760 New version to server. 1234

25. 0451_7500451-760 Send to SMS Dept. 0451-760 12345

26. 0451_7500451-760 Create ETSI instance. 0451-760 12345 0451_760 6

27. 0451_7500451-760 New instance to server. 0451-760 12345 0451_760 67

28. 0451_7500451-760 OAP 0451-760 12345 0451_760 67 8 0451_761 (4 months +)

29. 0451_7500451-760 New version to server. 0451-760 12345 0451_760 67 8 0451_761 9

30. New original spec. 0451_761 And so the cycle continues from generation unto generation.