The lifecycle of a GSM spec

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
The parent, its useful life over, is removed from
the server and is sent for all eternity to the
archive directory.
11
But theres 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...
12
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!
13
The new instance (of the same version) of the
spec then replaces its elder sibling on the
server.
14
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.
16
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.
17
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
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
Original spec.
21
Create CR.
22
Approve CR.
23
Implement CR.
24
New version to server.
25
Send to SMS Dept.
26
Create ETSI instance.
27
New instance to server.
28
OAP
(4 months )
29
New version to server.
30
New original spec.
And so the cycle continues from generation unto
generation.