Guidance from the Management Area Director on evaluating AI/ML network management submissions
v1.3 · Last updated: 15 July 2026
Side Meeting — IETF 126, Vienna
There will be a side meeting on this topic on Friday, July 24 at 8:00 a.m. in Park Suite 4. Room capacity is limited; attendees are encouraged to join remotely via WebEx: https://ietf.webex.com/meet/sidemeetings1
Agenda/Logistics/Notes: https://notes.ietf.org/notes-ietf-126-sidemeeting-aiops
Webex Side Meeting 08/10/2026
Webex Recording (password: cGBPEfh5 )
Notes, Claude-Minutes from Webex Transcript
Webex Side Meeting 08/24/2026
https://notes.ietf.org/notes-ietf-sidemeeting-aiops-082426
By audience: WG Chairs · Draft Authors · BoF Organizers · Side Meeting Participants
I am posting this page to share my assessment of the AI-driven network operations space and to provide guidance to working group chairs, draft authors, and the broader community on how I am thinking about this work as the Management AD. The disposition of individual submissions remains a matter for community consensus; this guidance reflects my view on what the IETF is well-positioned to produce and what I will be looking for when evaluating proposals for new work. The focus throughout is network management — how AI agents are configured, governed, and monitored — not AI applied to networking more broadly.
AI and ML techniques are increasingly being applied to network operations: anomaly detection, closed-loop remediation, intent translation, and autonomous device management. The IETF community has responded with a growing number of individual drafts, but these efforts remain disconnected. There is no working group with adopted work items in this space, no agreed set of deliverables, and no clear standards-track path for the work. Without coordination, the community risks producing overlapping informational documents rather than interoperable standards.
The autonomic networking architecture the IETF has already standardized provides directly relevant context. The Autonomic Service Agent (ASA) model, Autonomic Control Plane (ACP), BRSKI, and GRASP (RFC 8990) were designed for autonomous, policy-driven agents operating in network infrastructure. LLM-based AI agents represent a more capable instantiation of that model, not a departure from it. Work in this space should build on this foundation rather than treat AI agents as an entirely new category of management entity.
This page identifies what the IETF is well-positioned to standardize, describes categories of work appropriate for IETF standardization, and flags where community consensus is still forming.
Adoption and disposition of individual submissions are decisions for WG chairs and the working group's rough consensus, not the AD. Where this page describes a decision I will make, it is specifically whether a working group is formed — a decision made in concert with the relevant WG chairs, not unilaterally by the AD. Throughout this page, work items in this space are chartered into the Proposed New WG: OPSAWG's and NMOP's current charters do not cover AI agent management for network operations as their own scope, and expanding either to absorb this work is not the proposed path. Coordination with OPSAWG, NMOP, and NETCONF WG remains important wherever their existing YANG models or protocol mechanics are directly reused. This does not preclude NMOP from running complementary, scoped experiments in this space — in the spirit of its NETCONF/YANG-Push-with-Kafka work — for example on closed-loop automation, anomaly detection, or YANG topology/digital-map issues; that is a parallel, coordinated track alongside the Proposed New WG's standards-track deliverables, not an alternative home for them.
The following efforts are currently active in the IETF and IRTF in this space:
draft-smith-opsawg-ai-network-governance — proposes a governance framework of thirteen principles for AI-mediated autonomous network device management, covering human authority, safety, auditability, reversibility, and bounded autonomy.draft-zhao-nmop-network-management-agent — defines a Network Management Agent (NMA) concept using an Intent-Awareness-Analysis-Decision-Execution (IAADE) control loop, with Agent-to-User (A2U), Agent-to-Controller (A2C), and Agent-to-Network (A2N) interfaces. The A2C interface is deferred to future work.draft-king-rokui-ainetops-usecases — documents use cases including reactive troubleshooting, proactive assurance, closed-loop optimization, misconfiguration detection, and virtual operator assistance.draft-irtf-nmrg-ai-challenges — identifies IRTF research challenges for coupling AI with network management, including distribution of AI tasks and privacy concerns.draft-zeng-opsawg-applicability-mcp-a2a — argues that NETCONF has five architectural gaps for AI-driven operations and proposes MCP and A2A as complementary layers, not replacements for NETCONF.draft-zeng-opsawg-llm-netconf-gap — gap analysis of NETCONF/RESTCONF for LLM-driven intent-based networking, identifying the absence of a YANG-to-JSON-Schema automation pipeline as a blocking gap.draft-zw-opsawg-mcp-network-mgmt — specifies concrete MCP extensions mapping directly onto YANG datastore operations (get, edit-config, commit, rollback) with YANG-module capability advertisement.draft-irtf-nmrg-llm-nm — proposes a framework for LLM-assisted network management with a mandatory human-in-the-loop audit step before any AI-generated configuration is deployed.draft-carpenter-anima-grasp-rendezvous — defines two GRASP-based procedures for agent rendezvous: a simple procedure using GRASP M_DISCOVER/M_RESPONSE, and a negotiated procedure using brief GRASP dialogue. The mechanism operates without dependency on DNS or mDNS, making it applicable in network instability scenarios where other discovery mechanisms may fail. Builds on RFC 8990 (GRASP) and the autonomic networking architecture; a prototype implementation exists. Authentication and authorization between rendezvous participants are explicitly deferred to the post-rendezvous protocol.draft-zhao-nmop-nma-a2u-yang — YANG model for the Agent-to-User (A2U) interface, covering NMA capability discovery, unified intent submission, task lifecycle management, execution plan exposure, human-in-the-loop confirmation, and consistent error reporting. Developed by the same authors as draft-zhao-nmop-network-management-agent; fills the "intent submission" YANG model slot identified in this guidance.draft-feng-netmod-naim-00 — proposes NAIM (Natural AI Interface Modeling), a canonical semantic representation format for network models designed to bridge the gap between YANG's machine-readable structures and the semantic framing LLMs need for effective reasoning. Positioned as a layer between YANG and MCP, not a replacement for either.draft-fu-nmop-agent-communication-framework — defines a centralized agent registry system for network AIOps, covering dynamic discovery of deployed AI agents, capability descriptors, and an Agent Name Service component. Based on deployment experience at China Telecom; addresses the agent discovery lifecycle gap.draft-fu-nmop-tokenops-probelem-statement — problem statement for model grounding: how an AI agent is populated with accurate, real-time network context (topology, performance state, policy) before it begins operating. Based on operational deployment experience at China Telecom.The AINETOPS non-WG mailing list (ainetops@ietf.org) was established to discuss integration of AI and ML in network operations using IETF technologies.
Two BoFs approved for IETF 126 are directly relevant to work identified on this page:
Additional individual drafts are being positioned for IETF 126 and were not yet available for inclusion in this landscape summary. These will be assessed against the same categories and criteria during or after the IETF 126 meeting, alongside the drafts listed above.
The IETF's established strengths lie in defining data models, protocol behavior, and operational guidelines. Applied to AI-driven network operations, this means:
The IETF is not well-positioned to specify AI algorithms, model architectures, or training methodologies.
The following subsections describe categories of work that are well-suited to IETF standardization. Whether any given submission should be adopted, where it should be placed, and on what track it should be published are matters for the WG and community consensus.
A use cases and requirements document is a valuable early work item that scopes and prioritizes normative deliverables. It should not be a standalone endpoint — its value is in grounding subsequent data model and protocol work. draft-king-rokui-ainetops-usecases is an example of current community work in this category.
YANG data models represent a primary category of work appropriate for IETF standardization. The problem space and required data structures are sufficiently well understood to support standards-track YANG work in the following areas:
draft-smith-opsawg-ai-network-governance specifies what an audit trail must contain: action timestamps, triggering anomaly, AI prompts and responses, pre- and post-action state snapshots, outcome, and human approval status. Standardizing this as a YANG model would ensure interoperability across vendors and compatibility with existing operational tooling. The model would also capture the human-in-the-loop workflow: whether a proposed action required human approval, the approver identity, and the approval/rejection timestamp. Audit log retention periods are a local policy decision and are not appropriate for inclusion in the model.draft-smith-opsawg-ai-network-governance — Action Registry, Allow/Block Lists, rate limits, protected resource targets, and degradation level thresholds — are all operator-configured state. Standardizing these as a YANG schema gives operators a vendor-neutral basis for AI agent governance. The question of which management interface carries that schema (*CONF, MCP, or other) is separate and should not be prejudged by the data model work itself.draft-zhao-nmop-network-management-agent, the active intent being processed, and per-phase inputs, outputs, and exceptions.Protocol extensions anchored in existing IETF management protocols are in principle well within IETF scope. However, several proposed extensions in this category are contested, and chairs should be aware of the open questions before adopting work here.
Open question. Some submissions propose a dedicated metadata attribute on
<edit-config>and RESTCONF PATCH to identify AI-initiated changes. A counterargument is that AI agents, like any other operator, already have unique management-plane identities, and existing *CONF audit mechanisms are sufficient to trace what they did. Adding an AI-specific tag may also create a false sense of security. This is an open question for the community.
Open question. Some submissions propose a new lightweight context identifier for NETCONF sessions to isolate concurrent agent tasks. Private candidates in NETCONF already provide a form of session isolation; whether a new mechanism is warranted, or whether existing facilities are sufficient, is an open question.
The Model Context Protocol (MCP) is an AI-facing capability-discovery and invocation interface through which tools, resources, and prompts can be exposed to LLM-based agents. An MCP server may abstract or broker operations implemented using NETCONF, RESTCONF, or other backends — this is an implementation relationship, not a protocol-layer relationship. The network-management semantics come from the underlying YANG models, information models, and tool contracts; MCP exposes those capabilities but does not itself carry the semantics. Three current submissions — draft-zeng-opsawg-applicability-mcp-a2a, draft-zeng-opsawg-llm-netconf-gap, draft-zw-opsawg-mcp-network-mgmt — explore this interface and its relationship to NETCONF and YANG.
Open question — see DAWN BoF. Some submissions propose a new YANG module for MCP capability advertisement. A counterargument is that *CONF already has capability discovery mechanisms today — for example, MCP can expose a tool or resource that fetches
ietf-yang-librarydirectly. Whether additional standardization is needed here, or whether existing mechanisms are sufficient, is an open question being discussed in the DAWN BoF. Chairs should not treat this as settled work.
draft-ietf-nmop-yang-message-broker-integration provides guidance for message broker deployments. This is broader than the security BCP and should be considered as a separate deliverable, or as an expanded BCP scope.
Open question — YANG semantic gap. Whether existing YANG models provide sufficient semantic framing for LLMs to reason effectively over network state is actively debated. Community discussion and early deployment experience suggest that raw YANG data may lack the contextual and relational semantics an AI agent needs.
draft-feng-netmod-naim-00(NAIM — Natural AI Interface Modeling) proposes a canonical semantic representation layer between YANG and AI agents; a counterargument is that the Message Broker with YANG schema registry already serves this function for streaming data, preserving schema and semantics without an additional layer. Whether IETF should standardize a semantic enrichment layer — and if so, in what form and venue — is an open question.
draft-zhao-nmop-network-management-agent identifies two interfaces that require standardization: the Agent-to-Controller (A2C) interface between the NMA and an existing SDN controller, and peer Agent-to-Agent (A2A) interfaces for multi-agent coordination across heterogeneous deployments.
Interface definitions of this type are appropriate IETF work when expressed using existing IETF management protocols and YANG data models, avoiding the introduction of a new protocol. For the A2A case, such work would typically include: a YANG module for agent capability advertisement once a management session is already established (distinct from the pre-session discovery/rendezvous problem covered by DAWN and by the draft below), a mechanism for task delegation and status reporting, and the trust and authorization model governing agent-to-agent interactions.
draft-carpenter-anima-grasp-rendezvous provides a concrete example of protocol-anchored A2A work in this space: two GRASP-based rendezvous procedures built directly on RFC 8990, with a working prototype. It addresses discovery/bootstrapping, not capability advertisement within an established session — see the cross-reference under Agent Discovery for how this relates to DAWN. The draft explicitly scopes out authentication and authorization between rendezvous participants — a gap that is significant for AI agent deployments, where the authorization model governing what one agent can ask another to do carries governance implications beyond those of traditional autonomous agents. Work building on this draft should address that gap, either in scope or by identifying a companion work item.
Open question — see AGENTPROTO BoF. The AGENTPROTO BoF (approved IETF 126) proposes A2A communication protocols built on MoQ (Media over QUIC) rather than NETCONF/RESTCONF. If AGENTPROTO forms a working group, it may define the A2A protocol standard that OPS area management work would reference rather than define independently. Whether network management A2A interfaces require separate treatment in OPSAWG, NMOP, or the Proposed New WG — or whether they are a use case AGENTPROTO would cover — is an open question the side meeting should address.
The security considerations specific to AI-mediated network management are qualitatively different from traditional management plane access. A BCP document addressing the following concerns is well within IETF scope:
Governance principle documents represent a distinct category appropriate for IETF publication. When a submission defines a well-structured, broadly applicable set of principles for AI-mediated network management — covering human authority, safety, auditability, reversibility, and bounded autonomy — it can provide a stable reference foundation for the normative work in the other categories. Such submissions are strong candidates for Informational publication if the community reaches consensus on their content.
The normative content that implements governance principles — specific configurations, data models, and protocol behaviors — is better expressed in YANG data models than in the principles document itself. draft-smith-opsawg-ai-network-governance is an example of current community work in this category.
The community has identified a set of AI agent lifecycle topics not yet well-addressed by current submissions and representing a gap in the existing work:
draft-carpenter-anima-grasp-rendezvous is itself a discovery mechanism — a GRASP-based alternative to DNS/mDNS for the network-instability case — and should be coordinated with DAWN rather than progressed as a separate, uncoordinated discovery track.draft-fu-nmop-tokenops-probelem-statement (China Telecom) addresses this as a problem statement, based on operational deployment experience.AI network architecture documents
High-level architecture descriptions of how AI fits into network management are better suited to IRTF or IAB documents. IETF work should start from a defined architecture and produce data models and protocol extensions for it, not define the architecture itself. Note: the boundary between an architecture document and legitimate protocol or model work is a matter of community judgment. draft-zhao-nmop-network-management-agent has been raised as a case that may straddle this boundary; apply the evaluation criteria when assessing it.
AI and ML algorithm specification
Specifying which algorithms to use for anomaly detection, classification, or remediation recommendation is outside IETF scope. YANG data models and protocol extensions in this space are intentionally AI-service-agnostic.
Standalone gap analyses
Gap analyses directly coupled to a committed standards-track or BCP work item in the same body of work are in scope. Gap analyses that stand alone — without an associated data model or protocol document — are not strong candidates for adoption as work items.
External framework alignment guidelines
Guidelines for aligning IETF YANG data models with TMF, 3GPP, or other external frameworks are outside IETF scope and should be addressed through liaison statements rather than adopted as WG work items.
Whether any specific submission falls within a given category, and what should happen to it, are matters for community evaluation.
| Category | Track | Key Evaluation Criterion |
|---|---|---|
| Use cases and requirements | Community decision | Scopes normative work; should not stand alone as a work item endpoint |
| YANG data models (intent, audit, governance, operational state) | Standards Track | Vendor-neutral schema for AI agent management; management interface (*CONF, MCP, or other) is a separate design question |
| NETCONF/RESTCONF intent-based RPCs | Standards Track | Accepts high-level operational goals as inputs; qualitatively different from existing NETCONF RPCs |
| NETCONF attribution metadata / session isolation | Contested | Open questions: agents already have unique *CONF identities; private candidates may already provide session isolation |
| MCP-to-YANG operation mapping | Standards Track | Maps YANG datastore operations to MCP tool schemas with consistent parameter names and error codes |
| MCP capability discovery | Contested — see DAWN | Open question: *CONF already has ietf-yang-library; whether additional standardization is needed is under discussion |
| Agent-to-Controller and Agent-to-Agent interfaces | Standards Track | AGENTPROTO BoF may define A2A transport on MoQ rather than *CONF; coordinate before assuming *CONF substrate |
| Operational security BCP | BCP | Normative baseline for operators; not vendor- or algorithm-specific |
| Governance principles | Informational | Broad community consensus on principles; normative specifics expressed in YANG models |
| AI agent lifecycle — discovery | See DAWN BoF | DAWN BoF (IETF 126) is the primary venue; twelve drafts in progress |
| AI agent lifecycle — benchmarking | Gap | Coordinate with BMWG |
| AI agent lifecycle — grounding | Problem statement exists | See draft-fu-nmop-tokenops-probelem-statement (China Telecom); normative work not yet started |
| AI agent lifecycle — upgrade and lifecycle management | Partial — see RFC 9222 §7 | RFC 9222 §7 covers autonomous agent upgrade and lifecycle; residual gap: LLM-specific scenarios (model version rollback, model change impact assessment) |
| Standalone gap analyses | Scoped only | Must be coupled to an associated standards-track or BCP work item in the same body of work |
Adoption of individual submissions as work items is a decision for chairs and the working group, not the AD. When evaluating whether to adopt a submission as part of a proposal for the Proposed New WG, I encourage chairs to apply the following criteria — the same criteria I will use when assessing whether the overall WG-formation proposal is ready to bring to IESG:
These criteria complement the standard threshold questions from RFC 5434:
Several areas in this space remain actively contested (see the open question callouts in Categories of Work). When a submission touches a contested area, chairs should:
Use the summary table to identify which category your work falls in, then target the appropriate venue:
If your work touches any of the following contested areas, come prepared with a clear problem statement that addresses the counterarguments:
ietf-yang-library, accessible via an MCP tool or resource, is not sufficient. Note this is also within scope of the DAWN BoF discussion.If you are considering proposing a BoF in this space, the RFC 5434 questions are the primary lens I will apply when evaluating the proposal. In addition, I will want clear answers to the following before recommending a BoF to IESG:
The open questions on the AI agent lifecycle and the contested items in Categories of Work are the areas most likely to benefit from BoF-level discussion if there is sufficient community interest and critical mass. If you are considering a BoF proposal, I encourage you to reach out to me on the OPSAWG, NMOP, or AINETOPS mailing list before the deadline.
A BoF is not a required step for WG formation. Together with the chair candidates the meeting identifies, I am prepared to take a proposal for the Proposed New WG directly to IESG — without a BoF — if the IETF 126 side meeting produces clear answers to the questions in Part B below. For that to work, the side meeting must address not just the open technical questions in Part A, but the WG formation questions that a BoF would normally resolve. If those questions are not answered to a level I can bring to IESG, I will state what remains unresolved at the close of the meeting.
These questions need resolution before the scope of any new WG can be meaningfully defined. Brief review of what is settled (YANG data models for intent, audit, and governance; MCP-to-YANG operation mapping; A2C/A2A interfaces; BCP) should take no more than ten minutes. The remaining time in Part A focuses on contested areas:
ietf-yang-library accessible via an MCP tool or resource sufficient, or is a new YANG module warranted? How does this relate to the DAWN BoF?If the side meeting is the trigger for WG formation rather than a precursor to a BoF, the following questions must be addressed to a level that the Management AD can take to IESG. These are the same questions a BoF would answer; bypassing the BoF does not bypass the questions.
Participants should review the BoF Readiness section of this page, since Part B of the side meeting covers the same ground.
Success looks different depending on outcome:
This page reflects the current understanding of the AI/ML network operations space and will be updated as community consensus develops. Feedback and questions on specific submissions or proposals are welcome on the mailing lists below.
OPSAWG mailing list: opsawg@ietf.org — archive
NMOP mailing list: nmop@ietf.org — archive
AINETOPS mailing list: ainetops@ietf.org — archive