4/16/89     X3T9.2/89-55 Rev 1
Del Shoemaker
Chairman X3T9
Digital Equipment Corporation
Suite 600,  MS: WNP
1331 Pennsylvania Avenue NW
Washington, DC 20004

Subject: Comments accompanying my letter ballot on forwarding 
X3T9/89-042 dated 3/16/89

     The members of X3T9.2 and especially the editors should be 
congratulated on their drafting of SCSI-2 which enhances the SCSI 
definition while maintaining downward compatibility with the 
implementations which are already a valuable factor in the market 
place. As far as SCSI-2 is concerned, the standards community 
should now turn their attention to making the necessary document 
changes to enable publication of this important standard. The 
following items are my contribution to the publication revisions 
and are the comments cited by the signature page of my letter 
ballot.

     I am providing an electronic copy of this letter, but not 
the signature page of the ballot, to be made available to 
followers of the X3T9.2 activity.

     Since it was necessary to read the entire document to obtain 
the non-trivial comments and since it would appear to be a 
massive task for the ANSI editor to catch all purely editorial 
items, I decided to include some comments I might have omitted 
from a reasonably sized document.

     My comments by document sequence are:

1) As in my vote on SCSI-1, I recommend that all references to " 
small computers " be modified to "physically small computers". As 
in the vote years ago, the reason for this is that SCSI is 
applicable to high performance processor configurations which are 
not classified as "small computers". To avoid many changes in the 
document, I would be satisfied if this change were only made in 
the Abstract on the cover page.

2) The warning notice should be changed. It is being forwarded 
for the purpose of final review and publication.

3) Since the standard is not the place to provide implementation 
choices and the phrase is unnecessary, on page 1-1 delete 
"depending upon the implementation choices".

4) It seems to me the third key objective on page 1-1 is in 
conflict with the statement of what it requires. The statement is 
"A third key objective of SCSI-2 is to move device-dependent 
intelligence out to the SCSI-2 devices.  This requires the 
definition of a command set that allows a sophisticated operating 
system to obtain all required initialization information from the 
attached SCSI-2 devices."

     The objective could be met without obtaining all required 
initialization information from SCSI-2 devices. Much of the 
information has been included for the convenience of implementing 
SCSI bridge controllers.

5) The discussion of drivers and receivers is out of place on 
page 1-1. It should be slightly modified and moved to a position 
later in the scope as follows:

     "--- A logical unit may coincide with all or part of a 
peripheral device.

     "The interface protocol includes provision for the 
connection of multiple initiators ---

--- mixed on the same bus.  

Provision is made for cable lengths up to 25 meters using 
differential drivers and receivers.  A single-ended driver and 
receiver configuration allows cable lengths of up to 6 meters and 
is primarily intended for applications within a cabinet."

     Section 5 describes ---" 

6) As in prior votes I still have difficulty accepting a 
statement that parts of a document are not part of the document. 
Please change page 1-3 to "--- However, the appendixes are not a 
required part of this standard. "

7)  On the assumption that ISO 8482 is too broad to be entirely 
applicable, I suggest changing page 2-1 to " The requirements of 
ISO 8482:1987, "Information Processing - twisted pair multi-point 
interconnection data communication" apply to the use of 
differential drivers and receivers.

8) The reference to SCSI should be improved by modifying the 
reference to " American National Standard Small Computer System 
Interface, X3.131-1986, may also be useful to achieve 
compatibility with devices that conform to version 1 of SCSI."

9) Should the disconnect definition be expanded on page 3-1? If 
an initiator selects a SCSI device that is not there, does it 
disconnect?

10) Beginning with page 3-1 and occurring in numerous locations 
throughout the document is an abrasive phrase, "an SCSI". My vote 
on SCSI-1 objected to this phrase. I still object. It is true 
that their is a guide that the letter "S" is pronounced "es" and 
therefore it can be concluded "an SCSI" is correct. However it 
makes strong men shudder. Clearly "Small" should be preceded by 
"a" not to mention that "Skuzzy" should be preceded by "a". Even 
if SCSI is interpreted as "es see es eye" preceding it with "a" 
does not have the connotation of "finger nails on the 
blackboard."

11) If only a message is passed, has an I/O process occurred? If 
it has, should the definition be changed?

12) I think LUN is used more broadly. Consequently I think the 
definition should be expanded to "LUN.  Logical unit number. Also 
used to refer to the logical unit."

13) Similarly expand "one.  A true signal value or a true 
condition of a variable."

14) Should "target routines" include messages?

15) On page 4-1 it is confusing if the minimum conductor size is 
a diameter with a call out to Note 2 or if it is square 
millimeters. I suggest that Sections 4.2 and 4.2.3 be changed to 
"--- 0.08042 square mm ---".

16) To eliminate ambiguity change 4.2.1 to "--- The maximum 
cumulative cable length shall be ---" 

17) Amplify the stub length requirement to "A stub length of no 
more than 0.1 meters is allowed off the mainline interconnection 
within any connected equipment or from any connected point."

18) Modify the termination requirement to "SCSI bus termination 
shall be at each end of the cable and may be internal to the SCSI 
devices that are at the ends of the cable."

19) Modify Section 4.2.2 on page 4-2 to "The maximum cumulative 
cable length shall be 25 meters.  ---"

20) Amplify the stub length requirement to "A stub length of no 
more than 0.2 meters is allowed off the mainline interconnection 
within any connected equipment or from any connected point."

21) Modify the termination requirement to "SCSI bus termination 
shall be at each end of the cable and may be internal to the SCSI 
devices that are at the ends of the cable."

22) On page 4-19 the requirements of items 1 and 2 of Section 
4.4.1 are conflicting. The requirement in 1 is equivalent to 125 
ohms to 139 ohms. I recommend that requirements 1 and 2a be 
combined to "--- may choose a method meeting the following 
conditions:

     a) The termination of each signal shall supply a 
characteristic impedance between 100 and 139 ohms. The 
utilization of +/- 1% resistors typically improves noise margin. 

     b) ---

     c) The current available to any signal line driver shall not 
exceed 48 milliamps when the driver asserts the line and pulls it 
to 0.5 volts d.c.

     d) ---

     e) ---"

     The specified impedances and voltages do not allow the 
requirement in the original (c) to be met.

23) Add to Section 4.4.2 "The utilization of +/- 1% resistors 
typically improves noise margin. "

24) The original intent for a minimum 4.25 V single ended 
termination voltage was at the end of the cable (termination 
point). This intent should be reflected in the documentation. I 
recommend changing Section 4.4.3 to "--- may supply terminator 
power. Interface error rates are lower if the terminator voltage 
requirements are maintained at the extreme ends of the cable."

25) From a regulatory standpoint I see no justification to 
recommending a current limit of 1 amp in one cable and 2 amps in 
another cable of the same wire gauge. Unless there is a 
justification, I recommend making both 2 amps.

26) A recent change to Section 4 has added impractical 
requirements. A mass produced SCSI device should not have to know 
at what position it will be installed. Section 4.4.4 requires a 
change to make it palatable with mass production. I object to " 
The lines labeled RESERVED in the A cable contact assignment 
tables (Table 4-2 and Table 4-4) shall be connected to ground in 
--- the end devices on the SCSI cable.  The RESERVED lines should 
be open in the other SCSI devices, but may be connected to 
ground." To accomplish the intent of these lines which have been 
changed from ground to reserved, I suggest the following revised 
wording : "SCSI-1 required that the lines, now designated as 
RESERVED (Table 4-2 and Table 4-4) be grounded. SCSI-2 has 
changed these lines to RESERVED to allow the possibility of 
utilizing these lines in a future version of SCSI for some other 
purpose such as additional terminator power. SCSI-2 specifically 
allows plug compatibility with SCSI-1 and therefore it is 
permissible for the lines designated as RESERVED to be grounded. 
Designs initiated after the publication of SCSI-2 should 
accommodate a new preferred configuration. The new configuration 
should allow these lines to be continuous with the daisy chain 
connection and should other wise be available for a Terminator. 
The terminator shall connect the RESERVED lines which correspond 
to the odd line numbers in Set 1 to ground. The terminator shall 
connect the RESERVED lines which correspond to the even line 
numbers in Set 1 to either ground or to an impedance no smaller 
than the specified terminator values and no greater than 1.5 k 
ohms."

     To tie the requirements together this change should be 
accompanied by an addition to 4.4.1 which states "--- of the 
cable. See Section 4.4.4 for terminating requirements for the 
RESERVED lines."

27) The sample SCSI configurations on page 4-24 leave out the 
highest volume implementation, embedded SCSI disk drives. Why not 
show at least one?

28) On page 4-25 the wording should be corrected to "--- any 
combination of initiators and targets except eight targets."

29) The utilization of signals on page 4-25 would be clearer if 
it stated " A total of 11 signals are used for control and 36 are 
used for data (messages,commands, status, and user data), 
including parity.  ---" 

30) To avoid confusion change 4.6.1 to " --- In the case of non-
OR-tied drivers, the signal may be actively driven false. In this 
standard, wherever the term negated is used, it means that the 
signal may be actively driven false, or may be simply released 
(in which case the bias circuitry pulls it false), at the option 
of the implementor.  --- simply released. This facilitates the 
reliable transfer of data at high rates, especially at the longer 
cable lengths used with differential drivers."

31) Since the parity bit must operate as fast as any other bit, 
should the fact that this "OR-tied" may be driven false during 
data transfers be emphasized rather than just concluded by 
contrast to arbitration?

32) To indicate the actual requirement change 4.7.7 on page 4-29 
and 4.8.2 on page 4-31 to " --- maximum difference in propagation 
time allowed between any two SCSI bus signals measured between 
any two SCSI devices ---"

33) In Section 4.7.11 on page 4-30 "respectively" is not needed 
and implies a more complex relationship then required for this 
simple requirement.

34) Ordinarily it is not productive to impose timing restrictions 
too small for items that have no perceptible impact upon 
performance. Consequently the Selection Time-out Delay should be 
changed in 4.7.17 to "--- The specifications for the peripheral 
devices shall be consulted for potential longer timing 
requirements."

35) To eliminate a subtle double negative, change Section 5.1 on 
page 5-1 to "--- time. In the following descriptions, signals 
that are not mentioned shall not be asserted."

36) Make Section 5.1.1 more crisp and complete by changing it to 
"The BUS FREE phase is used to indicate that no SCSI device is 
actively using the SCSI bus and that it is available. In some 
cases BUS FREE is reverted to by a SCSI device" (or should it be 
target?) "to clear an error condition that it has no other way to 
handle."

37) Clarify the actual function of 5.1.2 on page 5-2 by changing 
it to "The ARBITRATION phase allows one SCSI device to gain 
control of the SCSI bus so that it can initiate or resume an 
operation. --- a "wired-OR glitch" may ---" The last change 
should also be made in Section 5.1.4.1 on page 5-4.

38) Requirement (4) allows a SCSI device a freedom of choice it 
should not have. This requirement should be changed to "--- then 
the SCSI device has lost the arbitration and the SCSI device 
shall release its signals within a bus clear delay after SEL 
becomes true and may return to Step (1).  If no higher priority 
SCSI ID bit is true on the DATA BUS, then the SCSI device has won 
the arbitration and it shall assert the SEL signal." Delete the 
balance of requirement (4). 

39) Section 4.6 states that parity is not defined during the 
selection phase. This is in conflict with Section  5.1.3 which 
states "--- The target shall not respond to a selection if bad 
parity is detected.  ---"

40) The implementors note on page 5-8 is too obtuse. "n and m" 
have not been defined. Is m=1?

41) Should a timing requirement be added on page 5-11 to quantify 
5.1.9.2 with respect to "--- When re-sending more than one 
message byte, the initiator shall assert the ATN signal prior to 
asserting the ACK signal on the first byte ---"?

42) On page 5-15 and 5-16, it should be noted that Figure 5-3 
does not actually show all allowable phases. Therefore the third 
paragraph of Section 5.3 should be modified to " The additional 
allowable sequences shall be as shown in Figure 5-2.  ---".

43) On page 5-18, I think a note should be added to indicate that 
Abort Tag and Clear Queue are mandatory if the Queuing option is 
implemented.

44) With the Ignore Wide Residue message being only inbound, how 
does a target know if the initiator has transferred the intended 
logical block size (why isn't it a bilateral process)?

45) On page 5-18 it is a little confusing to have a footnote on 
codes not listed. I suggests modifying it to "80h+ = Codes 80h 
through FFh are used for IDENTIFY messages. See Table 5-7."

46) An extended message comprising only three bytes is a 
nonsequitur and none are defined. Please change the top of page 
5-19 to "The minimum number of bytes sent for an 
extended message is four."

47) Why was the Abort Tag Message Format deleted from page 5-21?

48) In section 5.6.2 a classic illustration, of the difficulty 
caused by not capitalizing SCSI Functions and fields, occurs. 
A normal reading of "Pending status, data, and queued I/O 
processes for any other I_T_x nexus shall not be cleared." makes 
it appear that the sentence was incomplete. This difficulty is 
avoided by "Pending_Status, Data, and Queued I/O 
Processes for any other I_T_x nexus shall not be cleared." While 
the clarity of the standard would be increased by more liberal 
capitalization, I think it is too late. I assume the difficulty 
of changing the convention at this stage would be too large a job 
and be subject to errors. I leave it to the judgment of the 
editor.

49) I presume in some cases such as linked commands and ordered 
queuing it will not be practical for the "Execution of other I/O 
processes --- to continue in the normal manner." Consequently I 
recommend changing the last sentence of Section 5.6.2 to 
"Execution --- shall not be aborted." On the other hand it is not 
clear why both of the last two sentences are needed. 

50) To stay with SCSI definitions 5.6.3 should be changed to "--- 
selected SCSI device. The target ---"

51) To avoid incomplete configuration changes, should the last 
paragraph of Section 5.6.4 be changed to "Previously established 
conditions, including MODE SELECT parameters, reservations, and 
extended contingent allegiance and executing MODE SELECT commands 
shall not be changed by the CLEAR QUEUE message."? If so the 
first paragraph would need to be modified to "--- All executing 
I/O processes except MODE SELECT shall be halted. ---".

52) Add an "a" or a "the" to Section 5.6.6 to produce, for 
example, "--- respond by sending a MESSAGE REJECT message to the 
initiator."

53) Having looked back for a code in Table 5-2, I suggest it be 
changed to code order.

54) Since there can be more than one LUN, the wording in 5.6.8 
should be modified slightly to "A LUNTAR bit of one specifies 
that the IDENTIFY message is directed to a target routine that 
does not involve a logical unit."

55) Why are the target routines limited so much? For example if 
no LUNs are attached to a bridge controller, would it be 
desirable to be able to execute diagnostics?

56) To be precise change the last paragraph to "--- on the next 
phase for an inbound IDENTIFY message sent during reconnection."

57) Prediction is too risky. The last paragraph of Section 5.6.8 
should be changed to "Even though a byte is invalid its 
corresponding parity bit shall be valid for the value 
transferred.  ---"

58) The last paragraph of Section 5.6.9 should be changed to add 
some "an"s. "A MESSAGE REJECT response to an INITIATE RECOVERY 
message indicates that an extended contingent allegiance 
condition shall not be established.  The enabled or disabled 
state of an extended contingent allegiance is not changed by the 
rejection of an INITIATE RECOVERY message."

     However with the paragraph cleaned up it still seems 
contradictory. What is the meaning of the conjunction of "shall 
not be established" and "enabled --- is not changed ---"? Does it 
mean if an Initiate Recovery message is transmitted and accepted 
and then the target stutters with another Initiate Recovery 
message the second can be rejected without impacting the effect 
of accepting the first?

59) I thought it had been concluded that repeated messages should 
not cause a repeat of actions already taken. Is this wrong or 
lost? Should the implementors note on page 5-25 be a requirement 
and should it be modified?

60) In Section 5.6.17 shouldn't "A queue tag becomes available 
for re-assignment when the I/O process ends." be removed from the 
Implementors note and inserted into the basic standard?

61) Should Section 5.6.17 or 5.6.17.2 be expanded to state that 
the number value of the Queue Tag has no meaning regarding the 
sequence of execution?

62) It seems to me the requirement is much clearer if the 
parenthesis are removed from Section 5.6.19.

63) Should Section 5.6.21 be expanded to indicate that the 
synchronous data transfer agreement applies only to the Data 
Phase?

64) For completeness the second paragraph should be changed to 
"--- SCSI devices that are capable of synchronous data transfers 
shall not respond to an error free SDTR message with a MESSAGE 
REJECT message."

65) It was agreed that the SDTR negotiation would be changed to 
prevent the result from being too low. The wording didn't achieve 
this goal. The agreement can be implemented by changing the third 
full paragraph on page 5-29 to "--- successfully.  If the 
responding device can also receive data successfully with these 
values or smaller periods and/or larger offsets, it returns the 
same values in its SDTR message.  ---" 
66) Modify the next to last paragraph on page 5-32 to "--- shall 
not respond to an error free WDTR message with a MESSAGE REJECT 
message."

67) Remove an extra "by" from page 5-33 by changing the last 
paragraph to "--- This may be done either by changing to any 
other ---"

68) I had forgotten to ask, are "Implementors Note"s plural or 
possessive?

69) On page 6-2, it strikes me that performed is the wrong 
word. I suggest the sentence be changed to "A request to a 
peripheral device is communicated by sending a command descriptor 
block to the target."

70) I think some "why" and "shall" should be added to Section 
6.2.2 in the paragraph or in the Warning. If in the warning, I 
suggest: "
WARNING:  The logical unit number field is included in the 
command descriptor block for compatibility with some SCSI-1 
devices.  This field may be reclaimed in SCSI-3.  New 
implementations shall use the outbound IDENTIFY message which is 
mandatory in SCSI-2 to establish the I_T_L nexus."

71) Section 6.2.4 definitely needs a "be". Change it to "--- 
indicates the number of blocks that shall be transferred." 

72) For correctness change 6.2.6 to "The allocation length is 
typically used to limit the maximum amount of sense data (e.g., 
mode data, log data, diagnostic data, etc.) returned to an 
initiator."

73) In Section 6.3 there is a conflict between the description of 
the Condition Met and Intermediate statuses. I suggest changing 
Link bit on page 6-7 to "--- upon successful termination of the 
command, shall return INTERMEDIATE or CONDITION MET status and 
shall then send one of the two messages defined by the flag bit 
(above)" and Intermediate on page 6-9 to "--- If this status or 
Condition Met status is not returned, the chain of linked 
commands is broken; no further commands in the series are 
executed."

     An alternative solution would be to change Condition Met to 
"CONDITION MET.  This status is used only for non-linked 
commands. Non-linked SEARCH DATA commands shall return this 
status whenever a search condition is satisfied.  This status 
breaks a chain of linked commands.  --- This status is also 
returned by non-linked PRE-FETCH commands when there is 
sufficient space in the cache memory for all of the addressed 
logical blocks.

     I prefer the first solution since the second while 
consistent defeats a major reason for linking.

74) You will notice that the plague of "an SCSI" has contaminated 
the thinking of the editors. Please change QUEUE FULL to "--- a 
SIMPLE ---".

75) In addition it seems to me Section 6.8.2 indicates that the 
QUEUE TAG occurs before the command is sent, therefore the last 
sentence of 6.3 should be changed to "The command descriptor 
block is not requested during this I/O process."

76) Unless more care is used in the descriptions it will not be 
practical to reclaim the LUN bits in the CDB. Modify Section 
6.4.1 to "--- After a successful IDENTIFY Message the target 
obtains the command from the initiator (in this case, a READ 
command).  --- "

77) Change 6.4.2 to "---When the data are ready to be 
transferred, the target arbitrates for the bus and when 
successful reconnects to the initiator.  --- The initiator 
recognizes that the operation is complete when the COMMAND 
COMPLETE message is received."

78) Modify 6.4.3 on page 6-10 by changing the last sentence in 
the first paragraph to "All commands in a series of linked 
commands shall be addressed to the same logical unit." and by 
deleting the last sentence in the third paragraph.

79) Not all items under Section 6.5 are exception conditions. The 
Section needs a more appropriate title. At the moment I don't 
have one I am proud of, but perhaps "Command Processing Special 
Considerations and Exception Conditions" will do.

80) Section 6.5.1 should be modified to "--- more 
recently developed targets meeting a different level of SCSI 
specification in systems which comply with the low-level hardware 
definitions of SCSI-2. ---" or by changing it to "The low-level 
hardware parameters, including REQ/ACK to DATA BUS timing, 
arbitration timing, and parity definitions probably cannot be 
changed by modifying the operating definition. ---".

     By the way, should there be a statement somewhere about how 
you get back to SCSI-2 after being changed to SCSI-1?

81) Change the first paragraph on page 6-12 to " An initiator may 
interrogate the logical unit for an optional list of the operating 
definitions it supports. After obtaining the list, the initiator 
may obtain optional descriptive text for each operating definition.  

82) It seems to me the most likely implementors to choose not to 
implement the SNS function are those that can't find where it is 
documented. It is not apparent that the CHANGE DEFINITION command 
has an SNS bit.

83) It is not clear to me why a redundant I/O process is always 
to be considered a catastrophic failure. As a user I occasionally 
consciously repeat a command simply because I was interrupted by 
a phone call. It seems to me, no harm, no foul. Why isn't Busy an 
allowable choice in Section 6.5.2?

84) In Section 6.5.3 on page 6-13 should the requirement be 
changed to "(3) --- The target's response to any command other 
then INQUIRY or REQUEST SENSE is vendor specific."?

85) Why use the mixed up terms? I suggest Section 6.5.5 be 
changed to "--- is not intended to be used while an I_T_L/R nexus 
exists between the processor device (initiator of the nexus) and the 
other SCSI device (target of the nexus)." or should it be "--- is 
not intended to be used while an I_T_L nexus exists between the 
processor device (initiator of the nexus) and the LUN (logical 
unit of the nexus) of the other SCSI 
device."?

86) Section 6.6 on page 6-16 would be clearer if Contingent 
Allegiance Condition were defined. The definition should either 
be at he start of the section or in the glossary. A candidate 
definition is:

"Contingent Allegiance Condition is a state assumed by a target 
after a detected error which assures the best available chances 
of recovery until the current initiator has an opportunity to 
take action on the error."

87)The requirement should be modified to "Those targets that do 
not maintain independent recovery operations and independent 
sense information, ---".

88) In a total reading of Section 6.8.1 it appears that the last 
sentence of the first paragraph should be changed to "Only one 
command for each I_T_x nexus shall be accepted at a time."

89) In addition the last sentence of the first paragraph on page 
6-18 should be changed to "It is the responsibility of the 
initiator to assure that only one such command is issued at any 
time (see 6.5.2)."

     This item is dependent upon the outcome of my comment (83). 
However, Section 6.5.2 is a better place to have the cross 
reference if not in both places.

90) On page 6-18, the wording is not clear, to me, as to whether 
six linked commands have one or six queue tags. Assuming an abort 
tag would abort the entire link with the single tag, I suggest 
the following change to the second paragraph of 6.8.2.

"--- Each I/O process may be a command or a set of linked 
commands with a unique queue tag identifying the first of the 
linked commands."

91) Change the last sentence of the second paragraph on page 6-19 
to "--- even though all of the linked commands may not yet be 
present in the queue."

92) Change the last sentence of the fifth paragraph to "--- since 
the information returned has no effect on the condition of the 
logical unit."

93) The wording of Extended Contingent Allegiance makes it clear 
that recovery operations are handled by non-queued commands, 
therefore I suggest the first sentence of paragraph seven on page 
6-19 be changed to "The first post recovery option is to continue 
execution of commands in the queue after the contingent 
allegiance or extended contingent allegiance condition has 
cleared."

94) The next sentence should be moved to Sections 6.6 and 6.7.

95) The third and fourth sentences should be deleted. 

96)  The second and third sentences of the ninth paragraph should 
be deleted. The fourth should be modified to "When the queue is 
cleared because of this recovery option, a unit attention 
condition shall be created for all other initiators and the 
additional sense code shall be set to TAGGED COMMANDS CLEARED BY 
ANOTHER INITIATOR."

97) Change Section 6.8.3 to " An example of I/O process queuing 
benefits from the consideration of the execution of a number of 
commands.  After each command, the state of the queue kept in the 
target is shown to indicate the function actually performed by 
the queuing."

98) Modify the last paragraph on page 6-20 to "---when the 
target is prepared to transfer the appropriate data, ---".

99) In Section 6.9, condition (8) should be modified back to the 
sense of earlier revisions by changing it to "Any other event 
occurs that requires the attention of the initiator."

100) Change 7.1.1.1 to "used during bus arbitration and selection 
or reselection of SCSI devices.  Each device on the SCSI bus is 
assigned an unique address."

101) Move the first paragraph of 7.1.1.2 to be the last 
paragraph.

102) Section 7.1.1.3 could be impacted by my comment (55)

103) It strikes me as bad standards practice to say a mandatory 
command is not essential. Change Section 7.1.2.4 to "Although the 
TEST UNIT READY command is quite useful in that it allows ---".

104) It would be helpful to add command type to Table 7-1 as 
shown below:

                  Table 7-1: Commands for All Device Types

=================================================================
                           Operation         
Command Name                 Code        Section      Type
-----------------------------------------------------------------
CHANGE DEFINITION             40h          7.2.1       O
COMPARE                       39h          7.2.2       O
COPY                          18h          7.2.3       O
COPY AND VERIFY               3Ah          7.2.4       O
INQUIRY                       12h          7.2.5       M
LOG SELECT                    4Ch          7.2.6       O
LOG SENSE                     4Dh          7.2.7       O
MODE SELECT(6)                15h          7.2.8       D
MODE SELECT(10)               55h          7.2.9       D
MODE SENSE(6)                 1Ah          7.2.10      D
MODE SENSE(10)                5Ah          7.2.11      D
READ BUFFER                   3Ch          7.2.12      O
RECEIVE DIAGNOSTIC RESULTS    1Ch          7.2.13      O
REQUEST SENSE                 03h          7.2.14      M
SEND DIAGNOSTIC               1Dh          7.2.15      M
TEST UNIT READY               00h          7.2.16      M
WRITE BUFFER                  3Bh          7.2.17      O
==============================================================
D=Device Type dependent  O=Optional  M=Mandatory

105) It does not seem appropriate to me to include Vendor 
Specific suggestions as implementor's notes. Delete the second 
IMPLEMENTORS NOTE on page 7-5.

106) For clarity modify item (2) to "--- capable of maintaining 
an unique operating definition, for each initiator in the system,
that applies to all logical units of the target."

107) Add an "a" to (3) "The operating definition of a logical 
unit relative ---".

108) Modify the IMPLEMENTORS NOTE at the bottom of Page 7-5 to "-
-- other initiators in the system operating below the SCSI-2 
level."

     You should also note that the numerical designation of items 
is not clear. It would be clearer if items were enumerated where 
they occur as for example "1)" and where they are cited within 
the text as for example "(1)". 


109) In Section 7.2.3.5 on page 7-14 change the last paragraph to 
"If block-length mismatches are detected prior to the beginning 
of the read operation by the SCSI device managing the COPY, ---".

110) Change the second paragraph on page 7-15 to "--- Destination 
block length mismatches are handled in analogous manner as source 
block length mismatches."

     They are not the same, as write operations are pertinent, 
not read operations.

111) Change Section 7.2.3.7 on page 7-16 to "--- (in each 
applicable segment descriptor) are defined in Table 7-12."

112) Change the last entry in Table 7-12 to "--- This code is not 
valid in the last segment of the COPY command."

113) Delete the last sentence on page 7-19 in Section 7.2.5.1. It 
is redundant to the first sentence of the third paragraph on page 
7-18.

114) Modify the 1Fh entry in Table 7-17 to "Unknown or no device 
type"

115) It is not clear to me why the mandatory Inquiry command 
should allow non-supporting SCSI devices to return the wrong 
device type. This appears to be in part due to our not coming to 
grips with fully specifying what is mandatory and what is 
optional. I suggest that the second paragraph on page 7-22 be 
changed to "--- SCSI devices that do not support this feature 
shall return 1Fh."

116) At what actual point will the wording of 2h in Table 7-18 
change?

117) The wording in Table 7-18 for 0h should be changed to "The 
device does not comply with an ANSI SCSI standard or was 
implemented prior to the final approval of SCSI-1 by ANSI."

118) Consideration should be give to assigning 3h for devices 
which comply with CCS and SCSI-2.

119) Modify paragraph 8 on page 7-23 to "--- A value of zero 
indicates the device does not support tagged command queuing for 
this logical unit."


120) Modify the IMPLEMENTORS NOTE at the end of Section 7.2.5.2 
to " The vital product data would be obtained for the failing 
device by using the INQUIRY command.---The contents of the data 
is vendor-specific; therefore it may require detailed information 
about the device. ---".

121) Delete "in a rigorous manner," from the first paragraph of 
Section 7.2.6.

122) The first implementor's note on page 7-26 should be part of 
the text and not a note.

123) The second implementors note on page 7-26 adds no value and 
should be deleted.

124) The implementors note on page 7-29 should be deleted. It is 
redundant to the information presented in 7.2.6 and if it was not 
redundant it should instead be in Section 7.2.6.

125) It seems to me that logical unit encompasses the peripheral 
device and medium. Consequently I think the first paragraph in 
Section 7.2.8 and 7.2.9 should be modified to "--- provides a 
means for the initiator to specify logical unit parameters to the 
target. --- ".

126) In Section 7.2.8 the last sentence of the second paragraph 
"If separate copies are saved, the target shall maintain separate 
current values for each I_T_L nexus. Pages which are common to 
all initiators are not required to have multiple copies." and the 
first sentence of the fourth paragraph "The target may provide 
for independent sets of parameters for each attached logical unit 
or for each combination of logical unit and initiator. " appear 
to be in conflict. I think the latter should be deleted.

127) I am puzzled by the forward reference in the second 
paragraph on page 7-31, Section 7.2.8, since it points to a 
different additional sense code. This confusion would be avoided 
by changing the paragraph to "--- header by the MODE SENSE 
command (see 7.2.10.4).  If --- INVALID FIELD IN CDB."

128) In many instances the expression "may not" gives false 
impressions. I suspect most places should be replaced with "might 
not". At any rate, change the implementor's note in Section 
7.2.10 on page 7-34 to "--- Targets might not support ---" or if 
you prefer to "--- Some targets may not support ---".

129) In section 7.2.10.1 it was not necessary to append the 
phrase "that has been received" to clause (1). Delete the phrase 
from clause (2).

130) I recall that we agreed to change "not changeable" to 
"target defined". Consequently in Section 7.2.10.2 change the 
last paragraph on page 7-34 to "--- All bits of parameters that 
are target defined (not changeable by the initiator) shall be set 
to zero."

131) I think 7.2.10.4 should be expanded to say "--- The page 
requested shall be returned with the parameters set to their 
saved and target defined values.  ---".

     Depending upon how this is handled it may be necessary to 
define savable values as both the initiator defined and target 
determined values or do a global addition most places saved 
values are mentioned.

132) Implementation requirements should be avoided. Therefore 
replace "Implementation Requirements" in Table 7-29 with "Type" 
which I believe was the term used in earlier portions of the 
document to identify mandatory and optional. 

133) Since implementors notes should be something that could be 
deleted without technically changing the document, it seems 
unnecessary to have two notes on one page that give the same 
information. On page 7-38 delete the second note but use its 
better wording in the first note yielding " IMPLEMENTORS NOTE: 
Modes 000b and 001b are included for compatibility with products 
that were designed prior to the generation of this standard.  
Some of these products that were designed prior to the generation 
of this standard restrict the available length to to 65535 
bytes."

134) The first sentence of the second paragraph in Section 
7.2.12.1 and the last sentence of the third paragraph are 
redundant. I suggest deleting the first occurrence.

135) Section 7.2.12.2 is not correct, I assume it should be 
changed to "In this mode, the meaning of the buffer ID, buffer 
offset, and allocation length fields are not specified by this 
standard."

136) Change Section 7.2.14 to "--- receipt of any subsequent 
command (including REQUEST SENSE) for the same I_T_x nexus."

137) I have always objected to the term "fatal error". It should 
be replaced in each instance on Page 7-43 and all other pages 
where it may occur with "unrecovered error(s)" or "crucial 
error(s)" or "vital error(s)".

138) Change the third paragraph on page 7-45 to "The intention of 
the hierarchy is to provide a top-down approach ---". 

139) In the last portion of the page replace "(Type" with 
"(Device Type" in approximately seven places.

140) Modify clause four to "--- write error, when unwritten data 
blocks, ---".

141) I think item (a) on page 7-46 should be "the number of data 
blocks, filemarks, and/or setmarks ---". 

142) The meaning of "An additional sense code value is mandatory 
if that condition is reportable by the device." is not at all 
clear. Does that mean it is mandatory to implement all sense 
codes that are implemented? Or does it mean it is mandatory for a 
given device type to be able to report any code listed for that 
type through the ingenuity of the committee? Or does it mean that 
the committee has just gotten carried away?

143) I think it is unnecessary to have a sentence four lines 
above a section to say the section is coming. Consequently I 
think the next to last paragraph in Section 7.12.14 should be 
deleted.

144) I think there are too many fields on page 7-47. Change the 
first paragraph to "The Field Pointer points to illegal 
parameters ---".

145) Based upon past agreements change the paragraph above Table 
7-37 to " --- These fields identify the actual number of retries 
of the recovery algorithm used in attempting to recover from the 
error condition." With this change or without it the redundant 
paragraph after Table 7-37 should be deleted.

146) Delete the un-necessary implementor's note after Table 7-38.

147) In Section 7.2.14.2 on page 7-49 consideration should be 
given to beginning a new paragraph with "If AEN is not supported 
---" in the third paragraph. In any case the first sentence of 
the fourth paragraph should be appended to what is now the third 
paragraph and a new paragraph started after that sentence.

148) The following conditions (1) and (2) appear to be 
contradictory. I suggest (2) be modified to "If a deferred error 
can be associated with a causing initiator and with a particular 
function or a particular subset of data and the error is either 
unrecoverable or required to be reported by MODE SELECT 
parameters, a deferred error indication shall be ---".

149) Should condition (5) state "has been posted" rather than 
"has been recovered"?

150) In Table 7-40, Sense Key Ch should be shortened to "EQUAL.  
Indicates a SEARCH DATA command was satisfied." 

151) In Table 7-41 the fact or alleged fact of a historical 
anomaly may have been important in the deliberations of the 
committee, why should it be flouted in the published standard?

     Along these lines shouldn't all the "should use" and "use" 
statements be purged?

152) From here on out, Table 7-41 would be more valuable if 
ordered by code rather than description. I suggest Table 7-41 and 
Appendix I be interchanged.

153) Regarding code 50 02 what is a Timer Position Error?
Incidentally why are so many caps wasted in Table 7-41 and 
withheld in the rest of the document?

154) Since no codes are blank, the last note should be shortened 
to " All codes not shown are Reserved".

155) Modify the first paragraph of 7.2.15 to "tests on itself, on 
the LUNs, or on both. ---". 

156) In the sixth paragraph of page 7-58, is "cache replacement" 
a well understood term? Does it refer to chip removal and 
replacement?

157) In the last paragraph should "alternate interfaces" be 
replaced with "other" interfaces since I think some referred to 
are not alternates for SCSI?

158) It seems highly incestuous to have implementor's notes cited 
by other sections such as in Section 7.2.15 on page 7-59.

159) Other sections of SCSI-2 indicate the Read Buffer and Write 
Buffer are diagnostic commands. Therefore change Section 7.2.17 
to "--- This diagnostic command shall not alter any medium ---".

160) I see little reason to have any implementor's note and no 
reason to have them repeated. Delete the additional appearance of 
the note on page 7-61.

161) The forward references in Section 7.3.2 and 7.3.3 are 
correct but incomplete. Change them to "8.3.2, 9.3.2,".

162) On page 7-66 change the DU description to "--- block) nor 
for list parameters (indicated by the LP bit).  The target shall 
ignore the value of any DU bits in a LOG SELECT command."

163) I think a more explicit description is required of the 
difference between the DS bit on page 7-66 and the TSD bit on 
page 7-67.

164) The description of the ET bit is puzzling, it implies tri-
state. Since the ET bit is binary, it always has a value of one 
or zero. What is the meaning of "Thus when the ET bit is set to a 
value by the initiator, this value is returned for both the 
cumulative and threshold values of the log parameter."?

165) In Table 7-52 was it intended to cover, equal, not equal, 
and greater or was it intended to cover equal, less than, and 
greater?

166) On page 7-69, Table 7-53 would be more useful in code order.

167) Why split the Reserved Log Page Codes on both sides of the 
Vendor Specific (hyphen omitted in Table 7-54 but I'm not a 
hyphen fan so I will not comment)? I suggest 3Fh be Vendor 
Specific.

168) In Table 7-57 on page 7-71, what does "Errors corrected by 
other means" mean? Or maybe the question is what is "on-the-fly"? 
Does it mean fairly fast or without missing one-to-one interleave 
and no perceived processing time?

169) In the first paragraph on page 7-75  singularize "The device 
specific parameter ---" 

170) The last sentence of the third paragraph is redundant to the 
last phrase of the first paragraph under Table 7-64. Delete it.

171) Add a "d" to the first paragraph of page 7-77 to produce "--
- provided no field is truncated and the page length field ---".

172) Change Table 7-65 to code order. 

173) On page 7-79, Section 7.3.3.1, change the third paragraph to 
"--- A unit attention condition shall be generated for each 
initiator which had commands in the queue except the initiator 
that received the original Initiate Recovery message. When ---".

174) In case there is no lower value, would it be acceptable to 
delete "down" from "round down" in the buffer full and buffer 
empty paragraphs on page 7-81?

175) What is the difference between 01b and 11b in Table 7-69? 
Does 01b mean that data transfer is completed but and ending 
status is not given until a subsequent reconnect? Or does it mean 
that a disconnect will occur,providing it is not the last block,  
on a logical block boundary?

176) On page 7-83,in Table 7-71 shouldn't SCSI-1 be allowed? What 
about IPI-3 and IPI COM?

177) Since the features are optional, modify Section 7.3.4 to 
"that are potentially applicable to all SCSI devices. ---".

178) Change Table 7-73 to code order.

179) The last paragraph of page 7-84 is redundant to the last 
sentence of the first paragraph. Delete it.

180) The fourth paragraph should be modified to "allocation 
length is less than the length of data to be returned, ---".

181) Why was a new length designation invented on page 7-85. 
Change Byte 4 of Table 7-74 to "ASCII Information Length (m-4)",
byte "m+4" to byte "m", and byte "m+5" to byte "m+1".

182) Concerning the requirements in the first paragraph of page 
7-86, is their any special impact of the truncation caused by 
certain allocation lengths which cause the last line of graphic 
codes to be short and end without a "null" character?

     An analogous version of this comment applies to the last 
paragraph of Section 7.3.4.5.

183) A volatile direct access device is a degenerate form. I 
suggest that the second paragraph of Section eight be changed to 
"--- The physical medium is typically non-volatile (see glossary) 
although in some cases volatile medium is used which usually 
provides quicker access time at the expense of special provisions 
for power interruptions.  The physical medium has portions ---".

184)  Modify Section 8.1.2 to "--- the block length of a 
particular logical block is often the same as all other logical 
blocks but each logical block may have a different length as 
determined by the Mode Parameter Block Descriptors (see 7.3.3). 
As a practical matter, the following types of DADs may be seen by 
initiators:"

185) Modify Section 8.1.4 to "Many DADs must be initialized once 
by direct --- will not normally a require FORMAT command.  Some 
MODE SELECT parameters may need to be initialized after each 
power-on, ---".

186) Modify the last sentence in Section 8.1.5 to "This operation 
can be repeated at a later time if a defect appears in the 
logical block."

187) In section 8.1.7 remove an "a" producing "In general, the 
initiator uses reservations to gain a mode of access to extents -
--".

     Also remove the less than helpful phrase "by whatever 
mechanism that occurs."

     Modify the fourth paragraph to "--- conflict will occur."

188) The sixth paragraph on page 8-6 is jumbled. I understand 
that a reservation conflict occurred if access of extents are 
affected. I don't follow what log select has to do with this. The 
paragraph needs help but I have lost what was intended.

189) I don't follow why a diagnostic command in paragraph seven 
would adversely affect the manner of access to an extent. Are we 
not talking about manner but time?

190) Delete the inflammatory first paragraph in section 8.1.8 or 
delete the Rezero Unit command. If the command is not deleted add 
Unit to the section title.

191) The Notches section has the justification backwards. Change 
section 8.1.9 to "since different portions of the physical medium 
may be able to contain different numbers of sectors per track by 
using approximately constant data densities. The notch control --
-".

192) Relative addressing is used by Section 8.2.6 but not 
explained. Delete the forward reference in 8.1.10 unless there is 
some place better than 8.1.10 where it is explained.

193) The last sentence of Section 8.1.10 appears to be in 
conflict with the ninth paragraph of page 8-6.

194) In my opinion Section 8.1.11 Error Reporting should not be a 
part of the model. It should be a part of the requirements.

195) Beginning with page 8-8 the term MEDIUM ERROR for 
unrecoverable read error. This is of course a conclusion which 
often would be correct. On the other hand it would also be true 
that RECOVERED ERRORs are often medium errors. The cause of an 
unrecoverable read error might also be a hardware error such as a 
defective read filter. I suggest that MEDIUM ERROR be globally 
replaced with DATA ERROR or UNRECOVERED ERROR.

196) Since BLANK CHECK is not applicable to Section 8 delete it 
from page 8-8. It is specified in the Error Reporting section of 
Section 15.

197) The last entry in the condition table should be expanded to 
"Logical unit or block is reserved to another initiator."

198) The fourth paragraph on page 8-9 should at least be modified 
to be compliant with comments 183 and 185. But why is this 
paragraph included. The material is just a re-hash of earlier 
parts of the model.

199) I presume Section 8.1.12.3 is the principal reason the 
feared word "volatile" was included in the model. Consequently 
change the last sentence to "Memory devices typically store less 
data than disks or tapes, and are usually volatile when not 
protected by power backup." If not, delete volatile from the 
model.

200) Modify the note at the bottom of Table 8-2 to "--- All 
remaining operation codes are reserved for other device types or 
for future standardization."

201) Modify the Dlist paragraph on page 8-14 to "--- supplied to 
the target by ---".

202) Is the third sentence of the Glist requirement "The Glist 
shall include Dlists provided to the target during the previous 
and the current FORMAT UNIT commands.", the third sentence of 
the fourth paragraph "The result is to purge any previous Glist 
and to build a new Glist.", and the last sentence "The 
combination of the Dlist and the Clist (if certification is 
performed) creates the new Glist."  in conflict? If so change the 
first paragraph to "--- The Glist shall include Dlists provided 
to the target during the previous, providing the CmpLst bit is 
zero, and the current FORMAT UNIT commands." 

203) The terminology in the Glist second and fourth paragraphs 
and the first paragraph after Table 8-4 "the defect list header" 
and Table 8-4 "Defect Descriptors" are inconsistent. In addition 
the second paragraph points out the need for caps which would 
improve to "Defect List Format field".

204) Modify the fourth paragraph to "--- may add to the Dlist as 
---".

205) I don't know if I want something added, but I thought there 
was going to be some description of how the Format command was to 
be processed in products which have a buffer too small to handle 
all the defect descriptors (or should that be too many defects to 
be buffered). (We do not have a problem so this is just a 
reminder not a request.)

206) For consistency the VU bit in Table 8-4 should be changed to 
"VS".

207) It is not clear what "above" refers to in the first 
paragraph after Table 8-5. If I have guessed correctly, change 
the paragraph to "All options in Table 8-5 shall include the 
creation of a new Glist during the execution of the FORMAT UNIT 
command." Please note that this also applies to vendor specific 
options.

208) Change the references in item (3) of the Immed bit portion 
of page 8-19 to "7.2.14.1" and "7.2.14.2".

209) It may be ok to have the IP bit description out of sequence. 
However the VS bit should be described after (3).

210) Modify the implementor's note on page 8-19 to "--- This 
option typically only initializes the initiator accessible area 
of the media to the specified pattern and typically does not 
write to any initiator inaccessible areas of the disk."

211) I presume the "may" in the last paragraph on page 8-20 and 
the last paragraph of Section 8.2.1.1 are obtuse indications that 
IP bit support in a target is optional. While it appears to be a 
large documentation task, and perhaps a trigger for debate, I 
think a method of defining which items are optional and which are 
mandatory should be added. Commands as a whole are clear. However 
it is not clear with an implemented optional command, what is 
mandatory.

212) Change the first paragraph after Table 8-8 to "--- The 
defect descriptors shall be in ascending order." 

213) Change the first paragraph after Table 8-9 to "--- Each defect 
descriptor is comprised of the cylinder number of the defect, the 
head number of the defect, and the number of bytes from index to 
the defect.  The defect descriptors shall be in ascending order.  
---". 

214)  Change the first paragraph after Table 8-10 to "Each defect 
descriptor for the physical sector format specifies a sector- 
size defect location comprised of the cylinder number of the 
defect, the head number of the defect, and the defect's sector 
number.  The defect descriptors shall be in ascending order.  For 
determining ascending order, the cylinder number of defect is 
considered the most significant part of the address and the 
defect's sector number is considered the least significant part 
of the address.  More than one block may be relocated by each 
defect descriptor."

215) In section 8.2.4 and some others what is the meaning of 
"Peripheral Device Type:  Direct-Access, Write-Once, CD-ROM, 
Optical-Memory Sequential Access, Medium Changer"?

     Does it mean that commands which do not list Write-Once, CD-
ROM, Optical-Memory Sequential Access, Medium Changer are not 
allowed to be used by these devices? Or does it mean that these 
are especially nice commands for these devices? Or is it refuting 
indications in the model that these devices are direct access 
devices?

216) The first paragraph of 8.2.4 is in conflict with the first 
paragraph of 8-40. It seems to me the Reservation should prevail 
over the Allow Medium Removal and that there may be reason for 
the Prevent Medium Removal to prevail over a Reservation. However 
I am not 100% sure of the latter and will not suggest a change to 
allow it. Consequently change the first paragraph of Section 
8.2.4 to "--- in the logical unit. If the target allows Prevent 
Medium Removal on a separate basis for each initiator, this 
mechanism shall not allow medium removal if any other initiator 
currently has medium removal prevented."

217) The third paragraph is redundant to the first paragraph and 
should be deleted.

218) The fourth paragraph should be modified to "Targets that 
contain write cache memory shall implicitly ---".

219) Modify (or delete) the implementor's note on page 8-28 to 
"The DPO bit may be used to control replacement of logical blocks 
in the cache when the host has information on the future usage of 
the logical blocks.  If the the DPO bit is set to one, the host 
assumes the logical blocks accessed by the command are ---".


220) Change the first full paragraph on page 8-29 to "An FUA --- 
If during a subsequent cached write an error occurs, the deferred 
error is not reported until a subsequent command (e.g., 
SYNCHRONIZE CACHE command) unless AEN is used."

     But, why are the requirements of the write operation 
specified in the read section? Shouldn't the write requirements 
be moved to the write section?

221) The reference in the last paragraph of Section 8.2.6 is of 
no value. Logical Block Address is self explanatory or could be 
explained in less space than the reference and the reference does 
not contain a list of exception conditions. Delete it.

222) Modify the second paragraph of Section 8.2.7 to "--- The 
logical block address in the command descriptor block shall be 
set to zero for this option. ---".

223) Since it is not clear which function is referred to, modify 
(or delete) the implementor's note on page 8-30 to "The PMI bit 
is intended to assist storage management software ---".

224) Relative to the paragraph, two above Table 8-19, if the 
defect list formats do not match, why wasn't the additional sense 
code Invalid Field In Parameter List rather than Defect List Not 
Found?

225) In two places on page 8-32 the cited references are a near 
miss. Shorten both references to "8.2.1". (The subject was 
appropriate but the subsection didn't have the information 
referred to.) 

226) The fifth paragraph on page 8-33 is redundant to the second 
paragraph. Delete the fifth paragraph.

227) Modify (or delete) the implementor's note on page 8-34 and 
on page 8-56 to "--- (e.g., a data synchronization mark within 
the ECC area). ---".

228) Modify the last paragraph of Section 8.2.9 and of 8.2.23 to 
"--- A byte transfer length of zero indicates that no bytes shall 
be transferred. This shall not be considered an error."

229) The last paragraph on page 8-36 seems misleading to me. I 
don't think an unrecoverable error in a block not specified by 
the defect list should cause the Reassign Blocks command to fail. 
After all some systems may prefer to reassign defective blocks 
one at a time. In this case I presume the target should ignore 
other blocks in the vicinity with errors. Therefore I think that 
paragraph should be deleted.

230) Why shouldn't the implementor's note at the top of page 8-37 
be part of the requirement? 

231) Modify the first paragraph in Section 8.12.1 on page 8-39 to 
"--- or by a power off/on cycle.---" Incidentally this change 
should be global where changes are indicated due to power on. 
They really begin the change at power off.

232) Modify the first paragraph after Table 8-25 on page 8-41 to 
"The size of the extent list shall be defined by the extent list 
length bytes. The extent ---". 

233) Should the descriptions on page 8-41 mention the verify 
commands or should they be left as implied by read and write? 
Does a Read Exclusive reservation allow Verify from another 
initiator?

234) Regarding Section 8.12.3, what is the underlying reason a 
reservation for third party SCSI Device 3 made by SCSI Device 2, 
can not be released by SCSI Device 3?

235) One backward reference to the same thing is sufficient in a 
given section delete the second "(see 6.2.7)" on page 8-45.

236) Correct the next to last paragraph on page 8-46 to "--- If 
the value of the first record offset field is larger than ---".

237) It seems highly unnecessary for a subsection to refer to the 
main section. Why not delete "(See 8.2.14.)" in Section 8.2.14.2 
and 8.2.14.3?

238) Modify the last paragraph of Section 8.2.17 on page 8-50 to 
"Targets that contain write cache memory shall implicitly ---".

239) Modify the first paragraph on page 8-52 to "After attempting 
to write all of the specified logical blocks, if any non-
recovered errors have occurred that have not been previously 
reported (possibly due to a deferred write caching error), then 
the most recent non-recovered error shall be reported.  If all 
errors were recovered, then the most recent recovered error (if 
any) shall be reported."

     On the other hand, I have presumed that deferred errors, at 
least unrecovered deferred errors, are reported on the subsequent 
command without or before executing the subsequent command. If 
this is true, the the whole phrase about errors which have not 
been previously reported should be deleted.

240) The hyphen at the end of the line in Section 8.2.19 reminds 
me, why is vendor specific the only field title which is 
hyphenated? If they need to be why not vendor_specific (not 
mentioning the preferred Vendor_Specific)?

241) On page 8-55 and 8-56, the definition of Logical Block 
Address would take no more lines than the reference.

242) Since the implementor's note on page 8-55 is correct that 
the requirement is specifically stated even if the note 
misquoted, why not delete the note? If the note is left, perhaps 
the discussion of standard implications should be increased to 
add "or by a Read command."

243) The implementor's note on page 8-57 states that the Write 
same command is used for a purpose the committee has repeatedly 
rejected. Delete the unneeded and wrong note.

244) Modify the fourth paragraph of Section 8.2.24 to "using the 
physical sector format (equivalent to Table 8-10).

245) Modify the first paragraph after Table 8-41 on page 8-59 to 
"The supplied format field specifies the format of the address to 
translate field. This field is equivalent to the Defect List 
Format field of the FORMAT UNIT command. Valid ---". and the 
second paragraph to "The translate format field specifies which 
format the initiator would like the address to be translated to.  
This field is also equivalent to the Defect List Format field of 
the FORMAT UNIT command. Valid values for this field are defined 
in Table 8-5.  If the target does ---".

246) Modify the first paragraph on page 8-61 "--- An ALTTRK bit 
of zero indicates that no part of the translated address is 
located on an alternate track of the medium or the target cannot 
determine if all or part of the translated address is located on 
an alternate track.

247) On page 8-61, by what divine power does a target translate a 
logical block address or a sector address containing a defect to 
a eight byte region?

248) Since the appendices are not applicable change note 1 to 
Table 8-44 to "(1) See Appendix D for additional standards 
information.

249) Modify the first paragraph after Table 8-46 to "For direct-
access devices, if the Notch page (Table 8-53) is not supported, 
or if the active notch field in the notch parameter page is zero, 
then each page descriptor specifies parameters --- If disk 
notches and the Notch page are supported, and the active notch --
-".

250) To avoid wholesale confusion, change the name of the MS bit 
to "Multiply Selection" or even better change the bit to Multiply 
Factor (MF) or Multiplication Factor.

251) It is difficult to imagine any write cache data that has not 
been transferred from the initiator to the target. Modify the 
paragraph before {table 8-48 to "--- that has also been 
transferred from the cache to the medium."

252) Change 0h in Table 8-48 to "indicates that the priority 
is vendor specific" and delete the implementor's note which has 
disrupted the table. Also move Fh to the last entry in the table.

253) Regarding the reserved codes in Table 8-48, why not allow 
them for intermediate priorities or vendor specific?

254) Should the first implementor's note on page 8-67 be part of 
the requirement?

255) In the next paragraph, depending upon comment (250), change 
the bit acronym to "MS".

256) Delete the last implementor's note on page 8-67. If it is 
not deleted, it is mandatory to delete the last phrase since a 
randomly sampled opinion has no place in a standard.

257) In Table 8-49 and on page 8-70 why is the terminology 
"sector" used rather than "logical block"?

258) Why do Tables 8-49 and 8-50 have different titles when they 
are the same Page?

259) Change the implementor's note to part of the requirement 
following Table 8-50 and 8-60 and modify it to "--- disk drives, 
but may be used for other devices, if it is useful."

260) Change the first paragraph on page 8-70 and the third 
paragraph on page 8-89 to "--- Heads used exclusively for servo 
information are excluded."

261) Should the fifth and sixth paragraphs on page 8-70 and the 
fourth and fifth on page 8-89 be modified to the equivalent of "-
-- is equal to or greater than the value in the number of 
cylinders field, ---"?

262) The fourth paragraph of page 8-71 sounds like the MO bit is 
defined backwards. Should it be changed to Motor On Not (MON) or 
Motor On Pin (MOP)?

263) Correct the sixth paragraph to "The write compensation value 
field is used to specify the amount of write ---".

     Since the value is vendor-specific, the last sentence should 
be deleted.

264) Modify the last paragraph of page 8-71 and the first two 
paragraphs of page 8-72 to "--- interface.  The use of this pin 
varies among vendors and drives.  The following table allows the 
initiator to select how pin ---".

265) Correct the last paragraph on page 8-72 to "(e.g., 2400 
rpm).  This field ---".

266) The implementor's note on page 8-75 should be made a part of 
the requirement.

267) Modify the last paragraph on page 8-75 to "--- shall create 
a CHECK CONDITION status ---". 

268) Modify the next to last paragraph on page 8-76 to "--- 
progressive addresses to all logical blocks within --- 
progressive addresses to all logical blocks on a surface ---".

269) Modify the opening paragraph of Section 8.3.3.4 to "The 
medium types supported page (Table 8-52) contains a list of the 
medium types supported by the target as logical units."

270) I haven't found where the medium types are defined. Perhaps 
when I find it I will know why it is limited to four. It is clear 
that the present references on page 8-77 do not provide the 
information.

271) In Section 8.3.3.4, why is the awkward title "Notch and 
Partition Page" used. Why not just Notch Parameters Page"?

     Modify the first paragraph to " The notch page (Table 8-53) 
contains parameters for direct-access devices which implement a 
variable number of blocks per cylinder and support the Notch 
parameters page." The parameters are not necessarily needed for 
embedded notched drives and the X3T9.2 committee turned down 
their use for leading implementations of notched drives.

272) On page 8-78 it sounds like the PLN bit is defined 
backwards. For the definition it should be Logical or Physical 
Notch (LPN).

273) The fourth paragraph of page 8-79 needs to be changed to 
account for defect reassignments. Perhaps it should be changed to 
"If the PLN bit is one," (using the backwards semantics) 
"excluding the impact of logical block deallocation, each notch 
shall span ---".

274) No matter how liberal we may wish to be, Table 8-54 should 
not give unfair advantage to a cadre of individuals by reserving 
a field for a working group.

275) Should Verify be addressed in the first paragraph on page 8-
80?

276) Modify the EER definition in Table 8-55 to "--- expedient 
form of error recovery first.  This bit ---".

277) Modify the EER zero definition in Table 8-55 to "--- 
detection or mis-correction first."

278) Regarding DTE equals one, how do you terminate upon 
detection of a recovered error before you know if it recovers? 
Did it intend to say terminate after the error is recovered?

279) Modify all zeros in Table 8-56 to "command for recovered 
errors (PER set to 0).  The command --- ".

280) I do not understand why 0010 is invalid. I do understand why 
it is not the way I would recommend.

281) I also do not understand why 0011 is invalid. I do 
understand why it is not the way I would recommend.

282) For PER set to one it is not necessary to include "(PER set 
to 1)". This applies several times.

283) The wording near the end of 0110 is better than in the other 
equivalent definitions.

284) I generally agree with the definition for 1001 but I thought 
the obtuse wording of "most expedient" for EER was to allow this. 
Therefore I do not see why it is invalid.

285) I have a similar problem with 1010, 1011, 1101, and 1111 
although it may be cleared up by the answer to (278).

286) Modify the third paragraph after Table 8-59 to and the first 
paragraph on page 8-92 to "--- data error burst for which ---".

287) Make the next implementor's note a part of the requirement.

288) I think the the recovery time limit field on page 8-87 
should be expanded to "--- individual logical block. A value of 
zero specifies that the target shall use its default values."

289) The various pages are inconsistent in the use of "Parameter 
Length" and "Page Length". 

290) Modify the sixth paragraph on page 8-89 to "The drive step 
rate field indicates the step rate in 100 nanoseconds increments. 
The target shall use a step rate, slower than or equal to the 
step rate in bytes 12 and 13. If the target rounds ---".

291) Modify the seventh paragraph to "--- shall park the disk 
heads assuming the target is able to achieve variable locations.  
A negative --- location specified. A zero indicates that the 
default location should be used."

292) It seems to me that 00b in Table 8-61 should be allowed for 
mode select. In addition add a paragraph that states the values 
in Table 8-61 shall apply for all initiators regardless of which 
initiator set the values.

293) Modify the second paragraph on page 8-90 to "If a target, 
designated as a slave fails to achieve synchronization ---".

294) On page 8-90 add a paragraph after items (1) and (2) which 
states that a loss of synchronization report is generated only 
one time for applicable initiators for any one occurrence of loss 
of synchronization. Subsequent operations will go on without 
error indications except for potential loss of performance.

295) Modify the last paragraph on page 8-90 to " --- (e.g., 3600 
rpm)."

296) Depending on the response to comment (288), I think the 
implementor's note on page 8-92 should be made part of the 
requirement and modified to "To disable all types of correction 
and retries the initiator should set the EER bit to zero, the 
PER, DTE and DCR bits to one and the number of retries to zero."

297) The glossary definition for Cache is a degenerate 
definition. Webster is adequate and the term as used in SCSI is 
well understood in the industry. Delete it.

298) If data cache should remain modify it slightly to "not 
directly accessible".

299) Several terms are defined in the glossary and not used in 
the section. I think this applies to LBA Space, Read Hit, 
Subrange, and User Data. If I am correct, delete them. Move what 
is left to the front of Section eight. The analogous comment 
applies to many of the glossaries.

300) Modify the first paragraph in Section 9 to "Sequential-
access devices (called devices below) are optimized for storing 
or retrieving user data in a sequential manner.  Position changes 
typically take a long time, when compared to direct-access 
devices."

     The reason for the latter change is that the statement was 
wrong. Direct-access devices are even faster when used for 
sequential operations. The reason for the relative slowness is 
the greater masses involved and the difficulty of maintaining 
contact recording, without wearing out the media and heads, at 
higher speeds along with the difficulty of starting and stopping 
the media when very high slew rates are employed. Another 
alternative change would be to delete the last sentence.

301) I am inclined to question the sentence in the fourth 
paragraph "Volumes have an attribute of being mounted or 
demounted on a suitable transport mechanism." Since it is in the 
tape section perhaps it is ok that this conflicts with fixed disk 
volumes. Incidentally the prior sentence makes me wonder if a 
recorded volume must have data recorded on the physical carrier.

     Since I commented too much on this I will offer two 
alternatives. One solution is to modify the third paragraph to 
"The recording medium for tape devices consists of various widths 
and lengths of a flexible substrate coated with a semi-permanent 
magnetic material which are called volumes.  The recording ---" 
and delete the fourth paragraph. Another alternative is to leave 
the third alone and modify the fourth paragraph to "A complete 
medium unit comprises the recording medium and its physical 
carrier (e.g., reel, cartridge, cassette). The accessible portion 
of the medium unit is called a volume. The state of a volume is 
mounted on an appropriate transport mechanism or demounted."

302) Modify the first paragraph after Figure 9-2 to "--- reading 
follows the same or opposite course of tracks as writing."

303) Data Buffering in Section 9 is quite different than the 
buffer of section 7. I think the use of this term in such 
esoteric ways will cause problems for the system integrator who 
is not versed in tape lore and just wants to integrate a back up 
tape. I am not going to offer a solution because I am not sure in 
which instances the phrase buffer has been used for speed 
matching and where it is used for caching. A further consequence 
of this confusion is that some of my following suggestions may be 
off the mark due to not understanding which was being described.

304) It appears that in Section 9.1.5 the last sentence of the 
first paragraph and of the second paragraph are in conflict. I 
suggest deleting the last sentence of the second paragraph.

305) I thought SCSI devices were required to be buffered. 
Consequently I suggest changing the second paragraph to "A device 
may be capable of operating in either a cached or uncached mode.  
A device with no caching operates only in uncached mode.  Either 
term is only applicable to the manner in which the device manages 
information to be written to the medium. Cached mode is not 
applicable during read commands (although read-ahead buffering is 
applicable)."

306) Modify the third paragraph to "Depending upon the immediate 
bit, A device operating in cached mode --- in uncached mode, GOOD 
---".

     This change should be followed by a global in Section 9 to 
determine any other buffered or unbuffered usage which should 
change. For example the buffer phrase in the first paragraph on 
page 9-8 is ok.

307) Modify the last paragraph on page 9-8 to "--- physical block 
identifier are not the same. ---".

308) Similarly modify the second paragraph of Section 9.1.7 to " 
--- direction has an alternating relationship to the physical 
motion of the medium."

309) With first usage modify the fourth paragraph to "--- at 
BOPx, at end-of-data (EOD), at EOPx, or at EOM, since ---".

310) Separate Section 9.1.8 from the model. Also in this section, 
I believe the concern over tape reliability is excessive. I think 
the potential for a recovered error should be added to the 
Condition table to offset all the unrecovered errors.

311) Modify the first paragraph on page 9-14 to "--- command.  
Any cached erases ---".

312) Modify the first paragraph of Section 9.2.2 to "Prior to 
performing the unload operation, the target shall ensure that all 
cached data, ---".

313) Modify the second paragraph to "as soon as all cached 
commands ---".

314) Modify the implementor's note to "--- that all cached data, 
filemarks, or setmarks have been transferred to the medium prior 
to issuing a UNLOAD command with an Immed bit of one."

315) Modify the last paragraph on page 9-15 to "When operating in 
cached mode 1h or 2h (see 9.3.3), the target shall discard any 
unwritten buffered data after the UNLOAD command is ---".

316) Change the references in Section 9.2.4 on page 9-17 to 
"(9.2.5)" and "(7.3.3)".  

317) I think the second sentence in the second paragraph on page 
9-18 should be changed to "If the SILI bit is zero the target 
shall report ---".

318) Consideration should be given to making the implementor's 
note on page 9-18 part of the requirement. In any case modify it 
to "--- (e.g., including length information in the data block)."

319) In the last paragraph on page 9-18, for variable length 
blocks, why is the residue set to the requested length rather 
than the transferred length? This comment also applies to the 
first and fourth paragraphs on page 9-19, the first paragraph of 
page 9-24, the fifth and sixth paragraphs on page 9-25, and the 
first item (2) on page 9-36.

320) Modify the second paragraph on page 9-19 to "--- REW bit is 
zero or if the REW option is not supported.

321) Regarding the implementor's note, with such risk, why is the 
REW bit included in the standard? If left in, modify the note to 
"--- Setting the REW bit to one is not recommended ---". This 
comment also applies to page 9-31.

322) Modify the first paragraph in page 9.2.5 to "--- requests 
that the target's block length limits capability with the logical 
unit be returned."

323) I am confused by the second paragraph of page 9-23. I would 
think the next block to be transferred between the buffer and the 
medium would be dependent upon what the next command is. Probably 
there is some missing caching language involved here. Or maybe I 
need a tape primer more extensive than the model.

324) In Section 9.2.8 the last sentence on page 9-24 and the last 
sentence in the third paragraph appear to be contradictory. The 
wrong one should be changed.

325) On page 9-26 it is an excessive peek of egotism to have the 
subsection refer to itself. If the reference is necessary make it 
"(see 9.2.10.1)".

326) Why has the special provision been included to allow third-
party reserve/release machinations for performing copy without a 
reservation?

327) Modify the last paragraph on page 9-27 to " condition, or by 
a power off-on cycle.  ---".

328) Modify the second paragraph of 9.2.10.1 to "--- If the 
3rdPty bit is one the target shall reserve ---".

329) Is the expected impact of the implementor's note on page 9-
29 that the new requirements of the Rewind command will be mute? 
If so why were they added?

330) Modify the first and second paragraphs on page 9-31 to "--- 
shall be set to one in the sense data.  ---". In addition the 
double period in the second paragraph should be reduced by one.

331) On page 9-32 is the "or more" in (1) and (3) contradictory 
to positioning after the Nth filemark (or setmark)?

332) Does REW need to be addressed on page 9-32, especially with 
regard to the sixth paragraph? This comment also applies to the 
first paragraph on page 9-38. 

333) The reference for variable block mode in items (2) and (3) 
on page 9-38 are indirect. Change them to "(9.2.5)". In addition 
in (3) modify it to "--- (the number of filemarks or ---".

334) In Table 9-20 move 00h to be the first item.

335) Modify Table 9-21 to "

==============================================================================
  Bit|   7    |   6    |   5    |   4    |   3    |   2    |   1    |   0    |
Byte |        |        |        |        |        |        |        |        |
==============================================================================
 2   |   WP   |      Buffered Mode       |               Speed               |
==============================================================================
"

336) Modify 2h to "--- and (2) All cached data from other 
initiators --- "

337) Delete "or only" from items (1), (2a), and (2b) on page 9-41.

338)  Modify (4a) to "--- if a previous MODE SELECT command has 
not established a density code value for the currently mounted 
volume."

339) In Table 9-22 are the standards for 04h and 05h the same 
one? If so the 04h standard should be modified to "X3.136-1986".

340) Does the note 6 on 13h indicate that the X3B5/88-185A 
document is just an informational paper and not a dpANS?

341) Change note (4) to "See Appendix D for additional standards 
information."

342) Order Table 9-23 by Page Code.

343) Regarding the first paragraph on page 9-45, since Active 
Format Field codes are not shown, why isn't the value vendor 
specific even if the default density is not selected? 

344) Modify the ninth paragraph to "--- repositioning.  An AVC 
bit of zero indicates the speed chosen should be the device's 
default speed." Or should "default" be replaced with "current"?

345) Should the last paragraph be changed to "--- If the RSmk bit 
is one, the target shall interpret this field as stop on 
consecutive setmarks regardless of the SOCF value? Regardless, 
modify the start of the paragraph to "The stop on consecutive 
filemarks field (SOCF) of ---".

346) Modify the third paragraph on page 9-47 to "The select data 
compression algorithm field set to 00h indicates that the target 
shall not use a compression algorithm on any data sent to it 
prior to writing the data to the medium.  ---".

347) Isn't it confusing to have Table 9-25 showing redundant byte 
numbering? Would it be clearer if the the second 0 was n-1 and 
the second 1 was n?

348) Delete the last implementor's note on page 9-48.

349) Add "Space" to the glossary. Depending upon the outcome to 
my earlier comments, add "cached" and/or "buffered" to the 
glossary and change "volume". Move the glossary to the front of 
Section 9.

350) Excluding embedded SCSI printers is not appropriate. Change 
the first paragraph in Section 10 to "This command set includes 
capability for the printer-controlling device, which is an SCSI 
target, to be functionally separate from the physical printer 
device (see Figure 10-1) as well as integrated with it. ---".

351) X3T9 has previously disallowed using company names to 
identify requirements` Consequently throughout Section 10 change 
"Data Products interface" to "Line Printer interface" or "defacto 
Line Printer interface" and "Centronics printer interface" to 
"Character Printer interface" or "defacto Character Printer 
interface".

352) In addition to the prior changes, change the second 
paragraph to "--- because the options requiring controls utilize 
control codes embedded in the data stream."

353) I have no objection to ASCII (X3.4-1977). I offer this 
comment as a flag in case someone else does. The recommendation 
and editorial at the bottom of page  10-1 undoubtedly is not 
appropriate for the SCSI standard. I think this paragraph should 
be reduce to just the first sentence.

354) On page 10-7 modify the last paragraph to "--- not already 
printed to be printed and followed by any data transferred by a 
subsequent command, if any.  ---".

355) In many of the X.3.1 sections why is the Diagnostic Page 
Code table given even though the device type doesn't support 
anything except code 00h and vendor specific? It seems to me 
nearly all of these can be eliminated and just rely on 7.3.1.

356) Change Table 10-9, 10-11, and 11-6 to Page Code order. 
(Incidentally any similar table I did not make this comment on 
was probably an oversight.)

357) Change Table 10-10 to"

==============================================================================
  Bit|   7    |   6    |   5    |   4    |   3    |   2    |   1    |   0    |
Byte |        |        |        |        |        |        |        |        |
==============================================================================
     |Reserved|      Buffered Mode       |             Reserved              |
==============================================================================
"

358) What are bits 6 and 7 of Byte 3 in Table 10-13? What are the 
"+" marks for between Bytes 3&4 and 7&8 and between Bytes 3&4 in 
Table 10-14?

359) Is the EVFU bit defined for Mode Select?

360) On page 10-15 modify 1h, 2h, 3h, in the first table and 1h, 
and 2h of the second table to "The target shall insert an ---".

361) On page 10-16 modify codes 2h,3h,4h,5h, and 6h to "The 
target shall print any ---".

362) In the second paragraph on page 10-17 fill in the blanks 
with "6.5.4". 

363) Delete the last two sentences of the first paragraph on page 
11-2.

364) Change the reference in Section 11.2.2 to "6.5.5". However 
the second and last paragraphs on page 11-6 appear to be two 
different ways of specifying the same thing. I'm inclined to 
recommend deleting the former and retaining the latter.

365) Change Table 11-4 to "

==============================================================================
  Bit|   7    |   6    |   5    |   4    |   3    |   2    |   1    |   0    |
Byte |        |        |        |        |        |        |        |        |
==============================================================================
 0   |     Reserved    | LUNTAR |     Reserved    |        LUNTRN            |
-----|-----------------------------------------------------------------------|
 1   |                               Sub-logical Unit Number                 |
-----|-----------------------------------------------------------------------|
 2   |                               Reserved                                |
-----|-----------------------------------------------------------------------|
 3   |                               Reserved                                |
-----|-----------------------------------------------------------------------|
 4 to|                               Sense Data Byte (0)                     |
- - -|- -                                                                 - -|
 n+4 |                               Sense Data Byte (n)                     |
==============================================================================

366) Modify the first paragraph after Table 11-4 to "The 
identify, LUNTAR, and LUNTRN fields are defined in 5.6.7. The 
sub-logical unit fields are used to designate resources within 
the Logical Unit designated by LUNTRN."

367) Modify the data packet definition on page 11-8 to "--- A 
data packet often contains information ---".

368) Modify the resource definition to "A part of the device 
required to operate on or store the data packet."

369) Move the glossary to the front of Section 11.

370) Modify the third paragraph on page 12-1 to ""Updating" 
of blocks (see 15.1.1) is abnormal. ---" and the next paragraph 
to "Some devices may be able to determine ---".

371) The first sentence of Section 12.1.4 appears to be 
contradictory to Section 12.1.3.

372) As in other sections, the Error Reporting requirements 
should be separated from the model.

373) Although it is only a reference, move the glossary to the 
front of Section 12.

374) For the reasons stated previously, delete "Sony-Philips" 
from the second paragraph on page 13-1 and delete "The CD-ROM 
standards were developed by N.V. Philips & Sony Corporations." 
from the CD-ROM definition on page 13-47.

375) The last two paragraphs of Section 13.1 are too specific and 
probably should be deleted.

376) Modify the seventh full paragraph on page 13-3 to "--- track 
has an index value of one.  ---".

377) I think the first paragraph of Section 13.1.2 should be 
modified to "--- consists of 98 small frames."

378) Modify item (4) on page 13-6 to "The controller cannot 
select the drive."

379) Separate the Error Reporting requirements from the model.

380) For clarity reformat the error table in Section 13.1.7 to "
---

Attempt to read a blank or previously
unwritten block.                                  BLANK CHECK

Attempt to play a data block as audio.            BLANK CHECK

Overrun or other error that might
be resolved by repeating the command              ABORTED COMMAND

---"

381) Delete the empty Page column from Table 13-3 and 13-4. Also 
13-3 should have an indication that it is continued in 13-4 or 
the keys should be given.

382) The third paragraph on page 13-13 poses a dilemma. I can not 
tell if the Resume bit should instead be one or if the Check 
Condition should result from the description regardless of the 
state of the Resume bit.

383) The last sentence of the fourth paragraph on page 13-14 is 
redundant to the first sentence and should be deleted.

384) The implementor's note on page 13-15 should be made part of 
the requirement as should the ones on page 13-20 and 13-21.

385) Section 13.2.8 has conflicting requirements. The type is 
mandatory and the implementor's note says it is not required. 
Change one or the other.

386) Modify the last paragraph on page 13-22 to "--- shall be set 
to zero for this option."

387) Regarding the implementor's note at the top of page 13-23, 
why shouldn't the target return an address equal to the last 
readable block? The second implementor's note appears to be 
something that should be moved to the model.

388) The reference should be changed to "8.1.10".

389) On page 13-26 it is not clear if the note has established a 
sanctioned use for the reserved bits or it is just anticipating 
what they might be used for in the future? Is the information in 
the note correct and in correct form?

390) Is the first paragraph on page 13-28 appropriate for 
multiple initiators?

391) Modify the first implementor's note to "Usual values for 
Sub-channel ---".

392) On page 13-30 interchange the full name  and acronym usage 
for ISRC between the second and first paragraphs.

393) Order Table 13-25, 13-29, 14-22, 14-23, 15-23, 17-9, and 17-
10 by Page Code.

394)  Modify Table 13-27 to "

==============================================================================
  Bit|   7    |   6    |   5    |   4    |   3    |   2    |   1    |   0    |
Byte |        |        |        |        |        |        |        |        |
==============================================================================
     |   WP   |    Reserved     | Cache  |           Reserved       |  EBC   |
==============================================================================

395) I am uncertain where the reference was directed. Perhaps it 
should be changed to "(see 8.2.6)".

396) On page 13-37 it sounds as if the meaning of the Continue 
bit zero and one are reversed. Is additional definition required 
in paragraph two and/or three?

397) Delete the implementor's note on page 13-38.

398) If the note at the top of page 13-39 is correct, is the 
0h meant to break the device? Should infinite be set by a less 
likely value than 0h?

399) In Table 13-35, should the EER value be R and noted as 
reserved rather than X?

400) Add a comma to the last paragraph in Table 13-36 "--- media, 
data transfer ---".

401) Modify the bcd definition to "--- Numbers that use this 
notation ---".

402) Delete the hex definition on page 13-48 and move the 
glossary to the front of Section 13.

403) Delete the confessions in Sections 14.1 and 14.4 along with 
the deletion of the sections.

404) Change the Section references in Table 14-1 for Release unit 
to 9.2.9 and for Reserve Unit to 9.2.10.

405) What are the pluses for in Table 14-4 and 14-5?

406) I think the disclaimer on errors is normally used when a 
field of zeros causes the command to not go on, since the zero 
value is defined, I think the last sentence of the first 
and second paragraphs on page 14-6 should be deleted.

407) In the next to last paragraph, the use of a hex byte 
identifier is confusing. Change it to "--- byte twenty-five of 
the Window Descriptor." 

408) In Table 14-7, what is the difference between 00h and 03h?

409) The first paragraph on page 14-10 uses terminology that does 
not correlate with the reference. What is the "region descriptor 
block"?

410) Why can't Tables 14-13 and 14-14 be deleted and just refer 
to Tables 14-4 and 14-5?

411) Should Gamma Function used in Tables 14-17 and 14-20 be 
defined?

412) Modify the second paragraph of 14.3.3 to "The mode parameter 
list, including the mode parameter header and mode block 
descriptor is defined in 7.3.3."

413) In the fifth paragraph of page 15-1 change "discouraged" to 
"not recommended".

414) Modify the sixth paragraph to "--- previously written blocks 
to prevent a destructive overwrite. ---".

415) With an optimistic view, change Section 15.1.2 to "Medium 
defect rates, as of 1989, are typically higher --- ".

416) Separate the error reporting from the model.

417) The reference midway through Section 15.2.1 is obtuse. 
Change it to 8.1.10. make the same change on page 15-9.

418) On page 15-14 and 15-15 the phrase "maximum generation 
address" needs to be clarified. Having the glossary at the start 
of Section 15 would help but even with the generation definition 
maximum generation does not become obvious.

419) On page 15-16 change the second reference to "8.1.10".

420) Delete the implementor's note at the bottom of page 15-19 
and modify the prior paragraph to "This standard does not define 
the result, but recommends against the use of a WRITE command 
issued to a block previously updated by an UPDATE BLOCK command 
when blank checking is disabled."

421) Change the second reference on page 15-21, 15-23, and 15-26 
to "8.1.10".

422) Modify the Section reference in Table 15-22 to "8.3.1.1" for 
40h.

423) Modify Table 15-24 to "

==============================================================================
  Bit|   7    |   6    |   5    |   4    |   3    |   2    |   1    |   0    |
Byte |        |        |        |        |        |        |        |        |
==============================================================================
     |   WP   |    Reserved     | Cache  |           Reserved       |  EBC   |
==============================================================================
"

424) Change the last reference on page 15-28 to "8.2.6"

425) Make the implementor's note on page 16-1 part of the text.

426) Change the first reference on page 16-2 to "16.3.3.3".

427) Modify the last paragraph on page 16-3 to "--- LOAD/UNLOAD 
commands ---".

428) The Volume Tag sections should be part of the requirement 
and not part of the model.

429) Add a reference to the third paragraph of Section 16.2.5.1 
"(see 16.2.5.2)" unless next section references will be deleted.

430) On page 16-15 the Element Descriptor length is not clear. 
What is z+1? Why isn't it just z?

431) In Table 16-11 "omit" is not sufficiently definitive. Does 
it mean the bytes are zeros or does it mean Reserved and Vendor 
Unique begins at a lower byte count? I think it should be zeros 
in the bytes.

432) For consistency the order of the paragraphs after the table 
should correlate to their position in the table.

433) Modify the fourth paragraph (before reordering) on page 16-
17 to "An exception (Except) bit of one indicates ---".

434) Modify the second paragraph on page 16-20 to "An 
import/export (Imp/Exp) bit of one indicates ---".

435) Modify the first reference on page 16-26 to "(16.2.8.1)" and 
the second to "(16.2.8.3)".

436) Modify the first reference on page 16-28 to "(16.2.7.2)".

437) In Section 16 "then" is used where it does not need to be. 
This is also true in some other sections.

438) On page 16-33 I am not sure what the meaning is of "If this 
field is not sent". Does it means the bytes may be missing or 
they will be filled with zeros? This helps my confusion over the 
minimum and maximum values of the Send Volume Parameters length 
field. If the max length is 28h, why was two bytes used?

439) The reference at the end of Section 16.3.3.3 appears to be 
correct but of no great value.

440) Move the glossary to the front of Section 16.

441) For the bilateral functions, why are different names chosen 
for the commands in the Processor and Communications sections?

442) Change the Section references in Table 17-1 to "

Command Name                       Code   Type    Section     Page
-------------------------------------------------------------------
CHANGE DEFINITION                  40h      O      7.2.1 
GET MESSAGE(6)                     08h      M     17.2.1           
GET MESSAGE(10)                    28h      O     17.2.2           
GET MESSAGE(12)                    A8h      O     17.2.3           
INQUIRY                            12h      M      7.2.5         
LOG SELECT                         4Ch      O      7.2.6  
LOG SENSE                          4Dh      O      7.2.7 
MODE SELECT(6)                     15h      O      7.2.8 
MODE SELECT(10)                    55h      O      7.2.9  
MODE SENSE(6)                      1Ah      O      7.2.10
MODE SENSE(10)                     5Ah      O      7.2.11
READ BUFFER                        3Ch      O      7.2.12
RECEIVE DIAGNOSTIC RESULTS         1Ch      O      7.2.13      
REQUEST SENSE                      03h      M      7.2.14      
SEND DIAGNOSTIC                    1Dh      M      7.2.15      
SEND MESSAGE(6)                    0Ah      M     17.2.4          
SEND MESSAGE(10)                   2Ah      O     17.2.5          
SEND MESSAGE(12)                   AAh      O     17.2.6          
TEST UNIT READY                    00h      M      7.2.16      
WRITE BUFFER                       3Bh      O      7.2.17
=================================================================
"

443) Move the glossary to the beginning of Section 17.

444) Delete the timing notes on page A-1 as they are redundant to 
the body of SCSI-2.

445) To avoid the implication of a requirement in the Appendix, 
change Arbitration Phase on page A-3 to "This phase is documented 
as mandatory in SCSI-2. In SCSI-1 ---".

446) I don't understand the Message Out phase statement as there 
are eighteen messages out.

447) Unless the HBA is supposed to have a perverse role, change 
the next to last paragraph on page C-2 to "--- expected to ensure 
that the target does not reach outside its allocated blocks."

448) Modify The second paragraph of D-1 to "--- However, these 
standards may be useful. Please ---".

449) Delete the editorial "This topic has been the subject of 
great debate in the past, and thus a clear and precise written 
explanation was deemed appropriate." in the first paragraph of 
page E-1.

450) Change "discussion" in Appendix E to "appendix".

451) Appendix E has the glossary where it should be.

452) Modify implicit ordered I/O process to "This is an I/O 
process that includes a MUNDANE QUEUE TAG message, but the target 
has determined it will treat it as an ordered I/O process for the 
purposes of queuing."

453) Modify the biggest paragraph on page E-2 to "This follows 
directly from the definitions in the above glossary ---".

454) Modify the first full paragraph on page F-1 to "This 
appendix describes the normal ---".

455) Change the title of F.1. to "System Initialization"

456) Modify the Start Device: first paragraph on page F-6 to "If 
the boot device supports START/STOP commands and is not already 
Ready or Busy, a START/STOP UNIT command should --- If system-
controlled power surge sequencing of the peripheral devices is 
required, it is done by managing the timing relationship of the 
START/STOP UNIT commands to different logical units or by vendor 
specific techniques such as sequencing by SCSI device address."

457) It may be that the first part of the change could be 
omitted with the consequences of the second paragraph.

458) Modify the seventh paragraph to "If any other error is 
detected, (Busy is not an error) the general ---".

459) Modify the first paragraph on page F-7 to "Determine 
Parameters:  If the ANSI-approved version field of the previously 
executed INQUIRY command was 0 or 1, the MODE SENSE information, 
if any, may be vendor unique and this function should be skipped 
after further interrogation unless required by the vendor-unique 
initialization protocols."

460) In association with the second paragraph on page F-8 add a 
note to the effect "
CAUTION: The use of a Format Command will destroy user data and 
can lead to significant recovery steps. The initiator should 
insure that safeguards are taken to avoid frivolous or mistaken 
Format operations!"

469) I think the Determine Format Parameters paragraph and the 
two Set Format Parameters paragraphs should be tied together 
and/or combined. At the same time the ANSI-approved versions 
paragraphs on page F-8 and F-9 should be tied together and/or 
combined.

470) The second paragraph of F.5 refers to the "recommended 10 
second wait time for devices to respond". Where is that 
recommendation documented?

471) On page G-1 it is not clear what the significance is of the 
two CONNECTOR words in the table.

472) On page G-2 the significance of the "*"s in the table is not 
explained. What is it?

473) Change the last paragraph on page G-2 to "Fast data transfer 
timing parameters were not tested for the single-ended 
transceiver option prior to publication of this standard."

474) Swap Table I-1 with the one in the body of the standard. 
However both need to have the references to a historical anomaly 
deleted throughout the table. Also modify the first paragraph to 
"--- of this standard, the definitions of Section 7.2.14.2 
apply."

475) Delete all the "should use" statements.

476) This comment intentionally left blank.

477) In Table I-2 change the definition of the "C" flag to "C = 
Change of opcode definition for different device types"




                              G.E. Milligan
                              Member, X3T9

Note: This is a revised copy of the original submission. It 
corrects finger faults that were present in comments 34, 110, 
144, 213, 214, 220, 235, 249, 260, 396, 405, 420, and 476.