It is currently possible for an administrator to create a replication agreement from an RHDS node back to itself, without any warnings, cautions, or other mechanisms to attempt to prevent or warn the administrator that they are about to do so. 

Based upon the results found in one customer environment running RHDS 12.6,  this was performed unintentionally with the only information being provided from the system were a handful of error messages. The replication agreement was ultimately and unintentionally modified causing that host to begin replicating data back to itself. The result of this modified replication agreement ultimately took down a large portion of the production business environment for this customer.

1. Proposed title of this feature request
   1. need for a mechanism to prevent the ability of creating a replication agreement from a node back to itself
2. What is the nature and description of the request?
   1. It is currently possible for an administrator to create a replication agreement from an RHDS node back to itself, without any warnings, cautions, or other mechanisms to attempt to prevent or warn the administrator that they are about to do so. 
3. Why does the customer need this? (List the business requirements here)
   1. It is currently possible for an administrator to create a replication agreement from an RHDS node back to itself, without any warnings, cautions, or other mechanisms to attempt to prevent or warn the administrator that they are about to do so. 

Based upon the results found in one customer environment running RHDS 12.6,  this was performed unintentionally with the only information being provided from the system were a handful of error messages. The replication agreement was ultimately and unintentionally modified causing that host to begin replicating data back to itself. The result of this modified replication agreement ultimately took down a large portion of the production business environment for this customer.

1. How would the customer like to achieve this? (List the functional requirements here)
   1. To completely prevent this from being able to happen all together, specifically on systems with only one directory instance running on them
   2. Alternatively introducing some sort of mechanism to provide the administrator with warnings, cautions, or verification mechanism to attempt to prevent or warn the administrator that they are about to create a replication agreement from that host back to itself.
2. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
   1. To completely prevent this from being able to happen all together, specifically on systems with only one directory instance running on them
   2. Alternatively introducing some sort of mechanism to provide the administrator with warnings, cautions, or verification mechanism to attempt to prevent or warn the administrator that they are about to create a replication agreement from that host back to itself.
3. Is there already an existing RFE upstream or in Red Hat Bugzilla?
   1. Not that I could fine.
4. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL8, RHEL9)?
   1. "This should have already been present, so we would like to see it as soon as possible."
5. Is the sales team involved in this request and do they have any additional input?
   1. Yes
6. List any affected packages or components.
   1. 389-ds-base
7. Would the customer be able to assist in testing this functionality if implemented?
   1. Yes. However, coordination will need to be planned ahead of time, and should involve their TAM.