Access Controls ASCQs for rev 7

[Gerry_Houlder at notes.seagate.com]

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry_Houlder at notes.seagate.com
*

Regarding Jim Hafner's comment (in quotes below):

   "If an initiator sends the ACCESS ID ENROLL service action
and the target can't implement the complete merger of the initiator's
TransportID-specified LUN Map and its AccessID-specified
LUN Map, should there be some sense data in the response
which indicates this? (Right now, the only thing required is logging
the event for PAM to look at later -- the enrolling initiator gets GOOD
status.)
    I think it's important the the command still succeed with status GOOD,
so the enrollment actually takes place and the non-conflicting
part of the map get instantiated."

Lets not lose sight of what ASC/ASCQ bytes are. They are only generated
when a CHECK CONDITION status occurs, never on GOOD status. The desire to
have "error codes" and GOOD status (which is supposed to mean no errors) is
an oxymoron in SCSI. This is a legacy from parallel SCSI where the sense
bytes must be retrieved in a separate Request Sense command instead of
being attached to the status packet (like FC).

SCSI also has a status called "Intermediate GOOD" or "Condition Met/ GOOD".
You might be able to drum up support to allow sense bytes to be valid on of
of these, but it is unlikely you could get support to have valid sense data
with GOOD status.

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org