On Wed, Apr 21, 2021 at 7:48 AM Balázs Lengyel <[email protected]>
wrote:
> 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
>
>
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
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.
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.
> I consider 4) and 5) to violate the YANG standard.
> Regards Balazs
>
Andy
>
> -----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:
> [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-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
> >
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
