Hi, Jason, all, I think all system configuration that is non-deletable should be defined in <system>, if things differ from case to case, I have concern that it is hard to enumerate all cases. The draft already states that <system> may change dynamically. Deletable system configuration should be present in <running>, otherwise how is it possible for the client to delete it? If it is in <running>, doesn't it have an origin value "intended"? If we make a distinction this way, is it safe to infer that all nodes using or:system are originating from <system>? Am I missing something?
Jürgen has suggested to use sysds:system to report configuration originating from <system>, but I am unsure if that is possible to define another identical identity also derived from "origin" identity? Andy raised the case of dynamic default, I think another choice is to report dynamic default as origin: default, e.g., the BGP example (https://datatracker.ietf.org/doc/html/rfc8342#appendix-C.2.2.1) given in RFC8342 also have the origin of local-as and peer-as being reported as or: default. Best Regards, Qiufang -----Original Message----- From: Jason Sterne (Nokia) <[email protected]> Sent: Friday, November 8, 2024 4:24 AM To: Jürgen Schönwälder <[email protected]>; Kent Watsen <[email protected]> Cc: [email protected] Subject: [netmod] Re: origin "system" in system-config-09 One note: we do need to be careful to distinguish system config (in the system DS) from factory defaults RFC8088. If that administrator account is deletable (and probably is or should be for security reasons) I'd call that factory default (not system DS) and it would be visible in <running>. > -----Original Message----- > From: Jürgen Schönwälder <[email protected]> > Sent: Thursday, November 7, 2024 2:54 PM > To: Kent Watsen <[email protected]> > Cc: Jason Sterne (Nokia) <[email protected]>; [email protected] > Subject: Re: [netmod] origin "system" in system-config-09 > > > CAUTION: This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext for additional > information. > > > > 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] _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
