ETSI GR ZSM 011 V2.1.1 (2024-09)

Zero-touch network and Service Management (ZSM); Intent-driven autonomous networks; Generic aspects

RGR/ZSM-011ed211_IntentDrv

General Information

• Status: Not Published
• Technical Committee: ZSM - Zero-touch network and Service Management
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Due Date: 11-Oct-2024
• Completion Date: 24-Sep-2024

Standards Content (Sample)

GROUP REPORT
Zero-touch network and Service Management (ZSM);
Intent-driven autonomous networks;
Generic aspects
Disclaimer
The present document has been produced and approved by the Zero-touch network and Service Management (ZSM) ETSI
Industry Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GR ZSM 011 V2.1.1 (2024-09)

Reference
RGR/ZSM-011ed211_IntentDrv
Keywords
automation, autonomic networking, generic

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2024.
All rights reserved.
ETSI
3 ETSI GR ZSM 011 V2.1.1 (2024-09)
Contents
Intellectual Property Rights . 6
Foreword . 6
Modal verbs terminology . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 9
3.3 Abbreviations . 9
4 The concept of intent-driven management . 9
4.1 Introduction . 9
4.2 Definition of intents. 10
4.2.1 Introduction. 10
4.2.2 Principles of intent . 11
4.2.3 Ensuring trust in intent-driven autonomy . 11
4.2.4 Additional aspects of intent . 12
4.3 Examples of use cases considered . 12
4.3.1 Introduction. 12
4.3.2 Automotive use case . 13
4.3.2.1 Description . 13
4.3.2.2 KPIs. 13
4.3.2.3 Intents . 14
4.3.3 Cloud Private Line services . 15
4.3.3.1 Description . 15
4.3.3.2 Intent parameters . 16
4.3.3.3 Intent translation . 17
4.3.3.4 CPL service delivery by Intent Management Entities . 17
5 Intent-driven management within the ZSM framework architecture . 17
5.1 The role of Intent Management Entity . 17
5.2 Mapping of ZSM closed loop concepts to Intent Management Entity operations . 19
5.3 Intent interactions between different management domains . 23
5.4 Intent model federation . 24
5.4.1 Introduction. 24
5.4.2 Criteria for selection of intent common models . 25
5.4.3 Intent common model from TM Forum . 25
5.4.4 Declarative Intent Model . 27
5.4.4.1 Intent Expectation . 27
5.4.4.2 Desired outcomes as intent targets . 27
5.4.4.3 Intents and Managed Entities . 27
5.4.4.4 Context and filter information . 28
5.4.4.5 Intent fulfilment status . 28
5.4.4.6 Class definitions . 28
5.5 Intent lifecycle . 30
5.5.1 Introduction. 30
5.5.2 Phases of the intent lifecycle. 30
5.5.3 States machine of intent handling . 31
5.6 Intent-based interface . 33
5.6.1 Introduction. 33
5.6.2 Relationship between intent owner and intent handler . 33
5.6.3 Operations on the intent interface . 34
5.6.3.0 Introduction . 34
5.6.3.1 Mandatory operations. 34
ETSI
4 ETSI GR ZSM 011 V2.1.1 (2024-09)
5.6.3.1.1 Introduction . 34
5.6.3.1.2 Create. 34
5.6.3.1.3 Read . 35
5.6.3.1.4 Update . 35
5.6.3.1.5 Delete. 35
5.6.3.2 Optional operations . 35
5.6.3.2.1 Introduction . 35
5.6.3.2.2 Judge . 35
5.6.3.2.3 Feasibility . 36
5.6.3.2.4 Best . 36
5.6.3.3 Optional operations to ensure confidence in intent-driven autonomy . 36
5.6.3.3.1 Introduction . 36
5.6.3.3.2 Activate . 36
5.6.3.3.3 Deactivate . 37
5.6.3.3.4 Suspend . 37
5.6.3.3.5 Resume . 37
5.6.3.3.6 Logging . 38
5.6.3.3.7 Notification . 38
5.6.3.3.8 Testing . 38
5.6.3.3.9 Verification of intent outcome . 39
5.6.4 Intent Management Entity registry . 39
5.7 Handling management conflicts . 40
5.7.1 Introduction. 40
5.7.2 Categories of intent conflicts . 41
5.7.3 Intent - Non-Intent Conflicts . 41
5.7.4 Potential intent conflict resolution approaches . 41
5.8 Intent translation . 42
5.8.1 Intent translation: background . 42
5.8.2 Intent translation: methods . 42
5.9 Potential deployment of intent interface . 43
6 Next steps of standardization activities for ZSM Intent-driven autonomous networks . 44
6.1 Summary of the present document . 44
6.2 Challenges faced on the present document . 44
6.3 Potential future work based on the present document . 44
Annex A: Examples of intents . 46
Annex B: Required Classes of the declarative intent model . 48
B.1 Example of declarative intent model . 48
B.2 Intent <> . 48
B.3 IntentExpectation <> . 49
B.4 IntentTarget << dataType >> . 50
B.5 context << datatype >> . 50
B.6 fulfillmentInfo << dataType >> . 51
Annex C: Testing intent-based autonomous networks and services. 52
Annex D: Alternative Concepts of Intent modelling . 53
D.1 List of challenges . 53
D.2 Service catalog . 54
D.3 Intent model . 54
D.4 Intent-based service model . 55
Annex E: Industry progress of Intent Standardization . 56
E.0 Introduction . 56
ETSI
5 ETSI GR ZSM 011 V2.1.1 (2024-09)
E.1 TM Forum ANP . 56
E.1.1 Definition of Intent . 56
E.1.2 Properties of Intent . 56
E.1.3 Meta Model of Intent . 56
E.1.4 Intent Management . 57
E.2 3GPP SA5 . 57
E.2.1 Definition of Intent . 57
E.2.2 Properties of Intent . 57
E.2.3 Definition of Intent Model. 57
E.2.4 Intent Management . 58
E.3 IRTF NMRG . 58
E.3.1 Definition of Intent . 58
E.3.2 Properties and Principles of Intent . 58
E.3.3 Definition of Intent Model. 58
E.3.4 Intent Management . 59
E.4 ETSI NFV . 59
E.4.1 Definition of Intent . 59
E.4.2 Definition of Intent Model. 59
E.4.3 Intent Management . 59
E.5 ETSI F5G . 60
E.5.1 Definition of Intent . 60
E.5.2 Definition of Intent Model. 60
E.5.3 Intent Management . 60
Annex F: Bibliography . 61
Annex G: Change History . 62
History . 63

ETSI
6 ETSI GR ZSM 011 V2.1.1 (2024-09)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Zero-touch network and
Service Management (ZSM).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
7 ETSI GR ZSM 011 V2.1.1 (2024-09)
1 Scope
The present document studies how intent-based management can be used to enable autonomous networks. Intent-based
management enables simpler, more user-friendly expressions of input information, and higher flexibility in automation.
Intent is a key enabler to increase automation and make management simpler; therefore the present document
investigates the potential use of intents as key enabler for enhancing autonomous network and service management
within ZSM framework. It provides a formal definition of intents and a list of principles of intent-driven management,
leveraging existing standardization work. Some use cases are also included in the present document to provide
examples of management domains where intents are applicable and capabilities that may be needed. Intent-driven
management within the ZSM framework is investigated and the concept of an intent management entity is introduced,
which is responsible for the life cycle management of intents and the exchange of intents between different management
domains. The present document also maps the intent management entity with the concept of closed loops that is
specified in ETSI GS ZSM 009-1 [i.14]. Intent modelling is also investigated, and two different approaches are
proposed. The present document defines intent life cycle phases and a state diagram, together with a set of (mandatory
and optional) interface capabilities that are needed for the life cycle management of intents. Finally, additional aspects
such as conflicts between intents, intent translation, and intent testing are investigated. The present document outlines
potential future work based on the topics explored and the critical areas that were identified in the present document.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are not necessary for the application of the present document, but they assist the
user with regard to a particular subject area.
[i.1] ETSI GR ZSM 005: "Zero-touch network and Service Management (ZSM); Means of
Automation".
[i.2] TM Forum IG1230: "Autonomous Networks Technical Architecture v1.1.1".
[i.3] IETF RFC 9315: "Intent-Based Networking - Concepts and Definitions".
[i.4] ETSI TS 128 312: "LTE; 5G; Management and orchestration; Intent driven management services
for mobile networks (3GPP TS 28.312 Release 17)".
[i.5] TM Forum IG1253: "Intent in Autonomous Networks v1.3.0".
[i.6] TM Forum TR290: "Intent Common Model v3.4.0".
[i.7] TM Forum TR290A: "Intent Common Model - Intent Expression v3.4.0".
[i.8] TM Forum TR290B: "Intent Common Model - Intent Reporting v3.4.0".
[i.9] TM Forum TR290V: "Intent Common Model - Vocabulary Reference v3.4.0".
[i.10] TM Forum TR291: "Intent Extension Models v3.4.0".
[i.11] TM Forum IG1253C: "Intent Life Cycle Management and Interface v1.1.0".
ETSI
8 ETSI GR ZSM 011 V2.1.1 (2024-09)
[i.12] TeraFlow Project: "Secured autonomic traffic management for a Tera of SDN Flows".
[i.13] TeraFlow Project: "Scenarios".
[i.14] ETSI GS ZSM 009-1: "Zero-touch network and Service Management (ZSM); Closed-Loop
Automation; Part 1: Enablers". ®
[i.15] W3C Recommendation 25 February 2014: "RDF 1.1 Concepts and Abstract Syntax".
[i.16] ETSI GS ZSM 007: "Zero-touch network and Service Management (ZSM); Terminology for
concepts in ZSM".
[i.17] Dave Lenrow: "Intent: Don't Tell Me What to Do! (Tell Me What You Want)".
[i.18] ETSI GS ZSM 009-2: "Zero-touch network and Service Management (ZSM); Closed-Loop
Automation; Part 2: Solutions for automation of E2E service and network management use cases".
[i.19] IETF RFC 9316: "Intent Classification".
[i.20] ETSI GR NFV-IFA 041 (V4.1.1): "Network Functions Virtualisation (NFV); Release 4
Management and Orchestration; Report on Enabling Autonomous Management in NFV-MANO".
[i.21] ETSI GS F5G 006 (V1.1.1): "Fifth Generation Fixed Network (F5G); End-to-End Management
and Control; Release #1".
[i.22] ETSI GS NFV-IFA 050 (V4.5.1): "Network Functions Virtualisation (NFV); Release 4
Management and Orchestration; Intent Management Service Interface and Information Model
Specification".
[i.23] TM Forum 921A: "Intent Management API Profile v1.1.0".
[i.24] TM Forum: "Intent-driven autonomous networks - Phase III".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GS ZSM 007 [i.16] and the following apply:
autonomous entity: part of a network that is capable of making and actuating decisions within its specified degree of
autonomy and area of influence
NOTE: In the ZSM Framework a Management Domain is an example of an autonomous entity.
intent: formal specification of the expectations, including requirements, goals, and constraints, given to a technical
system
NOTE: See TM Forum IG1230 [i.2].
intent handler: logical entity that receives intents (i.e. the intent information objects) and handles them in the domain
that is responsible for that intent's fulfilment
NOTE: An intent handler is not allowed to modify and/or remove an intent but can reject to fulfil it. It fulfils the
requirements and goals, based on the resources and solutions it has available once it has accepted the
intent. An intent handler reports back to the intent owner regarding the intent fulfilment.
intent information object: information object that represents a specific set of requirements, goals and constraints
which are structured according to the intent IOC
intent information object class: object class that describes the type, structure and relationships of the information
elements that specify the requirements, goals, and constraints of an intent
ETSI
9 ETSI GR ZSM 011 V2.1.1 (2024-09)
intent management entity: autonomous entity in a domain that can play the role of intent owner and/or intent handler
and is capable of making and actuating decisions to fulfil intents
intent negotiation: procedure involving an intent owner and an intent handler where the intent fulfilment terms are
settled prior to the intent being accepted by the intent handler
NOTE 1: Alternatively, an intent negotiation could also result in a rejection of the intent.
NOTE 2: An intent handler is an autonomous entity in a domain for the aspect of intent fulfilment.
intent object instance: unique managed object instance that is instantiated at the intent handler (MnS producer) based
on the information of intent requirements, goals and constraints sent to the intent handler (MnS producer) by the intent
owner (MnS consumer)
intent owner: logical entity that originates intents (creating intent information objects) and is responsible for managing
its lifecycle. Ideally only an intent owner is allowed to manage the intent lifecycle
opportunity cost: cost of a particular good or service compared to an alternative
NOTE: Opportunity cost is a term used in economics. When consumers or businesses make the decision to
purchase or produce particular goods, they are doing so at the expense of buying or producing something
else. This is referred to as the opportunity cost.
producer utility: total benefit for a producer to supply a good or service
utility: total satisfaction received from consuming a good or service
NOTE: Utility is a term used in economics. Economic theories based on rational choice usually assume that
consumers will strive to maximize their utility. The utility is subjective. It depends upon the mental
assessment of the consumer and is determined by several factors which influence the consumer's
judgment.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS ZSM 007 [i.16] and the following apply:
CFS Customer Facing Service
IOC Information Object Class
MnS Management Service
OPEX OPerational EXpenditure
4 The concept of intent-driven management
4.1 Introduction
In an autonomous networks management framework that is purely intent-driven, all goals and expected behaviour are
defined with intents. The management framework will only perform operations that relate to the fulfilment and
assurance of an intent, which means that all goals - including those that may have been considered "common sense" in
human-operated systems - are to be expressed as intents.
An intent in an autonomous management framework is expressed declaratively - that is, as a goal that describes the
properties of a satisfactory outcome rather than prescribing a specific solution. This gives the framework the flexibility
to explore various solution options and find the optimal one. It also allows the framework to optimize by choosing its
own actions and decisions, e.g. exactly which service to instantiate, or configuration to make, that will ultimately
maximize utility.
ETSI
10 ETSI GR ZSM 011 V2.1.1 (2024-09)
Unlike traditional software systems, where requirements are analysed offline to detect and resolve conflicts prior to
implementation, intents are added to an autonomous framework during runtime. Adaptation to changed intent as well as
conflict detection and resolution are therefore essential capabilities of an autonomous framework.
Expectations originate from contracts or business strategy and remain constant when the underlying framework is
replaced or modified. Consequently, when setting up the intents, it is important that they are formulated in an
infrastructure-agnostic form, so that they can be transferred across network and infrastructure implementations,
i.e. vendor, technology, and operator agnostic.
As described in clause 5.2, intents can be used for interactions between management service consumer and management
service producer in intent-driven management. From the management service consumer's perspective, an intent that is
used in such an interaction is agnostic to the management service producer's infrastructure and the resources that are
ultimately used in the intent fulfilment.
In short, the intent establishes a universal mechanism for defining expectations for different layers of network
operations. It expresses goals, utility, requirements, and constraints. It defines expectations on service delivery as well
as the behaviour of the autonomous management framework and the underlying managed network.
An original intent will be transformed and decomposed when transferred between different domains. At each stage it
can be decomposed into several new declarative intents and also, partly or completely, transformed into various actions.
In addition, the decomposition and transformation will happen not only when the intent will be transferred between
different domains but also between the different levels and layers of operational management to define for example
needs, requirements, constraints, and targets.
Although purely intent-driven management frameworks are foreseen, it is more likely that intent-driven management
will complement the traditional imperative (not intent-driven) management solutions.
4.2 Definition of intents
4.2.1 Introduction
ETSI GR ZSM 005 [i.1] introduced intent-based approach as a means of automation. Clause 4.3.0 of ETSI
GR ZSM 005 [i.1] summarizes how the notion of intents emerged in the telecommunications industry and how some of
the main academic and industry work have adopted this concept in the area of network and service management and
automation. Also, the later TM Forum IG 1230 [i.2] presents the concept of intent and the evolution of the concept over
time in clause 5.7, showing mainly how intent is defined and used in different standardization organizations.
The notion of intent as a concept and its role in the telecommunication industry has evolved over time from being
policy-centric towards being a means for declaration and communication of goals, requirements, and constraints to parts
of a technical system, such as a management system. The setting of intent is often linked to humans' expectations and
desires, but it can also be used to express goals to be exchanged between machines or within an autonomous system.
IRTF NMRG [i.3] has defined intent as "A set of operational goals (that a network should meet) and outcomes (that a
network is supposed to deliver) defined in a declarative manner without specifying how to achieve or implement them".
In ETSI TS 128 312 [i.4], intent is defined as "a desire to reach a certain state for a specific service or network
management workflow". Besides that, "an intent specifies the expectations including requirements, goals and
constraints given to a 3GPP system, without specifying how to achieve them".
The same general definition has been adopted in TM Forum IG 1230 [i.2] as a baseline. TM Forum's work emphasize
that from the user's perspective, an intent expresses the expectation the user has with respect to the behaviour of the
system. Intents should be used to convey the goals needed to ultimately fulfil humans' expectations. In this sense,
according to TM Forum IG 1230 [i.2], an intent can also be defined as "the formal specification of all expectations
including requirements, goals, and constraints given to a technical system".
Based on the definitions presented above, there is a common understanding in the industry that an intent is a knowledge
object that is used to describe the expectations to a system in a way that allows autonomous operations to be performed
by the system receiving such intents. The ZSM framework should use the same definition when applying an
intent-driven approach in the zero-touch networks and services management.
ETSI
11 ETSI GR ZSM 011 V2.1.1 (2024-09)
Therefore, the adoption of intent definition as in TM Forum IG1230 [i.2] is proposed:
"Intent is the formal specification of the expectations, including requirements, goals, and constraints, given to
a technical system".
4.2.2 Principles of intent
Properties and implications of intent are well defined in [i.2] and some others of the previously mentioned documents.
As conclusion the following principles of intent are identified for ZSM:
1. Intent establishes machine-processable knowledge
Intents are formal specification created for a technical system, which means that they establish machine-readable
knowledge to be considered by the autonomous management. In an autonomous network, where business goals and
requirements can change dynamically and the operations need to quickly adapt without human intervention, the
business objectives of the operators as well as the expectations of the customers and users need to be conveyed in some
means of knowledge, and this is the main purpose of intents.
2. Intent is declarative, so it leaves any implementation detail internal to the solution provider
Intents define goals, requirements, and constraints, which should be provided in a declarative form. The definition
excludes all imperative implementations and solutions aspects. Therefore, intents leave out the implementation of the
details of how the network and service is operated to the internal management capabilities of the autonomous network.
In this respect, artifacts such as workflows, policies, decision rules, etc. are still needed to realize intent-driven
autonomous networks. Such tools will be used internally to the autonomous systems according to network operator's
strategies.
3. Intent is focused on expectations of the results for the consumer
Intents focus on a specification of expectations, reflecting the idea that intents are expressed from a consumer's
perspective. Intents can originate directly from humans, e.g. customers or operators using intents to communicate to an
autonomous system their expectations. It is the job of the autonomous system to fulfil those expectations, while the
intent originator may play a supervisory role. Intents can also be generated internally within the autonomous system and
can be used between the autonomous entities to influence the details of the specific wanted behaviour and contribute to
the overall fulfilment of human expectations (expressed by intents initially created).
4. Intent is formally expressed so it is machine-processable and readable for human
Finally, one of the most important aspects of intents is that they are formally expressed so that they can be interpreted
by machines as well as by humans. The sender and receiver of intents need to agree in their interpretation; therefore,
there should be no ambiguity in their meaning. The formal expression and unambiguous meaning of intents can be
achieved by well-defined information models that completely define the semantics and vocabulary that is required for
the operation of each autonomous system that uses intents. The intent models that can be defined in the ETSI ZSM
scope are presented in clause 5.4.
5. Intent supports complete automation of intent owner-intent handler interactions as well as of intent-defined
service delivery
Intents are abstract, which allows them to be formulated by
...