[keeping netmod, bcc netconf]
On 12/01/2017 22:05, Andy Bierman wrote:
On Thu, Jan 12, 2017 at 1:59 PM, Martin Bjorklund <[email protected]
<mailto:[email protected]>> wrote:
Ladislav Lhotka <[email protected] <mailto:[email protected]>> wrote:
>
> > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder
> > <[email protected]
<mailto:[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]
<mailto:[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.
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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
