RRSF - segment-level control for command propagation

Background / Current behavior
We use RRSF automatic command direction to synchronize RACF profiles across multiple systems. This works well operationally. However, IBM Documentation describes AUTODIRECT control in the RRSFDATA class strictly at the command level using resource names in the format AUTODIRECT.target-node.classname.command-name. 
The same documentation explicitly states that automatic command direction occurs only at the command level and that operands/segment information cannot be selectively directed (example given for ADDUSER segments). 
The “Customizing a remote sharing environment” topic likewise describes AUTODIRECT.node.class.command as controlling automatic direction for the command as a whole.

Business / Security impact

• Forces us to choose between:
  1. No dataset profile synchronization (operational overhead, increased drift), or
  2. Synchronization that can overwrite system-unique encryption configuration (risk of broken access, incorrect encryption behavior, or policy violations).
• The DFP segment is used for dataset encryption configuration (e.g., DATAKEY/key label) (other options to trigger DS encryption exists but DFP is the only way to centrally enforce it by security admin)
• This creates a practical barrier to using RRSF for consistent access control while maintaining system-specific encryption uniqueness.

Requested enhancement
Introduce a supported mechanism to control automatic command direction at operand/segment level for DATASET commands (at minimum for ADDSD and ALTDSD). Examples of acceptable approaches:

1. Extended RRSFDATA resource naming that can include operand/segment qualifiers for supported commands
   • e.g., AUTODIRECT.<node>.DATASET.ADDSD.SEGMENT.DFP (deny/allow)
2. Policy-based filtering of operands/segments in automatic direction rules
   • e.g., “AUTODIRECT ADDSD/ALTDSD but exclude DFP segment”
3. A supported exit/hook invoked before sending the automatically directed command, allowing removal/masking of selected operands/segments.

Acceptance criteria (minimal viable)

• Ability to define a rule that results in:
  • ADDSD/ALTDSD automatically directed to selected nodes, but DFP segment contents are not propagated.
• Default behavior remains backward compatible (command-level direction unchanged unless new option is configured).
• Clear auditing/logging that a segment/operand was suppressed during propagation.

Why this is important now
Pervasive encryption adoption makes DFP/encryption attributes increasingly common in dataset profiles, but key labels and encryption policy often must remain environment-unique. Without segment-level steering, RRSF cannot safely be used for dataset profile synchronization in such environments.