Hi, “E.g., if the template picks an if-type based on the interface name then <running> validation will fail.” <Shiya> Exactly. <running> is always un-expanded data. So it becomes difficult to templatise a mandatory data node as these data nodes must exist in the running DS in all the entries anyways, to pass the validation. I think these are important features to support to take full advantage of templates.
“ If any client configures data that references the interface 'type' field, that validation will fail. “ <Shiya> Indeed, another failure point. I guess such cases can only be solved on a case by case basis (i.e. for e.g. if the reference is a leafref, we may make it require-instance false; references in must/when also needs careful analysis etc). “NMDA seems to defeat the main purpose of templates.“ Why do you think its NMDA specific? The <running> DS in any case is what the client configured (i.e. un expanded data). So if mandatory not present, running validation will fail even in non-NMDA right? Thanks, Shiya From: Andy Bierman <[email protected]> Sent: Wednesday, November 13, 2024 10:49 PM To: Shiya Ashraf (Nokia) <[email protected]> Cc: Kent Watsen <[email protected]>; [email protected] Subject: Re: [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. On Wed, Nov 13, 2024 at 1:39 PM Shiya Ashraf (Nokia) <[email protected]<mailto:[email protected]>> wrote: Hi, Consider a template that defines some interface data nodes using ietf interfaces yang model. Leaf node “type” is a mandatory data node according to RFC 8343. +--rw interfaces +--rw interface* [name] +--rw name string +--rw description? string +--rw type identityref So even if you have defined the “type” of the interface in the templates, you will be forced to set this at the reference point as well. Isn’t it? It depends if NMDA is used I guess. The validation is done on the datastore, not the RPC input. If the datastore contains the combined entry from the client and the template(s), then everything works fine. If not, then it will not be possible for <running> to pass validation tests. E.g., if the template picks an if-type based on the interface name then <running> validation will fail. If any client configures data that references the interface 'type' field, that validation will fail. NMDA seems to defeat the main purpose of templates. Thanks, Shiya Andy From: Andy Bierman <[email protected]<mailto:[email protected]>> Sent: Wednesday, November 13, 2024 6:36 PM To: Kent Watsen <[email protected]<mailto:kent%[email protected]>> Cc: Shiya Ashraf (Nokia) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [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<http://nok.it/ext> for additional information. On Wed, Nov 13, 2024 at 8:35 AM Kent Watsen <[email protected]<mailto:kent%[email protected]>> wrote: 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>) Agreed. This is easily accomplished by using an 'anydata' wrapper for the template content. <template> <name>template1</name> <target>/ietf-interfaces:interfaces/interface</target> <data> <interface> .... </interface> <data> </template> This solution has been in deployment for over 7 years. https://github.com/YumaWorks/yumapro-yang/blob/main/yumaworks/yumaworks-templates.yang IMO the WG should try to support more than the basics (like ranges and conditional logic). FWIW, I was referring to Slide 8 of Template Idea #1. K. Andy <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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
