On Thu, Jan 12, 2017 at 02:05:07PM -0800, Andy Bierman wrote: > > So this thread is questioning why YANG allows constraints on config=false > data nodes. >
The point I am trying to make is that for configuration data, we have a clear model what validation means and when it is applied. The basic idea is that the running configuration of a system is always valid and configuration changes will never leave the running configuration in an invalid state, i.e., configuration change requests are rejected if they would leave to invalid configuration state. For operational state data, it is not entirely clear where and when validation will occur or if it will occur at all. In fact, if a system is in a weird state, it might actually be useful for certain purposes to expose the weird state. And, as Martin pointed out, inconsistencies may also result from the technical difficulties to take a consistent snapshort of a system with several concurrent subsystems. For these reasons, the assumption that a server always returns valid operational state data is likely not true. > From the generic toolbuilder POV, it allows the YANG engine to > report issues to the operator without custom programming for each > little issue. Who knows why the foo-table requires 3 entries to be > valid min-elements 3). The tool can report to the operator > "foo-table does not have enough entries" and let the operator decide > what to do about it. Yes, it will be up to the client's functionality and its implemention specifics to deal with the question whether it is useful to validate operational state data or what to do if the received operational state data is invalid. While servers are expected to be strict about the validity of configuration data, I think clients need to be lenient about the validity of operational state data. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
