Hi,
IMO the YANG data model constraints are too domain-specific to generalize.
If the designer is adding a constraint (must, when. min-elements -- makes
no difference)
then if must matter to that specific data model. It is not a SHOULD, but a
MUST.
Otherwise YANG has no value to data model designers.
Seems to me that your proposal combines 'applied' and 'operational'
incorrectly.
The only type of object that should be de-duplicated is the clone of
config-foo
for the sake of providing the oper-foo value (which could be supplied by
the get-oper RPC instead).
It is the 'applied' datastore that is not subject to validation, not the
operational datastore.
Combining trees doesn't work if the 'normal' config=false nodes are placed
under
a list or P-container. There is no way to instantiate these nodes unless
the ancestor
config nodes also exist.
The openconfig design pattern is getting phased out.
This never involved 2 trees anyway
grouping config-X { .... }
uses config-X {
augment . {
container oper {
config false;
uses config-X;
}
}
}
I don't see how combining the ancestor top-level node with another one
makes any difference to the solution.
Andy
On Fri, Jan 13, 2017 at 8:21 AM, Robert Wilton <[email protected]> wrote:
> [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]> 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.
> 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]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
>
> _______________________________________________
> netmod mailing [email protected]https://www.ietf.org/mailman/listinfo/netmod
>
>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
