> On 12 Jan 2017, at 23:05, Andy Bierman <[email protected]> wrote: > > > > On Thu, Jan 12, 2017 at 1:59 PM, Martin Bjorklund <[email protected]> wrote: > Ladislav Lhotka <[email protected]> wrote: > > > > > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder > > > <[email protected]> wrote: > > > > > > On Thu, Jan 12, 2017 at 09:38:46AM -0800, Andy Bierman wrote: > > >> On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder < > > >> [email protected]> wrote: > > >> > > >>> On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote: > > >>>> > > >>>> YANG statements: > > >>>> - It is not possible to define these statements so they are different > > >>>> for config and oper > > >>>> - must > > >>>> - when > > >>>> - unique > > >>>> - key > > >>>> - min-elements > > >>>> - max-elements > > >>>> - leafref (path) > > >>>> - if-feature > > >>>> - deviation > > >>>> - type (or any sub-statements of type-stmt) > > >>>> - status > > >>>> - description > > >>>> - reference > > >>> > > >>> Considering statements that constraint 'values', it is not entirely > > >>> clear to me what they mean for state nodes. If a server has > > >>> operational state that violates a must or range or ... constraint in > > >>> the YANG model, what is the server expected to do? > > >>> > > >> > > >> The client uses the YANG validation to check on what the server is > > >> sending. > > >> The server is buggy if it is sending data that violates YANG > > >> constraints. > > >> If any of these statements need to be different for config and oper > > >> then the old style YANG has to be used instead. > > >> > > > > > > OK. So the client does the validation. What does the client do if the > > > operational state it got is not valid according to the YANG > > > constraints? > > > > Don't forget that data models also provide guidelines to server > > implementors. > > Yes, and that it is all that can be done currently. I don't think any > implemention that receives a <get> request today freezes the system in > order to get a guaranteed consistent snapshot. Instead, the different > subsystems will be queried, sequentially or in parallell, and the end > result is shipped to the client. The result may or may not be > consistent. > > > > So this thread is questioning why YANG allows constraints on config=false > data nodes.
Partly it is a fault of YANG spec because RFC 7950 only says in sec. 8.1 that The running configuration datastore MUST always be valid. This is exactly what I would like to remove. *Any* data tree for which we have a corresponding YANG data model can be validated, and it is IMO up to a particular management application (with a certain datastore model) to decide what needs to be validated and what not. A particular workflow, datastore model and validation procedure can also be standardized, but it should be done outside the YANG spec. Lada > 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. > > > > /martin > > > Andy > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
