LLNL Pub Review Comments on SAM

Lansing J Sloan ljsloan at anduin.ocf.llnl.gov
Fri Mar 24 10:42:03 PST 1995


To:    SCSI Reflector
From:  Lansing Sloan

LLNL's public review comments on SAM follow.
They were discussed at the March 8 SCSI Working Group meeting.

(Six of the comments were e-mailed March 3.)

                                                    March 9, 1995



X3 Secretariat
Attn.:  Lynn Barra
1250 Eye Street N.W., Suite 200
Washington, D.C.  20005-3922

Membership of X3:
     
     Here  are  Lawrence Livermore National Laboratory's comments
to  the  public  review of X3.270:199x, the  SCSI-3  Architecture
Model  (Revision 016).  We consider this to be a "yes" vote  once
the comments are resolved.
     
     Comments are organized as follows:
     
     #xxx (?) Comment on y.y.y

where
     
     xxx is the comment number,
     
     ? is the type (E: Editorial, T: Technical), and
     
     y.y.y is the referenced section number.
                                
                        SPECIFIC COMMENTS

#001 (E) Comment on 4.1.101
     
     It appears that the last command in a series of linked
commands is defined to be an unlinked command.  Is that the
intent?

#002 (E) Comment on 4.3
     
     Should entries for "SCSI-1" and "SCSI-3" be added, or "SCSI-
2" deleted?

#003 (E) Comment on 5.2.1, last paragraph
     
     Most of this paragraph should be in Clause 5.3 rather than
in 5.2.1.

#004 (E) Comment on 5.2.1, last paragraph, last sentence
     
     The second word should be "ensure," not "insure".  A global
search for this wording throughout the SAM document may be in
order.

#005 (T) Comment on 5.2.1, last paragraph
     
     Somewhere, SAM should specify information such as the
following.  "An SCSI-3 protocol standard shall specify formats
and encodings of addresses and identifiers (e.g., in requests,
command descriptor blocks, parameter blocks, etc.)."  It's not
clear that this is a complete list of such items that protocol
standards must specify.  Perhaps this information could be added
after the fourth sentence of the last paragraph of 5.2.1.

#006 (E) Comment on 5.3, Figure 8
     
     This figure shows the box for "Service Delivery Port" having
two parents.  Should Clause 4.6.4 mention the possibility of
multiple parents in such diagrams?

#007 (E) Comment on 5.5.1
     
     At least four terms, "client," "initiator," "server," and
"target," are used in this clause.  Is it reasonable to replace
all instances of "initiator" by "client" and all instances of
"target" by "server"?  Or other consistent replacements?
     
     If "client" and "server" are the best terms, then
"initiator" at the end of sentence 2 in paragraph 1 probably
should be replaced by "target."  By contrast, the use of "target"
in sentence 3 seems to be reasonable.  The last sentence of that
paragraph uses both "target" and "initiator," possibly correctly.
The last sentence of the second paragraph should say "client"
rather than "initiator."

#008 (T) Comment on 5.5, last paragraph, first sentence
     
     What is meant by "The service delivery subsystem provides
error-free transmission of requests and responses ..."?  It does
not seem likely that SAM prohibits errors or requires protocol
standards to prohibit errors.  (Possibly, some text similar to
the last paragraph of 5.5.2 would be appropriate, to explain that
SAM assumes error-free transmission for simplicity but, say,
requires protocol standards to provide a certain level of
assurance of error detection and recovery.  What are SAM's actual
requirements?)

#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
standards."
     
     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 proposed in the preceding paragraph should then
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
useful.

#012 (T) Comment on 6.1.2, vendor-specific
     
     There should be some description of "vendor-specific" bits.
For instance, should SAM say the value "00" means there is no
vendor-specific information?

#013 (E) Comment on 6.2, first paragraph, second sentence
     
     This sentence mentions a service response of "Command
Complete," consistent with the service response "Send Command
Complete" in clause 6.3 but not consistent with "Task Complete",
the first of the listed "Service Response" values in clause 6.
We suspect clause 6.2 should say "Task Complete."

#014 (T) Comment on 6.2, paragraph on "BUSY"
     
     Note: this comment sneaks in some issues related to
Livermore's desire for "distributed I/O" in large configurations
where initiators are not all equally trusted.  The paragraph
describes what status to return if a command is received from an
"otherwise acceptable" initiator but says nothing about what
status to return if a command is received from an unacceptable
initiator.

#015 (E) Comment on 6.2, paragraph on "RESERVATION CONFLICT"
     
     The first sentence mentions a "RESERVE UNIT" command.  Since
that command is no longer in SPC, but new commands are being
proposed, please reword the paragraph to refer to all reservation
commands.  Consider making the following changes inside the
parentheses: change "see" to "such as", delete "and RESERVE
UNIT", and change "commands" to "command".

#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 service 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.

#019 (E) Comment on Table of Contents
     
     Each of clauses 2.1, 4.4.1, 5.2.1, 5.6.2.1, and 8.2.1 is not
followed by another clause at the same level.  In "Object
definition (6)", the letter "d" should be upper case.  "Figure
23" should be followed by a colon.  Any corrections made here
apply also to the body of the document.

#020 (E) Comment on 4.1.48
     
     It seems desirable to append to the second sentence "if
compliance is claimed", or to find some other change for the
definition of "option."

#021 (E) Comment on 4.1.51
     
     Change the "pending task" definition by adding the text "...
nor a completed task."

#022 (E) Comment on 4.1.55
     
     The definition of "protocol-specific" talks about a "SCSI-3
protocol standard," but the term "protocol standard" is never
defined. Clauses 2 and 2.1 do talk about "implementation
standards" and could easily introduce terms such as "command
standard," "protocol standard," and "interconnect standard," if
such terms would be helpful.  Clause 6.6.4 mentions "device
command standard" and "protocol standard."

#023 (E) Comment on 4.1.55
     
     The pointer to clause 1 seems bad.  Clause 2 or 2.1 seems
better.

#024 (E) Comment on 4.1.55 and 4.1.57
     
     The first of these uses "protocol standard," the second uses
"protocol specification."  Perhaps the latter is preferable
unless "protocol standard" is defined.

#025 (E) Comment on 4.1.57
     
     Why is "protocol option" defined but neither "interconnect
option" nor "command option"?

#026 (E) Comment on 4.1.96
     
     Spelling: Use "dependent."
     
     Probably a spell checker should be run on the document and
questionable spellings brought to the committee.

#027 (E) Comment on 4.3
     
     For "SCSI," replace "Either" with "Any one of".

#028 (E) Comment on 4.4, second paragraph, first sentence
     
     The word "attributes" should be singular.

#029 (E) Comment on 4.6, first paragraph, third sentence
     
     SAM does not define an "I/O bus" object; the example is
poor.

#030 (E) Comment on 4.6.1
     
     The definition of symbol "nn" is confusing.  An example that
includes at least one digit greater than 1 would help.  Currently
the confusion is not resolved until clause 4.6.2.

#031 (E) Comment on 5.1, second normal paragraph, last sentence
     
     It is not clear whether that sentence ("The description of
internal behavior ...) applies to SAM or whether it applies to
all SCSI-3 standards.  It almost surely should not apply to CAM.
     
     If it is intended to apply to any SCSI-3 standards other
than SAM, that intent should be stated more clearly.

#032 (E) Comment on 5.1, last paragraph
     
     This paragraph is helpful.  However, a complete list of SAM
clauses that apply to any SCSI-3 standards would be useful.
Clauses 4.5, 5.2.1 (at least the last paragraph), 5.6.2.1 (on
addressing the task manager), 6.1, and 6.2 should be included in
such a list, in addition to 6.3 and 7.7.

#033 (E) Comment on 5.2, first paragraph, second sentence
     
     "Dashed horizontal arrows" here conflicts with "dotted" in
the paragraph following figure 18.

#034 (E) Comment on Figures 5, 6, 16(?), 18, and maybe others
     
     The quality of figures is low enough that it is hard to tell
whether lines are dashed, dotted, solid, or something else.

#035 (E) Comment on 5.3, 5.4, and maybe elsewhere
     
     The first paragraph in 5.3 seems indented by a blank.  The
description for "Service Delivery Subsystem" in 5.4 seems
indented by a blank.  The document should be scanned for other
such possibly unwanted blanks.

#036 (E) Comment on 5.4
     
     Is "Service Delivery Interface" in Figure 9 (or any other
places that it might occur in SAM) the same as "Service Delivery
Port"?

#037 (E) Comment on 5.5.1, first paragraph, last sentence
     
     Insert an apostrophe before the "s" in "initiators".

#038 (E) Comment on 5.5.2, fourth paragraph, last sentece
     
     "or places" should be "nor places", and after "requirement
on" there should be a comma.

#039 (E) Comment on 5.6, under Object Definition (3)
     
     The text describing a Target should end with a period (or
else a lot of periods should be removed from similar descriptions
in SAM).

#040 (E) Comment on 5.6
     
     For the description of "Service Delivery Port," the words
"interconnect subsystem delivery" probably should be "service
delivery subsystem."

#041 (E) Comment on 5.6
     
     In the text describing "Port Identifier", the words "by the
device" probably should be deleted or explained.  For instance,
in Fibre Channel it is quite possible that the identifier is a
Fibre Channel address assigned by a Fabric and that the device
has no control at all.

#042 (E) Comment on 5.6.2
     
     In the description of "Logical Unit 0", if there should be
two sentences then "see" should be "See" but if there should be
one sentence then the period after "zero" should be removed.  In
either case, the period after "5.6.3" and before the closing
parenthesis should be deleted.

#043 (E) Comment on 5.6.2.1, first paragraph, second sentence
     
     Text should be added to explain which, if any, LUN value is
or can be used when external ports communicate with the task
manager.  Possibly clause 7 is a better place to provide the
information.

#044 (E) Comment on 5.6.2.1, last paragraph
     
     To improve clarity, change "An" to "If an", change "wishing"
to "wishes", change "insure" to "ensure", and insert "it" after
the comma.

#045 (E) Comment on 5.6.3
     
     The use of the term "Implementation-specific information"
and the description of this term are not helpful.  Is such
information supposed to be standard, or outside the scope of
standards?  (Keep in mind nearly all SCSI-3 standards are
"implementation standards" in clause 2.1.)

#046 (E) Comment on 5.7, first paragraph that follows figure 16
     
     For clarity, insert ", respectively" before the period
ending the second sentence.  To make the result correct, either
interchange "LLP" and "ULP" in the first sentence or else
interchange "outgoing" and "incoming" in the second sentence.

#047 (E) Comment on Figure 18
     
     Parts of the right side of the figure seem to be missing.

#048 (E) Comment on 6.1, third paragraph
     
     Should "medium" be replaced by "media information," which is
in the glossary?

#049 (E) Comment on 6.1, Table 1
     
     Should there be an alteration to the table to indicate an
arbitrary number of bytes between byte 1 and byte "n-1"?

#050 (E) Comment on 6.1.2
     
     The fourth paragraph after Table 3 should be moved to
immediately follow Table 3.

#051 (E) Comment on 6.2, "GOOD"
     
     Should "the comand" be "an unlinked command"?  Or, perhaps,
"an unlinked command or the last of a series of linked commands"?

#052 (E) Comment on 6.2, "INTERMEDIATE"
     
     The wording is awkward, in that it says a "successfully
completed command" can end with "CHECK CONDITION" or other such
status.  It should be rewritten.  The text in the following
paragraph is a better model.

#053 (E) Comment on 6.2, "TASK SET FULL"
     
     Should "TASK SET FULL" be prohibited for a CDB in a task
other than the first one?  Consider linked CDBs.

#054 (E) Comment on 6.3
     
     Should the "Send SCSI Command" request have a Command Byte
Count, in analogy with DATA IN and DATA OUT requests?

#055 (E) Comment on 6.3.1, last paragraph
     
     Should the last word, "undefined," be "unspecified"?

#056 (E) Comment on 6.4, paragraph before list of responses (page
51)
     
     Delete the second colon at the end of the paragraph.

#057 (E) Comment on 6.4, list of responses
     
     Under b), a comma (not period) should follow "POWER ON".

#058 (E) Comment on 6.4, list of responses
     
     Under f), does SAM want to discuss "OTHER PORT"?

#059 (E) Comment on 6.4
     
     Should there be a discussion (perhaps elsewhere) of possible
hazards if a CDB (not the first of a task) is sent more or less
concurrently with a unit attention condition or something else
indicating the task was blown away?

#060 (E) Comment on 6.5.2, paragraph numbered 2
     
     One of the periods after the last sentence should be
deleted.

#061 (E) Comment on 6.6.1.2, fourth paragraph
     
     Delete the ssecond comma.

#062 (E) Comment on 6.6.2, second paragraph
     
     Why is a tagged task "with a tag value exceeding FFh"
treated differently than tagged tasks with smaller tag values?
Without some explanation, this looks like a typographical error.

#063 (E) Comment on 6.6.3, a), first paragraph, third sentence
     
     The sense data must be returned by "the target", not the
nonexistent logical unit.

#064 (E) Comment on 6.6.3, d), second paragraph
     
     Why is auto contingent allegiance mentioned in case d) but
not in any of cases a), b), or c)?

#065 (E) Comment on 6.6.3, d), second paragraph
     
     The paragraph says what happens unless an ACA exists.  What
happens if an ACA does exist?

#066 (T) Comment on 6.6.3
     
     Consider adding a case "e) The target supports the logical
unit under miscellaneous, perhaps transient, internal
circumstances.  For instance, a processor device might use LUNs
to identify transactions and might make the LUN exist from the
beginning to the end of the transaction and no later."

#067 (E) Comment on 6.6.4, first paragraph, last sentence
     
     Before "SCSI-3 protocol standard", insert "applicable."

#068 (E) Comment on 6.6.5, fifth paragraph, part 1)
     
     Delete the comma following the last word.

#069 (E) Comment on 6.6.5, fifth paragraph, part 2)
     
     Three actions are mentioned.  The first (report) is
mandatory, the second (discard) is optional, and it's unclear
whether the third (clear) is mandatory or optional.  Assuming the
third is mandatory, it seems better to reorder the three actions
to make the two mandatory ones occur first.  If two of them are
optional, the wording should be changed to be explicit that each
of them, independent of the other, is optional.

#070 (E) Comment on 8, third paragraph, second sentence
     
     There should be commas following "TASK SET FULL" and "ACA
ACTIVE".

#071 (E) Comment on 8.1
     
     Is "task set" ever clearly explained as a concept in SAM?
Clause 8.1 would probably be the right place.

#072 (E) Comment on 8.2
     
     In the description of "task abort", should "6.6.2" be
"8.2.1" or something else?

#073 (E) Comment on 8.3
     
     Should there be an 8.3.5 to discuss "Current"?

#074 (E) Comment on 8.6.3 Figure 27
     
     For the task set in the upper right corner, should there
still be an ordered blocking boundary before ORDERED task 3?
     
     Should all four parts of the figure show an ordered blocking
boundary above ordered task 6?  Only the lower right one shows it
now.

#075 (E) Comment on Annex A Tables
     
     It appears that the columns in Table 1, 3, and 4 are not
always aligned.
     
     It appears that a couple of columns in Table 2 are sometimes
misaligned.

#076 (E) Comment on Annex A Tables
     
     More explanation of what the tables are saying would be
welcome.  For example, in Table 1 does "I1L0H" decode to
"initiator 1, LUN 0, Head of queue"?  Are events that are
successive in time denoted as separate rows as one reads down
toward the bottom of the table?
     
     
                         Sincerely,



                         Lansing J. Sloan


Lansing Sloan            Lawrence Livermore National Laboratory
(510) 422-4356 (phone)   M/S L-60
(510) 423-8715 (fax)     7000 East Avenue
ljsloan at llnl.gov         Livermore, CA 94550-9900  USA





More information about the T10 mailing list