rfc9968.original.md   rfc9968.md 
--- ---
title: "Report from the IAB Workshop on the Next Era of Network Management Operations (NEMOPS)" title: "Report from the IAB Workshop on the Next Era of Network Management Operations (NEMOPS)"
abbrev: "NEMOPS Workshop Report" abbrev: "NEMOPS Workshop Report"
category: info category: info
docname: draft-iab-nemops-workshop-report-latest docname: draft-iab-nemops-workshop-report-latest
submissiontype: IAB submissiontype: IAB
number: ipr: trust200902
date: number: 9968
updates:
obsoletes:
date: 2026-04
consensus: true consensus: true
pi: [toc, symrefs, sortrefs]
v: 3 v: 3
lang: en
keyword: keyword:
- YANG - YANG
- NETCONF - NETCONF
- RESTCONF - RESTCONF
- NMOPS - NMOPS
- RFC3535 - RFC3535
venue:
github: "intarchboard/draft-iab-nemops-workshop-report"
latest: "https://intarchboard.github.io/draft-iab-nemops-workshop-report/draft-iab-
nemops-workshop-report.html"
author: author:
- -
fullname: "Wes Hardaker" fullname: "Wes Hardaker"
email: "hardaker@isi.edu" email: "hardaker@isi.edu"
- -
fullname: "Dhruv Dhody" fullname: "Dhruv Dhody"
email: "dd@dhruvdhody.com" email: "dd@dhruvdhody.com"
normative: normative:
informative: informative:
RFC3535: RFC3535:
RFC6241: RFC6241:
RFC7950: RFC7950:
RFC8040: RFC8040:
RFC8309: RFC8309:
RFC9196: RFC9196:
I-D.ietf-core-comi: I-D.ietf-core-comi:
display: CORECONF
I-D.ietf-nmop-rfc3535-20years-later: I-D.ietf-nmop-rfc3535-20years-later:
display: OP-REQ-NM
SURVEY: SURVEY:
target: https://ietf.iad1.qualtrics.com/jfe/form/SV_9vQxBRiZqDntarc target: https://ietf.iad1.qualtrics.com/jfe/form/SV_9vQxBRiZqDntarc
title: Next Era of Network Management Operations (NEMOPS) workshop survey title: Next Era of Network Management Operations (NEMOPS) workshop survey
date: October 2024 date: October 2024
SURVEY-INSIGHTS: SURVEY-INSIGHTS:
target: https://datatracker.ietf.org/meeting/interim-2024-nemopsws-02/materials/s lides-interim-2024-nemopsws-02-sessa-6-insights-from-operator-outreach-survey-03.pdf target: https://datatracker.ietf.org/meeting/interim-2024-nemopsws-02/materials/s lides-interim-2024-nemopsws-02-sessa-6-insights-from-operator-outreach-survey-03.pdf
title: Insights from Operator Survey & Outreach title: Insights from Operator Survey & Outreach
date: December 2024 date: December 2024
SCHONWALDER: SCHONWALDER:
target: https://www.ietf.org/slides/slides-nemopsws-paper-composable-declarative- reproducible-verifiable-network-and-service-configurations-00.pdf target: https://www.ietf.org/slides/slides-nemopsws-paper-composable-declarative- reproducible-verifiable-network-and-service-configurations-00.pdf
skipping to change at line 80 skipping to change at line 86
target: https://www.ietf.org/slides/slides-nemopsws-paper-lessons-learned-from-30 -years-of-net-snmp-00.pdf target: https://www.ietf.org/slides/slides-nemopsws-paper-lessons-learned-from-30 -years-of-net-snmp-00.pdf
title: Lessons Learned from 30 Years of Net-SNMP title: Lessons Learned from 30 Years of Net-SNMP
author: author:
- -
ins: W. Hardaker ins: W. Hardaker
name: Wes Hardaker name: Wes Hardaker
date: November 2024 date: November 2024
NET-SNMP: NET-SNMP:
target: http://www.net-snmp.org/ target: http://www.net-snmp.org/
title: Net-SNMP title: Net-SNMP
date: false
BORMANN: BORMANN:
target: https://www.ietf.org/slides/slides-nemopsws-paper-coreconf-managing-iot-d evices-with-yang-models-00.pdf target: https://www.ietf.org/slides/slides-nemopsws-paper-coreconf-managing-iot-d evices-with-yang-models-00.pdf
title: "CORECONF: Managing IoT Devices with YANG Models" title: "CORECONF: Managing IoT Devices with YANG Models"
author: author:
- -
ins: C. Bormann ins: C. Bormann
name: Carsten Bormann name: Carsten Bormann
date: November 2024 date: November 2024
SHAKIR: SHAKIR:
target: https://www.ietf.org/slides/slides-nemopsws-paper-rethinking-standardisat ion-of-network-management-00.pdf target: https://www.ietf.org/slides/slides-nemopsws-paper-rethinking-standardisat ion-of-network-management-00.pdf
title: Rethinking Standardisation of Network Management title: Rethinking Standardisation of Network Management
author: author:
- -
ins: R. Shakir ins: R. Shakir
name: Rob Shakir name: Rob Shakir
date: September 2024 date: September 2024
OPENCONFIG: OPENCONFIG:
target: https://www.openconfig.net/ target: https://www.openconfig.net/
title: OpenConfig title: OpenConfig
date: false
KELLER: KELLER:
target: https://www.ietf.org/slides/slides-nemopsws-nemops-rfc3535-and-the-forgot ten-word-00.pdf target: https://www.ietf.org/slides/slides-nemopsws-nemops-rfc3535-and-the-forgot ten-word-00.pdf
title: "NEMOPS: RFC3535 and the forgotten word — Or Provisioning is only a subset of Network Management" title: "NEMOPS: RFC3535 and the forgotten word - Or Provisioning is only a subset of Network Management"
author: author:
- -
ins: N. Warnke ins: N. Warnke
name: Nils Warnke name: Nils Warnke
- -
ins: R. Geib ins: R. Geib
name: Rüdiger Geib name: Rüdiger Geib
- -
ins: M. Horneffer ins: M. Horneffer
name: Martin Horneffer name: Martin Horneffer
skipping to change at line 214 skipping to change at line 222
- -
ins: D. Voyer ins: D. Voyer
name: Dan Voyer name: Dan Voyer
- -
ins: P. Lucente ins: P. Lucente
name: Paolo Lucente name: Paolo Lucente
- -
ins: D. Lopez ins: D. Lopez
name: Diego Lopez name: Diego Lopez
- -
ins: I. Martinez-Casanueva ins: I. D. Martinez-Casanueva
name: Ignacio Dominguez Martinez-Casanueva name: Ignacio Dominguez Martinez-Casanueva
- -
ins: B. Peters ins: B. Peters
name: Brad Peters name: Brad Peters
- -
ins: P. Fasano ins: P. Fasano
name: Paolo Fasano name: Paolo Fasano
- -
ins: P. Ran ins: P. Ran
name: Pang Ran name: Pang Ran
skipping to change at line 265 skipping to change at line 273
- -
ins: M. Gudi ins: M. Gudi
name: Manoj Gudi name: Manoj Gudi
- -
ins: A. Pelov ins: A. Pelov
name: Alexander Pelov name: Alexander Pelov
- -
ins: L. Toutain ins: L. Toutain
name: Laurent Toutain name: Laurent Toutain
- -
ins: J. Bonnin ins: J. M. Bonnin
name: Jean-Marie Bonnin name: Jean-Marie Bonnin
date: November 2024 date: November 2024
FOROUGHI: FOROUGHI:
target: https://www.ietf.org/slides/slides-nemopsws-paper-projecting-data-mesh-to -model-driven-telemetry-a-path-to-data-ecosystems-management-operations-00.pdf target: https://www.ietf.org/slides/slides-nemopsws-paper-projecting-data-mesh-to -model-driven-telemetry-a-path-to-data-ecosystems-management-operations-00.pdf
title: "Projecting Data Mesh to Model-driven Telemetry: A Path to Data Ecosystem’ s Management Operations" title: "Projecting Data Mesh to Model-driven Telemetry: A Path to Data Ecosystem' s Management Operations"
author: author:
- -
ins: P. Foroughi ins: P. Foroughi
name: Parisa Foroughi name: Parisa Foroughi
- -
ins: L. Ciavaglia ins: L. Ciavaglia
name: Laurent Ciavaglia name: Laurent Ciavaglia
date: November 2024 date: November 2024
MARTINEZ: MARTINEZ:
target: https://www.ietf.org/slides/slides-nemopsws-paper-iab-nemops-position-pap er-telefonica-00.pdf target: https://www.ietf.org/slides/slides-nemopsws-paper-iab-nemops-position-pap er-telefonica-00.pdf
title: "IAB NEMOPS Position Paper - Telefonica" title: "IAB NEMOPS Position Paper - Telefonica"
author: author:
- -
ins: I. Martinez-Casanueva ins: I. D. Martinez-Casanueva
name: Ignacio Dominguez Martinez-Casanueva name: Ignacio Dominguez Martinez-Casanueva
date: November 2024 date: November 2024
JIMENEZ-2: JIMENEZ-2:
target: https://www.ietf.org/slides/slides-nemopsws-paper-managing-iot-devices-wi th-lwmm-00.pdf target: https://www.ietf.org/slides/slides-nemopsws-paper-managing-iot-devices-wi th-lwmm-00.pdf
title: Managing IoT Devices with LwM2M title: Managing IoT Devices with LwM2M
author: author:
- -
ins: J. Jiménez ins: J. Jiménez
name: Jaime Jiménez name: Jaime Jiménez
date: November 2024 date: November 2024
skipping to change at line 342 skipping to change at line 350
name: Roland Bless name: Roland Bless
date: November 2024 date: November 2024
SCHARF: SCHARF:
target: https://www.ietf.org/slides/slides-nemopsws-paper-network-management-chal lenges-for-ip-based-cyber-physical-networks-00.pdf target: https://www.ietf.org/slides/slides-nemopsws-paper-network-management-chal lenges-for-ip-based-cyber-physical-networks-00.pdf
title: Network Management Challenges for IP-based Cyber-Physical Networks title: Network Management Challenges for IP-based Cyber-Physical Networks
author: author:
- -
ins: M. Scharf ins: M. Scharf
name: Michael Scharf name: Michael Scharf
date: November 2024 date: November 2024
--- abstract --- abstract
The "Next Era of Network Management Operations (NEMOPS)" workshop was convened by the Internet Architecture Board (IAB) from December 3-5, 2024, as a three-day online mee ting. It builds on a previous 2002 workshop, the outcome of which was documented in R FC 3535, identifying 14 operator requirements for consideration in future network man agement protocol design and related data models, along with some recommendations for the IETF. Much has changed in the Internet’s operation and technological foundations since then. The NEMOPS workshop reviewed the past outcomes and discussed any operatio nal barriers that prevented these technologies from being widely implemented. With th e industry, network operators and protocol engineers working in collaboration, the wo rkshop developed a suggested plan of action and network management recommendations fo r the IETF and IRTF. Building on RFC 3535, this document provides the report of the f ollow-up IAB workshop on Network Management. The "Next Era of Network Management Operations (NEMOPS)" workshop was convened by the Internet Architecture Board (IAB) from December 3-5, 2024 as a three-day online meet ing. It builds on a previous 2002 workshop, the outcome of which was documented in RF C 3535, identifying 14 operator requirements for consideration in future network mana gement protocol design and related data models, along with some recommendations for t he IETF. Much has changed in the Internet's operation and technological foundations s ince then. The NEMOPS workshop reviewed the past outcomes and discussed any operation al barriers that prevented these technologies from being widely implemented. With the industry, network operators and protocol engineers working in collaboration, the wor kshop developed a suggested plan of action and network management recommendations for the IETF and IRTF. Building on RFC 3535, this document provides the report of the fo llow-up IAB workshop on network management.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do no t necessarily reflect IAB views and positions. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do no t necessarily reflect IAB views and positions.
--- middle --- middle
# Introduction # Introduction
<!-- Reference review notes:
* WiPs
[I-D.boucadair-nmop-rfc3535-20years-later]
draft-ietf-nmop-rfc3535-20years-later-01
IESG State: I-D Exists as of 12/24/25
[I-D.ietf-core-comi]
draft-ietf-core-comi-20
IESG State: I-D Expired as of 12/24/25
Note: this I-D reference is missing the editor roles. They will need to be added
in the XML (see "final conversion AQ").
-->
<!-- [rfced] FYI - We will do the following when we convert the file to RFCXML:
- The BibXML entry for [I-D.ietf-core-comi] is missing the "editor" roles. We will
add this accordingly.
- The reference entry for [Jimenez] is missing the author name "Raquel Rodriguez A".
We will add this accordingly.
- Luis M. Contreras prefers his name to be displayed as "LM. Contreras" when
abbreviated. We will update his name accordingly in the reference entries for
[CONTRERAS], [GIRALT], and [OP-REQ-NM].
-->
The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions f or the Internet architecture. This long-term planning function of the IAB is complem entary to the ongoing engineering efforts performed by working groups of the Internet Engineering Task Force (IETF). The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions f or the Internet architecture. This long-term planning function of the IAB is complem entary to the ongoing engineering efforts performed by working groups of the Internet Engineering Task Force (IETF).
The IAB organized a workshop in 2002 to establish a dialog between network operators and protocol developers, and to guide the IETF's work on network management protocols . The outcome of that workshop was documented in the "Overview of the 2002 IAB Networ k Management Workshop" {{RFC3535}}, which identified 14 operator requirements and 11 recommendations for consideration in future network management protocol design and re lated data models within the IETF. The IAB organized a workshop in 2002 to establish a dialog between network operators and protocol developers and to guide the IETF's work on network management protocols. The outcome of that workshop was documented in the "Overview of the 2002 IAB Network Management Workshop" {{RFC3535}}, which identified 14 operator requirements and 11 r ecommendations for consideration in future network management protocol design and rel ated data models within the IETF.
Those requirements were instrumental in developing the NETCONF protocol (in the NETCO NF Working Group) {{RFC6241}}, the associated YANG data modeling language (in the NET MOD Working Group) {{RFC7950}}, RESTCONF {{RFC8040}}, and most recently CORECONF {{I- D.ietf-core-comi}}. Those requirements were instrumental in developing the Network Configuration Protocol (NETCONF) (in the NETCONF Working Group) {{RFC6241}}, the associated YANG data model ing language (in the NETMOD Working Group) {{RFC7950}}, RESTCONF {{RFC8040}}, and mos t recently the CoAP Management Interface (CORECONF) {{I-D.ietf-core-comi}}.
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 deployments, state of the art) and identify any operational barriers that prevent these technologies from being widely implemented (limitations, hurdles). * Review the outcomes and results of the 2002 workshop (current deployments and state of the art) and identify any operational barriers that prevent these technologies fr om being widely implemented (limitations and hurdles).
* Sketch new requirements for future network management operations in a collaborative manner with the industry, network operators, and protocol engineers. * Sketch new requirements for future network management operations in a collaborative manner with the industry, network operators, 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 the second IAB wo rkshop on the future of Network Management. The goal of the second workshop was not t o invalidate or replace the first, but to extend the discussion with lessons learned since then. Together, both documents capture a snapshot of the evolving needs of netw ork management over time. This document builds on RFC 3535 with new information gathered from the second IAB wo rkshop on the future of network management. The goal of the second workshop was not t o invalidate or replace the first but to extend the discussion with lessons learned s ince then. Together, both documents capture a snapshot of the evolving needs of netwo rk management over time.
## About this workshop report content ## About the Content of This Workshop Report
This document is a report on the proceedings of the workshop. The views and positions documented in this report are expressed during the workshop by participants and do n ot necessarily reflect IAB's views and positions. This document is a report on the proceedings of the workshop. The views and positions documented in this report are expressed during the workshop by participants and do n ot necessarily reflect the IAB's views and positions.
Furthermore, the content of the report comes from presentations given by workshop par ticipants and notes taken during the discussions, without interpretation or validatio n. Thus, the content of this report follows the flow and dialogue of the workshop bu t does not necessarily attempt to capture a consensus, unless stated otherwise. Furthermore, the content of the report comes from presentations given by workshop par ticipants and notes taken during the discussions, without interpretation or validatio n. Thus, the content of this report follows the flow and dialogue of the workshop bu t does not necessarily attempt to capture a consensus, unless stated otherwise.
# Outreach and Survey {#outreach} # Outreach and Survey {#outreach}
The IAB workshop's Program Committee (PC) planned outreach initiatives to foster disc The IAB workshop's Program Committee (PC) planned outreach initiatives to foster disc
ussions and gather interest by engaging with operators at various operational venues ussions and gather interest by engaging with operators at various operational venues
(RIPE, NANOG, APRICOT, LACNIC, AutoConn, etc) and conducting information/requirement- (Réseaux IP Européens (RIPE), North American Network Operators Group (NANOG),
gathering sessions. Participants were encouraged to submit "position papers" or "expr Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT), Lati
essions of interest" to join the workshop. Additionally, a [SURVEY] was conducted to n American and Caribbean Internet Addresses Registry (LACNIC), AutoConn, etc.) and co
collect valuable insights to inform the workshop. nducting information-/requirement-gathering sessions. Participants were encouraged to
submit "position papers" or "expressions of interest" to join the workshop. Addition
ally, a {{SURVEY}} was conducted to collect valuable insights to inform the workshop.
Some PC members continued to engage with network operators at operational venues afte r the workshop to facilitate information sharing and gather their feedback on the wor kshop, thereby helping to shape the next steps and outcomes. After the workshop, some PC members continued to engage with network operators at ope rational venues to facilitate information sharing and gather their feedback on the wo rkshop, thereby helping to shape the next steps and outcomes.
# Workshop Scope and Discussion # Workshop Scope and Discussion
The workshop was organized across three days, with all participants contributing to o <!--[rfced] FYI: We updated the following section titles (note that
ne discussion per day. The workshop was organized around three topic areas: "Session this follows similar formatting in RFC 9707, which is an IAB
I: the Past (lookback and analysis)" ({{past}}), "Session II: Present (identified pro workshop document). Please let us know of any objections.
blems and requirements)" ({{present}}), and "Session III: Future (possible solutions,
recommendations and next steps)" ({{future}}). The program committee organized the p
aper submissions to fit these three main themes in order to drive discussion during e
ach of the slots. During each discussion, the papers were presented sequentially, and
an open discussion was held afterwards. On the last day, an additional discussion on
the key takeaways from the workshop and possible next steps took place ({{key}}).
The workshop agenda for each day is at [past](https://datatracker.ietf.org/doc/agenda Original:
-interim-2024-nemopsws-01-sessa/), [present](https://datatracker.ietf.org/doc/agenda- 3.1. Session I: Past (lookback, analysis)
interim-2024-nemopsws-02-sessa/), and [future](https://datatracker.ietf.org/doc/agend 3.2. Session II: Present (identified problems & requirements)
a-interim-2024-nemopsws-03-sessa/). All workshop papers and slides are at [materials] 3.3. Session III: Future (possible solutions, recommendations
(https://datatracker.ietf.org/group/nemopsws/materials/). and next steps)
## Session I: Past (lookback, analysis) {#past} Current:
3.1. Session I: Past - Lookback and Analysis
3.2. Session II: Present - Identified Problems and Requirements
3.3. Session III: Future - Possible Solutions, Recommendations,
and Next Steps
-->
The workshop was organized across three days, with all participants contributing to o
ne discussion per day. The workshop was organized around three topic areas: "Session
I: Past - Lookback and Analysis" ({{past}}), "Session II: Present - Identified Proble
ms and Requirements" ({{present}}), and "Session III: Future - Possible Solutions, Re
commendations, and Next Steps" ({{future}}). The program committee organized the pape
r submissions to fit these three main themes in order to drive discussion during each
of the slots. During each discussion, the papers were presented sequentially, and an
open discussion was held afterwards. On the last day, an additional discussion took
place on the key takeaways from the workshop and possible next steps ({{key}}).
<!-- [rfced] In Section 3, note that "past", "present", and "future"
are linked to the respective papers/slides in the html and pdf
files. In the txt file, the URLs are included as shown below. Is this
agreeable? Or should these links be renamed for easier readability
(e.g., "Past (Session I)", "Present (Session II)", and "Future
(Session III)") and/or contain quote marks? Please let us know your
preference.
Current:
The workshop agenda for each day can be viewed at past
<https://datatracker.ietf.org/doc/agenda-interim-2024-nemopsws-
01-sessa/>, present <https://datatracker.ietf.org/doc/agenda-interim-
2024-nemopsws-02-sessa/>, and future
<https://datatracker.ietf.org/doc/agenda-interim-2024-nemopsws-
03-sessa/>.
Perhaps:
The workshop agenda for each day can be viewed at "Past (Session 1)"
<https://datatracker.ietf.org/doc/agenda-interim-2024-nemopsws-
01-sessa/>, "Present (Session II)" <https://datatracker.ietf.org/doc/agenda-interi
m-
2024-nemopsws-02-sessa/>, and "Future (Session III)"
<https://datatracker.ietf.org/doc/agenda-interim-2024-nemopsws-
03-sessa/>.
-->
The workshop agenda for each day can be viewed at [past](https://datatracker.ietf.org
/doc/agenda-interim-2024-nemopsws-01-sessa/){: brackets="angle"}, [present](https://d
atatracker.ietf.org/doc/agenda-interim-2024-nemopsws-02-sessa/){: brackets="angle"},
and [future](https://datatracker.ietf.org/doc/agenda-interim-2024-nemopsws-03-sessa/)
{: brackets="angle"}. All workshop papers and slides can be viewed at [materials](htt
ps://datatracker.ietf.org/group/nemopsws/materials/){: brackets="angle"}.
## Session I: Past - Lookback and Analysis {#past}
The first day of the workshop focused on reflecting on the past by reviewing the evol ution of network management since the 2002 workshop, analyzing both the successes and the challenges encountered along the way. The presentations covered a range of topic s, including reflections on the history of network management, lessons learned from w idely used tools, practices in constrained networks, and the need to reconsider how n etwork management models and protocols are standardized within the IETF. The first day of the workshop focused on reflecting on the past by reviewing the evol ution of network management since the 2002 workshop, analyzing both the successes and the challenges encountered along the way. The presentations covered a range of topic s, including reflections on the history of network management, lessons learned from w idely used tools, practices in constrained networks, and the need to reconsider how n etwork management models and protocols are standardized within the IETF.
### Reflections ### Reflections
The workshop began by reflecting on the IAB’s role in shaping the evolution of networ k management away from CLI/SNMP/MIB technologies, focusing on the context and key out comes of the previous workshop, an assessment of the current state of network managem ent as a whole, and an acknowledgement of some regrets in how network management tech nologies developed in the last two decades (such as XML as the data representation fo rmat). {{SCHONWALDER}} emphasized the need to shift the focus from device-level confi guration to network and service-level configuration. Key properties highlighted for e ffective network and service configurations included being Composable (assembled out of modular configurations), Declarative (define state while systems determine themsel ves how to implement those goals), Reproducible (reliably and consistently recreated) , and Verifiable (asserting that the correct changes have been applied). The workshop began by reflecting on the IAB's role in shaping the evolution of networ k management away from Command-Line Interface (CLI), SNMP, and MIB technologies, focu sing on the context and key outcomes of the previous workshop, an assessment of the c urrent state of network management as a whole, and an acknowledgement of some regrets in how network management technologies developed in the last two decades (such as XM L as the data representation format). {{SCHONWALDER}} emphasized the need to shift th e focus from device-level configuration to network and service-level configuration. K ey properties highlighted for effective network and service configurations included b eing Composable (assembled out of modular configurations), Declarative (define state while systems themselves determine how to implement those goals), Reproducible (relia bly and consistently recreated), and Verifiable (asserting that the correct changes h ave been applied).
An operator’s perspective highlighted that the recommendations of {{RFC3535}} (which led to the development of YANG and NETCONF) have been successful in addressing device configuration in many, but not all, environments. In certain areas, the advancements in semantics and protocols for streaming telemetry have even surpassed the original scope of {{RFC3535}}. {{FARRER}} cautioned against making changes that could disrupt the ecosystem. The presentation emphasized the need to prioritize service modeling in the IETF and addressed the challenges of mapping to the Business Support Systems (BS S) domain. It also stressed the importance of including the operational state in serv ice models to enable closed-loop automation for end-to-end (E2E) services. Revisiting {{RFC8309}}, which asserts that the operational state of a service is not part of a customer service model but can be achieved through extensions, was suggested. Additio nally, the lack of open-source NMS implementations, tools, and device model implement ations was identified as a significant barrier to advancing standardization efforts. The IETF could play a key role in fostering and enabling collaborations to address th ese challenges. While the IETF does not itself build tools, it was suggested that hav ing a translation tool that runs outside the network device to map IETF device models to vendor-specific ones would be beneficial. An operator's perspective highlighted that the recommendations of {{RFC3535}} (which led to the development of YANG and NETCONF) have been successful in addressing device configuration in many, but not all, environments. In certain areas, the advancements in semantics and protocols for streaming telemetry have even surpassed the original scope of {{RFC3535}}. {{FARRER}} cautioned against making changes that could disrupt the ecosystem. The presentation emphasized the need to prioritize service modeling in the IETF and addressed the challenges of mapping to the Business Support Systems (BS S) domain. It also stressed the importance of including the operational state in serv ice models to enable closed-loop automation for end-to-end (E2E) services. Revisiting {{RFC8309}}, which asserts that the operational state of a service is not part of a customer service model but can be achieved through extensions, was suggested. Additio nally, the lack of open-source Network Management System (NMS) implementations, tools , and device model implementations was identified as a significant barrier to advanci ng standardization efforts. The IETF could play a key role in fostering and enabling collaborations to address these challenges. While the IETF does not itself build tool s, it was suggested that having a translation tool that runs outside the network devi ce to map IETF device models to vendor-specific ones would be beneficial.
### Lessons to be Learned ### Lessons to be Learned
{{HARDAKER}} emphasized that the success of Net-SNMP {{NET-SNMP}} was driven by empow ering users through simplicity, stressing that the focus should remain on ensuring ea se of use and adaptability of the protocols. Emphasis was placed on the two distinct audiences for standardized network management protocols: toolkit vendors and system o perators. Their requirements for protocol simplicity differ, and it is essential to a ddress the needs of both to ensure success. {{BORMANN}} presented an overview of the CORECONF architecture, showcasing how model-driven network management techniques can be applied to manage IoT devices (which is different from other network management sc enarios), with a focus on the unique characteristics of constrained nodes. Some parti cipants noted that the binary encoding of CBOR has applications that extend beyond th e IoT networks. {{HARDAKER}} emphasized that the success of Net-SNMP {{NET-SNMP}} was driven by empow ering users through simplicity, stressing that the focus should remain on ensuring ea se of use and adaptability of the protocols. Emphasis was placed on the two distinct audiences for standardized network management protocols: toolkit vendors and system o perators. Their requirements for protocol simplicity differ, and it is essential to a ddress the needs of both to ensure success. {{BORMANN}} presented an overview of the CORECONF architecture, showcasing how model-driven network management techniques can be applied to manage Internet of Things (IoT) devices (which is different from other network management scenarios), with a focus on the unique characteristics of constrai ned nodes. Some participants 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}} emphasized that protocol definition and data models cannot be done in isolation; instead, they must i ntegrate lessons learned from implementation and large-scale deployment. Thus, highli ghting the importance of enabling quick iterations, shipping rapidly, embracing open- source, readily available tools, adopting systems thinking driven by business outcome s, and reusing existing technologies rather than developing solutions exclusively for operator network management. A call was made for the IETF to rethink the approach to standardize data models and the associated network management protocols under this g uidance. Drawing from the experience of OpenConfig {{OPENCONFIG}}, {{SHAKIR}} emphasized that protocol definition and data models cannot be done in isolation; instead, they must i ntegrate lessons learned from implementation and large-scale deployment. Thus, highli ghting the importance of enabling quick iterations, shipping rapidly, embracing open source, readily available tools, adopting systems thinking driven by business outcome s, and reusing existing technologies rather than developing solutions exclusively for operator network management. A call was made for the IETF to rethink the approach to standardize data models and the associated network management protocols under this g uidance.
### Discussion ### Discussion
The Session I open discussion highlighted the divergence between vendor implementatio ns of YANG models and what is accessible via them, particularly when compared to CLI. Questions were raised about how to incorporate fast iteration and rapid changes with in the established IETF process and culture, especially in contrast to the approach u sed by OpenConfig. Common challenges identified included a lack of tooling, performan ce issues at scale, the steep learning curve for network management protocols/models/ tools, initial difficulty in moving away from CLI, and the backward compatibility of models (versioning). Some participants suggested that the IETF should focus on system -level APIs that address specific problems. Additionally, the lack of simple tools fo r smaller networks operating under tight timelines and budgets was emphasized. A key question raised was whether the proliferation of protocols and languages complicates adoption, and if converging on a single approach would improve adoption. The existenc e of multiple schemas and protocols beyond NETCONF, such as BMP and IPFIX, to address network management challenges beyond configuration is an established reality. One co nclusion was that a mechanism was needed to interconnect and harmonize these schemas to provide a cohesive and comprehensive understanding of the data. The Session I open discussion highlighted the divergence between vendor implementatio ns of YANG models and what is accessible via the models, particularly when compared t o CLI. Questions were raised about how to incorporate fast iteration and rapid change s within the established IETF process and culture, especially in contrast to the appr oach used by OpenConfig. Common challenges identified included a lack of tooling, per formance issues at scale, the steep learning curve for network management protocols/m odels/tools, initial difficulty in moving away from CLI, and the backward compatibili ty of models (versioning). Some participants suggested that the IETF should focus on system-level APIs that address specific problems. Additionally, the lack of simple to ols for smaller networks operating under tight timelines and budgets was emphasized. A key question raised was whether the proliferation of protocols and languages compli cates adoption and if converging on a single approach would improve adoption. The exi stence of multiple schemas and protocols beyond NETCONF, such as the BGP Monitoring P rotocol (BMP) and IP Flow Information Export (IPFIX), to address network management c hallenges beyond configuration is an established reality. One conclusion was that a m echanism was needed to interconnect and harmonize these schemas to provide a cohesive and comprehensive understanding of the data.
## Session II: Present (identified problems & requirements) {#present} ## Session II: Present - Identified Problems and Requirements {#present}
The second day of the workshop concentrated on challenges and emerging requirements f or future network management operations. The presentation emphasized the importance o f validation, observability, automation, and the need for agile, incremental developm ent of both network models and management protocols. A compilation of new requirement s from operators was presented; they are being maintained in {{I-D.ietf-nmop-rfc3535- 20years-later}}. The final presentation of the day provided a summary of the survey r esults and operator feedback gathered from outreach events. The second day of the workshop concentrated on challenges and emerging requirements f or future network management operations. The presentation emphasized the importance o f validation, observability, automation, and the need for agile, incremental developm ent of both network models and management protocols. A compilation of new requirement s from operators was presented; they are being maintained in {{I-D.ietf-nmop-rfc3535- 20years-later}}. The final presentation of the day provided a summary of the survey r esults and operator feedback gathered from outreach events.
### Operator Feedback ### Operator Feedback
{{KELLER}} shared Deutsche Telekom’s perspective, emphasizing that while YANG models perform well for provisioning, they currently fall short in providing the operational stability required for validation. In their experience, the IETF service models (whe re available) were considered stable and in good condition, whereas the OpenConfig de vice models were noted as lacking feature richness and stability. In contrast, vendor YANG models are often more flexible and available in a more timely manner. Achieving fully closed-loop automated and autonomous networking will require a greater focus o n observability, particularly through advancements in streaming telemetry with the "o n-change" feature {{RFC9196}}. {{KELLER}} shared Deutsche Telekom's perspective, emphasizing that while YANG models perform well for provisioning, they currently fall short in providing the operational stability required for validation. In their experience, the IETF service models (whe re available) were considered stable and in good condition, whereas the OpenConfig de vice models were noted as lacking feature richness and stability. In contrast, vendor YANG models are often more flexible and available in a more timely manner. Achieving fully closed-loop automated and autonomous networking will require a greater focus o n observability, particularly through advancements in streaming telemetry with the "o n-change" feature {{RFC9196}}.
{{JIMENEZ}} discussed the challenges associated with the Software Defined Networking (SDN) Transport Automation Platform, including observability and analytics requiremen ts, issues with data streaming, scalability, diverse models in heterogeneous multi-ve ndor environments, and mechanisms to secure the network management protocols. The pre sentation also emphasized how advancements in AI and machine learning, along with the potential adaptation of protocols designed for constrained environments, could drive the next evolution in network management. {{JIMENEZ}} discussed the challenges associated with the Software Defined Networking (SDN) Transport Automation Platform, including observability and analytics requiremen ts, issues with data streaming, scalability, diverse models in heterogeneous multi-ve ndor environments, and mechanisms to secure the network management protocols. The pre sentation also emphasized how advancements in AI and machine learning, along with the potential adaptation of protocols designed for constrained environments, could drive the next evolution in network management.
Using YANG-Push as an example, {{GRAF}} highlighted how standards development often f ails to align with the needs of network operators, the constraints of network vendors , and the integration requirements. Most critically, it lacks an agile, incremental d evelopment process. The presentation advocated for adopting an iterative approach to standards development, focusing on delivering minimal viable products as part of the process. Using YANG-Push as an example, {{GRAF}} highlighted how standards development often f ails to align with the needs of network operators, the constraints of network vendors , and integration requirements. Most critically, it lacks an agile, incremental devel opment process. The presentation advocated for adopting an iterative approach to stan dards development, focusing on delivering minimal viable products as part of the proc ess.
{{CONTRERAS}} emphasized reassessing deployment assumptions and incorporating updated operator requirements. The authors are addressing these aspects through {{I-D.ietf-n mop-rfc3535-20years-later}}, leveraging feedback and discussions from the workshop. S ome key requirements, suggestions and observations that were highlighted in the works hop: {{CONTRERAS}} emphasized reassessing deployment assumptions and incorporating updated operator requirements. The authors are addressing these aspects through {{I-D.ietf-n mop-rfc3535-20years-later}}, leveraging feedback and discussions from the workshop. S ome key requirements, suggestions, and observations that were highlighted in the work shop:
* Network software implementations can only happen with a strong, committed standardi zation effort, complemented by active involvement in open-source projects that facili tate access to code. * Network software implementations can only happen with a strong, committed standardi zation effort, complemented by active involvement in open-source projects that facili tate access to code.
* Need to rationalize the device model space and avoid redundant efforts. Unlike serv ice and network models, IETF-defined device models are not widely implemented. * Need to rationalize the device model space and avoid redundant efforts. Unlike serv ice and network models, IETF-defined device models are not widely implemented.
* Define a reference approach/process for service exposure discovery (API discovery). * Define a reference approach/process for service exposure discovery (API discovery).
* Outlines a set of recommendations for core/key features, along with appropriate jus * Outline a set of recommendations for core/key features, along with appropriate just
tifications, that will help foster more implementations that meet operators’ needs. ifications, that will help foster more implementations that meet operators' needs.
* Reassess the value of some IETF proposals, including compared to competing or emerg * Reassess the value of some IETF proposals, including comparison to competing or eme
ing solutions (e.g., gNMI vs. YANG-Push) rging solutions (e.g., gRPC Network Management Interface (gNMI) vs. YANG-Push)
* Need for a more agile process for the development and maintenance of YANG modules i n the IETF. RFCs might not be suited for documenting YANG modules. * Need for a more agile process for the development and maintenance of YANG modules i n the IETF. RFCs might not be suited for documenting YANG modules.
* Consider approaches to ease integration by design (e.g., protocols and data models) . * Consider approaches to ease integration by design (e.g., protocols and data models) .
* There is a need for a reference specification to translate YANG-based data into the knowledge graph (KG). * Need for a reference specification to translate YANG-based data 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 between service/networ k/device data models. * Consider programmatic approaches to ensure lossless mappings between service/networ k/device data models.
* Consider approaches to ensure reuse/consistent data structure across various NM seg ments. * Consider approaches to ensure reuse of / consistent data structure across various n etwork management segments.
* Some networks have specific network management requirements, such as the need for a synchronous operations or constraints on data compactness. * Some networks have specific network management requirements, such as the need for a synchronous operations or constraints on data compactness.
* There is a necessity to handle the heterogeneity of data, configuration, and networ k management/requirements. Resolving such issues could draw on insights from parallel technical fields such as knowledge engineering practices and concepts associated wit h Linked Data in the Semantic Web, areas where it is common to manage problems of het erogeneity and data reconciliation across various application domains. * Necessity to handle the heterogeneity of data, configuration, and network managemen t/requirements. Resolving such issues could draw on insights from parallel technical fields such as knowledge engineering practices and concepts associated with Linked Da ta in the Semantic Web, areas where it is common to manage problems of heterogeneity and data reconciliation across various application domains.
* Consider having YANG as part of the protocol specification/change where possible, o r have the YANG document progress in parallel. * Consider having YANG as part of the protocol specification/change where possible, o r have the YANG document progress in parallel.
* Need to ease the integration of low-level/network-oriented solutions with native "I T tooling" * Need to ease the integration of low-level/network-oriented solutions with native "I T tooling".
* Ease exposure of libraries and host tools (e.g., yangkit) to ease integration. * Ease exposure of libraries and host tools (e.g., yangkit) to ease 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 collaborate. * Create an ecosystem where data and networking engineers can collaborate.
* The distinct approaches followed in both the compute and the network environments t o define suitable mechanisms for enabling an efficient interplay, while highly automa ting the overall service delivery procedure. * Distinct approaches are followed in both the compute and the network environments t o define suitable mechanisms for enabling an efficient interplay, while highly automa ting the overall service delivery procedure.
* The target application/applicability of a network management approach should be doc umented. * The target application/applicability of a network management approach should be doc umented.
* Readily available API specifications could be generalized from YANG modules for fas t development, prototyping, and validation. * Readily available API specifications could be generalized from YANG modules for fas t development, prototyping, and validation.
### Survey {#survey} ### Survey {#survey}
As outlined in {{outreach}}, the workshop program committee organized outreach initia tives to gather direct feedback and conducted a survey. {{SURVEY-INSIGHTS}} provided an overview of the respondents’ backgrounds, as well as insights into the most widely used tools, protocols, and APIs for configuration, monitoring, and other network ope rations. Notably, the survey revealed that Ansible and CLI are the most popular confi guration tools, NETCONF is the preferred configuration protocol, and Prometheus and S NMP are widely used for monitoring. The survey also captured feedback on network auto mation and streaming telemetry. Issues and future requirements such as scalability, p erformance, the need for easier mapping of various models, tooling, management of leg acy devices, collaboration with open-source, and vendor-specific issues were highligh ted. Additionally, valuable insights from direct operator feedback were also presente d (see {{insights}}). As outlined in {{outreach}}, the workshop program committee organized outreach initia tives to gather direct feedback and conducted a survey. {{SURVEY-INSIGHTS}} provided an overview of the respondents' backgrounds, as well as insights into the most widely used tools, protocols, and APIs for configuration, monitoring, and other network ope rations. Notably, the survey revealed that Ansible and CLI are the most popular confi guration tools, NETCONF is the preferred configuration protocol, and Prometheus and S NMP are widely used for monitoring. The survey also captured feedback on network auto mation and streaming telemetry. Issues and future requirements such as scalability, p erformance, the need for easier mapping of various models, tooling, management of leg acy devices, collaboration with open source, and vendor-specific issues were highligh ted. Additionally, valuable insights from direct operator feedback were presented (se e {{insights}}).
### Discussion ### Discussion
The Session II open discussion featured feedback from implementers, highlighting the difficulty in moving to YANG and mapping to vendor implementations and how divergence in the implementations creates complexity and necessitates workarounds. Implementati ons need to support standard models alongside native vendor models, which adds comple xity and leads to confusion. Challenges were highlighted in mapping standard models t o internal device models and legacy devices, with some cases where mapping is not fea sible at all (device-specific knobs). The conversation also emphasized the importance of developing open-source reference implementations, compliance and interoperability testing for vendors with real data, and better quality of vendor implementation and documentation. The implementation and support of multiple models (IETF, OpenConfig, a nd native vendor models) is an unavoidable reality in network management. Additionall y, since the services offered by operators vary significantly, reaching a consensus o n a common service model within the IETF can be a challenging task. It was also noted that the IETF should expedite the publication of standards as well as consider gatin g them with multiple interoperable implementations. The Session II open discussion featured feedback from implementers, highlighting the difficulty in moving to YANG and mapping to vendor implementations and how divergence in implementations creates complexity and necessitates workarounds. Implementations need to support standard models alongside native vendor models, which adds complexity and leads to confusion. Challenges were highlighted in mapping standard models to in ternal device models and legacy devices, with some cases where mapping is not feasibl e at all (device-specific knobs). The conversation also emphasized the importance of developing open-source reference implementations, compliance and interoperability tes ting for vendors with real data, and better quality of vendor implementation and docu mentation. The implementation and support of multiple models (IETF, OpenConfig, and n ative vendor models) is an unavoidable reality in network management. Additionally, s ince the services offered by operators vary significantly, reaching a consensus on a common service model within the IETF can be a challenging task. It was also noted tha t the IETF should expedite the publication of standards as well as consider gating th em with multiple interoperable implementations.
## Session III: Future (possible solutions, recommendations and next steps) {#future} ## Session III: Future - Possible Solutions, Recommendations, and Next Steps {#future }
The final day of the workshop centred on exploring potential future solutions and ide ntifying key takeaways, recommendations, and next steps. At the end of day three, to conclude the workshop, the chairs worked to summarize the key takeaways (see {{key}}) that garnered consensus among the participants. The final day of the workshop centered on exploring potential future solutions and id entifying key takeaways, recommendations, and next steps. At the end of day three, to conclude the workshop, the chairs worked to summarize the key takeaways (see {{key}} ) that garnered consensus among the participants.
### Suggestions on Future Directions ### Suggestions on Future Directions
{{CLAISE}} highlighted the challenges of integrating data models across different sil os, protocols, and data structures, emphasizing the need for a machine-readable appro ach to expose semantics. Additionally, the related tools being developed and showcase d in the IETF Hackathons, along with the various challenges in mapping across protoco ls and models, were discussed. A potential solution was proposed using a knowledge gr aph based on the Semantic Web Stack, along with the need to define a basic ontology f or the networking domain in an iterative manner (outside of RFCs). {{CLAISE}} highlighted the challenges of integrating data models across different sil os, protocols, and data structures, emphasizing the need for a machine-readable appro ach to expose semantics. Additionally, the related tools being developed and showcase d in the IETF Hackathons, along with the various challenges in mapping across protoco ls and models, were discussed. A potential solution was proposed that uses a knowledg e graph based on the Semantic Web Stack, along with the need to define a basic ontolo gy for the networking domain in an iterative manner (outside of RFCs).
{{WATSEN}} recommends prioritizing the following areas in four recommendations: (1) u sing RESTCONF+JSON (including YANG-Push Lite) as a single protocol beyond network man agement, (2) utilizing Network Management Datastore Architecture (NMDA) model, (3) cr eating data model adapters (off-box so that common standard models can be developed i n parallel to the required device "native" vendor models), and (4) defining device pr otocol adapters (with RESTCONF-like NBI for a common shared-by-all repository). {{WATSEN}} recommended prioritizing the following into four areas: (1) using RESTCONF +JSON (including YANG-Push Lite) as a single protocol beyond network management, (2) utilizing Network Management Datastore Architecture (NMDA) model, (3) creating data m odel adapters (off-box so that common standard models can be developed in parallel to the required device "native" vendor models), and (4) defining device protocol adapte rs (with RESTCONF-like Northbound Interface (NBI) for a common shared-by-all reposito ry).
{{WILTON}} recommends reducing unnecessary complexity, delivering timely solutions, f ostering open collaboration between vendors and operators, prioritizing simplicity, a nd converging to a single model/protocol (though this was discussed as difficult to a ccomplish). Practical suggestions include focusing on YANG-Push Lite, introducing YAN G 2.0 through incremental updates, developing NETCONFv2, and managing IETF YANG model s as code or APIs rather than embedding them within RFCs. {{WILTON}} recommended reducing unnecessary complexity, delivering timely solutions, fostering open collaboration between vendors and operators, prioritizing simplicity, and converging to a single model/protocol (though this was discussed as difficult to accomplish). Practical suggestions include focusing on YANG-Push Lite, introducing YA NG 2.0 through incremental updates, developing NETCONFv2, and managing IETF YANG mode ls as code or APIs rather than embedding them within RFCs.
### Discussion ### Discussion
The open discussion in Session III explored a range of topics. These included the abs ence of NMDA in OpenConfig and debate over whether its complexity is justified; the h istorical context of gNMI’s introduction in the IETF and whether RESTCONF offers adva ntages over it; and the broader challenges of building consensus, with participants n oting that while the process takes time, it should not be short-circuited. The discus sion also addressed the practicality of converging on a single protocol and concluded that such convergence is, in fact, feasible. The open discussion in Session III explored a range of topics. These included the abs ence of NMDA in OpenConfig and debate over whether its complexity is justified; the h istorical context of gNMI's introduction in the IETF and whether RESTCONF offers adva ntages over it; and the broader challenges of building consensus, with participants n oting that while the process takes time, it should not be short-circuited. The discus sion also addressed the practicality of converging on a single protocol and concluded that such convergence is, in fact, feasible.
The discussion emphasized off-box adapters, which allow vendors to continue innovatin g and developing native vendor models rapidly. One suggestion that attracted a lot of discussion centred on developing a standard model mapping to native vendor models th at could be maintained in a common repository, enabling the community to assess cover age and alignment. The discussion emphasized off-box adapters, which allow vendors to continue innovatin g and developing native vendor models rapidly. One suggestion that attracted a lot of discussion centered on developing a standard model mapping to native vendor models t hat could be maintained in a common repository, enabling the community to assess cove rage and alignment.
Further, the discussion explored alternative approaches to YANG models within the IET F but outside of RFCs, such as leveraging GitHub to accelerate the process (along wit h the challenges associated with it), living documents within the WG charter, and sup porting academia to take up the open source efforts, such as device adapters. The dis cussion emphasized the need for process experimentation, particularly at the working group or area level, where we could have consensus among the YANG/OPS community on ho w we iterate in WGs without IETF/RFC-wide changes, but making sure the operators are involved in the process. Further, the discussion explored alternative approaches to YANG models within the IET F but outside of RFCs, such as leveraging GitHub to accelerate the process (along wit h the challenges associated with it), living documents within the WG charter, and sup porting academia to take up the open source efforts, such as device adapters. The dis cussion emphasized the need for process experimentation, particularly at the working group or area level, where we could have consensus among the YANG/OPS community on ho w we iterate in WGs without IETF-/RFC-wide changes, but making sure the operators are involved in the process.
Conversations ensued around questions asked, such as "Is YANG applicable beyond netwo rk management?" and "Can applications adopt YANG as a modelling language to define th eir services?" Conversations ensued around questions asked, such as "Is YANG applicable beyond netwo rk management?" and "Can applications adopt YANG as a modeling language to define the ir services?"
Some key recommendations made by operators during outreach ({{outreach}}) are listed in {{recommendations}}. Some key recommendations made by operators during outreach ({{outreach}}) are listed in {{recommendations}}.
## Key Takeaways {#key} ## Key Takeaways {#key}
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 last discussion of the workshop, and anything that did not reach a wide consensus was moved into a "future considerati ons" list ({{workneeded}}). At the end of the third day, the discussion turned to key takeaways that have a high- level consensus. These were edited live during the last discussion of the workshop, and anything that did not reach a wide consensus was moved into a "future considerati ons" list ({{workneeded}}).
### Ecosystem conclusions ### Ecosystem Conclusions
The following takeaways try to document the general thinking of the participants with respect to the entire Network Management ecosystem as it exists today. The following takeaways try to document the general thinking of the participants with respect to the entire network management ecosystem 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.
1. The overall ecosystem is still fragmented for both protocols and 1. 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, networks. Popular protocols include SNMP, NETCONF, RESTCONF,
and gNMI. and gNMI.
1. Documentation about the architecture and usage of the network 1. 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
general architecture documentation, deployment guides, tutorials, general architecture documentation, deployment guides, tutorials,
training material, and getting-started guides. training material, and getting-started guides.
1. Transitioning between network management frameworks is challenging, 1. Transitioning between network management frameworks is challenging,
just like it is for transitioning between other protocols like IPv4 just like it is for transitioning between other protocols like IPv4
to IPv6. to IPv6.
1. Model-driven network management is generally a success where it has been 1. Model-driven network management is generally a success where it has been
implemented and is possible to use. implemented and is possible to use.
1. More easily usable network management tools for the operators are 1. 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.
### Protocol conclusions ### Protocol Conclusions
The following conclusions came while discussing Network Management protocols, more sp ecifically. The following conclusions were reached while discussing network 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.
1. NETCONF and YANG do not have full coverage on many devices. 1. NETCONF and YANG do not have full coverage on many devices.
1. Polling-based solutions are still frequently deployed. Push-based solutions are o ften desired but are not yet widely available. 1. Polling-based solutions are still frequently deployed. Push-based solutions are o ften desired but are not yet widely available.
### Modeling conclusions ### Modeling Conclusions
The following conclusions came while discussing Network Management modeling, more spe cifically. The following conclusions were reached while discussing network management modeling, more specifically.
1. Some YANG models can become complex due to the underlying features they represent, not due to the language itself. 1. Some YANG models can become complex due to the underlying features they represent, not due to the language itself.
1. Multi-vendor compatibility support is required. 1. Multi-vendor compatibility support is required.
1. Even vendor-specific features, not just standardized protocol 1. Even vendor-specific features, not just standardized protocol
features, need to be exposed through network management models and protocols features, need to be exposed through network management models and protocols
for a network management ecosystem to be viable. for a network management ecosystem to be viable.
1. Greater support for service-level modeling is needed. Device-level 1. Greater support for service-level modeling is needed. Device-level
modeling can be a building block to achieve a sufficient 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.
1. Network configuration needs to be verifiable to ensure any 1. 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 this device) may be the best path forward to simultaneously achieve this
and the goal of supporting one configuration set across a diversity and the goal of supporting one configuration set across a diversity
of devices with different internal models. of devices with different internal models.
### Standardization conclusions ### Standardization Conclusions
The following conclusions were reached while discussing the best ways to standardize network management protocols and associated models. The following conclusions were reached while discussing the best ways 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 deployment. ensure model deployment can keep pace with new feature deployment.
We need a solution that significantly increases the speed and We need a solution that significantly increases the speed and
predictable timeline for developing and publishing models within predictable timeline for developing and publishing models within
the IETF. New approaches and methods to make models live outside the IETF. New approaches and methods to make models live outside
of published RFCs should be explored. An experiment should be of published RFCs should be explored. An experiment should be
started to test a new rapid development approach. started to test a new rapid development approach.
1. Protocol and model complexity should be reduced to keep additions 1. 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.
1. More standardization focus is needed on the scalability of the 1. 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.
1. Enhancements to network management protocols and models need to be 1. Enhancements to network management protocols and models need to be
backed by real-world operator use cases and expected adoption by backed by real-world operator use cases and expected adoption by
vendors. Vendors and operators will need to work together to vendors. Vendors and operators will need to work together to
ensure these goals are appropriately met. ensure these goals are appropriately met.
### Conclusions that did not reach consensus during the takeaways discussion {#workne eded} ### Conclusions That Did Not Reach Consensus During the Takeaways Discussion {#workne eded}
Here we list the things that the group realized needed significantly more attention i n order to come to a conclusion while updating the key takeaways in real time. Here, we list the things that the group realized needed significantly more attention in order to come to a conclusion, while updating the key takeaways in real time.
1. Some, but not all, saw NETCONF for configuration as being successful in some larg er-scale deployments. Although this statement is true in some contexts, many operato rs indicated their need to rely on other forms of access to manage their networks, su ch as CLIs, Expect scripts, and other protocols. 1. Some, but not all, saw NETCONF for configuration as being successful in some larg er-scale deployments. Although this statement is true in some contexts, many operato rs indicated their need to rely on other forms of access to manage their networks, su ch as CLIs, Expect scripts, and other protocols.
2. Many hope that NETCONF, and RESTCONF more specifically, will continue to move to a long-term configuration management solution. However, some participants doubted wh ether the protocol and its data models can ever be truly ubiquitous and keep pace wit h the device deployment pace. 2. Many hope that NETCONF, and RESTCONF more specifically, will continue to move to a long-term configuration management solution. However, some participants doubted wh ether the protocol and its data models can ever be truly ubiquitous and keep pace wit h the device deployment pace.
While many other items also need further discussion, this list specifically includes those that were actively discussed during the live editing session in the workshop. While many other items also need further discussion, this list specifically includes those that were actively discussed during the live editing session in the workshop.
# Not Covered in the Workshop # Not Covered in the Workshop
Some topics absent from the workshop discussions included tooling (what is currently missing) and strategies to support tool development (who pays, who develops, who main tains). The primary focus of the discussion was on YANG and NETCONF/RESTCONF, while s everal other network management protocols and techniques currently used received less attention during the workshop. The discussion during the workshop on possible future directions prioritized improving existing solutions rather than introducing entirely new ones (such as enabling intelligence in network management). Some topics absent from the workshop discussions included tooling (what is currently missing) and strategies to support tool development (who pays, who develops, and who maintains). The primary focus of the discussion was on YANG and NETCONF/RESTCONF, whi le several other network management protocols and techniques currently used received less attention. During the workshop, the discussion on possible future directions pri oritized improving existing solutions rather than introducing entirely new ones (such as enabling intelligence in network management).
# Security Considerations # Security Considerations
This document is a workshop report and does not impact the security of the Internet. This document is a workshop report and does not impact the security of the Internet.
# IANA Considerations # 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.]
--- back --- back
# Operator Feedback {#insights} # Operator Feedback {#insights}
This section compiles the operator feedback gathered through outreach and information gathering at various operational venues (RIPE, NANOG, APRICOT, LACNIC, AutoConn, etc ). The PC synthesized this input and presented it during the workshop (see {{survey}} ). This section compiles the operator feedback gathered through outreach and information gathering at various operational venues (RIPE, NANOG, APRICOT, LACNIC, AutoConn, etc .). The PC synthesized this input and presented it during the workshop (see {{survey} }).
## General ## General
1. In network deployments, operations are typically at the bottom of the ladder. It's the most squeezed for time and resources. Network engineers are not typically season ed developers. The development of needed in-house tools often takes years to develop. There is a need for tools that are easy to use and just work. 1. In network deployments, operations are typically at the bottom of the ladder. It's the most squeezed for time and resources. Network engineers are not typically season ed developers. The development of needed in-house tools often takes years to develop. There is a need for tools that are easy to use and just work.
2. The vast majority of smaller operators use CLI and open source to manage their net works. 2. The vast majority of smaller operators use CLI and open source to manage their net works.
3. There is debate fatigue. The protocol/model debate is a recurring conversation. Th e problem isn’t going away. 3. There is debate fatigue. The protocol/model debate is a recurring conversation. Th e problem isn't going away.
4. It was suggested that other domains (e.g., K8N/automation) are years ahead of the current network engineering stack. 4. It was suggested that other domains (e.g., K8N/automation) are years ahead of the current network engineering stack.
5. Support for multiple friendly, stable and feature-rich libraries for programming l 5. Support for multiple friendly, stable, and feature-rich libraries for programming
anguages is needed. Many DevOps routines use shell scripts, while others use a high-l languages is needed. Many DevOps routines use shell scripts, while others use a high-
evel programming language. In any case, on the client side, multiple programming lang level programming language. In any case, on the client side, multiple programming lan
uages are used. guages are used.
6. Screen scraping is unfortunately necessary and painful. This most often occurs whe 6. Screen scraping is unfortunately necessary and painful. This most often occurs whe
n interacting with a device having only a CLI. n interacting with a device that only has a CLI.
7. It was noted that there could be an outreach to Academia to establish programs to teach lessons using modern management stacks, and then a new generation of engineers could help to improve tooling and automation, with university (and/or IETF) hackathon s. 7. It was noted that there could be an outreach to Academia to establish programs to teach lessons using modern management stacks, and then a new generation of engineers could help to improve tooling and automation, with university (and/or IETF) hackathon s.
## Data Models ## Data Models
1. In some network deployments, the focus is solely on service-level models, such tha t device-level protocols and device-level models are unimportant. This assumes the ex istence of a device adaptation layer to transcode service-level models to device-leve l models and conform to the device-specific protocol. 1. In some network deployments, the focus is solely on service-level models, such tha t device-level protocols and device-level models are unimportant. This assumes the ex istence of a device adaptation layer to transcode service-level models to device-leve l models and conform to the device-specific protocol.
2. There is a need for solutions to not hide vendor-specific parameters. Currently, v endors compete by differentiating their offerings in unique ways. The reason why an O perator may choose a particular vendor is because of its differentiating features. Wh ilst standard models enable conformance, they must not hide the vendor-specific param eters. YANG deviations are a partial solution to not hiding vendor knobs. 2. There is a need for solutions to not hide vendor-specific parameters. Currently, v endors compete by differentiating their offerings in unique ways. The reason why an o perator may choose a particular vendor is because of its differentiating features. Wh ilst standard models enable conformance, they must not hide the vendor-specific param eters. YANG deviations are a partial solution to not hiding vendor knobs.
3. It was emphasized that streaming telemetry requires picking a model and sticking w ith it. It is quite a commitment, and the current environment makes the decision hard er. 3. It was emphasized that streaming telemetry requires picking a model and sticking w ith it. It is quite a commitment, and the current environment makes the decision hard er.
4. It was noted that IETF's focus should be on defining abstract/service-level data m odels since it is the only thing the community may ever agree on. 4. It was noted that IETF's focus should be on defining abstract/service-level data m odels since it is the only thing the community may ever agree on.
5. It was noted that navigating standard models can be difficult. The Network Enginee r knows the vendor CLI commands but has trouble locating the corresponding leaves in the standard YANG models defined by SDOs. 5. It was noted that navigating standard models can be difficult. A network engineer knows the vendor CLI commands but has trouble locating the corresponding leaves in th e standard YANG models 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.
# Key Recommendations from Operator Feedback {#recommendations} # Key Recommendations from Operator Feedback {#recommendations}
Various recommendations were made by the operators during the outreach events. The ke y ones presented during the workshop were (there were a lot more collected): Various recommendations were made by the operators during the outreach events. The ke y ones presented during the workshop were (note that there were a lot more collected) :
* Everyone: Continue to focus on model-driven management as a means to achieve autom ation. * Everyone: Continue to focus on model-driven management as a means to achieve autom ation.
* SDOs: Re-introduce “running code” as part of the specification verification proces * SDOs: Re-introduce "running code" as part of the specification verification proces
s. s.
* 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 for common cases . * Technology Ambassadors: Evangelize the recommended solution stack for common cases .
* Vendors: Support the recommended approach to the solution stack for common cases. * Vendors: Support the recommended approach to the solution stack for common cases.
# Position Papers # Position Papers
20 position papers were submitted to the workshop call for papers. All papers are ava ilable at <https://datatracker.ietf.org/group/nemopsws/materials/>. 20 position papers were submitted to the workshop call for papers. All papers are ava ilable at [](https://datatracker.ietf.org/group/nemopsws/materials/){:brackets="angle "}.
This is the list of all papers: This is the list of all papers:
* J Schönwälder: Composable, Declarative, Reproducible, Verifiable Network and Servic * J.&nbsp;Schönwälder: Composable, Declarative, Reproducible, Verifiable Network and
e Configurations {{SCHONWALDER}} Service Configurations {{SCHONWALDER}}
* K. Larsson, K. Lambrechts, and I. Farrer: RFC3535, 20 Years Later from an Operator’ * K.&nbsp;Larsson, K.&nbsp;Lambrechts, and I.&nbsp;Farrer: RFC3535, 20 Years Later fr
s Perspective (Deutsche Telekom) {{FARRER}} om an Operator's Perspective (Deutsche Telekom) {{FARRER}}
* W. Hardaker: Lessons Learned from 30 Years of Net-SNMP {{HARDAKER}} * W.&nbsp;Hardaker: Lessons Learned from 30 Years of Net-SNMP {{HARDAKER}}
* C. Bormann: CORECONF: Managing IoT Devices with YANG Models {{BORMANN}} * C.&nbsp;Bormann: CORECONF: Managing IoT Devices with YANG Models {{BORMANN}}
* R. Shakir: Rethinking Standardisation of Network Management {{SHAKIR}} * R.&nbsp;Shakir: Rethinking Standardisation of Network Management {{SHAKIR}}
* N. Warnke, R. Geib, M. Horneffer, and H. Keller: NEMOPS: RFC3535 and the forgotten * N.&nbsp;Warnke, R.&nbsp;Geib, M.&nbsp;Horneffer, and H.&nbsp;Keller: NEMOPS: RFC353
word — Or Provisioning is only a subset of Network Management {{KELLER}} 5 and the forgotten word - Or Provisioning is only a subset of Network Management {{K
* J. Jiménez, S. Mansfield, R. Rodriguez A., M. Pesonen, V. Torvinen, and J. Karvonen ELLER}}
: Evolving Challenges and Solutions in Network Management {{JIMENEZ}} * J.&nbsp;Jiménez, S.&nbsp;Mansfield, R.&nbsp;Rodriguez A., M.&nbsp;Pesonen, V.&nbsp;
* M. Boucadair, L. M. Contreras, O. Gonzalez de Dios, T. Graf, R. Rahman, and L. Tail Torvinen, and J.&nbsp;Karvonen: Evolving Challenges and Solutions in Network Manageme
hardat: RFC 3535, 20 Years Later: An Update of Operators Requirements on Network Mana nt {{JIMENEZ}}
gement Protocols and Modelling {{CONTRERAS}} * M.&nbsp;Boucadair, LM.&nbsp;Contreras, O.&nbsp;Gonzalez de Dios, T.&nbsp;Graf, R.&n
* T. Graf, H. Keller, D. Voyer, P. Lucente, B. Claise, R. Wilton, A. Huang-Feng, and bsp;Rahman, and L.&nbsp;Tailhardat: RFC 3535, 20 Years Later: An Update of Operators
P. Francois: Agile Incremental Driven Development for Network Management {{GRAF}} Requirements on Network Management Protocols and Modelling {{CONTRERAS}}
* B. Claise, T. Graf, H. Keller, D. Voyer, P. Lucente, D. Lopez, I. D. Martinez-Casan * T.&nbsp;Graf, H.&nbsp;Keller, D.&nbsp;Voyer, P.&nbsp;Lucente, B.&nbsp;Claise, R.&nb
ueva, B. Peters, P. Fasano, P. Ran, W. Cheng, and M. Mackey: Knowledge Graph Framewor sp;Wilton, A.&nbsp;Huang-Feng, and P.&nbsp;Francois: Agile Incremental Driven Develop
k for Network Operations {{CLAISE}} ment for Network Management {{GRAF}}
* K. Watsen: Four Thoughts for How to Improve Network Management for Operators {{WATS * B.&nbsp;Claise, T.&nbsp;Graf, H.&nbsp;Keller, D.&nbsp;Voyer, P.&nbsp;Lucente, D.&nb
EN}} sp;Lopez, I.&nbsp;D.&nbsp;Martinez-Casanueva, B.&nbsp;Peters, P.&nbsp;Fasano, P.&nbsp
* R. Wilton and N. Corran: Device Network Management: Current Status and Future Direc ;Ran, W.&nbsp;Cheng, and M.&nbsp;Mackey: Knowledge Graph Framework for Network Operat
tion {{WILTON}} ions {{CLAISE}}
* M. Gudi, A. Pelov, L. Toutain, and J.-M. Bonnin: Evolving Network Management Archit * K.&nbsp;Watsen: Four Thoughts for How to Improve Network Management for Operators {
ecture: Integrating CORECONF with NETCONF for Efficient Telemetry and Management {{GU {WATSEN}}
DI}} * R.&nbsp;Wilton and N.&nbsp;Corran: Device Network Management: Current Status and Fu
* P. Foroughi and L. Ciavaglia: Projecting Data Mesh to Model-driven Telemetry: A Pat ture Direction {{WILTON}}
h to Data Ecosystem’s Management Operations {{FOROUGHI}} * M.&nbsp;Gudi, A.&nbsp;Pelov, L.&nbsp;Toutain, and J.&nbsp;M.&nbsp;Bonnin: Evolving
* I. D. Martinez-Casanueva: IAB NEMOPS Position Paper - Telefonica {{MARTINEZ}} Network Management Architecture: Integrating CORECONF with NETCONF for Efficient Tele
* J. Jiménez: Managing IoT Devices with LwM2M {{JIMENEZ-2}} metry and Management {{GUDI}}
* L. M. Contreras, R. Schott, S. Randriamasy, R. Yang, and J. Ros-Giralt: Towards a U * P.&nbsp;Foroughi and L.&nbsp;Ciavaglia: Projecting Data Mesh to Model-driven Teleme
nified Compute and Communication Infrastructure for Application and Network Managemen try: A Path to Data Ecosystem's Management Operations {{FOROUGHI}}
t {{GIRALT}} * I.&nbsp;D.&nbsp;Martinez-Casanueva: IAB NEMOPS Position Paper - Telefonica {{MARTIN
* T. Eckert and M. Richardson: Resilient Remote Manageability of Wide-Area Network In EZ}}
frastructures {{ECKERT}} * J.&nbsp;Jiménez: Managing IoT Devices with LwM2M {{JIMENEZ-2}}
* R. Bless: An Invariant for Future Resilient Network Management Operations {{BLESS}} * LM.&nbsp;Contreras, R.&nbsp;Schott, S.&nbsp;Randriamasy, R.&nbsp;Yang, and J.&nbsp;
* M. Scharf: Network Management Challenges for IP-based Cyber-Physical Networks {{SCH Ros-Giralt: Towards a Unified Compute and Communication Infrastructure for Applicatio
ARF}} n and Network Management {{GIRALT}}
* T.&nbsp;Eckert and M.&nbsp;Richardson: Resilient Remote Manageability of Wide-Area
Network Infrastructures {{ECKERT}}
* R.&nbsp;Bless: An Invariant for Future Resilient Network Management Operations {{BL
ESS}}
* M.&nbsp;Scharf: Network Management Challenges for IP-based Cyber-Physical Networks
{{SCHARF}}
# Workshop Participants # Workshop Participants
The workshop participants were Alex Huang, Alexander Clemm, Alexander Pelov, Benoit C laise, Boris Khasanov, Brad Peters, Carsten Bormann, Chongfeng Xie, Cindy Morgan, Dan Voyer, Darren Loher, Dean Bogdanovic, Dean Bogdanović, Dhruv Dhody, Diego Lopez, Ebb en Aries, Frank (Chong Feng), Holger Keller, Ian Farrer, Jaime Jimenez, James Cumming , Janne Karvonen, Jason Sterne, Jiaming Ye, Jinming Li, John Carson, Julien Maisonneu ve, Jürgen Schönwälder, Kent Watsen, Kris Lambrechts, Kristian Larsson, Laurent Ciava glia, Laurent Toutain, Liz Flynn, Luis M. Contreras, Mahesh Jethanandani, Manoj Gudi, Martin Horneffer, Matthew Bocci, Med Boucadair, Michael Mackey, Michael Richardson, Michael Scharf, Mikko Pesonen, Nacho Dominguez, Naveen Achyuta, Nick Corran, Nils War nke, Oscar Gonzalez de Dios, Paolo Lucente, Parisa Foroughi, Per Andersson, Phil Shaf er, Qin Wu, Qiufang Ma, Raquel Rodriguez, Reshad Rahman, Rob Shakir, Rob Wilton, Rola nd Bless, Roland Schott, Rüdiger Geib, Rui Zhuang, Ruibo Han, Sabine Randriamasy, Sco tt Mansfield, Scott Robohn, Shengnan Yue, Suresh Krishnan, Thomas Graf, Toerless Ecke rt, Wangbo, Warren Kumari, Wes Hardaker, Wim Henderickx, Xue Yang, Y. Richard Yang, Y angbo, Yisong Liu, and Zhenqiang Li. The workshop participants were {{{Alex Huang}}}, {{{Alexander Clemm}}}, {{{Alexander Pelov}}}, {{{Benoît Claise}}}, {{{Boris Khasanov}}}, {{{Brad Peters}}}, {{{Carsten Bo rmann}}}, {{{Chongfeng Xie}}}, {{{Cindy Morgan}}}, {{{Dan Voyer}}}, {{{Darren Loher}} }, {{{Dean Bogdanovic}}}, {{{Dean Bogdanović}}}, {{{Dhruv Dhody}}}, {{{Diego Lopez}}} , {{{Ebben Aries}}}, {{{Frank (Chong Feng)}}}, {{{Holger Keller}}}, {{{Ian Farrer}}}, {{{Jaime Jimenez}}}, {{{James Cumming}}}, {{{Janne Karvonen}}}, {{{Jason Sterne}}}, {{{Jiaming Ye}}}, {{{Jinming Li}}}, {{{John Carson}}}, {{{Julien Maisonneuve}}}, {{{J ürgen Schönwälder}}}, {{{Kent Watsen}}}, {{{Kris Lambrechts}}}, {{{Kristian Larsson}} }, {{{Laurent Ciavaglia}}}, {{{Laurent Toutain}}}, {{{Liz Flynn}}}, {{{Luis M. Contre ras}}}, {{{Mahesh Jethanandani}}}, {{{Manoj Gudi}}}, {{{Martin Horneffer}}}, {{{Matth ew Bocci}}}, {{{Med Boucadair}}}, {{{Michael Mackey}}}, {{{Michael Richardson}}}, {{{ Michael Scharf}}}, {{{Mikko Pesonen}}}, {{{Nacho Dominguez}}}, {{{Naveen Achyuta}}}, {{{Nick Corran}}}, {{{Nils Warnke}}}, {{{Oscar Gonzalez de Dios}}}, {{{Paolo Lucente} }}, {{{Parisa Foroughi}}}, {{{Per Andersson}}}, {{{Phil Shafer}}}, {{{Qin Wu}}}, {{{Q iufang Ma}}}, {{{Raquel Rodriguez}}}, {{{Reshad Rahman}}}, {{{Rob Shakir}}}, {{{Rob W ilton}}}, {{{Roland Bless}}}, {{{Roland Schott}}}, {{{Rüdiger Geib}}}, {{{Rui Zhuang} }}, {{{Ruibo Han}}}, {{{Sabine Randriamasy}}}, {{{Scott Mansfield}}}, {{{Scott Robohn }}}, {{{Shengnan Yue}}}, {{{Suresh Krishnan}}}, {{{Thomas Graf}}}, {{{Toerless Eckert }}}, {{{Wangbo}}}, {{{Warren Kumari}}}, {{{Wes Hardaker}}}, {{{Wim Henderickx}}}, {{{ Xue Yang}}}, {{{Y. Richard Yang}}}, {{{Yangbo}}}, {{{Yisong Liu}}}, and {{{Zhenqiang Li}}}.
# Workshop Program Committee # Workshop Program Committee
The workshop program committee members were Wes Hardaker (co-chair), Dhruv Dhody (co- chair), Qin Wu, Suresh Krishnan, Benoît Claise, Mohamed Boucadair, Mahesh Jethanandan i, Kent Watsen, and Warren Kumari. The workshop program committee members were {{{Wes Hardaker}}} (co-chair), {{{Dhruv D hody}}} (co-chair), {{{Qin Wu}}}, {{{Suresh Krishnan}}}, {{{Benoît Claise}}}, {{{Moha med Boucadair}}}, {{{Mahesh Jethanandani}}}, {{{Kent Watsen}}}, and {{{Warren Kumari} }}.
# IAB Members at the Time of Approval # IAB Members at the Time of Approval
{:numbered="false"} {:numbered="false"}
Internet Architecture Board members at the time this document was approved for public ation were: Internet Architecture Board members at the time this document was approved for public ation were:
* Matthew Bocci * {{{Matthew Bocci}}}
* Roman Danyliw * {{{Roman Danyliw}}}
* Dhruv Dhody * {{{Dhruv Dhody}}}
* Jana Iyengar * {{{Jana Iyengar}}}
* Cullen Jennings * {{{Cullen Jennings}}}
* Suresh Krishnan * {{{Suresh Krishnan}}}
* Mirja Kühlewind * {{{Mirja Kühlewind}}}
* Warren Kumari * {{{Warren Kumari}}}
* Jason Livingood * {{{Jason Livingood}}}
* Mark Nottingham * {{{Mark Nottingham}}}
* Tommy Pauly * {{{Tommy Pauly}}}
* Alvaro Retana * {{{Alvaro Retana}}}
* Qin Wu * {{{Qin Wu}}}
# Acknowledgments # Acknowledgments
{:numbered="false"} {:numbered="false"}
Thanks to Benoît Claise, Jürgen Schönwälder, Kristian Larsson, Jaime Jiménez, Michael Richardson, Phil Shafer, Mirja Kühlewind, and Roman Danyliw for helpful suggestions to improve this report. Thanks to {{{Benoît Claise}}}, {{{Jürgen Schönwälder}}}, {{{Kristian Larsson}}}, {{{J aime Jiménez}}}, {{{Michael Richardson}}}, {{{Phil Shafer}}}, {{{Mirja Kühlewind}}}, and {{{Roman Danyliw}}} for helpful suggestions to improve this report.
Thanks to Alvaro Retana for shepherding this document. Thanks to {{{Alvaro Retana}}} for shepherding this document.
<!-- [rfced] Abbreviations
a) FYI - We have added expansions for the following abbreviations per
Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review these and
each expansion in the document carefully to ensure correctness.
Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT)
BGP Monitoring Protocol (BMP)
Concise Binary Object Representation (CBOR)
Command-Line Interface (CLI)
CoAP Management Interface (CORECONF)
gRPC Network Management Interface (gNMI)
Internet of Things (IoT)
IP Flow Information Export (IPFIX)
Latin American and Caribbean Internet Addresses Registry (LACNIC)
North American Network Operators Group (NANOG)
Northbound Interface (NBI)
Network Configuration Protocol (NETCONF)
Network Management System (NMS)
Reseaux IP Europeens (RIPE)
b) How may we expand "K8N"? Is this term different than "Kubernetes (K8s)"?
Original:
4. It was suggested that other domains (e.g., K8N/automation) are
years ahead of the current network engineering stack.
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
For example, please consider whether the following should be updated:
- native
-->
 End of changes. 83 change blocks. 
156 lines changed or deleted 240 lines changed or added

This html diff was produced by rfcdiff 1.48.