RFC 9968

Report from the IAB Workshop on the Next Era of Network Management Operations (NEMOPS)

📅 published May 2026, from ietf

Report from the IAB Workshop on the Next Era of Network Management Operations (NEMOPS) 🎀

Okay bestie, this is RFC 9968 💖 It's an Informational report from the Internet Architecture Board (IAB), written by W. Hardaker and D. Dhody, and it's dated May 2026. It's published under ISSN 2070-1721 ✨ The title block doesn't list anything it obsoletes or updates, so it stands on its own, even though it's the follow-up to RFC 3535 🦋

Abstract 🌸

So the "Next Era of Network Management Operations (NEMOPS)" workshop was run by the IAB from December 3-5, 2024. It was a three-day online meeting, and it was basically a sequel to a 2002 workshop, whose results are written up in RFC 3535. That earlier workshop identified 14 operator requirements for future network management protocol design and related data models, plus some recommendations for the IETF 💅 The internet has changed a LOT since then, so NEMOPS looked back at those outcomes and asked what operational barriers stopped these technologies from being widely implemented 👀

The industry, network operators, and protocol engineers worked on it together, and they came out with a suggested plan of action and network management recommendations for the IETF and IRTF 🔥 This document is the report on that follow-up IAB workshop.

One important note: this is a report on what happened at the workshop. The views and positions in it belong to the workshop participants, and they don't necessarily reflect the IAB's views and positions 🫶

Status of This Memo 📜

This document is not an Internet Standards Track specification. It's published for informational purposes 🧚

It's a product of the Internet Architecture Board (IAB), and it holds information the IAB thought was valuable enough to keep on the permanent record. It represents the consensus of the IAB. Documents the IAB approves for publication are not candidates for any level of Internet Standard, so see Section 2 of RFC 7841 if you want the details 💀

For the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9968.

Copyright Notice ⭐

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please read those carefully, because they describe your rights and restrictions for this document 📖

Table of Contents 🍓

1.  Introduction
  1.1.  About the Content of This Workshop Report
2.  Outreach and Survey
3.  Workshop Scope and Discussion
  3.1.  Session I: Past - Lookback and Analysis
    3.1.1.  Reflections
    3.1.2.  Lessons to be Learned
    3.1.3.  Discussion
  3.2.  Session II: Present - Identified Problems and Requirements
    3.2.1.  Operator Feedback
    3.2.2.  Survey
    3.2.3.  Discussion
  3.3.  Session III: Future - Possible Solutions, Recommendations,
        and Next Steps
    3.3.1.  Suggestions on Future Directions
    3.3.2.  Discussion
  3.4.  Key Takeaways
    3.4.1.  Ecosystem Conclusions
    3.4.2.  Protocol Conclusions
    3.4.3.  Modeling Conclusions
    3.4.4.  Standardization Conclusions
    3.4.5.  Conclusions That Did Not Reach Consensus During the
            Takeaways Discussion
4.  Not Covered in the Workshop
5.  Security Considerations
6.  IANA Considerations
7.  Informative References
Appendix A.  Operator Feedback
  A.1.  General
  A.2.  Data Models
Appendix B.  Key Recommendations from Operator Feedback
Appendix C.  Position Papers
Appendix D.  Workshop Participants
Appendix E.  Workshop Program Committee
IAB Members at the Time of Approval
Acknowledgments
Authors' Addresses

1. Introduction ✨

The IAB runs occasional workshops to think about long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture 🌈 This long-term planning is a complement to the day-to-day engineering the IETF working groups do.

The IAB held a workshop in 2002 to get a real conversation going between network operators and protocol developers, and to steer the IETF's work on network management protocols. Its results are in "Overview of the 2002 IAB Network Management Workshop" [RFC3535], which identified 14 operator requirements and 11 recommendations for future network management protocol design and related data models within the IETF 🧠

Those requirements helped shape a lot of stuff, like the Network Configuration Protocol (NETCONF) from the NETCONF Working Group [RFC6241], the YANG data modeling language from the NETMOD Working Group [RFC7950], RESTCONF [RFC8040], and most recently the CoAP Management Interface (CORECONF) [CORECONF] 🔥

The recent NEMOPS IAB workshop focused on these key tasks:

Review the outcomes and results of the 2002 workshop (current deployments and state of the art), and identify any operational barriers that prevent these technologies from being widely implemented (limitations and hurdles).
Sketch new requirements for future network management operations, working collaboratively with the industry, network operators, and protocol engineers.
Develop a plan of action and recommendations for the IETF.

This document builds on RFC 3535 with new information from the second IAB workshop on the future of network management. The goal of the second workshop wasn't to invalidate or replace the first one. It was to extend the discussion with the lessons learned since then 🦋 Together, the two documents capture a snapshot of how the needs of network management have evolved over time 💜

1.1. About the Content of This Workshop Report 📝

This document is a report on the proceedings of the workshop. The views and positions in it were expressed during the workshop by participants, and they don't necessarily reflect the IAB's views and positions 🫶

Also, the content of the report comes from the presentations participants gave and from notes taken during the discussions, with no interpretation or validation. So the report follows the flow and dialogue of the workshop, but it doesn't necessarily try to capture a consensus, unless it says so 🙈

2. Outreach and Survey 📣

The workshop's Program Committee (PC) planned outreach to get people talking and gather interest. They engaged operators at a bunch of operational venues: Réseaux IP Européens (RIPE), North American Network Operators Group (NANOG), Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT), Latin American and Caribbean Internet Addresses Registry (LACNIC), AutoConn, and more 🌍 They ran information- and requirement-gathering sessions there. Participants were encouraged to submit "position papers" or "expressions of interest" to join the workshop. On top of that, a [SURVEY] was conducted to collect useful insights for the workshop 📊

After the workshop, some PC members kept talking with network operators at operational venues. That helped with sharing information and collecting feedback on the workshop, which in turn helped shape the next steps and outcomes 💅

3. Workshop Scope and Discussion 🎀

The workshop ran across three days, and every participant contributed to one discussion per day. It was organized around three topic areas: "Session I: Past - Lookback and Analysis" (Section 3.1), "Session II: Present - Identified Problems and Requirements" (Section 3.2), and "Session III: Future - Possible Solutions, Recommendations, and Next Steps" (Section 3.3). The PC arranged the paper submissions to fit these three themes, so each slot had something to drive the discussion 🧚 During each discussion, the papers were presented one after another, and an open discussion followed. On the last day, there was an extra discussion on the key takeaways and possible next steps (Section 3.4) 🔥

The agenda for each day can be found at "Past (Session 1)" <https://datatracker.ietf.org/doc/agenda-interim-2024-nemopsws-01-sessa/>, "Present (Session II)" <https://datatracker.ietf.org/doc/agenda-interim-2024-nemopsws-02-sessa/>, and "Future (Session III)" <https://datatracker.ietf.org/doc/agenda-interim-2024-nemopsws-03-sessa/>. All the workshop papers and slides are under "materials" <https://datatracker.ietf.org/group/nemopsws/materials/> 🌸

3.1. Session I: Past - Lookback and Analysis ⏪

The first day was all about reflecting on the past. Participants reviewed how network management has evolved since the 2002 workshop, and they looked at the wins and the struggles along the way 😭 The presentations covered a range of topics, including reflections on the history of network management, lessons learned from widely used tools, practices in constrained networks, and the need to rethink how network management models and protocols get standardized within the IETF. Honestly this session is iconic for setting the scene 👑

3.1.1. Reflections 🪞✨

okay so the workshop kicked off with a little looking-back moment 🥹 The IAB reflected on its role in moving network management away from Command-Line Interface (CLI), SNMP, and MIB tech. They covered the context and key outcomes of the previous workshop, took a real look at where network management stands right now, and owned up to some regrets from the last two decades, like picking XML as the data representation format 💀 [SCHONWALDER] pushed for shifting focus from device-level configuration to network and service-level configuration, and the vibe was very much "think bigger, bestie" 🦋 The key properties for good network and service configurations were Composable (assembled out of modular configurations) 🧩, Declarative (you define the state and the systems figure out how to get there) 🎯, Reproducible (reliably and consistently recreated) 🔁, and Verifiable (you can assert that the right changes were actually applied) ✅

An operator's perspective came in next 💅 [RFC3535] led to YANG and NETCONF, and those recommendations have worked out really well for device configuration in many environments (though not all of them, so lowkey not a perfect record). In some areas, the semantics and protocols for streaming telemetry have even gone beyond the original scope of [RFC3535] 📈 [FARRER] warned everyone to be careful about making changes that could shake up the ecosystem, which, fair 😅 The talk stressed prioritizing service modeling in the IETF and dealt with the challenges of mapping to the Business Support Systems (BSS) domain. It also pointed out that operational state needs to be part of service models so closed-loop automation can work for end-to-end (E2E) services 🔄 People suggested revisiting [RFC8309], which says that the operational state of a service is not part of a customer service model but can be handled through extensions. Another big one: the lack of open-source Network Management System (NMS) implementations, tools, and device model implementations was called out as a major barrier to standardization efforts 🚧 The IETF could play a key role in fostering and enabling collaborations to tackle this. The IETF doesn't build tools itself, but it was suggested that a translation tool running outside the network device, mapping IETF device models to vendor-specific ones, would be super helpful 🛠️

3.1.2. Lessons to be Learned 📚

[HARDAKER] shared that the success of Net-SNMP [NET-SNMP] came from empowering users through simplicity 🙌 The focus should stay on ease of use and adaptability of the protocols. There were two distinct audiences for standardized network management protocols, toolkit vendors and system operators, and their requirements for protocol simplicity are different. Addressing the needs of both is essential for success 💖 [BORMANN] gave an overview of the CORECONF architecture, showing how model-driven network management techniques can be applied to manage Internet of Things (IoT) devices. That's a different scenario from other network management, and the talk focused on the unique characteristics of constrained nodes 🧚 Some participants noted that the binary encoding of Concise Binary Object Representation (CBOR) has applications beyond IoT networks, which is a very "wait, it's bigger than we thought" moment 😭

Drawing from the experience of OpenConfig [OPENCONFIG], [SHAKIR] emphasized that protocol definition and data models can't be done in isolation 🙅‍♀️ They have to integrate lessons learned from implementation and large-scale deployment. So the takeaways were: enable quick iterations, ship rapidly, embrace open source, make tools readily available, adopt systems thinking driven by business outcomes, and reuse existing technologies instead of building solutions only for operator network management 🔥 A call went out for the IETF to rethink how it standardizes data models and the associated network management protocols along these lines 🌈

3.1.3. Discussion 🗣️

The open discussion for Session I highlighted the gap between vendor implementations of YANG models and what is actually accessible through the models, especially compared to CLI 👀 People asked how to bring fast iteration and rapid changes into the established IETF process and culture, particularly in contrast to the approach OpenConfig takes 🏃‍♀️ Common challenges included a lack of tooling, performance issues at scale, the steep learning curve for network management protocols, models, and tools, initial difficulty moving away from CLI, and backward compatibility of models (versioning) 😩 Some participants suggested the IETF should focus on system-level APIs that address specific problems 🎯 The lack of simple tools for smaller networks operating under tight timelines and budgets was also emphasized 💸

A key question was whether the proliferation of protocols and languages makes adoption harder, and whether converging on a single approach would improve adoption 🤔 It's an established reality that there are multiple schemas and protocols beyond NETCONF, such as the BGP Monitoring Protocol (BMP) and IP Flow Information Export (IPFIX), addressing network management challenges beyond configuration 🍓 One conclusion was that a mechanism is needed to interconnect and harmonize these schemas, so you get a cohesive and comprehensive understanding of the data 🫶

3.2. Session II: Present - Identified Problems and Requirements 🔍

Day two was all about the challenges and emerging requirements for future network management operations 🚀 The presentations stressed how important validation, observability, and automation are, plus the need for agile, incremental development of both network models and management protocols 💜 A compilation of new requirements from operators was presented, and they're being maintained in [OP-REQ-NM] 📋 The final talk of the day summarized the survey results and operator feedback gathered from outreach events 🌸

3.2.1. Operator Feedback 💬

[KELLER] shared Deutsche Telekom's perspective: YANG models perform well for provisioning, but they currently fall short when it comes to the operational stability needed for validation 😬 In their experience, IETF service models (where available) were considered stable and in good condition, while the OpenConfig device models were noted as lacking feature richness and stability. Vendor YANG models, on the other hand, are often more flexible and show up in a more timely manner ⏰ Getting to fully closed-loop, automated, and autonomous networking will need a bigger focus on observability, especially through advancements in streaming telemetry with the "on-change" feature [RFC9196] ✨

[JIMENEZ] dug into the challenges of the Software Defined Networking (SDN) Transport Automation Platform 🛰️ That includes observability and analytics requirements, issues with data streaming, scalability, diverse models in heterogeneous multi-vendor environments, and mechanisms to secure network management protocols 🔐 The talk also pointed out that advances in AI and machine learning, along with possibly adapting protocols designed for constrained environments, could drive the next evolution of network management 🤖

Using YANG-Push as an example, [GRAF] highlighted how standards development often fails to line up with what network operators need, the constraints of network vendors, and integration requirements 😭 The biggest problem is that it lacks an agile, incremental development process. The presentation pushed for an iterative approach to standards development, focused on delivering minimal viable products as part of the process 🧁

[CONTRERAS] emphasized reassessing deployment assumptions and bringing in updated operator requirements 📝 The authors are working on these through [OP-REQ-NM], using feedback and discussions from the workshop. Here are the key requirements, suggestions, and observations highlighted at the workshop 👑

Network software implementations can only happen with a strong, committed standardization effort, plus active involvement in open-source projects that make code accessible 🫶
The device model space needs rationalizing, and redundant efforts should be avoided. Unlike service and network models, IETF-defined device models are not widely implemented 🙈
Define a reference approach or process for service exposure discovery (API discovery) 🔎
Outline a set of recommendations for core or key features, with appropriate justifications, to help foster more implementations that meet operators' needs 🌟
Reassess the value of some IETF proposals, including comparisons to competing or emerging solutions (for example, gRPC Network Management Interface (gNMI) vs. YANG-Push) ⚖️
A more agile process is needed for developing and maintaining YANG modules in the IETF. RFCs might not be suited for documenting YANG modules 🧩
Consider approaches that ease integration by design (for example, protocols and data models) 🔧
A reference specification is needed to translate YANG-based data into the knowledge graph (KG) 🕸️
Consider approaches to help YANG models scale 📏
Consider programmatic approaches to ensure lossless mappings between service, network, and device data models 🔄
Consider approaches that ensure reuse of, or consistent data structure across, various network management segments 🎀
Some networks have specific network management requirements, such as the need for asynchronous operations or constraints on data compactness 📦
Heterogeneity of data, configuration, and network management requirements has to be handled. Insights could be drawn from parallel technical fields such as knowledge engineering practices and Linked Data concepts from the Semantic Web, areas that commonly manage heterogeneity and data reconciliation across application domains 🧠
Consider having YANG as part of the protocol specification or change where possible, or have the YANG document progress in parallel 🤝
Ease the integration of low-level, network-oriented solutions with common "IT tooling" 🛠️
Ease exposure of libraries and host tools (for example, yangkit) to make integration easier 📚
Tooling is needed, especially on the client side 💻
Create an ecosystem where data and networking engineers can collaborate 👯‍♀️
Distinct approaches are followed in both the compute and the network environments to define suitable mechanisms for an efficient interplay, while highly automating the overall service delivery procedure ⚡
The target application or applicability of a network management approach should be documented 📌
Readily available API specifications could be generalized from YANG modules for fast development, prototyping, and validation 🦋

3.2.2. Survey ✨

okay so, like we talked about in Section 2, the workshop program committee went all in on outreach 📣 and ran a survey to get direct feedback from people. [SURVEY-INSIGHTS] gave us the tea on who the respondents were and which tools, protocols, and APIs people actually use for configuration, monitoring, and other network ops 💅 Ansible and CLI are the most popular configuration tools, NETCONF is the preferred configuration protocol 🔥, and Prometheus and SNMP are widely used for monitoring 📊. The survey also collected feedback on network automation and streaming telemetry 🦋. Issues people flagged for the future were scalability, performance, the need for easier mapping of various models, tooling, managing legacy devices, collaborating with open source, and vendor-specific issues 🙈. Plus, the valuable insights from direct operator feedback are in Appendix A 🫶

3.2.3. Discussion 💜

the Session II open discussion had implementers spilling the details 🗣️ it's really hard to move over to YANG and to map things onto vendor implementations, and when every vendor does things a little differently, it gets messy and people end up building workarounds 😭 implementations have to support standard models next to vendor-specific ones, which adds complexity and confuses people 💀 mapping standard models onto internal device models and legacy devices was a whole challenge, and in some cases mapping isn't possible at all, like with device-specific knobs 🙅‍♀️ the group also stressed how important it is to build open-source reference implementations, run compliance and interoperability testing for vendors using real data, and make vendor implementations and documentation way better 🌈 supporting multiple models (IETF, OpenConfig, and vendor-specific) is just an unavoidable reality in network management, no cap 🧚 and since operators offer wildly different services, getting agreement on a common service model within the IETF can be really tough 😩 someone also pointed out that the IETF should speed up publishing standards, and also think about gating them on multiple interoperable implementations ⭐

3.3. Session III: Future - Possible Solutions, Recommendations, and Next Steps 🚀

the final day of the workshop was all about dreaming up future solutions and pinning down the key takeaways, recommendations, and next steps 🌸 at the end of day three, the chairs wrapped things up by summarizing the key takeaways (see Section 3.4) that the participants agreed on 🎀

3.3.1. Suggestions on Future Directions 🔮

[CLAISE] called out how hard it is to integrate data models across different silos, protocols, and data structures, and stressed that we need a machine-readable way to expose semantics 🤓 the group also talked about the related tools being built and shown off in the IETF Hackathons, plus all the challenges of mapping across protocols and models 🛠️ one proposed solution was a knowledge graph built on the Semantic Web Stack, along with the idea of defining a basic ontology for the networking domain iteratively (outside of RFCs) 🧠

[WATSEN] recommended focusing on four areas, bestie 👑: (1) using RESTCONF+JSON (including YANG-Push Lite) as a single protocol beyond network management, (2) utilizing the Network Management Datastore Architecture (NMDA) model, (3) creating data model adapters (off-box so that common standard models can be developed in parallel to the required device vendor-specific models), and (4) defining device protocol adapters (with a RESTCONF-like Northbound Interface (NBI) for a common shared-by-all repository) 💖

[WILTON] recommended cutting unnecessary complexity, shipping timely solutions, fostering open collaboration between vendors and operators, prioritizing simplicity, and converging on a single model/protocol (even though this was discussed as hard to pull off 😭) some practical suggestions were focusing on YANG-Push Lite, introducing YANG 2.0 through incremental updates, developing NETCONFv2, and managing IETF YANG models as code or APIs rather than embedding them inside RFCs 🫶

3.3.2. Discussion 🗨️

the open discussion in Session III was all over the place in the best way 🌈 people brought up NMDA not being in OpenConfig and whether its complexity is actually justified 🤔 the historical context of gNMI's introduction in the IETF came up, along with whether RESTCONF has any advantages over it 👀 and the bigger struggle of building consensus, where participants noted that while the process takes time, it shouldn't be short-circuited ⏳ the group also talked about whether converging on a single protocol is practical, and concluded that such convergence is, in fact, feasible ✨

the discussion put a lot of emphasis on off-box adapters, which let vendors keep innovating and build vendor-specific models fast 🏃‍♀️ one suggestion that got tons of attention was developing a standard model that maps to vendor-specific models and lives in a common repository, so the community can check coverage and alignment 💜

the discussion also explored other ways to handle YANG models within the IETF but outside of RFCs, like using GitHub to speed things up (with its own set of challenges 🙃), living documents within the WG charter, and getting academia involved with open-source efforts like device adapters 🎓 people stressed the need for process experimentation, especially at the working group or area level, where the YANG/OPS community could agree on how to iterate in WGs without IETF-/RFC-wide changes, while making sure operators stay involved 🫶

there were also conversations around questions people asked, like "Is YANG applicable beyond network management?" and "Can applications adopt YANG as a modeling language to define their services?" 🤯

some key recommendations operators made during outreach (Section 2) are listed in Appendix B 📋

3.4. Key Takeaways 🏆

at the end of day three, the discussion moved to key takeaways that had high-level consensus 💅 these got edited live during the last discussion of the workshop, and anything that didn't reach wide consensus got moved into a "future considerations" list (Section 3.4.5) 📝

3.4.1. Ecosystem Conclusions 🌍

the following takeaways try to capture the general thinking of the participants about the entire network management ecosystem as it exists today 🦋

the current network management protocols, models, and tools still fail the 'ease of use' requirement 😩 participants noted that the tools almost matter more than the protocols 🛠️
the overall ecosystem is still fragmented for both protocols and data models 🧩 SNMP is still used extensively for monitoring, and the CLI is still heavily relied on for configuration in many networks 📟 popular protocols include SNMP, NETCONF, RESTCONF, and gNMI 💖
documentation about the architecture and usage of the network management ecosystem is lacking 📚 more work is needed to create general architecture documentation, deployment guides, tutorials, training material, and getting-started guides 🎀
transitioning between network management frameworks is challenging, just like transitioning between other protocols, like IPv4 to IPv6 🙈
model-driven network management is generally a success where it has been implemented and is possible to use 🎉
operators need more easily usable network management tools 🔧 the lack of open-source tools is seen as a barrier to adoption 🚧 tools need good use cases, example flows, and better analysis of when and how they work and have been successful 🌟

3.4.2. Protocol Conclusions 📡

the following conclusions were reached while discussing network management protocols, more specifically 🤓

NETCONF and YANG aren't used much for monitoring tasks 📉
NETCONF and YANG don't have full coverage on many devices 😬
polling-based solutions are still frequently deployed 🔁 push-based solutions are often desired but aren't yet widely available 🥺

3.4.3. Modeling Conclusions 🧩

the following conclusions were reached while discussing network management modeling, more specifically 💅

some YANG models can get complex because of the underlying features they represent, not because of the language itself 🤷‍♀️
multi-vendor compatibility support is required 🤝
even vendor-specific features, not just standardized protocol features, need to be exposed through network management models and protocols for a network management ecosystem to be viable 🌈
greater support for service-level modeling is needed 📈 device-level modeling can be a building block toward a sufficient service-level model, but it isn't a complete solution by itself 🧱
network configuration needs to be verifiable so that any potential changes can be accepted by devices ✅ model translation adapters (likely run on the management station, not the end device) may be the best path forward to achieve this and the goal of supporting one configuration set across a diversity of devices with different internal models at the same time 🦋

3.4.4. Standardization Conclusions 📜

the following conclusions were reached while discussing the best ways to standardize network management protocols and associated models 🎀

we need a methodology of rapid model development procedures so model deployment can keep pace with new feature deployment ⚡ we need a solution that significantly increases the speed and predictable timeline for developing and publishing models within the IETF 🏁 new approaches and methods to make models live outside of published RFCs should be explored 🌸 an experiment should be started to test a new rapid development approach 🧪
protocol and model complexity should be reduced so additions and changes stay within a minimal set of agreed-upon core features 🧹
more standardization focus is needed on the scalability of the different roles of network management: monitoring, configuration, and notifications 📊
enhancements to network management protocols and models need to be backed by real-world operator use cases and expected adoption by vendors 🫶 vendors and operators will need to work together to make sure these goals are appropriately met 🤝

3.4.5. Conclusions That Did Not Reach Consensus During the Takeaways Discussion 🥺

Okay bestie, these are the things the group realized needed a lot more attention before anyone could reach a conclusion. We were updating the key takeaways in real time, so these got flagged as "we need to keep talking about this" 💅

Some (but not all) people saw NETCONF for configuration as a win in some larger-scale deployments 👑. That's true in certain contexts, but many operators said they still have to rely on other ways of accessing their networks, like CLIs, Expect scripts, and other protocols 🙈.
Lots of people hope NETCONF, and RESTCONF specifically, will keep growing into the long-term configuration management solution 🌈. Still, some participants doubted that the protocol and its data models can ever be truly ubiquitous and keep up with how fast devices get deployed 💀.

Plenty of other items still need discussion, but this list is just the ones that actually came up during the live editing session at the workshop ✨

4. Not Covered in the Workshop 🧚

Some topics just didn't come up at the workshop. That includes tooling (what's currently missing) and strategies to support tool development, which is the "who pays, who develops, and who maintains" question 🫶. The discussion was mostly centered on YANG and NETCONF/RESTCONF, while several other network management protocols and techniques that people actually use got a lot less attention 😭. When it came to possible future directions, the group focused on improving existing solutions instead of introducing brand-new ones (like enabling intelligence in network management). Very practical of them, honestly 💜

5. Security Considerations 🔥

This document is a workshop report, and it does not impact the security of the Internet. Okay, deep breath, but this is the one spot where we keep it serious: nothing in this report changes how secure the Internet is 🛡️

6. IANA Considerations 🎀

This document has no IANA actions. Nothing to register, nothing to update, zero paperwork for IANA this time 💅

7. Informative References 📚

These are the sources the report points to. Every entry is listed in full, exactly as written:

[BLESS]    Bless, R., "An Invariant for Future Resilient Network
           Management Operations", November 2024,
           <https://www.ietf.org/slides/slides-nemopsws-paper-an-
           invariant-for-future-resilient-network-management-
           operations-00.pdf>.

[BORMANN]  Bormann, C., "CORECONF: Managing IoT Devices with YANG
           Models", November 2024, <https://www.ietf.org/slides/
           slides-nemopsws-paper-coreconf-managing-iot-devices-with-
           yang-models-00.pdf>.

[CLAISE]   Claise, B., Graf, T., Keller, H., Voyer, D., Lucente, P.,
           Lopez, D., Martinez-Casanueva, I. D., Peters, B., Fasano,
           P., Ran, P., Cheng, W., and M. Mackey, "Knowledge Graph
           Framework for Network Operations", November 2024,
           <https://www.ietf.org/slides/slides-nemopsws-paper-
           knowledge-graph-framework-for-network-operations-00.pdf>.

[CONTRERAS]
           Boucadair, M., Contreras, LM., Gonzalez de Dios, O., Graf,
           T., Rahman, R., and L. Tailhardat, "RFC 3535, 20 Years
           Later: An Update of Operators Requirements on Network
           Management Protocols and Modelling", October 2024,
           <https://www.ietf.org/slides/slides-nemopsws-paper-
           rfc3535-years-later-an-update-of-operators-requirements-
           on-network-management-protocols-and-modelling-00.pdf>.

[CORECONF] Veillette, M., Ed., Van der Stok, P., Ed., Pelov, A., Ed.,
           Bierman, A., and C. Bormann, Ed., "CoAP Management
           Interface (CORECONF)", Work in Progress, Internet-Draft,
           draft-ietf-core-comi-21, 2 March 2026,
           <https://datatracker.ietf.org/doc/html/draft-ietf-core-
           comi-21>.

[ECKERT]   Eckert, T. and M. Richardson, "Resilient Remote
           Manageability of Wide-Area Network Infrastructures",
           November 2024, <https://www.ietf.org/slides/slides-
           nemopsws-paper-resilient-remote-managability-of-wide-area-
           network-infrastructures-00.pdf>.

[FARRER]   Larsson, K., Lambrechts, K., and I. Farrer, "RFC3535, 20
           Years Later from an Operator's Perspective (Deutsche
           Telekom)", November 2024, <https://www.ietf.org/slides/
           slides-nemopsws-paper-rfc3535-years-later-from-an-
           operators-perspective-deutsche-telekom-00.pdf>.

[FOROUGHI] Foroughi, P. and L. Ciavaglia, "Projecting Data Mesh to
           Model-driven Telemetry: A Path to Data Ecosystem's
           Management Operations", November 2024,
           <https://www.ietf.org/slides/slides-nemopsws-paper-
           projecting-data-mesh-to-model-driven-telemetry-a-path-to-
           data-ecosystems-management-operations-00.pdf>.

[GIRALT]   Contreras, LM., Schott, R., Randriamasy, S., Yang, R., and
           J. Ros-Giralt, "Towards a Unified Compute and
           Communication Infrastructure for Application and Network
           Management", November 2024, <https://www.ietf.org/slides/
           slides-nemopsws-paper-towards-a-unified-compute-and-
           communication-infrastructure-for-application-and-network-
           management-00.pdf>.

[GRAF]     Graf, T., Keller, H., Voyer, D., Lucente, P., Claise, B.,
           Wilton, R., Huang-Feng, A., and P. Francois, "Agile
           Incremental Driven Development for Network Management",
           November 2024, <https://www.ietf.org/slides/slides-
           nemopsws-paper-agile-incremental-driven-development-for-
           network-management-01.pdf>.

[GUDI]     Gudi, M., Pelov, A., Toutain, L., and J. M. Bonnin,
           "Evolving Network Management Architecture: Integrating
           CORECONF with NETCONF for Efficient Telemetry and
           Management", November 2024, <https://www.ietf.org/slides/
           slides-nemopsws-paper-evolving-network-management-
           architecture-integrating-coreconf-with-netconf-for-
           efficient-telemetry-and-management-00.pdf>.

[HARDAKER] Hardaker, W., "Lessons Learned from 30 Years of Net-SNMP",
           November 2024, <https://www.ietf.org/slides/slides-
           nemopsws-paper-lessons-learned-from-30-years-of-net-snmp-
           00.pdf>.

[JIMENEZ]  Jiménez, J., Mansfield, S., Rodriguez A, R., Pesonen, M.,
           Torvinen, V., and J. Karvonen, "Evolving Challenges and
           Solutions in Network Management", November 2024,
           <https://www.ietf.org/slides/slides-nemopsws-paper-
           evolving-challenges-and-solutions-in-network-management-
           00.pdf>.

[JIMENEZ-2]
           Jiménez, J., "Managing IoT Devices with LwM2M", November
           2024, <https://www.ietf.org/slides/slides-nemopsws-paper-
           managing-iot-devices-with-lwmm-00.pdf>.

[KELLER]   Warnke, N., Geib, R., Horneffer, M., and H. Keller,
           "NEMOPS: RFC3535 and the forgotten word - Or Provisioning
           is only a subset of Network Management", November 2024,
           <https://www.ietf.org/slides/slides-nemopsws-nemops-
           rfc3535-and-the-forgotten-word-00.pdf>.

[MARTINEZ] Martinez-Casanueva, I. D., "IAB NEMOPS Position Paper -
           Telefonica", November 2024, <https://www.ietf.org/slides/
           slides-nemopsws-paper-iab-nemops-position-paper-
           telefonica-00.pdf>.

[NET-SNMP] "Net-SNMP", <http://www.net-snmp.org/>.

[OP-REQ-NM]
           Boucadair, M., Contreras, L. M., Gonzalez de Dios, O.,
           Graf, T., and R. Rahman, "An Update of Operators
           Requirements on Network Management Protocols and
           Modelling", Work in Progress, Internet-Draft, draft-ietf-
           nmop-rfc3535-20years-later-04, 6 May 2026,
           <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-
           rfc3535-20years-later-04>.

[OPENCONFIG]
           "OpenConfig", <https://www.openconfig.net/>.

[RFC3535]  Schoenwaelder, J., "Overview of the 2002 IAB Network
           Management Workshop", RFC 3535, DOI 10.17487/RFC3535, May
           2003, <https://www.rfc-editor.org/info/rfc3535>.

[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>.

[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>.

[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>.

[RFC8309]  Wu, Q., Liu, W., and A. Farrel, "Service Models
           Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
           <https://www.rfc-editor.org/info/rfc8309>.

[RFC9196]  Lengyel, B., Clemm, A., and B. Claise, "YANG Modules
           Describing Capabilities for Systems and Datastore Update
           Notifications", RFC 9196, DOI 10.17487/RFC9196, February
           2022, <https://www.rfc-editor.org/info/rfc9196>.

[SCHARF]   Scharf, M., "Network Management Challenges for IP-based
           Cyber-Physical Networks", November 2024,
           <https://www.ietf.org/slides/slides-nemopsws-paper-
           network-management-challenges-for-ip-based-cyber-physical-
           networks-00.pdf>.

[SCHONWALDER]
           Schönwälder, J., "Composable, Declarative, Reproducible,
           Verifiable Network and Service Configurations", November
           2024, <https://www.ietf.org/slides/slides-nemopsws-paper-
           composable-declarative-reproducible-verifiable-network-
           and-service-configurations-00.pdf>.

[SHAKIR]   Shakir, R., "Rethinking Standardisation of Network
           Management", September 2024, <https://www.ietf.org/slides/
           slides-nemopsws-paper-rethinking-standardisation-of-
           network-management-00.pdf>.

[SURVEY]   "Next Era of Network Management Operations (NEMOPS)
           workshop survey", October 2024,
           <https://ietf.iad1.qualtrics.com/jfe/form/
           SV_9vQxBRiZqDntarc>.

[SURVEY-INSIGHTS]
           "Insights from Operator Survey & Outreach", December 2024,
           <https://datatracker.ietf.org/meeting/interim-2024-
           nemopsws-02/materials/slides-interim-2024-nemopsws-02-
           sessa-6-insights-from-operator-outreach-survey-03.pdf>.

[WATSEN]   Watsen, K., "Four Thoughts for How to Improve Network
           Management for Operators", November 2024,
           <https://www.ietf.org/slides/slides-nemopsws-nemops-
           position-paper-kent-watsen-00.pdf>.

[WILTON]   Wilton, R. and N. Corran, "Device Network Management -
           Current Status, and Future Direction", November 2024,
           <https://datatracker.ietf.org/doc/slides-nemopsws-paper-
           device-network-management-current-status-and-future-
           direction/>.

Appendix A. Operator Feedback 🌸

This section gathers up the operator feedback collected through outreach and information gathering at various operational venues (RIPE, NANOG, APRICOT, LACNIC, AutoConn, etc.) 🦋 The PC pulled all of that input together and presented it during the workshop (see Section 3.2.2) ✨

A.1. General ✨

Okay so, in network deployments, operations are basically at the bottom of the ladder 🪜 It's the most squeezed for time and resources. Network engineers are not typically seasoned developers, and building the in-house tools they need often takes years. There is a need for tools that are easy to use and just work 💅
The vast majority of smaller operators use CLI and open source to manage their networks 💻🌸
There is debate fatigue 😭 The protocol/model debate is a recurring conversation, and the problem isn't going away.
It was suggested that other domains (e.g., Kubernetes (K8s) / automation) are years ahead of the current network engineering stack 🚀
Support for multiple friendly, stable, and feature-rich libraries for programming languages is needed 📚 Many DevOps routines use shell scripts, while others use a high-level programming language. Either way, on the client side, multiple programming languages are used.
Screen scraping is unfortunately necessary and painful 🙈 This most often happens when interacting with a device that only has a CLI.
It was noted that there could be an outreach to Academia to establish programs that teach lessons using modern management stacks 🎓 Then a new generation of engineers could help improve tooling and automation, with university (and/or IETF) hackathons 🧚

A.2. Data Models

In some network deployments, the focus is solely on service-level models, so device-level protocols and device-level models are unimportant 🦋 This assumes the existence of a device adaptation layer to transcode service-level models to device-level models and conform to the device-specific protocol.
There is a need for solutions to not hide vendor-specific parameters 👑 Right now, vendors compete by differentiating their offerings in unique ways, and the reason an operator may choose a particular vendor is because of its differentiating features. Whilst standard models enable conformance, they must not hide the vendor-specific parameters. YANG deviations are a partial solution to not hiding vendor knobs 🎀
It was emphasized that streaming telemetry requires picking a model and sticking with it. It is quite a commitment, and the current environment makes the decision harder 😩
It was noted that IETF's focus should be on defining abstract/service-level data models, since that is the only thing the community may ever agree on 💜
It was noted that navigating standard models can be difficult. A network engineer knows the vendor CLI commands but has trouble locating the corresponding leaves in the standard YANG models defined by Standards Development Organizations (SDOs) 🥲
There was a wish that the IETF and OpenConfig models would merge 🌈

Appendix B. Key Recommendations from Operator Feedback ✨

Various recommendations were made by the operators during the outreach events. The key ones presented during the workshop were (note that there were a lot more collected) 🍓

Everyone: Continue to focus on model-driven management as a means to achieve automation.
SDOs: Re-introduce "running code" as part of the specification verification process.
Operators: Be actively involved with the "running code" efforts.
IETF: Recommend a solution stack for common use cases.
Technology Ambassadors: Evangelize the recommended solution stack for common cases.
Vendors: Support the recommended approach to the solution stack for common cases.

Appendix C. Position Papers 📝

20 position papers were submitted to the workshop call for papers. All papers are available at <https://datatracker.ietf.org/group/nemopsws/materials/>.

This is the list of all papers 🦋

J. Schönwälder: Composable, Declarative, Reproducible, Verifiable Network and Service Configurations [SCHONWALDER]
K. Larsson, K. Lambrechts, and I. Farrer: RFC3535, 20 Years Later from an Operator's Perspective (Deutsche Telekom) [FARRER]
W. Hardaker: Lessons Learned from 30 Years of Net-SNMP [HARDAKER]
C. Bormann: CORECONF: Managing IoT Devices with YANG Models [BORMANN]
R. Shakir: Rethinking Standardisation of Network Management [SHAKIR]
N. Warnke, R. Geib, M. Horneffer, and H. Keller: NEMOPS: RFC3535 and the forgotten word - Or Provisioning is only a subset of Network Management [KELLER]
J. Jiménez, S. Mansfield, R. Rodriguez A., M. Pesonen, V. Torvinen, and J. Karvonen: Evolving Challenges and Solutions in Network Management [JIMENEZ]
M. Boucadair, LM. Contreras, O. Gonzalez de Dios, T. Graf, R. Rahman, and L. Tailhardat: RFC 3535, 20 Years Later: An Update of Operators Requirements on Network Management Protocols and Modelling [CONTRERAS]
T. Graf, H. Keller, D. Voyer, P. Lucente, B. Claise, R. Wilton, A. Huang-Feng, and P. Francois: Agile Incremental Driven Development for Network Management [GRAF]
B. Claise, T. Graf, H. Keller, D. Voyer, P. Lucente, D. Lopez, I. D. Martinez-Casanueva, B. Peters, P. Fasano, P. Ran, W. Cheng, and M. Mackey: Knowledge Graph Framework for Network Operations [CLAISE]
K. Watsen: Four Thoughts for How to Improve Network Management for Operators [WATSEN]
R. Wilton and N. Corran: Device Network Management: Current Status and Future Direction [WILTON]
M. Gudi, A. Pelov, L. Toutain, and J. M. Bonnin: Evolving Network Management Architecture: Integrating CORECONF with NETCONF for Efficient Telemetry and Management [GUDI]
P. Foroughi and L. Ciavaglia: Projecting Data Mesh to Model-driven Telemetry: A Path to Data Ecosystem's Management Operations [FOROUGHI]
I. D. Martinez-Casanueva: IAB NEMOPS Position Paper - Telefonica [MARTINEZ]
J. Jiménez: Managing IoT Devices with LwM2M [JIMENEZ-2]
LM. Contreras, R. Schott, S. Randriamasy, R. Yang, and J. Ros-Giralt: Towards a Unified Compute and Communication Infrastructure for Application and Network Management [GIRALT]
T. Eckert and M. Richardson: Resilient Remote Manageability of Wide-Area Network Infrastructures [ECKERT]
R. Bless: An Invariant for Future Resilient Network Management Operations [BLESS]
M. Scharf: Network Management Challenges for IP-based Cyber-Physical Networks [SCHARF]

Appendix D. Workshop Participants 🌸

The workshop participants were Alex Huang, Alexander Clemm, Alexander Pelov, Benoît Claise, Boris Khasanov, Brad Peters, Carsten Bormann, Chongfeng Xie, Cindy Morgan, Dan Voyer, Darren Loher, Dean Bogdanovic, Dean Bogdanović, Dhruv Dhody, Diego Lopez, Ebben Aries, Frank (Chong Feng), Holger Keller, Ian Farrer, Jaime Jimenez, James Cumming, Janne Karvonen, Jason Sterne, Jiaming Ye, Jinming Li, John Carson, Julien Maisonneuve, Jürgen Schönwälder, Kent Watsen, Kris Lambrechts, Kristian Larsson, Laurent Ciavaglia, Laurent Toutain, Liz Flynn, Luis M. Contreras, Mahesh Jethanandani, Manoj Gudi, Martin Horneffer, Matthew Bocci, Med Boucadair, Michael Mackey, Michael Richardson, Michael Scharf, Mikko Pesonen, Nacho Dominguez, Naveen Achyuta, Nick Corran, Nils Warnke, Oscar Gonzalez de Dios, Paolo Lucente, Parisa Foroughi, Per Andersson, Phil Shafer, Qin Wu, Qiufang Ma, Raquel Rodriguez, Reshad Rahman, Rob Shakir, Rob Wilton, Roland Bless, Roland Schott, Rüdiger Geib, Rui Zhuang, Ruibo Han, Sabine Randriamasy, Scott Mansfield, Scott Robohn, Shengnan Yue, Suresh Krishnan, Thomas Graf, Toerless Eckert, Wangbo, Warren Kumari, Wes Hardaker, Wim Henderickx, Xue Yang, Y. Richard Yang, Yangbo, Yisong Liu, and Zhenqiang Li 🧚

Appendix E. Workshop Program Committee 👑

The workshop program committee members were Wes Hardaker (co-chair), Dhruv Dhody (co-chair), Qin Wu, Suresh Krishnan, Benoît Claise, Mohamed Boucadair, Mahesh Jethanandani, Kent Watsen, and Warren Kumari 💖

IAB Members at the Time of Approval 🦋

Internet Architecture Board members at the time this document was approved for publication were:

Matthew Bocci
Roman Danyliw
Dhruv Dhody
Jana Iyengar
Cullen Jennings
Suresh Krishnan
Mirja Kühlewind
Warren Kumari
Jason Livingood
Mark Nottingham
Tommy Pauly
Alvaro Retana
Qin Wu

Acknowledgments 🫶

Thanks to Benoît Claise, Jürgen Schönwälder, Kristian Larsson, Jaime Jiménez, Michael Richardson, Phil Shafer, Mirja Kühlewind, and Roman Danyliw for helpful suggestions to improve this report 💜

Thanks to Alvaro Retana for shepherding this document ✨

Authors' Addresses 💌

Wes Hardaker Email: hardaker@isi.edu

Dhruv Dhody Email: dd@dhruvdhody.com

That's the whole thing, bestie!! 🌈💅

📦 where this page comes from

ietf: rfc9968 2026-05
💖 girlified by claude-haiku-5-5 on 2026-10-19: a language model's rewrite of the original, under its terms