96-148R3 -- SPC Letter Ballot Comments Resolution
ROWEBER at acm.org
ROWEBER at acm.org
Wed Jul 3 14:46:50 PDT 1996
* From the SCSI Reflector, posted by:
* ROWEBER at ACM.ORG
*
X3T10/96-148R3
To: Membership of X3T10
From: Ralph O. Weber
Symbios Logic
Date: July 3, 1996
Subject: SPC Letter Ballot Comments Resolution
This revision is the same as R2 except that Seagate comment 73 is shown as
having been accepted (which it was).
It must be noted that Seagate comment 1 requested a page-by-page editing
meeting. That meeting was held over the course of three days; 17 and
18 April, and 10 May. Numerous changes were made during the editing
meeting(s), and those changes can be found in SPC rev 9b but are not described
in this document.
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 During the editing meeting(s), two abstracts were discovered. The
front matter has been reorganized following the model in SBC and now
there is only one abstract, which includes information about 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.
ACCEPT in principle. During the editing meeting(s), the names of the fields
in table 39 were changed to match common practice in SCSI standards and
suitable text definitions were added (or revised) for all fields.
28-(E) page 50 to 61 - The term 'extent' and 'element' are not defined.
They should be placed in the glossary.
ACCEPT
29-(E) page 53 - The sections that define the fields 'scope' and 'type'
should be move to this page under table 39. This is the first place
they are used and therefore should be defined here.
ACCEPT
30-(E) page 54 - Table 40 - The parameter list length field is a fixed
length so the length '18h' should be added to the field name in the
table.
ACCEPT
31-(E) page 54 - There must be a cross-reference to the scope and type
fields under table 40.
ACCEPT
32-(E) page 55 - 7.14.1.1 - Last paragraph - What does this sentence
mean?? I see no value so it should be deleted.
ACCEPT
33-(E) page 56 - third paragraph from top - The term 'active tasks' has
no meaning in SCSI. I assume it should be 'current tasks'.
ACCEPT
34-(E) page 57 - 7.14.1.5 - Last paragraph - What does this sentence
mean?? I see no value so it should be deleted.
ACCEPT
35-(E) page 57 - 7.14.1.6 - last paragraph - The statement 'Automatic
Contingent Allegiance condition (ACA condition)' should be replaced
with 'ACA condition'.
ACCEPT
36-(E) page 58 - 1st paragraph from top - Remove '(AEN)'.
ACCEPT
37-(E) page 58 - 4th paragraph from top - What does this sentence
mean?? I see no value so it should be deleted.
ACCEPT
38-(E) page 59 - The 4 paragraphs under table 43 need to be rewritten
to define each code. For example 'A type code of Read Shared (0h) allows
the execution of commands that perform....'
ACCEPT However, don't expect to see proposed new words in this document.
Check your next SPC revision.
39-(E) page 60 - 7.14.4 - first paragraph - The second sentence that
starts with 'Table 45 indicates..' should be moved to directly above
table 45.
ACCEPT
40-(E) page 60 - 7.14.4 - first paragraph - Remove the 3rd and 4th
sentences that start with 'Two PROUT ..' and end with '...parameter
description.' That information should be placed below table 44 and a
cross reference to a specific clause must be given.
ACCEPT
41-(E) page 60 - table 44 - The names of the first two fields should be
changed see comment number 27.
ACCEPT in part. During the editing meeting(s), the names of the fields in
table 44 were changed to match common practice in SCSI standards.
42-(E) page 60 - first paragraph after table 44 - The last sentence
should have the phrase 'and expected' removed.
ACCEPT & change 'set' to 'valid'
43-(E) page 60 - 2nd paragraph after table 44 - The third sentence
should be changed to 'For Preempt and Preempt and Clear actions...'.
ACCEPT
44-(E) page 60 - 3rd paragraph after table 44 - What are 'extent
parameters'?
ACCEPT in principle. During the editing meeting(s), the names of the fields
in table 44 were changed to match common practice in SCSI standards and
suitable text definitions were added (or revised) for all fields.
45-(E) page 60 - 4th paragraph after table 44 - What are 'element
address parameters'?.
ACCEPT in principle. During the editing meeting(s), the names of the fields
in table 44 were changed to match common practice in SCSI standards and
suitable text definitions were added (or revised) for all fields.
46-(E) page 60 - 5th paragraph after table 44 - The 2nd and 3rd
sentences should read 'The APTPL bit shall be set only for the Register
action. In all other cases, the APTPL bit shall be ignored.'
ACCEPT 'The APTPL bit shall be valid only for the Register action. In all
other cases, the APTPL bit shall be ignored.'
47-(E) page 61 - table 45 - Remove from the heading the statement 'Set
by initiator/expected by target'. Remove from the table all
'expected' and 'not set' and all '/'. This information contains no
useful information; everything that is set is expected and everything
that in not set is ignored.
ACCEPT Use "valid" or "ignored".
48-(T) page 65 - 7.17 - This sections should be removed see 13 above.
ACCEPT
49-(E) page 75 - first paragraph after table 62 - The last sentence
should read 'The progress indication shall be based upon the total
operation.'
ACCEPT
50-(E) page 75 - note 39 - The second sentence should read 'However,
since for example format time...'
ACCEPT
51-(E) page 84 - 7.23.1 - 3rd paragraph - The last sentence has an
undefined cross reference.
ACCEPT
52-(E) All - The left and right margins should be set to 1". Right now
the way they are set is causing words to be chopped of by the three hole
punch.
ACCEPT
53-(T) page 112 - 2nd and 3rd paragraphs - Should there even be a
ByprtM bit and a BybthS bit in SCSI-3? They appear to be from the dual
port proposal that was removed from SCSI-3. If they do remain then the
word 'both' in those two paragraphs should be changed to 'all'.
ACCEPT
54-(E) page 113 - first paragraph after table 98 - The terms 'Target
Role Agent' and 'Initiator Role Agent' need to be defined in the
glossary.
ACCEPT Get definitions from SIP.
55-(E) page 113 - 3rd paragraph after table 98 - There is no such term
as 'interconnect tenancy' in SIP so the last sentence for this
paragraph should be removed.
ACCEPT
56-(T) page 115 - 8.3.6 - First paragraph - The last sentence should be
changed to '...sense code of FAILURE PREDICTION THRESHOLD EXCEEDED or
WARNING to the applications client.' This change should have been part
of the proposal that added the WARNING ASC.
ACCEPT
57-(T) page 117 - first paragraph after table 101 - In second to the
last sentence the statement '...that the target shall only report the
information exception condition one time.' should be changed to '...that
the timer interval is vender specific.' Without this change it is
unclear what to do if both the interval timer and the report count
fields are set to zero.
ACCEPT, however, the exact wording differs from what is proposed here.
58-(E) page 119 - 8.3.8 - The following terms need to be added to the
glossary: standby condition, idle condition, and active condition.
Standby condition: When a logical unit is capable of accepting
commands, but media is not immediately accessible (e.g., spindle is
stopped).
Idle condition: When a logical unit is capable of responding quickly
to media access requests. However, a logical unit in the Idle
condition may take longer to complete the execution of a command
because it may have to activate some circuitry.
Active condition: When a logical unit is capable of responding
immediately to media access requests, and operations complete execution
in the shortest possible time.
ACCEPT
59-(E) page 119 - 8.3.8 - The following statement needs to replace
the first paragraph of this section:
The power conditions page (Table 104) provides the application client
the means to control the behavior of a logical unit in a manner which
reduces the power required to operate. There is no notification to the
initiator that a logical unit has entered into one of the power
conditions. The power conditions may be controlled by the Start/Stop
Unit command (See SBC) or the power condition page. If both methods
are being used on the same logical unit then any Start/Stop Unit
commands power condition request will override the power condition
pages power control.
No power condition shall affect the supply of termination power to the
SCSI bus.
ACCEPT
60-(E) page 119 - 8.3.8 -The following statement needs to be added
after the second paragraph (immediately before table 104):
Logical units that contain cache memory shall implicitly perform a
SYNCHRONIZE CACHE command (see SBC) for the entire medium prior to
entering into any power condition which prevents access the media (eg
the spindle being stopped).
The logical unit shall use the power condition page to control the
power conditions after a power on or a hard reset until a Start/Stop
Unit command is received that sets power conditions.
ACCEPT
61-(E) page 120 - figure 2 - Make the decision boxes into the
traditional shape.
ACCEPT
62-(E) page 123 - After table 109 the following statement needs to be
added: 'The peripheral qualifier field and the peripheral device type
field are defined in x.x.x.'
ACCEPT
63-(E) table 110 - table 111 - The values should be 0h,1h,2h,3h,and 4h.
ACCEPT
64-(T) 9. - This section should be removed. See comment 1.
REJECT
Milligan (Seagate) comments on SPC attached to No ballot:
1) Two factors seem apparent upon review of the SPC. The editor has done an
admirable job and X3T10 should have allocated time for a page by page
review of the document. The latter factor has contributed to the fact I
was unable to allocate sufficient time to do a complete the review. This
has been further aggravated by mid-air turbulence during dinner performing
a reset upon my unsaved comments during suspend mode.
ACCEPT The editing meetings were held on 17 and 18 April, and 10 May.
2) Normative requirements should not be included in the Foreword.
ACCEPT Remove every occurrence of "shall" from the Forward.
3) There is a grammatical error in the first line of the Revision Information
but it will soon disappear.
NICE
4) Referring to the first footnote, what are the changes that affect SBC?
ACCEPT issues resolved with SBC editor.
5) What is the meaning of the last line of the Introduction?
ACCEPT Change the last sentence to: "The information in the Annexes applies to
all the SCSI-3 command standards documents."
6) The second sentence of the second paragraph of clause 1 Scope is
confusing, possibly redundant to the third sentence, and should be
deleted.
ACCEPT Replace the last two sentences with: "This standard defines the SCSI
commands that are mandatory and optional for all SCSI devices."
7) In the second paragraph move the "also" from the first sentence to the
last sentence.
ACCEPT
8) Add "host" to the definitions.
ACCEPT Take the definition of host from 6.1.1 but add that the host typically
functions as an initiator.
9) Referring to Figure 1, I thought SAM was "Architectural". Delete "P" from
"P1394". Revise the SSA boxes to agree with the new revised SSA
architecture. Also delete X3T10.1.
REJECT SAM is Architecture.
ACCEPT changes to roadmap, see Symbios comments.
10)In 3.1.13 make "sets" singular.
ACCEPT
11)In 3.1.14 change "tast" to "task". This suggests that a spell check should
be run. Also change "in which task may" to "in which a task may".
ACCEPT
12)Why does 3.1.14 preclude parallel processing by a target (LUN?)? Perhaps
this is a SAM comment.
REJECT The current definition is ok.
13)In 3.1.18 "illegal" and "reserved" should not be synonyms.
ACCEPT Delete the "(reserved)".
14)Referring to 3.1.25, what are the definitions of the other usages?
ACCEPT Change as per the IBM comment.
15)Referring to 3.1.28, move "optional" to keywords and change "must be" to
"shall". (A global search should be done on "must".)
ACCEPT
16)In 3.1.30 change "Implementation of the reference item is defined" to
"Requirements for the reference item are defined".
ACCEPT
17)In 3.1.32 replace "clause ?" with the definitive clause.
ACCEPT
18)In 3.1.42 replace "to initiators" with "to one or more initiators".
ACCEPT
19)In 3.1.43 replace "may be used differently in various implementations" to
"may be vendor defined".
ACCEPT
19)I think the title of 3.2 should be changed from "Symbols and
abbreviations" to "Acronyms". There does not seem to any symbols or
abbreviations in the clause.
ACCEPT
20)In that clause, as an acronym definition, I think SCSI-3 should be dropped
from the MMC definition.
REJECT SCSI-3 is in the name of the MMC standard.
21)In 3.3 I think the definition of hexadecimal should be changed from
"Numbers immediately" to "Numbers or upper case letters immediately".
ACCEPT
22)In clause 4 delete the second, confusing, sentence in favor of the third
sentence which correctly states the requirement.
ACCEPT
23)In 4.1 "Status" does not match the convention defined by 3.3.
REJECT The current usage matches similar usage throughout the document.
24)Admittedly I remain somewhat confused by the obtuse language selected for
SCSI-3, but as I have understood it, device server is more closely aligned
with a LUN than with a target, especially when the LUNs are each different
device types, consequently I question "in a target is a device server" in
the last paragraph of 4.1.
ACCEPT The usage of target, LUN, and device server were reviewed at the
editing meeting(s).
25)Beginning, I believe, with 4.2 the term "Data-Out buffer" is used. This
term appears to be an inadvertent insertion of a vendor specific
implementation detail that is inappropriate for the standard. This clause
and other clauses revealed by a global search should be purged of the
implementation detail.
REJECT The current wording is the correct SAMinizing of the SCSI-2 text.
26)In clause 5 the second sentence states the model is not intended to
define any requirements. The third sentence defines a requirement. At one
time I proposed that models should not include requirements. I believe I
lost this argument but I do not recall for sure. (Having lost the
argument, I think, I am inclined to include requirements, not found
conveniently in other clauses, in the model of SBC.) However, regardless
of the X3T10 decision on the general issue, the last two sentences of
clause 5 should not contradict each other.
ACCEPT Replace the paragraph with: "This model describes the general
characteristics expected of SCSI-3 devices. All SCSI-3 devices shall
conform to the SCSI-3 Architecture Model (SAM)."
27)In 5.1.1 it is alleged that the INQUIRY includes the "standard level"
implemented. This is not true, I lost on a proposal to do that. INQUIRY
not only does not provide the standard level, it does not even include
which standards are implemented. It is true that it allows a delinquent
implementation to report SCSI-3 approved version (a meaningless
definition) but it is not true that information is provided as to which
SCSI-3 standard the implementation was referring to.
REJECT The ANSI approved version field remains in the standard INQUIRY data;
however, the name was changed to ANSI version in the editing
meeting(s).
28)"Powerful features" are in the eye of the beholder and part of the
marketing boiler plate, in 5.1.3 replace "other powerful features when
used in conjunction with the RECEIVE DIAGNOSTIC RESULTS command, but this
capability is optional" with "other optional features used in conjunction
with the RECEIVE DIAGNOSTIC RESULTS command."
ACCEPT Delete the word powerful.
29)In 5.2 replace "is responsible to" with "should".
ACCEPT
30)Referring to 5.3, I don't think reservations are used to protect from
accidental modification. The modification is not accidental. I think they
are used to protect the sequence of data modifications.
ACCEPT Change "to protect shared data from accidental modification" to "to
share and protect data or resources."
31)Having read persistent reservations, my impression is that the
nonpersistent reservations are more persistent that the persistent
reservations. I suggest replacing "nonpersistent" with "mandatory".
ACCEPT Delete the clause containing "nonpersistent".
32)Change "Extent reservations may place restrictions" to "Extent
reservations place restrictions". For the same reason delete "may" in the
third paragraph of 5.3.
ACCEPT
33)In the third paragraph change "The reservations do persist" to "The
reservations persist" and delete ", so that recovery can be managed
without requiring complete reinitialization of the system".
ACCEPT delete the "do". Change "so that" clause as shown in notes.
34)Change "command's operations contains" to "command contains".
ACCEPT
35)Change "Commands that retrieve or alter information about the device
server's operating state shall conflict with the logical unit reservation
unless otherwise specified." to "Commands that retrieve or alter
information about the device server's operating state shall be rejected
with a reservation conflict response unless otherwise specified." Make a
similar repair to the next sentence.
ACCEPT Additional changes were made at the editing meeting(s).
36)I have many marks on other pages through page 72 but have not been able to
allocate sufficient time to write them up. I hope to continue the write-up
and mark up in preparation for the editing session requested by comment
(1). My next comment is out of sequence with the remaining comments I have
in the queue.
ACCEPT
37)Referring to Table 5 and the balance of the document I note that the SET
CAPACITY command voted in by X3T10 has not yet been edited into the
document.
WITHDRAWN
I apologize for not being able to provide a full review by the closing date
of the letter ballot. To avoid such an apology in the future I do request
that X3T10 establish, or reestablish an editing review session prior to the
forwarding of each proposed standard. In submitting these, and the pending
comments I am definitely not requesting a protracted delay in the forwarding
since I wholeheartedly support regular publication of the standards which
have not become obsolete or academic.
Final Comments on SPC Revision 9
As I recall, the editing session in San Jose completed the comments through
Table 104. These are the comments I had after Table 104 based upon Revision 9.
38) indicates a logical unit shall should be changed to indicates the logical
unit shall.
ACCEPT
39) Regarding Figure 2 define Idle and Standby somewhere.
ACCEPT in part. Definitions have been added to the glossary for 'idle
condition' and 'standby condition'. The idle bit and standby bit need
no glossary definitions.
40) Regarding Table 105, what happened to John Lohmeyers universal
identification page? Or is it 83h?
ACCEPT That's right, it's 83h.
41) The first paragraph of 8.4.1 states that the contents of this data is not
defined. The last paragraph defines the contents of the data. I suggest
deleting the last sentence of the first paragraph.
ACCEPT
42) Should the last phrase of clauses 8.4.1 and 8.4.2 instead be one or more
null (00h) characters? In other words after a null is encountered can the
balance of the logical block be something other than null?
REJECT The null character marks the termination of the string. What
appears after the null is irrelevant and not a proper subject
for standardization.
43) In 8.4.2 replace returns with contains.
ACCEPT
44) 8.4.3 uses the phraseology optional device identification page which is
good but why don't the other optional pages have similar phraseology?
ACCEPT Remove 'optional' from 8.4.3.
45) The first paragraph states zero or more identification descriptors. But
the second paragraph states Device identifiers shall be assigned.
Consequently how can there be zero?
ACCEPT add "if any" to the second paragraph.
46) Change the SCC to SCC.
ACCEPT
47) Note 58 allows device identifiers to be vendor-specific in their
construction but device identifier is not actually a defined term. Does
this mean they can construct a new definition for the elements of page
code 83h?
ACCEPT Add reference information to note 58 to clarify the object being
discussed.
48) In Table 110 deleted only as it sounds demeaning.
ACCEPT
49) Regarding Table 111 add IEEE EUI-64 and X3.230-1994 to the normative
references.
ACCEPT in part. Normative reference added for X3.230-1994 but not for IEEE
EUI-64. It's unclear whether EUI-64 is a standard.
50) Should the example including Table 112 be part of a note or an annex?
REJECT the current format is the best we can do within the constraints of the
word processing software being used for the SPC.
51) Which Table 111 value does this example apply to?
ACCEPT notes have been added to guide the reader through the example.
52) In table 112 why is the quotation mark ahead of the company name?
REJECT the quotation mark is the ASCII value for 22h. Although 22h is the
byte count for the name string, it must be translated into ASCII in
accordance with the rules for this type of data presentation. Most
programming engineers recognize this data presentation method and will
not be confused by the quotation mark.
53) In 8.4.4 change specified to defined.
ACCEPT
54) I think 8.4.5 should also reference Table 105 or if that is too many
pages away clause 8.4.
ACCEPT added reference to clause 8.4.
55) The first sentence of the last paragraph of 8.4.6 states the data is
vendor-specific. The next sentence states a definition for the data.
Either it is vendor specific or it is not. Choose one.
ACCEPT reworded to clarify that the serial number is vendor-specific, but the
ASCII data used to represent it is not.
56) Change the title of clause 9 to Commands for processor device types.
ACCEPT
57) In 9.1 and 9.2 add the phrase If reserved.
ACCEPT
58) Why can the RECEIVE command be issued to any LUN but the SEND only to
LUN zero?
REJECT A SEND can be sent to any LUN, but a SEND with the AER bit set to one
can only be sent to LUN 0.
59) Regarding 9.2, add SCSI-2 to the normative references.
ACCEPT
60) In 10.1 Table 120 states reserved for device type pages. This is a
device type page. I think in this table it should be just plain reserved.
ACCEPT
61) Table 121 also states see specific device type for definition. This is a
device type page. I think in this table it should be just plain reserved.
ACCEPT
62) In the first paragraph of Annex A change conflict clause 7 to conflict
with clause 7.
ACCEPT
63) Delete the last sentence of the first paragraph.
ACCEPT
64) In the first paragraph of A.2 change the application client to an
application client.
ACCEPT
65) Table A.1 has at least 10 shalls and nearly as many in Tables A.4, A.6,
A.8 Delete them all and add an s to the following word. Except for the
shall nots which should be replaced with does not.
ACCEPT
66) In Table A.1 replace in which log parameter value has changed with in
which a log parameter value has changed
ACCEPT
67) In the first line above Table A.2 and several lines above Table A.3, A.4,
A.5, A.6 change the possible to possible.
ACCEPT
68) Regarding binary format clause A.1.1 contradicts the last two rows (not
lines) of Table A.2 and the last row of Table A.6, A.8.
ACCEPT
69) Three lines above Table A.5 replace selected for saving shall be saved
with selected for saving are saved.
ACCEPT
70) Eliminate the four shalls in Table A.6 with appropriate wording
adjustments.
ACCEPT
71) In A.4 replace things with items. Replace What those things are is left
up to the imagination of implementors. with Items which are logged are
vendor-specific. Delete the balance of the paragraph.
ACCEPT
72) Delete the next two sentences.
ACCEPT
73) In Table A.7 replace the application client with an application client
in two places.
ACCEPT
74) Above Table A.9 change describes how the target shall deal with exception
conditions with describes target logging exception conditions.
ACCEPT however the editing meeting developed different wording changes.
75) The pseudo code in A.4.3 should have an ) at the end of (a).
ACCEPT
76) Item (f) addresses the condition of ACA supported. What if ACA is not
supported?
ACCEPT added wording after table A.9 that describes the non-ACA case.
77) I think tables B.1, B.2 and B.3 should have a statement about blank codes.
ACCEPT
78) I think table B.2 should have a statement about how to deal with lack of
synchronization between SPC command code definitions and other command
set code definitions.
ACCEPT however, we're still working on the details of this.
Symbios Logic comments on SPC attached to Yes ballot:
1. (E) 2nd page
The internet address for subscribing to the SCSI Reflector
is now: majordomo at symbios.com
ACCEPT
2. (E) 2nd page
In the Patent Statement, "holder's" should be "holders".
ACCEPT
3. (E) Pages x & xi
Consider deleting these two pages; they add almost no value.
ACCEPT Yes, the notes table of contents should be deleted (along with the
revision information) prior to public review.
4. (E) 1, Page 1, Figure 1
This figure is out of date. Consider adding "at the time it was last
revised" to the end of the sentence above the figure. Consider updating
the figure based on the file provided separately.
ACCEPT
5. (E) 7.13.2, Page 51, Table 37
The "Additional length (n+8)" should be "Additional length (n-7)". This
error may have resulted from the second sentence in the description of
this field (which adds no real value and should be deleted).
ACCEPT
6. (E) 7.13.3, Page 52, Table 38
Same error as described in comment #5.
ACCEPT
Unisys comments on SPC attached to Yes ballot:
1) Section 7.13.2 PERSISTENT RESERVE IN - Page 52, first paragraph
following table 37. "The Generation value is a 32-bit counter in the
logical unit that shall be incremented every time a PROUT command
requests a Register, a Preempt, or a Preempt and Clear operation."
This seems to exempt the Clear operation. Or is the intention that
reference to the "Preempt and Clear operation" also covers the Clear
operation?
ACCEPT, provided the next General SCSI Working Group accepts the change.
2) Section 17.3.3 PERSISTENT RESERVE IN - Page 52, second paragraph
following table 38. The additional length definition in this paragraph
is identical to that used in 17.3.2 only 3 paragraphs above, so why not
reference it, rather than repeat it?
REJECT Why have the reader scanning the document for references when the text
is present and ready to read.
Unitrode comment on SPC attached to Yes ballot:
Fast-20 1071D should be added to Section 1.
ACCEPT
Late comment from Western Digital:
In SBC, the PREVENT ALLOW command is a TWO bit field, and in SPC
it is a ONE bit field. It seems to me that the TWO bit SBC version
should be moved into SPC. The two bit field seems pretty generic;
it has no inherent 'disk-ness'.
ACCEPT
More information about the T10
mailing list