The lifecycle of a GSM spec

Or
All you ever wanted to know about
where little GSM specs come from.
In the beginning was a
GSM spec.
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
The new offspring version
of the spec then replaces its
parent on the server.

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

7.5.0
But there’s more ...

The new version of the spec is sent

for processing by the ETSI
Secretariat.
7.6.0

It now becomes necessary to

distinguish between two
manifestations of (the same version
of) the spec...
Consider spec number 04.51 version 7.6.0, as
newly created by the MCC member.

Filename 0451-760

7.6.0

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

7.6.0

But it has a new filename!

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

National Standards Organizations 0451_760

(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
7.6.1
the server.
0451_761
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.

7.6.0
0451_760
So, the process in summary ...
 Original spec.
0451_750
Create CR.

0451_750
 2

Approve CR.
1

0451_750
 Implement CR.
2 3

0451-760

0451_750
 2 3

0451-760

4
1

0451_750
New version to server.
0451-760
 2 3

0451-760

4 5
1 Send to SMS Dept.

0451_750

0451-760
0451-760
 2 3

0451-760

4 5
1

0451_750

0451-760
0451-760
6
Create ETSI instance.

0451_760
 2 3

0451-760

4 5
1

0451_750

0451-760
0451_760 7 0451-760
6

New instance to server.

0451_760
 2 3

0451-760

4 5
1

0451_750

0451-760
0451_760 7 0451-760
6

0451_760

OAP 8
(4 months +)

0451_761
 2 3

0451-760

4 5
1

0451_750

0451-760
0451_760 7 0451-760

0451_761 6

0451_760
New version to server.
8
9

0451_761
 New original spec.

0451_761

And so the cycle continues from

generation unto generation.