Kent, Very good. Our products are leveraging the features you mention in Junos systems, and we have similar functionality in our own. I certainly see good value in these "configuration transformations”, but I also know that much of this value can be realized without changes to YANG, since in fact we already have such features implemented while also supporting an always valid running at the same time.
I agree more value could potentially be made available if the config transformations could be expressed more freely, but in my world, trading such a gain for the loss of a robust machine readable interface is a huge net negative. You are pointing to the crucial spot below when you say '''clients can "offline-validate <running>", when such features are in use, by groking and applying the processing-logic behind the features'''. If we can make a client grok and apply that processing logic by either a) applying processing logic defined in a standards track document, or b) applying a machine readable recipe (which is provided by the server) of what the transformations do exactly, I think this is a discussion worth pursuing. If, on the other hand, the suggestion is that clients should reverse engineer the black box transformation logic of each version of each type of system from each vendor and keep it up to date, then I think the potential value we're discussing here is dwarfed by the maintenance cost and interoperability concerns. So there you have it. To progress this idea of a changed definition of what "valid <running>" means, I think we would need to standardize the transformation logic in some way. There is some potential value, but surely a lot of work. Are we up for it? Best Regards, /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) <[email protected]> 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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
