rfc9968.original   rfc9968.txt 
Network Working Group W. Hardaker Internet Architecture Board (IAB) W. Hardaker
Internet-Draft Request for Comments: 9968
Intended status: Informational D. Dhody Category: Informational D. Dhody
Expires: 2 March 2026 29 August 2025 ISSN: 2070-1721 April 2026
Report from the IAB Workshop on the Next Era of Network Management Report from the IAB Workshop on the Next Era of Network Management
Operations (NEMOPS) Operations (NEMOPS)
draft-iab-nemops-workshop-report-04
Abstract Abstract
The "Next Era of Network Management Operations (NEMOPS)" workshop was The "Next Era of Network Management Operations (NEMOPS)" workshop was
convened by the Internet Architecture Board (IAB) from December 3-5, convened by the Internet Architecture Board (IAB) from December 3-5,
2024, as a three-day online meeting. It builds on a previous 2002 2024 as a three-day online meeting. It builds on a previous 2002
workshop, the outcome of which was documented in RFC 3535, workshop, the outcome of which was documented in RFC 3535,
identifying 14 operator requirements for consideration in future identifying 14 operator requirements for consideration in future
network management protocol design and related data models, along network management protocol design and related data models, along
with some recommendations for the IETF. Much has changed in the with some recommendations for the IETF. Much has changed in the
Internet’s operation and technological foundations since then. The Internet's operation and technological foundations since then. The
NEMOPS workshop reviewed the past outcomes and discussed any NEMOPS workshop reviewed the past outcomes and discussed any
operational barriers that prevented these technologies from being operational barriers that prevented these technologies from being
widely implemented. With the industry, network operators and widely implemented. With the industry, network operators and
protocol engineers working in collaboration, the workshop developed a protocol engineers working in collaboration, the workshop developed a
suggested plan of action and network management recommendations for suggested plan of action and network management recommendations for
the IETF and IRTF. Building on RFC 3535, this document provides the the IETF and IRTF. Building on RFC 3535, this document provides the
report of the follow-up IAB workshop on Network Management. report of the follow-up IAB workshop on network management.
Note that this document is a report on the proceedings of the Note that this document is a report on the proceedings of the
workshop. The views and positions documented in this report are workshop. The views and positions documented in this report are
those of the workshop participants and do not necessarily reflect IAB those of the workshop participants and do not necessarily reflect IAB
views and positions. views and positions.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://intarchboard.github.io/draft-iab-nemops-workshop-report/
draft-iab-nemops-workshop-report.html. Status information for this
document may be found at https://datatracker.ietf.org/doc/draft-iab-
nemops-workshop-report/.
Source for this draft and an issue tracker can be found at
https://github.com/intarchboard/draft-iab-nemops-workshop-report.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Architecture Board (IAB)
and may be updated, replaced, or obsoleted by other documents at any and represents information that the IAB has deemed valuable to
time. It is inappropriate to use Internet-Drafts as reference provide for permanent record. It represents the consensus of the
material or to cite them other than as "work in progress." Internet Architecture Board (IAB). Documents approved for
publication by the IAB are not candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 2 March 2026. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9968.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. About this workshop report content . . . . . . . . . . . 4 1.1. About the Content of This Workshop Report
2. Outreach and Survey . . . . . . . . . . . . . . . . . . . . . 4 2. Outreach and Survey
3. Workshop Scope and Discussion . . . . . . . . . . . . . . . . 5 3. Workshop Scope and Discussion
3.1. Session I: Past (lookback, analysis) . . . . . . . . . . 5 3.1. Session I: Past - Lookback and Analysis
3.1.1. Reflections . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Reflections
3.1.2. Lessons to be Learned . . . . . . . . . . . . . . . . 6 3.1.2. Lessons to be Learned
3.1.3. Discussion . . . . . . . . . . . . . . . . . . . . . 7 3.1.3. Discussion
3.2. Session II: Present (identified problems & 3.2. Session II: Present - Identified Problems and Requirements
requirements) . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Operator Feedback
3.2.1. Operator Feedback . . . . . . . . . . . . . . . . . . 8 3.2.2. Survey
3.2.2. Survey . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.3. Discussion
3.2.3. Discussion . . . . . . . . . . . . . . . . . . . . . 10 3.3. Session III: Future - Possible Solutions, Recommendations,
3.3. Session III: Future (possible solutions, recommendations and Next Steps
and next steps) . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. Suggestions on Future Directions
3.3.1. Suggestions on Future Directions . . . . . . . . . . 11 3.3.2. Discussion
3.3.2. Discussion . . . . . . . . . . . . . . . . . . . . . 12 3.4. Key Takeaways
3.4. Key Takeaways . . . . . . . . . . . . . . . . . . . . . . 12 3.4.1. Ecosystem Conclusions
3.4.1. Ecosystem conclusions . . . . . . . . . . . . . . . . 13 3.4.2. Protocol Conclusions
3.4.2. Protocol conclusions . . . . . . . . . . . . . . . . 13 3.4.3. Modeling Conclusions
3.4.3. Modeling conclusions . . . . . . . . . . . . . . . . 14 3.4.4. Standardization Conclusions
3.4.4. Standardization conclusions . . . . . . . . . . . . . 14 3.4.5. Conclusions That Did Not Reach Consensus During the
3.4.5. Conclusions that did not reach consensus during the Takeaways Discussion
takeaways discussion . . . . . . . . . . . . . . . . 15 4. Not Covered in the Workshop
4. Not Covered in the Workshop . . . . . . . . . . . . . . . . . 15 5. Security Considerations
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Informative References
7. Informative References . . . . . . . . . . . . . . . . . . . 16 Appendix A. Operator Feedback
Appendix A. Operator Feedback . . . . . . . . . . . . . . . . . 20 A.1. General
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 20 A.2. Data Models
A.2. Data Models . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix B. Key Recommendations from Operator Feedback
Appendix B. Key Recommendations from Operator Feedback . . . . . 21 Appendix C. Position Papers
Appendix C. Position Papers . . . . . . . . . . . . . . . . . . 22 Appendix D. Workshop Participants
Appendix D. Workshop Participants . . . . . . . . . . . . . . . 24 Appendix E. Workshop Program Committee
Appendix E. Workshop Program Committee . . . . . . . . . . . . . 24 IAB Members at the Time of Approval
IAB Members at the Time of Approval . . . . . . . . . . . . . . . 24 Acknowledgments
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The Internet Architecture Board (IAB) holds occasional workshops The Internet Architecture Board (IAB) holds occasional workshops
designed to consider long-term issues and strategies for the designed to consider long-term issues and strategies for the
Internet, and to suggest future directions for the Internet Internet, and to suggest future directions for the Internet
architecture. This long-term planning function of the IAB is architecture. This long-term planning function of the IAB is
complementary to the ongoing engineering efforts performed by working complementary to the ongoing engineering efforts performed by working
groups of the Internet Engineering Task Force (IETF). groups of the Internet Engineering Task Force (IETF).
The IAB organized a workshop in 2002 to establish a dialog between The IAB organized a workshop in 2002 to establish a dialog between
network operators and protocol developers, and to guide the IETF's network operators and protocol developers and to guide the IETF's
work on network management protocols. The outcome of that workshop work on network management protocols. The outcome of that workshop
was documented in the "Overview of the 2002 IAB Network Management was documented in the "Overview of the 2002 IAB Network Management
Workshop" [RFC3535], which identified 14 operator requirements and 11 Workshop" [RFC3535], which identified 14 operator requirements and 11
recommendations for consideration in future network management recommendations for consideration in future network management
protocol design and related data models within the IETF. protocol design and related data models within the IETF.
Those requirements were instrumental in developing the NETCONF Those requirements were instrumental in developing the Network
protocol (in the NETCONF Working Group) [RFC6241], the associated Configuration Protocol (NETCONF) (in the NETCONF Working Group)
YANG data modeling language (in the NETMOD Working Group) [RFC7950], [RFC6241], the associated YANG data modeling language (in the NETMOD
RESTCONF [RFC8040], and most recently CORECONF [I-D.ietf-core-comi]. Working Group) [RFC7950], RESTCONF [RFC8040], and most recently the
CoAP Management Interface (CORECONF) [CORECONF].
The recent NEMOPS IAB workshop focused on the following key tasks: The recent NEMOPS IAB workshop focused on the following key tasks:
* Review the outcomes and results of the 2002 workshop (current * Review the outcomes and results of the 2002 workshop (current
deployments, state of the art) and identify any operational deployments and state of the art) and identify any operational
barriers that prevent these technologies from being widely barriers that prevent these technologies from being widely
implemented (limitations, hurdles). implemented (limitations and hurdles).
* Sketch new requirements for future network management operations * Sketch new requirements for future network management operations
in a collaborative manner with the industry, network operators, in a collaborative manner with the industry, network operators,
and protocol engineers. and protocol engineers.
* Develop a plan of action and recommendations for the IETF. * Develop a plan of action and recommendations for the IETF.
This document builds on RFC 3535 with new information gathered from This document builds on RFC 3535 with new information gathered from
the second IAB workshop on the future of Network Management. The the second IAB workshop on the future of network management. The
goal of the second workshop was not to invalidate or replace the goal of the second workshop was not to invalidate or replace the
first, but to extend the discussion with lessons learned since then. first but to extend the discussion with lessons learned since then.
Together, both documents capture a snapshot of the evolving needs of Together, both documents capture a snapshot of the evolving needs of
network management over time. network management over time.
1.1. About this workshop report content 1.1. About the Content of This Workshop Report
This document is a report on the proceedings of the workshop. The This document is a report on the proceedings of the workshop. The
views and positions documented in this report are expressed during views and positions documented in this report are expressed during
the workshop by participants and do not necessarily reflect IAB's the workshop by participants and do not necessarily reflect the IAB's
views and positions. views and positions.
Furthermore, the content of the report comes from presentations given Furthermore, the content of the report comes from presentations given
by workshop participants and notes taken during the discussions, by workshop participants and notes taken during the discussions,
without interpretation or validation. Thus, the content of this without interpretation or validation. Thus, the content of this
report follows the flow and dialogue of the workshop but does not report follows the flow and dialogue of the workshop but does not
necessarily attempt to capture a consensus, unless stated otherwise. necessarily attempt to capture a consensus, unless stated otherwise.
2. Outreach and Survey 2. Outreach and Survey
The IAB workshop's Program Committee (PC) planned outreach The IAB workshop's Program Committee (PC) planned outreach
initiatives to foster discussions and gather interest by engaging initiatives to foster discussions and gather interest by engaging
with operators at various operational venues (RIPE, NANOG, APRICOT, with operators at various operational venues (Réseaux IP Européens
LACNIC, AutoConn, etc) and conducting information/requirement- (RIPE), North American Network Operators Group (NANOG), Asia Pacific
gathering sessions. Participants were encouraged to submit "position Regional Internet Conference on Operational Technologies (APRICOT),
papers" or "expressions of interest" to join the workshop. Latin American and Caribbean Internet Addresses Registry (LACNIC),
Additionally, a [SURVEY] was conducted to collect valuable insights AutoConn, etc.) and conducting information-/requirement-gathering
to inform the workshop. sessions. Participants were encouraged to submit "position papers"
or "expressions of interest" to join the workshop. Additionally, a
[SURVEY] was conducted to collect valuable insights to inform the
workshop.
Some PC members continued to engage with network operators at After the workshop, some PC members continued to engage with network
operational venues after the workshop to facilitate information operators at operational venues to facilitate information sharing and
sharing and gather their feedback on the workshop, thereby helping to gather their feedback on the workshop, thereby helping to shape the
shape the next steps and outcomes. next steps and outcomes.
3. Workshop Scope and Discussion 3. Workshop Scope and Discussion
The workshop was organized across three days, with all participants The workshop was organized across three days, with all participants
contributing to one discussion per day. The workshop was organized contributing to one discussion per day. The workshop was organized
around three topic areas: "Session I: the Past (lookback and around three topic areas: "Session I: Past - Lookback and Analysis"
analysis)" (Section 3.1), "Session II: Present (identified problems (Section 3.1), "Session II: Present - Identified Problems and
and requirements)" (Section 3.2), and "Session III: Future (possible Requirements" (Section 3.2), and "Session III: Future - Possible
solutions, recommendations and next steps)" (Section 3.3). The Solutions, Recommendations, and Next Steps" (Section 3.3). The
program committee organized the paper submissions to fit these three program committee organized the paper submissions to fit these three
main themes in order to drive discussion during each of the slots. main themes in order to drive discussion during each of the slots.
During each discussion, the papers were presented sequentially, and During each discussion, the papers were presented sequentially, and
an open discussion was held afterwards. On the last day, an an open discussion was held afterwards. On the last day, an
additional discussion on the key takeaways from the workshop and additional discussion took place on the key takeaways from the
possible next steps took place (Section 3.4). workshop and possible next steps (Section 3.4).
The workshop agenda for each day is at past The workshop agenda for each day can be viewed at past
(https://datatracker.ietf.org/doc/agenda-interim-2024-nemopsws- <https://datatracker.ietf.org/doc/agenda-interim-2024-nemopsws-
01-sessa/), present (https://datatracker.ietf.org/doc/agenda-interim- 01-sessa/>, present <https://datatracker.ietf.org/doc/agenda-interim-
2024-nemopsws-02-sessa/), and future 2024-nemopsws-02-sessa/>, and future
(https://datatracker.ietf.org/doc/agenda-interim-2024-nemopsws- <https://datatracker.ietf.org/doc/agenda-interim-2024-nemopsws-
03-sessa/). All workshop papers and slides are at materials 03-sessa/>. All workshop papers and slides can be viewed at
(https://datatracker.ietf.org/group/nemopsws/materials/). materials <https://datatracker.ietf.org/group/nemopsws/materials/>.
3.1. Session I: Past (lookback, analysis) 3.1. Session I: Past - Lookback and Analysis
The first day of the workshop focused on reflecting on the past by The first day of the workshop focused on reflecting on the past by
reviewing the evolution of network management since the 2002 reviewing the evolution of network management since the 2002
workshop, analyzing both the successes and the challenges encountered workshop, analyzing both the successes and the challenges encountered
along the way. The presentations covered a range of topics, along the way. The presentations covered a range of topics,
including reflections on the history of network management, lessons including reflections on the history of network management, lessons
learned from widely used tools, practices in constrained networks, learned from widely used tools, practices in constrained networks,
and the need to reconsider how network management models and and the need to reconsider how network management models and
protocols are standardized within the IETF. protocols are standardized within the IETF.
3.1.1. Reflections 3.1.1. Reflections
The workshop began by reflecting on the IAB’s role in shaping the The workshop began by reflecting on the IAB's role in shaping the
evolution of network management away from CLI/SNMP/MIB technologies, evolution of network management away from Command-Line Interface
focusing on the context and key outcomes of the previous workshop, an (CLI), SNMP, and MIB technologies, focusing on the context and key
assessment of the current state of network management as a whole, and outcomes of the previous workshop, an assessment of the current state
an acknowledgement of some regrets in how network management of network management as a whole, and an acknowledgement of some
technologies developed in the last two decades (such as XML as the regrets in how network management technologies developed in the last
data representation format). [SCHONWALDER] emphasized the need to two decades (such as XML as the data representation format).
shift the focus from device-level configuration to network and [SCHONWALDER] emphasized the need to shift the focus from device-
service-level configuration. Key properties highlighted for level configuration to network and service-level configuration. Key
effective network and service configurations included being properties highlighted for effective network and service
Composable (assembled out of modular configurations), Declarative configurations included being Composable (assembled out of modular
(define state while systems determine themselves how to implement configurations), Declarative (define state while systems themselves
those goals), Reproducible (reliably and consistently recreated), and determine how to implement those goals), Reproducible (reliably and
Verifiable (asserting that the correct changes have been applied). consistently recreated), and Verifiable (asserting that the correct
changes have been applied).
An operator’s perspective highlighted that the recommendations of An operator's perspective highlighted that the recommendations of
[RFC3535] (which led to the development of YANG and NETCONF) have [RFC3535] (which led to the development of YANG and NETCONF) have
been successful in addressing device configuration in many, but not been successful in addressing device configuration in many, but not
all, environments. In certain areas, the advancements in semantics all, environments. In certain areas, the advancements in semantics
and protocols for streaming telemetry have even surpassed the and protocols for streaming telemetry have even surpassed the
original scope of [RFC3535]. [FARRER] cautioned against making original scope of [RFC3535]. [FARRER] cautioned against making
changes that could disrupt the ecosystem. The presentation changes that could disrupt the ecosystem. The presentation
emphasized the need to prioritize service modeling in the IETF and emphasized the need to prioritize service modeling in the IETF and
addressed the challenges of mapping to the Business Support Systems addressed the challenges of mapping to the Business Support Systems
(BSS) domain. It also stressed the importance of including the (BSS) domain. It also stressed the importance of including the
operational state in service models to enable closed-loop automation operational state in service models to enable closed-loop automation
for end-to-end (E2E) services. Revisiting [RFC8309], which asserts for end-to-end (E2E) services. Revisiting [RFC8309], which asserts
that the operational state of a service is not part of a customer that the operational state of a service is not part of a customer
service model but can be achieved through extensions, was suggested. service model but can be achieved through extensions, was suggested.
Additionally, the lack of open-source NMS implementations, tools, and Additionally, the lack of open-source Network Management System (NMS)
device model implementations was identified as a significant barrier implementations, tools, and device model implementations was
to advancing standardization efforts. The IETF could play a key role identified as a significant barrier to advancing standardization
in fostering and enabling collaborations to address these challenges. efforts. The IETF could play a key role in fostering and enabling
While the IETF does not itself build tools, it was suggested that collaborations to address these challenges. While the IETF does not
having a translation tool that runs outside the network device to map itself build tools, it was suggested that having a translation tool
IETF device models to vendor-specific ones would be beneficial. that runs outside the network device to map IETF device models to
vendor-specific ones would be beneficial.
3.1.2. Lessons to be Learned 3.1.2. Lessons to be Learned
[HARDAKER] emphasized that the success of Net-SNMP [NET-SNMP] was [HARDAKER] emphasized that the success of Net-SNMP [NET-SNMP] was
driven by empowering users through simplicity, stressing that the driven by empowering users through simplicity, stressing that the
focus should remain on ensuring ease of use and adaptability of the focus should remain on ensuring ease of use and adaptability of the
protocols. Emphasis was placed on the two distinct audiences for protocols. Emphasis was placed on the two distinct audiences for
standardized network management protocols: toolkit vendors and system standardized network management protocols: toolkit vendors and system
operators. Their requirements for protocol simplicity differ, and it operators. Their requirements for protocol simplicity differ, and it
is essential to address the needs of both to ensure success. is essential to address the needs of both to ensure success.
[BORMANN] presented an overview of the CORECONF architecture, [BORMANN] presented an overview of the CORECONF architecture,
showcasing how model-driven network management techniques can be showcasing how model-driven network management techniques can be
applied to manage IoT devices (which is different from other network applied to manage Internet of Things (IoT) devices (which is
management scenarios), with a focus on the unique characteristics of different from other network management scenarios), with a focus on
constrained nodes. Some participants noted that the binary encoding the unique characteristics of constrained nodes. Some participants
of CBOR has applications that extend beyond the IoT networks. noted that the binary encoding of Concise Binary Object
Representation (CBOR) has applications that extend beyond the IoT
networks.
Drawing from the experience of OpenConfig [OPENCONFIG], [SHAKIR] Drawing from the experience of OpenConfig [OPENCONFIG], [SHAKIR]
emphasized that protocol definition and data models cannot be done in emphasized that protocol definition and data models cannot be done in
isolation; instead, they must integrate lessons learned from isolation; instead, they must integrate lessons learned from
implementation and large-scale deployment. Thus, highlighting the implementation and large-scale deployment. Thus, highlighting the
importance of enabling quick iterations, shipping rapidly, embracing importance of enabling quick iterations, shipping rapidly, embracing
open-source, readily available tools, adopting systems thinking open source, readily available tools, adopting systems thinking
driven by business outcomes, and reusing existing technologies rather driven by business outcomes, and reusing existing technologies rather
than developing solutions exclusively for operator network than developing solutions exclusively for operator network
management. A call was made for the IETF to rethink the approach to management. A call was made for the IETF to rethink the approach to
standardize data models and the associated network management standardize data models and the associated network management
protocols under this guidance. protocols under this guidance.
3.1.3. Discussion 3.1.3. Discussion
The Session I open discussion highlighted the divergence between The Session I open discussion highlighted the divergence between
vendor implementations of YANG models and what is accessible via vendor implementations of YANG models and what is accessible via the
them, particularly when compared to CLI. Questions were raised about models, particularly when compared to CLI. Questions were raised
how to incorporate fast iteration and rapid changes within the about how to incorporate fast iteration and rapid changes within the
established IETF process and culture, especially in contrast to the established IETF process and culture, especially in contrast to the
approach used by OpenConfig. Common challenges identified included a approach used by OpenConfig. Common challenges identified included a
lack of tooling, performance issues at scale, the steep learning lack of tooling, performance issues at scale, the steep learning
curve for network management protocols/models/tools, initial curve for network management protocols/models/tools, initial
difficulty in moving away from CLI, and the backward compatibility of difficulty in moving away from CLI, and the backward compatibility of
models (versioning). Some participants suggested that the IETF models (versioning). Some participants suggested that the IETF
should focus on system-level APIs that address specific problems. should focus on system-level APIs that address specific problems.
Additionally, the lack of simple tools for smaller networks operating Additionally, the lack of simple tools for smaller networks operating
under tight timelines and budgets was emphasized. A key question under tight timelines and budgets was emphasized. A key question
raised was whether the proliferation of protocols and languages raised was whether the proliferation of protocols and languages
complicates adoption, and if converging on a single approach would complicates adoption and if converging on a single approach would
improve adoption. The existence of multiple schemas and protocols improve adoption. The existence of multiple schemas and protocols
beyond NETCONF, such as BMP and IPFIX, to address network management beyond NETCONF, such as the BGP Monitoring Protocol (BMP) and IP Flow
challenges beyond configuration is an established reality. One Information Export (IPFIX), to address network management challenges
conclusion was that a mechanism was needed to interconnect and beyond configuration is an established reality. One conclusion was
harmonize these schemas to provide a cohesive and comprehensive that a mechanism was needed to interconnect and harmonize these
understanding of the data. schemas to provide a cohesive and comprehensive understanding of the
data.
3.2. Session II: Present (identified problems & requirements) 3.2. Session II: Present - Identified Problems and Requirements
The second day of the workshop concentrated on challenges and The second day of the workshop concentrated on challenges and
emerging requirements for future network management operations. The emerging requirements for future network management operations. The
presentation emphasized the importance of validation, observability, presentation emphasized the importance of validation, observability,
automation, and the need for agile, incremental development of both automation, and the need for agile, incremental development of both
network models and management protocols. A compilation of new network models and management protocols. A compilation of new
requirements from operators was presented; they are being maintained requirements from operators was presented; they are being maintained
in [I-D.ietf-nmop-rfc3535-20years-later]. The final presentation of in [OP-REQ-NM]. The final presentation of the day provided a summary
the day provided a summary of the survey results and operator of the survey results and operator feedback gathered from outreach
feedback gathered from outreach events. events.
3.2.1. Operator Feedback 3.2.1. Operator Feedback
[KELLER] shared Deutsche Telekom’s perspective, emphasizing that [KELLER] shared Deutsche Telekom's perspective, emphasizing that
while YANG models perform well for provisioning, they currently fall while YANG models perform well for provisioning, they currently fall
short in providing the operational stability required for validation. short in providing the operational stability required for validation.
In their experience, the IETF service models (where available) were In their experience, the IETF service models (where available) were
considered stable and in good condition, whereas the OpenConfig considered stable and in good condition, whereas the OpenConfig
device models were noted as lacking feature richness and stability. device models were noted as lacking feature richness and stability.
In contrast, vendor YANG models are often more flexible and available In contrast, vendor YANG models are often more flexible and available
in a more timely manner. Achieving fully closed-loop automated and in a more timely manner. Achieving fully closed-loop automated and
autonomous networking will require a greater focus on observability, autonomous networking will require a greater focus on observability,
particularly through advancements in streaming telemetry with the particularly through advancements in streaming telemetry with the
"on-change" feature [RFC9196]. "on-change" feature [RFC9196].
skipping to change at page 8, line 31 skipping to change at line 344
observability and analytics requirements, issues with data streaming, observability and analytics requirements, issues with data streaming,
scalability, diverse models in heterogeneous multi-vendor scalability, diverse models in heterogeneous multi-vendor
environments, and mechanisms to secure the network management environments, and mechanisms to secure the network management
protocols. The presentation also emphasized how advancements in AI protocols. The presentation also emphasized how advancements in AI
and machine learning, along with the potential adaptation of and machine learning, along with the potential adaptation of
protocols designed for constrained environments, could drive the next protocols designed for constrained environments, could drive the next
evolution in network management. evolution in network management.
Using YANG-Push as an example, [GRAF] highlighted how standards Using YANG-Push as an example, [GRAF] highlighted how standards
development often fails to align with the needs of network operators, development often fails to align with the needs of network operators,
the constraints of network vendors, and the integration requirements. the constraints of network vendors, and integration requirements.
Most critically, it lacks an agile, incremental development process. Most critically, it lacks an agile, incremental development process.
The presentation advocated for adopting an iterative approach to The presentation advocated for adopting an iterative approach to
standards development, focusing on delivering minimal viable products standards development, focusing on delivering minimal viable products
as part of the process. as part of the process.
[CONTRERAS] emphasized reassessing deployment assumptions and [CONTRERAS] emphasized reassessing deployment assumptions and
incorporating updated operator requirements. The authors are incorporating updated operator requirements. The authors are
addressing these aspects through addressing these aspects through [OP-REQ-NM], leveraging feedback and
[I-D.ietf-nmop-rfc3535-20years-later], leveraging feedback and discussions from the workshop. Some key requirements, suggestions,
discussions from the workshop. Some key requirements, suggestions
and observations that were highlighted in the workshop: and observations that were highlighted in the workshop:
* Network software implementations can only happen with a strong, * Network software implementations can only happen with a strong,
committed standardization effort, complemented by active committed standardization effort, complemented by active
involvement in open-source projects that facilitate access to involvement in open-source projects that facilitate access to
code. code.
* Need to rationalize the device model space and avoid redundant * Need to rationalize the device model space and avoid redundant
efforts. Unlike service and network models, IETF-defined device efforts. Unlike service and network models, IETF-defined device
models are not widely implemented. models are not widely implemented.
* Define a reference approach/process for service exposure discovery * Define a reference approach/process for service exposure discovery
(API discovery). (API discovery).
* Outlines a set of recommendations for core/key features, along * Outline a set of recommendations for core/key features, along with
with appropriate justifications, that will help foster more appropriate justifications, that will help foster more
implementations that meet operators’ needs. implementations that meet operators' needs.
* Reassess the value of some IETF proposals, including compared to * Reassess the value of some IETF proposals, including comparison to
competing or emerging solutions (e.g., gNMI vs. YANG-Push) competing or emerging solutions (e.g., gRPC Network Management
Interface (gNMI) vs. YANG-Push)
* Need for a more agile process for the development and maintenance * Need for a more agile process for the development and maintenance
of YANG modules in the IETF. RFCs might not be suited for of YANG modules in the IETF. RFCs might not be suited for
documenting YANG modules. documenting YANG modules.
* Consider approaches to ease integration by design (e.g., protocols * Consider approaches to ease integration by design (e.g., protocols
and data models). and data models).
* There is a need for a reference specification to translate YANG- * Need for a reference specification to translate YANG-based data
based data into the knowledge graph (KG). into the knowledge graph (KG).
* Consider approaches to help YANG models scale. * Consider approaches to help YANG models scale.
* Consider programmatic approaches to ensure lossless mappings * Consider programmatic approaches to ensure lossless mappings
between service/network/device data models. between service/network/device data models.
* Consider approaches to ensure reuse/consistent data structure * Consider approaches to ensure reuse of / consistent data structure
across various NM segments. across various network management segments.
* Some networks have specific network management requirements, such * Some networks have specific network management requirements, such
as the need for asynchronous operations or constraints on data as the need for asynchronous operations or constraints on data
compactness. compactness.
* There is a necessity to handle the heterogeneity of data, * Necessity to handle the heterogeneity of data, configuration, and
configuration, and network management/requirements. Resolving network management/requirements. Resolving such issues could draw
such issues could draw on insights from parallel technical fields on insights from parallel technical fields such as knowledge
such as knowledge engineering practices and concepts associated engineering practices and concepts associated with Linked Data in
with Linked Data in the Semantic Web, areas where it is common to the Semantic Web, areas where it is common to manage problems of
manage problems of heterogeneity and data reconciliation across heterogeneity and data reconciliation across various application
various application domains. domains.
* Consider having YANG as part of the protocol specification/change * Consider having YANG as part of the protocol specification/change
where possible, or have the YANG document progress in parallel. where possible, or have the YANG document progress in parallel.
* Need to ease the integration of low-level/network-oriented * Need to ease the integration of low-level/network-oriented
solutions with native "IT tooling" solutions with native "IT tooling".
* Ease exposure of libraries and host tools (e.g., yangkit) to ease * Ease exposure of libraries and host tools (e.g., yangkit) to ease
integration. integration.
* Focus on tooling is needed, especially on the client side. * Focus on tooling is needed, especially on the client side.
* Create an ecosystem where data and networking engineers can * Create an ecosystem where data and networking engineers can
collaborate. collaborate.
* The distinct approaches followed in both the compute and the * Distinct approaches are followed in both the compute and the
network environments to define suitable mechanisms for enabling an network environments to define suitable mechanisms for enabling an
efficient interplay, while highly automating the overall service efficient interplay, while highly automating the overall service
delivery procedure. delivery procedure.
* The target application/applicability of a network management * The target application/applicability of a network management
approach should be documented. approach should be documented.
* Readily available API specifications could be generalized from * Readily available API specifications could be generalized from
YANG modules for fast development, prototyping, and validation. YANG modules for fast development, prototyping, and validation.
3.2.2. Survey 3.2.2. Survey
As outlined in Section 2, the workshop program committee organized As outlined in Section 2, the workshop program committee organized
outreach initiatives to gather direct feedback and conducted a outreach initiatives to gather direct feedback and conducted a
survey. [SURVEY-INSIGHTS] provided an overview of the respondents’ survey. [SURVEY-INSIGHTS] provided an overview of the respondents'
backgrounds, as well as insights into the most widely used tools, backgrounds, as well as insights into the most widely used tools,
protocols, and APIs for configuration, monitoring, and other network protocols, and APIs for configuration, monitoring, and other network
operations. Notably, the survey revealed that Ansible and CLI are operations. Notably, the survey revealed that Ansible and CLI are
the most popular configuration tools, NETCONF is the preferred the most popular configuration tools, NETCONF is the preferred
configuration protocol, and Prometheus and SNMP are widely used for configuration protocol, and Prometheus and SNMP are widely used for
monitoring. The survey also captured feedback on network automation monitoring. The survey also captured feedback on network automation
and streaming telemetry. Issues and future requirements such as and streaming telemetry. Issues and future requirements such as
scalability, performance, the need for easier mapping of various scalability, performance, the need for easier mapping of various
models, tooling, management of legacy devices, collaboration with models, tooling, management of legacy devices, collaboration with
open-source, and vendor-specific issues were highlighted. open source, and vendor-specific issues were highlighted.
Additionally, valuable insights from direct operator feedback were Additionally, valuable insights from direct operator feedback were
also presented (see Appendix A). presented (see Appendix A).
3.2.3. Discussion 3.2.3. Discussion
The Session II open discussion featured feedback from implementers, The Session II open discussion featured feedback from implementers,
highlighting the difficulty in moving to YANG and mapping to vendor highlighting the difficulty in moving to YANG and mapping to vendor
implementations and how divergence in the implementations creates implementations and how divergence in implementations creates
complexity and necessitates workarounds. Implementations need to complexity and necessitates workarounds. Implementations need to
support standard models alongside native vendor models, which adds support standard models alongside native vendor models, which adds
complexity and leads to confusion. Challenges were highlighted in complexity and leads to confusion. Challenges were highlighted in
mapping standard models to internal device models and legacy devices, mapping standard models to internal device models and legacy devices,
with some cases where mapping is not feasible at all (device-specific with some cases where mapping is not feasible at all (device-specific
knobs). The conversation also emphasized the importance of knobs). The conversation also emphasized the importance of
developing open-source reference implementations, compliance and developing open-source reference implementations, compliance and
interoperability testing for vendors with real data, and better interoperability testing for vendors with real data, and better
quality of vendor implementation and documentation. The quality of vendor implementation and documentation. The
implementation and support of multiple models (IETF, OpenConfig, and implementation and support of multiple models (IETF, OpenConfig, and
native vendor models) is an unavoidable reality in network native vendor models) is an unavoidable reality in network
management. Additionally, since the services offered by operators management. Additionally, since the services offered by operators
vary significantly, reaching a consensus on a common service model vary significantly, reaching a consensus on a common service model
within the IETF can be a challenging task. It was also noted that within the IETF can be a challenging task. It was also noted that
the IETF should expedite the publication of standards as well as the IETF should expedite the publication of standards as well as
consider gating them with multiple interoperable implementations. consider gating them with multiple interoperable implementations.
3.3. Session III: Future (possible solutions, recommendations and next 3.3. Session III: Future - Possible Solutions, Recommendations, and
steps) Next Steps
The final day of the workshop centred on exploring potential future The final day of the workshop centered on exploring potential future
solutions and identifying key takeaways, recommendations, and next solutions and identifying key takeaways, recommendations, and next
steps. At the end of day three, to conclude the workshop, the chairs steps. At the end of day three, to conclude the workshop, the chairs
worked to summarize the key takeaways (see Section 3.4) that garnered worked to summarize the key takeaways (see Section 3.4) that garnered
consensus among the participants. consensus among the participants.
3.3.1. Suggestions on Future Directions 3.3.1. Suggestions on Future Directions
[CLAISE] highlighted the challenges of integrating data models across [CLAISE] highlighted the challenges of integrating data models across
different silos, protocols, and data structures, emphasizing the need different silos, protocols, and data structures, emphasizing the need
for a machine-readable approach to expose semantics. Additionally, for a machine-readable approach to expose semantics. Additionally,
the related tools being developed and showcased in the IETF the related tools being developed and showcased in the IETF
Hackathons, along with the various challenges in mapping across Hackathons, along with the various challenges in mapping across
protocols and models, were discussed. A potential solution was protocols and models, were discussed. A potential solution was
proposed using a knowledge graph based on the Semantic Web Stack, proposed that uses a knowledge graph based on the Semantic Web Stack,
along with the need to define a basic ontology for the networking along with the need to define a basic ontology for the networking
domain in an iterative manner (outside of RFCs). domain in an iterative manner (outside of RFCs).
[WATSEN] recommends prioritizing the following areas in four [WATSEN] recommended prioritizing the following into four areas: (1)
recommendations: (1) using RESTCONF+JSON (including YANG-Push Lite) using RESTCONF+JSON (including YANG-Push Lite) as a single protocol
as a single protocol beyond network management, (2) utilizing Network beyond network management, (2) utilizing Network Management Datastore
Management Datastore Architecture (NMDA) model, (3) creating data Architecture (NMDA) model, (3) creating data model adapters (off-box
model adapters (off-box so that common standard models can be so that common standard models can be developed in parallel to the
developed in parallel to the required device "native" vendor models), required device "native" vendor models), and (4) defining device
and (4) defining device protocol adapters (with RESTCONF-like NBI for protocol adapters (with RESTCONF-like Northbound Interface (NBI) for
a common shared-by-all repository). a common shared-by-all repository).
[WILTON] recommends reducing unnecessary complexity, delivering [WILTON] recommended reducing unnecessary complexity, delivering
timely solutions, fostering open collaboration between vendors and timely solutions, fostering open collaboration between vendors and
operators, prioritizing simplicity, and converging to a single model/ operators, prioritizing simplicity, and converging to a single model/
protocol (though this was discussed as difficult to accomplish). protocol (though this was discussed as difficult to accomplish).
Practical suggestions include focusing on YANG-Push Lite, introducing Practical suggestions include focusing on YANG-Push Lite, introducing
YANG 2.0 through incremental updates, developing NETCONFv2, and YANG 2.0 through incremental updates, developing NETCONFv2, and
managing IETF YANG models as code or APIs rather than embedding them managing IETF YANG models as code or APIs rather than embedding them
within RFCs. within RFCs.
3.3.2. Discussion 3.3.2. Discussion
The open discussion in Session III explored a range of topics. These The open discussion in Session III explored a range of topics. These
included the absence of NMDA in OpenConfig and debate over whether included the absence of NMDA in OpenConfig and debate over whether
its complexity is justified; the historical context of gNMI’s its complexity is justified; the historical context of gNMI's
introduction in the IETF and whether RESTCONF offers advantages over introduction in the IETF and whether RESTCONF offers advantages over
it; and the broader challenges of building consensus, with it; and the broader challenges of building consensus, with
participants noting that while the process takes time, it should not participants noting that while the process takes time, it should not
be short-circuited. The discussion also addressed the practicality be short-circuited. The discussion also addressed the practicality
of converging on a single protocol and concluded that such of converging on a single protocol and concluded that such
convergence is, in fact, feasible. convergence is, in fact, feasible.
The discussion emphasized off-box adapters, which allow vendors to The discussion emphasized off-box adapters, which allow vendors to
continue innovating and developing native vendor models rapidly. One continue innovating and developing native vendor models rapidly. One
suggestion that attracted a lot of discussion centred on developing a suggestion that attracted a lot of discussion centered on developing
standard model mapping to native vendor models that could be a standard model mapping to native vendor models that could be
maintained in a common repository, enabling the community to assess maintained in a common repository, enabling the community to assess
coverage and alignment. coverage and alignment.
Further, the discussion explored alternative approaches to YANG Further, the discussion explored alternative approaches to YANG
models within the IETF but outside of RFCs, such as leveraging GitHub models within the IETF but outside of RFCs, such as leveraging GitHub
to accelerate the process (along with the challenges associated with to accelerate the process (along with the challenges associated with
it), living documents within the WG charter, and supporting academia it), living documents within the WG charter, and supporting academia
to take up the open source efforts, such as device adapters. The to take up the open source efforts, such as device adapters. The
discussion emphasized the need for process experimentation, discussion emphasized the need for process experimentation,
particularly at the working group or area level, where we could have particularly at the working group or area level, where we could have
consensus among the YANG/OPS community on how we iterate in WGs consensus among the YANG/OPS community on how we iterate in WGs
without IETF/RFC-wide changes, but making sure the operators are without IETF-/RFC-wide changes, but making sure the operators are
involved in the process. involved in the process.
Conversations ensued around questions asked, such as "Is YANG Conversations ensued around questions asked, such as "Is YANG
applicable beyond network management?" and "Can applications adopt applicable beyond network management?" and "Can applications adopt
YANG as a modelling language to define their services?" YANG as a modeling language to define their services?"
Some key recommendations made by operators during outreach Some key recommendations made by operators during outreach
(Section 2) are listed in Appendix B. (Section 2) are listed in Appendix B.
3.4. Key Takeaways 3.4. Key Takeaways
At the end of the third day, the discussion turned to key takeaways At the end of the third day, the discussion turned to key takeaways
that have a high-level consensus. These were live edited during the that have a high-level consensus. These were edited live during the
last discussion of the workshop, and anything that did not reach a last discussion of the workshop, and anything that did not reach a
wide consensus was moved into a "future considerations" list wide consensus was moved into a "future considerations" list
(Section 3.4.5). (Section 3.4.5).
3.4.1. Ecosystem conclusions 3.4.1. Ecosystem Conclusions
The following takeaways try to document the general thinking of the The following takeaways try to document the general thinking of the
participants with respect to the entire Network Management ecosystem participants with respect to the entire network management ecosystem
as it exists today. as it exists today.
1. The current network management protocols, models and tools still 1. The current network management protocols, models, and tools still
fail the ‘ease of use’ requirement. Participants noted that the fail the 'ease of use' requirement. Participants noted that the
tools almost matter more than the protocols. tools almost matter more than the protocols.
2. The overall ecosystem is still fragmented for both protocols and 2. The overall ecosystem is still fragmented for both protocols and
data models. SNMP is still used extensively for monitoring, and data models. SNMP is still used extensively for monitoring, and
the CLI is still heavily relied on for configuration in many the CLI is still heavily relied on for configuration in many
networks. Popular protocols include SNMP, NETCONF, RESTCONF, and networks. Popular protocols include SNMP, NETCONF, RESTCONF, and
gNMI. gNMI.
3. Documentation about the architecture and usage of the network 3. Documentation about the architecture and usage of the network
management ecosystem is lacking. More work is needed to create management ecosystem is lacking. More work is needed to create
skipping to change at page 13, line 35 skipping to change at line 585
4. Transitioning between network management frameworks is 4. Transitioning between network management frameworks is
challenging, just like it is for transitioning between other challenging, just like it is for transitioning between other
protocols like IPv4 to IPv6. protocols like IPv4 to IPv6.
5. Model-driven network management is generally a success where it 5. Model-driven network management is generally a success where it
has been implemented and is possible to use. has been implemented and is possible to use.
6. More easily usable network management tools for the operators are 6. More easily usable network management tools for the operators are
needed. The lack of open-source tools is seen as a barrier to needed. The lack of open-source tools is seen as a barrier to
adoption. Tools need good use cases, example flows and better adoption. Tools need good use cases, example flows, and better
analysis of when and how they work and have been successful. analysis of when and how they work and have been successful.
3.4.2. Protocol conclusions 3.4.2. Protocol Conclusions
The following conclusions came while discussing Network Management The following conclusions were reached while discussing network
protocols, more specifically. management protocols, more specifically.
1. NETCONF and YANG are not used much for monitoring tasks. 1. NETCONF and YANG are not used much for monitoring tasks.
2. NETCONF and YANG do not have full coverage on many devices. 2. NETCONF and YANG do not have full coverage on many devices.
3. Polling-based solutions are still frequently deployed. Push- 3. Polling-based solutions are still frequently deployed. Push-
based solutions are often desired but are not yet widely based solutions are often desired but are not yet widely
available. available.
3.4.3. Modeling conclusions 3.4.3. Modeling Conclusions
The following conclusions came while discussing Network Management The following conclusions were reached while discussing network
modeling, more specifically. management modeling, more specifically.
1. Some YANG models can become complex due to the underlying 1. Some YANG models can become complex due to the underlying
features they represent, not due to the language itself. features they represent, not due to the language itself.
2. Multi-vendor compatibility support is required. 2. Multi-vendor compatibility support is required.
3. Even vendor-specific features, not just standardized protocol 3. Even vendor-specific features, not just standardized protocol
features, need to be exposed through network management models features, need to be exposed through network management models
and protocols for a network management ecosystem to be viable. and protocols for a network management ecosystem to be viable.
skipping to change at page 14, line 30 skipping to change at line 626
level modeling can be a building block to achieve a sufficient level modeling can be a building block to achieve a sufficient
service-level model, but it is not a complete solution by itself. service-level model, but it is not a complete solution by itself.
5. Network configuration needs to be verifiable to ensure any 5. Network configuration needs to be verifiable to ensure any
potential changes can be accepted by devices. Model translation potential changes can be accepted by devices. Model translation
adapters (likely performed on the management station, not the end adapters (likely performed on the management station, not the end
device) may be the best path forward to simultaneously achieve device) may be the best path forward to simultaneously achieve
this and the goal of supporting one configuration set across a this and the goal of supporting one configuration set across a
diversity of devices with different internal models. diversity of devices with different internal models.
3.4.4. Standardization conclusions 3.4.4. Standardization Conclusions
The following conclusions were reached while discussing the best ways The following conclusions were reached while discussing the best ways
to standardize network management protocols and associated models. to standardize network management protocols and associated models.
1. A methodology of rapid model development procedures is needed to 1. A methodology of rapid model development procedures is needed to
ensure model deployment can keep pace with new feature ensure model deployment can keep pace with new feature
deployment. We need a solution that significantly increases the deployment. We need a solution that significantly increases the
speed and predictable timeline for developing and publishing speed and predictable timeline for developing and publishing
models within the IETF. New approaches and methods to make models within the IETF. New approaches and methods to make
models live outside of published RFCs should be explored. An models live outside of published RFCs should be explored. An
experiment should be started to test a new rapid development experiment should be started to test a new rapid development
approach. approach.
2. Protocol and model complexity should be reduced to keep additions 2. Protocol and model complexity should be reduced to keep additions
and changes to a minimal set of agreed-upon core features. and changes to a minimal set of agreed-upon core features.
3. More standardization focus is needed on the scalability of the 3. More standardization focus is needed on the scalability of the
different roles of network management: monitoring, configuration, different roles of network management: monitoring, configuration,
notifications. and notifications.
4. Enhancements to network management protocols and models need to 4. Enhancements to network management protocols and models need to
be backed by real-world operator use cases and expected adoption be backed by real-world operator use cases and expected adoption
by vendors. Vendors and operators will need to work together to by vendors. Vendors and operators will need to work together to
ensure these goals are appropriately met. ensure these goals are appropriately met.
3.4.5. Conclusions that did not reach consensus during the takeaways 3.4.5. Conclusions That Did Not Reach Consensus During the Takeaways
discussion Discussion
Here we list the things that the group realized needed significantly Here, we list the things that the group realized needed significantly
more attention in order to come to a conclusion while updating the more attention in order to come to a conclusion, while updating the
key takeaways in real time. key takeaways in real time.
1. Some, but not all, saw NETCONF for configuration as being 1. Some, but not all, saw NETCONF for configuration as being
successful in some larger-scale deployments. Although this successful in some larger-scale deployments. Although this
statement is true in some contexts, many operators indicated statement is true in some contexts, many operators indicated
their need to rely on other forms of access to manage their their need to rely on other forms of access to manage their
networks, such as CLIs, Expect scripts, and other protocols. networks, such as CLIs, Expect scripts, and other protocols.
2. Many hope that NETCONF, and RESTCONF more specifically, will 2. Many hope that NETCONF, and RESTCONF more specifically, will
continue to move to a long-term configuration management continue to move to a long-term configuration management
skipping to change at page 15, line 37 skipping to change at line 679
keep pace with the device deployment pace. keep pace with the device deployment pace.
While many other items also need further discussion, this list While many other items also need further discussion, this list
specifically includes those that were actively discussed during the specifically includes those that were actively discussed during the
live editing session in the workshop. live editing session in the workshop.
4. Not Covered in the Workshop 4. Not Covered in the Workshop
Some topics absent from the workshop discussions included tooling Some topics absent from the workshop discussions included tooling
(what is currently missing) and strategies to support tool (what is currently missing) and strategies to support tool
development (who pays, who develops, who maintains). The primary development (who pays, who develops, and who maintains). The primary
focus of the discussion was on YANG and NETCONF/RESTCONF, while focus of the discussion was on YANG and NETCONF/RESTCONF, while
several other network management protocols and techniques currently several other network management protocols and techniques currently
used received less attention during the workshop. The discussion used received less attention. During the workshop, the discussion on
during the workshop on possible future directions prioritized possible future directions prioritized improving existing solutions
improving existing solutions rather than introducing entirely new rather than introducing entirely new ones (such as enabling
ones (such as enabling intelligence in network management). intelligence in network management).
5. Security Considerations 5. Security Considerations
This document is a workshop report and does not impact the security This document is a workshop report and does not impact the security
of the Internet. of the Internet.
6. IANA Considerations 6. IANA Considerations
This document does not have any IANA considerations. This document has no IANA actions.
[Note to the RFC Editor: Please remove this section during
publication.]
7. Informative References 7. Informative References
[BLESS] Bless, R., "An Invariant for Future Resilient Network [BLESS] Bless, R., "An Invariant for Future Resilient Network
Management Operations", November 2024, Management Operations", November 2024,
<https://www.ietf.org/slides/slides-nemopsws-paper-an- <https://www.ietf.org/slides/slides-nemopsws-paper-an-
invariant-for-future-resilient-network-management- invariant-for-future-resilient-network-management-
operations-00.pdf>. operations-00.pdf>.
[BORMANN] Bormann, C., "CORECONF: Managing IoT Devices with YANG [BORMANN] Bormann, C., "CORECONF: Managing IoT Devices with YANG
Models", November 2024, <https://www.ietf.org/slides/ Models", November 2024, <https://www.ietf.org/slides/
slides-nemopsws-paper-coreconf-managing-iot-devices-with- slides-nemopsws-paper-coreconf-managing-iot-devices-with-
yang-models-00.pdf>. yang-models-00.pdf>.
[CLAISE] Claise, B., Graf, T., Keller, H., Voyer, D., Lucente, P., [CLAISE] Claise, B., Graf, T., Keller, H., Voyer, D., Lucente, P.,
Lopez, D., Martinez-Casanueva, I., Peters, B., Fasano, P., Lopez, D., Martinez-Casanueva, I. D., Peters, B., Fasano,
Ran, P., Cheng, W., and M. Mackey, "Knowledge Graph P., Ran, P., Cheng, W., and M. Mackey, "Knowledge Graph
Framework for Network Operations", November 2024, Framework for Network Operations", November 2024,
<https://www.ietf.org/slides/slides-nemopsws-paper- <https://www.ietf.org/slides/slides-nemopsws-paper-
knowledge-graph-framework-for-network-operations-00.pdf>. knowledge-graph-framework-for-network-operations-00.pdf>.
[CONTRERAS] [CONTRERAS]
Boucadair, M., Contreras, L. M., Gonzalez de Dios, O., Boucadair, M., Contreras, L. M., Gonzalez de Dios, O.,
Graf, T., Rahman, R., and L. Tailhardat, "RFC 3535, 20 Graf, T., Rahman, R., and L. Tailhardat, "RFC 3535, 20
Years Later: An Update of Operators Requirements on Years Later: An Update of Operators Requirements on
Network Management Protocols and Modelling", October 2024, Network Management Protocols and Modelling", October 2024,
<https://www.ietf.org/slides/slides-nemopsws-paper- <https://www.ietf.org/slides/slides-nemopsws-paper-
rfc3535-years-later-an-update-of-operators-requirements- rfc3535-years-later-an-update-of-operators-requirements-
on-network-management-protocols-and-modelling-00.pdf>. on-network-management-protocols-and-modelling-00.pdf>.
[CORECONF] Veillette, M., Van der Stok, P., Pelov, A., Bierman, A.,
and C. Bormann, "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 [ECKERT] Eckert, T. and M. Richardson, "Resilient Remote
Manageability of Wide-Area Network Infrastructures", Manageability of Wide-Area Network Infrastructures",
November 2024, <https://www.ietf.org/slides/slides- November 2024, <https://www.ietf.org/slides/slides-
nemopsws-paper-resilient-remote-managability-of-wide-area- nemopsws-paper-resilient-remote-managability-of-wide-area-
network-infrastructures-00.pdf>. network-infrastructures-00.pdf>.
[FARRER] Larsson, K., Lambrechts, K., and I. Farrer, "RFC3535, 20 [FARRER] Larsson, K., Lambrechts, K., and I. Farrer, "RFC3535, 20
Years Later from an Operator's Perspective (Deutsche Years Later from an Operator's Perspective (Deutsche
Telekom)", November 2024, <https://www.ietf.org/slides/ Telekom)", November 2024, <https://www.ietf.org/slides/
slides-nemopsws-paper-rfc3535-years-later-from-an- slides-nemopsws-paper-rfc3535-years-later-from-an-
operators-perspective-deutsche-telekom-00.pdf>. operators-perspective-deutsche-telekom-00.pdf>.
[FOROUGHI] Foroughi, P. and L. Ciavaglia, "Projecting Data Mesh to [FOROUGHI] Foroughi, P. and L. Ciavaglia, "Projecting Data Mesh to
Model-driven Telemetry: A Path to Data Ecosystem’s Model-driven Telemetry: A Path to Data Ecosystem's
Management Operations", November 2024, Management Operations", November 2024,
<https://www.ietf.org/slides/slides-nemopsws-paper- <https://www.ietf.org/slides/slides-nemopsws-paper-
projecting-data-mesh-to-model-driven-telemetry-a-path-to- projecting-data-mesh-to-model-driven-telemetry-a-path-to-
data-ecosystems-management-operations-00.pdf>. data-ecosystems-management-operations-00.pdf>.
[GIRALT] Contreras, L. M., Schott, R., Randriamasy, S., Yang, R., [GIRALT] Contreras, L. M., Schott, R., Randriamasy, S., Yang, R.,
and J. Ros-Giralt, "Towards a Unified Compute and and J. Ros-Giralt, "Towards a Unified Compute and
Communication Infrastructure for Application and Network Communication Infrastructure for Application and Network
Management", November 2024, <https://www.ietf.org/slides/ Management", November 2024, <https://www.ietf.org/slides/
slides-nemopsws-paper-towards-a-unified-compute-and- slides-nemopsws-paper-towards-a-unified-compute-and-
communication-infrastructure-for-application-and-network- communication-infrastructure-for-application-and-network-
management-00.pdf>. management-00.pdf>.
[GRAF] Graf, T., Keller, H., Voyer, D., Lucente, P., Claise, B., [GRAF] Graf, T., Keller, H., Voyer, D., Lucente, P., Claise, B.,
Wilton, R., Huang-Feng, A., and P. Francois, "Agile Wilton, R., Huang-Feng, A., and P. Francois, "Agile
Incremental Driven Development for Network Management", Incremental Driven Development for Network Management",
November 2024, <https://www.ietf.org/slides/slides- November 2024, <https://www.ietf.org/slides/slides-
nemopsws-paper-agile-incremental-driven-development-for- nemopsws-paper-agile-incremental-driven-development-for-
network-management-01.pdf>. network-management-01.pdf>.
[GUDI] Gudi, M., Pelov, A., Toutain, L., and J. Bonnin, "Evolving [GUDI] Gudi, M., Pelov, A., Toutain, L., and J. M. Bonnin,
Network Management Architecture: Integrating CORECONF with "Evolving Network Management Architecture: Integrating
NETCONF for Efficient Telemetry and Management", November CORECONF with NETCONF for Efficient Telemetry and
2024, <https://www.ietf.org/slides/slides-nemopsws-paper- Management", November 2024, <https://www.ietf.org/slides/
evolving-network-management-architecture-integrating- slides-nemopsws-paper-evolving-network-management-
coreconf-with-netconf-for-efficient-telemetry-and- architecture-integrating-coreconf-with-netconf-for-
management-00.pdf>. efficient-telemetry-and-management-00.pdf>.
[HARDAKER] Hardaker, W., "Lessons Learned from 30 Years of Net-SNMP", [HARDAKER] Hardaker, W., "Lessons Learned from 30 Years of Net-SNMP",
November 2024, <https://www.ietf.org/slides/slides- November 2024, <https://www.ietf.org/slides/slides-
nemopsws-paper-lessons-learned-from-30-years-of-net-snmp- nemopsws-paper-lessons-learned-from-30-years-of-net-snmp-
00.pdf>. 00.pdf>.
[I-D.ietf-core-comi]
Veillette, M., Van der Stok, P., Pelov, A., Bierman, A.,
and C. Bormann, "CoAP Management Interface (CORECONF)",
Work in Progress, Internet-Draft, draft-ietf-core-comi-20,
6 May 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-core-comi-20>.
[I-D.ietf-nmop-rfc3535-20years-later]
Boucadair, M., Contreras, L. M., de Dios, O. G., Graf, T.,
Rahman, R., and L. Tailhardat, "An Update of Operators
Requirements on Network Management Protocols and
Modelling", Work in Progress, Internet-Draft, draft-ietf-
nmop-rfc3535-20years-later-00, 7 August 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-nmop-
rfc3535-20years-later-00>.
[JIMENEZ] Jiménez, J., Mansfield, S., , Pesonen, M., Torvinen, V., [JIMENEZ] Jiménez, J., Mansfield, S., , Pesonen, M., Torvinen, V.,
and J. Karvonen, "Evolving Challenges and Solutions in and J. Karvonen, "Evolving Challenges and Solutions in
Network Management", November 2024, Network Management", November 2024,
<https://www.ietf.org/slides/slides-nemopsws-paper- <https://www.ietf.org/slides/slides-nemopsws-paper-
evolving-challenges-and-solutions-in-network-management- evolving-challenges-and-solutions-in-network-management-
00.pdf>. 00.pdf>.
[JIMENEZ-2] [JIMENEZ-2]
Jiménez, J., "Managing IoT Devices with LwM2M", November Jiménez, J., "Managing IoT Devices with LwM2M", November
2024, <https://www.ietf.org/slides/slides-nemopsws-paper- 2024, <https://www.ietf.org/slides/slides-nemopsws-paper-
managing-iot-devices-with-lwmm-00.pdf>. managing-iot-devices-with-lwmm-00.pdf>.
[KELLER] Warnke, N., Geib, R., Horneffer, M., and H. Keller, [KELLER] Warnke, N., Geib, R., Horneffer, M., and H. Keller,
"NEMOPS: RFC3535 and the forgotten word — Or Provisioning "NEMOPS: RFC3535 and the forgotten word - Or Provisioning
is only a subset of Network Management", November 2024, is only a subset of Network Management", November 2024,
<https://www.ietf.org/slides/slides-nemopsws-nemops- <https://www.ietf.org/slides/slides-nemopsws-nemops-
rfc3535-and-the-forgotten-word-00.pdf>. rfc3535-and-the-forgotten-word-00.pdf>.
[MARTINEZ] Martinez-Casanueva, I., "IAB NEMOPS Position Paper - [MARTINEZ] Martinez-Casanueva, I. D., "IAB NEMOPS Position Paper -
Telefonica", November 2024, <https://www.ietf.org/slides/ Telefonica", November 2024, <https://www.ietf.org/slides/
slides-nemopsws-paper-iab-nemops-position-paper- slides-nemopsws-paper-iab-nemops-position-paper-
telefonica-00.pdf>. telefonica-00.pdf>.
[NET-SNMP] "Net-SNMP", n.d., <http://www.net-snmp.org/>. [NET-SNMP] "Net-SNMP", <http://www.net-snmp.org/>.
[OP-REQ-NM]
Boucadair, M., Contreras, L. M., de Dios, O. G., 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-03, 20 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-nmop-
rfc3535-20years-later-03>.
[OPENCONFIG] [OPENCONFIG]
"OpenConfig", n.d., <https://www.openconfig.net/>. "OpenConfig", <https://www.openconfig.net/>.
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network
Management Workshop", RFC 3535, DOI 10.17487/RFC3535, May Management Workshop", RFC 3535, DOI 10.17487/RFC3535, May
2003, <https://www.rfc-editor.org/rfc/rfc3535>. 2003, <https://www.rfc-editor.org/info/rfc3535>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/rfc/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/rfc/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/rfc/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/rfc/rfc8309>. <https://www.rfc-editor.org/info/rfc8309>.
[RFC9196] Lengyel, B., Clemm, A., and B. Claise, "YANG Modules [RFC9196] Lengyel, B., Clemm, A., and B. Claise, "YANG Modules
Describing Capabilities for Systems and Datastore Update Describing Capabilities for Systems and Datastore Update
Notifications", RFC 9196, DOI 10.17487/RFC9196, February Notifications", RFC 9196, DOI 10.17487/RFC9196, February
2022, <https://www.rfc-editor.org/rfc/rfc9196>. 2022, <https://www.rfc-editor.org/info/rfc9196>.
[SCHARF] Scharf, M., "Network Management Challenges for IP-based [SCHARF] Scharf, M., "Network Management Challenges for IP-based
Cyber-Physical Networks", November 2024, Cyber-Physical Networks", November 2024,
<https://www.ietf.org/slides/slides-nemopsws-paper- <https://www.ietf.org/slides/slides-nemopsws-paper-
network-management-challenges-for-ip-based-cyber-physical- network-management-challenges-for-ip-based-cyber-physical-
networks-00.pdf>. networks-00.pdf>.
[SCHONWALDER] [SCHONWALDER]
Schönwälder, J., "Composable, Declarative, Reproducible, Schönwälder, J., "Composable, Declarative, Reproducible,
Verifiable Network and Service Configurations", November Verifiable Network and Service Configurations", November
skipping to change at page 20, line 20 skipping to change at line 885
[WILTON] Wilton, R. and N. Corran, "Device Network Management - [WILTON] Wilton, R. and N. Corran, "Device Network Management -
Current Status, and Future Direction", November 2024, Current Status, and Future Direction", November 2024,
<https://datatracker.ietf.org/doc/slides-nemopsws-paper- <https://datatracker.ietf.org/doc/slides-nemopsws-paper-
device-network-management-current-status-and-future- device-network-management-current-status-and-future-
direction/>. direction/>.
Appendix A. Operator Feedback Appendix A. Operator Feedback
This section compiles the operator feedback gathered through outreach This section compiles the operator feedback gathered through outreach
and information gathering at various operational venues (RIPE, NANOG, and information gathering at various operational venues (RIPE, NANOG,
APRICOT, LACNIC, AutoConn, etc). The PC synthesized this input and APRICOT, LACNIC, AutoConn, etc.). The PC synthesized this input and
presented it during the workshop (see Section 3.2.2). presented it during the workshop (see Section 3.2.2).
A.1. General A.1. General
1. In network deployments, operations are typically at the bottom of 1. In network deployments, operations are typically at the bottom of
the ladder. It's the most squeezed for time and resources. the ladder. It's the most squeezed for time and resources.
Network engineers are not typically seasoned developers. The Network engineers are not typically seasoned developers. The
development of needed in-house tools often takes years to development of needed in-house tools often takes years to
develop. There is a need for tools that are easy to use and just develop. There is a need for tools that are easy to use and just
work. work.
2. The vast majority of smaller operators use CLI and open source to 2. The vast majority of smaller operators use CLI and open source to
manage their networks. manage their networks.
3. There is debate fatigue. The protocol/model debate is a 3. There is debate fatigue. The protocol/model debate is a
recurring conversation. The problem isn’t going away. recurring conversation. The problem isn't going away.
4. It was suggested that other domains (e.g., K8N/automation) are 4. It was suggested that other domains (e.g., K8N/automation) are
years ahead of the current network engineering stack. years ahead of the current network engineering stack.
5. Support for multiple friendly, stable and feature-rich libraries 5. Support for multiple friendly, stable, and feature-rich libraries
for programming languages is needed. Many DevOps routines use for programming languages is needed. Many DevOps routines use
shell scripts, while others use a high-level programming shell scripts, while others use a high-level programming
language. In any case, on the client side, multiple programming language. In any case, on the client side, multiple programming
languages are used. languages are used.
6. Screen scraping is unfortunately necessary and painful. This 6. Screen scraping is unfortunately necessary and painful. This
most often occurs when interacting with a device having only a most often occurs when interacting with a device that only has a
CLI. CLI.
7. It was noted that there could be an outreach to Academia to 7. It was noted that there could be an outreach to Academia to
establish programs to teach lessons using modern management establish programs to teach lessons using modern management
stacks, and then a new generation of engineers could help to stacks, and then a new generation of engineers could help to
improve tooling and automation, with university (and/or IETF) improve tooling and automation, with university (and/or IETF)
hackathons. hackathons.
A.2. Data Models A.2. Data Models
1. In some network deployments, the focus is solely on service-level 1. In some network deployments, the focus is solely on service-level
models, such that device-level protocols and device-level models models, such that device-level protocols and device-level models
are unimportant. This assumes the existence of a device are unimportant. This assumes the existence of a device
adaptation layer to transcode service-level models to device- adaptation layer to transcode service-level models to device-
level models and conform to the device-specific protocol. level models and conform to the device-specific protocol.
2. There is a need for solutions to not hide vendor-specific 2. There is a need for solutions to not hide vendor-specific
parameters. Currently, vendors compete by differentiating their parameters. Currently, vendors compete by differentiating their
offerings in unique ways. The reason why an Operator may choose offerings in unique ways. The reason why an operator may choose
a particular vendor is because of its differentiating features. a particular vendor is because of its differentiating features.
Whilst standard models enable conformance, they must not hide the Whilst standard models enable conformance, they must not hide the
vendor-specific parameters. YANG deviations are a partial vendor-specific parameters. YANG deviations are a partial
solution to not hiding vendor knobs. solution to not hiding vendor knobs.
3. It was emphasized that streaming telemetry requires picking a 3. It was emphasized that streaming telemetry requires picking a
model and sticking with it. It is quite a commitment, and the model and sticking with it. It is quite a commitment, and the
current environment makes the decision harder. current environment makes the decision harder.
4. It was noted that IETF's focus should be on defining abstract/ 4. It was noted that IETF's focus should be on defining abstract/
service-level data models since it is the only thing the service-level data models since it is the only thing the
community may ever agree on. community may ever agree on.
5. It was noted that navigating standard models can be difficult. 5. It was noted that navigating standard models can be difficult. A
The Network Engineer knows the vendor CLI commands but has network engineer knows the vendor CLI commands but has trouble
trouble locating the corresponding leaves in the standard YANG locating the corresponding leaves in the standard YANG models
models defined by SDOs. defined by Standards Development Organizations (SDOs).
6. There was a wish that the IETF and OpenConfig models would merge. 6. There was a wish that the IETF and OpenConfig models would merge.
Appendix B. Key Recommendations from Operator Feedback Appendix B. Key Recommendations from Operator Feedback
Various recommendations were made by the operators during the Various recommendations were made by the operators during the
outreach events. The key ones presented during the workshop were outreach events. The key ones presented during the workshop were
(there were a lot more collected): (note that there were a lot more collected):
* Everyone: Continue to focus on model-driven management as a means * Everyone: Continue to focus on model-driven management as a means
to achieve automation. to achieve automation.
* SDOs: Re-introduce “running code” as part of the specification * SDOs: Re-introduce "running code" as part of the specification
verification process. verification process.
* Operators: Be actively involved with the “running code” efforts. * Operators: Be actively involved with the "running code" efforts.
* IETF: Recommend a solution stack for common use cases. * IETF: Recommend a solution stack for common use cases.
* Technology Ambassadors: Evangelize the recommended solution stack * Technology Ambassadors: Evangelize the recommended solution stack
for common cases. for common cases.
* Vendors: Support the recommended approach to the solution stack * Vendors: Support the recommended approach to the solution stack
for common cases. for common cases.
Appendix C. Position Papers Appendix C. Position Papers
20 position papers were submitted to the workshop call for papers. 20 position papers were submitted to the workshop call for papers.
All papers are available at All papers are available at
https://datatracker.ietf.org/group/nemopsws/materials/ <https://datatracker.ietf.org/group/nemopsws/materials/>.
(https://datatracker.ietf.org/group/nemopsws/materials/).
This is the list of all papers: This is the list of all papers:
* J Schönwälder: Composable, Declarative, Reproducible, Verifiable * J. Schönwälder: Composable, Declarative, Reproducible, Verifiable
Network and Service Configurations [SCHONWALDER] Network and Service Configurations [SCHONWALDER]
* K. Larsson, K. Lambrechts, and I. Farrer: RFC3535, 20 Years * K. Larsson, K. Lambrechts, and I. Farrer: RFC3535, 20 Years Later
Later from an Operator’s Perspective (Deutsche Telekom) [FARRER] from an Operator's Perspective (Deutsche Telekom) [FARRER]
* W. Hardaker: Lessons Learned from 30 Years of Net-SNMP [HARDAKER] * W. Hardaker: Lessons Learned from 30 Years of Net-SNMP [HARDAKER]
* C. Bormann: CORECONF: Managing IoT Devices with YANG Models * C. Bormann: CORECONF: Managing IoT Devices with YANG Models
[BORMANN] [BORMANN]
* R. Shakir: Rethinking Standardisation of Network Management * R. Shakir: Rethinking Standardisation of Network Management
[SHAKIR] [SHAKIR]
* N. Warnke, R. Geib, M. Horneffer, and H. Keller: NEMOPS: * N. Warnke, R. Geib, M. Horneffer, and H. Keller: NEMOPS: RFC3535
RFC3535 and the forgotten word — Or Provisioning is only a subset and the forgotten word - Or Provisioning is only a subset of
of Network Management [KELLER] Network Management [KELLER]
* J. Jiménez, S. Mansfield, R. Rodriguez A., M. Pesonen, V. * J. Jiménez, S. Mansfield, R. Rodriguez A., M. Pesonen,
Torvinen, and J. Karvonen: Evolving Challenges and Solutions in V. Torvinen, and J. Karvonen: Evolving Challenges and Solutions in
Network Management [JIMENEZ] Network Management [JIMENEZ]
* M. Boucadair, L. M. Contreras, O. Gonzalez de Dios, T. Graf, * M. Boucadair, LM. Contreras, O. Gonzalez de Dios, T. Graf,
R. Rahman, and L. Tailhardat: RFC 3535, 20 Years Later: An R. Rahman, and L. Tailhardat: RFC 3535, 20 Years Later: An Update
Update of Operators Requirements on Network Management Protocols of Operators Requirements on Network Management Protocols and
and Modelling [CONTRERAS] Modelling [CONTRERAS]
* T. Graf, H. Keller, D. Voyer, P. Lucente, B. Claise, R. * T. Graf, H. Keller, D. Voyer, P. Lucente, B. Claise, R. Wilton,
Wilton, A. Huang-Feng, and P. Francois: Agile Incremental Driven A. Huang-Feng, and P. Francois: Agile Incremental Driven
Development for Network Management [GRAF] Development for Network Management [GRAF]
* B. Claise, T. Graf, H. Keller, D. Voyer, P. Lucente, D. * B. Claise, T. Graf, H. Keller, D. Voyer, P. Lucente, D. Lopez,
Lopez, I. D. Martinez-Casanueva, B. Peters, P. Fasano, P. I. D. Martinez-Casanueva, B. Peters, P. Fasano, P. Ran, W. Cheng,
Ran, W. Cheng, and M. Mackey: Knowledge Graph Framework for and M. Mackey: Knowledge Graph Framework for Network Operations
Network Operations [CLAISE] [CLAISE]
* K. Watsen: Four Thoughts for How to Improve Network Management * K. Watsen: Four Thoughts for How to Improve Network Management for
for Operators [WATSEN] Operators [WATSEN]
* R. Wilton and N. Corran: Device Network Management: Current * R. Wilton and N. Corran: Device Network Management: Current Status
Status and Future Direction [WILTON] and Future Direction [WILTON]
* M. Gudi, A. Pelov, L. Toutain, and J.-M. Bonnin: Evolving * M. Gudi, A. Pelov, L. Toutain, and J. M. Bonnin: Evolving Network
Network Management Architecture: Integrating CORECONF with NETCONF Management Architecture: Integrating CORECONF with NETCONF for
for Efficient Telemetry and Management [GUDI] Efficient Telemetry and Management [GUDI]
* P. Foroughi and L. Ciavaglia: Projecting Data Mesh to Model- * P. Foroughi and L. Ciavaglia: Projecting Data Mesh to Model-driven
driven Telemetry: A Path to Data Ecosystem’s Management Operations Telemetry: A Path to Data Ecosystem's Management Operations
[FOROUGHI] [FOROUGHI]
* I. D. Martinez-Casanueva: IAB NEMOPS Position Paper - Telefonica * I. D. Martinez-Casanueva: IAB NEMOPS Position Paper - Telefonica
[MARTINEZ] [MARTINEZ]
* J. Jiménez: Managing IoT Devices with LwM2M [JIMENEZ-2] * J. Jiménez: Managing IoT Devices with LwM2M [JIMENEZ-2]
* L. M. Contreras, R. Schott, S. Randriamasy, R. Yang, and J. * LM. Contreras, R. Schott, S. Randriamasy, R. Yang, and J. Ros-
Ros-Giralt: Towards a Unified Compute and Communication Giralt: Towards a Unified Compute and Communication Infrastructure
Infrastructure for Application and Network Management [GIRALT] for Application and Network Management [GIRALT]
* T. Eckert and M. Richardson: Resilient Remote Manageability of * T. Eckert and M. Richardson: Resilient Remote Manageability of
Wide-Area Network Infrastructures [ECKERT] Wide-Area Network Infrastructures [ECKERT]
* R. Bless: An Invariant for Future Resilient Network Management * R. Bless: An Invariant for Future Resilient Network Management
Operations [BLESS] Operations [BLESS]
* M. Scharf: Network Management Challenges for IP-based Cyber- * M. Scharf: Network Management Challenges for IP-based Cyber-
Physical Networks [SCHARF] Physical Networks [SCHARF]
Appendix D. Workshop Participants Appendix D. Workshop Participants
The workshop participants were Alex Huang, Alexander Clemm, Alexander The workshop participants were Alex Huang, Alexander Clemm, Alexander
Pelov, Benoit Claise, Boris Khasanov, Brad Peters, Carsten Bormann, Pelov, Benoît Claise, Boris Khasanov, Brad Peters, Carsten Bormann,
Chongfeng Xie, Cindy Morgan, Dan Voyer, Darren Loher, Dean Chongfeng Xie, Cindy Morgan, Dan Voyer, Darren Loher, Dean
Bogdanovic, Dean Bogdanović, Dhruv Dhody, Diego Lopez, Ebben Aries, Bogdanovic, Dean Bogdanović, Dhruv Dhody, Diego Lopez, Ebben Aries,
Frank (Chong Feng), Holger Keller, Ian Farrer, Jaime Jimenez, James Frank (Chong Feng), Holger Keller, Ian Farrer, Jaime Jimenez, James
Cumming, Janne Karvonen, Jason Sterne, Jiaming Ye, Jinming Li, John Cumming, Janne Karvonen, Jason Sterne, Jiaming Ye, Jinming Li, John
Carson, Julien Maisonneuve, Jürgen Schönwälder, Kent Watsen, Kris Carson, Julien Maisonneuve, Jürgen Schönwälder, Kent Watsen, Kris
Lambrechts, Kristian Larsson, Laurent Ciavaglia, Laurent Toutain, Liz Lambrechts, Kristian Larsson, Laurent Ciavaglia, Laurent Toutain, Liz
Flynn, Luis M. Contreras, Mahesh Jethanandani, Manoj Gudi, Martin Flynn, Luis M. Contreras, Mahesh Jethanandani, Manoj Gudi, Martin
Horneffer, Matthew Bocci, Med Boucadair, Michael Mackey, Michael Horneffer, Matthew Bocci, Med Boucadair, Michael Mackey, Michael
Richardson, Michael Scharf, Mikko Pesonen, Nacho Dominguez, Naveen Richardson, Michael Scharf, Mikko Pesonen, Nacho Dominguez, Naveen
Achyuta, Nick Corran, Nils Warnke, Oscar Gonzalez de Dios, Paolo Achyuta, Nick Corran, Nils Warnke, Oscar Gonzalez de Dios, Paolo
Lucente, Parisa Foroughi, Per Andersson, Phil Shafer, Qin Wu, Qiufang Lucente, Parisa Foroughi, Per Andersson, Phil Shafer, Qin Wu, Qiufang
Ma, Raquel Rodriguez, Reshad Rahman, Rob Shakir, Rob Wilton, Roland Ma, Raquel Rodriguez, Reshad Rahman, Rob Shakir, Rob Wilton, Roland
Bless, Roland Schott, Rüdiger Geib, Rui Zhuang, Ruibo Han, Sabine Bless, Roland Schott, Rüdiger Geib, Rui Zhuang, Ruibo Han, Sabine
Randriamasy, Scott Mansfield, Scott Robohn, Shengnan Yue, Suresh Randriamasy, Scott Mansfield, Scott Robohn, Shengnan Yue, Suresh
Krishnan, Thomas Graf, Toerless Eckert, Wangbo, Warren Kumari, Wes Krishnan, Thomas Graf, Toerless Eckert, Wangbo, Warren Kumari, Wes
Hardaker, Wim Henderickx, Xue Yang, Y. Richard Yang, Yangbo, Yisong Hardaker, Wim Henderickx, Xue Yang, Y. Richard Yang, Yangbo, Yisong
Liu, and Zhenqiang Li. Liu, and Zhenqiang Li.
Appendix E. Workshop Program Committee Appendix E. Workshop Program Committee
The workshop program committee members were Wes Hardaker (co-chair), The workshop program committee members were Wes Hardaker (co-chair),
Dhruv Dhody (co-chair), Qin Wu, Suresh Krishnan, Benoît Claise, Dhruv Dhody (co-chair), Qin Wu, Suresh Krishnan, Benoît Claise,
Mohamed Boucadair, Mahesh Jethanandani, Kent Watsen, and Warren Mohamed Boucadair, Mahesh Jethanandani, Kent Watsen, and Warren
Kumari. Kumari.
IAB Members at the Time of Approval IAB Members at the Time of Approval
 End of changes. 123 change blocks. 
313 lines changed or deleted 302 lines changed or added

This html diff was produced by rfcdiff 1.48.