NMA Lifecycle Management YANG Data Model

Introduction Network Management Agents (NMAs) are increasingly being used for network fault analysis, path optimization, change recommendations, and other network management scenarios. NMAs from different vendors represent lifecycle states and version information differently, making unified management more difficult. This document defines a minimal YANG data model for NMA lifecycle management. It provides a consistent representation of instance information, lifecycle state, version state, and associated event notifications. The model can be implemented by an NMA itself or by a management adapter. Initiating and executing lifecycle operations, the internal implementation of an agent, and agent discovery protocols are outside the scope of this document.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology and Conventions This document uses the YANG 1.1 terminology defined in . Configuration and operational state data follow the concepts described in , and the YANG tree diagram uses the notation specified in .

NMA (Network Management Agent): A software agent instance used to perform network management tasks.
NMA Management System: A system that manages NMAs using the model defined in this document.

Relationship to Existing Work

RFC 9222: ASA Life Cycle Section 7 of , developed in the ANIMA Working Group, describes the life cycle of an Autonomic Service Agent (ASA) in terms of stages including Installation, Instantiation, Operation, and Removal. The NMA lifecycle states proposed in this document draw on the staged progression described in , with adjustments to address the operational control requirements for AI agents in production networks. Installation and pre-production validation are grouped into a production admission (admission) state; version replacement is explicitly represented by a changing state; and final removal is represented by an offboarded state. Furthermore, whereas focuses on lifecycle management primitives and operational procedures, this document represents these stages only as YANG state enumeration values and does not define control commands that trigger state transitions.

DAWN: Agent Discovery Information The DAWN Minimal Discovery Information (MDI) draft addresses the discovery of general-purpose agents on networks. It defines discovery attributes such as an Entity Identifier, entity type, and communication endpoints. This document assumes that NMA instances are already known to the management system through an external discovery mechanism. Accordingly, the model uses only agent-id as a unique lookup key within the management domain. It does not redefine discovery attributes, specify a mapping between agent-id and a DAWN Entity Identifier, or define any discovery-layer protocol.

NMA Lifecycle Management Framework In operator network management workflows, an NMA instance typically passes through four key management stages between introduction and retirement from production. Rather than directly issuing commands to control these stages, the ietf-nma-lifecycle model serves as a management-plane state record that captures essential configuration and operational state information at each stage:

Production Admission: After an NMA instance has been deployed and connected to the network management system, its lifecycle state is admission. At this stage, operators can use the configuration container to preconfigure the instance's operating mode (for example, initially selecting the shadow mode for passive testing and validation), permitted network scope (allowed-scope), and maximum operation risk level (max-risk-level). The instance can enter production after the external admission process has been completed successfully.
Runtime Management: An admitted NMA enters the active state. During operation, the management system can adjust its configuration policies at any time. For example, during a period of frequent faults, the NMA can be changed from autonomous to recommendation-only mode so that it presents proposed actions to on-duty operators for confirmation. The management system can also retrieve instance health and current version information through operational-state/health-status and version-state/current-version.
Version Change and Rollback: When an NMA undergoes a version upgrade or a rollback following a failure, its lifecycle state changes to changing. To avoid ambiguity during the transition, current-version continues to indicate the previous production version until the replacement has completed. When the external upgrade or rollback operation finishes, the instance reports the target version and final execution result (success or failed) through a version-change-result notification.
Planned Offboarding: When an NMA instance is no longer needed and an external process has completed its shutdown, its lifecycle-state transitions to offboarded. A lifecycle-state-change notification is also generated to support management-system archiving and auditing.

Design of the NMA Lifecycle YANG Model

Model Structure Overview The ietf-nma-lifecycle module uses a top-level agents container as its entry point. Within this container, NMA instances are represented by a list keyed by agent-id. The tree structure is shown below:

Description of Key Data Nodes Each agent instance comprises three categories of data nodes and three types of notifications: Instance Identification and Lifecycle State: The agent-id, name, vendor, and description nodes identify an NMA within the network management system and record its vendor and functional responsibilities. The read-only lifecycle-state node indicates the current lifecycle stage of the instance (admission, active, changing, or offboarded). Management Configuration (configuration container): This container defines policies that constrain an NMA during admission and operation:

operating-mode determines how the agent operates, with four progressively more autonomous modes:
- shadow (default): Processes live inputs in the background for testing or evaluation only. Inference outputs are recorded only in validation logs; they do not enter production work-order workflows or trigger network changes.
- recommendation-only: Participates in actual production operations by sending actionable recommendations to on-duty operators or a supervisory system, but does not execute operations without explicit confirmation.
- hybrid: Allows some operations to execute autonomously and requires explicit approval for others, depending on operation risk and management policies.
- autonomous: Independently executes network management operations within the configured risk limit and permitted scope.
max-risk-level defines six risk tiers from R0 through R5 (default: R0) to express the highest operation risk level the NMA is permitted to handle. This field expresses management intent only and does not replace actual access control and operation authorization mechanisms enforced by network elements or controller interfaces.
allowed-scope declares, as a string, the service domains, sites, or VPNs within which the NMA may operate. The deployment environment's policy engine determines how this string is parsed and how the scope boundaries are enforced.

Operational and Version State (operational-state and version-state containers): These two read-only containers expose the NMA's current health status and version information, respectively. In addition to the conventional up, degraded, and down values, health-status introduces a rate-limited enumeration value. This value indicates that NMA processing is impeded by rate limits on an underlying large language model inference API or by exhausted quotas for external tool invocations. The current-version node records the version of the current instance. Lifecycle Event Notifications: To allow the management system to detect state changes driven by external processes, the model defines three YANG 1.1 notifications under each agent instance. lifecycle-state-change reports the new state whenever a lifecycle transition occurs. version-change-result reports the target version and whether an upgrade or rollback succeeded when the operation completes. health-status-change reports the new health status when that status changes.

YANG Module The module structure is defined in accordance with .

Security Considerations The YANG model defined in this document is accessed through network management interfaces such as NETCONF or RESTCONF . The underlying transport MUST use a secure transport protocol, such as NETCONF over SSH or RESTCONF over TLS . Deployments SHOULD also enable the Network Configuration Access Control Model (NACM) to restrict unauthorized access. The following writable data nodes in the ietf-nma-lifecycle module are particularly security-sensitive:

/agents/agent/configuration/operating-mode: An unauthorized modification, such as maliciously changing this value from shadow or recommendation-only to hybrid or autonomous, could allow an NMA that has not been adequately validated to initiate changes directly in a production network.
/agents/agent/configuration/max-risk-level and /agents/agent/configuration/allowed-scope: Tampering with these nodes could expand the operation risk level or scope that an NMA is permitted to handle from the management system's perspective.

Furthermore, unauthorized access to read-only data nodes in the module (such as /agents/agent/lifecycle-state, operational-state, and version-state) or to its three notification types could reveal the distribution of software versions and lifecycle states of NMAs in a production network. An attacker could use this information to mount targeted attacks.

IANA Considerations This document requests that IANA register the following namespace in the IETF XML Registry:

URI: urn:ietf:params:xml:ns:yang:ietf-nma-lifecycle
Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace.

This document also requests the following registration in the YANG Module Names registry:

Name: ietf-nma-lifecycle
Namespace: urn:ietf:params:xml:ns:yang:ietf-nma-lifecycle
Prefix: nma-lifecycle
Reference: RFC XXX

Future Work In future revisions, the authors intend to explore the following extensions based on feedback from production deployments:

Composite Version Description: An NMA's actual behavior depends not only on its software code version, but also on the versions of the underlying foundation model, prompt templates, and external toolsets (such as MCP tools). Future work will evaluate whether version-state should be extended to represent fine-grained component versions and the baseline version used for rollback.
Structured References for Risk Levels and Permitted Scope: Future work will investigate linking allowed-scope to standard network topology models (such as ietf-network) and refining the relationship between risk tiers R0-R5 and approval policies.