I think you can argue about that, so here is my view ;-)

A parameter in general is just a way to tell the type or provider how to behave in different situations. For the `netapp_quota` type I can image a `resize => true/false` parameter to surpress quota reloading/resizing after changing a quota entry (for performance reasons or whatever). This would just tell the provider what to do after changing an entry but it is not something that has a "current value" and a "desired value".

When you look at the following quota entry:

    bob user@/vol/home/bob_h 100M 10K 90M 90M 9K

and the following resource

    netapp_quota { 'bob':
      ensure    => present,
      type      => user,
      volume    => 'home'
      qtree     => 'some_other_tree',
      disklimit => '200M',
    }

then - in an ideal world - `name`, `type`, `volume` and `qtree` should all be parameters because they tell the provider against which existing quota_entry you want your resources to match against. In the NetApp-World the puppetresource above describes a *different* quota entry than the line above (one quota entry is identified by target, type, volume and qtree). Unfortunelty multiple keyattributes are broken in Puppet so we have to treat the quota entry and the resource as identical (because the `quota-target` is everything that counts)

So if we life with the fact that `quota-target` has to be unique then I'd say that `qtree` should be treated as a property because it has a current value and a desired value. But we have a problem if qtree is out of sync: We'd have to remove and recreate the quota (remeber: in the NetApp world two quotas with the same target but different qtrees are two different quotas). I just did not want to implement that and prefer to raise a warning.

If we implement `qtree` as a parameter, we may run in situations where a resource declaring to operate on qtree `q1` modifies the disklimit of qtree `q2` without raising any warnings. This may lead to a few surprises ;-)