Qiufang, While we have tools that actually do offline validation a lot, I am not against discussing removing that possibility from YANG (in a multi-year plan), if there are strong benefits with this idea. So far I haven't seen them.
In the old SNMP world, we had MIB models. They described what you could read and write, but not when you could do so or how things interacted. Now we have YANG-based interfaces that are transactional (sequencing no longer a client concern) and with machine readable constraints. I don't see any way to reach the high automation levels we are enjoying today without this. These principles are bringing a lot of very tangible owner and consumer value $€¥ every day. Running reflects the client's intent. If an upcoming intent can no longer be validated by anybody else than the system being managed, and the rules by which it validates running depends on a black box, then it becomes very hard for the client to express its intent. Sounds like we'd be going back to the SNMP age. If anyone can explain a) how a client should go about expressing its intent in a world where running no longer needs to be valid, and b) what the strong benefits of this model would be, I'd be happy to discuss. Best Regards, /jan 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 netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
