On Mon, Dec 13, 2021 at 11:44:31PM +0000, Kent Watsen wrote: > 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? >
Well, while doing the NMDA work, we already acknowledged that there are proprietary extensions (like templates or inactive nodes) and hence we moved validation to <intended>. Since people felt it was kind of hopeless to standardize templates, we accepted that there is vendor specific magic applied to the config from <running> to become <intended>. So from this perspective, merging in some system config is not making things any worse, we already broke the ability to validate a copy of <running> in an interoperable way in the NMDA work. If we accept that there is system configuration one can rely on, then this system configuration obviously flows into <intended>. Whether it is possible to standardize this, I do not know, we even failed with inactive in the past. That said, I am not convinced by the proposed with-system parameter. If you retrieve <running>, then you should get <running> and not something that happens to <running> later down the pipeline. If people want offline validation, then they either retrieve <intended> and work with that or they have to implement the vendor's magic for merging system configuration, for dealing with inactive nodes, for expanding templates, and whatever comes next. This is bad news for everybody who wants to do validation of config _before_ it is shipped to <running> since these folks have to implement vendor specific logic. This is unfortunate but I believe we started accepting this with NMDA and we accepted it because this is what implementations apparently do... I still believe that good data model design can avoid many of the situations where people believe they need to depend on system configuration. The interface example presented at IETF 112 is a weak example since we rely on lazy name bindings for interfaces, a description configured for an interface "foo" is applied to an interface "foo" if there is one, otherwise it is not applied. You do not need to know whether the system supplies a "foo" interface to validate the config. But then I am sure there are examples where non lazy bindings exist, perhaps hidden deep in some MUST expressions. /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
