Hi Jan, RFC 8342 defines the ability for "configuration transformations” to map <running> to <intended>, which is "subject to validation”. Section 5.1.4 describes cross-cutting features, such as deactivating nodes and templating, that can result in an invalid <running>, when <running> is considered alone. However, clients can "offline-validate <running>", when such features are in use, by groking and applying the processing-logic behind the features (mimicking that which the server does to produce <intended>), and then YANG-validate the result (same as the server). All this is well understood, expected, and good - right?
FWIW, these features have been implemented in Junos for as long as I know. And yes, the Juniper NMS systems I worked on offline-validated “<running>” before <edit-config> by mimicking the processing logic locally, as described above. What Qiufang proposes now adds to this. It is one more thing for clients wishing to offline-validate <running> to mimic. In this case, they need to mimic the merging of <running> and <system>, which entails the clients also fetching <system> from the server, in case they don’t have it already. None of this takes away from transactional interfaces, machine readable constraints, high automation levels, or the ability for clients to express intent. With regards to owner and consumer value, I see each of these three features (deactivating nodes, templating, and <system>) as providing clients greater/better flexibility/control/insight. Agreed? Kent > On Oct 26, 2023, at 10:42 AM, Jan Lindblad (jlindbla) > <jlindbla=40cisco....@dmarc.ietf.org> wrote: > > 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
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
