Subject: [netmod] system DS polluting intended and operational

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 9 Dec 2021 17:51:48 +0000

I wonder if having all the system config appear in intended and operational may be annoying. We didn't want to pollute running with 100s/1000s of lines of unreferenced system config. So maybe putting all that in intended & operational is also ugly ?

We should have *some* way that a client can retrieve system configuration though.

Some potential options (without system flowing 100% of its contents into intended):
a) <system> DS that can be read (but doesn't flow into intended or operational)
b) a "with-system" extension (like "with-defaults"). Returns a merge of running+system (or candidate+system, or intended+system).

Maybe we'd also want (or maybe want instead) is a way to see *referenced* system config (either on its own, or merged with another DS).

Jason

From: netmod <[email-masked]> On Behalf Of maqiufang (A)
Sent: Monday, November 22, 2021 9:58 PM
To: [email-masked]
Subject: [netmod] Should the origin="system" be required for system configurations copied/pasted into <running>?

Hi, all

There is still another issue which is about origin metadata annotation: should the origin="system" be required for system configurations copied/pasted into <running>?

Currently any system configuration explicitly declared in <running> in order to configure its descendant nodes or maintain <running> offline-valid will show up in <operational> with origin=intended.
The question behind this issue is whether we want a copied/pasted system defined data node to override and take precedence over <system>.

The choices and some considerations of this issue received so far:
o  Origin=system IS required for system configuration copied/pasted into <running>
?  I believe that "system" reflects the most accurate source in this case. And only in this way, a server can allow a read-only system configuration to be declared in <running>(e.g., in order to valid <running>) by the clients.
?  The challenge for this choice is on the server side. It MUST be able to recognize a particular data node which explicitly defined in <running> is actually a mirror of what is in <system>.
o  Origin=system is NOT required for system configuration copied/pasted into <running>
?  Good consistency. For all configurations explicitly defined in <running>, if they appear in <operational>, the origin value is "intended" with no exceptions.
o  Define a system-mode which is similar to with-defaults basic mode and allow a server to advertise a particular behavior
?  Does it mean we could get the Pros from both choices?
Any other thoughts?

---

From: Jürgen Schönwälder <[email-masked]>
Date: Thu, 9 Dec 2021 19:19:00 +0100

> I wonder if having all the system config appear in intended and operational may be annoying. We didn't want to pollute running with 100s/1000s of lines of unreferenced system config. So maybe putti…

The applied config, part of operational, is the config that is
actually used by the device. RFC 8342 has the details.

> b) a "with-system" extension (like "with-defaults"). Returns a merge of running+system (or candidate+system, or intended+system).

You want to rewrite RFC 8342?
 
> Maybe we'd also want (or maybe want instead) is a way to see *referenced* system config (either on its own, or merged with another DS).

The 'referenced system config' has to be in running since otherwise it
can't be referenced.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>