Juergen/Andy,
> 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). > Juergen, you mentioned this before. I don’t recall if there were any responses, but how would this solution address the various concerns that have been raised? > +1 to option 3. > Consider an implementation that moves all the "hidden system logic" off-box > to a controller, such that the initial config is literally supplied by an > external client. Andy, IIRC, you +1’ed Juergen’s previous “option #3”, but can you to answer the same question about how solution address concerns? > I have yet to hear a single use-case for creating a <system> datastore. > "The client might want" is not a use-case for standardization. > I do not understand the "pure view". Seems like if this was a real problem to > solve, > then NMDA would have included a system datastore from the start. Use-cases and issues were discussed at both the Interim and at IETF 112. I don’t recall you or Juergen attending either, but the 112-recording starts at the 23-minute mark here: https://play.conf.meetecho.com/Playout/?session=IETF112-NETMOD-20211111-1430 <https://play.conf.meetecho.com/Playout/?session=IETF112-NETMOD-20211111-1430> K. // as a contributor
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
