> On 12 Jan 2017, at 23:05, Andy Bierman <a...@yumaworks.com> wrote:
> 
> 
> 
> On Thu, Jan 12, 2017 at 1:59 PM, Martin Bjorklund <m...@tail-f.com> wrote:
> Ladislav Lhotka <lho...@nic.cz> wrote:
> >
> > > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder
> > > <j.schoenwael...@jacobs-university.de> 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 <
> > >> j.schoenwael...@jacobs-university.de> 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67





_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to