On Wed, Nov 13, 2024 at 3:33 PM Shiya Ashraf (Nokia) <[email protected]> wrote:
> 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? > > > Where does it say <running> contains only data provided by the client in <edit-config> operations? (Nowhere) > I am a bit lost ☹. Sorry if I am overlooking some basics. > > > > Thanks, > > Shiya > > > Andy > > *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]> 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]
