On Thu, Apr 22, 2021 at 2:07 AM Vladimir Vassilev <
[email protected]> wrote:

>
> On 21/04/2021 17.10, Andy Bierman wrote:
> >
> > 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.
>
>
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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to