Overview of ETSI Standards Development Process

Introduction

This post aims to share information about the ETSI Standards development process to people who are unfamiliar with the work ETSI does. Also, I add my own insights from my experience of the work at ETSI though it is limited at the moment but should still prove useful.

Steps

The objective of the ETSI Standards Making Process (SMP) is to convert market needs for standardisation in the ICT area into ETSI deliverables (specifications, standards, norms, guides, reports) used in the market place.

The input to the process is an existing (as yet known or unknown) market need for standardization. The output is the broad application of the produced deliverables in the market place.

The SMP consists of several elements with their own distinct objectives, inputs and outputs. Each process is defined to the level of which operational tasks are performed, and wherein the ETSI organisation they are performed.

The whole ETSI organization is in one way or the other involved in either operation of the SMP or in direct or indirect support of it. The main technical activities are performed in the Technical Bodies of the Technical Organization. The main direct support for those activities is provided by ETSI Operations (OPS) Division of the ETSI Secretariat.

The operation of the SMP in the Technical Organization is governed by the ETSI Directives, in particular the Technical Working Procedures, and the ETSI Drafting Rules. The processes, tasks and procedures of the ETSI Secretariat are governed by the Secretariat's Quality Management System documentation, notably that of ETSI Operations (OPS) Division.

Inception

[inception - an act, process, or instance of beginning (as of an institution, organisation, or concept)]

The times when initiatives to standardisation were taken only when products and services were already available are since long gone. This is particularly the case for telecommunications where standardization precedes or goes hand in hand with the design and development processes.

The input to this sub-process is "what's going on in the marketplace", with "marketplace" having a broad interpretation, including development in the research and academic circles.

The output is a new standardization area, given to an existing or a new Technical Body. The formal output is the Terms of Reference (ToR) and/or a Project Requirements Definition (PRD) document, approved by the ETSI Board or, in the case of an ETSI Partnership Project with an external organisation, approved by the ETSI General Assembly.

Conception
[conception - the capacity, function, or process of forming ideas or abstractions or of grasping the meaning of symbols representing such ideas or abstractions; an idea or general notion; the originating of something (as an idea or plan) in the mind]

The creation of a new standardization area or ISG is manifested by the establishment of the new Technical Body or the amendment of the Terms of Reference of the Project Requirements Definition of an existing.

The identification, definition, approval and adoption of work items are the main elements of the conception phase (even if work items may have been envisaged already during the inception process).

The input is identified by standardisation needs in the area. These work items may either be entirely new, leading to new deliverables, or a new version of an existing deliverable ("maintenance work item"). The output is a work item, adopted by the ETSI Membership.

A proposal for a work item may come from inside or outside the Technical Body. The Technical Body may approve the work item if at least four ETSI Members volunteer to support the work. The adoption is formally done by the ETSI Membership (the existence of new work items is made known via the ETSI Web site and Members who disagree with the item may within a 30 day period oppose its adoption into the ETSI Work Programme.

Drafting

[drafting - pres part of draft - to make a preliminary or tentative version, sketch, or outline (as of  literary composition or other documents)]

A work item in the ETSI Work Programme is intended to lead to one (or more) ETSI deliverable(s).

A Technical Body is free to organise its work in any way it wishes, within the rules of the Technical Working Procedures, including creating Working Groups to which the tasks of drafting parts of the Technical Body's work programme are given.

The drafting usually takes place in a small team (Rapporteur Group) led by a Rapporteur. The work is largely done by "correspondence", i.e. by an exchange of documents via the ETSI DocBox server and LISTSERV email exploder facilities. 

On a side note while the rapporteur is in charge of assembling the work documents and will often write and contribute content/text to it they are not meant to single handily write the entire document. The process requires involvement and engagement from all parties. 

When the draft by the Rapporteur Group is considered ready, the draft deliverable is handed over to the Working Group (when it exists) for approval. The formal approval for further processing or, in the case of ETSI Technical Specifications or ETSI Technical Reports, approval and adoption can only be done by the Technical Body, either at a meeting or by correspondence.

From my experience, this process can either go through smoothly or you find yourself spending a whole working day stuck on single paragraph arguing over wording, context and meaning. Ideally, it is best to handle these kinds of issues during the drafting/writing process. Which means following the updates and working versions that are made available. Plus during conference calls to discuss ongoing work you heed the requests for comment and feedback. All meetings and documents should be accessible through the members ETSI site. So, unless the working group is lax in that regard being unable to find out when meetings and online calls are happening and locating the latest drafts is not an excuse to stay uninformed of what is happening.

Some drafting activities for a Technical Body are performed by Specialist Task Forces (STF) located at the ETSI Secretariat.

The adaptation of specifications from external bodies (Publicly Available Specifications (PAS)) to the ETSI deliverable structure follows the same rules, but will normally be performed by the PAS provider, as defined in the Guidelines the for adoption of Publicly Available Specifications.

Adoption

[adoption - the taking of an outsider into a family, clan or tribal group]

While the drafting process is, in principle, the same for all ETSI deliverables, the process elements of the adoption process depend on the type of deliverable being processed.

ETSI Technical Specification, ETSI Technical Report, ETSI Special Report, ETSI Group Report  and ETSI Group Specification.

For ETSI Technical Specifications (TS),  ETSI Special Report (SR) ETSI Group Specification (GS), ETSI Group Report (GR) and ETSI Technical Reports (TR), the Technical Body approval and adoption take place at the same time (one combined decision). The publication is then the only element in the adoption process.

Voting

Votes are successful if at least 71% of the weighted votes cast are in favour of the draft. This applies to all types of documents, except for some Group Specifications. For European Standards the vote of each nation is weighted as agreed by the ETSI General Assembly. For other types of document, the vote of each ETSI member is weighted as agreed between the members.

Publication 

The approved standard is published by the ETSI Secretariat, whose permanent staff are based at their headquarters. The Secretariat works closely with those drafting the document and is responsible for ensuring that the relevant procedures have been followed. This helps to guarantee the high quality of the final document. This is mainly done through a group called 'Edit Help' who will proof-read the document and ensure that it applied to ETSI standards drafting rules. To minimise the pain of having to correct all the red-highlights they will make it is best to families yourself with the ETSI writing guidelines beforehand. 

Maintenance

This is an important part of the standardisation process. It is how ETSI adapts its standards to evolving technology and the developing needs of the market place.

Their standards are updated as required to take account of the latest developments and revised versions are published.


Conclusion

Hopefully, this proves interesting and useful. I would encourage looking through the ETSI site to learn more about the standards development process. Also, it is worth checking other SDOs such as CEN-CENELEC, ISO, NIST and IEEE of how they develop standards. Plus, while ENISA is not an SDO it does supports the development of ICT security standards and certification frameworks in Europe as the work they do in it that area is worth checking. There are broad overlaps but key differences in procedure.  

Sources



Comments

Post a Comment

Popular posts

Balancing functionality, usability and security in design

Image
Introduction When designing new devices or applications there is a requirement nowadays to consider there functionality, usability and security. While there has been a push through secure-by-design guidelines for security to be built-in from the beginning there are still gaps in implementation and part of these gaps are design considerations of functionality and usability. Part of this that doing security well is hard work, but it should never block useful functionality for the user. Ideally, when security interferes with key software capabilities, the security must be tweaked. The answer should never be to abandon the functionality and certainly not to abandon the security. Though achieving this balance is admittedly not straightforward. This blog post will aim to look at this triad and how they can be balanced and not compromise each other. Defining the Triad in design A triangle can be used to help explain the relationship between the concepts of security, functionality and ea
Read more

Personal Interest - Unbuilt fleets of the Royal Navy

Image
Introduction Throughout the 20th Century the Royal Navy designed and examined different types of fleets that were never realised either due to budget constraints, arms treaties or the changing nature of war. These are only a few examples of the different types of unbuilt fleets. Some of these had prototypes built and tasted for the Royal Navy which would serve as technological testbeds. Images and info from secret projects forum, shipbucket, popular mechanics/science and naval-matters. Washington Naval Treaty (WNT) The  Washington Naval Treaty  was a treaty signed during 1922 among the major nations that had won  World War I , which agreed to prevent an  arms race  by limiting naval construction. It was negotiated at the  Washington Naval Conference , held in  Washington, D.C. , from November 1921 to February 1922, and it was signed by the governments of the United Kingdom, the United States, France, Italy, and Japan. It limited the construction of  battleships ,  battlecruisers
Read more

Personal Interest - RAF Unbuilt Projects

Image
  Introduction This blog post looks at the different groups of cancelled RAF projects. It will focus on the 50s, 60s, 90s/00s and a brief look at hypersonic research projects. While these projects were often cut or cancelled for budget or austerity reasons, they were also pushed by the changing nature of warfare firstly from conventional style WW2 warfare to the predicated quick, short scale nuclear war which was expected from 1947 to 1989. Later from the 90s and into the 21st Century a change from state on state conflict to facing insurgencies, counter-terrorism and peacekeeping missions again led to a change in how wars are fought. Though the work and research done on these projects would rarely go to waste with it being used and applied in other projects and works even if sometimes it could take another ten or twenty years before anything operational came of that work. There won't be large amounts of text explaining or exploring the designs there are far better sources for th
Read more