SAM Comments
Gene Milligan
Gene_Milligan at notes.seagate.com
Sun Sep 6 23:24:59 PDT 2015
_Date: 01-03-94 11:29:58 AM
_To: scsi at wichitaks.ncr.com@internet
_Cc: monia @ starch.enet.dec.com @ INTERNET
_Recipient: scsi at wichitaks.ncr.com@internet
_From: Gene Milligan at SEAGATE
_Subject: SAM Comments
1/3/94
John Lohmeyer
Chairman X3T9.2
Cc: Charles Monia Technical Editor
Subject: Comments on Working Draft SCSI-3 Architectural Model (No Document
Number) Revision 12
I did not want to submit comments on one of the several X3T9.2 documents being
"forwarded" simultaneously until I had an opportunity to review them all.
Having completed the review of the set, this is the last of a series of
comments on the documents.
A number of the comments were previously communicated verbally to the
Technical Editor but are repeated here to avoid remembering wrong which ones
were previously communicated.
1) A minor nit, on the front page, the copyright notice should not mention ANSI
X3.131. since this dpANS has no resemblance to that document and therefore that
copyright could have no relevance.
2) The foreword spelling should be corrected and it should serve a more useful
purpose than inviting questions. The technical interpretation should not be
deleted but it should be preceded with some introductory information regarding
SCSI-3 and SAM. Global Engineering documents should not be in the body of the
standard - not even the foreword.
3) I think CAM should be added to Figure Anonymous in the scope. In listing
(10) the description should be updated and the (?) deleted. In listing (12) it
should be corrected to "Common" rather than "Command".
4) Delete "under X3T9.2 jurisdiction".
5) Delete "target" from SPC.
6) SBP is not the IEEE SerialBus. It is the Serial Bus Protocol for IEEE 1394.
7) For GPP, the interconnects are not packetized. GPP paketizes them. If it is
not made a technical report, delete "packetized".
8) In all instances of 1394 delete "P".
9) In the next paragraph change SCSI to SCSI-3 since SCSI-1 and SCSI-2 do not
comply with SAM.
10) SCSI-2 is not "-1992". It may be "-1993". Check with yourself to see if it
is 1993 or 1994.
11) The TBD of section 2 needs to be addressed.
12) In 3.1 the ACA attribute needs to be defined or a forward reference given.
13) In 3.1.9 "aborting" does not define "aborted". What does "execute" mean?
14) In 3.1.20 what is "starting execution"?
15) In 3.1.24 Replace "defined" with "listed" and delete "may be specified by
the system integrator or". It would be better if "implementation-specific" were
replaced with "vendor-specific" as used in SCSI-2.
16) The movement of the SCSI-2 initiator to encompass more Host functions is
troublesome. Do application clients have a close relationship to applications?
Does an application taking advantage of multiple initiators for resiliency have
multiple application clients or application clients using multiple initiators?
17) In 3.1.28 how does the single integrated path relate to full duplex SSA,
multi pathing GPP, and maximum surprise FC fabrics? An analogous question
applies to 3.1.41.
18) In 3.1.32 what is the significance of "externally"?
19) How does the LUN definition of 3.1.33 apply to a system based upon SPI?
20) The definition of "optional" should go on to state the standard verbiage
about if it is implemented it has to comply with the definitions of the
standard.
21) In 3.1.74 what does "concealed from the task" mean? Isn't there a more
direct definition.
22) I have the impression that targets receive and LUNs execute (whatever that
means). In 3.1.75 it is difficult to follow whether the target or the LUN is
being referred to.
23) In 3.1.84 I think "queuing" should be replaced with "task management".
24) Regarding 3.1.87 I thought the third party command could also involve an
initiator acting upon the behalf of another initiator.
25) In 3.2 has SCSI-3 written off SCSI-1?
26) In 3.3.1 why is neither the USA or the ISO numeric convention used?
27) In 3.4 I don't think conceptually needs to be in quotations.
28) In 3.4.2 replace "must be" with "shall be". "implementation" should be
replaced with "protocol". Is there actually a case in this standard of a
maximum where the address or identifier can not be less? Perhaps "this
standard" should be replaced with "the protocol standard".
29) Delete the small file names in each of the figures or move them to a corner
and add to the conventions what they are. Another alternative would be to make
them white on white.
30) In 4.1 It is difficult to understand how the common set of requirements in
SAM can apply to interconnects which were all developed prior to SAM.
31) In 4.2 should there be a definition for "caller".
32) In 4.2.1 hopefully task management functions provide more use than aborting
or terminating. For example I think they also allow performance optimization
through command overlapping (in the English sense - not the SCSI overlapped
sense).
33) In the last line of 4.2 I doubt that 4.4 defines each system component.
34) Figure 9 seems to imply that the I/O System Model is a loop. Perhaps there
should be a note to indicate that other than a loop is accommodated.
35) In 4.6 the last line could benefit from different terminology than "order".
It implies that chaos is also allowed.
36) The page layout should be adjusted to allow Figure 13 and some of the other
figures to be larger for readability.
37) The Application Client box in Figure 15 is incomplete.
38) Is it true that an initiator can have as low as 0 Application Clients? (Is
the system turned on?)
39) In 4.7.2 why the disparity between Logical Unit and Target. Why isn't the
definition Logical Unit Number or Target? (Why Target Identifier?)
40) Regarding the note in 4.7.3.1, why isn't this true even if other requests
are not pending?
41) Why doesn't 4.7.3.2 have an upper bound of one on untagged tasks per
initiators?
42) Another nit, the comma in 6 should be outside the bracket enclosing
"Autosense data".
43) The ??? needs to be replaced with a section number.
44) "(see clause 6.5.8" needs a closing bracket.
45) Under Autosense Return Flag - Status replace "shall be undefined" with "is
not valid".
46) In the last line replace "The actual events" with "The protocol events".
47) In the title for 6.1 delete "Implementation".
48) In the first and third instance change SCSI-3 to SCSI. Also change "future
revision to" to "future version of".
49) In the first paragraph of 6.2 delete "one of".
50) Change "All SCSI protocol specifications shall accept" to "All SCSI
protocol standards shall define".
51) In 6.2.1 why is Group 5 the only one with a table reference?
52) Should the Group 6 and 7 vendor specific commands now be limited to 16 or
less bytes?
53) In 6.2.2 does the citation of of protocol standards include CAM and SCSI-2?
54) What does item (d) of 6.3 mean?
55) I remain concerned that there may be a conflict with the installed base
which had a presumption of bit significance and the use of the BUSY bit in the
Task Set Full Status code.
56) If the committee again rules out bit significance of the installed base,
the bit significant language of Intermediate_Condition Met should be changed.
57) In 6.5.1 the second paragraph is too definite on what can be changed.
Change "The parameters that can be be changed by" to "Among the parameters than
might be capable of being changed by".
58) The last sentence of the second paragraph seems to denigrate the
recommended procedures of SCSI-2 to "vendor specific cases". Why is this?
59) In the third paragraph change "should" to "shall".
60) The next two paragraphs need to be challenged on the basis of "execution".
61) Change the last phrase to "optionally descriptive".
62) In the last sentence of 6.5.2 delete "construed to mean".
63) In 6.5.2.2 I think the ACA should be cleared by a power off condition
rather than power on.
64) It appears to me that the next to last paragraph should be included after
item (a) (the second (a)).
65) Why should a protocol standard not require overlapped commands (in the SCSI
sense) to be detected? (6.5.3).
66) In 6.5.4 should the " e.g." statement be "one peripheral device" or "one
LUN"?
67) In the last sentence of 6.5.8 replace "client must issue" with "client
shall issue".
68) In 6.6 the "(to be specified)" needs to be replaced.
69) I recognize that the wording of item (f) is the same as SCSI-2. However, is
the intention that the Unit Attention condition be set even if there was no
change to the parameters?
70) The wording of (h) has changed. Shouldn't "that requires the attention of
the initiator" still be included? Otherwise the interfaces will do nothing but
service events they do not need to.
71) In the fifth paragraph item (1) change "on the logical unit" to "for the
logical unit".
72) In item (2) delete "may" or it collapses to item (1).
73) In the last paragraph delete "on the logical unit".
74) In 7.1 there is approximately an infinite amount of information concealed
|from the task but most of it is not suspended information. A better definition
is needed for suspended information.
75) The concept of an Ordered Blocking Boundary should not be enclosure but
should be a separation boundary. Comment also applies to Figures in section 7.4.
76) In the second line of 7.2 change "is a description these" to "is a
description of these".
77) A page break, as the document stands now, would be beneficial ahead of
"Events:"
78) A reference should be given to the location of the QErr bit definition.
79) I consider issuing "Command Complete" part of "command execution". I
suggest Enabled be "The task may continue processing and issue a service
response of Command Complete."
80) Assuming a task can not be simultaneously Held and Blocked, I suggest
replacing "The state of a once" with "The new state of a".
81) I don't consider TERMINATE TASK executed until the task is ended and has no
state. What if the ACA was for the task of the TERMINATE TASK? My informed poll
did not uncover any implementors of TERMINATE TASK.
82) Why is Dormant singled out for the extra discussion? An exception to the
description is the time from created to completed which is observable.
Therefore the "shall" requirement can not be met.
83) In 7.3 the description of what Figure 23 and Table 10 are don't seem to
match the nomenclature of the figure and the table.
84) It can not be deduced from 7.2 that an isolated (the only command this
week) SIMPLE task starts in the Dormant state. I thought it started Enabled.
85) A small nit, change "As shown Figure 22," to "As shown in Figure 22,".
86) In the line ahead of Table 9 delete "be".
87) In the third from last paragraph, Termination Pending, it is not clear
what caused the second ACA.
88) An exception to the next to last paragraph is if the state were already
Done.
89) In 7.4 it does not appear that the Legend box is needed. If It were deleted
the figures could be bigger and more readable. Less shading would also help
readability.
90) In the dreaded IMPLEMENTORS NOTES of section 8, change "all initiators on
all task sets" to "all initiators in all task sets".
91) In 8.1 change item (2) to "begins processing the function."
92) In the last paragraph of 8.4 change "When" to "After". (Fewer carriage
returns above that paragraph might take care of the orphan problem for
"Description:" in 8.7.)
93) The third from last paragraph, counting the note, of 8.7, suffers from
confusion as to which function or task is being referred to. Consequently I
concluded that if the target could not stop a task, the task would be
completed. But if it didn't support the function the task could not complete in
a normal manner. I think the paragraph can only be understood if the reader
already knows how it works and can fault tolerantly process the terminology.
94) Another nit, "(Autosense Buffer Pointer,)" should have the comma after the
parenthesis.
95) I had awarded the "a/an" prize to the SBP editors but perhaps you should
share it. Because it is so distasteful I can not tell you what to do about the
"n" ahead of "SCSI" in the second paragraph of Annex A.
96) Annex C should be deleted and any needed information, if not covered by SAM
already, included in SAM.
G.E. Milligan
--
Gene Milligan (Gene_Milligan at notes.seagate.com)
-------------------------------------------------------------------------
Seagate Technology - 920 Disc Drive - Scotts Valley, CA 95066 USA
Main Phone 408-438-6550 - Email Problems postmaster at notes.seagate.com
Technical Support: BBS 408-438-8771 Fax 408-438-8137 Voice 408-438-8222
-------------------------------------------------------------------------
More information about the T10
mailing list