On Wed, Nov 13, 2024 at 2:35 PM Shiya Ashraf (Nokia) <[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]> > *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]> 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]> > *Sent:* Wednesday, November 13, 2024 6:36 PM > *To:* Kent Watsen <[email protected]> > *Cc:* Shiya Ashraf (Nokia) <[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 8:35 AM Kent Watsen <[email protected]> wrote: > > Hi Shiya, > > > > On Nov 13, 2024, at 10:09 AM, Shiya Ashraf (Nokia) <shiya.ashraf= > [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] > To unsubscribe send an email to [email protected] > >
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
