RFC 9315

Intent-Based Networking - Concepts and Definitions 💖

Okay bestie, let's start with the basics of RFC 9315 🎀 It's an Informational document from the Internet Research Task Force (IRTF), published in October 2022. Its ISSN is 2070-1721. It doesn't obsolete or update any other RFCs, since none are listed in its header ✨

The authors are A. Clemm (Futurewei), L. Ciavaglia (Nokia), L. Z. Granville (Federal University of Rio Grande do Sul (UFRGS)), and J. Tantsura (Microsoft) 🫶 The whole squad 👑

Abstract 🦋

Okay so intent and Intent-Based Networking are absolutely everywhere right now 😭 But people keep using these terms loosely, and they get mixed up with other stuff, especially "policy," which is giving confusion 💀 This document clears that up by pinning down what "intent" actually means and giving an overview of the functionality that comes with it 💅 The big goal is a shared understanding of the terms, concepts, and functionality, so future research and engineering problems (and their solutions) have a solid foundation to build on 🌈

This document is a product of the IRTF Network Management Research Group (NMRG). It reflects the group's consensus, and the research group gave it lots of detailed and positive reviews 🙈 It's published for informational purposes ✨

Status of This Memo 🌸

Bestie, this one's not an Internet Standards Track specification. It's only published for informational purposes 💜

This document is a product of the Internet Research Task Force (IRTF), which shares the results of Internet-related research and development. Those results might not be ready for deployment, so be careful 🍓 This RFC represents the consensus of the Network Management Research Group of the IRTF. Documents that the IRSG approves for publication are not candidates for any level of Internet Standard. For the details, check Section 2 of RFC 7841 🧚

Want the current status of this document, any errata, or a way to send feedback? Head to https://www.rfc-editor.org/info/rfc9315 🦋

Copyright Notice 💅

The copyright belongs to the IETF Trust and the people listed as the document's authors, © 2022, with all rights reserved 🌈

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at https://trustee.ietf.org/license-info. Those rules apply as of the publication date. Please read them carefully, because they explain what you're allowed to do with this document and what you're not 🫶⭐

Table of Contents 🧚

   1.  Introduction
   2.  Definitions and Acronyms
   3.  Introduction of Concepts
     3.1.  Intent and Intent-Based Management
     3.2.  Related Concepts
       3.2.1.  Service Models
       3.2.2.  Policy and Policy-Based Network Management
       3.2.3.  Distinguishing between Intent, Policy, and Service
               Models
   4.  Principles
   5.  Intent-Based Networking - Functionality
     5.1.  Intent Fulfillment
       5.1.1.  Intent Ingestion and Interaction with Users
       5.1.2.  Intent Translation
       5.1.3.  Intent Orchestration
     5.2.  Intent Assurance
       5.2.1.  Monitoring
       5.2.2.  Intent Compliance Assessment
       5.2.3.  Intent Compliance Actions
       5.2.4.  Abstraction, Aggregation, Reporting
   6.  Life Cycle
   7.  Additional Considerations
   8.  IANA Considerations
   9.  Security Considerations
   10. Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction ✨

okay so this doc is a product of the IRTF Network Management Research Group (NMRG) 💅 it reflects the consensus of the RG, got reviews and explicit support from a bunch of participants, and it's published for informational purposes 🦋

so like, back in the day IETF folks were mostly obsessed with individual network and device features 🙈 the standardization energy went to management instrumentation that had to be provided to a networking device. the prime example is SNMP-based management [RFC3411] and the 200+ MIBs the IETF has defined over the years 💀 more recent examples include YANG data model definitions [RFC7950] for stuff like interface configuration, Access Control List (ACL) configuration, and Syslog configuration 🎀

and bestie, managing networks by configuring myriads of "nerd knobs" on a device-by-device basis is NOT an option anymore 😭 it's giving chaos. keeping device configurations consistent across a whole network is hard, and it's also hard to keep them consistent with the needs of the services and service features they're supposed to enable. there's more: networks need to adapt quickly and do it at scale ✨ operations also need to be streamlined and automated wherever possible, not just to lower operational expenses but to allow rapid reconfiguration at sub-second time scales and to make sure networks are actually delivering their functionality as expected 🔥 so basically this means being able to consume operational data, do analytics, and dynamically take actions in a way that's aware of context and intended outcomes, at near real-time speeds 🧚

so the IETF has started addressing end-to-end management aspects that go beyond individual devices in isolation 👑 examples are YANG models for network topology [RFC8345] and service models used by service orchestration systems and controllers [RFC8309] 🌸 a lot of the interest was fueled by discussions about managing autonomic networks in the ANIMA Working Group 🦋 autonomic networks are driven by the desire to lower operational expenses and make managing the network as a whole more straightforward, which kind of clashes with the need to manage the network one device and one feature at a time 🙃 and while autonomic networks are meant to have "self-management" properties, they still need input from an operator or outside system to provide operational guidance and info about the goals, purposes, and service instances the network is supposed to serve 💜

this input and operational guidance is commonly called "intent" ✨ a network that lets operators provide their input using intent is an "Intent-Based Network" (IBN), and a system that helps implement intent is an "Intent-Based System" (IBS) 🫶 these can show up in a bunch of ways: a controller or management system running as an application on a server or set of servers, or a set of functions distributed across a network that collectively perform their intent-based functionality 🌈

but intent is about more than just letting operators interact with the network through higher-layer abstractions 👀 it's also about letting operators focus on what they want their desired outcomes to be while leaving the details of how those outcomes get achieved to the IBN (or IBS) 💅 focusing on the outcome gives you way more operational efficiency and flexibility at greater scale, on shorter time scales, and with less dependency on human activities (so less room for mistakes) 🍓 this also makes Intent-Based Networking an ideal candidate for artificial intelligence techniques that can bring about the next level of network automation [CLEMM20] 🤖✨

the industry has totally caught on to this vision 😭 there's a significant number of solutions offering Intent-Based Management, promising network providers they can manage networks holistically at a higher level of abstraction, as a system made of interconnected components rather than a set of independent devices (that happen to be interconnected) 🧠 those offerings include IBNs and IBSs (offering a full life cycle of intent), Software-Defined Network (SDN) controllers (offering a single point of control and administration for a network), and network management and Operations Support Systems (OSSs) 💖

ngl, comprehensive management has never been able to live only at the level of individual devices and low-level configurations, and people have known that for a long time 🙈 so the vision of intent isn't totally new. ITU-T's model of a Telecommunications Management Network (TMN) introduced management layers forming a management hierarchy of network element, network, service, and business management [M3010] 🍰 high-level operational objectives propagated top-down from upper to lower layers, and that abstraction hierarchy was crucial for breaking management complexity into separate areas of concern 🌟 it came with an information hierarchy that was device-specific at the lowest level but, at higher layers, included things like end-to-end service instances 🎀 similarly, Policy-Based Network Management (PBNM) has long promised that users can manage networks by specifying high-level management policies, with policy systems automatically "rendering" those policies, i.e., breaking them down into low-level configurations and control logic 🦄

As a note, in the context of this document, "users" generally refers to operators and administrators who are responsible for the management and operation of communication services and networking infrastructures, not to "end users" of communication services.

what's been missing, though, is putting these concepts into a more current context and updating them for current technology trends 🌷 so this document clarifies the concepts behind intent, differentiates intent from related concepts, and gives an overview of first-order principles of Intent-Based Networking along with the associated functionality 💜 the goal is a common, shared understanding that can be the foundation for articulating research and engineering problems in Intent-Based Networking ✨

the articulation of IBN-related research problems is out of scope here 🙅‍♀️ but IBN has become a seriously important topic in the research community 😭 per IEEE Xplore [IEEEXPLORE], as of December 2021, in the decade since 2012 there were 1138 papers with the index term "intent", 411 of which specifically mention networking 📚 the period since 2020 alone accounts for 316 papers on intent and 153 on intent networking, which is accelerating interest, no cap 🚀 workshops dedicated to the theme are also popping up, like the IEEE International Workshop on Intent-Based Networking [WIN21], plus various special journal issues [IEEE-TITS21] 🎟️ a survey of current intent-driven networking research was published in [PANG20], and among the most pressing research challenges it lists are intent translation and understanding, intent interfaces, and security 🔐

---

2. Definitions and Acronyms 💜

• ACL: Access Control List 🔒
• API: Application Programming Interface 🧩
• IBA: Intent-Based Analytics. Analytics that are defined and derived from users' intent and used to validate the intended state. 📊
• IBN: Intent-Based Network. A network that can be managed using intent. 🌐
• IBS: Intent-Based System. A system that supports management functions that can be guided using intent. 🛠️
• Intent: 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. 🎯
• Intent-Based Management: The concept of performing management based on the concept of intent. 🦋
• PBNM: Policy-Based Network Management 📜
• PDP: Policy Decision Point 🧑‍⚖️
• PEP: Policy Enforcement Point 🚧
• Policy: A set of rules that governs the choices in behavior of a system. 📏
• Service Model: A model that represents a service that is provided by a network to a user. 🍓
• SSoT: Single Source of Truth. A functional block in an IBN system that normalizes users' intent and serves as the single source of data for the lower layers. 👑
• Statement of Intent: A specification of one particular aspect or component of intent, also referred to as an intent statement. ✍️
• SVoT: Single Version of Truth 🌸
• User: In the context of this document, an operator and/or administrator responsible for the management and operation of communication services and networking infrastructure (as opposed to an end user of a communication service). 🫶

---

3. Introduction of Concepts 🧚

okay so this section gives an overview of the concept of intent and Intent-Based Management 💖 it also covers the related concepts of service models and policies (and Policy-Based Network Management), and explains how they relate to intent and Intent-Based Management 🌈

3.1. Intent and Intent-Based Management 🎀

Okay so, in this document, intent means a set of operational goals (stuff a network is supposed to meet) and outcomes (stuff a network is supposed to deliver). It's all declared in a declarative way, without saying how to achieve or implement any of it. 💅

The word "intent" first showed up in Autonomic Networks, where it was described as "an abstract, high-level policy used to operate the network" [RFC7575]. By that definition, an intent is a special kind of policy that a user gives to guide the Autonomic Network, which would otherwise run without any human intervention. 🧚 But if we just treat intent as a fancy synonym for policy, that's messy, so we need a distinction that clearly separates intent from other kinds of policies. 🫶

One note regarding the use of the plural form of "intent": in the English language, the term "intent" is generally used only in singular form. However, the specification of intent as a whole usually involves the specification of several individual statements of intent, or intent statements. In some cases, intent statements are colloquially also referred to as "intents", although in general, the use of the term "intents" is discouraged.

Intent-Based Management is all about getting to networks that are way simpler to manage and operate, needing only minimal outside help. 🌈 Even autonomic networks aren't clairvoyant. They have no magical way to automatically know particular operational goals or which networking services they should support. In other words, they don't know what the network provider's intent is, and that intent is the whole reason the network exists! 😭 So it still has to be communicated to the network, through what informally counts as intent. That said, intent isn't only for autonomic networks, like ones that feature an Autonomic Control Plane [RFC8994]. It applies to any network, periodt. 🦋

Intent defines goals and outcomes in a purely declarative way. It says what to accomplish, not how to achieve it. So intent juggles a few important concepts at the same time:

• It provides data abstraction: Users do not need to be concerned with low-level device configuration and nerd knobs. 🤓
• It provides functional abstraction from particular management and control logic: Users do not need to be concerned even with how to achieve a given intent. What is specified is the desired outcome, with the IBS automatically figuring out a course of action (e.g., using an algorithm or applying a set of rules derived from the intent) for how to achieve the outcome. 👑

Here are some examples of intent, written in natural language so it's easy to follow. (Real interfaces for conveying intent may look different, though!) 🍓

• "Steer networking traffic originating from endpoints in one geography away from a second geography, unless the destination lies in that second geography." (states what to achieve, not how.)
• "Avoid routing networking traffic originating from a given set of endpoints (or associated with a given customer) through a particular vendor's equipment, even if this occurs at the expense of reduced service levels." (states what to achieve, not how, providing additional guidance for how to trade off between different goals when necessary.)
• "Maximize network utilization even if it means trading off service levels (such as latency, loss) unless service levels have deteriorated 20% or more from their historical mean." (a desired outcome, with a set of constraints for additional guidance, that does not specify how to achieve this.)
• "Ensure VPN services have path protection at all times for all paths." (a desired outcome of which it may not be clear how it can be precisely accommodated.)
• "Generate in situ Operations, Administration, and Maintenance (OAM) data and network telemetry for later offline analysis whenever significant fluctuations in latency across a path are observed." (goes beyond event-condition-action by not being specific about what constitutes "significant" and what specific data to collect.)
• "Route traffic in a Space Information Network in a way that minimizes dependency on stratospheric balloons unless the intended destination is an aircraft." (does not specify how to precisely achieve this; extrapolates on scenarios mentioned in [PANG20].)
• "For a smart city service, ensure traffic signal control traffic uses dedicated and redundant slices that avoid fate sharing." (a desired outcome with a set of constraints and additional guidance without specifying how to precisely achieve this; extrapolates on scenarios from [GHARBAOUI21].)

Now the flip side. These are NOT intent, same natural-language vibe: 🙈

• "Configure a given interface with an IP address." (This would be considered device configuration and fiddling with configuration knobs, not intent.)
• "When interface utilization exceeds a specific threshold, emit an alert." (This would be a rule that can help support network automation, but a simple rule is not an intent.)
• "Configure a VPN with a tunnel from A to B over path P." (This would be considered as a configuration of a service.)
• "Deny traffic to prefix P1 unless it is traffic from prefix P2." (This would be an example of an access policy or a firewall rule, not intent.)

In networks, especially ones that are deemed autonomic, intent should ideally be rendered by the network itself, meaning translated into device-specific rules and courses of action. ✨ Ideally, intent wouldn't need to be orchestrated or broken down by a higher-level, centralized system. Instead, the network devices would do it themselves, using a mix of distributed algorithms and local device abstractions. In this dreamy vision, since intent holds for the network as a whole, it should ideally be automatically spread across all devices in the network, and each device can decide for itself whether it needs to act on it. 🌸

Real life isn't always that dreamy, though. Some stuff will need to be at least conceptually centralized. For example, users may need a single conceptual point of interaction with the network. That system acts as the operational front end for the network, so users can send requests at the network and get updates back from it. 💖 It may appear to users as one single system, even if it's actually built in a distributed way. It then interacts with and manages other systems in the network as needed, in order to realize (that is, to fulfill and to assure) the desired intent. Also, the vast majority of network devices may be intent-agnostic and only focus on, for example, actually forwarding packets. Plus, many devices are constrained in their processing resources, so not every device will be able to act on intent on its own. In those cases, intent can be achieved by a separate system that performs the required actions. 🫠

Another reason to provide intent functionality from a conceptually centralized point is when realizing a certain type of intent benefits from global knowledge of a network and its state. Individual devices often can't practically maintain such a global view, for example because of the volume of data and the time lags involved. It may even be impractical for devices to just access such a view from another remote system, even if one were available. 😤

So, all of this means that in many cases, certain intent functionality needs to be provided by functions specialized for that purpose, which may run on dedicated systems (and in some cases those systems could also co-host other networking functions). For example, translating specific types of intent into corresponding courses of action and algorithms to achieve the desired outcomes may need to be handled by such specialized functions. Of course, to avoid single points of failure, the implementation and hosting of those functions may still be distributed, even if they're conceptually centralized. 🧠

Whether it's implemented in a centralized or decentralized way, an IBN is a network that can be managed using intent. That means it can recognize and ingest the intent of an operator or user, then configure and adapt itself to that intent, achieving an intended outcome (a desired state or behavior) without the user having to spell out the detailed technical steps. Instead, the IBN will figure out on its own how to achieve the outcome. 🦋 Similarly, an IBS is a system that lets users manage a network using intent. Such a system serves as a point of interaction with users and implements the functionality needed to achieve the intended outcomes, interacting with the network as required for that purpose. 💅

Other definitions of intent exist too, such as [TR523]. There, intent is simply defined as a declarative interface that is typically provided by a controller. That implies a centralized function that renders the intent into lower-level policies or instructions and orchestrates them across the network. Honestly, that's one valid way to implement it, but the definition in this document is broader and more ambitious. It stresses managing the network by specifying desired outcomes without the specific steps needed to reach them. A controller API that just provides abstraction at the network level is more limited, and it wouldn't necessarily qualify as intent. 🙃 Also, ingesting and recognizing intent may not happen through an API based on function invocations and simple request-response interactions. It may involve other kinds of human-machine interaction too, like dialogs to provide clarifications and refinements to requests. 🗣️✨

---

3.2. Related Concepts 💜

3.2.1. Service Models ✨

okay bestie, let's talk about service models 💅 A service model represents a service that a network provides to a user. Per [RFC8309], it describes a service and its parameters in a portable, implementation-agnostic way, so it can be used no matter what equipment or operating environment actually makes the service happen 🧚 There are two subcategories: a "Customer Service Model" describes an instance of a service as given to a customer (maybe tied to a service order 📦), and a "Service Delivery Model" describes how a service gets set up on top of existing networking infrastructure 🛠️

Some examples of services: a Layer 3 VPN service [RFC8299], a Network Slice [NETWORK-SLICE], or residential Internet access 🏠 Service models treat service instances as their own little entities 💖 They have their own parameters, actions, and life cycles. And typically, service instances can be bound to end users, who might get billed for the services they use 💸

Instantiating a service usually involves a bunch of moving parts:

• A user (or northbound system) needs to define and/or request a service to be instantiated 🙋‍♀️
• Resources, such as IP addresses, AS numbers, VLAN or VxLAN pools, interfaces, bandwidth, or memory, need to be allocated 📊
• How services get mapped to resources needs to be defined. Multiple mappings are often possible, and which one gets picked may depend on context (like what kind of access is available to connect the end user of a communication service with the service) 🗺️
• Bindings between upper- and lower-level objects need to be maintained 🔗
• Once instantiated, the service operational state needs to be validated and assured, so the network actually delivers the service as requested ✅

The realization of service models involves a system, like a controller, that provides provisioning logic. This includes breaking down high-level service abstractions into lower-level device abstractions, identifying and allocating system resources, and orchestrating the individual provisioning steps 🎛️ Orchestration is generally done with a "push" model. The controller or manager starts the operations as needed, then pushes the specific configurations down to the device, and then checks whether the new changes were accepted and whether the new operational and derived states have been reached and are in sync with the intent or desired state 🔄 Beyond instantiating and creating new service instances, updating, modifying, and decommissioning services also need to be supported 🧹 The device itself typically stays agnostic to the service, and doesn't really care that its resources or configurations are part of a service or concept living at a higher layer 🤷‍♀️

Instantiated service models map to instantiated lower-layer network and device models. Examples include instances of paths or instances of specific port configurations 🛤️ The service model typically also models the dependencies and layering of services over the lower-layer networking resources used to provide them 🥞 This makes management easier, since you can follow dependencies when troubleshooting and do impact analysis, which assesses how events in the network affect services and customers 🔍 Services are typically orchestrated and provisioned top to bottom, which also helps keep track of how network resources get assigned (composition), while troubleshooting goes bottom up (decomposition) ⬆️⬇️ Service models might also be associated with other data that doesn't concern the network but adds business context 💼 That includes things like customer data (such as billing information), service orders and service catalogs, tariffs, service contracts, and Service Level Agreements (SLAs), including contractual agreements about remediation actions 📜

[SERVICE-MAPPING-YANG] is an example of a data model that provides a mapping from customer service models (e.g., the L3VPN Service Model) to Traffic Engineering (TE) models (e.g., the TE Tunnel or the Abstraction and Control of Traffic Engineered Networks Virtual Network model) 🧩

Like intent, service models provide higher layers of abstraction 🌈 They're often also paired with mappings that capture dependencies between service and device or network configurations. But unlike intent, service models do not let you define a desired "outcome" that an IBS would automatically maintain 🙅‍♀️ Instead, managing service models requires sophisticated algorithms and control logic built by network providers or system integrators 🧠

---

3.2.2. Policy and Policy-Based Network Management 🎀

Policy-Based Network Management (PBNM) is a management paradigm that separates the rules governing a system's behavior from the system's functionality 👑 It promises to reduce maintenance costs for information and communication systems while improving flexibility and runtime adaptability 📈 It sits at the heart of a whole bunch of management architectures and paradigms, including SLA-driven, business-driven, autonomous, adaptive, and self-* management [BOUTABA07]. If you're curious, the interested reader is invited to check out the rich set of existing literature, which includes this and many other references 📚 Here we'll only give a much-abridged, distilled overview, so don't worry, it's not a whole novel 😂

At the heart of policy-based management is the concept of a policy. There are multiple definitions floating around: "Policies are rules governing the choices in the behavior of a system" [SLOMAN94]. "Policy is a set of rules that are used to manage and control the changing and/or maintaining of the state of one or more managed objects" [STRASSNER03]. The thread connecting most of them is that a policy is a "rule." Typically, a rule is made of an event (whose occurrence triggers the rule), a set of conditions (which get assessed and which must be true before any actions are actually "fired"), and finally, a set of one or more actions that get carried out when the condition holds ⚡

Policy-based management can be considered an imperative management paradigm 🫡 Policies spell out precisely what needs to be done, when, and in which circumstances. Using policies, management can, in effect, be defined as a set of simple control loops 🔁 That makes policy-based management a suitable technology for implementing autonomic behavior that can show self-* management properties, including self-configuration, self-healing, self-optimization, and self-protection 🌟 And this holds even though policy-based management may use abstractions (like "Bob gets gold service") that hide from the user the specifics of how that abstraction is rendered in a particular deployment 🥇

Policies typically involve a certain degree of abstraction, so they can cope with the heterogeneity of networking devices 🌍 Rather than writing a device-specific policy that defines events, conditions, and actions in terms of device-specific commands, parameters, and data models, a policy is defined at a higher level of abstraction, using a canonical model of the systems and devices it's going to be applied to 🪄 A policy agent on a controller or the device then "renders" the policy, which means it translates the canonical model into a device-specific representation 🔧 This lets you apply the same policy across a wide range of devices without defining multiple variants 🙌 In other words, policy definition is decoupled from policy instantiation and policy enforcement 🫶 That enables operational scale and lets network operators and policy authors think in higher terms of abstraction than device specifics, reusing the same high-level definition across different networking domains: WAN, data center (DC), or public cloud ☁️

PBNM is typically "push-based": policies are pushed onto devices, where they get rendered and enforced 📤 The push operations are conducted by a manager or controller, which is responsible for deploying policies across the network and monitoring their proper operation 👀 That being said, other policy architectures are possible 💅 For example, policy-based management can also include a pull component, in which the decision about which action to take is delegated to a so-called Policy Decision Point (PDP). This PDP can reside outside the managed device itself and typically has global visibility and context to make policy decisions 🌐 Whenever a network device observes an event that is associated with a policy, but it either lacks the full definition of the policy or can't reach a conclusion about the expected action, it reaches out to the PDP for a decision (reached, for example, by deciding on an action based on various conditions) 🙋‍♀️ Then the device carries out the decision the PDP returned. The device "enforces" the policy, and so it acts as a PEP (Policy Enforcement Point) 🛡️ Either way, PBNM architectures typically involve a central component from which policies are deployed across the network and/or policy decisions are served 🏰

Like intent, policies provide a higher layer of abstraction ✨ Policy systems can also capture dynamic aspects of the system under management, through rules that allow defining various triggers for specific courses of action ⚡ Unlike intent, though, the definition of those rules (and courses of action) still needs to be articulated by users. Since the intent is unknown, conflict resolution within or between policies requires interaction with a user, or some kind of logic that lives outside of PBNM 🤔 In that sense, policy is a lower level of abstraction than intent 📉 But it's totally conceivable for IBSs to generate policies that are then deployed by a PBNM system, which lets PBNM support Intent-Based Networking 💜

3.2.3. Distinguishing between Intent, Policy, and Service Models 💅✨

Okay so, intent, policy, and service models all have the SAME vibe at the core: they're a higher layer of abstraction over a network 🌸. None of them care about device specifics, they basically transcend individual devices, and they make the network way easier to manage for apps and humans than babysitting one box at a time 🫶. Beyond that? Things get juicy. Let's spill the differences 💜

Summarized differences:

• A service model is a data model that describes instances of services provided to customers 💼. It depends on lower-level models (device and network models) when it's describing how the service gets mapped onto the underlying network and IT infrastructure 🧩. Instantiating a service model REQUIRES orchestration by a system. Like, the logic for how to orchestrate, manage, and provide the service model, and how to map it onto underlying resources, is NOT included in the model itself 🙈. The model is the what, not the how.
• Policy is a set of rules, typically modeled around a variation of events/conditions/actions 🎀. It's used to express simple control loops that devices can render WITHOUT needing the outside system to step in 🦋. Policies let users define what to do under what circumstances 💅, but they do NOT specify the desired outcome. Rules, not goals, bestie 😭.
• Intent is a high-level, declarative goal that operates at the level of a network and the services it provides, NOT individual devices 🌈. It's used to define outcomes and high-level operational goals, without specifying how those outcomes should be achieved or how goals should specifically be satisfied 👑, and WITHOUT the need to enumerate specific events, conditions, and actions ✨. Which algorithm or rules to apply can be automatically "learned/derived from intent" by the IBS 🧚. In the context of autonomic networking, intent is ideally rendered by the network itself 🌟. Also, the dissemination of intent across the network and any required coordination between nodes is resolved by the network WITHOUT the need for external systems 💜.

One analogy to capture the difference between policy-based systems and IBSs is that of Expert Systems and Learning Systems in the field of Artificial Intelligence 🤖. Expert Systems operate on knowledge bases with rules supplied by users, which is analogous to policy systems whose policies are supplied by users 📚. They can make automatic inferences based on those rules, but they are NOT able to "learn" new rules on their own 💀. Learning Systems (popularized by deep learning and neural networks) 🧠, on the other hand, are able to learn WITHOUT depending on user programming or articulation of rules 🙌. However, they DO require a learning or training phase that needs large data sets 📊, and explaining the actions the system actually takes is a different set of challenges 🙈. Analogous to IBSs, users focus on what they'd like the learning system to accomplish, but NOT how to do it 💖.

4. Principles 🌈

The following main operating principles allow characterizing the intent-based/-driven/-defined nature of a system 🔥.

1. Single Source of Truth (SSoT) and Single Version of Truth (SVoT). The SSoT is an essential component of an IBS because it enables several important operations 👑. The set of validated intent expressions is the system's SSoT 💜. SSoT and the records of the operational states let you compare the intended/desired state and the actual/operational state of the system and determine drift between them 🦋. SSoT and the drift information are the basis for corrective actions 🛠️. If the IBS can predict states, it can develop strategies to anticipate, plan, and pro-actively act on diverging trends, with the aim of minimizing their impact 🔮. Beyond providing consistent system operation, SSoT also allows better traceability, so you can validate if and how the initial intent and associated business goals were properly met, and evaluate the impacts of changes in intent parameters and the effects of events occurring in the system 📈.

Single Version (or View) of Truth derives from the SSoT and can be used for other operations like querying, polling, or filtering measured and correlated information to create so-called "views" 🎀. These views can serve the users of the IBS ✨. To create intent statements as single sources of truth, the IBS MUST follow well-specified and well-documented processes and models 📋. In other contexts, SSoT is also referred to as the invariance of the intent [LENROW15] 🌸.

2. One touch but not one shot. In an ideal IBS, the user expresses intent in one form or another, and then the system takes over all subsequent operations (one touch) 🫶. A zero-touch approach could also be imagined where the IBS can recognize intentions in any form of data 🪄. However, the zero- or one-touch approach should NOT distract from the fact that reaching a well-formed and valid intent expression is NOT a one-shot process 😭. Instead, the interfacing between the user and the IBS could be an interactive and iterative process 🔁. Depending on the level of abstraction, intent expressions may initially contain more or less implicit parts and imprecise or unknown parameters and constraints 🌫️. The role of the IBS is to parse, understand, and refine the intent expression until it reaches a well-formed and valid one that the system can use for fulfillment and assurance operations 💅. An intent refinement process could use a combination of iterative steps involving the user, to validate the proposed refined intent and to ask for clarifications when some parameters or variables cannot be deduced or learned by the system itself 🙋‍♀️. In addition, the IBS will need to moderate between conflicting intent, helping users choose between intent alternatives that may have different ramifications ⚖️.
3. Autonomy and Supervision. A desirable goal for an IBS is a high degree of flexibility and freedom on both the user side and the system side 🦄. For example, users can express intent in their own terms, the system supports different forms of expression for individual statements of intent, and it can refine those expressions into well-formed and exploitable ones 🧁. This dual principle of autonomy and supervision lets the system operate with the necessary autonomy to conduct its tasks and operations WITHOUT requiring user intervention 🤖. It takes its own decisions (within its areas of concern and span of control) about how to meet user expectations for performance and quality 🏃‍♀️. At the same time, it provides the proper level of supervision to satisfy user requirements for reporting and escalation of relevant information 📣.
4. Learning. An IBS is a learning system 🧠. In contrast to an imperative system, such as Event-Condition-Action policy rules, where the user defines beforehand the expected behavior for various events and conditions, in an IBS the user only declares what the system is supposed to achieve and NOT how to achieve it 💭. So reasoning and rationality transfer from the human (domain knowledge) to the system 🔄. This transfer of cognitive capability also implies that the IBS has capabilities or means for learning, reasoning, and knowledge representation and management 📚. The learning abilities of an IBS can apply to different tasks, such as optimizing intent rendering or intent refinement processes ✨. Because an IBS is a continuously evolving system, it creates the condition for continuous learning and optimization 🌱. Other cognitive capabilities, such as planning, can also be used in an IBS to anticipate or forecast future system state and responses to changes in intent or network conditions 🔭. That lets it elaborate plans to accommodate changes while preserving system stability and efficiency, trading off against cost and robustness of operations ⚖️.
5. Capability exposure. Capability exposure means expressive network capabilities, requirements, and constraints need to be available so the system can compose and decompose intent and map the user's expectations onto system capabilities 🧩.
6. Abstract and outcome-driven. Users do NOT need to be concerned with how intent is achieved, and they are empowered to think in terms of outcomes 👑. They can also refer to concepts at a higher level of abstraction, independent of, for example, vendor-specific renderings 🦋.

The principles described above are perhaps the most prominent, but they are NOT an exhaustive list 💕. There are additional aspects to consider, such as:

• Intent targets are NOT individual devices but typically aggregations (such as groups of devices that share a common criterion, like devices of a particular role) or abstractions (such as service types, service instances, or topologies) 🎯.
• Abstraction and inherent virtualization: agnostic to implementation details 🌸.
• Human-tailored network interaction: IBN should speak the language of the user, as opposed to requiring the user to speak the language of the device/network 🗣️.
• Explainability as an important IBN function, detection and IBN-aided resolution of conflicting intent, and reconciliation of what the user wants and what the network can actually do 🔍.
• Inherent support, verification, and assurance of trust 🔐.

All of these principles and considerations have implications for the design of IBSs and their supporting architecture 🏗️. Accordingly, they need to be considered when deriving functional and operational requirements 💖.

5. Intent-Based Networking - Functionality ✨

okay so Intent-Based Networking has a ton of functions 💖 and they can be roughly sorted into two big buckets:

• Intent Fulfillment 🎯 is all the functions and interfaces that let users tell the network what they want and then do the work to make it happen. That includes algorithms that figure out the best courses of action, and functions that learn to optimize outcomes over time. It also covers things like orchestrating coordinated configuration across the whole network, and turning high-level abstractions into lower-level parameters and control knobs 🎀
• Intent Assurance 🔍 is the functions and interfaces that let users check and monitor that the network is actually sticking to its intent 🫶 This is how you find out whether the actions taken during fulfillment actually worked, and that feedback is what lets those functions get trained or tuned over time. Assurance also handles "intent drift" 😭 Intent isn't a one-and-done thing, it's more of a "set and forget" vibe. It's supposed to stay in effect over time (unless someone explicitly says otherwise). Intent drift happens when a system meets the intent at first, but slowly lets its behavior change or get affected until it doesn't meet it anymore, or does so in a less effective way 💀

The next sections give a more detailed tour of all of those functions 🦋

---

5.1. Intent Fulfillment 🌸

Intent fulfillment is all about the functions that take intent from the moment a user (usually an administrator at the responsible organization) comes up with it, all the way to making it real in the network 👑

5.1.1. Intent Ingestion and Interaction with Users 🍓

The first set of functions is all about "ingesting" intent, which just means getting intent through conversations with users 💬 They recognize intent from what the user says, and they also help users refine their intent and phrase it in a way that an IBS can actually act on. This usually goes way beyond what a non-intent-based API offers, though non-intent-based APIs can still be around (and are sometimes needed for stuff that talks to other machines instead of humans) 🤖 A lot of setups also come with easy, intuitive workflows that walk users through ingestion, making sure they've provided every input needed for intent modeling and the translation that comes after 🧚 They can even support kinda unconventional human-machine interactions, where the human doesn't just bark commands. Instead there's a back-and-forth dialog to ask for clarifications, explain the ramifications and trade-offs, and help refine things 🙈

The big goal is to make IBSs as easy and natural to use as possible 🌈 Users should be able to talk to the IBS without having to learn its whole "language" first, which would be a massive vibe killer 😤 Ideally, the IBS gets better and better at understanding the user, instead of the user having to adapt to the IBS. Of course, more research is needed before that becomes reality 🔬

5.1.2. Intent Translation 🦋

A second set of functions has to translate user intent into courses of action and requests to act on the network, stuff that actually means something to network configuration and provisioning systems ⭐ These functions are the core of an IBS, bridging the gap between chatting with users on one side and the management and operations side that has to orchestrate provisioning and configuration across the network on the other 🔥

Translation is more than just breaking down a higher layer of abstraction (intent) into a lower layer (policies and device configuration) 💜 It can also come with optimizations and algorithms that learn and improve over time to get the best outcomes, especially when there are multiple ways to reach the same result. For example, satisfying an intent might mean computing paths and other parameters that need to be configured across the network 🗺️ The heuristics and algorithms for doing that can evolve over time to optimize outcomes that depend on a whole myriad of dynamic network conditions and context 🌊

5.1.3. Intent Orchestration 🎀

A third set of functions deals with the actual configuration and provisioning steps that need to be orchestrated across the network. Those steps were figured out in the previous intent translation step 🧩

---

5.2. Intent Assurance 💅

Intent Assurance is concerned with the functions needed to make sure the network really does comply with the desired intent once it's been fulfilled ✨

5.2.1. Monitoring 👀

A first set of assurance functions monitors and observes the network and how it behaves 🔭 That includes all the usual assurance stuff, like monitoring the network for events and performance outliers, taking measurements to assess the service levels being delivered, and generating and collecting telemetry data 📊 Monitoring and observation are required as the basis for the next set of functions, which check whether the observed behavior actually complies with what's expected based on the intent 🫧

5.2.2. Intent Compliance Assessment 🔎

At the core of Intent Assurance are functions that compare the network's actual monitored and observed behavior with the intended behavior that's expected per the intent and held by SSoT 💖 These functions keep assessing and validating whether the observations show compliance with the intent. That includes checking how effective the intent fulfillment actions were, like verifying that they had the desired effect and measuring how big that effect was where it applies 🎯 It can also include functions that analyze and aggregate the raw observation data 🧮 The results of the assessment can be fed back into learning functions that optimize outcomes 🔁

Intent compliance assessment also covers checking whether intent drift happens over time 😭 Drift can be caused by a control plane or lower-level management operations that accidentally change behavior in ways that conflict with intent that was orchestrated earlier. IBSs and Networks need to be able to detect when drift occurs, or is about to occur, and figure out how severe it is 🚨

5.2.3. Intent Compliance Actions 🛠️

When intent drift happens or network behavior doesn't line up with the desired intent, you need functions that can trigger corrective actions 🙌 That includes actions that resolve the drift and bring the network back into compliance. Otherwise, and where necessary, reporting functions need to be triggered to alert operators and give them the info and tools to react appropriately 📣 For example, they can help operators reword the original intent so conflicting concerns get balanced out 🤝

5.2.4. Abstraction, Aggregation, Reporting 📚

The results of Intent Assurance need to be reported back to the user in a way that lets them connect the outcomes to their intent 💌 This takes a set of functions that can analyze, aggregate, and abstract the observation results. A lot of the time, lower-level stuff like detailed performance statistics and low-level settings has to get "up-leveled" into concepts the user can relate to and act on 🌟

The aggregation and analysis functionality also needs to be paired with functions that report intent compliance status, plus summarization and visualization that human users can actually understand 📈✨

6. Life Cycle ✨

okay so intent has a whole life cycle, bestie 🦋 it comes into being, it can glow up with changes over time, and at some point it can get retracted 💅 and this whole journey is lowkey tied to the different interconnection functions that come with the intent concept 🌸

Figure 1 is the map of the intent life cycle and its main functions 🗺️ the functions were introduced in Section 5, and they're split into two horizontal planes, one for fulfillment and one for assurance 💖 they're also split into three vertical spaces 🧚

the spaces are all about who's involved and how they interact 👑

• User Space 🎀 this is where the network and IBS talk to the human user. it's the part where users articulate their intent and the IBS recognizes it. it also covers reporting the status of the network relative to the intent, and letting users check the outcomes and see whether their intent actually had the effect they wanted 💜
• Translation, or Intent-Based System (IBS) Space ✨ this one is the bridge between intent users and the network operations infrastructure 🌈 it covers translating an intent into a course of action, plus the algorithms that plan and optimize those courses of action, including feedback and observations from the network. it also analyzes and aggregates network observations to validate compliance with the intent and to take corrective actions when needed. and it abstracts observations from the network so they relate back to the intent as the user communicated it, which makes the reporting in the user space way easier 🫶
• Network Operations Space 🛠️ last but not least, this is where orchestration, configuration, monitoring, and measurement happen. these functions carry out the rendered intent and watch how it affects the network 🔥

           User Space   :       Translation / IBS       :  Network Ops
                        :            Space              :     Space
                        :                               :
          +----------+  :  +----------+   +-----------+ : +-----------+
  Fulfill |recognize/|---> |translate/|-->|  learn/   |-->| configure/|
          |generate  |     |          |   |  plan/    |   | provision |
          |intent    |<--- |  refine  |   |  render   | : |           |
          +----^-----+  :  +----------+   +-----^-----+ : +-----------+
               |        :                       |       :        |
  .............|................................|................|.....
               |        :                  +----+---+   :        v
               |        :                  |validate|   :  +----------+
               |        :                  +----^---+ <----| monitor/ |
  Assure   +---+---+    :  +---------+    +-----+---+   :  | observe/ |
           |report | <---- |abstract |<---| analyze | <----|          |
           +-------+    :  +---------+    |aggregate|   :  +----------+
                        :                 +---------+   :

                       Figure 1: Intent Life Cycle

when you look at the diagram closely, you'll notice the intent life cycle actually has two loops 🔁

• the "inner" intent control loop lives between the IBS and the network operations space, and it's completely autonomic 🤖 no human in the loop at all! it's closed-loop automation that does automatic analysis and validation of intent based on what the network operations space observes. those observations get fed into the function that plans how the intent gets rendered, so the network's configuration can be adjusted as needed 💅 this loop catches and counteracts any intent drift that might be happening 👀 it uses observations to measure how compliant the network is with the intent and automatically triggers actions to fix any discrepancies. it also checks how well those actions worked, so it can keep learning and improving how intent gets rendered to hit the outcomes people want 📈
• the "outer" intent control loop reaches all the way into the user space 🧁 here the user takes action and tweaks their intent based on observations and feedback from the IBS. so yeah, intent has its own life cycle again: it comes into being, it may get refined, modified, and changed over time, and it may eventually get retracted 🦋

---

7. Additional Considerations 💜

okay so, intent is SO popular right now that people keep stretching the word to cover other concepts 😭 this is called "intent-washing," where you basically take an existing concept and slap new intent vocabulary on it to make it look fresh ✨ a classic example is calling the northbound interface of SDN controllers an "intent interface" 🙈 that said, sometimes it actually makes sense and isn't just marketing fluff, because it can help relate old concepts and new ones to each other 🫶

with that in mind, it helps to split intent into a few subcategories 🌸

• Operational Intent 🎯 this is about the operational goals of an operator. it matches the original "intent" term and the concepts defined in this document 💖
• Rule Intent 📜 a synonym for policy rules about what to do when certain events happen
• Service Intent 🧾 a synonym for customer service model [RFC8309]
• Flow Intent 🌊 a synonym for a Service Level Objective for a given flow

a full set of classifications for the different concepts and categories of intent will be described in a separate document 🧚 stay tuned, bestie!

---

8. IANA Considerations 🌷

this document has no IANA actions. nothing to see here for registries, zero vibes of paperwork 🥰

---

9. Security Considerations 🔐

okay this section is serious, so read it carefully bestie 🙏 this document describes concepts and definitions of Intent-Based Networking. because of that, the security considerations below stay high level, meaning they're in the form of principles, guidelines, or requirements. more detailed security considerations will show up in the documents that specify the architecture and functionality 💀

security in Intent-Based Networking can apply to a few different facets 🛡️

• Securing the IBS itself 🔒
• Mitigating the effects of erroneous, harmful, or compromised intent statements 🚨
• Expressing security policies or security-related parameters with intent statements 🗝️

securing the IBS is about making it operationally secure by using security mechanisms and applying security best practices 💪 in the Intent-Based Networking context, those mechanisms and practices can include intent verification and validation, letting only authenticated and authorized users operate on intent, and protecting against or detecting tampered intent statements 🕵️‍♀️ they may also include introducing multiple levels of intent. for example, intent about securing the network should live at a "deeper" level that overrides other levels of intent when necessary. that level shouldn't be changed through regular operations, only through operations that are specifically secured 🏰 using extra mechanisms, like explanation components that describe the security ramifications and trade-offs, should be considered too 💅

mitigating the effects of erroneous or compromised intent statements is about making the IBS operationally safe, with checkpoint and safeguard mechanisms and operating principles 🧯 in this context, those can include automatically detecting unintended, detrimental, or abnormal behavior 👀 they can also include the ability to automatically (and gracefully) roll back or fall back to a previous "safe" state ⏪ and the ability to prevent or contain error amplification. that one matters because a higher degree of automation combined with the inherent freedom, ambiguity, and implicit information carried by intent statements can make mistakes snowball 😱 dynamic levels of supervision and reporting are part of this too, so the user is aware of the right information at the right time with the right level of context 🔔 erroneous or harmful intent statements may spread without anyone noticing and end up compromising security 😬 and compromised intent statements, like ones forged by an inside attacker, may sabotage or harm network resources and leave them open to further, bigger attacks, for example by getting around certain security mechanisms 🚩

expressing security policies or security-related parameters as intent means using the intent formalism (a high-level, declarative abstraction), or part of an intent statement, to define security-related aspects such as 🧾

• data governance;
• level(s) of confidentiality in data exchange;
• level(s) of availability of system resources, of protection in forwarding paths, and of isolation in processing functions;
• level(s) of encryption; and
• authorized entities for given operations.

Intent-Based Networking in operational environments will definitely create new security concerns 😤 those concerns have to be anticipated at design and specification time. that said, Intent-Based Networking can also be an enabler for better security 🌈 for instance, security and privacy rules could be expressed in a more human-friendly and generic way, less tied to specific technology and less complex, which leads to fewer low-level configuration mistakes 🙌 detecting threats or attacks could also become simpler and more comprehensive, thanks to conflict detection at a higher level or at a coarser granularity 🔍

more thorough security analyses should be conducted as our understanding of Intent-Based Networking technology matures 🌱 we're not done yet, so keep your eyes peeled, bestie 👑✨

10. Informative References ✨

Okay bestie, this is the reading list 📚💅 Every single one of these is a source the RFC leans on, so I've kept each entry exactly as written, details and all, so you can go find them.

[BOUTABA07]
           Boutaba, R. and I. Aib, "Policy-Based Management: A
           Historical Perspective", Journal of Network and Systems
           Management (JNSM), Vol. 15, Issue 4,
           DOI 10.1007/s10922-007-9083-8, November 2007,
           <https://doi.org/10.1007/s10922-007-9083-8>.

[CLEMM20]  Clemm, A., Faten Zhani, M., and R. Boutaba, "Network
           Management 2030: Operations and Control of Network 2030
           Services", Journal of Network and Systems Management
           (JNSM), Vol. 28, Issue 4, DOI 10.1007/s10922-020-09517-0,
           October 2020,
           <https://doi.org/10.1007/s10922-020-09517-0>.

[GHARBAOUI21]
           Gharbaoui, M., Martini, B., and P. Castoldi,
           "Implementation of an Intent Layer for SDN-enabled and
           QoS-Aware Network Slicing", 2021 IEEE 7th International
           Conference on Network Softwarization (NetSoft), pp. 17-23,
           DOI 10.1109/NetSoft51509.2021.9492643, June 2021,
           <https://doi.org/10.1109/NetSoft51509.2021.9492643>.

[IEEE-TITS21]
           Garg, S., Guizani, M., Liang, Y-C., Granelli, F., Prasad,
           N., and R. R. V. Prasad, "Guest Editorial Special Issue on
           Intent-Based Networking for 5G-Envisioned Internet of
           Connected Vehicles", IEEE Transactions on Intelligent
           Transportation Systems, Vol. 22, Issue 8, pp. 5009-5017,
           DOI 10.1109/TITS.2021.3101259, August 2021,
           <https://doi.org/10.1109/TITS.2021.3101259>.

[IEEEXPLORE]
           IEEE, "IEEE Xplore", <https://ieeexplore.ieee.org/>.

[LENROW15] Lenrow, D., "Intent As The Common Interface to Network
           Resources", Intent Based Network Summit 2015 ONF Boulder:
           IntentNBI, February 2015.

[M3010]    ITU-T, "Principles for a telecommunications management
           network", ITU-T Recommendation M.3010, February 2000.

[NETWORK-SLICE]
           Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S.,
           Makhijani, K., Contreras, L. M., and J. Tantsura,
           "Framework for IETF Network Slices", Work in Progress,
           Internet-Draft, draft-ietf-teas-ietf-network-slices-14, 3
           August 2022, <https://datatracker.ietf.org/doc/html/draft-
           ietf-teas-ietf-network-slices-14>.

[PANG20]   Pang, L., Yang, C., Chen, D., Song, Y., and M. Guizan, "A
           Survey on Intent-Driven Networks", IEEE Access, Vol. 8,
           pp.22862-22873, DOI 10.1109/ACCESS.2020.2969208, January
           2020, <https://doi.org/10.1109/ACCESS.2020.2969208>.

[RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
           Architecture for Describing Simple Network Management
           Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
           DOI 10.17487/RFC3411, December 2002,
           <https://www.rfc-editor.org/info/rfc3411>.

[RFC7575]  Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
           Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
           Networking: Definitions and Design Goals", RFC 7575,
           DOI 10.17487/RFC7575, June 2015,
           <https://www.rfc-editor.org/info/rfc7575>.

[RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
           RFC 7950, DOI 10.17487/RFC7950, August 2016,
           <https://www.rfc-editor.org/info/rfc7950>.

[RFC8299]  Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
           "YANG Data Model for L3VPN Service Delivery", RFC 8299,
           DOI 10.17487/RFC8299, January 2018,
           <https://www.rfc-editor.org/info/rfc8299>.

[RFC8309]  Wu, Q., Liu, W., and A. Farrel, "Service Models
           Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
           <https://www.rfc-editor.org/info/rfc8309>.

[RFC8345]  Clemm, A., Medved, J., Varga, R., Bahadur, N.,
           Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
           Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
           2018, <https://www.rfc-editor.org/info/rfc8345>.

[RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
           Autonomic Control Plane (ACP)", RFC 8994,
           DOI 10.17487/RFC8994, May 2021,
           <https://www.rfc-editor.org/info/rfc8994>.

[SERVICE-MAPPING-YANG]
           Lee, Y., Ed., Dhody, Dhruv., Ed., Fioccola, G., Wu, Q.,
           Ed., Ceccarelli, D., and J. Tantsura, "Traffic Engineering
           (TE) and Service Mapping YANG Data Model", Work in
           Progress, Internet-Draft, draft-ietf-teas-te-service-
           mapping-yang-11, 11 July 2022,
           <https://datatracker.ietf.org/doc/html/draft-ietf-teas-te-
           service-mapping-yang-11>.

[SLOMAN94] Sloman, M., "Policy Driven Management for Distributed
           Systems", Journal of Network and Systems Management
           (JNSM), Vol. 2, Issue 4, pp. 333-360, December 1994.

[STRASSNER03]
           Strassner, J., "Policy-Based Network Management", August
           2003.

[TR523]    Open Networking Foundation, "Intent NBI - Definition and
           Principles", ONF TR-523, October 2016.

[WIN21]    Ciavaglia, L. and E. Renault, "1st International Workshop
           on Intent-Based Networking", IEEE International Conference
           on Network Softwarization, June 2021,
           <https://netsoft2021.ieee-netsoft.org/program/workshops/
           win-2021/>.

---

Acknowledgments 🫶

Big shoutout to the members of the IRTF Network Management Research Group (NMRG)! 🌸 They gave loads of super valuable discussions and feedback. The authors especially want to thank Remi Badonnel, Walter Cerroni, Marinos Charalambides, Luis Contreras, Jerome Francois, Molka Gharbaoui, Olga Havel, Chen Li, William Liu, Barbara Martini, Stephen Mwanje, Jeferson Nobre, Haoyu Song, Peter Szilagyi, and Csaba Vulkan for their feedback and support. 💜

Then there's the extra-iconic group who went one step further and actually reviewed the document: Remi Badonnel, Walter Cerroni, Jerome Francois, Molka Gharbaoui, Barbara Martini, Stephen Mwanje, Peter Szilagyi, and Csaba Vulkan. 👑 Literally the real MVPs 🔥

---

Authors' Addresses 💌

Here are the people who wrote this one, along with where to find them 🦋

Alexander Clemm
Futurewei
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: ludwig@clemm.org


Laurent Ciavaglia
Nokia
Route de Villejust
91620 Nozay
France
Email: laurent.ciavaglia@nokia.com


Lisandro Zambenedetti Granville
Federal University of Rio Grande do Sul (UFRGS)
Av. Bento Gonçalves
Porto Alegre-RS
9500
Brazil
Email: granville@inf.ufrgs.br


Jeff Tantsura
Microsoft
Email: jefftant.ietf@gmail.com

That's a wrap on RFC 9315! 🌈✨ Slay, bestie 💖