On Thu, Nov 07, 2024 at 02:33:09PM +0000, Kent Watsen wrote: > > Indeed. It might help to think about the use-case that <system> intends to > support. My understanding is that it’s trying to reveal more about what the > buried program logic does, so that the network’s functioning can be better > understood, e.g., to implement a digital twin. >
I guess I understand the system datastore differently. Perhaps some examples help: 1) Consider an interface generating link-local IPv6 addresses. I expect that these address has or:system, I do not expect to find them in the system datastore. 2) Consider a system that has a default administrative user account. I expect that this account has sysds:system, I consider this hard wired configuration. 3) I consider a list of applications or preconfigured ACL rules as sysds:system content. This is also the example given in the I-D. I do not find where the document says that all system generated applied config should be reflected in sysds:system. This would turn sysds:system into a constantly changing dynamic configuration datastore. And if system is merged into intended, I start wondering whether values would not have or:intended. Or if your model applies, then why would we even need a new identity since we have already or:system? /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
