]> Huawei

bill.wu@huawei.com

Cisco

dceccare@cisco.com

Telefonica

luismiguel.contrerasmurillo@telefonica.com

Lancaster University

d.king@lancaster.ac.uk

Huawei

giuseppe.fioccola@huawei.com

CMCC

zhouchengyjy@chinamobile.com

Network Management Agents Observability Control Intervention This document defines architecture and a set of requirements for Observability, Control, and Intervention for Network Management Agents. It identifies gaps in existing mechanisms and specifies required interaction capabilities between Agent supervision systems and network management agents across multi-vendor environments, specifically observability, control, and runtime intervention. The requirements aim to guarantee comprehensive, lifecycle control over AI agents and enable observation, constraint, intervention, and correction to ensure network operational resilience and continuity. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction AI agents are increasingly deployed for network management tasks — including service provisioning and network configuration change, service assurance and automated incident diagnosis and resolution. While the introduction of agents significantly improves the efficiency for network management, it also inevitably brings challenges such as hallucination and execution unreliability. Existing mechanisms for agent assurance typically rely on static guardrails (e.g., input/output validation, operation allowlists/blocklists, pre-action approval), while assuming that all agent failure modes can be predefined. Unlike deterministic software systems, however, LLM-based agents exhibit emergent behaviors that cannot be fully anticipated or encoded in static rules. When agentic systems produce novel actions or reasoning paths that fall outside predefined static boundaries, it might lead to risks such as unintended configuration changes, policy violations, or cascading failures in the network. The operational problems, architectural challenges, and technical gaps regarding the observability, control, and intervention of autonomous network management agents are thoroughly detailed in . This document builds upon those identified gaps to specify a set of essential requirements that supervisors need when deploying agents in real networks for agent observability, control, and intervention. Furthermore, it also defines an architecure for ICON — Intervention, Control, and Observability for Network Management Agents. This document specifies the architecture and communication requirements between the agent and the supervision system. It does not standardize the internal LLM architecture, planning algorithms, or training methodologies of the network management agents themselves. This document does not specify a particular protocol, data model, or implementation API. Those topics are orthogonal to the operational requirements defined here, which are intended to be solution-neutral.

Observability, Control and Intervention Workflow of Network Management Agents When AIOPS Assistant exchanges the user intent with an untrusted Network Management Agent or a network management agent with lowest trust score, the Agent Observability process and Evaluation process will be intitialized to collect and evaluate Agent behavior information. In case of high risk operation or agent deviating from what Agents are expected to do, the decision will be escalated to the human. Human operation will use Intervention signal or control signal to provide guardrail protection for Agent behavior.

Sample Workflow Observability| +------------------+ | Process | +-------------+ Observability Signal interface ]]>

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the following terms defined in :

• Observability
• Intervention
• Control
• Human Oversight

This document defines the following terms:

context:

The network operational data, interaction history, and situational network parameters that allow AI agents to remember the history of a specific interaction over multiple turns.

Existing Mechanisms for Agent Observability, Control, and Intervention After receiving a user request, agents will perform a chain-of-thought (CoT) reasoning process, then it will autonomously decide whether to break down the task into subtasks, or dynamically decide to invoke multiple external tools, retrieve vector databases (RAG), or request more information from the supervisor. Existing telemetry mechanisms are excellent for tracking traditional network infrastructure or software which are built for deterministic systems. However, as analyzed in , they are facing severe limitations when applied to AI agents. For example, existing logging practices only record what action was taken, completely missing why it was taken, including the agent's internal reasoning provenance and confidence scores. Existing tracing mechanism designed for static and linear execution path also cannot capture the complex and dynamic execution trajectories of AI agents. Existing AI guardrails primarily operate at static boundaries, such as input/output validation and pre-action checks. These mechanisms are designed to constrain AI agents within predefined operational and compliance boundaries, but they assume that all possible violations can be anticipated and encoded in static rules. As AI systems increasingly operate in non‑deterministic environments, these static measures are proving insufficient as they cannot detect, interrupt, and recover from unanticipated behaviors. Although there are some modern agent systems that provide interrupt or kill switch capabilities, they remain framework-specific, insufficient, or proprietary. These gaps motivate the architectural framework and requirements for agent observability, control, and intervention defined in and , respectively.

Architectural Framework for ICON This section describes the reference architecture for ICON. The architecture defined in serves as the structural foundation to derive the requirements specified in .

ICON Architecture | || | | | | | | | | || |Agent 1| |Agent 2| ... | | |+-------------+| || | | | | | | ||Observability|| || +---^---+ +---^---+ | | |+-------------+| || | | | | | | +---------+ || +---v- --------------------+ | | (b)| | | | || |Function Modules & Tools | | <----> (b) Human | || +--------------------------+ | | | <-> | |+-------------------------------+ | |+-------------+| | | | | || Control || |Oversight| +----------------------------------+ |+-------------+| | | | | +---------+ +----------------------------------+ | | | Network Controller Layer | | | |+-------------------------------+ | | | || Agent Enforcement Plane(Agent | | |+-------------+| || +-------+ +-------+ Fabric) | | || Intervention|| || | | | | | | (a)|+-------------+| || |Agent 1| |Agent 2|... | <----> | || | | | | | | | | || +---^---+ +---^---+ | | | | || | | | | | | || +---v- -------------------+ | | | | || |Function Modules & Tools | | | (b)| | || +-------------------------+ | <----> | |+----------------------------- -+ | | | | | | | +--------------+-------------------+ |---------------+ | | Legend: +--------------V------------------+(a)Observability Interface | Network Infrastructure |(b)Intervention and Control +---------------------------------+ Interface ]]>

Human Oversight Human oversight represents the top-level authority of the agent management. It provides the post-execution feedback, injects global policies, reviews agent escalation requests, and issues high-level intervention commands during crises or anomalies.

• Policy and Constraint Injection:

  Human operators could express high-level operational constraints or boundaries. These intents are translated into machine-readable policies by ICON client and sent to the policy enforcement component.

• Escalation Handling:

  When an active agent encounters an ambiguous scenario, a conflict between different policies, or a decision whose confidence score falls below a predefined threshold, the enforcement plane suspends the task and escalates it to operators. A human operator could either approve, reject, or modify the agent's pending action sequence.

• Emergency Intervention Trigger:

  In case of an unforeseen and deviated agent behavior (e.g., an agent entering an infinite inference loop or executing based on outdated data or incorrect assumption), human oversight allows immediate, manual injection of high-priority override instructions (e.g., global kill switches or behavior corrections).

• Post-Execution Feedback:

  Beyond runtime intervention, human operators could also provide a critical retrospective evaluation feedback. Following an incident, anomaly, or successful resolution, human operators may inject multi-dimensional feedback (e.g., assessing the agent’s reasoning paths, correcting intermediate planning errors, or evaluating the quality of tool selection). This retrospective feedback could be used to update the prompt templates or refine downstream guardrail policies, preventing the recurrence of similar behavioral drifts.

It is worth mentioning that human operators rarely send raw agent control or intervention protocol payloads directly. They could use more flexible and human-friendly formatting such as natural language which is relayed to the agent management plane to translate into structured control or intervention signals for normalization and distribution.

Agent Management Plane Agent management plane is the Agent assurance capabilities which are used to manage, monitor, and regulate autonomous AI agents on behalf of human operators. It is logically decoupled from the agent enforcement plane. Note that agent management plane might include other technical and operational pillars such as agent lifecycle management, which are out of the scope of this draft.

• Observability:

  It receives observation streams transmitted from downstream agent enforcement plane. It provides human operators with comprehensive agent behavioral visibility and the ability to identify operational anomalies or performance drifts.

• Policy Control:

  It acts as the centralized Policy Decision Point (PDP) that translates human operator intent or operational guidelines into agent behavioral boundaries, guardrails, or operational constraints. It dynamically pushes a set of structured rules or policy constraints down to agent enforcement plane.

• Emergency Intervention:

  It hosts the emergency orchestration logic required to reactively instruct agents in response to boundary violations, anomalies, failures, or operational risks. Upon detecting critical policy violations or receiving manual override commands from human oversight, it generates specific instructions (such as pause or terminate) and pushes them down to the enforcement component. In addition, it also receives upstream messages initiated by agents, such as escalation requests that proactively require human intervention.

In practical deployments, the agent management plane may be embedded within network management systems/OSS, an external Agent supervision or management platform, or even an upper-layer supervisor Agent.

Agent Enforcement Plane The Agent Enfocement Plane is the runtime environment in which AI agents operate, perform reasoning and planning, collaborate with other agents, and invoke capabilities exposed through the Function Modules & Tools layer described in . Through that layer, agents obtain network information and translate their reasoning outcomes into operations on the network infrastructure. The Agent Enforcement Plane receives high-level intents originating from network operators or upstream agents and executes the corresponding tasks step by step. An agent may delegate parts of a task to other agents. Each execution step may involve invoking tools, function calls, APIs, knowledge retrieval interfaces, or reusable agent skills exposed through the Function Modules & Tools layer. During and after task execution, the Agent Enforcement Plane collects execution status, operational logs, tool invocation records, and resulting network observations. It provides the corresponding agent observability data to the Agent Management Plane for supervision. The Agent Enfocement Plane supports policy enforcement at critical points throughout task execution, including before task processing, before tool invocation or network actions, and before delivering a final response. It also accepts and applies Agent Control and Intervention Signals received from the Agent Management Plane.

Function Modules & Tools As depicted in , agents in the Agent Enforcement Plane act on the network infrastructure via the Function Modules & Tools layer rather than interacting with network devices directly. Agents invoke this layer to translate their reasoning decisions into concrete operational actions on the underlying network. Although represented as a single functional block in , this layer could abstract a richer and heterogeneous set of functions and tools. It may encompass, for example, the tool and function-calling interfaces exposed to agents, network management protocol adapters and clients (e.g., NETCONF , RESTCONF ), API gateways, retrieval and knowledge access components (e.g., RAG or vector-database lookups), reusable agent skills, and automation scripts. The internal composition, interfaces, and orchestration are implementation specific. A detailed decomposition of this layer is outside the scope of this document, which focuses on the requirements of observability, control, and intervention interactions between the Agent Management Plane and the Agent Enforcement Plane. Consequently, this layer is intentionally treated as an abstract entity in this framework.

Requirements

Observability Requirements The observability requirements are organized into the following categories:

• Execution Trajectory and Decision Logic ()
• Data Governance, Accountability ()
• Observability Infrastructure Requirements ()
• Agent Metrics Collection ()

Execution Trajectory and Decision Logic

OBS-1: Step-by-Step CoT and Execution Trajectory Capture

The framework must support visibility into complete agent execution trajectories, including reasoning CoT, actions planning, executed steps, and network observations. In a network change scenario, e.g., it must include capturing the specific mapping from the agents' reasoning chain and action planning to the generated network configuration diffs (e.g., CLI changes, Yang patches) and the subsequent network state observations, enabling end-to-end traceability from thinking to network effect.

OBS-2: Reasoning and Knowledge Provenance

The framework must support visibility into reasoning provenance, including intent understanding, inference, confidence scores, and evidence chains justifying why a specific network operation decision was made. It must also track external knowledge sources, version numbers, and matching weights retrieved and referenced by the agent during decision-making and enable traceability of how external information influenced the agent's reasoning steps.

OBS-3: Tool Invocation Capture

The framework must capture the complete input/output of all tools (Skills, APIs, CLIs, scripts) invoked by the agent, including tool selection logic and parameter bindings, and execution results.

OBS-4: Human-on-the-Loop and Multi-Agent Delegation

It must capture human expert interventions (e.g., kill switch, pause, rollback), escalation handling, and feedback signals on agent actions in the workflows. In case of multi-agent collaboration, the framework must track inter-agent communication messages, task delegation paths, anddynamic collaboration.

Data Governance and Accountability

OBS-5: Telemetry Integrity and Completeness Protection

The framework must support tamper-evident mechanisms (e.g., cryptographic hashing) to prevent unauthorized alteration or omission of execution trajectories. This ensures the integrity and completeness of observability data.

OBS-6: Privacy Protection

The framework must apply dynamic redaction to sensitive data, including prompt text, network topology information, Personally Identifiable Information (PII), and credentials before telemetry data is persisted or exported. The redaction process must be context-aware and must not impede the diagnostic value of the telemetry for authorized operators.

OBS-7: Accountability

The framework must support immutable audit logging of agent execution, enabling attribution of network outcomes (e.g., service degradation, configuration drift, new alarms) to specific intent interpretations, LLM inferences, tool/skill invocations, and actions for post-incident audit and compliance review. The framework must support reverse tracing from network operational state or newly raised alarms to the specific historical reasoning or tool/API invocation action that triggered it.

Observability Infrastructure Requirements

OBS-8: Authoritative Clock Synchronization & Event Ordering

The framework must provide an authoritative clock source and a causal event-ordering model (Event-Ordering Model) across all distributed components. This ensures that agent reasoning steps, tool invocations, and network state changes are associated with a globally consistent timestamp baseline across distributed environments.

OBS-9: Telemetry Pipeline Resilience

The observability pipeline must support adaptive backpressure, dynamic sampling, and retention policies to prevent telemetry storms from overwhelming collectors caused by, e.g., intensive agent Chain-of-Thought (CoT) reasoning logs or high-frequency tool invocation traces. The pipeline should additionally support self-health monitoring capabilities to detect data loss, transmission latency, or connectivity disruptions at telemetry collectors in real time.

Agent Metrics Collection

OBS-10: Operational Health, Resource, and Efficiency Metrics

The framework must support the collection of metrics characterizing agent operational health, cost, and efficiency. This includes, but is not limited to failed tool/API invocation rates, action execution latency, configuration rollback rates, token consumption, reasoning latency including Time to First Token (TTFT) and Time Per Output Token (TPOT), task completion rates and Mean Time To Repair (MTTR).

Control Requirements The control requirements are organized into the following categories:

• Agent Execution Guardrails and Risk Control ()
• Authorization and Access Control ()
• Policy Precedence and Concurrency Control ()
• Agent Control Resilience ()

Agent Execution Guardrails and Risk Control CTL-1: Action Risk Classification : The framework must require an agent to classify the risk level of any action (e.g., Low, Medium, High, Critical) prior to execution. The classification must consider the operation type, target device roles, and potential impact on network stability. Downstream policy engines must consume this risk level to enforce differentiated approval workflows and constraints. CTL-2: Maximum Blast Radius Limits : The framework must enforce a configurable maximum blast radius for each agent action, restricting potential impact across device counts, link counts, service impact, customer scope, and traffic volume. The agent must evaluate the blast radius before execution and abort any action exceeding configured thresholds unless explicitly overridden by a human operator. CTL-3: Rate Limiting and Concurrency Control : The framework must enforce rate limits and concurrency controls on agent actions to prevent automation storms from overwhelming network devices or the management plane. Agents must comply with per-device, per-operator, and global rate limits, as well as maximum concurrent task thresholds. Exceeded actions must be queued or rejected with explicit feedback. CTL-4: Action Cancellation Semantics : The framework must define and support explicit cancellation semantics across three action states: Queued (remove without side effects), Executing (gracefully terminate and rollback where feasible), and Completed (interpret as a rollback request invoking inverse workflows). All cancellation results must be logged for accountability. CTL-5: Temporal and Contextual Validity : The framework must ensure that agents operate strictly within authorized network maintenance time windows. Additionally, agents must validate the freshness, integrity, and temporal validity of context, network state, and configuration data before acting upon it.

Authorization and Access Control CTL-6: Separation of Duties : The framework must enforce strict separation among five operational roles: Read-Only, Propose, Validate, Approve, and Execute. Each role MUST be tied to distinct credentials and permissions. A single agent or operator must not possess end-to-end capabilities across all roles without explicit supervisory authorization. This separation must be enforceable at both agent and orchestrator levels. CTL-7: Fine-Grained Access and Permissions : The framework must provide mechanisms to define and enforce fine-grained operational boundaries. This MUST include restricting an agent's scope to specific network domains, device sets, protocols, and tools, as well as YANG node-level access control specifying permitted datastores, YANG data nodes, and RPCs for read or modification. CTL-8: Authorization and Approval Escalation : The framework must support designating specific high-risk network operations as requiring explicit human approval before execution. It SHOULD support configurable escalation chains and communication channels to route approval requests sequentially to designated personnel. CTL-9: Progressive Authorization Upgrade and Downgrade : The framework must support a progressive authorization mechanism for network management agents during the deployment (e.g., from read-only, to restricted write, to autonomous execution), and the ability to downgrade authorization levels during operation based on assessment results.

Policy Precedence and Concurrency Control CTL-10: Change Attribution and Distributed Locking : The framework must support change attribution tracking and distributed locking mechanisms for concurrent multi-agent or human-agent operations. An agent MUST acquire a lock (containing owner identity, target scope, and expiration time) on target resources prior to initiating changes. Conflicting requests MUST be queued or rejected with clear conflict notifications. CTL-11: Cross-Domain Policy Conflict Resolution : The framework must implement deterministic cross-domain policy conflict resolution. When an action spans multiple policy domains (e.g., routing, security, QoS, multi-vendor domains) and generates conflicts, the framework MUST resolve them using configurable priority models (e.g., security policies take precedence over routing policies). Actions MUST be halted until conflicts are resolved or overridden by a human supervisor. CTL-12: Deterministic Authority Precedence : The framework must enforce a deterministic hierarchy across four control sources: Human Operators (highest precedence), Supervisor Agents, Orchestrators, and Autonomous Agents. When conflicting instructions are received, higher-precedence sources MUST preempt lower-precedence ones, and lower-precedence sources MUST receive preemption notifications. CTL-13: Intent Validation and Alignment : The framework must ensure agents validate high-level network intents received from operators or upstream agents before execution. Agents MUST verify that generated configuration syntax and semantics strictly align with network intents and operational constraints.

Agent Control Resilience CTL-14: Degraded Behavior on Control Plane Unreachability : The framework must define deterministic degradation behaviors when an agent loses connectivity with the ICON control/management plane. Agents MUST support at least one configurable fallback mode: (a) Fail-Safe (abort active/pending actions and enter read-only state), (b) Fail-Hold (complete current action but reject new requests), or (c) Fail-Local (continue execution using local cached authorizations). CTL-15: Management Plane High Availability and Geographic Isolation : The framework must support high availability and geographically isolated deployments for ICON management plane components across multiple availability zones with automated failover. Active operations MUST be safely recovered or re-evaluated by the backup primary control plane without duplicate executions or data loss. CTL-16: Intended vs. Actual State Reconciliation : The framework must support continuous reconciliation between intended network state and actual state derived from telemetry. When state drift is detected, agents MUST trigger idempotent automated remediation workflows unless explicitly disabled by operators. CTL-17: Dynamic Boundary Adaptation : The framework must support the injection of global coordination policies across multi-agent environments and enable dynamic adjustment of operational boundaries (e.g., tightening permissions from read-write to read-only) based on real-time network operational health and threat levels.

Intervention Requirements The intervention requirements are organized into the following categories:

• Runtime Execution Intervention ()
• Post-execution Rollback ()
• Escalation ()
• Correction ()

Runtime Execution Intervention

INT-1: Execution Interruption

The supervisor must be able to immediately stop or redirect or isolate or report a running agent's runtime execution.

• Pause and Stop

  The framework must support a temporary operational pause that preserves the execution state (e.g., giving human operators time to analyze before deciding on further action), as well as a hard stop that terminates execution with or without instant configuration rollback when an agent is actively causing network instability.

• Emergency Intervention

  Emergency intervention operations (e.g., pausing, terminating) must be executed independently of the agent's internal LLM reasoning state or responsiveness or other agent's runtime execution, i.e., the framework MUST support out-of-band emergency pause or kill-switch signals in cases where an agent encounters a major failure (e.g., infinite reasoning loops, deadlocks) or becomes totally unresponsive without affecting the other agent's runtime execution.

• Verification and reporting ：The framework must support explicit acknowledgement and effect reporting for intervention commands (e.g., termination, pause, stop), distinguishing between "command accepted" and "command applied". The execution plane must return the state of the intervention target before and after the command, the intervention result (completed, partially completed, failed, unknown), and the failure reason, and should support timeout reporting and retry semantics.

Post-execution Rollback

INT-2: Rollback and Recovery

The supervisor must be able to reverse actions already taken by an agent. The framework MUST support multiple granularities of action rollback. Based on the severity and impact of the failure, the rollback granularities SHOULD include:

• Agent Workflow Level

  Reverts a specific step or a subset of execution steps within the agent's execution chain, without canceling the overall task. This is applicable for localized errors. For example, When an agent is onboarding a network device, the supervisor rolls back only a failed post-configuration script execution step while keeping the successfully downloaded boot image.

• Agent Task Level

  Reverts an entire task execution, performing a comprehensive rollback of all network operations introduced since the initiation of the task. This is used as an emergency mechanism for severe failures where the agent's entire execution is failed. For example, when an agent fails to provision a network service, the supervisor triggers a full task rollback to wipe out the entire provisioning attempts across all affected nodes.

• Agent Context Level

  Reverts all network operations across multiple related tasks bound by the same context. This acts as an ultimate rollback mechanism to reset the entire multi-turn interaction or back to its original historical baseline. For example, during a multi-turn network troubleshooting conversation, an agent executes three tasks under the same context to mitigate an anomaly. If supervisor realizes the entire investigation pathway was flawed, they may select context level rollback to comprehensively wipe out all configuration changes made across all three tasks in this specific context.

Escalation

INT-3: Escalation

The framework must support the mechanism to allow the agent to route operational decisions, anomalies, and conflicts to a higher authority. An escalation is used when the current level (operator or agent) cannot or should not resolve the situation without supervision. During an escalation event, the framework must preserve the agent's runtime context and its full reasoning provenance trail to enable a seamless handover.

Correction

INT-4: Correction

The supervisor MUST be able to correct an autonomous agent failure through any of the following mechanisms:

• Providing Refined Intent

  Clarifying or refining the high-level intent when the agent misinterprets the operational goal.

• Injecting Additional Operational Constraints

  Appending runtime network constraints or specific limits.

• Providing Missing or Correcting network context

  supplying missing, updated or corrected network knowledge, telemetry data, or topological information that the agent relied on during its reasoning loop.

• Modifying Pending Actions or Planned Configuration Changes

  Adjusting the agent's generating configuration, tool selections, parameters, or execution order before they are applied to the network.

Security Considerations This document defines a set of functional requirements for observability, control, and intervention of AI agents in the context of network management. The requirements themselves do not introduce additional security vulnerabilities. Rather, this document requirements some security safeguards such as access control, identity authentication, and integrity guarantees that should be enforced by the implementation and deployed systems.

IANA Considerations This document has no IANA actions.

References Normative References Huawei Cisco CMCC Telefonica Lancaster University This document provides an overview of the issues associated with the deployment of the observability, intervention, and control of autonomous agent pipelines in large-scale heterogeneous network environments. The term "Observability, Intervention and Control" is used to describe a set of automated and human-initiated mechanisms that guarantee the capability to observe, evaluate, constrain, correct, and terminate Autonomous agents at any point, for any reason, irrespective of their level of autonomy under which it operates, to ensure resilience, recovery, and operational continuity. The set of enabled observability, intervention and control reflects operator service offerings to ensure that autonomous network operations can be stopped, or safely redirected when required and is designed in conjunction with agent to agent, agent to tools, agent to human interaction and service and network policy. This document also identifies several key areas that the Agent Observability, Intervention and Control group will investigate to guide its architectural and protocol work and associated documents. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Huawei China Mobile Telefonica China Unicom Daejeon University A Network Digital Twin (NDT) provides a network emulation tool usable for different purposes such as scenario planning, impact analysis, and change management. Agentic AI enables dynamic goal-driven execution and adaptive behavior and closed-loop autonomy. By integrating a NDT into network management together with the Agentic AI, it allows the network management activities to take user intent or service requirements as input, automatically assess, model, and refine optimization strategies under realistic conditions but in a risk-free environment. Such environment that operates to meet these types of requirements is said to have AI-driven network operations. AI-driven network operations brings together existing technologies such as Agentic AI and NDT which may be seen as the use of a toolbox of existing components enhanced with a few new elements. This document describes an architecture for AI-driven network operations and shows how these components work together with NDT and Agentic AI capabilities. This document is a glossary of policy-related terms. It provides abbreviations, explanations, and recommendations for use of these terms. The intent is to improve the comprehensibility and consistency of writing that deals with network policy, particularly Internet Standards documents (ISDs). This memo provides information for the Internet community. The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).

Acknowledgments The authors of this document would also like to thank Benoit Claise, Swamynathan B, Laurent Ciavaglia, Parisa Foroughi, Reza Rokui, Luis M. Contreras, Oscar Gonzalez de Dios, ZhenQiang Li, Cheng Zhou, Daniele Ceccarelli, Dan Voyer, Thomas Graf, Alex Huang Feng for review and comments.

Contributors Cisco

davoyer@cisco.com

Huawei

maqiufang1@huawei.com

Huawei

101 Software Avenue, Yuhua District Jiangsu 210012 China yangyuanyuan55@huawei.com