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 protected]> On Behalf Of maqiufang (A)
Sent: Monday, November 22, 2021 9:58 PM
To: [email protected]
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?

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to