These possible remedies are only this commenter's observations and 
require further study, ongoing within the IEEE 802.1ASbt working group.


No strong recommendation is given; however, two complementary 
possibilities are explored below.


Specific to the allowedLostResponses hysteresis issue:
The behavior could be altered to increase the hysteresis by changing the 
allowedLostResponses value to a value substantially greater than 3, but 
only if asCapable has been set for "a time" - but this must be balanced 
with the need to rapidly detect a link-local issue and fail over to an 
alternate network path (if available).
A trivial approach may address this by defining a boolean 
"asCapableIsStable" that is set to TRUE in the 
WAITING_FOR_PDELAY_INTERVAL_TIMER if asCapable=TRUE for 60 consecutive 
times.   Once asCapableIsStable is TRUE, then the value of 
allowedLostResponses could be increased from 3 to 10 (and restored to 3 
when asCapableIsStable is FALSE.   This approach has the problem of 
greatly increasing the delay before asCapable is FALSE in the face of a 
true problem with Pdelay exchanges.


=======

Specific to the hair-trigger behavior behavior in 
WAITING_FOR_PDELAY_INTERVAL_TIMER.  This state could be amended to 
preclude the possibility of asCapable being set FALSE immediately if one 
of the three "immediate" hair-triggers is encountered. This could be as 
simple as adding a counter "detectedFaults" similar to 
"allowedLostResponses"
For example, asCapable could be set to FALSE only if 3 faults are 
detected in a row,  by changing the else statement in this state:


From just "asCapable=FALSE;" to an if/else statement as follows:

if ((neighborPropDelay <= neighborPropDelayThresh) &&
    (rcvdPdelayRespPtr->sourcePortIdentity.clockIdentity != thisClock) &&
    neighborRateRatioValid)
{
  asCapable = TRUE;
  detectedFaults = 0;
}
else
{
  if (detectedFaults <= allowedFaults)
    detectedFaults += 1;
  else
  {
    asCapable = FALSE;
    detectedFaults = 0;
  }
}
where detectedFaults is properly initialized to zero in 
INITIAL_SEND_PDELAY_REQ and allowedFaults is defined, perhaps to 3 to be 
consistent with the current allowedLostResponses.   This solution could 
also be adjusted to not require the faults to be "in a row", however if 
this adjustment were pursued, a window would have to be defined (eg: "3 
faults in 60" would cause asCapable to be FALSE )


======

A better approach may be to still allow for a rapid fault detection 
mechanism to allow asCapable to be set FALSE when an issue is 
encountered,  but provide stronger guidance on the neighborPropDelay and 
neighborRateRatioValid.  Perhaps testable minimum requirements such as 
requiring neighborPropDelay outlier rejection and/or averaging 
mechanisms and requirements over certain windows.