Liaison statement
Reply to LS on need for modeling isInvariant and SystemCreated in YANG

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/