> On 13 Jan 2017, at 09:51, Juergen Schoenwaelder > <j.schoenwael...@jacobs-university.de> wrote: > > 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
These are valid reasons and could IMO be lived with, but I think we have to require "best effort" from the server. If we drop validity of state data altogether, their invalidity will be commonplace, and (I suspect) caused mainly by laziness of server implementors. That said, I would be in favour of decoupling data models of configuration and state data. If a device produces native state data in a format that's difficult to translate to a standard form, vendors could be allowed to use a proprietary model for state data. It is IMO still far better than declaring compliance to RFC XXXX on paper and then sending something else. > 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. It is all about the Postel Principle: the server should be strict, and the client may be lenient. It also depends on the character of the state data and specific aspect of validity (broken leafref is not the same as missing mandatory leaf). Lada > > /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/> > > _______________________________________________ > Netconf mailing list > netc...@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
