SAM Comments

Gene Milligan Gene_Milligan at
Sun Sep 6 23:24:59 PDT 2015

_Date: 01-03-94 11:29:58 AM
_To: scsi at
_Cc: monia @ @ INTERNET
_Recipient: scsi at
_From: Gene Milligan at SEAGATE
_Subject: SAM Comments

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 

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 

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, why isn't this true even if other requests 
are not pending?

41) Why doesn't have an upper bound of one on untagged tasks per 

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 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 

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 

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 

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 

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 

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
Seagate Technology   -   920 Disc Drive   -   Scotts Valley, CA 95066 USA
Main Phone 408-438-6550   -   Email Problems postmaster at
Technical Support: BBS 408-438-8771  Fax 408-438-8137  Voice 408-438-8222  

More information about the T10 mailing list