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.
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