On Fri, Jan 13, 2017 at 12:51 AM, 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 > 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. > > Actually, a client that is not restricted by NACM can use the YANG validation just fine. There are opstate tables that churn but that is the exception. Also note that the rpc/input and action/input constraints are validated by the server, and MUST be implemented. The XPath in these contexts are allowed to reference state data (starting in YANG 1.1) > /js > Andy > > -- > 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
