rfc9968v1.md   rfc9968.md 
skipping to change at line 415 skipping to change at line 415
# Outreach and Survey {#outreach} # Outreach and Survey {#outreach}
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 (Réseaux IP Européens (RIPE), North American Network Operators Group (NANOG), 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 (Réseaux IP Européens (RIPE), North American Network Operators Group (NANOG),
Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT), Lati n American and Caribbean Internet Addresses Registry (LACNIC), AutoConn, etc.) and co 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. Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT), Lati n American and Caribbean Internet Addresses Registry (LACNIC), AutoConn, etc.) and co 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.
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. 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
<!--[rfced] FYI: We updated the following section titles (note that
this follows similar formatting in RFC 9707, which is an IAB
workshop document). Please let us know of any objections.
Original:
3.1. Session I: Past (lookback, analysis)
3.2. Session II: Present (identified problems & requirements)
3.3. Session III: Future (possible solutions, recommendations
and next steps)
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}}). 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" The workshop agenda for each day can be viewed at ["Past (Session 1)"](https://datatr
are linked to the respective papers/slides in the html and pdf acker.ietf.org/doc/agenda-interim-2024-nemopsws-01-sessa/){: brackets="angle"}, ["Pre
files. In the txt file, the URLs are included as shown below. Is this sent (Session II)"](https://datatracker.ietf.org/doc/agenda-interim-2024-nemopsws-02-
agreeable? Or should these links be renamed for easier readability sessa/){: brackets="angle"}, and ["Future (Session III)"](https://datatracker.ietf.or
(e.g., "Past (Session I)", "Present (Session II)", and "Future g/doc/agenda-interim-2024-nemopsws-03-sessa/){: brackets="angle"}. All workshop paper
(Session III)") and/or contain quote marks? Please let us know your s and slides can be viewed at ["materials"](https://datatracker.ietf.org/group/nemops
preference. ws/materials/){: brackets="angle"}.
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} ## 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 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). 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 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. 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.
skipping to change at line 509 skipping to change at line 467
* Reassess the value of some IETF proposals, including comparison to competing or eme rging solutions (e.g., gRPC Network Management Interface (gNMI) vs. YANG-Push) * Reassess the value of some IETF proposals, including comparison to competing or eme 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) .
* 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 of / consistent data structure across various n etwork management segments. * 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.
* 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. * 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 common "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.
* 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. * 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 presented (se e {{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 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. 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 vendor-specific models, which adds complexi ty and leads to confusion. Challenges were highlighted in mapping standard models to internal device models and legacy devices, with some cases where mapping is not feasi ble at all (device-specific knobs). The conversation also emphasized the importance o f developing open-source reference implementations, compliance and interoperability t esting for vendors with real data, and better quality of vendor implementation and do cumentation. The implementation and support of multiple models (IETF, OpenConfig, and vendor-specific 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.
## 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 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. 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 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). {{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}} 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). {{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 vendor-specific models), and (4) defining device protocol adapte rs (with RESTCONF-like Northbound Interface (NBI) for a common shared-by-all reposito ry).
{{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. {{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 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. The discussion emphasized off-box adapters, which allow vendors to continue innovatin g and developing vendor-specific models rapidly. One suggestion that attracted a lot of discussion centered on developing a standard model mapping to vendor-specific mode ls that could be maintained in a common repository, enabling the community to assess coverage 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 modeling language to define the ir 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 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}}). 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}}).
skipping to change at line 660 skipping to change at line 618
# 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., Kubernetes (K8s) / automation) are year s ahead of the current network engineering stack.
5. Support for multiple friendly, stable, and feature-rich libraries for programming languages is needed. Many DevOps routines use shell scripts, while others use a high- level programming language. In any case, on the client side, multiple programming lan guages are used. 5. Support for multiple friendly, stable, and feature-rich libraries for programming languages is needed. Many DevOps routines use shell scripts, while others use a high- level programming language. In any case, on the client side, multiple programming lan guages are used.
6. Screen scraping is unfortunately necessary and painful. This most often occurs whe n interacting with a device that only has a CLI. 6. Screen scraping is unfortunately necessary and painful. This most often occurs whe 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.
skipping to change at line 745 skipping to change at line 703
* {{{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}}}, {{{J aime 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. 8 change blocks. 
52 lines changed or deleted 12 lines changed or added

This html diff was produced by rfcdiff 1.48.