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
