Hi Kent, all, The point of the “default” raised on slide 8 of proposal #1 is not related to YANG validation.
The issue that I raise in slide 8 of proposal #1 is the following. A data node “foo” that has a default can be used in a template configuration without problem (while configuring the template, the default can be used or another value can be explicitly configured instead). However, this same data node “foo” must not keep this default value when used in the YANG schema of the instance. Why so ? Well, imagine that the template is explicitly configured with “foo” having value 200, so, different from the default. In the general case, the vast majority of the data nodes of an instance are not explicitly configured because the expectation is that their value comes from the template. If the instance data node “foo” is left unconfigured (naively hoping to inherit 200 from the template) but still has its default 100, the default value 100 will take effect as-if it had been explicitly configured and hence 100 will overrule the value 200 coming from the template. The problem is that this default value overruling the template will happen silently, so this is very prone to unintended behaviour ! So this is why default values in instances should not be present. The issue with mandatory is that data nodes that are mandatory in templates and instances must be configured twice: once in the template (this one is OK) but also in the instance (this one is useless, value would have come from the template anyway). This causes inefficiency to the template mechanism, albeit it is less problematic than the “default” issue because it is not a silent side effect. Best regards, Robert From: Kent Watsen <[email protected]> Sent: Wednesday, November 13, 2024 5:15 PM To: Shiya Ashraf (Nokia) <[email protected]> Cc: [email protected] Subject: [netmod] Mandatory/default statements and templates (was: Yang Template Proposals) CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Shiya, On Nov 13, 2024, at 10:09 AM, Shiya Ashraf (Nokia) <[email protected]<mailto:[email protected]>> wrote: Hi Kent, Sorry but I miss the point you made with the below statement: “As a contributor, I feel that the concern is unwarranted. My belief/hope is that templates are not themselves validated when defined, but rather only the fully expanded/flattened results of templates are validated.“ Shiya>> For mandatories, the problem that was highlighted was more about following the DRY approach for templates. For instance, in the below example copied from #3, slide 6, assume if the ‘mtu’ was defined as a mandatory data node with in a non-presence container, you will be forced to add it anyway for each interface in the below example and thus loosing the advantage of templating for these special data nodes. Isn’t it? I don’t understand your comment, but I will state my worldview (as a contributor) which is: - any data model can be templatized (including already published YANG modules) - these data models may contain `mandatory` and `default` statements - templates are NOT themselves ever validated - only the post-expanded/flattened result is validated (e.g., in <intended>) FWIW, I was referring to Slide 8 of Template Idea #1. K. <interfaces> <interface yt:apply-templates=“set_physical_mtu”> <name>GigabitEthernet0/0/0/0</name> </interface> <interface> <name>GigabitEthernet0/0/0/1</name> </interface> </interfaces> Thanks, Shiya
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
