]> Huawei

lana.wubo@huawei.com

China Mobile

wangminxue@chinamobile.com

CAICT

zhaoxing@caict.ac.cn

Cisco

dceccare@cisco.com

Huawei

zhenghaomian@huawei.com

ZTE

zhou.jin6@zte.com.cn

NMOP Working Group AI-driven Network Management Agents (NMAs) are being deployed to automate operational workflows such as cross-domain fault diagnosis and service remediation. While the IETF has standardized service data models and access protocols through the Controller NBI (RFC 8969), these provide atomic configuration and monitoring capabilities, not the semantics for delegating end-to-end operational tasks to an autonomous agent. As a result, NMA northbound interfaces are vendor-specific overlays. This document defines the problem statement for the Northbound Task Interface (NTI): the interface through which an operator or OSS delegates operational tasks to an NMA.

Introduction The IETF has standardized data models and access protocols for network service management through YANG , NETCONF , RESTCONF , and the Controller NBI architecture . Within this framework, SDN Controllers expose standardized northbound interfaces for service configuration, operational state retrieval, and event notification. AI-driven Network Management Agents (NMAs) are being deployed within these Controllers to automate operational workflows -- such as fault diagnosis, service remediation, and what-if feasibility analysis -- that currently require human operators to decompose high-level goals into sequences of atomic data model operations. However, while the Controller NBI provides the data models and access mechanisms for individual network operations, it does not provide the semantics for delegating an end-to-end operational task to an autonomous agent. The interface through which an operator or OSS/BSS delegates such tasks to an NMA, and receives structured feedback on execution progress, is implemented today as vendor-specific overlays. This document defines the problem statement for standardizing these interfaces, referred to as the Northbound Task Interface (NTI).

The Gap: From Atomic Operations to Task Delegation The IETF has standardized data models for network configuration, operational state, topology, performance monitoring, and service assurance, accessible through the Controller NBI using NETCONF, RESTCONF, and YANG-Push . These interfaces provide deterministic operations on well-defined data structures: an OSS can retrieve an interface counter, modify a VPN parameter, or subscribe to an alarm stream. However, accomplishing an operational goal -- such as diagnosing and remedying a VPN service degradation -- requires the OSS to sequence and correlate multiple such atomic operations across independent YANG modules, interpret intermediate results, and decide on subsequent actions. The NBI provides the data and the operations, but not the semantics for delegating the end-to-end goal as a unitary task. NMAs address this by internally decomposing operational goals into NBI operations, executing them, and verifying outcomes. Because the NMA resides within the Controller and uses the standardized NBI as its southbound interface, its internal reasoning is decoupled from the consumer. Yet the northbound interface through which the consumer delegates the goal and monitors progress remains vendor- specific. In multi-vendor environments, operators must therefore maintain distinct integration logic per Controller. The gap is not in the data models or the access protocols, but in the task- abstraction layer above them. Existing standards define how to operate on network resources; what is missing is a standardized interface for expressing an operational intent, tracking its execution lifecycle, negotiating when constraints conflict, and discovering what autonomous capabilities an NMA supports.

Scope and Non-Goals This document defines the problem statement for the Northbound Task Interface (NTI): the interaction through which an operator or OSS/BSS delegates operational tasks to an NMA and receives structured feedback on execution progress, capability boundaries, and task outcomes. The following are explicitly out of scope:

• Internal NMA implementation: The data models, algorithms, or reasoning mechanisms used by the NMA to decompose tasks into southbound operations. The NTI standardizes the northbound contract, not the internal implementation.
• Agent-to-Agent (A2A) protocols: Inter-NMA negotiation, cross-domain task delegation, and multi-agent coordination. These are addressed by other opensource projects, or other SDO, e.g. TMF. The NTI is complementary: it standardizes how a single NMA exposes capabilities and reports progress to its consumer.
• Southbound data models: The NTI layers task semantics atop existing IETF data models without defining new device-level or service-level configuration structures.
• Transport protocol definition: The NTI standardizes the semantics and information model for task delegation. Whether these semantics are carried over RESTCONF, NETCONF, or another existing IETF protocol is a matter for subsequent work.

Problem Statement The scenarios below do not argue that AI-driven diagnosis is superior to existing automation; they demonstrate that when an NMA is capable of autonomous reasoning, the absence of a standardized task interface forces the OSS to integrate with vendor-specific overlays.

Use Case 1: L3VPN Intermittent Performance Degradation Scenario: A gold-tier enterprise L3VPN service (VPN-Corp-A) experiences bursty quality degradation during peak hours. End users report application timeouts and video conference freezes. Network monitoring shows periodic packet loss bursts (2-5 seconds, several times per hour) with rapid recovery. Traditional threshold-based alarms cannot reliably detect this: the loss bursts are too brief to trigger sustained alarm conditions, and average loss over 5-minute intervals remains within normal range. The Controller NBI exposes YANG models for VPN service configuration (ietf-l3vpn-ntw), VPN performance monitoring , alarm notification , topology , service assurance , and interface state . The OSS can retrieve VPN routing state, query interface counters, subscribe to telemetry streams, and receive threshold-crossing alarms. The operator's goal is not to "retrieve counters" but to "restore VPN-Corp-A to contracted SLA (packet loss < 0.1%, latency < 50ms) and identify the root cause." Achieving this goal requires correlating transient events across multiple data sources over time, which the existing NBI does not support as a delegable task. Specifically, the diagnostic process involves:

1. Detecting the micro-burst pattern (2-5 second loss) that does not trigger sustained alarms, requiring high-frequency telemetry analysis.
2. Localizing the fault to ingress PE, egress PE, or core P-node path by correlating interface drop counters across nodes.
3. Identifying the root cause: congestion, routing instability, MTU mismatch, or link-level errors.
4. Selecting and executing remediation (QoS adjustment, BGP policy tuning, protection switching, etc.).
5. Verifying that the micro-burst pattern disappears and SLA metrics are restored.

The gap: The existing NBI provides all the raw data for steps 1-5, but no semantics to delegate the end-to-end goal. The OSS must either implement all correlation and reasoning logic itself, or integrate with a vendor-specific NMA interface. In a multi-vendor network, the latter requires distinct integration logic per Controller vendor.

Use Case 2: Cross-Domain Hardware Fault with Human Repair Action Scenario: A 5G base station (gNB-001) connects to the IPRAN access network via a single fiber pair to PE-agg-01. The operator observes service degradation for cells served by gNB-001. The goal is to determine whether the root cause lies in the IP transport domain or the RAN access domain, and to restore service or prepare a structured human repair action. The IP domain Controller has a co-resident NMA. The RAN domain is managed by a separate Controller with limited northbound data exposure. The IP domain Controller NBI exposes YANG models for interface state (ietf-interfaces), performance monitoring (ietf-network-vpn-pm), and other necessary metrics. The OSS can query these directly. The operator's goal is not to "query interface counters" but to "determine the root cause and restore service, or prepare a structured human repair action if the fault is physical." This goal spans both domains, but the OSS must perform the correlation itself. The NMA in the IP domain can:

1. Query the gNB-001 attachment interface on PE-agg-01: admin-up, oper-down. Optical RX power on PE-agg-01: -28dBm (below receiver sensitivity of -20dBm). Optical TX power on PE-agg-01 is within normal range. Conclusion: PE-agg-01 is transmitting normally but receiving no usable light.
2. Infer fiber plant status from available IP-domain data: the interface on PE-agg-01 shows no administrative disable, no protection switching events, and no interface-level alarms beyond the loss of signal. The optical transceiver on PE-agg-01 reports that a faint optical signal is detected on the receive side, though insufficient for data reception. Conclusion: there is no positive evidence of a fiber break observable from the IP domain; the fault appears to be upstream of PE-agg-01.
3. Query Layer 2/Layer 3 reachability: no ARP response or ICMP echo reply from gNB-001. The faint optical signal detected on PE-agg-01 indicates the remote transmitter is emitting weak light. Conclusion: gNB-001 is powered but data signal is insufficient.
4. Query RAN domain status: gNB-001 reported as "administratively online" by RAN OAM 5 minutes ago, but current status query times out. No "site power loss" alarm. Conclusion: base station likely has power but management/data paths are non-functional.
5. Correlate findings: optical RX below threshold, no positive evidence of fiber break from IP domain data, PE-agg-01 TX normal, gNB-001 emits weak signal but no protocol response, no power alarm. Root cause inference: gNB-001 optical transceiver (TX side) degraded or failed, or there is a partial fiber fault between gNB-001 and PE-agg-01 that severely attenuates the signal. IP domain equipment is not at fault, though the exact boundary of the failure (gNB-001 transceiver vs. fiber plant) cannot be determined from IP-domain data alone.
6. Determine: physical inspection or repair at gNB-001 site is required. Possible actions include optical transceiver replacement at gNB-001, fiber cleaning, or fiber plant testing. No autonomous remediation available. Task cannot be fully closed without human repair action.

The gap: At step 6, the NMA has completed diagnosis but cannot complete remediation. The OSS needs:

• Task status: not "success" or "failure," but "diagnosed, human repair action required"
• Structured human repair data: location, action, estimated duration, business impact
• Evidence trace: references to YANG-modeled data supporting the diagnosis

The existing NBI provides no semantics for the NMA to report such a structured conclusion. The OSS must either perform this correlation itself or integrate with each vendor's proprietary diagnostic output. In a multi-vendor deployment, diagnostic quality, repair dispatch workflows, and programmatic verifiability remain vendor-specific.

Gaps Identified from Operational Scenarios The operational scenarios in reveal the following gaps, which a standardized NTI would need to address.

Structured Interface for Task Delegation Current NMA northbound interfaces are implemented as vendor- specific constructs: proprietary REST APIs, gRPC schemas, or conversational prompt templates. In multi-vendor environments, operators must integrate with each of these variations individually. The gap is the absence of a common, machine-readable structure for expressing operational goals, constraints, and execution feedback. Whether such a structure is expressed in YANG, JSON Schema, or another formalism is a matter for subsequent standardization work.

Intent Expression Above Data Operations The existing Controller NBI enables the OSS to operate on network resources -- modify a VPN parameter, retrieve a metric, subscribe to an alarm stream. However, the operator's goal is often expressed at a higher level: "restore VPN-X to its SLA within 30 minutes." The gap is that current NMA interfaces either expose the same data operations as the NBI (forcing the OSS to decompose the goal itself) or accept goals through proprietary, unstructured formats. There is no standardized mechanism for expressing an operational intent with its associated constraints and success criteria.

Common Task Lifecycle Semantics Current vendor NMA interfaces use divergent models for tracking task execution. One vendor may report "submitted -> in_progress -> done -> failed"; another may use "accepted -> analyzing -> acting -> verifying -> closed"; a third may expose no intermediate states at all, requiring the OSS to poll for completion. The gap is the absence of common semantics for expressing task progress, partial completion, suspension awaiting human input, or handover to another system. Operators cannot build unified dashboards or automated escalation workflows without normalizing these divergent state models.

Correlation with Existing IETF Data Models When an NMA reports a diagnostic conclusion or remediation result, the consumer needs to verify it against the network state. Current vendor implementations use proprietary formats for referencing incidents, alarms, performance metrics, and topology resources. The gap is the absence of a standardized mechanism for NMA outputs to reference existing IETF data model instances -- such as an ietf-network-incident record, an ietf-alarms instance, or an ietf-network-vpn-pm metric -- by standard identifier. Without this, the consumer cannot programmatically correlate NMA conclusions with the underlying network data.

Programmatic Visibility into NMA Capabilities Operators managing multi-vendor networks lack a standardized mechanism to determine what tasks an NMA supports without vendor- specific integration. Capability information is typically conveyed in human-readable documentation or proprietary API descriptors, not in a machine-consumable structure that an OSS can query and act upon. For example, one vendor's NMA may support autonomous VPN fault remediation; another's may only support advisory diagnosis.

Clarification of Layer Boundaries Some current NMA implementations expose operations through their northbound interface that are already available through the Controller NBI -- such as VPN service creation, tunnel parameter modification, or QoS policy adjustment. This creates ambiguity for the consumer: should the OSS use the standardized NBI directly, or the NMA's proprietary interface for the same operation? The gap is the absence of a clear boundary between the task layer (what goal to achieve) and the data layer (how to configure a resource).

Authorization Interface for Autonomous Operations When an NMA performs autonomous remediation, the operator needs to define and enforce boundaries: what actions may be taken without human confirmation, under what time constraints, and with what scope limitations. Current vendor implementations use proprietary authorization models -- some support per-task risk levels, others use static allow-lists, others provide no programmatic control at all. The gap is the absence of a standardized mechanism for the consumer to express authorization constraints to the NMA and for the NMA to report compliance with those constraints.

Event Notification for Task Progress Current NMA interfaces require the OSS to either poll for task status or maintain vendor-specific event subscriptions. In multi- vendor environments, this forces the OSS to implement multiple notification mechanisms -- REST callbacks, gRPC streams, or proprietary message formats. The gap is the absence of common semantics for notifying the consumer of task progress, partial completion, or state transitions that require human attention. Whether these notifications are delivered via YANG-Push, HTTP callbacks, or another mechanism is a matter for subsequent standardization.

Relationship to Other Work The NTI is a consumer of existing IETF specifications and complementary to other SDO work; it is not a replacement.

RFC 8969: Controller NBI Architecture RFC 8969 defines the architecture for a YANG-based controller northbound interface. The NTI assumes this architecture: the NMA resides within or alongside the Controller and consumes the NBI for southbound operations. The NTI operates at the layer above the NBI, where operational tasks are delegated to the NMA and execution progress is reported back.

YANG Message Broker Integration defines an architecture for integrating YANG-Push notifications with message brokers and schema registries. The NTI may reference data distributed through this architecture as part of Task Context. The NTI consumes standardized data; it does not redefine the distribution mechanisms.

RFC 9315: Intent-Based Networking RFC 9315 defines Intent-Based Networking (IBN) concepts for expressing network service and resource configuration objectives. The NTI addresses a distinct but related scope: operational task delegation -- such as fault diagnosis, service assurance remediation, and what-if analysis -- rather than network resource configuration. The two may be used together, but neither depends on the other.

RFC 9417/9418: Service Assurance for IBN RFC 9417 and RFC 9418 define the SAIN architecture and YANG models for health scores, symptoms, and assurance graphs. The NTI may reference SAIN-modeled data in Task Context or execution results, but does not define assurance data structures; it references them by standard identifier.

NMA Architecture defines the NMA concept, architecture variants, and deployment modes. It identifies the need for a northbound task interface but does not define its semantics. This document provides the problem statement motivating that standardization work.

Network Incident YANG defines a YANG model for network incident lifecycle management. The NTI may reference incident instances in Task Context, but does not define incident structures.

Resource Performance Monitoring YANG defines a YANG model for resource performance monitoring. The NTI may reference resource PM data in Task Context or execution results, but does not define PM data structures.

TMF A2A-T TMF IG1453 (A2A-T) defines generic task templates, event structures, and negotiation semantics for cross-domain multi-agent collaboration. The NTI addresses a related but distinct scope: how a single NMA exposes task delegation, capability, and progress reporting to its consumer using IETF management protocol identifiers. Where an operator uses A2A-T for inter-domain coordination, the NTI defines how those same task concepts are expressed within the IETF management stack. The two are complementary and not overlapping.

Security Considerations Standardization of the NTI would introduce the following security considerations, which are distinct from those of the underlying management protocols (NETCONF, RESTCONF) due to the higher semantic level of task delegation. Intent Injection: A compromised consumer could submit malicious goals that trigger unintended autonomous actions across the network. This risk is analogous to configuration injection but operates at a higher semantic level where a single task maps to multiple underlying operations. Standardization of the NTI would need to consider how intent authentication, authorization, and scope validation relate to existing mechanisms such as NACM . Information Leakage: NTI responses may contain diagnostic conclusions, evidence traces, or capability descriptions that reveal internal network topology, resource utilization, or operational weaknesses. Standardization would need to consider how response content is authorized and filtered, potentially leveraging access control frameworks such as NACM . Concurrent Operation Conflicts: In deployments where both the NTI and direct NBI access are available, a task delegated through the NTI may overlap with manual NBI operations. This creates potential for race conditions. Standardization would need to make such conflicts visible and auditable.

IANA Considerations This document makes no requests of IANA.

References Normative References YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). 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). The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle (e.g., service instantiation, service provisioning, service optimization, service monitoring, service diagnosing, and service assurance). Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance. This document describes a framework for service and network management automation that takes advantage of YANG modeling technologies. This framework is drawn from a network operator perspective irrespective of the origin of a data model; thus, it can accommodate YANG modules that are developed outside the IETF. Informative References This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics). The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. This document obsoletes RFC 7223. This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models. This document defines a YANG module for alarm management. It includes functions for alarm-list management, alarm shelving, and notifications to inform management systems. There are also operations to manage the operator state of an alarm and administrative alarm procedures. The module carefully maps to relevant alarm standards. This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. Intent and Intent-Based Networking are taking the industry by storm. At the same time, terms related to Intent-Based Networking are often used loosely and inconsistently, in many cases overlapping and confused with other concepts such as "policy." This document clarifies the concept of "intent" and provides an overview of the functionality that is associated with it. The goal is to contribute towards a common and shared understanding of terms, concepts, and functionality that can be used as the foundation to guide further definition of associated research and engineering problems and their solutions. This document is a product of the IRTF Network Management Research Group (NMRG). It reflects the consensus of the research group, having received many detailed and positive reviews by research group participants. It is published for informational purposes. The data model for network topologies defined in RFC 8345 introduces vertical layering relationships between networks that can be augmented to cover network and service topologies. This document defines a YANG module for performance monitoring (PM) of both underlay networks and overlay VPN services that can be used to monitor and manage network performance on the topology of both layers. This document describes an architecture that provides some assurance that service instances are running as expected. As services rely upon multiple subservices provided by a variety of elements, including the underlying network devices and functions, getting the assurance of a healthy service is only possible with a holistic view of all involved elements. This architecture not only helps to correlate the service degradation with symptoms of a specific network component but, it also lists the services impacted by the failure or degradation of a specific network component. This document specifies YANG modules for representing assurance graphs. These graphs represent the assurance of a given service by decomposing it into atomic assurance elements called subservices. The companion document, "Service Assurance for Intent-Based Networking Architecture" (RFC 9417), presents an architecture for implementing the assurance of such services. The YANG data models in this document conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. The evolution from Level 3 (assisted automation) to Level 4 (closed- loop autonomy) in Autonomous Networks (AN) introduces requirements for agentic capabilities, including intent-based reasoning, autonomous planning, and context-aware decision-making, and execution coordination, which transcend the static, rule-based logic of traditional network controllers. This document defines the concept of the Network Management Agent (NMA), a network management entity with autonomous task processing capabilities designed to bridge the gap between service intent and network operations. This document describes the role of NMA in network management and control architectures, and specifies how the NMA collaborates with existing network controllers to achieve Autonomous L4 without replacing or duplicating their functions. It further defines the reference architecture, deployment modes, and logical interfaces of the NMA, including Agent-to-User (A2U), Agent-to-Agent (A2A), Agent- to-Controller (A2C), and Agent-to-Network (A2N) interactions. This document defines a YANG Module for the network incident lifecycle management. This YANG module is meant to provide a standard way to report, diagnose, and help reduce troubleshooting tickets and resolve network incidents for the sake of network service health and probable cause analysis. Huawei Technologies FiberCop China Unicom Huawei Technologies Futurewei Technologies Nokia CAICT Huawei Technologies This document defines a YANG data model for resource Performance Monitoring, applicable to network controllers, which provides the functionalities of retrieval of performance monitoring capabilities, TCA (Threshold Crossing Alert) configuration, current or history performance data retrieval, and performance monitoring task management. Swisscom Swisscom This document describes the motivation and architecture of a native YANG-Push notifications and YANG Schema integration into a Message Broker and YANG Schema Registry. TM Forum

Workflow Comparison

Current Practice: OSS-Centric Orchestration In today's multi-vendor deployments, an OSS managing VPN service assurance must interact with each Controller's NBI directly. For a fault diagnosis task, the OSS typically:

1. Subscribes to alarm streams via YANG-Push
2. Retrieves performance metrics from ietf-network-vpn-pm
3. Queries topology from ietf-network-topology
4. Correlates findings in custom application logic
5. Decides on remediation actions
6. Executes configuration changes via NETCONF/RESTCONF
7. Verifies recovery through repeated metric queries

Steps 1-7 must be implemented per vendor, as each Controller may expose different YANG module versions, different notification mechanisms, or different RPC signatures. The orchestration logic -- state machines, error handling, retry policies, correlation rules -- is maintained in the OSS layer.

The Gap: Task Delegation Without Standardization When an NMA exists within the Controller, capable of performing steps 1-7 internally, the OSS currently has no standardized interface to delegate the goal. Instead, the OSS must either continue executing steps 1-7 itself, or integrate with the vendor's proprietary task interface, replicating this integration for each Controller vendor. The NTI would address this gap by providing standardized semantics for the OSS to express the operational goal, receive progress updates, and obtain structured results -- without requiring the OSS to know how the NMA internally decomposes the task into NBI operations. The following diagram illustrates the conceptual relationship between the layers.

Traditional OSS-driven workflow vs. NMA task-driven workflow