Hi, “This "client-only" rule for <running> does not exist in the RFCs. “ <Shiya> I see, I need to think how it will work if the device have a different view of the config than the client. But anyways, if you are storing the expanded data in <running>, what are you then actually aiming to gain with the templates. Only less data over the wire? One of the main motivation for me to use templates is the much lesser memory foot print it leaves on the device.
“No. There are no such rules for the <running> datastore or edit-config operation.“ <Shiya> I read in RFC 7950, Section 8.1 - The running configuration datastore MUST always be valid. Is this specific for NMDA? I am a bit lost ☹. Sorry if I am overlooking some basics. Thanks, Shiya From: Andy Bierman <[email protected]> Sent: Wednesday, November 13, 2024 11:43 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 2:35 PM Shiya Ashraf (Nokia) <[email protected]<mailto:[email protected]>> wrote: 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. Maybe in your server <running> is always unexpanded data. This "client-only" rule for <running> does not exist in the RFCs. The client configures the template, sends an edit request specifying the template to use, and provides the partial entry that needs to be filled in by the template. IMO this just a different kind of edit than a plain edit-config. “ 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). failure only if <running> is missing all the pre-staged client template data. “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? No. There are no such rules for the <running> datastore or edit-config operation. Thanks, Shiya Andy From: Andy Bierman <[email protected]<mailto:[email protected]>> Sent: Wednesday, November 13, 2024 10:49 PM To: Shiya Ashraf (Nokia) <[email protected]<mailto:[email protected]>> Cc: Kent Watsen <[email protected]<mailto:kent%[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 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]
