Kent, >> 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.
Absolutely. Today the words written down in the specs are only talking about one kind of validation. Offline validation is not a concept I have been using. It's not used in the RFCs. If you think this concept has merit, it would be good if you took the time to define it. And if you also think the RFCs that currently do not use it, should use it, then by all means suggest changes. > 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). That a client with insufficient privileges may have trouble understanding or controlling a server is no surprise to me. I don't quite see why you think this observation is relevant for the discussion about whether a datastore is valid or not? >> 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. Ok, fair enough. To whom it may concern: Regarding "offline validation" or "online validation", please note that these concepts are yet undefined in any RFCs or drafts (as far as I'm aware). If you intend to use these concepts, please be so kind as to either define or point to definitions of them. >> 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. Good to hear. My preference would be that the validation rules already established in 6020, 7950 and 8342 stay close to what they are. If we decide to accommodate further use cases, that should be allowed by clients that flag awareness of extended mechanisms. Old, unaware servers and clients should be able to continue staying true to their legacy. >>> 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? Well, I'm not worried about the CLI users getting trouble. I'm worried that CLI users would cause trouble for automation clients, by for example referencing something out of the system datastore. The next time someone does a get-config towards running, it might not be valid any longer, with the RFCs' definition of valid. Best Regards, /jan _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
