Subject: [netmod] Compatibility of config=false data

From: Balázs Lengyel <[email-masked]>
Date: Tue, 20 Apr 2021 15:35:28 +0000

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-masked]> 
Sent: 2021. április 14., szerda 17:08
To: Balázs Lengyel <[email-masked]>
Cc: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; Andy Bierman
<[email-masked]>; [email-masked]
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%2F>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 20 Apr 2021 18:26:31 +0200

My understanding is that a <get> returns the leafs that exist and that
are not filtered.

/js

-- 
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/>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 20 Apr 2021 11:20:49 -0700

> My understanding is that a <get> returns the leafs that exist and that
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

> > <
> https://protect2.fireeye.com/v1/url?k=9e758f86-c1eeb764-9e75cf1d-86073b36ea
> >

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 21 Apr 2021 08:45:02 +0000

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-masked]> 
Sent: 2021. április 20., kedd 20:21
To: Juergen Schoenwaelder <[email-masked]>; Balázs Lengyel <[email-masked]>; Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; Andy Bierman <[email-masked]>; [email-masked]
Subject: Re: Compatibility of config=false data

On Tue, Apr 20, 2021 at 9:26 AM Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]> > wrote:

 

/js

Andy

On Tue, Apr 20, 2021 at 03:35:28PM +0000, Balázs Lengyel wrote:
> From: Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]> > 
> To: Balázs Lengyel <[email-masked] <mailto:[email-masked]> >
> Cc: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]> >; Andy Bierman
> <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
> %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> >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 21 Apr 2021 12:32:28 +0200

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

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 21 Apr 2021 14:48:05 +0000

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-masked]> 
Sent: 2021. április 21., szerda 12:32
To: Balázs Lengyel <[email-masked]>
Cc: Andy Bierman <[email-masked]>; Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; [email-masked]
Subject: Re: Compatibility of config=false data

RFC 7950 section 8:

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:
> To: Juergen Schoenwaelder <[email-masked]>; 
> Balázs Lengyel <[email-masked]>; Sterne, Jason (Nokia - 
> CA/Ottawa) <[email-masked]>; Andy Bierman 
> > 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?
> > 
> > From: Juergen Schoenwaelder <[email-masked] 
> > <mailto:[email-masked]> >
> > Cc: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked] 
> > <mailto:[email-masked]> >; Andy Bierman <[email-masked] 
> > <mailto:[email-masked]> >; [email-masked] 
> > <mailto:[email-masked]>
> > 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>
> 
> 
> 
> -- 
> 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>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 21 Apr 2021 08:10:39 -0700

On Wed, Apr 21, 2021 at 7:48 AM Balázs Lengyel <[email-masked]>
wrote:

> 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

IMO mandatory-stmt has no meaning for config=false.
In fact, validation for config=false was never properly considered and it
has 2 major flaws:

1) mandatory means nothing for config=false data nodes

The server doesn't get to decide "maybe I will return /foo counter values
today"
because mandatory=false.  I brought this issue up years ago and Martin
clarified
the issue (can't find it now).

Mandatory-stmt does not alter module conformance.
Only if-feature=false can do that (and deviations of course).
Unless a filter or NACM removes the data node, then a <get-data> on
<operational>
is supposed to return the requested data if it exists. Period.

 Constraints on Data

   o  If the constraint is defined on notification content, it MUST be
      true in any notification data tree.

   o  If the constraint is defined on RPC or action input parameters, it
      MUST be true in an invocation of the RPC or action operation.

   o  If the constraint is defined on RPC or action output parameters,
      it MUST be true in the RPC or action reply.

It is not clear that bullet 5 really applies to content within the <config>
parameter.
It clearly applies to the nodes specified in the rpc or action "output"
statement.
It seems that bullet 2 does not apply because the client does not have the
state data tree, it has an <rpc-reply> element.

2) must-stmt constraints are purely theoretical in the rpc-reply XPath
context

Again, it is not clear at all that constraints defined in YANG models are
part of the
validation within an <rpc-reply>.  Clearly the output parameters are
validated but
not at all clear whether a state data tree can exist in an <rpc-reply> or
only in a server.

Since the XPath context allows config and state data from OUTSIDE the
<rpc-reply>,
it is clearly impossible for a client to have BOTH the server state data
tree
and the <rpc-reply> from the same moment in time.  This conceptual
evaluation
is never actually done on the server, but that is how the constraint is
defined.

Since these constraints are rare it is not an urgent issue, but it should
be addressed
if yang-next is ever chartered.

Andy

> 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
>
> > *     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
> >
> >
> >
> [email-masked] <mailto:
> [email-masked]> > wrote:
> >
> > 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>
> >
> >
>
>
>
> --
> 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
> >
>

---

From: Italo Busi <[email-masked]>
Date: Wed, 21 Apr 2021 17:21:19 +0000

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

> From: Balázs Lengyel [mailto:[email-masked]]
> Sent: mercoledì 21 aprile 2021 16:48
> To: Juergen Schoenwaelder <[email-masked]>
> Cc: Andy Bierman <[email-masked]>; Sterne, Jason (Nokia - CA/Ottawa)
> <[email-masked]>; [email-masked]
> Subject: Re: [netmod] Compatibility of config=false data
> 
> Hello Juergen,
> This means I strongly deviate from the real module, but at least I publish a
> contract I adhere to
> Cc: Andy Bierman <[email-masked]>; Sterne, Jason (Nokia - CA/Ottawa)
> <[email-masked]>; [email-masked]
> 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.
> 
> we want the state data to be as close as possible to the ground truth and we
> 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
> >
> >
> >
> > On Tue, Apr 20, 2021 at 9:26 AM Juergen Schoenwaelder
> <[email-masked] <mailto:j.schoenwaelder@jacobs-
> university.de> > wrote:
> >
> <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> >
> >
> 
> 
> 
> --
> <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>

---

From: Vladimir Vassilev <[email-masked]>
Date: Thu, 22 Apr 2021 11:07:52 +0200

> IMO mandatory-stmt has no meaning for config=false.

This is not spelled out in the current version of YANG. Instead one can 
assume that using config=false, mandatory=false leafs is the correct way 
to model optional information fields. There is nothing formal in RFC7950 
that contradicts that. This interpretation seems to be one solution when 
the implementation has to handle different equipment instances where 
some support certain information fields and others do not. An 
alternative solution would require the overhead of defining an extra 
leaf for each optional leaf indicating if the information is present or 
not or adding an invalid value to the value space of the leaf 
representing the optional information.

That said I do not think this optional information fields modelling 
technique was the intention in the majority of published modules that do 
not specify mandatory-stmt in config=false nodes. It is just that 
RFC7950 has mandatory=false specified as default and this works better 
for config=true nodes then config=false nodes.

/Vladimir

---

From: Kent Watsen <[email-masked]>
Date: Thu, 22 Apr 2021 15:06:44 +0000

> That said I do not think this optional information fields modelling technique was the intention in the majority of published modules that do not specify mandatory-stmt in config=false nodes. It is just that RFC7950 has mandatory=false specified as default and this works better for config=true nodes then config=false nodes.

I tend to agree.  Furthermore, I feel that it is best practice to specify "mandatory true” when it is the intention that the “config false” node is always provided.

There are effectively three kinds of “config false” leafs:
  1) opstate data
  2) rpc/action replies
  3) notifications 

IMO, the “best practice” holds in all three cases, but it might be interesting to consider each in turn.

Note that I wrote “intention” above.  It is understood that a system may not be able to provide the “mandatory” node, but I wonder how much of that statement is supported by data.

K.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Apr 2021 08:24:59 -0700

> for config=true nodes then config=false nodes.
I misspoke.
The mandatory-stmt applies to the top-level leaf.
A valid state data tree must have the leaf instance present at all times.
If mandatory=false then this instance is optional.

So if a client has a complete copy of the server state data tree then the
mandatory-stmt
validation can be checked.

I doubt any server implementation would ever validate its own output.
This is a slow and expensive way to discover bugs in your own code.

I don't think the WG gave much thought
to the issue of client validation of server config=false state data.
Several WG members have expressed thoughts on the wisdom of
sending an unfiltered <get> request to the server, in order to obtain a
complete
state data tree.

/Vladimir

Andy