Which problem is solved by adding additonal rules and constraints?
I am a big fan of the separation of mechanism and policy. How someone
uses a mechanism to mask tags should be left open to whoever uses this
mechanisms. If someone wants to mask a user level tag, so be
it. Consider someone does not like the 'foo' tag and he is dealing
with servers there some (newer) severs have 'foo' defined as a model
tag while others have defined it as some other tag. Being able to mask
'foo' on all servers (regardless their software versions) simplifies
things.
Your proposed new text is vague. Is a server to reject an edit if
someone masks a system tag? Or worse, does "not applied" mean the
sever accepts the instruction to mask 'foo' but then does not mask the
tag? If you propose to make something a hard error, then I would
expect more explicit text. I vote for not making this an error.
/js
On Wed, Aug 24, 2022 at 03:39:47AM +0000, Qin Wu wrote:
> Hi, All:
> In IETF 114, one issue we discussed for draft-ietf-netmod-node-tags is about
> mask-tag usage, we use mask-tag to remove the tag.
> actually we have two options to remove the tag, one is using edit-data
> protocol operation to delete the tag,
> the other is to use mask-tag to remove tag. so the question when to use
> mask-tag to remove tag and when to use edit-data operation to delete the tag,
> what is their priority.
> Since the tag can either schema level tag or instance level tag, the original
> proposal is only using mask-tag to remove schema level tag, which is static
> tag, the tag will disappear
> from operational datastore, but it still exists in the model schema.
> But for instance level tag, it is actually user configured tag, I think we
> can skip to use mask-tag, just use edit-data operation to add tag and remove
> tag. The reason to skip to use mask tag, becos, the mask tag is only applied
> to schema level tag or static tag.
> Here is the proposed changes to section 7:
> OLD TEXT:
> "
> leaf-list masked-tag {
> type tags:tag;
> description
> "The list of tags that should not be associated with the
> node within the YANG module. The user can remove
> (mask) tags from the operational state datastore by
> adding them to this list. It is not an error to add tags
> to this list that are not associated with the data
> node within YANG module, but they have no operational
> effect.";
> "
> NEW TEXT:
> "
> leaf-list masked-tag {
> type tags:tag;
> description
> "The list of tags that should not be associated with the
> node within the YANG module. The user can remove
> (mask) tags from the operational state datastore by
> adding them to this list. It is not an error to add tags
> to this list that are not associated with the data
> node within YANG module, but they have no operational
> effect. Note that the tags described here are limited to system tags
> not applied to user configured tags. ";
> "
> OLD TEXT:
> "
> The 'operational' state view of this list is
> constructed using the following steps:
>
> 1) System tags (i.e., tags of 'system' origin) are added.
> 2) User configured tags (i.e., tags of 'intended' origin) are added.
> 3) Any tag that is equal to a masked-tag is removed.";
> "
> NEW TEXT:
> "
> The 'operational' state view of this list is
> constructed using the following steps:
>
> 1) System tags (i.e., tags of 'system' origin) are added.
> 2) User configured tags (i.e., tags of 'intended' origin) are added.
> 3) Any system tag that is equal to a masked-tag is removed.
> 4) User configured tags can be removed using standard protocol
> operation.
> ";
> "
>
> -Qin
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
--
Jürgen Schönwälder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
