Thanks for your feedback, Nathan!

First, you're right that default attributes can be used to effect the same thing this code does. I also agree with your comment regarding `updated_by_last_action` in this scheme. If we keep the current semantics, we will make the two changes you have suggested.

Now, to the larger issue you have raised regarding persistent attributes. The previous semantics of the rule resource suffered from a couple of problems:

1. Changing an existing `simple_iptables_rule` resource did not remove the old rule and replace it with the new one. What it did depended on what you changed. If you changed the `rule` attribute value, the new rule was appended to the old one. If you changed the `direction` attribute value, nothing happened, since the logic assumed you were specifying a duplicate rule.

2. Rules had to be removed explicitly by specifying the `:delete` action. I know that this is often de rigueur in the Chef world, but it meant that to remove a rule, the cookbook had to be updated in two stages (first specify the `:delete` action, then remove the resource altogether).

We have tens of nodes we manage with Chef. We treat Chef cookbooks like code in the sense that we subject changes to cookbook contents to a test cycle before releasing them to our production nodes. As a result, we feel very strongly that to the extent possible, the resources in this cookbook should behave declaratively: After having run Chef, an iptables rule should be present on the system if and only if it exists in some recipe. That is the motivation for this set of changes.

Now, having said all that, I am interested in hearing more about your proposed `:reset` action. If it is compatible with our use cases, we will give it serious consideration. Alternatively, it is possible to have two modes: persistent and non-persistent. I'm not a huge fan of this as it is likely to complicate the code and because the "persistent" mode of operation will not be tested by us.