SPC-2 Changes complementary to RBC

[ROWEBER at acm.org]

* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* ROWEBER at acm.org
*

} BUT, would you, please, provide something more concrete than an assertion
} of discomfort when you say T10 shouldn't link REQUEST SENSE support to the
} transport protocol. As far as I can determine you have said the same thing 
} in words that are likely to be less than transparent to many readers.
}
} Perhaps a counter-example of when it's NOT appropriate to link the two would
} be helpful. I'm ready to have my opinion changed.

To the best of my knowledge, the ONLY place where it's okay to point to 
protocol documents from SPC is the Disconnect-Reconnect Mode Page.  This is 
not so much a matter of it's being a good thing to do, but rather the linkage 
is the only way to maintain any upward compatibility between SCSI-2 and SPC.
If we could start with a clean sheet of paper, the Disconnect-Reconnect Mode
Page would not be part of SCSI.

All other references to protocols say essentially that details of field usage
are protocol-specific or that additional similar conditions and results may
be defined as part of a protocol (i.e., a protocol may extend SPC definitions,
but not change them).

I don't think we are bereft of alternatives (as was true with the Disconnect-
Reconnect Mode Page) and the proposal definitely is a protocol-based 
redefinition of SPC behavior (not an extension to it).  So, I'd prefer to 
find a way of writing the definition that keeps the requirements statements 
in SPC (as opposed to having them in SPC and some other document).

Thanks.

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