Dissimilar policies for node replication

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Storage
Product - Tivoli Storage Manager (TSM) Family

For recording keeping, the previous attributes were:
Brand - Tivoli
Product family - Storage
Product - Tivoli Storage Manager (TSM) Family

Thank you for submitting the request. This is a valid request and might be useful for service providers with the flexibility and convenience it provides to manage each customers differently. While consistent with our current product direction, we cannot at this time commit to delivery of this enhancement in the next release or two. If,
after our next release of TSM, you still would like this requirement to be re-considered, please reopen it in RFE and we will again consider it. Thank you
for your commitment to TSM and for your support in moving the product forward.

In a service provider setup with a configuration manager, the backup policies on all TSM instances are controlled from here using policysets..
The backup policies will often be named in such a way, so it is easy for the client/customer to understand the retention from the policy name, e.g. 5V180R2V365R - so they won't have to examine the details of the policy in order to find out what retention has been configúred for the specific policy.

When using dissimilar policies, the name of the mgmt class should be the same - but the settings would be different on the source and target servers. In order to be able to accomplish this, two different policysets would need to be maintaned for each domain - one for the replication source, and another for the replication target. In this case, a backup policy would have to be named e.g. 2V90R1V180R-5V180R2V365R.
In order to satisfy the different requirements from a lot of customers, you would quickly end up with thousands of management classes, as each customer has different requirements for the retention on different files types locally and remotely.

As configuration in a policy set/domain is seen by all nodes in the domain, and nodes from several customers are defined in the same domain, it is essential, that naming is general and not customer specific, as all customers will be able to see all defined policies.
If the customers should be able to control the retention themselves in the current way it works (and change retention parameters), the naming could be e.g. RS1_POL_1 (RS1 for RemoteServer 1, POL_1 for customer specific policy 1) or RS2_POL_3 (Remote Server 2 policy 3) - but the issue is, that another customer would be able to use this policy as well, and if the first customer suddenly changes retention parameters, it will affect the data of customer number 2 without his knowledge. It is impossible to ensure, that one customer doesn't use the mgmt class defined by another.
Maintaining a policy set for each customer (actually a pair of policysets, as one is needed for the sourve. and another for the target) would result in administrative overhead - as it takes time to maintain many policy-sets, and whenever a new customer signs up, a new policyset would need to be defined from scracth (including schedules and so on).

If the mgmt class could be specified in the dsm.opt file for the primary and secondary copy/copies, only a single policy set would need to be maintained for each domain - thereby simplifying administration on both the TSM server side and the client configuration side.

With the recent release of TSM 7.1.1 and the support of dissimilar policies using node replication, it is unclear whether this delivered support has not satisfied your desired usage? Could you please provide more clarification what is not being satisfied with our present implementation?