[keeping netmod, bcc netconf]

On 12/01/2017 22:05, Andy Bierman wrote:


On Thu, Jan 12, 2017 at 1:59 PM, Martin Bjorklund <m...@tail-f.com <mailto:m...@tail-f.com>> wrote:

    Ladislav Lhotka <lho...@nic.cz <mailto:lho...@nic.cz>> wrote:
    >
    > > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder
    > > <j.schoenwael...@jacobs-university.de
    <mailto: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
    <mailto: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. 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.

The constraint checking that you describe sounds more like a "should" statement than a "must" statement.

I can't see that a server would want to validate must constraints on config false nodes when it is the source of that data, for several reasons: - it is unclear what, if anything, it could do if one of the constraints fails.
- it wouldn't want the extra validation processing overhead.
- there would be an assumption that the data generated should conform to the model anyway.

Further, a client cannot reject a pushed notification or GET response from a server even if it doesn't conform with the constraints. I agree that the checking that you describe above could be useful to flag problems, although I'm not sure how easily an automated client would be able to deal with them anyway.

One of the strong stated desired from the OpenConfig operators is that a device should accurately report what is is actually doing. The question I have is what should a device do if it wants to return a value outside of the allowable range. E.g. consider a schema that defines the maximum allowed value for leaf foo as 2, but due to some unexpected internal error, when the value is read from hardware it reports that the value is 3 instead. Another case would be if the server wanted to return a value outside the specified range for a given type.

In these cases, depending on the encoding used, it may not be possible to return a value at all. If this is a GET request then the server can return a error for the particular leaf path. Does an equivalent solution for notifications also exist?

Rob




    /martin


Andy

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




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

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

Reply via email to