Hi, Andy, all, While I agree that the client should have complete control over <running>, and the read back of <running> should return exactly what was sent by the client (we’ve discussed this a lot in the system-config thread), I also understand there are some proprietary implementations that would evolve configuration in <running> beyond client initialization. I prefer to consider <running> in this situation as a “intended-like” datastore (it is <running>, but quite like <intended> in the design of NMDA).
In any case, I think the template solution should be able to return configuration with both unexpanded and expanded views of templates. An unexpanded view, without any transformations, can be useful for the client to check which nodes has applied which configuration templates, and it may further decide how they want to modify the current application or delete/override some nodes provided by the template, and maybe also useful for a simple and consistent view of configuration. An expanded view is needed for configuration transformation and validity check. This seems easy to achieve in NMDA (i.e., RFC8342 already states that template is unexpanded in <running> and expanded in <intended>), but I am unsure whether we need to work out a solution for non-NMDA as well. Best Regards, Qiufang From: Andy Bierman [mailto:[email protected]] Sent: Thursday, November 14, 2024 9:16 AM To: Kent Watsen <[email protected]> Cc: Shiya Ashraf (Nokia) <[email protected]>; [email protected] Subject: [netmod] Re: Mandatory/default statements and templates (was: Yang Template Proposals) On Wed, Nov 13, 2024 at 4:05 PM Kent Watsen <[email protected]<mailto:kent%[email protected]>> wrote: Hi Shiya, Where does it say <running> contains only data provided by the client in <edit-config> operations? (Nowhere) To put a finer point on this, it is a long-standing desire that changes to <running> happen only with the client’s knowledge. That said, <running> could contain config that was *generated* due to a client-instruction. For instance, the “resolve-system” flag that was recently removed from the “system-config” draft or, in Yuma’s case, an instruction that causes a template-expansion to occur at time of the <edit-config>. RFC 4741 was way before YANG existed. Even in RFC 6241, the WG was careful about leaving the datastore details to the implementation. The metadata in the edit-config operation are processing instructions. They do not get added to the datastore. The template or loop instructions are no different. I do not agree with your strict interpretation of client-initiated. A client may set a CLI parameter or otherwise direct the server to use some feature or behavior. In this template case all the data is client-provided, but even when system data is provided, it is due to the configuration settings from the operator. Kent // contributor Andy _______________________________________________ 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]
