[T11.3] Re: FC-DA: SCSI command tables

Robert Griswold rgriswold at crossroads.com
Fri Jun 21 09:47:56 PDT 2002

INCITS T11.3 Mail Reflector
After reading Rob's evaluation, it seems to me (and others here) that =
is exactly right.  This has the potential of turning into a major
headache for development staff if the requirements governing the
behavior of the SCSI commands are over-ridden by standards governing
transports and protocols. =20

Rob is right here, let's heed his warnings, and put those changes into
the command specs, where they belong.


Robert Griswold
Chief Technologist &
Director of Marketing
Crossroads Systems, Inc.

-----Original Message-----
From: Elliott, Robert (Server Storage) [mailto:Elliott at hp.com]=20
Sent: Thursday, June 20, 2002 1:54 PM
To: Dave Peterson; t11.3; T10 Reflector
Subject: RE: FC-DA: SCSI command tables

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
HP does not believe SCSI command level requirements belong in FC-DA.

Upper level software generating SCSI CDBs should be
protocol-independent.  We don't want to see FC-DA joined by pSCSI-DA,
SAS-DA, iSCSI-DA, InfiniBandSRP-DA, etc. profiles each defining its own
set of requirements.  The T10 command set standards should define
everything needed for interoperability.  If you think that identifying
specific parameters as required/optional (e.g., select Persistent
Reservation Out service actions) is necessary, let's push those
requirements into SPC-3, SBC-2, SSC-2, SMC-2, SES-2, etc. =20

The current FC-DA draft wants to make REPORT LUNS required for all
device types; I don't mind doing that, but it should be done in the
command set standards themselves (as has been proposed for SSC-2).

The FCP-2 clearing effects table is an example where a standard tried =
make rules that belong in other standards. It had some errors (when
reviewed by a wider audience) and quickly became out of date.
Fortunately, iSCSI and SRP avoided defining their own, conflicting,
tables, deferring to SAM-n and the command set standards so the effects
are protocol-independent.

Rob Elliott, elliott at hp.com
Industry Standard Server Storage Advanced Technology

> -----Original Message-----
> From: Dave Peterson [mailto:dap at cisco.com]=20
> Sent: Wednesday, June 19, 2002 12:56 PM
> To: t11.3
> Cc: T10 Reflector
> Subject: FC-DA: SCSI command tables
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Dave Peterson" <dap at cisco.com>
> *
> Howdy All,
> The current FC-DA technical report contains tables describing=20
> SCSI command usage pertaining to Fibre Channel. These types=20
> of tables have been specified in previous technical reports=20
> (e.g., PLDA, FC-TAPE). FC-DA is intended to replace these=20
> technical reports, so we need to determine if these types of=20
> tables need to be carried over into FC-DA.
> Some folk have indicated the tables are (and have been)=20
> useful for conformance testing/implementation purposes.
> Other folk have indicated the tables are not useful and the=20
> SCSI device specific command specifications (e.g., SPC-3,=20
> SBC-2, SSC-2, SMC-2) should be the appropriate document for =
> Please indicate your (company) preference via the reflector=20
> (or privately to me if you desire) regarding this matter.
> For the record, I would prefer to keep the command tables in=20
> FC-DA. My main reason is that the current SCSI device=20
> specific command specifications document whether or not a=20
> command is manadatory but do not specify whether or not=20
> (each) command specific parameter is required or optional. (I=20
> would probably change my vote if the SCSI device specific=20
> command specifications did address this matter, but I do not=20
> believe this will happen any time soon, if at all, and I'm 
> not convinced that they should either).
> Thanks...dap
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org

To Unsubscribe:
mailto:t11_3-request at mail.t11.org?subject=3Dunsubscribe

More information about the T10 mailing list