CA_ACA Proposal 97-225r0.DOC

Tom Coughlan coughlan at
Thu Sep 4 19:24:09 PDT 1997

* From the T10 (formerly SCSI) Reflector (t10 at, posted by:
* coughlan at (Tom Coughlan)
Regarding Gene's reply to my second set of comments:

>Deferred Errors:
>It does result in a check condition.

A check condition for who, the causing initiator or the other initiator?

I'll recap, and clarify my question.

The CA_ACA proposal says:

       If it is possible to associate a deferred error with a causing
       initiator and with a particular function or a particular subset of
       data, and the error is either unrecovered or required to be
       reported by the mode parameters, a deferred error indication shall
       be returned to an application client on the causing initiator. If
       an application client on an initiator other than the causing
       initiator attempts access to the  particular function or subset of
       data associated with the deferred error, the command attempting the
       access shall be responded to according to the requirements for a
       contingent allegiance condition.

The way I interpret this, an application client on an initiator other than
the causing initiator shall be responded to as though there is a contingent
allegiance with the causing initiator.  (The CA with the causing initiator
isn't quite in place yet because the deferred error is still pending, but
we act as though the check condition has been sent.) 

This means that, prior to the CA_ACA proposal, the non-causing initiator
will get Busy.  With the CA_ACA proposal in effect, and assuming there
aren't any ordered commands in the queue, the non-causing initiator's
command will just execute.

I believe that this effect of the CA_ACA proposal is incorrect.  The
non-causing initiator's command should be blocked, somehow, because the
data it is referencing is the subject of a deferred error for another
initiator.  My suggestion was to return a (TBD) check condition to the
non-causing initiator.  Busy would be okay too.

>><< It needs to be made clear that the SCSI-2 extended auto contingent 
>>allegiance is obsolete (illegal?) in SCSI-3. >> 
> OK. How about "1. The SCSI-2 contingent allegiance condition has been 
>augmented and the extended auto contingent allegiance condition has been 
>replaced in SCSI-3 by auto contingent allegiance in conjunction with the NACA 

This is fine.  Why, though, is the phrase "in conjunction with the NACA
bit" needed?  The NACA bit is an integral part of SCSI-3 auto contingent 
allegiance, and doesn't require special mention here.  Giving it special
mention could cause confusion on this point.  
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list