Connection Parameter Negotiation Using Tolerance Settings - Best Practices

Question

Hello Nordic team, 
 I'm developing a BLE peripheral using nRF52833 and would like to validate that my approach for handling connection parameters aligns with Nordic's best practices. 
 We were noticing some intermittent disconnects between our peripheral and iPhone centrals. Based on Apple and Nordic's recommendation we increased the Supervision Timeout (initially set by Apple central to 720 ms) and this fixed the issue. 
 I'm using the ble_conn_params module with decreased tolerance values to force negotiation when parameters fall outside acceptable ranges: 
 
 c 
 
 // Preferred connection parameters 
 # define MIN_CONN_INTERVAL MSEC_TO_UNITS ( 30 , UNIT_1_25_MS ) // 30ms 
 # define MAX_CONN_INTERVAL MSEC_TO_UNITS ( 100 , UNIT_1_25_MS ) // 100ms 
 # define SLAVE_LATENCY 4 
 # define CONN_SUP_TIMEOUT MSEC_TO_UNITS ( 4000 , UNIT_10_MS ) // 4000ms 
 
 // Tolerance settings to force negotiation 
 # define NRF_BLE_CONN_PARAMS_MAX_SLAVE_LATENCY_DEVIATION 0 // Exact match required 
 # define NRF_BLE_CONN_PARAMS_MAX_SUPERVISION_TIMEOUT_DEVIATION 100 // ±1000ms (in 10ms units) 
 
 // Standard conn_params module initialization 
 # define FIRST_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS ( 5000 ) // 5 seconds 
 # define NEXT_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS ( 30000 ) // 30 seconds 
 # define MAX_CONN_PARAMS_UPDATE_COUNT 3 // 3 attempts

With supervision timeout of 4000ms ± 1000ms: 
 
 Minimum accepted : 3000ms (meets Apple's 2000ms minimum) 
 Maximum accepted : 5000ms (within Apple's 6000ms maximum) 
 iOS's initial 720ms : Rejected by is_conn_params_ok() , triggering negotiation 
 
 This approach leverages the Nordic module's existing validation logic without modifying ble_conn_params.c . 
 Questions: 
 
 Is using tolerance values to force negotiation a recommended practice? By setting NRF_BLE_CONN_PARAMS_MAX_SUPERVISION_TIMEOUT_DEVIATION to reject iOS's initial 720ms timeout, we ensure negotiation always occurs. Is this approach robust across different central implementations? 
 Central rejection handling: If a central device completely rejects our parameter update request (not just negotiates different values, but refuses the L2CAP request entirely):
 
 Does the ble_conn_params module automatically continue with the central's original parameters? 
 Could this cause connection failure, or does the module handle this gracefully since we set disconnect_on_fail = false ?

Retry behavior: With MAX_CONN_PARAMS_UPDATE_COUNT = 3 , if all attempts fail:
 
 Will our peripheral be unable to connect at all? It seems like it would be better if we just accepted whatever the central offered if they rejected our 3 previous update requests, but I don't see an obvious way to accomplish this using ble_conn_params.

My Core Concern: While this tolerance-based approach elegantly forces negotiation for iOS devices, I want to ensure it won't cause connection failures with central devices that have unusual connection parameter policies. Does disconnect_on_fail = false setting protect against this? Ours is set to false, I'd like confirmation that the module handles all edge cases gracefully. 
 Is this tolerance-based approach a valid use of the ble_conn_params module, or would Nordic recommend a different strategy for ensuring Apple-compliant connection parameters? 
 Thank you for your guidance!