Hi, Jurgen:
-----邮件原件-----
发件人: Jürgen Schönwälder [mailto:[email protected]]
发送时间: 2022年8月24日 14:00
收件人: Qin Wu <[email protected]>
抄送: NetMod WG <[email protected]>; Balázs Lengyel <[email protected]>
主题: 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
> [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
