Hello Juergen, IMHO the server should in the order of preference: 1) ALWAYS report mandatory state data - this is the correct thing; it should happen most of the times 2) Report real data in some of the cases and deviate the mandatory=true statement to mandatory=false. - This means I deviate from the real module, but at least I publish a contract I adhere to 3) Never report the data and deviate the schema node to not-supported . - This means I strongly deviate from the real module, but at least I publish a contract I adhere to 4) Not deviate the module as described above, but do not report data 5) Report fake data - I agree that this is the worst
I consider 4) and 5) to violate the YANG standard.
Regards Balazs
-----Original Message-----
From: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>
Sent: 2021. április 21., szerda 12:32
To: Balázs Lengyel <balazs.leng...@ericsson.com>
Cc: Andy Bierman <a...@yumaworks.com>; Sterne, Jason (Nokia - CA/Ottawa)
<jason.ste...@nokia.com>; netmod@ietf.org
Subject: Re: Compatibility of config=false data
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 <a...@yumaworks.com>
> Sent: 2021. április 20., kedd 20:21
> To: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>;
> Balázs Lengyel <balazs.leng...@ericsson.com>; Sterne, Jason (Nokia -
> CA/Ottawa) <jason.ste...@nokia.com>; Andy Bierman
> <a...@yumaworks.com>; netmod@ietf.org
> Subject: Re: Compatibility of config=false data
>
>
>
>
>
>
>
> On Tue, Apr 20, 2021 at 9:26 AM Juergen Schoenwaelder
> <j.schoenwael...@jacobs-university.de
> <mailto:j.schoenwael...@jacobs-university.de> > 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 <j.schoenwael...@jacobs-university.de
> > <mailto:j.schoenwael...@jacobs-university.de> >
> > Sent: 2021. április 14., szerda 17:08
> > To: Balázs Lengyel <balazs.leng...@ericsson.com
> > <mailto:balazs.leng...@ericsson.com> >
> > Cc: Sterne, Jason (Nokia - CA/Ottawa) <jason.ste...@nokia.com
> > <mailto:jason.ste...@nokia.com> >; Andy Bierman <a...@yumaworks.com
> > <mailto:a...@yumaworks.com> >; netmod@ietf.org
> > <mailto:netmod@ietf.org>
> > 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-86
> > 073b36ea
> > 28-0d304a28a3dae2f9&q=1&e=81180de4-8958-40ba-aeb8-c689e3da33e8&u=htt
> > ps%3A%2F %2Fwww.jacobs-university.de
> > <https://protect2.fireeye.com/v1/url?k=baf9f9a4-e562c0c5-baf9b93f-86
> > d8a30ca42b-c249ef726e615faa&q=1&e=bc74e019-40cf-4237-b824-ce71a0cdcb
> > 90&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://protect2.fireeye.com/v1/url?k=d890b7b7-870b8efa-d890f72c-86b568293eb5-194b9ab47bb1629f&q=1&e=c0276ac5-8c8a-44d6-a9a9-0c536215db5a&u=https%3A%2F%2Fwww.jacobs-university.de%2F%2520%253Chttps%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D7cfb0d8b-236034ea-7cfb4d10-86d8a30ca42b-e823d1eec435af45%26q%3D1%26e%3Dbc74e019-40cf-4237-b824-ce71a0cdcb90%26u%3Dhttps%253A%252F%252Fwww.jacobs-university.de%252F>
> >
>
--
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=15fc93b5-4a67aaf8-15fcd32e-86b568293eb5-538a1e7d95e0a648&q=1&e=c0276ac5-8c8a-44d6-a9a9-0c536215db5a&u=https%3A%2F%2Fwww.jacobs-university.de%2F>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
