NMOP Working Group B. Wu Internet-Draft Huawei Intended status: Informational M. Wang Expires: 7 January 2027 China Mobile X. Zhao CAICT D. Ceccarelli Cisco H. Zheng Huawei J. Zhou ZTE 6 July 2026 Problem Statement for Standardizing the northbound Task Interface (NTI) of the Network Management Agent draft-wu-nmop-nma-nti-problem-statement-00 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Wu, et al. Expires 7 January 2027 [Page 1] Internet-Draft NTI Problem Statement July 2026 This Internet-Draft will expire on 7 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Gap: From Atomic Operations to Task Delegation . . . 3 1.2. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 4 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Use Case 1: L3VPN Intermittent Performance Degradation . 5 2.2. Use Case 2: Cross-Domain Hardware Fault with Human Repair Action . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Gaps Identified from Operational Scenarios . . . . . . . . . 7 3.1. Structured Interface for Task Delegation . . . . . . . . 7 3.2. Intent Expression Above Data Operations . . . . . . . . . 8 3.3. Common Task Lifecycle Semantics . . . . . . . . . . . . . 8 3.4. Correlation with Existing IETF Data Models . . . . . . . 8 3.5. Programmatic Visibility into NMA Capabilities . . . . . . 9 3.6. Clarification of Layer Boundaries . . . . . . . . . . . . 9 3.7. Authorization Interface for Autonomous Operations . . . . 9 3.8. Event Notification for Task Progress . . . . . . . . . . 9 4. Relationship to Other Work . . . . . . . . . . . . . . . . . 10 4.1. RFC 8969: Controller NBI Architecture . . . . . . . . . . 10 4.2. YANG Message Broker Integration . . . . . . . . . . . . . 10 4.3. RFC 9315: Intent-Based Networking . . . . . . . . . . . . 10 4.4. RFC 9417/9418: Service Assurance for IBN . . . . . . . . 10 4.5. NMA Architecture . . . . . . . . . . . . . . . . . . . . 11 4.6. Network Incident YANG . . . . . . . . . . . . . . . . . . 11 4.7. Resource Performance Monitoring YANG . . . . . . . . . . 11 4.8. TMF A2A-T . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 12 Wu, et al. Expires 7 January 2027 [Page 2] Internet-Draft NTI Problem Statement July 2026 Appendix A. Workflow Comparison . . . . . . . . . . . . . . . . 14 A.1. Current Practice: OSS-Centric Orchestration . . . . . . . 14 A.2. The Gap: Task Delegation Without Standardization . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction The IETF has standardized data models and access protocols for network service management through YANG [RFC7950], NETCONF [RFC6241], RESTCONF [RFC8040], and the Controller NBI architecture [RFC8969]. 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). 1.1. 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 [RFC8641]. 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 Wu, et al. Expires 7 January 2027 [Page 3] Internet-Draft NTI Problem Statement July 2026 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. 1.2. 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. 2. 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. Wu, et al. Expires 7 January 2027 [Page 4] Internet-Draft NTI Problem Statement July 2026 2.1. 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 [RFC9375], alarm notification [RFC8632], topology [RFC8345], service assurance [RFC9418], and interface state [RFC8343]. 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. Wu, et al. Expires 7 January 2027 [Page 5] Internet-Draft NTI Problem Statement July 2026 2.2. 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. Wu, et al. Expires 7 January 2027 [Page 6] Internet-Draft NTI Problem Statement July 2026 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. 3. Gaps Identified from Operational Scenarios The operational scenarios in Section 2 reveal the following gaps, which a standardized NTI would need to address. 3.1. 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. Wu, et al. Expires 7 January 2027 [Page 7] Internet-Draft NTI Problem Statement July 2026 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. 3.2. 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. 3.3. 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. 3.4. 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. Wu, et al. Expires 7 January 2027 [Page 8] Internet-Draft NTI Problem Statement July 2026 3.5. 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. 3.6. 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). 3.7. 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. 3.8. 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. Wu, et al. Expires 7 January 2027 [Page 9] Internet-Draft NTI Problem Statement July 2026 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. 4. Relationship to Other Work The NTI is a consumer of existing IETF specifications and complementary to other SDO work; it is not a replacement. 4.1. RFC 8969: Controller NBI Architecture RFC 8969 [RFC8969] 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. 4.2. YANG Message Broker Integration [I-D.ietf-nmop-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. 4.3. RFC 9315: Intent-Based Networking RFC 9315 [RFC9315] 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. 4.4. RFC 9417/9418: Service Assurance for IBN RFC 9417 [RFC9417] and RFC 9418 [RFC9418] 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. Wu, et al. Expires 7 January 2027 [Page 10] Internet-Draft NTI Problem Statement July 2026 4.5. NMA Architecture [I-D.zhao-nmop-network-management-agent] 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. 4.6. Network Incident YANG [I-D.ietf-nmop-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. 4.7. Resource Performance Monitoring YANG [I-D.yu-ccamp-resource-pm-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. 4.8. TMF A2A-T TMF IG1453 (A2A-T) [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. 5. 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 [RFC8341]. Wu, et al. Expires 7 January 2027 [Page 11] Internet-Draft NTI Problem Statement July 2026 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 [RFC8341]. 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. 6. IANA Considerations This document makes no requests of IANA. 7. References 7.1. Normative References [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and L. Geng, "A Framework for Automating Service and Network Management with YANG", RFC 8969, DOI 10.17487/RFC8969, January 2021, . 7.2. Informative References Wu, et al. Expires 7 January 2027 [Page 12] Internet-Draft NTI Problem Statement July 2026 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . [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, . [RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm Management", RFC 8632, DOI 10.17487/RFC8632, September 2019, . [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, . [RFC9315] Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, "Intent-Based Networking - Concepts and Definitions", RFC 9315, DOI 10.17487/RFC9315, October 2022, . [RFC9375] Wu, B., Ed., Wu, Q., Ed., Boucadair, M., Ed., Gonzalez de Dios, O., and B. Wen, "A YANG Data Model for Network and VPN Service Performance Monitoring", RFC 9375, DOI 10.17487/RFC9375, April 2023, . [RFC9417] Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T. Arumugam, "Service Assurance for Intent-Based Networking Architecture", RFC 9417, DOI 10.17487/RFC9417, July 2023, . [RFC9418] Claise, B., Quilbeuf, J., Lucente, P., Fasano, P., and T. Arumugam, "A YANG Data Model for Service Assurance", RFC 9418, DOI 10.17487/RFC9418, July 2023, . [I-D.zhao-nmop-network-management-agent] Zhao, X., Wang, M., Wu, B., Ceccarelli, D., Zheng, H., and J. Zhou, "AI based Network Management Agent(NMA): Concepts and Architecture", Work in Progress, Internet-Draft, draft-zhao-nmop-network-management-agent-05, 6 July 2026, . Wu, et al. Expires 7 January 2027 [Page 13] Internet-Draft NTI Problem Statement July 2026 [I-D.ietf-nmop-network-incident-yang] Hu, T., Contreras, L. M., Wu, Q., Davis, N., and C. Feng, "A YANG Data Model for Network Incident Management", Work in Progress, Internet-Draft, draft-ietf-nmop-network- incident-yang-10, 6 July 2026, . [I-D.yu-ccamp-resource-pm-yang] Yu, C., Peruzzini, F., Yanlei, Z., Busi, I., Guo, A., Lopez, V., XingZhao, and M. Jin, "A YANG Data Model for Resource Performance Monitoring", Work in Progress, Internet-Draft, draft-yu-ccamp-resource-pm-yang-05, 7 January 2026, . [I-D.ietf-nmop-yang-message-broker-integration] Graf, T. and A. Elhassany, "An Architecture for YANG-Push to Message Broker Integration", Work in Progress, Internet-Draft, draft-ietf-nmop-yang-message-broker- integration-13, 2 July 2026, . [A2A-T] TM Forum, "IG1453: Autonomous Networks Agent-to-Agent (A2A) Task Interface", Version 1.0, 2025, . Appendix A. Workflow Comparison A.1. 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 Wu, et al. Expires 7 January 2027 [Page 14] Internet-Draft NTI Problem Statement July 2026 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. A.2. 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. Wu, et al. Expires 7 January 2027 [Page 15] Internet-Draft NTI Problem Statement July 2026 Traditional approach (YANG APIs) NTI approach ============================== ===================== OSS / Orchestrator OSS / Orchestrator | | +--------+--------+ +--------+--------+ | | | | v v v | Alarm PM Topology NTI task submission | Model Model (goal + constraints) | | | | +--------+--------+ | | | | | OSS local orchestration | | logic | | | v | v NMA internal Controller NBI (RFC 8969) orchestration & reasoning | | | v v | Network devices Controller NBI (RFC 8969) | v Network devices Figure 1: Traditional OSS-driven workflow vs. NMA task-driven workflow Authors' Addresses Bo Wu Huawei Email: lana.wubo@huawei.com Minxue Wang China Mobile Email: wangminxue@chinamobile.com Xing Zhao CAICT Email: zhaoxing@caict.ac.cn Daniele Ceccarelli Cisco Wu, et al. Expires 7 January 2027 [Page 16] Internet-Draft NTI Problem Statement July 2026 Email: dceccare@cisco.com Haomian Zheng Huawei Email: zhenghaomian@huawei.com Jin Zhou ZTE Email: zhou.jin6@zte.com.cn Wu, et al. Expires 7 January 2027 [Page 17]