Hi Jan, > Here you are introducing two concepts that the RFCs (6020, 7950, 8342) are > never mentioning: online and offline validation. Then you say that because > the RFCs don't talk about these concepts, the behavior is undefined. I > strongly disagree. The RFCs talk about validation, and describes the rules > for how that happens. These rules always apply, regardless of online, offline > or the phase of the moon.
Look, specs are very simple: stuff is written down in black and white and either it’s there or not. In this case, the fact remains that there is no document I can point to that says offline validation is a thing. It is also notable that RFC 8341 say nothing about the fact that clients effected by NACM may not be able to pass validation (it’s not even mentioned). > If you think the online and offline validation concepts have merit, I would > like to see proper definitions of them, and how you would like to modify the > existing RFCs with respect to these concepts. It might also be a good idea to > update the proposed draft, which currently does not mention these concepts. This is part of the discussion we’re having now. The outcome of which may trigger clarifications to some RFCs. All fine suggestions, but replace “you” with “folks”, as it’s not on my shoulders to do any of this. > The added value and the core essence of YANG is enabling us to reason about > configurations and compute configuration changes without necessarily asking > the server if a configuration is valid by "trial and error". This is possible > because a YANG model is a detailed and reasonably complete description of the > management interface. Introducing changes to YANG that breaks this basic > premise would be dumbing down YANG, and I can't see the benefit with this > change, or how this would be compatible with YANG 1.0, or 1.1 rules. I never said offline validation shouldn’t be possible. Rather, please know that, NACM aside, my understanding of the goal of the draft is that offline validation *is* supported...but it entails clients merging their view of <running> with the server’s <system> before doing the validation (i.e., <running> alone may not be enough, see Subject line). Good news is that, since <system> is effectively static, no new round-trips are incurred. > I think the ideas behind the system datastore are interesting and in many use > cases useful. We just need to introduce them in a way that doesn't break > existing, agnostic implementations. > > I made some proposals earlier, both on the interim and privately to the draft > authors, along these lines: > > Option #1 > + We could have a new system datastore that technically is a part of running. > Everything in system would show up in running to clients unaware of the > system datastore. Every time the system datastore changes for whatever > reason, the running datastore transaction ids (if we manage to get that > concept defined), are updated > + Clients interested to see pure view of the system datastore without > anything else in running could issue a get-data towards the system datastore > + Clients interested to see a pure view of running without any system > datastore elements could issue a get-data towards running with an extra flag > called 'without-system' > + Since all system elements are already part of running, clients have no need > to copy data between the two datastores > > Option #2 > + We could have a system datastore that technically is a part of operational. > Everything in system would show up in operational to clients unaware of the > system datastore. The running datastore always maintains referential > integrity, i.e. cannot reference the system datastore. > + Clients interested to see pure view of the system datastore could issue a > get-data towards the system datastore > + Since the system datastore is not part of running, clients can already see > a pure view of running without any system datastore elements using a simple > get-data. > + Clients that are aware of the system datastore and are interested to > configure references from running to system elements would issue an edit-data > rpc with the additional flag 'resolve-system-references'. This will make the > server copy any system elements referenced into running without the client > doing so explicitly. > + Clients unaware of the system datastore would have to include (copy) > information from the system datastore to running in order to reference them. I see these as possible fallback solutions. >> In the meanwhile, can we discuss the issues around a legacy client failing >> an offline validation? In this case, a production deployment must have 1) >> deployed devices that support <system>, 2) deployed at least one client that >> supports <system>, and 3) decided to let clients start pushing config using >> <system>. While in the pre-production testing phase, it would be quickly >> discovered that all legacy clients need to be updated. By the time of going >> to production, the deployment should have all the clients updated, so it >> seems that only the forgotten (relatively insignificant) clients might have >> an offline validation of <running> failure. Is this a fair assessment? > > 1) agreed, without devices that support the system datastore, no problem > 2,3) well, a "client" in this case could very well be a CLI operator or other > management interface. Even in highly automated networks, CLI operators are > still common Sure, but there’s no impact to CLI operators as they’re effectively getting server-side validation all the time. Just saying that CLI-ops don’t seem to be effected by any of this, right? > Your description of the operations environment where the operator has full > implementation control of all clients is very different from my field > experience. Not only do I believe the situation with multiple, independent > clients is the most commonly occurring one in the real world across all > server deployments, but I also think the operator usually has limited insight > into as well as control over which specific protocol features the clients > implement. I therefore think your assessment is fair only for a minority of > field situations. Sure, there will be some shops that play it loose, but serious deployments know what is accessing their management network, whether allowed through firewall rules or admin-accounts, it shouldn’t be hard for them to round up a short-list of apps (clients) accessing their management network. I’m sure the view you obtained via in your years differs from mine. Please, provide more detail about the management practices of the kinds of shops you have in mind. Are they providing NaaS (Network as a Service)? Thanks, Kent
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
