Re: [netmod] Mask tag Usage in draft-ietf-netmod-node-tags

[Qin Wu <[e-mail]>]

Hi, Jurgen:
-----邮件原件-----
发件人: Jürgen Schönwälder [mailto:[e-mail]] 
发送时间: 2022年8月24日 14:00
收件人: Qin Wu <[e-mail]>
抄送: NetMod WG <[e-mail]>; Balázs Lengyel <[e-mail]>
主题: Re: [netmod] Mask tag Usage in draft-ietf-netmod-node-tags

Which problem is solved by adding additional rules and constraints?

[Qin Wu] The problem is whether mask-tag will overrides edit protocol operation for tag removal or protocol operation overrides mask-tag,
Since one rule we followed in draft-ietf-netmod-node-tags, which is similar to RFC8819, is to use 'masked-tag' in the ietf-node-tags to indicate removing tag from <operational>, the tag can be either instance level tag or schema level tag.
But it seems we could also use standard protocol operation, e.g., edit-data, to remove instance level tag from running and therefore disappear in <operational>.
In such situation, whether we should forbid using one and allow use the other, whether mask-tag should have higher priority. This was actually issue raised in IETF 114.

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.

[Qin Wu] Tend to agree, the mask-tag in the original proposal is more powerful and can be used to remove both system tag and user configured tag, now I add some text to limit its use, make it only applicable to system tag which seems not reasonable.

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.
[Qin Wu] Thanks for your clarification and suggestion, edit is only applicable to user configured tag, but masked-tag can be applied to user configured tag as well. I feel mask-tag should always preempt edit operation, flagging an error seems not needed in this case. 

/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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod


-- 
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>