“We are completely rethinking the standardization workflow. This is more about transformation than technology in search of an application”

October 2025 - In addition to oneM2M’s IoT technical standardization activities, members also contribute to improving the organizations' working procedures. One of the key initiatives is to modernize the standardization workflow. The goal is to raise productivity by automating and compressing the workflow from standardization to software product management. For this interview, we hear from three people, Andreas Kraft (AK), Miguel Angel Reina Ortega (MARO), and Roland Hechwartner (RH), who have been closely involved in this initiative. They describe the application of open source and software development practices both to delight oneM2M delegates and to cast behind outmoded ways of working.

Q: Would each of you begin by introducing yourselves?

AK: I am Andreas Kraft and I used to work for Deutsche Telekom (DT) as a principal enterprise architect in the area of standardization and innovation management. I have been involved in the Internet of Things (IoT) for many years. Since my semi-retirement, I have been working as a consultant for oneM2M technologies. My focus is on the development of oneM2M’s technical specifications and the promotion of oneM2M standards in the IoT ecosystem. I am also the author and maintainer of the ACME CSE open-source project. This is an implementation of a oneM2M-compliant Common Services Entity (CSE) which is similar to and a bit more than an IoT platform if I can use a common industry term.

 


MARO: Hello and I am Miguel Ortega. I have been working in ETSI's Centre for Testing and Interoperability for almost 20 years. My role is to support several Technical Groups on the development of interoperability and conformance test specifications in line with ETSI’s testing methodology recommendations. One of these Technical Groups is oneM2M. In addition to the testing activities, I support all Technical Groups to modernize their working procedures with the application of software-development tools and methods to standardization activities. These activities make use of the ETSI Forge platform.

 

 

 

 RH: I am the Chair of oneM2M’s Technical Plenary and have responsibility for coordinating the overall management of the technical work within the Technical Plenary (TP) and its Working Groups (WGs). I am also a representative of Deutsche Telekom (DT).

 

  

 

Q: Let us set the context for how standardization procedures work today?

RH: Standardization proceeds in three steps, beginning with a selection of use-cases which determine a set of (technical) requirements of which the most common ones across use cases are candidates for standardization. From these requirements, it is customary to develop an architecture and follow that up with the definition of protocols for different functionalities.

For the past few decades, this procedure has involved member contributions and change requests, technical discussions, and consensus driven decision making. Everything relies on electronic documents, invariably Microsoft’s WordTM, documents based on a template defined by ETSI, and the “track-changes” function. The procedure is common across oneM2M and 3GPP bodies. The steps in this process involve a lot of manual labour to merge agreed inputs and to manage document versions. These tasks fall, in the oneM2M case, to the Rapporteurs who find themselves in a difficult position. We have a saying that “Rapporteurs never become famous, but they always get the blame.” It is important to note that member delegates to oneM2M take the role of a rapporteur voluntarily. Anything we can do to simplify their role benefits everyone.

MARO: The process to update the documents is slow. The integration of change requests takes time - anything from a couple of days to a couple of weeks. It is not a great use of an expert’s time. At some point, executives from member companies will ask why they are paying a subject matter expert for electronic document processing, literally for copying text from one document to another.

Q: What needs to change and what is your vision for the future?

RH: We have several goals to improve the process. Transparency and traceability are important when there are many contributions and change requests to manage. At the moment, we are constrained by the specificities of Microsoft WordTM; for document production and change tracking. We do not want to be tied to the package, especially as our IoT focus on interoperable standards aims is all about reducing lock-in risks.

We want to ease the burden on rapporteurs and make it easier for delegates to contribute and developers to access our technical specifications. Remember that standardization bodies such as the ISO and ITU at the international level and national bodies (such as DIN in Germany) charge a fee to access their standards; oneM2M makes its technical specifications available at no charge so our documentation approach aims for openness.

In practical terms, we expect that readers and developers will want to access documents directly via browsers instead of having to download and use keyword searches in specification documents. If somebody writes an article about a system that uses oneM2M specifications, they could link to relevant sections of key documents for quick and easy reader access. All of this is to say that our vision for the future is to provide the kind of environment that software developers use to manage code repositories.

Q: What will that mean in practical terms?

AK: At present, when somebody proposes a change to a technical document that addition has to be copied as pure text (i.e., without formatting) into a master document. This can be a source of errors when several changes are involved. It can take rapporteurs a few weeks to make updates which leaves other delegates waiting. We therefore need a way to automate all the boring stuff. Learning from the software world, we see developer communities coping with multiple changes, running automatic code checks and background tests for validity. That is what persuaded us to use the Git approach. It handles specifications of standard processes, is open, and captures important meta information such as author details and timing which are important for tracking and version management.

A second practical aspect is to manage the transition from existing Word-format documents while creating a process for new documents within the confines of oneM2M’s working procedures.

Q: What are the technical implications of your plan?

AK: We began with a feasibility assessment to learn about the migration from Word-format to Markdown documents. Markdown has the advantage of being human and machine readable with a small number of syntax elements. We did not go with XML-based formats as it is more complicated and less easy to read.

Git and GitLab are two other important tools we chose to use. Git is a powerful distributed version control system and makes it possible to tag releases; a developer can look at the history of a contribution and see everything related to a specification in one place without having to open and consolidate information from multiple documents. Git also supports ‘forking’ so that organizations can download all specifications of interest to them and then integrate them directly into product development and software tools. One consequence is to cut down on intermediate steps while lowering the dependency on proprietary document formats. As a result, there are savings both in time and money.

GitLab is a web-based Git repository management platform that provides us with CI/CD functionalities (i.e. Continuous Integration / Continuous Delivery/Deployment). The use of scripts makes it possible to add even more automation, such as syntactic and semantic checking, to the process. In many respects, we are bringing agile, software development processes to standardization which is often accused of being slow and unwieldy.

Q: What are you doing at the implementation level?

MARO: I have been leading the work to bring these new ideas into oneM2M using ETSI's hosting resources. This involves managing a GitLab instance and putting in place the necessary automation and workflow pipelines. We are running two parallel processes. One is for existing and published documents. The other is for new documents that oneM2M members are creating around new standardization topics.

To show you how successful the process is, it is now routine for Technical Plenary participants to open a web browser, navigate to our GitLab projects, and interact with documents and change information. Accessibility is tremendous, with members able to choose their preferred screen reader without being forced to use a specific package (apart from Git). Now, nobody looks at Microsoft WordTM documents. After experiencing the new process for a couple of meetings, nobody wants to go back.

We are seeing wider interest in this approach beyond oneM2M delegates. As part of my implementation support responsibilities, I am doing more and more demonstrations to outside delegates and organizations in other ETSI Technical Groups. There is huge interest in this new approach. I am hopeful that we will see a change in working methods leading to a reduction in the time to take specifications into commercial products.

Q: What benefits do you see from this initiative?

AK: There are so many possibilities. For my work with the developer community, I see this as a way to make knowledge more easily accessible in StackOverflow discussions, for example, via direct referencing to relevant sections in specification documents. Also, linking between documents and specification clauses becomes possible and therefore helps understanding the specifications.

MARO: There are tremendous productivity and efficiency gains. Think about a change that affects two documents. Using GitLab’s merge process and markdown, the changes are straightforward to make. Also, the Rapporteur can review and resolve the contribution within a matter of minutes. 

RH: I agree with everything that has been said. It is important to state that we are completely rethinking activities in the standardization workflow. This is more about transformation than technology in search of an application. We see how oneM2M delegates have adapted their ways of working. 

I believe that there are many more benefits on the horizon. To take one example, by making our documents machine readable, we are on the path to AI processing which is an unplanned benefit. The design of our approach, which began a few years ago, is ahead of the market.

Q: So, what comes next?

AK: We are now in the process of migrating existing documents to the new format. This is a big task, and we are making good progress. We are also working on improving the automation and workflows to make it even easier for rapporteurs and delegates to contribute to the standardization process.

Something else we are trying is to catch errors automatically in the documents and accompanying source files before they are published. This will be a big step forward compared to the previous process where discrepancies were sometimes only discovered after publication.

Q: How can readers get more information?

MARO: All of the work under this initiative is publicly available. We welcome any feedback and ideas to enhance the procedure and tools. Readers can start from the following three resources: