Title: Reply to LS on need for modeling isInvariant and SystemCreated in YANG Submission Date: 2025-06-06 URL of the IETF Web page: https://datatracker.ietf.org/liaison/2005/
From: Charles Eckel <[email protected]> To: Susanna Kooistra <[email protected]>, Peter Schmitt <[email protected]> Cc: Kent Watsen <[email protected]>,Network Modeling Discussion List <[email protected]>,Lou Berger <[email protected]>,Mohamed Boucadair <[email protected]>,Mahesh Jethanandani <[email protected]>,Charles Eckel <[email protected]> Response Contacts: Kent Watsen <[email protected]>,Lou Berger <[email protected]> Technical Contacts: Purpose: In response Referenced liaison: LS on need for modeling isInvariant and SystemCreated in YANG (https://datatracker.ietf.org/liaison/1818/) Body: 1. Description Dear 3GPP TSG SA WG5, We thank you for your LS [1] dated, 2023-03-09, explaining your desire and rationale for the IETF to standardize proposed "IsInvariant" and "SystemCreated" annotations for use with the YANG language. We apologize for the slightly delayed response, but the NETMOD working group has been considering a solution in this area, which although it may not exactly meet your concerns (further details below), we believe that we have documents [2][3] that have progressed reasonably far through the IETF publication process and hence now would be a good time for members in your community to review and provide comments on them. The proposed solution is two-fold: 1) a new datastore called <system>, that can document what configuration is system-defined and 2) a new metadata annotation called "immutable", that a server may return for <system> defined data, thus enabling clients to know when certain edit operations against immutable data may fail. Regarding 1.2.1 isInvariant: We are not able to offer an exact solution for standardizing an "isInvariant" extension because of concerns that such an extension would end up breaking the transactional behavior of NETCONF and RESTCONF. I.e., to help keep programmatic network management clients simple, there is a very strong desire to always allow a client to migrate a devices state from any valid configuration to any different valid configuration as a single committed configuration change. Defining a flag such as "isInvariant" that forces clients to make configuration changes in multiple independent steps breaks this transactional behavior and adds complexity to the client. Instead, the solution that the WG would propose is that servers are implemented such that if it is necessary to delete and recreate an object when a field within that object is changed, that instrumentation should be performed automatically by the server and be invisible to the client. This would, as your liaison indicated, potentially be a traffic impacting change, but it has been observed that many such changes are possible and supported in general network device configuration that has not previously required an 'invariant' behavior annotation or a break in transactional behavior. As you indicate, it has also been observed that some vendors do indeed have configuration that exhibits "isInvariant" style behavior, but NETMOD's goal here is that it would be more desirable to gradually migrate away from such behavior rather than standardize and encourage further proliferation of such behavior that introduces unnecessary complexities to automated management clients. Instead, it is assumed that clients can be designed and implemented so that they can manage such changes appropriately. Hence the "immutable-flag" draft [3] defines a metadata attribute called "immutable" that can be used by a system to declare which configuration nodes it deems immutable. Regarding 1.2.2 SystemCreated Classes: The system datastore defined in [2] provides a similar, but slightly different solution to the problem described by SystemCreated Classes in your LS. The NETMOD WG believes that that the "system-config" draft provides a solution for your problem, whilst preserving NETCONF/YANGs transactional behavior in an NMDA [4] compliant manner. Specifically, the solution defines a new NMDA datastore called "system", where system-defined nodes may be declared. The NETMOD WG asks 3GPP TSG SA WG5 to review and provide comments on these solutions. We encourage the use of the NETMOD WG mailing list [5] as the most effective and expedient way to provide comments. Kent and Lou, NETMOD chairs, on behalf of IETF NETMOD Working Group 2. Upcoming Meetings IETF 123, 19 - 25 July 2025, Madrid, ES IETF 124, 1-7 November, Montreal, CA 3. References [1] https://datatracker.ietf.org/liaison/1818 [2] https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config [3] https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag [4] https://datatracker.ietf.org/doc/html/rfc8342 [5] https://datatracker.ietf.org/wg/netmod/about/ Attachments: Reply to LS on need for modeling isInvariant and SystemCreated in YANG https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2025-06-06-netmod-3gpp-3gpp-tsg-sa-wg5-reply-to-ls-on-need-for-modeling-isinvariant-and-systemcreated-in-yang-attachment-1.docx Reply to LS on need for modeling isInvariant and SystemCreated in YANG https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2025-06-06-netmod-3gpp-3gpp-tsg-sa-wg5-reply-to-ls-on-need-for-modeling-isinvariant-and-systemcreated-in-yang-attachment-2.pdf _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
