# Is it possible to restrict the deletion of an entry from list based on the count()?

**URL:** <https://dmap-community.ductus.global/t/is-it-possible-to-restrict-the-deletion-of-an-entry-from-list-based-on-the-count/2765>\
**Category:** YANG\
**Created:** [November 12, 2019, 8:56am UTC](https://dmap-community.ductus.global/t/is-it-possible-to-restrict-the-deletion-of-an-entry-from-list-based-on-the-count/2765 "2019-11-12T08:56:00Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![mroobini](https://avatars.discourse-cdn.com/v4/letter/m/57b2e6/32.png) [@mroobini](https://dmap-community.ductus.global/u/mroobini)\
**Post date:** [November 12, 2019, 8:56am UTC](https://dmap-community.ductus.global/t/is-it-possible-to-restrict-the-deletion-of-an-entry-from-list-based-on-the-count/2765/1 "2019-11-12T08:56:00Z")

</div>

Team,

I have a yang model like below,

augment “/interfaces/interface” {  
container tag-ip{  
leaf tag-ip {  
must “(count(/interfaces/interface/tag-ip[bit-is-set(tag-ip, ‘inband’)]) = 1)”;  
type bits {  
bit inband {  
position 0;  
}  
}  
}  
}

My assumption is that the count statement inside the must condition will always ensure the interface with bit ‘inband’ set is always 1. It is restricting the creation of more than one entry with bit ‘inband’ set but not restricting the deletion of an entry.

I want deletion should be allowed only when deletion and creation of an interface (with inband bit set ) are done in a single commit.

Please let me know if i am missing anything or any other possible solution for this problem.

---

<div class="post-metadata">

**Author:** ![per](https://avatars.discourse-cdn.com/v4/letter/p/9f8e36/32.png) [@per](https://dmap-community.ductus.global/u/per)\
**Post date:** [November 15, 2019, 10:46pm UTC](https://dmap-community.ductus.global/t/is-it-possible-to-restrict-the-deletion-of-an-entry-from-list-based-on-the-count/2765/2 "2019-11-15T22:46:36Z")

</div>

As explained in the `Semantic validation` chapter of the User Guide, validation doesn’t validate the _changes_ to the configuration, but the configuration that would _result_ from those changes. And only the nodes that actually exist in that resulting configuration are validated - thus, since your `must` expression specifies a constraint on the `tag-ip` leaf, it won’t be evaluated if there are no `tag-ip` leafs in the resulting configuration.

The solution is to put the constraint on a “higher level” in the configuration - if you want it to be enforced when at least one element of the `interface` list exists, but not if there are no entries in that list, you can put the constraint on `interface`. If you want it to _always_ be enforced, effectively requiring that there is at least one entry in the `interface` list, you can put the constraint on the `interfaces` container.

In your particular case, you can’t add the `must` expression to either `interface` or `interfaces` via `augment`, since `must` is not allowed as a direct substatement to `augment` - but you _can_ do it via `tailf:annotate` or `deviation`. However this, as well as your original attempt, is a bad idea - while it isn’t formally forbidden by the YANG spec, it violates the “spirit” of this paragraph in [https://tools.ietf.org/html/rfc7950#section-7.17](https://tools.ietf.org/html/rfc7950#section-7.17) -

```auto
   If the augmentation adds mandatory nodes (see Section 3) that
   represent configuration to a target node in another module, the
   augmentation MUST be made conditional with a "when" statement. Care
   must be taken when defining the "when" expression so that clients
   that do not know about the augmenting module do not break.

```

You aren’t adding a mandatory node, but adding a node that is required to exist due to a `must` expression is effectively the same - clients that don’t know about your augmentation + must-addition may break, since they are not aware that they must make sure that there is a `tag-ip` leaf with the `inband` bit set.