96-148r0 -- SPC Letter Ballot Comments Resolution
ROWEBER at acm.org
ROWEBER at acm.org
Wed Mar 20 19:58:25 PST 1996
* From the SCSI Reflector, posted by:
* ROWEBER at ACM.ORG
*
X3T10/96-148R0
To: Membership of X3T10
From: Ralph O. Weber
ENDL Associates
Date: March 20, 1996
Subject: SPC Letter Ballot Comments Resolution
The following is a tentative resolution for the SPC letter ballot comments.
Final resolution is pending an SPC editing meeting scheduled for 17 and
18 April in San Jose, hosted by Seagate.
Exabyte comments on SPC attached to No ballot:
I am voting NO to forwarding X3T10/995D rev 9 for further processing with the
following comments.
I tried to sort the comments into editorial and technical. Anything requir-
ing clarification is included in the technical comments. I am willing to
entertain the possibility of changing my vote to YES if the technical
comments are reasonably addressed.
Technical comments:
1. Page 10-11, Reservations. The interactions between persistent and non-
persistent reservations are not clear. The last paragraph in the section
talks about conflicts between the different reservations but does not
state what happens.
ACCEPT sort-of. The descriptions of what happens when reservations are
improperly mixed with persistent reservations will be described in the
definitions of the RESERVE, RELEASE, PERSISTENT RESERVE IN, and
PERSISTENT RESERVE OUT commands.
The text to be placed in the RESERVE and RELEASE commands is:
"If a device server has any reservation keys registered (see clause
7.14.1.1) a RESERVE (or RELEASE) command shall be rejected with a
RESERVATION CONFLICT status."
2. Page 50, PERSISTENT RESERVE IN command. The first paragraph states "..
and cannot be used with the RESERVE and RELEASE commands". What does used
with mean? What if the logical unit is already reserved? Conversely,
what if persistent reservations exist and the other reserve is used?
This information should be in section 5.3 reservations and referred to
by the PERSISTENT RESERVE IN command.
ACCEPT Add the following text to the PERSISTENT RESERVE IN, and PERSISTENT
RESERVE OUT commands: "When a PERSISTENT RESERVE IN command (or
PERSISTENT RESERVE OUT command) is received and RESERVE(6) or
RESERVE(10) logical unit or extent reservations are active (see
clause 7.23), the command shall be rejected with a RESERVATION
CONFLICT status."
3. Page 53, PERSISTENT RESERVE OUT command. The first paragraph states
"... and shall not be used with the RESERVE and RELEASE commands". Same
comments as before (note that Reserve Out states shall whereas Reserve In
states cannot). This information should be in section 5.3 reservations
and referred to by the PERSISTENT RESERVE OUT command.
ACCEPT see resolution for Exabyte comment #2.
4. Page 62, paragraph under table 46. The first sentence states that a
reservation conflict shall occur when a PREVENT ALLOW MEDIUM REMOVAL
command is received from an initiator other than the one holding a
logical unit reservation. The last sentence states that a reservation
shall not occur when Prevent bit is zero for extent reservations. This
is a conflict. The blanket statement at the beginning of the paragraph
needs to be changed.
REJECT The first sentence in the paragraph is NOT a blanket statement. It
is specifically limited to "a logical unit reservation." The last
sentence in the paragraph covers "extent reservations."
5. Page 62, paragraph under table 46. The case of prevent bit set to 0
not causing a reservation conflict should not be restricted to extent
reservations. Any prevent must be releasable by an initiator regardless
of the reservation situation.
ACCEPT SCSI-2 clearly allows PREVENT ALLOW MEDIUM REMOVAL commands with
Prevent=0 not to be blocked by any type of reservation.
6. Page 62, paragraph under table 46. Thinking about the first sentence
again, that sentence (which is used for many commands) implies that a
reservation conflict occurs when NO initiator holds a reservation. An
initiator sending a command to a non-reserved target could be interpreted
as different than no initiator holding a logical unit reservation.
Therefore, a reservation conflict would exist, according to the first
statement. Additionally, it states "holding a logical unit reservation",
not "holding a reservation on the logical unit". This could be
interpreted as a reservation on a different logical unit affecting the
logical unit for which the command was sent. A better statement would
be:
A reservation conflict shall occur when a PREVENT ALLOW MEDIUM REMOVAL
command is received with the Prevent bit set to one if the logical unit
is reserved by any initiator other than the one requesting the command.
Similar text may fix the other commands using the reservation statement
substituting the command name and removing the text about the Prevent bit.
ACCEPT Add the following sentence to the beginning of all command paragraphs
describing reservations interactions: "If reservations are active, they
shall affect the execution of the XXX command as follows."
7. Page 66, RECEIVE DIAGNOSTIC RESULTS command. Didn't we add a page code
to the RECEIVE DIAGNOSTICS command (or at least agree to the concept of
adding a page code)? We talked about it in the November 1995 working
group when we talked about 95-324r1. While the enclosure services are
not included in 995 r9, maybe we should add the page code to the command
in byte 2?
ACCEPT
8. Page 68, RELEASE(10) command. Is support of the LongID bit optional?
It should be and the standard text about ILLEGAL REQUEST needs to be
added if it is not supported.
ACCEPT Add the following text: "Device servers that support device IDs greater
than 255 shall accept commands with LongID equal to one. Device
servers whose devices IDs are limited to 255 or smaller may reject
commands with LongID equal to one with a sense key of ILLEGAL REQUEST."
9. Page 69, REPORT LUNS command. No mention on affects of reservations is
made. State "The REPORT LUNS command shall not be affected by
reservations".
ACCEPT
10.Page 88, RESERVE(10) command. Is support of the LongID bit optional?
It should be and the standard text about ILLEGAL REQUEST needs to be
added if it is not supported.
ACCEPT Add the following text: "Device servers that support device IDs greater
than 255 shall accept commands with LongID equal to one. Device
servers whose devices IDs are limited to 255 or smaller may reject
commands with LongID equal to one with a sense key of ILLEGAL REQUEST."
11.Add "ANSI", "ECMA", and "ISO" to the list in Annex C. This would help
in the use of the Report Supported Densities command in SSC.
ACCEPT in part
X3 was added to be used by Report Supported Densities. Using ANSI
is inappropriate because ANSI is not the standards developing body,
generally an X3 technical committee develops standards that are later
approved by ANSI. Add ECMA and ISO to the table in Annex C to permit
their use in reporting secondary identifications (standards references)
for tape densities.
Editorial comments:
1. Page 9 has the usage of "may be" in the first sentence of 5.1.1. Is
the use of "may be" appropriate for a standard?
REJECT The statement in question is describing a possibility that may be
exercised by the application client. It must be noted that SCSI
standards traditionally place the fewest possible number of
requirements on the application client. In this case, even
"should" would be too strong a statement.
2. Pages 67 and 68, RELEASE(x) commands. A reference to section 5.3,
reservations, should be made, particularly in reference to Persistent
reservations.
ACCEPT
3. Page 73, subsection d) under information field data. For both cases
1) and 2), instead of stating what fixed block mode and variable block
mode indicate, direct the reader to SSC. The text in parenthesis is not
exactly correct since the error could occur on a non-write command.
Being model dependent, the detailed text should not be stated here.
ACCEPT Add the following text at the end of bullet d) "For additional
information see SSC."
4. Pages 84 and 88, Reserve(x) commands. A reference to section 5.3,
reservations, should be made, particularly in reference to Persistent
reservations.
ACCEPT
5. Page 84, section 7.23.1, paragraph 3 has "See clause ?". Should refer
to section 5.3.
ACCEPT
6. Page 89, SEND DIAGNOSTICS command. Too many references to RECEIVE
DIAGNOSTICS RESULTS are made in the last sentence of the first paragraph.
Should be clause 7.18.
ACCEPT
7. Page 91, TEST UNIT READY command. The last sentence in the paragraph
above table 73 states "Higher-priority responses (e.g. BUSY or RESERVATION
CONFLICT) are also permitted. In the paragraph above, text indicates that
a reservation conflict shall occur. Therefore, reference to RESERVATION
CONFLICT in this sentence should be stricken. Also, what is a higher-
priority response if the only example is BUSY?
ACCEPT The critical thought in the sentence is that the table is not complete.
Other conditions may necessitate other responses. Change the paragraph
to read: "Table 73 defines the preferred GOOD and CHECK CONDITION
status responses to the TEST UNIT READY command. Other conditions may
result in other responses (e.g., BUSY or RESERVATION conflict status)."
IBM comments on SPC attached to No ballot:
1-(T) I do not think processor devices should be included in the SPC
standard. They should have their own command set document. This is
even more an issue with the newly proposed device for enclosures. The
new device and processor devices should both be in the same command set
document.
REJECT The SCSI working group continues to prefer including the processor
commands in the SPC.
2-(E) page i-1 - Abstract - The abstract does not include any comment
about processor devices. One must be place here if they remain in this
document.
REJECT Second paragraph of abstract covers processor devices.
3-(E) page 2 - 3.1.5 - This definition should be remove as the term is
not used in SPC unless someone can point it out where it is used.
REJECT "Blocked task" is used in the description of the Qerr bit in the
Control mode page (8.3.4).
4-(E) page 3 - 3.1.14 - This definition should be remove as the term is
not used in SPC unless someone can point it out where it is used.
REJECT "Enabled" (as in enabled task) is used in the description of the PROUT
command Reserve function (7.14.1.2). "Enabled task" is used in the
description of deferred errors (7.22.2).
5-(E) page 3 - 3.1.16 - The term I/O processes should be changed to
tasks.
ACCEPT
6-(E) page 4 - 3.1.25 - The statement 'Most usages of medium' should be
change to 'Except where noted the usage of medium'.
ACCEPT
7-(E) page 4 - 3.1.32 - There is a missing cross-reference.
ACCEPT
8-(E) page 4 - 3.1.35 - This definition should be remove as the term is
not used in SPC unless someone can point it out where it is used.
REJECT "Service delivery subsystem" is used in the definitions of SCSI Device
and SCSI Domain. "Service delivery subsystem" also is used in the
description of Asynchronous Event Reporting (6.2.1), the description
of the READ BUFFER command (7.16), the description of the REQUEST
SENSE command (7.22), and the description of the WRITE BUFFER
command (7.27). There may be more; I stopped searching here.
9-(E) page 6 - 4. - Need a comment about processor devices if they
remain in this document.
ACCEPT
10-(E) page 10 - 5.1.3 - Last sentence - The statement 'all is well'
should be replaced with 'if the test is successful'.
ACCEPT
11-(E) page 11 - 5.3 last paragraph - The term action is used here and
in the persistent reserve sections. This term needs to be added to the
glossary. For sample wording look in SCC at definition of service
action.
ACCEPT
12-(E) all - Replace SAM with SCSI-3 Architecture Model.
ACCEPT in part. Change "the SAM" to "SAM" throughout.
13-(T) page 16 - table 5 - Move Medium (attached) and Read Element
Status (attached) commands should be removed. They are already defined
in the SMC why are they redefined in SPC. If other non-SMC devices
need to use these commands then those devices command standards should
reference the SMC. If it is insisted these commands should be in SPC
then they need to be removed from SMC. In any case they should only be
defined in one place.
REJECT The SCSI working group agreed to leave these commands in table 5, but
to make the references directly to SMC, instead of to clauses in SPC.
14-(E) page 16 table 5 - What does (attached) mean in the Move Element
Status and Move Medium commands mean? Is it part of the command name
or what. I see no value it should be removed.
ACCEPT Change "(attached)" to "ATTACHED" throughout.
15-(E) page 32 table 19 - The use of italicized fonts should be removed
from this table.
ACCEPT Return the SIP-specific bit names to table 19, but add a table note
about their limited use.
16-(E) page 33 table 21 - I do not remember approving a document called
'here'. This should be a cross-reference to either SPC or the actual
clause in SPC.
ACCEPT Change 'here' to 'SPC'.
17-(T) page 34 - The second to last paragraph, third sentence should be
removed.
ACCEPT
18-(E) page 34 Last paragraph - page 35 first paragraph - page
36 table 23 - page 36 third paragraph - The use of italicized fonts
should be removed.
ACCEPT see resolution for IBM comment 15.
19-(E) page 38 - second paragraph - It is not clear at all what the
following statement means or why there is a requirement that the
peripheral qualifier and type byte be followed by anything: 'the
requested SCSI operation code it shall return the peripheral qualifier
and type byte followed by a byte containing 01h.'
ACCEPT change 'followed by a byte containing 01h' to 'and all zeros in byte
1 except for the Valid bit, which shall be set to one.'
20-(E) page 38 - paragraph above note - The statement 'Except for group
6 and group 7 operation code,' should be removed. All CDB lengths, even
the vendor specific lengths are defined in SAM.
ACCEPT Delete all but the first sentence in the paragraph in question.
21-(E) page 44 - second paragraph under table 29 - There are no more
dual ports in SCSI. 'Dual port' should be removed or replaced with
'multiple port' and 'both ports' should be replaced with 'all ports' or
removed.
ACCEPT Make replacements for 'dual port'.
22-(E) page 45 - 4th paragraph - last sentence - The list of standards
should be (SBC,SSC,SGC,MMC,SCC, etc.).
ACCEPT
23-(E) page 47 - table 32 heading - The table heading 'subclause'
should be 'clause'.
ACCEPT change all instances
24-(E) page 48 - 1st paragraph - last sentence - The list of standards
should be (SBC,SSC,SGC,MMC,SCC, etc.).
ACCEPT
24-(E) page 48 - 7.10.1 - 7.10.2 - 7.10.3 - 7.10.4 - The 0h, 1h, 2h,
and 3h should be 00b, 01b, 10b, and 11b.
REJECT why change from SCSI-2?
25-(T) page 49 - 7.12 - This sections should be removed see 13 above.
ACCEPT
26-(E) page 50 to 61 - The acronym PRIN and PROUT serve on useful
purpose other than making SCSI look more like a secret organization.
Remove those acronyms and replace them with Persistent Reserve In and
Persistent Reserve Out.
ACCEPT
. 27-(E) page 53 table 39 - The field 'Reservation key under which the
. reservation is held' should be just 'Reservation key' and should be
. described in the text. The field 'LBA of first block of Extent or
. Element Address' should be just 'LBA' or 'LBA_E or LBA_EA' and should
. be described in the text. The field 'Extent length' is not defined
. anywhere.
More information about the T10
mailing list