Problem Statement for Standardizing the northbound Task Interface (NTI) of the Network Management Agent
draft-wu-nmop-nma-nti-problem-statement-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Bo Wu , Minxue Wang , XingZhao , Daniele Ceccarelli , Haomian Zheng , Jin Zhou | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wu-nmop-nma-nti-problem-statement-00
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,
<https://www.rfc-editor.org/info/rfc7950>.
[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,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[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, <https://www.rfc-editor.org/info/rfc8969>.
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,
<https://www.rfc-editor.org/info/rfc8343>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm
Management", RFC 8632, DOI 10.17487/RFC8632, September
2019, <https://www.rfc-editor.org/info/rfc8632>.
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
September 2019, <https://www.rfc-editor.org/info/rfc8641>.
[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, <https://www.rfc-editor.org/info/rfc9315>.
[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,
<https://www.rfc-editor.org/info/rfc9375>.
[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,
<https://www.rfc-editor.org/info/rfc9417>.
[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,
<https://www.rfc-editor.org/info/rfc9418>.
[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,
<https://datatracker.ietf.org/doc/html/draft-zhao-nmop-
network-management-agent-05>.
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-nmop-
network-incident-yang-10>.
[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, <https://datatracker.ietf.org/doc/html/
draft-yu-ccamp-resource-pm-yang-05>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-nmop-
yang-message-broker-integration-13>.
[A2A-T] TM Forum, "IG1453: Autonomous Networks Agent-to-Agent
(A2A) Task Interface", Version 1.0, 2025,
<https://www.tmforum.org/resources/ig1453/>.
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]