280 likes | 297 Views
The lonely road or How a spec gets from WG Secretary to the server, and how it gets published as an ETSI deliverable. So, you have learnt how a specification is updated via CRs and edited by the WG Secretary. If you haven’t, then read this first: http://www.etsi.org.
E N D
The lonely roadorHow a spec gets from WG Secretary to the server, and how it gets published as an ETSI deliverable
So, you have learnt how a specification is updated via CRs and edited by the WG Secretary. If you haven’t, then read this first: http://www.etsi.org Now get a fascinating insight into the adult phase of a spec’s life cycle.
The WG Secretary sends the updated new spec to the Specifications Manager – normally by e-mail.
The Specifications Manager extracts the spec (or specs) from the e-mail ...
…and files the incoming specs by date and by provider in a holding area.
The presence of any necessary ancillary files (ASN.1, C code, ATS TTCN, PICS, …) is checked.
If the Specifications Manager is not satisfied that the spec is correct in these respects …
… the MCC database record is updated to show that the spec exists.
…and on to the external file server: http://www.3gpp.org/ftp/Specs/2000-12/R1999/24_series/
…if the spec is to be published by the SDOs (i.e. it pertains to a frozen release), it is converted to PDF format*: * The ETSI route is shown.
Its subsequent treatment in ETSI is described in a separate presentation.
In addition, its version-specific record in WPM is created and details filled in:
And so to the next spec … last slide