X3T9.2/89-103 Rev 1 September 6, 1989 Thomas Wicklund Ciprico, Inc. 2955 Xenium Lane Plymouth, MN 55441 612-559-2034 612-559-8799 (FAX) The following are comments on the SCSI-2 R10 document. They are editorial in nature, point out inconsistencies between sections of the document, or point out possible upward compatibility issues. 1. Page 3-2, definition of I_T_L_Q nexus, it states that receipt of of a queue tag causes this nexus to replace an I_T_L nexus. On page 6-12 (section 6.5.2) it states that an incorrect inititator connection occurs when an initiator "(1) attempts to establish an I_T_L_Q nexus when an I_T_L nexus already exists." Since an I_T_L nexus exists after the IDENTIFY message, it follows that an I_T_L_Q nexus must replace an existing I_T_L nexus when the queue tag message arrives. The text in 6.5.2 needs to be modified so that normal IDENTIFY and queue tag message sequences are allowed. 2. Is there a reason why section 4.2.3 duplicates the conductor size requirements already specified in 4.2? I can't see a reason for putting them in two places. 3. Section 6.2, the RelAdr bit has been removed from the typical CDB for 10 and 12 byte commands. Since this bit isn't described under individual commands, it is left undefined in most cases. I can find a description of RelAdr under the Search Data command, however this isn't an intuitively obvious place for SCSI neophytes to look. 4. In section 6.7, ECA: The top of page 6-17 states that a target may generate an ECA during an AEN by sending INITIATE RECOVERY following the IDENTIFY message. Since the device is sending an AEN, it is acting as an initiator at this point and the word "target" is inappropriate. I think the sentence should be reworded to something like: "If a device wishes to ..." 5. Table 7-39, Sense Keys: The description of ILLEGAL REQUEST should be modified to specify that ILLEGAL REQUEST can be generated by conditions other than a CDB or parameter list error. In particular, an invalid IDENTIFY message sets an ILLEGAL REQUEST sense key (see section 5.6.7, 3rd to last paragraph). 6. Table 7-44, TEST UNIT READY responses: This table lists an ASC of "Unsupported Logical Unit". In table 7-41 this is described as "Logical Unit Not Supported". Please make the names consistent, especially since there are no ASC numbers in table 7-44. 7. Inquiry command, all text fields: To ease into ISO standardization, should the proper ISO character set standard be referenced in addition to ASCII? Or is the term ASCII acceptable? I also repeat my comment back in the R5 document, will there be foreign language problems with only supporting ASCII codes 20h to 7Eh? This prohibits using any non-English inquiry text. 8. WRITE AND VERIFY command: Regarding reallocation when the WRITE and VERIFY command is used, the second paragraph of the description of this command specifically states that the verify error recovery page shall be used. This should be modified to state that an amalgamation of verify error recovery page plus the AWRE bit from the read-write error recovery page is to be used or remove the statement that the verify error recovery page is used in WRITE AND VERIFY. 9. Section 8.3.2: Should direct access devices define Log Page 04h, which returns a count of Read Reverse errors? There is no read reverse command defined for direct access devices. I suggest this line be removed. 10. Section 8.3.3, device specific parameter byte: Should the Mode Select meaning of WP and Cache be "ignored"? This means that these bits can never be used in an upward compatible enhancement of SCSI-2 (for example, having WP set write protect for the unit). Would Reserved be a better definition so that the fields must be 0? Also on this page, in table 8-45, bit 5 should also be flagged as Reserved. 11. Section 8.3.3.3, Format Device Page, Interleave parameter: The Interleave parameter is defined as ignored in mode select. Wouldn't it be safer to specify it as not-changeable and require that the initiator return the same value it received, as with all other non-changable parameters? It's reasonable in SCSI-x to have interleave specified by this page instead of by Format. It'll be harder to do if systems are setting this parameter to random garbage as is currently allowed. 12. A final general comment. This document MUST have an index when published. The index must at the very least document all commands and where they are defined. Given a command name, at present there is no simple way to find the command in the document. I realize this is a lot of work for somebody, but it's extremely frustrating to use a >600 page reference work without an index. [The following comments were added in Rev 1 of this document:] 13. Section 7.2.10.4, Mode Sense, Saved Values: This section says that if saved values are "not available" the target should return ILLEGAL REQUEST and SAVING PARAMETERS NOT SUPPORTED. I interpret "not available" to apply in the case of initial power up, which conflicts with section 7.2.10.5. I can't think of a case where parameters are "not available" but implemented which doesn't imply a not ready condition. Therefore, I suggest the words "not available or" be removed from section 7.2.10.4. 14. Section 8.3.3.8, Verify error recovery page: This page includes the DTE bit (disable transfer on error). If the BytChk bit is not set in the verify command this bit doesn't make sense (how does one terminate the data phase if the command doesn't have one?) Does DTE have a meaning in a VERIFY command with BytChk not set? 15. Also in section 8.3.3.8, the third paragraph regarding the AWRE bit, it isn't clear to me whether this means the AWRE bit for the current read / write recovery page or whether the AWRE bit should also be added to the verify error recovery page. I don't think the reference to the COPY command should be in this paragraph, the verify error recovery page doesn't apply to the COPY command. I suggest this paragraph be reworded to something like the following (assuming I have the correct interpretation): During the verify portion of the WRITE AND VERIFY or COPY AND VERIFY commands the AWRE bit from the currently active Read Write Error Recovery Page (see table 8-54) applies, allowing automatic reallocations during this phases."