Sorry all - I just noticed that my email client didn't thread all the responses to this topic in with the original post. It looks like this has been heavily discussed and I'll look through those emails.
From: netmod <netmod-boun...@ietf.org> On Behalf Of Sterne, Jason (Nokia - CA/Ottawa) Sent: Wednesday, December 8, 2021 5:51 PM To: maqiufang (A) <maqiufang1=40huawei....@dmarc.ietf.org>; netmod@ietf.org 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>" ? 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 ? 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> ? Jason From: netmod <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> On Behalf Of maqiufang (A) Sent: Monday, November 22, 2021 7:11 AM To: netmod@ietf.org<mailto:netmod@ietf.org> 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: * "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> * 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
