Balazs, Few questions for clarification
In case 3, is it required to deviate the schema node to not-supported or would it be also possible to deviate it as mandatory=false? How would you consider the definition of some "special" value (e.g., 0 in case of integer or "unknown" in case of enumeration) as a way to report "fake" data? Are these rules written or planned to be written somewhere? Thanks, Italo > -----Original Message----- > From: Balázs Lengyel [mailto:[email protected]] > Sent: mercoledì 21 aprile 2021 16:48 > To: Juergen Schoenwaelder <[email protected]> > Cc: Andy Bierman <[email protected]>; Sterne, Jason (Nokia - CA/Ottawa) > <[email protected]>; [email protected] > Subject: Re: [netmod] Compatibility of config=false data > > 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 <[email protected]> > Sent: 2021. április 21., szerda 12:32 > To: Balázs Lengyel <[email protected]> > Cc: Andy Bierman <[email protected]>; Sterne, Jason (Nokia - CA/Ottawa) > <[email protected]>; [email protected] > 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 <[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:j.schoenwaelder@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 <[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-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%2 > Furl%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> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
