some comments on SAM Rev016

Lansing J Sloan ljsloan at
Fri Mar 3 17:07:15 PST 1995

SCSI Folks,
     The following are some of Lawrence Livermore National
Laboratory's expected comments to the public review of the SCSI-3
Architecture Model (Revision 016), at least so far.  If they
fit into the SCSI WG agenda item 5.4 (Public Review Comments
on SAM), that's their purpose.  Otherwise, you may ignore for now.

     Comments are organized as follows:
     #xxx (?) Comment on y.y.y

     xxx is the comment number,
     ? is the type (E: Editorial, T: Technical), and
     y.y.y |is the referenced section number.
     We have also provided many additional comments directly to
the document editor, Charles Monia, as markups on a copy of the
document.  We expect the editor to bring to X3T10's attention any
such comments that require committee consideration.


#009 (T) Comment on 6.1, first paragraph, last sentence
     The last sentence is true, but incomplete.  Consider adding
a sentence such as the following: "Protocol-specific formatting
of parameters is specified in the applicable SCSI-3 protocol
     If the last sentence is normative (i.e., a requirement for
command standards), then it should be reworded, perhaps by
changing "... are specified ..." to "... shall be specified ...".
The new sentence just proposed should be similarly modified.
     (FCP Rev 10, clause 5.2, is an example of a protocol
standard specifying protocol-specific formatting of a parameter.)

#010 (T) Comment on 6.1.2, link bit
     SCSI-2 has text in clause 7.8.2 that concerns the
interaction of queuing and linked commands.  "A series of linked
commands constitute a single I/O process. ... A command received
with a HEAD OF QUEUE TAG message shall not suspend a series of
linked commands for which the target has begun execution."
     Is that, or a similar, requirement supposed to be in SCSI-3?
If so, is SAM the appropriate standard that should state the
requirement?  (I have not found such text in any SCSI-3 document,
though could easily have failed to see it.)

#011 (T) Comment on 6.1.2, link bit
     Is it supposed to be possible in SCSI-3 to use linked
commands to create complex atomic operations?  Assume there may
be multiple initiators.  As a specific example, suppose one
initiator has reserved two adjacent extents of a logical unit.
Suppose that initiator links three commands.  The first two
commands each release a reservation.  The third reserves the
combined extent.  For this example, assuming no errors occur, is
there any assurance that no commands are accepted that access the
extents while the extents are unreserved?  Alternatively, are
there specific sequences that permit the extents to be accessed
before the third (the RESERVE) command is executed?
     Text (perhaps informative) discussing such issues seems

#016 (T) Comment on 6.3.1, third-from-last paragraph
     The first sentence of this paragraph probably is violated by
most "initiator implementations" inside peripherals that
implement the COPY command, since when they behave as initiators
they do not support a resolution of one byte. It is not obvious
how to improve the wording while keeping the requirement as
strong as seems intended.  Perhaps add: "Coarser resolutions are
permitted during the execution of some commands in command
standards (e.g., the COPY command in SPC)."

#017 (T) Comment on 7.1, last paragraph, last sentence
     If a service delivery subsystem misorders (as is
specifically allowed by the last paragraph of clause 5.5.2), the
target can guarantee that no further responses are sent from the
task, but the target cannot guarantee that the client will
receive no responses from the task after that client receives the
response to ABORT TASK.  The current text appears to be correct
(depending on what "further" means) but misleading, and therefore
should be reworded to point out that clients can receive task
responses after they receive the servide response to ABORT TASK.

#018 (T) General comment
     In large SCSI configurations where all initiators are not
equally trusted, peripherals should be allowed to reject in some
manner unwanted commands from untrusted initiators.  Such issues
are presently beyond the scope of SCSI standards.  However, SAM
should not have words that conflict with such possible future
configurations.  In a quick scan of SAM Revision 016, no
offending text was detected.  If there are any changes to SAM,
they should not introduce offending text, and if any now exists,
it should be corrected.

                      Lansing J. Sloan
                      Lawrence Livermore National Laboratory
                      ljsloan at

More information about the T10 mailing list