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> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
