Hi, Jason Thanks for kicking off some discussion around this question. Please see my reply inline.
From: Sterne, Jason (Nokia - CA/Ottawa) [mailto:[email protected]] Sent: Thursday, December 9, 2021 6:51 AM To: maqiufang (A) <[email protected]>; [email protected] Subject: RE: [netmod] Should the "with-origin" parameter be supported for <intended>? Hi Qiufang, In your first option, did you mean "understand a certain data node is from <running> or from <system>" ? [Qiufang Ma] Yes, you're correct. We already define that a data node which is present in <system> and not overwritten by <running> will appear in <operational> with "origin=system" as always when applied successfully. So the server needs to remember whether a particular data node in <intended> is from <running> or from <system>. The question is should the server expose this source information to the client. It is an interesting question about whether the origin annotation could/should be available in a read from <intended>, and what values that origin could take. We should consider other transformations between <running> and <intended> (besides the merging of <system>): - active/inactive config - configuration templates Inactive config would simply be stripped and not appear in <intended> at all. So nothing to discuss for that. But would elements provided from within config templates have an 'origin' that indicates what template it came from ? [Qiufang Ma] I am not quite sure what do you mean by "what template it came from". But for the client-defined template in <running>, elements provided from within the config template will exist in <intended> and finally have an origin="intended" when present in <operational>. I believe that this is already well defined in NMDA work. I suppose the same question could apply to 'origin' in the <operational> DS. Having origin purely available in the operational DS may not be complete enough. Some config nodes may not be present in operational because they are not "applied". So you wouldn't necessarily be able to get the full picture of the origin of all intended config by just checking the origin in the <operational> DS. Maybe that's an argument to have an origin in <intended> ? [Qiufang Ma] That is a good point. <operational> only contains those are actually used by the system. It might be useful if a client can fetch <intended> can understand the origin of some data nodes which is after configuration transformation(e.g., client-defined/system-defined templates expansion) but may not be successfully applied by the device. Best Regards, Qiufang Ma Jason From: netmod <[email protected]<mailto:[email protected]>> On Behalf Of maqiufang (A) Sent: Monday, November 22, 2021 7:11 AM To: [email protected]<mailto:[email protected]> Subject: [netmod] Should the "with-origin" parameter be supported for <intended>? Hi, all In the "system-defined configuration(draft-ma-netmod-with-system)" work, an optional datastore named "system" is introduced to hold non-deletable system configurations. We define that if a server implements <intended>, <system> MUST be merged into <intended>. So there is the cases that the clients can fetch <intended> and <intended> contains merged <system>. The question is should we extend the "with-origin" parameter to support <intended>? The possible considerations for following two choices: o "with-origin" parameter should be supported for <intended> ? It may be helpful for a client to fetch <intended> to understand a certain data node is from <running> or from <intended> o There is no need for <intended> to support "with-origin" ? We already have <operational> to provide the origin for a particular data node Any thoughts on this? Best Regards, Qiufang Ma
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
