This is a public working draft that has not been reviewed by the IAB or the IETF
This page contains specific information about the IETF relevant to the European Multi Stakeholder Platform on ICT Standardisation, MSP for short. This page is intended for the stakeholders that seek information specific to the MSP's work and how that work relates to the IETF, it is not intended for IETF participants seeking more information about the MSP.
For more detailed information, or to submit relevant information to the MSP, please contact Mat Ford or Olaf Kolkman who are the IETF representatives in the platform and the editors of this page.
This Rolling Plan for ICT Standardisation identifies EU policy priorities where ICT standardisation and ICT standards should be considered as part of policy making. The Rolling Plan is a strategic document focussing on the support that standards, technical specifications, and standardisation in general can provide in the context of EU policy priorities.
The Rolling Plan looks at the standardisation landscape in relation to the EU policy priorities. It identifies possible areas for action and may go into suggesting a plan or roadmap regarding effective standardisation support.
In chapter 3 of the Rolling Plan various policy areas are identified that need to be supported by ICT standardisation. Below we follow the structure of this Rolling Plan and supply information about the related standardisation and research activities in the IETF and IRTF. The final Rolling Plan itself incorporates the IETF-related sections on this page where appropriate.
Previous versions of the Rolling Plan and the IETF work that fits into it:
The current structure is based on the draft document "Rolling Plan on ICT Standardisation (2024 revision)". The objective of this page is to raise awareness regarding policy areas that need standardisation from a European Commission point of view and collect input regarding relevant work at the IETF and IRTF.
Since there may not be sufficient specific policy area expertise for each of the areas mentioned in Chapter 3 of the Rolling Plan the references below are likely to be incomplete. Readers are advised to review the IETF areas for potentially related technology work and contact Mat Ford or Olaf Kolkman or any Area Director with general or specific questions.
RP: Digital technologies are transforming the economy and society, and data is at the centre of this transformation. Data-driven innovation will be essential for the modernisation of Europe and the data economy which has the potential of bringing enormous benefits for citizens, for example in support to medicine, mobility, Green Deal. The key role of data is reflected in many chapters of the rolling plan outlining the respective sector specific aspects. On top of that, and addressed in this chapter, data is of foundational and horizontal relevance.
Action 1: SDOs to identify and inform about standards that are available or under way and that are of relevance in supporting the digital transformation at the level of data-innovation and of the data economy.
Action 2: SDOs to collaborate on developing a programme for addressing standardisation needs around all the data lifecycle, from data collection to record keeping, archiving and long term preservation of information and start the respective standardisation activities.
Action 3: In the context of the MSP, start an analysis on the role of open source software complementing standardisation for the data economy, e.g. with APIs, protocols, service delivery and other platforms.
Action 4: SDOs to identify and inform about standards that are available or under way and that are of relevance in supporting the interoperability of data as well as data sharing services between different sectors and domains.
Action 5: SDOs to develop standards in support of the Data Governance Act, the Digital Services Act and the Digital Markets Act, taking into account the results of ISA2 program.
Action 6: EC to facilitate bringing eArchiving and respective requirements into standardisation.
Action 7: In collaboration with the Data Spaces Support Centre (DSSC), stakeholders to address the topic of gathering and processing data from different sources across domains which is becoming a priority and is largely encouraged trough standardisation actions. In several sectors a global approach may be helpful as regards reference data and vocabularies, dictionaries an other meta data and respective standardisation developments might be started in order to enhance interoperability and lower implementation costs.
The following IETF Working Group is active in this area:
The Building Blocks for HTTP APIs (httpapi) Working Group will standardise HTTP protocol extensions for use when HTTP is used for machine-to-machine communication, facilitated by HTTP APIs. Output can include the following:
https://wiki.ietf.org/en/group/iab/Multi-Stake-Holder-Platform#h-301-data-economy
RP: The Communication on ICT standardisation priorities for the digital single market proposes actions on cybersecurity, considered as priority domain for Europe For security and notification requirements for operators of essential services, the focus will be on establishing a number of reference standards and/or specifications relevant to network and information security, including, where relevant, harmonised standards, to serve as a basis for encouraging the coherent adoption of standardisation practices across the EU. For security and notification requirements for digital service providers, in line with the objectives of the Digital single market strategy, the Directive aims to establish a harmonised set of requirements so that they can expect similar rules wherever they operate in the EU. It is important that all levels of an organisation –particularly the strategic level and the management board - are aware of the need for standards and frameworks for cybersecurity. Moreover, between organisations that are partners in (vital) online chains, clear agreements will have to be made on the different standards.
Action 1: SDOs to develop standards and sectorial specifications for critical infrastructure protection in support of and responding to the requirements in anticipation of the reviewed NIS2 Directive. Foster the application of EN 62443 series (base on IEC 62443 series) for the firm establishment of EU regulatory requirement operational technology (OT) security including critical infrastructures.
Action 2: SDOs to assess the content of existing standards and specifications applied under the European Cybersecurity Certification Framework in order to revise existing documents or create new standards. It should be ensured that these standards are gradually and timely made available for providing support to any certification activity, particularly as the preparation and implementation of certification schemes has come under the remit of ENISA on Common Criteria (EUCC), Cloud services (EUCS) and 5G (EU5G). In particular, SDOs are encouraged to develop and harmonise standards related to the specification and assessment of security properties in ICT products and services (including cloud services), as well as those related to security in processes related to the design, development, delivery and maintenance of an ICT product or service, as well as methodologies concerning assurance levels for industry sectors.
Action 3: SDOs to investigate and prepare harmonised evaluation methodologies of cybersecurity risks, controls and interfaces as required by EU policy instruments such as the Certification Framework of the EU Cybersecurity Act, the Cyber Resilience Act and others for their horizontal application into trusted products such as semiconductors, the European Digital Identity Wallet, and other digital technologies.
Action 4: SDOs to assess areas and options for the preparation and implementation of European cybersecurity policy, in particular of essential cybersecurity requirements relevant to the digital products and ancillary services referred by the Cyber Resilience Act, but also of relevance to complement the instruments related to the Machinery Directive, the Radio Equipment Directive or to the machine learning component for the AI Act.
Action 5: SDOs to investigate requirements for secure and interoperable communication protocols for mobile and fixed networks of distributed devices and services that may in addition rely upon limited resources and interfaces. Requirements should address relevant mechanisms of authenticating, registering, and processing user identities seamlessly across devices, services and applications.
Action 6: SDOs to investigate the availability of standards and specifications in general or for business sectors as regards to the requirements to risk management across the supply chain and incident notification for operators of essential services in anticipation of the NIS2 Directive and in support of possible other pieces of EU law , including certification schemes as defined in the Cybersecurity Act.
Action 7: SDOs to assess gaps and develop standards on cybersecurity of consumer products in support of possible certification schemes completed under the European Cybersecurity Act and in support of other possible instruments of EU law.
Action 8: SDOs to explore options for the composition and matching of assurance statements as issued under the Certification Framework of the Cybersecurity Act also in conjunction to the provisions of related EU policy instruments like the Cyber Resilience Act, the NIS2 Directive or the new eIDAS regulation.
Action 9: SDOs should foster/establish cooperation with the European Cybersecurity Coordination Centre in order to facilitate the results of current research and outputs from the funding programmes Horizon Europe and Digital Europe.
Action 10: SDOs to assess gaps and develop standards in support of trust services under the NIS2 proposal and other possible instruments of EU law
The IETF Security Area is the home for working groups focused on security protocols. They provide one or more of the security services: integrity, authentication, non-repudiation, confidentiality, and access control. Since many of the security mechanisms needed to provide these security services employ cryptography, key management is also vital.
The Security Area intersects with all other IETF Areas, and the participants are frequently involved with activities in the working groups from other areas. This involvement focuses upon practical application of Security Area protocols and technologies to the protocols of other Areas.
The full list of IETF Working Groups in the Security Area is available here: https://datatracker.ietf.org/wg#SEC
RP: The focus will be on establishing a number of reference standards and/or specifications relevant to privacy in the electronic communications environment, including, where relevant, harmonised standards, to serve as a basis for encouraging the coherent adoption of standardisation practises across the Union. The Commission recently has proposed a mandate to European Standards Organisations seeking to routinely include privacy management methodologies in both the design and production phases of cybersecurity technologies generally.
In the light of the accountability and privacy by design principles, ICT standards generally should be created in order to ensure a high-level of protection of individuals with regard to personal data processing, and the free movement of such data, and the application of privacy by design methodologies. Privacy and data protection standards should thus be examined, developed or improved if necessary, so as to provide standardised methods that support that review and improvement in due respect of EU data protection rules. Proposed specific areas for SDOs to focus on are:
Action 1: Continuing work on standardising browser functionalities and defaults to enable users to easily control whether they want to be tracked.
Action 2: SDOs to work on standardised solutions for location data used by mobile applications. ISO/IEC 29184 Information technology - Online privacy notices and consent is adopted unmodified as EN ISO/IEC 29184.
Action 3: SDOs to investigate standards for supporting compliance and certification of compliance with GDPR and possible other EU data privacy requirements. . Also a gap analysis should be run so to understand needed future work that may have to be prioritised.
Action 4: Promote EU-wide attention to standardisation of privacy statements and terms & conditions, given that there is mandatory acceptance of diverse, ambiguous and far-reaching online privacy conditions, and taking into account the GDPR. The Kantara CIS work and the data use statements described in ISO/IEC 19944 could be used as a basis for this action.
Action 5: SDOs to continue investigating technical measures apt to make personal data anonymous or pseudonymised (and therefore unintelligible by those who are not authorised to access them).
Action 6: SDOs to continue investigating how to warrant a user-centric approach in privacy & access management: see http://www.laceproject.eu/blog/give-students-control-data/ and
http://www.lvm.fi/julkaisu/4440204/mydata-a-nordic-model-for-human-centred-personal-data-management-and-processing.
Action 7: SDOs to prevent unwarranted pervasive monitoring by default when developing standards. This is not only relevant in the context the internet but also the IoT.
Action 8: SDOs to develop secure coding standards for secure application development: EU-wide attention to standardisation of privacy statements and terms & conditions as far as possible, given the existing state of mandatory acceptance of diverse, ambiguous and far-reaching online privacy conditions, taking into account the GDPR and the emergence of the IoT, where (embedded) devices process the device owner's personal data and possible different device users' personal data, creating additional challenges to transparency and informed consent.
The following IETF Working Groups are active in this area:
The DNS PRIVate Exchange (dprive) WG develops mechanisms to provide confidentiality to DNS transactions, to address concerns surrounding pervasive monitoring (RFC 7258). The set of DNS requests that an individual makes can provide an attacker with a large amount of information about that individual. DPRIVE aims to deprive the attacker of this information.
The Privacy Pass (privacypass) WG is standardising a protocol that provides a performant, application-layer mechanism for token creation and anonymous redemption. Servers (Issuers) create and later verify tokens that are redeemed by an ecosystem of clients, such that:
The QUIC (quic) WG is developing the QUIC protocol which provides end-to-end security for transport connections, including protection of header fields that are left unprotected by TLS. The QUIC working group's specifications are currently in last call, and will soon become recognised standards. The use of QUIC in the Internet is already quite high and growing.
Many network topologies lead to situations where transport protocol proxying is beneficial. For example, proxying enables endpoints to communicate when end-to-end connectivity is not possible, or to apply additional encryption where desirable (such as a VPN). Proxying can also improve client privacy, e.g., by hiding a client's IP address from a target server. The Multiplexed Application Substrate over QUIC Encryption (masque) WG is developing mechanism(s) that allow configuring and concurrently running multiple proxied stream- and datagram-based flows inside an HTTPS connection. These mechanism(s) are collectively called MASQUE.
The MAC address Device Identification for Network and Application Services (madinas) Working Group is documenting recommended means to reduce the impact of randomized and changing MAC addresses (RCM) while ensuring that the privacy achieved with RCM is not compromised. The Working Group will liaise with other relevant organizations, such as IEEE 802 and the Wireless Broadband Alliance (WBA), by coordinating on the different recommendations, as well as potential follow-up activities within or outside the IETF.
There are many situations in which it is desirable to take measurements of data which people consider sensitive. For instance, a browser company might want to measure web sites that do not render properly without learning which users visit those sites, or a public health authority might want to measure exposure to some disease without learning the identities of those exposed. In these cases, the entity taking the measurement is not interested in people's individual responses but rather in aggregated data (e.g., how many users had errors on site X). Conventional methods require collecting individual measurements in plaintext and then aggregating them, thus representing a threat to user privacy and rendering many such measurements difficult and impractical.
New cryptographic techniques address this gap through a variety of approaches, all of which aim to ensure that the server (or multiple, non-colluding servers) can compute the aggregated value without learning the value of individual measurements. The Privacy Preserving Measurement (ppm) Working Group will standardize protocols for deployment of these techniques on the Internet.
The Oblivious HTTP Application Intermediation (ohai) Working Group will define a protocol for anonymization of HTTP requests using a partly-trusted intermediary, a method of encapsulating HTTP requests and responses that provides protected, low-latency exchanges. Applications and use cases best suited for this protocol are those that have discrete, transactional queries that might reveal small amounts of information that accumulate over time. Examples include DNS queries, telemetry submission, and certificate revocation checking.
The Privacy Enhancements and Assessments Research Group (PEARG) in the IRTF is a general forum for discussing and reviewing privacy enhancing technologies for network protocols and distributed systems in general, and for the IETF in particular.
https://wiki.ietf.org/en/group/iab/Multi-Stake-Holder-Platform#h-303-eprivacy
RP: The Communication on ICT standardisation priorities[11] identifies 5G standards as key to competitiveness and the interoperability of global networks, with stakeholders from different standardisation cultures called upon to collaborate. It also details the actions required.
The first phase of 5G standards from 3GPP focuses on enhanced mobile broadband while also supporting ultra-reliability and low latency. The second phase should deliver the standards for other use-cases, such as those related to industrial applications or transversal needs such as lawful interception. Here, availability of standards promoting open innovation and opportunities for start-ups is also key.
The European Commission has called on Member States and industry to commit to the following objectives:
In December 2017, Commissioner Gabriel sent a letter to 3G PP, urging the standardisation bodies and the concerned industrial actors to step-up their efforts for the rapid development of 5G standards addressing more immediate market needs while driving a clear strategy for a 5G global standard bringing benefits to a wide range of industrial use cases, in line with the EU strategy targeting 5G developments in support of "vertical" industries and of our wider objectives of digitising the European industry.
Interactions between IETF and 5G developments fall into several categories:
https://wiki.ietf.org/en/group/iab/Multi-Stake-Holder-Platform#h-311-5g-and-beyond
RP: The Communication on ICT Standardisation Priorities for the digital single market proposed priority actions in the domain of Cloud. Some actions are still relevant and mentioned below. Others come from the need to respond to the challenges of the Digital Decade Communication.
Action 1: Identify needs for ICT standards and open source technologies to further improve the interoperability, data protection and portability of cloud services and continue or start respective development activities. This should also take into account available open source technologies and their role for interoperability, data protection and management of multiple clouds.
Action 2: Promote the use of the ICT standards needed to further improve the interoperability, data protection and portability of cloud services as well as multi-cloud management.
Action 3: Further strengthen the interlock between standardisation and open source in the area of Cloud and establish and support bilateral actions for close collaboration of open source and standardisation. Foster a level playing field that allows the use of Open Source procedures and deliverables where they make economic sense complementing or substituting standardisation.
Action 4: Promote international standards on service level agreements (SLAs) and usage of the cloud code of conduct (CoC).
Action 5: Promote the use of the ISO/IEC JTC 1 reference cloud architecture and define generic cloud architecture building blocks. Map available standards to the generic cloud architecture building blocks. Define privacy, security and test standards for each building block. This will also help determine which standards can be used for open cloud platforms and architectures taking into account the key role of open source for cloud infrastructure design and implementations.
Action 6: Promote the development of adequate standards/open source developments to ensure a competitive playing field for cloud services provision in Europe and contribute to the green agenda.
Action 7: SDOs and open source communities to foster their collaboration, mutual exchange, integration of Open Source outcomes in SDO deliverables and identification of technologies, e.g. APIs, that have been developed in open source and could be standardised.
Action 8: SDOs should focus on addressing the edge/cloud X-continuum paradigm and standardisation challenges. In particular, due to huge increase of connected devices and systems, several computing deployments are embracing the notion of computing continuum, where the right compute resources are placed at optimal processing points, i.e., cloud data centre, edge computing systems and end devices, This requires the support of: (1) continuum of technologies across sensors, connectivity, gateways, edge processing, robotics, platforms, applications, Al, and analytics, including underlying technologies like optical, wireless (cellular and non-cellular) and satellite communications, (2) continuum of intelligence and edge capabilities, (3) continuum of edge applications across vertical sectors and seamless integration.
Action 9: SDOs to prepare an overview of available open interoperability specifications that respond to the legal requirements outlined in the draft data act and that could be promoted for use to demonstrate compliance.
Action 10: SDOs to Promote the development of a standard or a set of standards for processor sockets for cloud computing infrastructure.
The IETF has multiple groups working on standards for virtualization techniques, including techniques used in cloud computing and datacenters.
The Layer 2 Virtual Private Networks (L2VPN) Working Group produced specifications defining and specifying solutions for supporting provider-provisioned Layer-2 Virtual Private Networks (L2VPNs). They also addressed requirements driven by cloud computing services and data centers as they apply to Layer-2 VPN services. The L2VPN Service Model (L2SM) Working Group is tasked to created a data model that describes an L2VPN service.
The Layer 3 Virtual Private Networks (L3VPN) Working Group was responsible for defining, specifying and extending solutions for supporting provider-provisioned Layer-3 (routed) Virtual Private Networks (L3VPNs). These solutions provide IPv4, IPv6, and MPLS services including multicast.
The Layer Three Virtual Private Network Service Model (L3SM) Working Group was tasked to create a YANG data model that describes an L3VPN service (an L3VPN service model) that can be used for communication between customers and network operators, and to provide input to automated control and configuration applications.
The Network Virtualization Overlays (NVO3) Working Group develops a set of protocols and extensions that enable network virtualization within a datacenter environment that assumes an IP-based underlay. An NVO3 solution provides layer 2 and/or layer 3 services for virtual networks enabling multi-tenancy and workload mobility, addressing management and security issues.
The System for Cross-domain Identity Management (SCIM) Working Group worked on standardising methods for creating, reading, searching, modifying, and deleting user identities and identity-related objects across administrative domains, with the goal of simplifying common tasks related to user identity management in services and applications.
The Computing in the Network Research Group (coinrg) of the IRTF explores existing research and fosters investigation of “Compute In the Network” and resultant impacts to the data plane. The goal is to investigate how to harness and to benefit from this emerging disruption to the Internet architecture to improve network and application performance as well as user experience.
https://wiki.ietf.org/en/group/iab/Multi-Stake-Holder-Platform#h-312-cloud-and-edge-computing
RP: With the continuously growing amount of data (often referred to as 'big data') and the increasing amount of open data, interoperability is increasingly a key issue in exploiting the value of this data.
Standardisation at different levels (such as metadata schemata, data representation formats and licensing conditions of open data) is essential to enable broad data integration, data exchange and interoperability with the overall goal of fostering innovation based on data. This refers to all types of (multilingual) data, including both structured and unstructured data, and data from different domains as diverse as geospatial data, statistical data, weather data, public sector information (PSI) and research data (see also the rolling plan contribution on 'e-Infrastructures for data and computing-intensive science'), to name just a few.
The following IETF Working Group is active in this area:
The A Semantic Definition Format for Data and Interactions of Things (asdf) Working Group is tasked with developing Semantic Definition Format (SDF) into a standards-track specification for thing interaction and data modelling. In the process of developing this specification, further functional requirements that emerge in the usage of SDF for model harmonization will be addressed.
https://wiki.ietf.org/en/group/iab/Multi-Stake-Holder-Platform#h-313-data-interoperability
RP: The Communication on ICT standardisation priorities for the digital single market proposes priority actions in the domain of internet of things. Actions mentioned below reflect some of them.
Action 1: SDOs to work on a landscape overview report and a gap analysis for IoT standardisation in the edge and swarm context.
Action 2: SDOs to continue ongoing work in the area of semantic standards for better data interoperability. Special focus should be put on further extending the SAREF ontology both in number of extensions and the content of each extension and further evolve it towards the requirements of the common European Data Spaces.. The results of European projects (such as the large scale IoT pilots and similar) could be used to achieve this, by providing interoperability profiles, associated justifications (interoperability cases) that would extend current standards e.g., ISO 21823 IoT interoperability. SAREF should also be adapted for new realities such as edge computing, (federated) machine learning and AI, etc. SDOs should also continue ongoing work for existing standards (e.g. ISO 13584-1 or IEC 61360/ Common Data Dictionary) on semantics. Concepts for digital twins require additional property types for operational use compared to the purely descriptive properties of an asset. These are states and parameters of the assets as well as their measured and actor values (dynamic data). Commands and entire functions (often called technical functions) must also be described using the same concepts. The concept of properties in today’s standards is to extend such semantics in the data models to be able to represent dynamic values correctly. Models for functions/commands are to be developed or existing ones defined in standards.
Action 3: SDOs to provide standards supporting compliance as well as standards enabling the integration of AI, data processing capabilities and digital twin systems into IoT products, systems, applications and processes. The digital twin part should cover aspects such as identifiers, trust, security, privacy, APIs, provisioning, monitoring, vocabularies and ontologies, metadata, etc.
Action 4: Develop a European standard for cyber security compliance of products and systems that is aligned with the current compliance framework of organisations based on the ISO 27000 Information Security Management Standards series and the GDPR regulation and the future compliance framework of systems based on standards such as ISO/IEC 27100, ISO/IEC 27400, 27402, 27403, ISO 31700.. Preferably the standard could be used to harmonise the requirements set out in the NIS directive and the cybersecurity certification framework.
Action 5: Promote the development and foster the adoption of novel Reference Architectures for IoT developed in ISO/IEC JTC 1/SC 41 and OneM2M. This architectures should interconnect highly heterogeneous and distributed edge nodes and (resource-constraint) devices and be compliant to the latest developments such as edge computing, distributed intelligence and learning, cognitive computing, mesh networking, swarm computing and digital twins.
Action 6: SDOs to assess further gaps and develop standards on the safety and cybersecurity of IoT consumer products under the European Cybersecurity Act or sectorial legislation.
Action 7: SDOs should consider further inclusion of and outreach to verticals.
Action 8: SDOs should get involved in the definition of the technical common ground of the Common European Data Spaces to be developed and deployed under the Digital Europe and Horizon Europe programmes and leverage the IoT interoperability standardisation assets for that purpose. This could include the management of data lifecycle, common interoperability and discovery language, common data models, data curation network, trustworthiness, governance models, decentralised architecture, scale-up methodologoes, etc.
Action 9: SDOs should look in the standardisation needs of the new edge paradigm and investigate the impact
on it of the specific use cases of the verticals (such as energy, mobility, agriculture, health and other). Specific concepts such as software containers, APIs and interfaces, etc. should be explored.
Action 10: Increased collaboration/synchronization between standardisation bodies (e.g., ETSI SAREF, W3C SOSA/SSN, IEEE 1872.2 Autonomous Robotics Ontology, ISO 21823- 3 IoT Semantic Interoperability, etc.).
Action 11: SDOs should consider addressing the standardisation of federated Learning and AI for IoT edge related challenges. In particular, federated Learning brings Al models close to the edge to enhance data protection, improve inference reliability, and increase autonomy of end clusters (e.g., end loT/lloT devices, on-premises servers, etc.). The cloud plays a federation role for aggregating insights from different loT edge distributed clusters to generate a federated model shared with each individual cluster. Such standardisation challenges are: (1) workflow standardisation, (2) interfaces edge/cloud, orchestration, (3) model contamination, and (4) pipes for handling distributed traffic.
Action 12: SDOs should get involved in the standardisation of loT Swarm Systems. In particular, focus on concepts for loT intelligence clustering to promote collaboration and share of resources and functions for performing specific tasks. These concepts impose standardisation challenges in the required architecture, such as interfaces, data models and ontologies and as well as security and privacy models.
Action 13: SDOs should focus on standardisation needs for IoT and edge computing
coexistence/integration/interoperability and continuum across several sectors and platforms. In particular, the use of end-to-end capabilities of IoT technologies across the edge granularity and beyond impose continuum standardisation challenges, such as support of interoperability by the means of new interfaces, data models, security and privacy models and security and privacy models.
Action 14: SDOs should consider addressing standardisation challenges for service discovery and authentication in the context of distributed and federated edge computing systems and in particular, for scenarios where multiple mobile devices are used that require services simultaneously and uninterruptedly. There is a challenge of effectively managing billions of IoT devices, ensuring that they are suitably configured, running appropriate software, kept up-to-date with security updates and patches, and run only properly authenticated and authorised applications. Authentication of services and service providers, while accounting for resource usage, is also an essential part of the economics of the network of the future. There is a need of ensuring interoperability across platforms, devices, and locations, by enabling assets to be securely purchased and transferred between virtual and real-world locations, authenticated and validated, using various consensus methods that support the validation of identity, ownership, and usage rights of any asset subject to relevant rights.
Action 15: SDOs should investigate and elaborate on system-level optimisation techniques combining lower power consumption and energy harvesting technologies, E2E energy methods and models for data compression and exchange in edge-cloud IoT platforms, benchmarking methods for energy-efficient and low CO2 footprint of edge IoT infrastructure and technical solutions, energy-efficient data aggregation mechanisms in intelligent edge IoT systems considering the associated processing and connectivity capabilities across the computing continuum. Specify (or modify existing) interfaces that help monitor and control of the energy usage in communication protocol layer stacks applied in IoT and edge computing solutions. Specify (or modify existing) IoT and edge computing related standards, interfaces, data models and ontologies to reduce the energy and carbon footprint.
Action 16: SDOs should investigate IoT system level and network function virtualisation and AI-based zero-touch operations automation including automated reconfiguration and setup.
Action 17: SDOs to work towards a faster standardisation cycle more adapted to the fast pace of IoT technology developments. Some examples already exist (e.g. for SAREF and FIWARE).
The IETF has a number of Working Groups chartered to develop standards to support the Internet of Things.
The IPv6 Over Low Power WPAN (6LOWPAN) Working Group developed standards to ensure interoperability between smart object networks and defining the necessary security and management protocols and constructs for building such networks.
The IPv6 over Networks of Resource-constrained Nodes (6LO) Working Group develops IPv6 adaptation mechanisms to a wider range of radio technologies including “Bluetooth Low Energy” (RFC 7668), ITU-T G.9959 (as used in Z-Wave, RFC 7428), and the Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) cordless phone standard and the low-cost wired networking technology Master-Slave / Token-Passing (MS/TP) that is widely used over RS-485 in building automation.
The IPv6 Over Low Power Wide-Area Networks (lpwan) WG focused on enabling IPv6 connectivity over the following selection of Low-Power Wide-Area networking technologies: SIGFOX, LoRa?, WI-SUN and NB-IOT.
The Light-Weight Implementation Guidance (LWIG) Working Group focuses on helping the implementors of the smallest devices. The goal is to be able to build minimal yet interoperable IP-capable devices for the most constrained environments.
The Routing over Low Power and Lossy Networks (ROLL) Working Group is developing standards to support the routing of communications within low-power and lossy networks.
The Constrained RESTful Environments (CORE) Working Group is specifying protocols that allow applications running in resource-constrained environments to interoperate with each other and the rest of the Internet. CORE is one of the most active IoT groups. Its main output centres around the “Constrained Application Protocol” (CoAP, RFC 7252), a radically simplified UDP-based analog to HTTP. Extensions to CoAP enable group communications (RFC 7390) and low-complexity server-push for the observation of resources (RFC 7641). This is complemented by a discovery and self-description mechanism based on a weblink format suitable for constrained devices (RFC 6690). Current WG activities focus on extensions that enable transfer of large resources, use of resource directories for coordinating discovery, reusable interface descriptions, and the transport of CoAP over TCP and TLS. CoRE is also looking at a data format to represent sensor measurements, which will benefit from the “Concise Binary Object Representation” (CBOR) (RFC 7049), a JSON analog optimised for binary data and low-resource implementations.
The A Semantic Definition Format for Data and Interaction of Things (asdf) Working Group is developing Semantic Definition Format (SDF) into a standards-track specification for thing interaction and data modelling. In the process of developing this specification, further functional requirements that emerge in the usage of SDF for model harmonization will be addressed.
The IOT Operations (iotops) Working Group is discussing and documenting operational issues related to IoT devices, in particular related to device onboarding and lifecycle management. This group is also tackling issues related to IoT operational security.
Security aspects of the IoT are being addressed in the following Working Groups:
The Trusted Execution Environment Provisioning (TEEP) WG is working on standardising protocols for provisioning applications into secure areas of computer processors.
The Software Updates for Internet of Things (SUIT) WG is working on mechanisms for securely updating the firmware in IoT devices.
The Authentication and Authorisation for Constrained Environments (ACE) WG is working on a standardised solution for authentication and authorisation to enable authorised access to resources on a device in constrained environments. In such environments, typical for the IoT, the network nodes are limited in CPU, memory and power. This work was supported by the COSE WG that built simplified CBOR analogs for the JSON object signing and encryption methods that were developed in the JOSE WG.
The DTLS In Constrained Environments (DICE) WG focused on supporting the use of DTLS Transport-Layer Security in these environments. Such constrained environments, including constrained devices (e.g. memory, algorithm choices) and constrained networks (e.g. PDU sizes, packet loss), are typical for the IoT, Smart grids, etc.
The Lightweight Authenticated Key Exchange (LAKE) WG is developing a ‘lightweight’ authenticated key exchange (LAKE) that enables forward security. 'Lightweight' refers to:
but the LAKE must still provide the security properties expected of IETF protocols, e.g., providing confidentiality protection, integrity protection, and authentication with strong work factor.
While the IoT-oriented IETF working groups have already produced the first wave of mature standards for IoT, new research questions are emerging based on the use of those standards. The IRTF Thing-to-Thing Research Group (T2TRG) was chartered in 2015 to investigate open research issues in IoT, focusing on issues that exhibit standardisation potential at the IETF.
https://wiki.ietf.org/en/group/iab/Multi-Stake-Holder-Platform#h-314-internet-of-things
RP: The eIDAS Regulation adopted on 23 July 2014 addresses in one comprehensive piece of legislation, electronic identification, electronic signatures, electronic seals, time stamping, electronic delivery, electronic documents and website certificates as core instruments for electronic transactions. To support the implementation of this highly technical regulation, further standardisation work will be needed. In the case of trust services, the planned secondary legislation refers extensively to the availability of standards as possible means to meet the regulatory requirements. Existing standards should be checked to take account of the protection of individuals with regard to personal data processing and the free movement of such data. Specific privacy by design standards should be identified and where needed developed. The accessibility needs of persons with disabilities should also be taken into account.
Action 1. Take ongoing EU policy activities into account in standardisation, e.g. in ISO/IEC JTC 1/SC 27/WG 5 (identity management and privacy technologies) and other working groups of ISO/IEC JTC 1/SC 27. Furthermore, in order to promote the strengths of the European approach to electronic identification and trust services at global level and to foster mutual recognition of electronic identification and trust services with non-EU countries, European and international standards should be aligned wherever possible. The promotion and maintenance of related European approaches, which especially take into account data protection considerations, in international standards should be supported.
Action 2: As required by the framework established under the proposed regulatory framework for European Digital Identities prepare standards for
Action 3: SDOs to cooperate and work in the areas of identifiers, vocabularies, semantics, taxonomies, ontologies for electronic attestations
The following IETF Working Groups are active in this area:
The Web Authorization Protocol (OAUTH) WG developed a protocol suite that allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. It also developed security schemes for presenting authorisation tokens to access a protected resource.
The ongoing standardisation effort within the OAUTH working group is focusing on enhancing interoperability of OAUTH deployments.
The Public Notary Transparency (TRANS) WG developed a standards-track specification of the Certificate Transparency protocol (RFC6962) that allows detection of the mis-issuance of certificates issued by CAs or via ad-hoc mapping by maintaining cryptographically verifiable audit logs.
The Automated Certificate Management Environment (ACME) WG specifies conventions for automated X.509 certificate management, including validation of control over an identifier, certificate issuance, certificate renewal, and certificate revocation. The initial focus of the ACME WG is on domain name certificates (as used by web servers), but other uses of certificates can be considered as work progresses.
The Supply Chain Integrity, Tranparency, and Trust (SCITT) Working Group works to define a set of interoperable building blocks that will allow implementers to build integrity and accountability into software supply chain systems to help assure trustworthy operation. For example, a public computer interface system could report its software composition that can then be compared against known software compositions or certifications for such a device thereby giving confidence that the system is running the software expected and has not been modified, either by attack or accident, in the supply chain.
Editor's note: No specific work identified in the IETF or IRTF
RP: Telecom manufacturers, operators and other stakeholders have an interest in assuring a minimum of interoperability of broadband infrastructure mapping to facilitate the deployment of next-generation networks, simplify their operation, reduce cost and finally open up a single market dimension. In order to achieve the EU broadband objectives of the Digital Agenda Europe, it is fundamentally important that there is reliable and valid data on existing and planned broadband infrastructures, services offered; and demand and investment. A standardised mapping of broadband infrastructures and services as well as of other related data will help identify gaps of broadband coverage and quality of service level and identify suitable areas of investment. Increasing the reliability of coverage data (QS1) will be particularly useful to avoid duplication of financing as subsidies can be allocated to areas truly affected by market failure and regulatory needs linked to market regulation. Gathering reliable quality of service data (QS2 and QS3) based on common methodologies will feed into other regulatory aspect linked to net neutrality and consumer protection as well as assisting in the provision of reliable 5G services to vertical industries.
Action 1 SDOs to further develop a standardised methodology and guidelines to assess and map availability and quality of fixed and wireless/mobile broadband services (including coverage, QoS and QoE, key quality indicators - KQI) also in view of the development of VHC (very high-capacity) and 5G services for a range of public and private users including the large industries such as vertical industrial sectors.
The Large-Scale Measurement of Broadband Performance (LMAP) Working Group standardised the LMAP measurement system for performance measurements of broadband access devices such as home and enterprise edge routers, personal computers, mobile devices, and set top boxes, whether wired or wireless.
Measuring portions of the Internet on a large scale is essential for accurate characterisations of performance over time and geography, for network diagnostic investigations by providers and their users, and for collecting information to support public policy development. The goal is to have the measurements (made using the same metrics and mechanisms) for a large number of points on the Internet, and to have the results collected and stored in the same form.
RP: Standardisation needs arise, for instance from the UN Convention, Article 9 of which requires the development of accessibility standards, and from the general obligations to promote universal design when drafting standards. Work on this area needs to advance at European level, where possible in coordination with related work at international level, and to support harmonised market requirements within Europe.
Action 1: SDOs to work on the development and revisions of the harmonised standards and technical reports, as requested by standardisation request Mandate 587.
Action 2: SDOs to produce a technical report describing requirements for ICT products and services to be designed to meet the needs of persons with cognitive and learning disabilities; the report should propose enhancements to relevant existing standards and identify needs for further standardisation such as the development of measurable requirements to address cognitive accessibility to be included in the standards implementing relevant legislation. The report should take into account the latest research in the field of cognitive disabilities and give guidance on which aspects of cognitive disabilities are sufficiently well understood so that support for people with such disabilities can be standardised (and tested) in a technically meaningful way.
Action 3: SDOs to produce a technical report on the possible accessibility requirements and standardisation needs of ICT products and services that are based on emerging technologies, such as natural language processing, wearables, virtual and augmented reality, AI, as well as biometrics and enhanced ICT security. These technologies must be designed to meet the needs of persons with disabilities, which includes cognitive and learning disabilities.
Action 4: SDOs to continue work on the implementation of the methodology developed under M/473, providing that new standardisation deliverables including the European standards comply with the methodology for mainstream accessibility in standardisation processes and the revision of existing standards in line with what it was agreed in the Mandate deliverable 3.1
Relevant work may be found in the ART area. For instance RFC 3551 identifies the requirements for SIP to support the hearing impaired and RFC4103 defines the RTP payload for text conversation.
RFCs 4103 and 5194 are being referenced in various accessibility regulations being proposed in the US (Section 255/508) and EU (e.g. M376).
RP: AI is a field that has had little standardisation activities in the past. However, the big increase of interest and activities around AI in the latest years brings together a need for the development of a coherent set of AI standards. In response to this, ISO has created a standardisation committee on AI, namely ISO/IEC JTC 1/SC 42, which is mostly active in the field of big data. The professional association IEEE is also very active in investigating and proposing new standards for AI, particularly in the field of ethics of autonomous and intelligent systems. The European Commission has launched its Communications of 25th April and a number of initiatives about AI, which are commented below.
Most of these activities are recent and will lead to requests for developing new standards. For the time being, there are no significant past activities to report about their progress.
The most likely areas where new AI standards will be required are the following:
Action 1: SDOs should establish coordinated linkages with, and adequately consider European requirements or expectations from initiatives, including policy initiatives, and organisations contributing to the discourse on AI standardisation. This in particular includes the contents of the EU proposal for an AI Regulation and of the standardisation request on AI issued by the European Commission in 2023 as well as the orientations set in the 2021 review of the Coordinated Plan.
Action 2: SDOs should further increase their coordination efforts around AI standardisation both in Europe and internationally in order to avoid overlap or unnecessary duplication of efforts and aim to the highest quality to avoid the creation and use of discriminating algorithms and to ensure a trustworthy and safe deployment of this technology.
Action 3: ESOs should coordinate with the Commission and appropriately direct their activities to ensure that the objectives set in the standardisation request on AI issued in 2023 are adequately and timely fulfilled. This includes ensuring active participation of representatives from SMEs and civil society organisations in their activities.
Action 4: Taking into account the cross-sectorial aspects of the proposed AI Regulation and the interactions between the AI Regulation and existing or future sectorial safety legislation (for example the proposed new EU Regulation on machinery products), ESOs shall devote specific attention to the elaboration of standards on the methodology of risk assessment of cyber-physical products powered by AI and on the testing framework.
Action 5: EC and ESOs should coordinate to promote mobilisation of stakeholders around AI standardisation activities.
Action 6: EC/JRC to coordinate with SDOs and other initiatives on developing analysis of AI standards and gap analysis to inform SDOs planning of activities.
The IETF Autonomic Networking Integrated Model and Approach Working Group will develop a system of autonomic functions that carry out the intentions of the network operator without the need for detailed low- level management of individual devices. This will be done by providing a secure closed-loop interaction mechanism whereby network elements cooperate directly to satisfy management intent. The working group will develop a control paradigm where network processes coordinate their decisions and automatically translate them into local actions, based on various sources of information including operator-supplied configuration information or from the existing protocols, such as routing protocol, etc.
Autonomic networking refers to the self-managing characteristics (configuration, protection, healing, and optimization) of distributed network elements, adapting to unpredictable changes while hiding intrinsic complexity from operators and users. Autonomic Networking, which often involves closed-loop control, is applicable to the complete network (functions) lifecycle (e.g. installation, commissioning, operating, etc). An autonomic function that works in a distributed way across various network elements is a candidate for protocol design. Such functions should allow central guidance and reporting, and co-existence with non-autonomic methods of management. The general objective of this working group is to enable the progressive introduction of autonomic functions into operational networks, as well as reusable autonomic network infrastructure, in order to reduce operating expenses.
https://wiki.ietf.org/en/group/iab/Multi-Stake-Holder-Platform#h-319-artificial-intelligence
Editor's note: No specific work identified in the IETF or IRTF
RP: The development of quantum technologies and infrastructures is a key objective of the 2030 Path to the Digital Decade[1] policy programme. The Commission has set a specific target for quantum (by 2025, the EU should have its first computer with quantum acceleration, paving the way for being at the cutting edge of quantum capabilities by 2030), and has proposed to set up a number of multi-country projects together with the MS (using the new instrument European Digital Infrastructure Consortium – EDICs) to ensure that this target is met. standardisation will be key, especially to develop quantum infrastructures with interoperable (certified) quantum technologies.
Action 1: CEN & CENELEC to continue the work on the standardisation landscape and gap analysis for quantum technologies (standardisation roadmap for Quantum Technologies) to identify which standards will be needed and for which applications. The roadmap should include recommendations for an action plan and a methodology that will identify the most important needs that have to be standardised.
Action 2: SDOs should develop standards for supply chains for modular quantum computers and communication architectures, and their enabling technologies. Initially the focus should be on QT research infrastructure, evolving towards QT commercial infrastructure
Action 3: The creation of an intelligent Dashboard to support SMEs, in which the existing standards as well
the work relating to quantum technologies of the main standardisation bodies are presented. The dashboard will facilitate SMEs to identify relevant open-source projects in the field of Quantum Computing and Communications, e.g. providing tools for testing, benchmarking etc.
Action 4: SDOs to set up processes for eliciting industry standardisation needs, and industry alliances to coordinate their experts' efforts to contribute to standardisation.
Action 5: SDOs should further increase their coordination efforts in Europe and internationally around Quantum Technologies standardisation in order to to avoid overlap or unnecessary duplication of efforts.
Action 6: SDOs should appropriately consider the effect of quantum computing and Quantum communication technologies on cybersecurity and provide an overview and analyse whether new standards or updates of existing standards on safety, privacy and cybersecurity are required.
Action 7: SDOs should devote specific attention to the standardisation processes (public documents) and existing or future sectorial export control legislation.
Action 8: SDOs should cooperate with the EuroQCI and start forming the technical committees to create the necessary pre-standards/standards for the commercial quantum communication technology in synergy with the specific requirements that are being explored for a certification of the technology.
Action 9: SDOs should cooperate with the EuroHPC Joint Undertaking and start forming the technical committees to create the necessary pre-standards/standards for quantum computing technology in synergy with the specific requirements that are being explored for a certification of the technology.
Some IETF protocols rely upon cryptographic mechanisms that are considered secure given today’s “classical computers” but would be vulnerable to attacks by a Cryptographically Relevant Quantum Computer (CRQC). These mechanisms rely upon algorithms based on integer factorization or the discrete logarithm problem. Active work is underway to develop and validate Post-Quantum Cryptography (PQC) mechanisms that are expected to be resilient to the cryptanalysis capabilities of future CRQCs (e.g., CFRG, US NIST). Select IETF WGs (e.g., LAMPS, TLS, IPSECME, COSE) have already begun standardizing revised protocol behaviors. The focus of the Post-Quantum Use In Protocols Working Group is to support this growing body of work in the IETF to facilitate the evolution of IETF protocols and document associated operational guidance with respect to PQC.
The WG will provide a standing venue to discuss PQC (operational and engineering) transition issues and experiences to date relevant to work in the IETF. The WG will also provide a venue of last resort to discuss PQC-related issues in IETF protocols that have no associated maintenance WGs. This WG will not update existing protocols, specify new protocols, define new cryptographic mechanisms, or assess whether a given cryptographic mechanism is quantum-resistant.
The Internet Research Task Force (IRTF) has hosted the Quantum Internet Research Group (QIRG) since the IETF 101 meeting in March 2018. The QIRG has no official membership and participation is open to everybody. The Research Group communicates primarily through its mailing list which can be freely subscribed and posted to. The entire mailing list archive is publicly available online. The QIRG also holds two or three meetings per year, virtually or in-person, usually at the IETF meetings. The scope of the QIRG’s work is defined in its charter. A key goal of the QIRG is the development of an architectural framework delineating network node roles and definitions that will serve as the first step toward a quantum network architecture. However, it is important to note that the QIRG focuses on fully entanglement-based quantum networks. QKD and trusted repeater networks are also often discussed, but usually in the context of being a stepping stone towards such a full quantum internet. The QIRG, just like all the other IRTF Research Groups, does not work on standards. It is instead focused on developing research collaborations and teamwork in exploring research issues related to the Internet. Nevertheless, the Research Group does also work on producing technical documents on quantum networks. Currently, the research group is working on two documents:
Since quantum networks are so different when compared to classical networking, the QIRG is also focused on educating the classical networking community on this new subject. In addition to discussions on the mailing list, the QIRG also hosts seminars with speakers from both industry and academia. So far three such seminars have taken place:
https://wiki.ietf.org/en/group/iab/Multi-Stake-Holder-Platform#h-3111-quantum-technologies
Editor's note: No specific work identified in the IETF or IRTF
Editor's note: No specific work identified in the IETF or IRTF
Editor's note: No specific work identified in the IETF or IRTF
Editor's note: No specific work identified in the IETF or IRTF
RP: In the event of an accident, in-vehicle sensors will automatically trigger an eCall. An audio connection is made with the European emergency number 112 and routed to the PSAP. At the same time, an emergency message is sent, providing information (the minimum set of data, or MSD) including the time, location and driving direction. The emergency call can also be triggered manually. Further conformance, performance and periodic tests need to be developed and innovative solutions found for situations (such as low cost, low power P2WVs) where normal full eCall provisions are not practical. The European eCall Implementation Platform is making recommendations to ensure the best operation of the service and to take full advantage of all its possibilities. eCall is regulated for the life of the vehicle, and further provisions may be required in respect of periodic technical inspection (PTI) and test, and at end of life decommissioning. Recognising that introducing the service via new vehicle models will mean taking considerable time to equip all cars, EU regulation has already encouraged automotive manufacturers to voluntarily introduce eCall in existing models. However, now that the public land mobile network (PLMN) and PSAP support networks are in place and operational, there is a considerable aftermarket opportunity to bring the benefits of eCall to the current stock of vehicles throughout Europe, and several equipment vendors (both from within Europe and abroad) have already shown interest to fill this market niche, in some cases directly for 112-eCall, and in others for third-party service-supported eCall. Other entrants are expected. However, as it will prove more difficult to control the performance and quality of such aftermarket devices, there is an urgent need to develop standards for the physical parameters, installation and operational performance of such aftermarket devices, to enable adequate certification and PTI provisions. This will be essential to avoid PSAPs to be potentially inundated with false messages from such devices, and to increase the reliable and safe operation of such devices. Subsequently (voluntary) specifications have been developed to extend the benefits of eCall to all categories of vehicles, and to migrate from 2G/3G communications to any wireless IMS communications media, and in special circumstances, to be supported over satellite communications. As soon as the new specifications are validated it may be desirable to upgrade them to EN’s, so that they may be referenceable in extensions to the current regulations.
Action 1: SDOs to develop technical specification and standards for the implementation of eCall in vehicles of categories other than M1 and N1 and for other user types, taking into account requirements included within type-approval regulation and ongoing activities in this area (pilots, the Connecting Europe Facility (CEF), etc).
Action 2: SDOs to lay down physical and operating requirements for aftermarket in-vehicle devices.
Action 3: SDOs to draft guidelines on certification of eCall Systems including aftermarket in-vehicle devices.
Action 4: SDOs to provide conformance and performance tests to the recently developed standards for packet-
switched networks (HLAP E-UTRAN — LTE/4G and migration to further generations by use of an IMS sublayer)
Action 5: SDOs to develop conformance and performance tests for recently developed technical specifications / standards for the provision of the eCall service eCall via shared vehicle platforms (C-ITS).
Action 6: SDOs to produce detailed conformity test specifications in support of certification schemes and periodic testing on IVS equipment.
Action 7: SDOs to carry out plugtest interoperability events, taking into account the technological evolution of the system [1].
Action 8: SDOs to collect feedback about the early versions of the standards and their implementation with technical representatives from vendors and implementers.
Action 9: SDOs to collect feedback from the relevant stakeholders on the real operation of the eCall service and when needed improve the standards, including through the European eCall Implementation Platform.
Action 10: SDOs to consider any changes to eCall that may be relevant in a 5G paradigm.
Action 11: In view of technology and networks evolution , SDOs to consider the development of conformance and interoperability test specifications for eCall provided over 4G (using VoLTE) and 5G (and VoNR) networks. When developing these specifications, considered the work done in CEN TS 17240
The Emergency Context Resolution with Internet Technologies (ECRIT) Working Group has developed a general architecture for enabling IP applications to discover and connect to emergency services.
The Geographic Location/Privacy (GEOPRIV) Working Group has developed protocols that allow IP networks to inform end devices about their geolocation, a critical pre-requisite for emergency calling.
The application-specific working groups in the IETF (for example, the Session Initiation Protocol Core (SIPCORE) Working Group) have developed extensions to support emergency calling as required.
https://wiki.ietf.org/en/group/iab/Multi-Stake-Holder-Platform#h-325-ecall
Editor's note: No specific work identified in the IETF or IRTF
Editor's note: No specific work identified in the IETF or IRTF
RP: The lack of commonly agreed standards in support of electronic communications networks for the emergency call service in Europe is a barrier to implementing future proof solutions which meet the requirements of the amended Universal Service Directive (Directive 2002/22/EC). Standards for total conversation access to 112 are required to meet special needs for users’ rights under Directive 2009/136/EC. The lack of harmonised values for location accuracy and reliability hampers Member State's efforts to develop adequate solutions.
Action 1: SDOs to update the existing standards to reflect the conceptual framework of the Directive (EU) 2018/1972, in particular where the concept of 'emergency services' is not consistently used to reflect the 'public safety answering points' or 'emergency communications' (for example ETSI TS 103 479).
Action 2: SDOs to address data protection and privacy requirements (privacy by design) in ongoing standardisation activities concerning emergency communications and processing and transmission of caller location information.
Action 3: SDOs to identify the applicable specifications and standardisation needs for the transmission of handset derived caller location to the most appropriate PSAPs by mobile network operators in both, user plane and control plane modes.
Action 4: SDOs to identify interoperability issues for packet switched emergency communications (e.g: VoLTE) at network and handset level, in particular when using roaming services.
Action 5: SDOs to set requirements, functional architecture, protocol and procedures specification for a Pan European mobile emergency application. Identify standardisation needs for the deployment of emergency applications enhanced with caller location information and accessibility features for the widest range of users, including end-users living with disabilities.
Action 6: ESOs to elaborate standards on accessibility of emergency communications as arising under the European Accessibility Act.
Action 7: to support the standardization of emergency SMS, in particular to '112', to enable the correct routing while roaming services are used.
Action 8: SDOs to define dictionaries for public warning messages for emergency communication services based on the input of various civil protection agencies.
Action 9: SDOs to identify standardisation needs for the establishment of a Union wide public warning system in line with recital 294 of Directive (EU) 2018/1972.
The Emergency Context Resolution with Internet Technologies (ECRIT) Working Group has developed a general architecture for enabling IP applications to discover and connect to emergency services.
The Geographic Location/Privacy (GEOPRIV) Working Group developed protocols that allow IP networks to inform end devices about their geolocation, a critical pre-requisite for emergency calling.
The application-specific working groups in the IETF (for example, the Session Initiation Protocol Core (SIPCORE) Working Group) have developed extensions to support emergency calling as required.
The Secure Telephone Identity Revisited (STIR) WG is developing Internet-based mechanisms that allow verification of the calling party's authorisation to use a particular telephone number for an incoming call. The main focus is on the SIP as one of the main VoIP technologies used by parties that want to misrepresent their origin, in this context the telephone number of origin. See, for example, RFC7375 "Secure telephone identity threat model".
Editor's note: No specific work identified in the IETF or IRTF
Editor's note: No specific work identified in the IETF or IRTF
Editor's note: No specific work identified in the IETF or IRTF
Editor's note: No specific work identified in the IETF or IRTF
Editor's note: No specific work identified in the IETF or IRTF
RP: Blockchain has great potential in providing an infrastructure for trusted, decentralised and disintermediated services beyond the financial sector. The first Semester of 2018 has seen $6.3bn invested in ICOs and $885mn for VC.[1]
While the FinTech? industry has been an early adopter because of its early awareness of bitcoin, blockchain will benefit many other industries. It is considered a foundational technology that some compare to the raise of the Internet in the early 90s. More than a technology, it could lead to a major political innovation by redefining the way we operate transactions, access information and share data (e.g. empowering patients to securely share e-health records and decide who to grant access to their data).
Blockchain is a promising technology to share data and manage transactions in a controlled manner, with many possible applications to deliver social goods in the field of eHealth and eGovernment, health records, land registries or the security certification of links in an Internet of Things chain of devices, manage intellectual property rights and eID.
It has also great potential for the private sector, in trading, contracting, supply chain management, traceability along industrial supply chains (e.g. on social & environmental conditions of work, on material composition or on the maintenance history of the item) and much more. It may also transform the governance of private organisations and of companies (concept of Decentralised Autonomous Organisation - DAO), and hence impact labour rights. Furthermore, from a regulatory and supervisory point of view, it can provide regulators with the same view into the data as the companies they're regulating, thereby reducing fraud and compliance costs.
However, this process is hindered by a lack of harmonisation and interoperability that constitute obstacles to cross border and cross sector transactions. The responsibility for public policy-makers would be to support innovation within a safe and future-proof technological and regulatory environment, ensuring appropriate transparency, accessibility, monitoring and governance
In the context of a DSM where the amount of online transactions and data is exploding, setting the right conditions for the advent of an open, trustworthy, transparent, compliant and authenticated transaction system is a real challenge for the EU. Existing decentralised environments lack trust, accountability, interoperability, regulatory certainty and mature governance models.
Action 1: The standardisation community should continue analysing possible standardisation gaps and reflect on best way to fill them. Activities may focus on governance and interoperability, organisational frameworks and methodologies, processes and products evaluation schemes, Blockchain and distributed ledger guidelines, smart technologies, objects, distributed computing devices and data services.
Action 2: Regularly update the white paper on the EU perspective on blockchain/DLT standardisation.
Action 3: Continue identifying use cases which are relevant for EU (including EU regulatory requirements like from GDPR, ePrivacy, eIDAS, AMLD, TOOP, etc..) and submit them to relevant standardisation bodies, including CEN & CENELEC and ETSI, and also ISO, ITU
Action 4: Continue identification of actual blockchain/DLT implementations in the EU and assess the need for standardisation, harmonisation and workforce training or adaptation.
Action 5: Standardisation of the operation and reference implementation of permissioned distributed ledgers and distributed applications, with the purpose of creating an open ecosystem of industrial interoperable solutions.
Action 6: Standards Development Organisations active in blockchain/DLT standardisation to liaise and coordinate to take advantage of synergies and maximise resources, including with relevant public and private partnerships
Action 7: ESOs to develop standards in line with the Data Act legislative proposal, in particular regarding essential requirements for smart-contracts. In addition, it would be recommended to explore a general framework for Governance of the European networks based on DLT to allow the flow of smart contracts between different networks.
Action 8: ESOs to develop the standards needed for the introduction of Digital Euro (CBDC) and token economy (upcoming MiCA Regulation), in particular to ensure interoperability with smart-contracts, legacy systems, etc. The revised legislative proposal of MiCA regulation introduces links with the EU Sustainable Finance taxonomy, thus activities towards assessing CO2 footprint of different blockchains/DLTs are very welcome.
Action 9: SDOs to develop standards to support the eIDAS2 proposal requirements related to Electronic Ledgers.
Action 10: Standardisation efforts to analyze and if needed, enhance the interoperability and international compatibility of the current and pending EBSI topics and capabilities previously mentioned.
The Decentralized Internet Infrastructure Research Group (DINRG) investigates open research issues in decentralizing infrastructure services such as trust management, identity management, name resolution, resource/asset ownership management, and resource discovery. The focus of DINRG is on infrastructure services that can benefit from decentralization or that are difficult to realize in local, potentially connectivity-constrained networks. Other topics of interest are the investigation of economic drivers and incentives and the development and operation of experimental platforms. DINRG will operate in a technology- and solution-neutral manner, i.e., while the RG has an interest in distributed ledger technologies, it is not limited to specific technologies or implementation aspects.
Editor's note: No specific work identified in the IETF or IRTF
RP: Standards are needed to cover the communication needs of the grid management, balancing and interfacing with the millions of new renewable sources, as well as standards for the complex interactions of the new distributed energy market, and in special a transparent Demand Response scheme which is accessible for all consumers. Communication standards will also be crucial for the deployment of electric cars and the building-up of smart cities. Harmonised communication protocols would provide standard components and interfaces giving ‘plug-and-play’ capability for any new entrant to the network, such as renewables or electric cars, or the use of open architectures based on global communication standards. To further promote interoperability, in addition to standardisation, testing and profiling should also be considered. A major challenge is engaging the right stakeholders which need to be brought together to conduct the standardisation work taking into account that between smart grid management (of relevance to utility producers, the utility network operators) and smart consumption (involving the end consumer) a seamless environment should be established where interests are not identical and potentially conflicting.
Action 1: Active involvement and participation of CEN & CENELEC CG-SG experts in the ongoing work of the Smart Grids Task Force on interoperability for access to data in a smart grid environment, building upon available standards. This is to prepare the ground for implementing acts on interoperability requirements and transparent and non-discriminatory procedures for access and exchange of data. The respective reports from this latest strand of work, as well as earlier deliverables from other activities of the Task Force are available on the smart grids task force dedicated webpage (CIRCA BC), which is a collaborative platform that gives access to all task-force documents, via the platform library”.
Action 2: ETSI, CEN & CENELEC and the other relevant SDOs and related organisations (such as DLMS, KNX and others) should combine their efforts to further enrich and extend the SAREF4ENER extension as well as the main SAREF ontology (including interoperability profiles and associated justifications (interoperability cases) from large-scale projects). The ETSI SAREF portal, which was launched recently, could be one of the tools to be leveraged for this purpose. Security aspects should be investigated. All new additions to the SAREF specifications should be transposed into the OneM2M specifications. A number of European projects could contribute to a larger scale deployment of SAREF-based solutions such as the Operational Digital Platforms under CEF Digital and the deployment of a common European data space in the DIGITAL programme, which will be prepared in Horizon Europe. An EN describing the principles of SAREF, thus avoiding annual updates, which is in the pipeline, should be completed. The updates needed to make SAREF fit for digital twins, edge-cloud IoT continuum, AI as well as other recent technological developments should be investigated and developed.
Action 3: CEN & CENELEC, IEEE and OASIS to foster their cooperation to ensure complementary parallel standardisation efforts, to avoid serious conflicts between their respective standardisation deliverables. This action should notably be undertaken in the context of H2-type standards (the interface used for smart grid communication), distributed energy resources and the smart grids architecture model as developed under M/490.
Action 4: ETSI, CEN & CENELEC should collaborate with the H2020 IoT Large Scale Pilot on Smart Grids and Smart Homes INTERCONNECT to include the outcomes and recommendations from the project into the SAREF4ENER and SAREF4BLDG standards. All new additions to the SAREF specifications should be transposed into the OneM2M specifications. The principles of SAREFisation should also be included.
Action 5: ETSI, CEN & CENELEC should collaborate with (or participate in) the Horizon Europe projects, which will establish the foundations for a Common European Energy Dataspace, and help identify, develop and standardise a set of common technical specifications for it. They should also collaborate with an upcoming Horizon Europe project on establishing an interoperable ecosystem in the energy area through creating a set of Minimum Interoperability Mechanisms for the energy sector.
Action 6: SDOs and related stakeholders and initiatives should work towards cross-sector interoperability, in particular for data exchange between grid, building and mobility domains.
Action 7: SDOs, in particular their grid-oriented, mobility-oriented, DER-oriented and storage-oriented technical committees, should cooperate to develop standards enabling the electric vehicles (with their – on-board or off-board – chargers) to play an active role through demand-response up to offering grid services.
Action 8: SDOs should collaborate with the project(s) resulting from call HORIZON-CL5-2023-D3-01-15 “Supporting the green and digital transformation of the energy ecosystem and enhancing its resilience through the development and piloting of AI-IoT Edge-cloud and platform solutions” to modify existing standards or adopt new ones based on the standardisation work and deliverables of the project(s).
RFC6272 identifies the key infrastructure protocols of the Internet Protocol Suite for use in the Smart Grid. The target audience is those people seeking guidance on how to construct an appropriate Internet Protocol Suite profile for the Smart Grid. In practice, such a profile would consist of selecting what is needed for Smart Grid deployment from the picture presented here.
The Energy Management (EMAN) WG has produced several specifications for an energy management framework, for power/energy monitoring and configuration. See http://datatracker.ietf.org/wg/eman/documents/ for the details. The framework focuses on energy management for IP-based network equipment (routers, switches, PCs, IP cameras, phones and the like).
Many of the IETF Working Groups listed under section 3.1.4 Internet of Things above are developing standards for embedded devices that may also be applicable to Smart grids.
https://wiki.ietf.org/en/group/iab/Multi-Stake-Holder-Platform#h-341-smart-grids-and-smart-metering
RP: In standards terms, there are some over-arching requirements, concerning standards for the way cities are managed, for common terminologies, for citizens’ interface with their local authority, etc. But mainly, smart city standards topics relate to the need to ensure commonalities —as far as these are appropriate and cost-effective— between the approaches taken by the different application areas, to enable the city to derive the best horizontal advantage from its overall approach and above all benefit from interoperability. The standards requirements as such for these application areas are specified in the Rolling Plan elsewhere at the appropriate points. The core components in such a complex system are the frameworks that assist companies, cities and other actors to provide appropriate solutions that prioritise economic, social and environmental outcomes. Solutions should address the whole lifecycle, optimising environmental, social and economic outcomes through the seamless transfer of information.
Action 1: Concerning Local Digital Twins, the following should be undertaken:
Action 2: SSDOs to consider the recommendations of the ETSI Technical Report 103 455 “Smart cities and communities; standardisation for citizens and consumers” and review how they could incorporate the proposals for organizational improvements to benefit smart city standardisation’s coverage of citizen/consumer issues, and for guidance material, codes of conduct and standards.
Action 3: Taking into account the results of the EU funded projects ESPRESSO and SynchroniCity, and in cooperation with city-led initiatives like the Smart Cities Marketplace demand-side group on Urban Platforms, the Open and Agile Smart Cities (OASC) network and Living-in.EU, SDOs should continue developing standards and technical specifications needed for a global market of open service platforms and applications for cities and communities,including for local digital twins, aligning their activities and integrating different standards and complementing protocols and communication standards. Possible actions in this sense could be:
Action 4: Define a set of standards and related criteria, value proposition and applicability statements for the deployment of platforms for cities and communities under the Digital Europe Programme. The set will be based on the EIP-SCC Reference architecture and design principles for urban platforms, the OASC Minimum Interoperability Mechanisms, OneM2M, NGSI-LD and SAREF and will further specify the minimum standardisation requirements to be met to achieve the goal of Interoperable European ecosystem of platforms and applications.
Action 5: Related to the CitiVerse, define a pre-standardisation roadmap to cater for a set of well-stablished technical standards to address the technological challenges and constraints arising from vertical technologies, and key enablers touching intrinsic EU-values, such as trust, security, privacy, sustainability and accessibility, openness, interoperability. All of it, driven by concrete use cases focusing on citizen’s engagement and predictive services for city’s efficiency.
The Energy Management (EMAN) WG has produced several specifications for an energy management framework, for power/energy monitoring and configuration. See http://datatracker.ietf.org/wg/eman/documents/ for the details. The framework focuses on energy management for IP-based network equipment (routers, switches, PCs, IP cameras, phones and the like).
A recently published standards track specification (RFC7603) presents the applicability of the EMAN information model in a variety of scenarios with cases and target devices. These use cases are useful for identifying requirements for the framework and MIBs. Further, it describes the relationship of the EMAN framework to other relevant energy monitoring standards and architectures.
Many of the IETF Working Groups listed under section 3.1.4 Internet of Things above are developing standards for embedded devices that may also be applicable to this section.
RP: A key challenge is achieving transparency around claims relating to the environmental performance of ICT products and services, and setting an effective basis to drive competition.
Action 1: Definition of Global KPIs for Energy Management of Fixed and Mobile access, and Core networks.
Action 2: Guidelines for the use of Global KPIs for Data Centres.
Action 3: Definition of Global KPIs for Data Services.
Action 4: Guidelines for the definition of Green Data Services.
Action 5: Definition and guidelines of KPIs for ICT networks.
Action 6: SDOs to identify needs and develop standards to support UN SDGs, in particular KPI for both synergies and conflicts in Digital transformation and Green transition projects.
Action 7: ETSI, in collaboration with the EGDC, to consider possible paths for ITU L.1480 and L.1333 to be made available for European standardisation to meet EU policy objectives.
The Energy Management (EMAN) Working Group has produced several specifications for an energy management framework, for power/energy monitoring and configuration. See http://datatracker.ietf.org/wg/eman/documents/ for the details. The framework focuses on energy management for IP-based network equipment (routers, switches, PCs, IP cameras, phones and the like).
A recently published standards track specification (RFC7603) presents the applicability of the EMAN information model in a variety of scenarios with cases and target devices. These use cases are useful for identifying requirements for the framework and MIBs. Further, it describes the relationship of the EMAN framework to other relevant energy monitoring standards and architectures.
The Internet Architecture Board has recently established the Environmental Impacts of Internet Technology (E-Impact) program as a venue for discussing environmental impacts and sustainability of Internet technology. Within this scope, the program looks at trends, issues, improvement opportunities, ideas, best practices, and subsequent direction of work related to Internet technology, architecture, and operations, including visibility and efficiency on energy and other environmentally-impacting attributes. In particular, the group focuses on Internet architecture's role in these topics.
https://wiki.ietf.org/en/group/iab/Multi-Stake-Holder-Platform#h-343-ict-environmental-impact
Editor's note: No specific work identified in the IETF or IRTF
RP: To take full advantage of the benefits that ICT-based systems and applications can bring to the transport sector it is necessary to ensure interoperability and continuity of the services among the different systems throughout Europe. The existence of common European standards and technical specifications is paramount to ensure the interoperability of ITS services and applications and to accelerate their introduction and impact. International cooperation aiming at global harmonisation should be pursued.
The IP Wireless Access in Vehicular Environments (ipwave) WG worked on Vehicle-2-Vehicle (V2V) and Vehicle-2-Internet (V2I) use-cases where IP is well-suited as a networking technology and will develop an IPv6 based solution to establish direct and secure connectivity between a vehicle and other vehicles or stationary systems. These vehicular networks are characterized by dynamically changing network topologies and connectivity.
V2V and V2I communications may involve various kinds of link layers: 802.11-OCB (Outside the Context of a Basic Service Set), 802.15.4 with 6lowpan, 802.11ad, VLC (Visible Light Communications), IrDA, LTE-D, LP-WAN. One of the most used link layers for vehicular networks is IEEE 802.11-OCB, as a basis for Dedicated short-range communications (DSRC). Several of these link-layers already provide support for IPv6. However, IPv6 on 802.11-OCB is yet to be fully defined. Some aspects of the IPv6 over 802.11-OCB work have been already defined at IEEE 1609 and the specification produced by this working group is expected be compatible with these aspects.
This group's primary deliverable is RFC8691, a standard to specify the mechanisms for transmission of IPv6 datagrams over IEEE 802.11-OCB mode.
Editor's note: No specific work identified in the IETF or IRTF
Editor's note: No specific work identified in the IETF or IRTF
Editor's note: No specific work identified in the IETF or IRTF
Editor's note: No specific work identified in the IETF or IRTF
Editor's note: No specific work identified in the IETF or IRTF
Editor's note: No specific work identified in the IETF or IRTF
RP: U-space is a set of new services relying on a high level of digitalisation and automation of functions and specific procedures, supported by AI, designed to provide safe, efficient and secure access to airspace for large numbers of unmanned aircraft, operating automatically and beyond visual line of sight. This initiative confirms the EU’s ambition to develop sustainable and digital mobility solutions.'
Action 1: Based on the U-space regulatory framework, and in coordination with the European UAS Standardisation Coordination Group (EUSCG), standardise semantic and technical interoperability specifications to exchange U-space information and operational data:
Action 2: The following complementary actions could be developed in addition to the standardisation action:
The Drone Remote ID Protocol (drip) WG has recently formed in the IETF. Civil Aviation Authorities (CAAs) worldwide have initiated rule making for Unmanned Aircraft Systems (UAS) Remote Identification (RID). CAAs currently promulgate performance-based regulations that do not mandate specific techniques, but rather cite industry-consensus technical standards as acceptable means of compliance. One key standard is ASTM International (formerly the American Society for Testing and Materials) WK65041. This technical specification defines UAS RID message formats, and transmission methods. Network RID defines a set of information for UAS to be made available globally via the Internet. Broadcast RID defines a set of messages for UAS to send locally one-way over Bluetooth or Wi-Fi. WK65041 does not address how to populate/query registries, how to ensure trustworthiness of information, nor how to make the information useful.
DRIP’s goal is to specify how RID can be made trustworthy and available in both Internet and local-only connected scenarios, especially in emergency situations. Some UAS operate in environments where the network or the devices or both are severely constrained in terms of processing, bandwidth (e.g., Bluetooth 4 beacon payload is 25 bytes long), or battery life, and DRIP aims to function in these environments. The specifications produced by the WG will need to balance public safety authorities’ need to know trustworthy information with UAS operators’ and other involved parties’ privacy.
The working group will primarily leverage Internet standards (including HIP, EPP, RDAP, and DNS) and infrastructure as well as domain name registration business models. The WG will track and align with the requirements being developed by regulatory authorities, e.g., the International Civil Aviation Organization the European Union Aviation Safety Agency (EASA) delegated and implementing regulations, and the US Federal Aviation Administration (US FAA).
https://wiki.ietf.org/en/group/iab/Multi-Stake-Holder-Platform#h-3412-u-space
Editor's note: No specific work identified in the IETF or IRTF
2013-07-04: Initial layout and first draft descriptions added.
2013-08-04: Added reference to Emun WG in section 3.3.2
2014-03-12: Added link to the final document and modified link to point to more accessible MSP pages
2015-08-27: Updated the document reflecting the draft 2016 Rolling Plan
2016-08-08: Changed the structure, moving the materials related to RP2016 to a separate page. Updated with the current draft of the RP 2017
2016-08-23: A round of updates to reflect current work
2017-09-12: Backup RP2017, created template RP2018
2017-09-20: Update to reflect current IETF and IRTF work, and to include updated text from RP2018 regarding EC perspectives
2017-09-22: More updates to reflect current IETF/IRTF work
2018-08-27: Archived RP2018, updates to reflect RP2019 changes
2018-09-19: Final updates prior to submission to EC RP 2019
2019-09-03: Archived RP2019, updates to reflect RP2020 changes
2019-09-10: Minor updates to prepare for RP2020 draft submission deadline
2020-09-18: Archived RP2020, numerous updates to reflect RP2021 changes
2020-10-02: Revise text on QUIC prior to submission
2021-09-24: Archived RP2021, updates to reflect RP2022 changes from MSP, added text on asdf, iotops and madinas WGs.
2022-09-21: Archived RP2022, updates to reflect RP2023 changes from MSP, added text on qirg, ohai, ppm, httpapi, and tigress WGs.
2023-09-22: Archived RP2023, updates to reflect RP2024 changes from MSP, added updated text on RP Actions, updated references to relevant IETF work, updated all links from old trac instance to new IETF wiki.
Attachments:
089_draft_rolling_plan_tfrp055r3_rp.pdf
118_rev_1_rolling_plan_draft_final.pdf
The content of this page was last updated on 2022-09-21. It was migrated from the old Trac wiki on 2023-01-25.