Kent, all, >>> 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? > > It’s related to if offline validation can succeed or not. Effectively, all > but the "recovery session” clients will not be able to offline-validate an > update to <running> prior to pushing config to the server.
I'm not sure why you say so. In my field experience, NACM is seldom, if ever, an issue for validation. Clients may have a full or partial view of the server, but even when partial, I can't recall seeing a case where that subset has been broken from a validity standpoint. Whoever is responsible for the deployment makes sure the client sees what it needs to see, and that that in itself is a consistent, valid (subset of) running. > That RFC 8341 doesn’t even mention this fact suggests that “validation” is a > concept that only manifests in servers. Just pointing to evidence of > precedence is all. I disagree :-) I don't think this is something we have agreed, and I don't see the point with this stance. In what way is the world a better place if we take this "suggestion" seriously? > Of course, I strongly support client-validation prior to push. My > recommendation is that clients, when interacting with an NMDA-server, learn > how to “cook” <intended> and validate that instead of just <running>. Great. While it sounds very nice to be able to validate both running and intended properly, establishing agreement on one particular industry wide recipe for how to cook running into intended sounds hard, and at the very least some way off. Even if we would agree on the cooking, I still think running needs to remain valid(*). Running is the interface that clients can interact with, and they should have a clear definition of what the contract looks like without spending an hour in the kitchen. *) Validity, as defined today, concerns running. It does not involve resolving templates etc. While intended should also be validated, as mentioned in 8342, there are no clear rules for how that validation should happen. Clearly it would be possible for a client to come up with a config that is valid in running, but gibberish in intended. The server is, already today, free to reject such a config. That this final part of the validation cannot happen in running is no argument for not validating running, and allowing running to violate the YANG constraints defined for it. > The question is what to do about legacy clients? > > First, we need to discuss what an “aware” (i.e., not “legacy”) client is. It > seems that “awareness" would have to be more than just understanding that > <intended> exists; the client would also have to understand each “cooking” > step (pruning inactive nodes, expanding templates, merging system nodes, > etc.) the server supports. There would need to be a client- compatibility > check such that, if the client doesn’t understand all of the steps, then it > must NOT proceed (aside: this reminds me of the “critical” extension that > Lada and I discussed before). Actually, we might consider reversing the > handshake and instead have the client present to the server a list of all the > “critical” things it understands and for the server to effectively drop the > client if it’s missing anything, since clients cannot predict what new > critical things may arise, there could be no false-positives. Warning, we’re > deep into NETCONF-next and RESTCONF-next territory here. Yes, if we agree to let legacy clients and servers behave as specified in the RFCs, we could come up with very creative things for "aware" systems. Some of that might be in *-next territory, but much of it could also happen today, as long as we have mutual consent from the participants. > It might turn out that the server, once upgraded to support “next” stuff, can > ONLY interact with next-clients. If so, there would be never be a mix of > legacy and not-legacy clients, and thus this entire hybrid-client > compatibility concern disappears. Even if I think the industry usually goes for evolution rather than revolution, I'm fine with that. As long as we get some value return for the work, and it doesn't break what's out there already, it's worth discussing. /jan _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
