On Fri, Dec 03, 2021 at 10:59:12AM +0100, Jan Lindblad wrote: > I made some proposals earlier, both on the interim and privately to the draft > authors, along these lines: > > Option #1 > + We could have a new system datastore that technically is a part of running. > Everything in system would show up in running to clients unaware of the > system datastore. Every time the system datastore changes for whatever > reason, the running datastore transaction ids (if we manage to get that > concept defined), are updated > + Clients interested to see pure view of the system datastore without > anything else in running could issue a get-data towards the system datastore > + Clients interested to see a pure view of running without any system > datastore elements could issue a get-data towards running with an extra flag > called 'without-system' > + Since all system elements are already part of running, clients have no need > to copy data between the two datastores > > Option #2 > + We could have a system datastore that technically is a part of operational. > Everything in system would show up in operational to clients unaware of the > system datastore. The running datastore always maintains referential > integrity, i.e. cannot reference the system datastore. > + Clients interested to see pure view of the system datastore could issue a > get-data towards the system datastore > + Since the system datastore is not part of running, clients can already see > a pure view of running without any system datastore elements using a simple > get-data. > + Clients that are aware of the system datastore and are interested to > configure references from running to system elements would issue an edit-data > rpc with the additional flag 'resolve-system-references'. This will make the > server copy any system elements referenced into running without the client > doing so explicitly. > + Clients unaware of the system datastore would have to include (copy) > information from the system datastore to running in order to reference them. >
Option #3 There is a client on the system that makes changes to running just like any other remote clients can make changes to running. System generate config that is not editable explicit config in running goes straight into the applied config in operational. This does not require a system datastore (in fact something like a system datastore may exist as the _logic_ of the system client, the good old example we had is allocting an unused uid for an account that, once allocated, is maintained in running). /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/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
