Key Issues in the SCSI-3 Primary Commands (SPC)

[Bob Snively]

>To:       Membership of X3T10
>
>From:     Ralph O. Weber
>          Digital Equipment Corporation
>
>Date:     May 13, 1994
>
>Subject:  Key Issues in the SCSI-3 Primary Commands (SPC)

...........

>The MODE SELECT(10) clause says, "Device servers that implement
>the MODE SELECT(10) command shall also implement the MODE
>SENSE(10) command."  The MODE SENSE(10) clause says, "If the MODE
>SELECT(10) command is implement the MODE SENSE(10) command shall
>be implemented."  Based on these statements, a devious target
>designer could implement MODE SENSE(10) but not MODE SELECT(10). 
>Such a target implementtion would be exceptionally nasty for most
>host software.  Can I reverse the sense of statement in the MODE
>SENSE(10) clause?
>

Yes.  

>Is the standard INQUIRY data SftRe bit still applicable in
>SCSI-3?  Is it protocol specific?
>

Soft Reset is an appealing function defined by SCSI-2 and
practically never used.  Most systems do not trust a 
partial reset and will perform full recovery anyway.  We're
probably stuck with it but it would be nice to get rid of it.
Perhaps we should reserve it for back compatibility and to 
recover it in SCSI-4.
Soft Reset is not defined by SAM.

>Is the standard INQUIRY data CmdQue bit still applicable in
>SCSI-3?
>

Yes.  There is no requirement that tagged command queueing be
accepted by a SCSI-3 device.  SAM implies (but does not state)
that it is optional on page 60.

>The standard INQUIRY data Sync, WBus16, and WBus32 bits are
>specific to SIP.  How should these bits be handled in the SPC? 
>Should I create a protocol-specific field?  Or, should I just
>leave the bits?  If I create a protocol specific field, does
>SftRe somehow map to it too?
>

These fields should be be recovered by making them reserved
for back compatibility.  Each protocol has mechanisms to
negotiate these values on a node by node basis, including SIP.
They were never required in the INQUIRY command itself except
to protect non-compliant devices that mishandle rejects from 
the embarrassment of being found out.


>Is the following statement correct: "The sense data shall be
>available if a Auto Contingent Allegiance condition exists for
>the task set"?  Is task set a wide enough boundary for the ACA
>requirement?
>

This text should allow for auto-sense to clear the ACA, in
which case no sense data remains available.

SAM defines ACA only over the task set. (SAM page 53)

>There is a sentence describing the "progress indication"  sense-
>key specific bytes that I do not understand.  The sentence is:
>These fields only apply to the FORMAT UNIT command with the Immed
>bit set to one.  Does this mean that the sense-key specific bytes
>are valid only while the device server is processing a FORMAT
>UNIT command?
>

As defined, it means that the device shall only permit the
SKSV bit to be one while presenting a NOT READY sense key
while a FORMAT immediate command is being executed.  At any other
time, the SKSV bit shall be zero for a NOT READY sense key.

>In item e) under deferred errors, the following sentence worries
>me: "If a deferred error occurs after a task has entered the
>enabled state and the task completes successfully, the target may
>choose to return the deferred error information after the
>completion of the current command."  This seems to conflict with
>the following previous statement: "If a task terminates with
>CHECK CONDITION status and the subsequent sense data returns a
>deferred error that task shall not have been executed."
>

This is conflicting and incorrect.  The obvious correction
is to choose one or the other.  Since it is likely that there
is no control over whether the task which carries the CHECK 
CONDITION was completed or not, the first case seems correct.

>How should the SPC say that the ILLEGAL REQUEST sense key can
>indicate that an invalid IDENTIFY message was received?
>

CHECK CONDITION followed by REQUEST SENSE to the same invalid
LUN should do it.  For the protocols with autosense, it is a lot
easier.

>Should ASC/ASCQ 2F/00 text be changed from, "COMMANDS CLEARED BY
>ANOTHER INITIATOR" to "TASK SET CLEARED BY ANOTHER INITIATOR"?
>

Yes

>In the Control mode page, is the DQue bit valid for SCSI-3?
>

Yes

>I am having serious difficulty SAMinizing the definition of the
>Disconnect-reconnect mode page.  I fear that if I do SAMinize,
>the definitions will be imprecise to the point of uselessness.
>

The definitions should be the same as SIP, but labeled with a
warning that they are interpreted in different manners by
each of the mapping protocols.  In particular, FCP uses
the Maximum Burst Size, while SBP may not.  Most of these
are really "optional for protocol" and "optional for
implementor or as required by protocol for implementor".


>I cannot see a way to put the full description of all the READ
>ELEMENT STATUS parameter pages in the SPC without dropping the
>whole medium changer device model in the SPC.  Help!!!
>

We could allow the "medium changer ready" option
to be described as a cross reference in each of the device
models that qualifies.  Then tables like SCSI-2 table 155 would
have cross references to the medium changer document instead of
a reference to SPC.  The medium changer document would be
the natural place to define the READ ELEMENT STATUS pages.