Re: [netmod] How to handle configuration node being effective after system-restart?

Hello Wolfgang,

I don't see any clear right answer here.

You're talking about a condition that must be met for a configuration change to take operational effect. In this case it is a restart. But there could be other types of similar conditions. E.g. other nodes that need:
- an admin-state to be disabled and then enabled (i.e. toggle/kick a protocol)
- some other magic before it takes effect

*Maybe* there are a set of somewhat common conditions across many types of systems that could be standardized in a YANG extension (and tag those nodes).  Or using a new standardized YANG model to list "needs restart" nodes (or nodes with other standard conditions).  These solutions are along the lines of your option 2 (although I'd lean more towards the extension route).

Using a leaf to indicate "needs restart" is possible but I think that would be a proprietary-only approach. Would you then also have some state information that says which list of nodes are waiting on a restart ?  Or maybe in your case it is "good enough" to just know you need a restart. But a client app would have to be specifically programmed with knowledge of that "needs restart" leaf.

I'm not sure I understand your approach #3.

Note that it is probably useful here to talk about the "applied config" concept for this node. Let's pretend node 'foo' was configured with value 5 and a system restart occurred after that. Then the user configures value 23 but does not restart the system:
A) IETF NMDA would say that reading node 'foo' in the operational datastore should return 5   (but reading node 'foo' in the running DS would return 23)
B) Another approach might be to have another leaf (config false) called 'oper-foo' that always reflects the current operational value (e.g. 5 in this case)
C) OpenConfig would have a "state" copy of node foo and reading that would return 5 (a bit like B above, although with a 'well known convention')

A client could diff the running config vs the applied config and at least know there is a difference (but then there isn't anything standard to know a restart is needed to bring them into sync).

Jason

> -----Original Message-----
> From: netmod <netmod-bounces@ietf.org> On Behalf Of Hauck Wolfgang
> (ETAS-DAP/XPC-Fe6)
> Sent: Wednesday, July 20, 2022 11:34 AM
> To: netmod@ietf.org
> Subject: [netmod] How to handle configuration node being effective after
> system-restart?
> 
> Hi all!
> 
> The use case I think about is as follows:
> 
> A configuration node  in a YANG model is effective only after a system-
> restart (i.e. not only a restart of the NETCONF server). Now I would like to
> see from a YANG model if a system-restart actually has to be carried out for
> that node. E.g. as system operator I would like to know from the model only
> if I have to wait and poll for the operational state resulting from the
> configuration, or if I have to actively restart the system. At the end, I would
> like to publish a YANG model such that the model's user is able to derive his
> or her actions only from that model without further studying any
> documentation.
> 
> Modelling how to perform a system-restart is easy, as I have seen in the
> draft "Factory default Setting". Recognising its necessity is the difficulty here.
> 
> What would be the best practice here?
> 
> I can think about three options:
> 
> 1) Explicitly modelling the property "system-restart needed", e.g. by a leaf
> next to the configuration node.
> 
> 2) Providing a YANG module listing all configuration nodes requiring a system-
> restart.
> 
> 3) Using the startup datastore. However, as the conventional configuration
> datastores have all the same datastore schema, there seems to be no
> possibility to see the property "system-start needed". Otherwise, it could
> have been modelled by a configuration node in the startup datastore, and as
> status node in all other datastores.
> 
> I highly appreciate any hints. - Thanks.
> 
> Regards,
> Wolfgang
> 
> ---
> 
> Dr. Wolfgang Hauck
> Engineering Data Acquisition and Processing - Lead Architect
> 
> ETAS GmbH, ETAS-DAP/XPC-Fe6
> Borsigstraße 24, 70469 Stuttgart, Germany
> www.etas.com
> 
> ETAS - Empowering Tomorrow's Automotive Software
> 
> Managing Directors: Christoph Hartung, Günter Gromeier, Götz Nigge
> Chairman of the Supervisory Board: Dr. Walter Schirm
> Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB:
> 19033
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod