RFC 7950 section 8:
Several YANG statements define constraints on valid data. These
constraints are enforced in different ways, depending on what type of
data the statement defines.
o If the constraint is defined on configuration data, it MUST be
true in a valid configuration data tree.
o If the constraint is defined on state data, it MUST be true in a
valid state data tree.
The main difference between configuration data and state data is that
a server can keep the configuration data in a valid state by rejecting
any changes that make the configuration data invalid. If, however, a
server reports an invalid state data tree, then obviously the server
did choose to do so and the clients may have to deal with it (which
includes the option of the client to reject all state data since it is
invalid, but that might not always be the best or most desirable
option).
If there is a mandatory state leaf that the server can't implement,
what should the server do? The worst of all possible solutions is to
report a fake leaf. This has happened quite a bit in the history of
SNMP and this is really really bad. Instead of reporting fake values,
it is far better to not report the leaf so that the deviation is
clear. Ideally, the server formally declare the deviation and all is
good.
When the NMDA document was put together, the intention was to say that
we want the state data to be as close as possible to the ground truth
and we rather do not want systems to report fake leafs.
/js
On Wed, Apr 21, 2021 at 08:45:02AM +0000, Balázs Lengyel wrote:
> Hello Andy,
>
> While NMDA states “it is possible that constraints MAY be violated under some
> circumstances”
>
> * this was never declared for non-NMDA systems, so IMHO a client can
> reasonably assume that if mandatory=true for a config=false node was declared
> the reason is that it will always be present; otherwise it should simply be
> mandatory=false.
> * IMHO this allowance for the operational datastore is for extra-ordinary
> situations. In the normal case as defined in the NMDA-RFC“<operational>
> SHOULD conform to any constraints specified”.
>
>
>
> Regards Balazs
>
>
>
> From: Andy Bierman <[email protected]>
> Sent: 2021. április 20., kedd 20:21
> To: Juergen Schoenwaelder <[email protected]>; Balázs
> Lengyel <[email protected]>; Sterne, Jason (Nokia - CA/Ottawa)
> <[email protected]>; Andy Bierman <[email protected]>; [email protected]
> Subject: Re: Compatibility of config=false data
>
>
>
>
>
>
>
> On Tue, Apr 20, 2021 at 9:26 AM Juergen Schoenwaelder
> <[email protected]
> <mailto:[email protected]> > wrote:
>
> My understanding is that a <get> returns the leafs that exist and that
> are not filtered.
>
>
>
> Yes -- this is what clients expect.
>
> It is not clear that real client apps rely too much on YANG validation of
>
> the config=false nodes in <operational>.
>
>
>
> The validation of server provided monitoring data was not a focus of YANG.
>
> It may not be valid to assume every sentence that applies to config=true
>
> also applies to config=false.
>
>
>
> Even the NMDA RFC ignores YANG validation of config=false nodes.
>
> There is a paragraph that says it SHOULD be done, but it really refers
>
> to how operational values of config=true MAY not pass validation.
>
>
>
>
>
> /js
>
>
>
> Andy
>
>
>
>
> On Tue, Apr 20, 2021 at 03:35:28PM +0000, Balázs Lengyel wrote:
> > Hello Juergen,
> > https://tools.ietf.org/html/rfc7950#section-7.6.5 states:
> >
> > If "mandatory" is "true", the behavior of the constraint depends on
> > the type of the leaf's closest ancestor node in the schema tree that
> > is not a non-presence container (see Section 7.5.1):
> > o If no such ancestor exists in the schema tree, the leaf MUST
> > exist.
> > o Otherwise, if this ancestor is a case node, the leaf MUST exist if
> > any node from the case exists in the data tree.
> > o Otherwise, the leaf MUST exist if the ancestor node exists in the
> > data tree.
> >
> > Let's take the simplest example a top level leaf. If it is mandatory=true ->
> > the leaf MUST exist. The above statements do not differentiate between
> > config=true or config=false leaves.
> >
> > If the leaf exists, for me, it is trivial that the reply to a get/get-data
> > operation MUST return it. (assuming it is not filtered out)
> > Anything else would be counter-intuitive and IMHO contradict RFC 7950.
> >
> > Do you agree?
> > If not, could you please describe what does a mandatory=true statement mean
> > for a config=false leaf in your interpretation?
> >
> > -------------------------------------------------------------------
> > IMHO we never stated that
> >
> >
> > Regards Balazs
> >
> > -----Original Message-----
> > From: Juergen Schoenwaelder <[email protected]
> > <mailto:[email protected]> >
> > Sent: 2021. április 14., szerda 17:08
> > To: Balázs Lengyel <[email protected]
> > <mailto:[email protected]> >
> > Cc: Sterne, Jason (Nokia - CA/Ottawa) <[email protected]
> > <mailto:[email protected]> >; Andy Bierman
> > <[email protected] <mailto:[email protected]> >; [email protected]
> > <mailto:[email protected]>
> > Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13
> >
> > On Wed, Apr 14, 2021 at 01:55:04PM +0000, Balázs Lengyel wrote:
> >
> > > * On the other hand, changing a state leaf from mandatory false to
> > true means always including the leaf in a <get> response.
> >
> > Where do you get this from?
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax: +49 421 200 3103
> > <https://protect2.fireeye.com/v1/url?k=9e758f86-c1eeb764-9e75cf1d-86073b36ea
> > 28-0d304a28a3dae2f9&q=1&e=81180de4-8958-40ba-aeb8-c689e3da33e8&u=https%3A%2F
> > %2Fwww.jacobs-university.de
> > <https://protect2.fireeye.com/v1/url?k=baf9f9a4-e562c0c5-baf9b93f-86d8a30ca42b-c249ef726e615faa&q=1&e=bc74e019-40cf-4237-b824-ce71a0cdcb90&u=http%3A%2F%2F2fwww.jacobs-university.de%2F>
> > %2F>
>
>
>
> --
> Juergen Schoenwaelder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <https://www.jacobs-university.de/
> <https://protect2.fireeye.com/v1/url?k=7cfb0d8b-236034ea-7cfb4d10-86d8a30ca42b-e823d1eec435af45&q=1&e=bc74e019-40cf-4237-b824-ce71a0cdcb90&u=https%3A%2F%2Fwww.jacobs-university.de%2F>
> >
>
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
