RFC 8342 has relevant information, including some MUSTs and SHOULDs. /js
On Thu, Oct 26, 2023 at 07:49:06AM +0000, maqiufang (A) wrote: > Hi, all > > I want to bring up a key issue that has been discussed before but hasn't > really been agreed upon: MUST offline-validation of <running> alone be > required? > > The question behind this issue is about: must referenced system config always > be copied into <running> to satisfy referential integrity constraints, or > <running> is implicitly valid if <intended> is valid by merging <system> and > <running> (after config transformation like removal of inactive config and > expansion of templates) to create its contents, <running> alone doesn't have > to be offline valid. > > It feels like the WG has a mixed viewpoints, and I would like to find a > solution and seek convergence here. Actually I am thinking, instead of > directly stating in the draft that any referenced system config must be > contained in <running>, we can point to RFC 7950 and RFC 8342 and state that > <running> MUST always be a valid configuration data tree. So that we just > leave it there and interpretations may vary. Anyway, the client can always > explicitly copy referenced system config into <running> or use the > "resolve-system" parameter if an offline-validation of <running> is needed. > > If we can reach an agreement on this handling, I believe then we can move on. > > One the other side, I also understand that we should not shy away from this > issue and need effectively work it out. Below are some thoughts and inputs > from the WG: > > > * Yes, <running> alone must be offline valid > > o Pros > > ? Clients can easily offline validate <running> without offline merging > <system> and <running> (which would bring extra complexity to clients) > > o Cons: > > ? Painful copy is needed. > > ? Need to deal with the scenario where the system config has updated and a > stale copy is still in <running> > > * No, Offline validation of <running> MAY consider other datastores > as well, two options: > > o Treat it as a bug-fix in existing RFCs > > ? Cons: might break legacy clients and existing tool chains > > o Wait for a new version of YANG/NC/RC > > ? Cons: might incur delay > > Any further thoughts on this? Comments and suggestions would be much > appreciated. > > > Best Regards, > Qiufang > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
