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 (ford at isoc.org) or Andrei Robachevsky (robachevsky at isoc.org) 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 (2023 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 Andrei Robachevsky 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.
The following IETF WGs are 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://trac.ietf.org/trac/iab/wiki/Multi-Stake-Holder-Platform#dataEconomy
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 for critical infrastructure protection and thus in support of and responding to the requirements laid down in the NIS Directive.
ACTION 2 SDOs to assess existing standards required to support the European Cyber-security Certification Framework to ensure that standards are available for providing the core of any certification activity. In particular, SDOs are encouraged to work on standards related to the specification and assessment of security properties in ICT products and services as well as those related to security in processes related to the design, development, delivery and maintenance of an ICT product or service.
ACTION 3 SDOs to investigate the issue of malware on personal computers. ENISA (the European union agency for network and information security) has concluded that many personal computers contain malware that is can monitor (financial) transactions. As we are becoming increasingly dependent on eBusiness and e-transactions, a European initiative should investigate this topic
ACTION 4 SDOs to investigate requirements for secure protocols for networks of highly constrained devices and heavily constrained protocol interaction (low bandwidth/ ultra-short session duration (50ms)/low processing capabilities
ACTION 5 SDOs to investigate the availability of standards as regards to the security and incident notification requirements for digital service providers as defined in the NIS Directive
ACTION 6 SDOs to develop a “guided” version of ISO/IEC 270xx series (information security management systems including specific activity domains) specifically addressed to SMEs, possibly coordinating with ISO/IEC JTC1 SC27 WG1 to extend the existing guidance laid out in ISO/IEC 27003. This guidance should be 100% compatible with ISO/IEC 270xx and help SMEs to practically apply it, including in scarce resource and competence scenarios
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
ACTION 8 SDOs to prepare a report on measures to mitigate, prevent and/or detect CLI spoofing. The report should address the technical, operational, standardisation and cost aspects of the different possible solutions (STIR/SHAKEN, blockchain, Solid, etc.) from the European perspective. It should also consider how such solutions could be deployed and managed at the European level.
The following IETF WGs are active in this area:
The Managed Incident Lightweight Exchange (MILE) WG develops standards to support computer and network security incident management. The WG is focused on two areas: IODEF (Incident Object Description Exchange Format, RFC5070), the data format and extensions to represent incident and indicator data, and RID (Real-time Inter-network Defense, RFC6545), the policy and transport for structured data.
The Security Automation and Continuous Monitoring (SACM) WG worked on standardising protocols to collect, verify, and update system security configurations that allow a high degree of automation. This facilitates securing information and the systems that store, process, and transmit that information. The focus of the WG was the assessment of network endpoint compliance with security policies so that corrective measures can be provided before they are exposed to those threats.
The aim of DDoS Open Threat Signalling (DOTS) WG is to develop a standards based approach for the realtime signalling of DDoS related telemetry and threat handling requests and data between elements concerned with DDoS attack detection, classification, traceback, and mitigation.
The goal of the Interface to Network Security Functions (I2NSF) WG is to define a set of software interfaces and data models for controlling and monitoring aspects of physical and virtual NSFs. A Network Security Function (NSF) is a function used to ensure integrity, confidentiality, or availability of network communications, to detect unwanted network activity, or to block or at least mitigate the effects of unwanted activity. The hosted, or cloud-based, security service is especially attractive to small and medium size enterprises who suffer from a lack of security experts to continuously monitor networks, acquire new skills and propose immediate mitigations to ever increasing sets of security attacks.
There are many situations in which it is desirable to transfer a copy of a digital credential to another person. For example, a private car owner may want to provide access to their vehicle to a friend or a family member. A private homeowner may want to provide access to their home to their cat sitter. An individual staying at a hotel may want to transfer a copy of a hotel room key to their spouse. Today, no such standardized method exists in a cross-platform, credential type-agnostic capacity. The The Transfer dIGital cREdentialS Securely (tigress) Working Group will standardize a protocol that will facilitate such credential transfers from one person's device to another person's device.
The full list of IETF Working Groups in the Security Area is available here: https://datatracker.ietf.org/wg/#sec
https://trac.ietf.org/trac/iab/wiki/Multi-Stake-Holder-Platform#NISec
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.
Action 3: SDOs to investigate standards for supporting compliance and certification of compliance with GDPR and possible other EU data privacy requirements.
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/ andhttp://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 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 DNS Over HTTPS (doh) WG standardised encodings for DNS queries and responses that are suitable for use in HTTPS. This enables the domain name system to function over certain paths where existing DNS methods (UDP, TLS [RFC 7857], and DTLS [RFC 8094]) experience problems. DNS Queries over HTTPS (RFC8484) was published in October 2018.
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://trac.ietf.org/trac/iab/wiki/Multi-Stake-Holder-Platform#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://trac.ietf.org/trac/iab/wiki/Multi-Stake-Holder-Platform#FiveG
RP: The Communication on ICT Standardisation Priorities for the digital single market proposes priority actions in the domain of Cloud. Actions mentioned below reflect some of them.
Action 1: Identify needs for ICT standards to further improve the interoperability, data protection and portability of cloud services and start respective development activities.
Action 2: Promote the use of the ICT standards needed to further improve the interoperability, data protection and portability of cloud services.
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.
Action 4: Promote international standards on service level agreements (SLAs) and usage of the cloud code of conduct (CoC).
Action 5: ESOs are asked to update the mapping of cloud standards and guidelines for end-users (especially SMEs and the public sector), in collaboration with international SDOs, cloud providers and end users. This action could also draw on the material developed, e.g. to update the standards mapping carried out by cloud standards coordination phases 1 & 2.
Action 6: 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.
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://trac.ietf.org/trac/iab/wiki/Multi-Stake-Holder-Platform#Cloud
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.
Editor's note: No specific work identified in the IETF or IRTF
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 complement ongoing gap analysis by analysis of gaps in wireless technologies required by IoT, including URLL (Ultra Reliable Low Latency) technologies required by Industry Automation. Action 2: SDOs to continue ongoing work in the area of semantic standards for better data interoperability. Action 3: SDOs to provide standards that can be used for compliance for IoT products, systems, applications and processes. Action 4: Develop a European standard for cyber security compliance of products that is aligned with the current compliance framework of organisations based on ISO 270xx and the GDPR regulation. Preferably the standard could be used to harmonise the requirements set out in the NIS directive. Action 5: Promote the development and foster the adoption of the international Reference Architecture for IoT developed in ISO/IEC JTC 1 SC41. Action 6: SDOs to assess gaps and develop standards on 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.
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 focuses 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://trac.ietf.org/trac/iab/wiki/Multi-Stake-Holder-Platform#IOT
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. Build on the work done under Mandate M/460, in the following way: address the trust service providers (TSP) providing signature creation services, the TSPs providing signature validation services, and standards for trust application service providers. Support harmonisation of identity proofing, particularly in relation certificate issuance and remote signing.
Action 2. 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 3. Support and improve the development of interoperable standards by facilitating the organisation of plugtests (interoperability events) and developing and enhancing conformity testing tools. Such interoperability events may address CAdES, XAdES, PAdES, ASiC, use of trusted lists, signature validation, remote signature creation and validation, e-delivery services, preservation services, etc.
Action 4. Foster the development of standards supporting the implementation of the measures derived from the revision of the eIDAS regulation, aimed to improve its effectiveness, extend its benefits to the private sector and promote trusted digital identities for all Europeans.
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 develops 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.
https://trac.ietf.org/trac/iab/wiki/Multi-Stake-Holder-Platform#eIdentity
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 develop 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.
Action 2 SDOs to develop standardised methodology to run public consultations and map future broadband investments in the EU.
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.
https://trac.ietf.org/trac/iab/wiki/Multi-Stake-Holder-Platform#BImap
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.
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).
https://trac.ietf.org/trac/iab/wiki/Multi-Stake-Holder-Platform#ICTAccess
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: Foster coordination and interaction of all stakeholders in providing European requirements for AI, e.g. based on the work of the AI High Level Expert Group, Members States initiatives, OECD etc. Encourage the development of shared visions as a basis for input and requirements to standardisation
Action 2: SDOs should coordinate their efforts on AI standardisation in Europe and internationally, especially ISO/IEC JTC 1 SC 42
Action 3: SDOs should establish coordinated linkages with, and consider European requirements from, initiatives, including policy initiatives, and organisations contributing to the discourse on AI standardisation. This in particular includes the results of the EU HLEG on AI and also the European Parliament, Member States' initiatives, Council of Europe, and others
Action 4: SDOs to consider cybersecurity and related aspects of artificial intelligence, to identify gaps and develop the necessary standards on safety, privacy and security of artificial intelligence, to protect against malicious artificial intelligence and to use artificial intelligence to protect against cyber-attacks
Action 5: Within the AI4EU initiative, identify leading open source activities which complement standardisation work and analyse to what extend they respond to EU requirements. Where useful establish dialogue, liaisons or partnerships with such open source projects.
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://trac.ietf.org/trac/iab/wiki/Multi-Stake-Holder-Platform#AI
Editor's note: No specific work identified in the IETF or IRTF
https://trac.ietf.org/trac/iab/wiki/Multi-Stake-Holder-Platform#EGNSS
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, it is working on two Internet Drafts which the group aims to publish as informational RFCs (i.e. not standards specifications):
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://trac.ietf.org/trac/iab/wiki/Multi-Stake-Holder-Platform#Quantum
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 address data protection and privacy requirements (privacy by design) in ongoing standardisation activities concerning location accuracy.
Action 2 Identify standardisation needs for the deployment of 112 smartphone applications enhanced with caller location and multimedia features accessible for the widest range of users. Action 3 SDOs to complete the M/493 standards to support the location-enhanced emergency call service. Global standards bodies are invited to contribute taking into account next-generation networks and location accuracy and reliability. Action 4 SDOs to identify the standardisation needs for the transmission of the GNSS location data from the handset to the PSAPs by mobile network operators. Action 5 SDOs to define dictionaries for warning messages for emergency communication service based on the input of various civil protection agencies. Action 6 SDOs to add rich media to the EU-Alert.
Action 7 SDOs to define requirements for communications involving IoT devices in all types of emergency situations.
Action 8 SDOs to describe the architecture (currently named Next Generation Emergency Communication architecture), the core elements and corresponding technical interfaces for network independent access to emergency services.
Action 9 SDOs to set requirements, functional architecture, protocol and procedures specification for a Pan European mobile emergency application. Action 10 ESOs to elaborate standards on accessibility of emergency number 112 as arising under the European Accessibility Act.
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".
https://trac.ietf.org/trac/iab/wiki/Multi-Stake-Holder-Platform#Emergency
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.
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://trac.ietf.org/trac/iab/wiki/Multi-Stake-Holder-Platform#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
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: Traditional financial institutions realize they have a lot to lose or gain from the Fintech revolution and invest huge effort and money to adapt their technology and processes to adjust to a new environment, find a place in this new ecosystem, compete with new business models and respond to new consumer needs and behaviours. Across Europe, there has been considerable uptake of new digital channels: over 58% of Western Europeans (85% for Northern Europeans) prefer to use digital over physical branches, compared to 52% of US bank customers. These trends have grabbed the attention of investors who have made massive investments, growing by 75% in 2015 to $22.3bn, five times higher than in 2013.
Fintech start-ups appear with innovative solutions challenging existing financial services business models, markets and regulation. The existing legal framework is being reviewed at EU level and the concept of regulatory experimentation frameworks (or sandboxes) explored to help address this transformation and enable innovation.
Some regulatory adjustments have already been adopted such as amendments to the Anti-Money Laundering directive and the use of electronic identification. Since July 2016, the Electronic Identification and Trust Services Regulation can give e-transactions and other e-signed documents the same legal status as those that are paper-based. The new Capital Requirement Regulation CRR2 package adopted in 2016 takes technological innovations into consideration, and so is the 2017 Action Plan for Retail Financial Services.
Following several public consultations regarding financial services and the EU Parliament report on blockchain and virtual currencies, the Commission has set-up a horizontal Financial Technology Task Force to explore the impact of new financial technologies on consumers and businesses and the possible risks for financial stability. One of the work streams of the Task Force focuses on Interoperability and Standardisation.
In parallel, and in relation to the need for more harmonised supervisory reporting, in its Communication on the CfE: “EU regulatory framework for financial services" the Commission committed to investigate and address the concerns around the costs and complexity of reporting by undertaking a review of reporting requirements in the financial sector. This work is performed within the ongoing financial data standardisation (FDS) project which will produce a comprehensive mapping of reporting requirements and aims to develop a common language on financial data. This initiative forms a key contribution to the Commission's Better Regulation agenda and the Regulatory Fitness and Performance (REFIT) programme, which ensures that EU Legislation delivers results for citizens and businesses effectively, efficiently and at minimum cost.
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, TOOP, etc..) and submit them to relevant standardization 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: A general framework for Governance of the European networks based on DLT should be developed to allow the flow of smart contracts between different networks.
Action 8: ESOs to develop the standards needed for the for the introduction of a private-sector programmable Euro, in particular to ensure interoperability.
The Decentralized Internet Infrastructure Research Group (DINRG) will investigate 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.
More details of the DIN RG are available.
https://trac.ietf.org/trac/iab/wiki/Multi-Stake-Holder-Platform#Ledger
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.
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://trac.ietf.org/trac/iab/wiki/Multi-Stake-Holder-Platform#SmartGrid
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.
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.
https://trac.ietf.org/trac/iab/wiki/Multi-Stake-Holder-Platform#SmartEnergy
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.
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.
https://trac.ietf.org/trac/iab/wiki/Multi-Stake-Holder-Platform#ICTenvironment
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 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 https://datatracker.ietf.org/wg/geopriv/about/ 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 https://datatracker.ietf.org/wg/sipcore/about/ Session Initiation Protocol Core (SIPCORE) Working Group) have developed extensions to support emergency calling as required.
The IP Wireless Access in Vehicular Environments (ipwave) WG works 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 (and the only Standards track item) will be a document that will specify the mechanisms for transmission of IPv6 datagrams over IEEE 802.11-OCB mode.
https://trac.ietf.org/trac/iab/wiki/Multi-Stake-Holder-Platform#IntelligentTransport
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: between air navigation service providers, common information service providers and U-space service providers; and between U-space service providers and UAS operators.
Action 2: The following complementary actions could be developed in addition to the standardisation action: Development of a reference implementation of U-space software components to facilitate the adoption of U-space. Development of a testing platform to assess whether the U-space interfaces developed by service providers comply with the standardised specifications.
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).
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.
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.