rfc9968v1.txt   rfc9968.txt 
skipping to change at line 191 skipping to change at line 191
(Section 3.1), "Session II: Present - Identified Problems and (Section 3.1), "Session II: Present - Identified Problems 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 took place on the key takeaways from the additional discussion took place on the key takeaways from the
workshop and possible next steps (Section 3.4). workshop and possible next steps (Section 3.4).
The workshop agenda for each day can be viewed at past The workshop agenda for each day can be viewed at "Past (Session 1)"
<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 (Session II)" <https://datatracker.ietf.org/doc/
2024-nemopsws-02-sessa/>, and future agenda-interim-2024-nemopsws-02-sessa/>, and "Future (Session III)"
<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 can be viewed at 03-sessa/>. All workshop papers and slides can be viewed at
materials <https://datatracker.ietf.org/group/nemopsws/materials/>. "materials" <https://datatracker.ietf.org/group/nemopsws/materials/>.
3.1. Session I: Past - Lookback and 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
skipping to change at line 410 skipping to change at line 410
on insights from parallel technical fields such as knowledge on insights from parallel technical fields such as knowledge
engineering practices and concepts associated with Linked Data in engineering practices and concepts associated with Linked Data in
the Semantic Web, areas where it is common to manage problems of the Semantic Web, areas where it is common to manage problems of
heterogeneity and data reconciliation across various application heterogeneity and data reconciliation across 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 common "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.
* Distinct approaches are followed in both the compute and the * Distinct approaches are followed in both the compute and the
skipping to change at line 455 skipping to change at line 455
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
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 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 vendor-specific 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 vendor-specific 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 3.3. Session III: Future - Possible Solutions, Recommendations, and
Next Steps Next Steps
The final day of the workshop centered on exploring potential future The final day of the workshop centered on exploring potential future
skipping to change at line 497 skipping to change at line 497
protocols and models, were discussed. A potential solution was protocols and models, were discussed. A potential solution was
proposed that uses 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] recommended prioritizing the following into four areas: (1) [WATSEN] recommended prioritizing the following into four areas: (1)
using RESTCONF+JSON (including YANG-Push Lite) as a single protocol using RESTCONF+JSON (including YANG-Push Lite) as a single protocol
beyond network management, (2) utilizing Network Management Datastore beyond network management, (2) utilizing Network Management Datastore
Architecture (NMDA) model, (3) creating data model adapters (off-box Architecture (NMDA) model, (3) creating data model adapters (off-box
so that common standard models can be developed in parallel to the so that common standard models can be developed in parallel to the
required device "native" vendor models), and (4) defining device required device vendor-specific models), and (4) defining device
protocol adapters (with RESTCONF-like Northbound Interface (NBI) for protocol adapters (with RESTCONF-like Northbound Interface (NBI) for
a common shared-by-all repository). a common shared-by-all repository).
[WILTON] recommended 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
skipping to change at line 523 skipping to change at line 523
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 vendor-specific models rapidly.
suggestion that attracted a lot of discussion centered on developing One suggestion that attracted a lot of discussion centered on
a standard model mapping to native vendor models that could be developing a standard model mapping to vendor-specific models that
maintained in a common repository, enabling the community to assess could be maintained in a common repository, enabling the community to
coverage and alignment. assess 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
skipping to change at line 903 skipping to change at line 903
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., Kubernetes (K8s) /
years ahead of the current network engineering stack. automation) are 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 that only has a most often occurs when interacting with a device that only has a
CLI. CLI.
 End of changes. 9 change blocks. 
15 lines changed or deleted 16 lines changed or added

This html diff was produced by rfcdiff 1.48.