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. 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? Also, as I noted earlier, memory gain is a major motivation for using templates (especially in Fiber network devices). I hope this expansion of templates in running DS doesnât mean we loose such gains. Thanks, Shiya From: Kent Watsen <[email protected]> Sent: Thursday, November 14, 2024 1:05 AM To: Shiya Ashraf (Nokia) <[email protected]> Cc: [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]
