Hi, Shiya, Please see my reply inline.
From: Shiya Ashraf (Nokia) [mailto:[email protected]] Sent: Thursday, November 14, 2024 9:02 AM To: Kent Watsen <[email protected]> Cc: [email protected] Subject: [netmod] Re: Mandatory/default statements and templates (was: Yang Template Proposals) Thanks Kent, Andy for your responses and the interesting discussion. Its getting very late here, so I will have to stop with this email for today. đ RFC 8342 says in section 5.1.3 for running DS â It MAY include configuration that requires further transformation before it can be applied, e.g., inactive configuration, or template-mechanism- oriented configuration that needs further expansion. â And in section 5.1.4 for intended DS âIt represents the configuration after all configuration transformations to <running> are performed (e.g., template expansion, removal of inactive configuration) and is the configuration that the system attempts to apply. â <Shiya> For me, these two explicit statements about templates gave me an understanding that <running> stores the unexpanded data while <intended> stores the expanded. [Qiufang] Yes, thatâs my understanding as well. And I believe thatâs also the intention of authors after extensively discussion on the list. And if the RFC is open on storing either the unexpanded or expanded one in <running>, there must have been a capability defined to expose how the server actually stores these data (transformed or not) isnât it? Otherwise, how will the client know what response he get for a get-config response, isnât this important? Also if some one need to fetch the un expanded data from the device, shouldnât there already be a way defined for this as well? [Qiufang] I donât think the RFC is open on storing either the unexpanded or expanded one in <running>, RFC 8342 is clear on this point. Maybe you are referring to non-NMDA? I guess that is because config template has never been standardized in IETF. If we are going to work on this, I think this is something we need to make it clear. Also, as I noted earlier, memory gain is a major motivation for using templates (especially in Fiber network devices). [Qiufang] Maybe, but it always needs to be expanded in the datastore (e.g., <intended>). I also think other motiviations like configuration reuse and consistency assurance to reduce errors and misconfigurations. I hope this expansion of templates in running DS doesnât mean we loose such gains. [Qiufang] If it is expanded in <running> (which I hope not), I assume <running> needs the same memory space as not using the template. But still, use of templates simplifies the configuration delivery. Thanks, Shiya Best Regards, Qiufang From: Kent Watsen <[email protected]<mailto:[email protected]>> Sent: Thursday, November 14, 2024 1:05 AM To: Shiya Ashraf (Nokia) <[email protected]<mailto:[email protected]>> Cc: [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 for additional information. 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>. Kent // contributor
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
