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> On Behalf Of maqiufang (A)
Sent: Monday, November 22, 2021 7:11 AM
To: 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
