Letter Ballot Results on forwarding SPC (96-012)
Lohmeyer, John
JLOHMEYE at cosmpdaero.co.symbios.com
Wed Mar 6 16:51:00 PST 1996
* From the SCSI Reflector, posted by:
* "Lohmeyer, John" <JLOHMEYE at cosmpdaero.co.symbios.com>
*
* From the SCSI Reflector, posted by:
* "Lohmeyer, John" <JLOHMEYE at COSMPDAERO.CO.SYMBIOS.COM>
*
[[ 96-020R0.TXT : 4408 in 96-020R0.TXT ]]
--
John Lohmeyer E-Mail: john.lohmeyer at symbios.com
Symbios Logic Inc. Voice: 719-573-3362
1635 Aeroplaza Dr. Fax: 719-573-3037
Colo Spgs, CO 80916 SCSI BBS: 719-574-0424 300--14400 baud
X3T10/96-020 r0
Accredited Standards Committee*
X3, Information Technology
Doc. No.: X3T10/96-020 r0
Date: March 6, 1996
Project: 0995-D
Ref. Doc.: X3T10/96-012
Reply to: Mr. John Lohmeyer
Symbios Logic Inc.
1635 Aeroplaza Dr.
Colo Spgs, CO 80916
(719) 573-3362
To: X3T10 Membership
Subject: Letter Ballot Results on forwarding SPC (96-012)
The letter ballot on forwarding SPC passed as shown in the below table. The
comments received need to be addressed by X3T10 and the proposed ballot
resolution must be approved by X3T10.
Organization Stat Person SPC Comments
(96-012)
Adaptec, Inc. P Mr. Norm Harris Y
Amdahl Corp. P Mr. Edward Fong Y
AMP, Inc. P Mr. Charles Brill Y
Amphenol Interconnect P Mr. Michael Wingard Y
Ancot Corp. P Mr. Jan V. Dedek Y
Apple Computer A Mr. Ron Roberts Y
BusLogic P Mr. Clifford E. Y
Strang Jr.
Ciprico Inc. P Mr. Gerry Johnsen Y
Circuit Assembly Corp. P Mr. Ian Morrell Y
Cirrus Logic Inc. P Mr. Joe Chen Y
CMD Technology P Mr. Edward Haske Y
Congruent Software, Inc. DNR
Dallas Semiconductor P Mr. Louis Grantham Y
Digital Equipment Corp. P Mr. Charles Monia Y
Eastman Kodak Co. DNR
ENDL Associate P Mr. Ralph O. Weber Y
Exabyte Corp. P Mr. Edward Lappin N
FSI Consulting Services P Mr. Gary R. Stephens Y
Fujitsu Computer P Mr. Robert Liu Y
Products,Am
Hewlett Packard Co. P Mr. Stephen Holmstead Y
Hitachi Micro Systems, Inc.P Mr. S. Nadershahi Y
Honda Connectors A Mr. Thomas J. Kulesza Y
IBM Corp. P Mr. George Penokie N
IIX Consulting DNR
Iomega Corp. P Mr. Geoffrey Barton Y
Linfinity Micro P Mr. Dean Wallace Y
Madison Cable Corp. P Mr. Robert Bellino Y
Maxtor Corp. P Mr. Pete McLean Y
Methode Electronics, Inc. P Mr. Steve D. Schueler Y
Molex Inc. P Mr. Joe Dambach Y
NEC Technologies DNR
Oak Technology, Inc. P Mr. Dennis Van Dalsen Y
Ophidian Designs DNR
Panasonic Technologies, IncP Mr. Stephen F. Heil Y
QLogic Corp. P Mr. Skip Jones Y
Quantum Corp. P Mr. James McGrath Y/C no comments
received
Seagate Technology P Mr. Gene Milligan N Individual vote
Silicon Systems, Inc. A Mr. Dave Guss Y
Storage Technology Corp. P Mr. Erich Oetting Y
Sun Microsystems Computer DNR
Co
Symbios Logic Inc. P Mr. John Lohmeyer Y/C
SyQuest Technology, Inc. P Mr. Patrick Mercer Y
Tandem Computers P Mr. John Moy Y
Toshiba America P Mr. Tokuyuki Totani Y
Trimm Technologies P Mr. Gary M. Watson Y
UNISYS Corporation DNR
Unitrode Integrated P Mr. Paul D. Aloisi Y/C
Circuits
Western Digital Corporation DNR
Woven Electronics DNR
Key: Totals: 37:3:0:9=49
Y - Yes
Y/C - Yes, with comment
N - No
DNR - Did Not Return ballot
Comments Received on SPC:
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 requiring
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.
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.
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.
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.
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.
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.
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?
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.
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".
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.
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.
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?
2. Pages 67 and 68, RELEASE(x) commands. A reference to section 5.3,
reservations, should be made, particularly in reference to Persistent
reservations.
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.
4. Pages 84 and 88, Reserve(x) commands. A reference to section 5.3,
reservations, should be made, particularly in reference to Persistent
reservations.
5. Page 84, section 7.23.1, paragraph 3 has "See clause ?". Should refer
to section 5.3.
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.
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?
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.
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
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.
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.
5-(E) page 3 - 3.1.16 - The term I/O processes should be changed to
tasks.
6-(E) page 4 - 3.1.25 - The statement 'Most usages of medium' should be
change to 'Except where noted the usage of medium'.
7-(E) page 4 - 3.1.32 - There is a missing cross-reference.
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.
9-(E) page 6 - 4. - Need a comment about processor devices if they
remain in this document.
10-(E) page 10 - 5.1.3 - Last sentence - The statement 'all is well'
should be replaced with 'if the test is successful'.
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.
12-(E) all - Replace SAM with SCSI-3 Architecture Model.
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.
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.
15-(E) page 32 table 19 - The use of italicized fonts should be removed
from this table.
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.
17-(T) page 34 - The second to last paragraph, third sentence should be
removed.
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.
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.'
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.
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.
22-(E) page 45 - 4th paragraph - last sentence - The list of standards
should be (SBC,SSC,SGC,MMC,SCC, etc.).
23-(E) page 47 - table 32 heading - The table heading 'subclause'
should be 'clause'.
24-(E) page 48 - 1st paragraph - last sentence - The list of standards
should be (SBC,SSC,SGC,MMC,SCC, etc.).
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.
25-(T) page 49 - 7.12 - This sections should be removed see 13 above.
26-(E) page 50 to 61 - The acronym PRIN and PROUT serve on usful
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.
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.
28-(E) page 50 to 61 - The term 'extent' and 'element' are not defined.
They should be placed in the glossary.
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.
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.
31-(E) page 54 - There must be a cross-reference to the scope and type
fields under table 40.
32-(E) page 55 - 7.14.1.1 - Last paragraph - What does this sentence
mean?? I see no value so it should be deleted.
33-(E) page 56 - third paragraph from top - The term 'active tasks' has
no meaning in SCSI. I assume it should be 'current tasks'.
34-(E) page 57 - 7.14.1.5 - Last paragraph - What does this sentence
mean?? I see no value so it should be deleted.
35-(E) page 57 - 7.14.1.6 - last paragraph - The statement 'Automatic
Contingent Allegiance condition (ACA condition)' should be replaced
with 'ACA condition'.
36-(E) page 58 - 1st paragraph from top - Remove '(AEN)'.
37-(E) page 58 - 4th paragraph from top - What does this sentence
mean?? I see no value so it should be deleted.
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....'
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.
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.
41-(E) page 60 - table 44 - The names of the first two fields should be
changed see comment number 27.
42-(E) page 60 - first paragraph after table 44 - The last sentence
should have the phrase 'and expected' removed.
43-(E) page 60 - 2nd paragraph after table 44 - The third sentence
should be changed to 'For Preempt and Preempt and Clear actions...'.
44-(E) page 60 - 3rd paragraph after table 44 - What are 'extent
parameters'?
45-(E) page 60 - 4th paragraph after table 44 - What are 'element
address parameters'?.
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.'
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.
48-(T) page 65 - 7.17 - This sections should be removed see 13 above.
49-(E) page 75 - first paragraph after table 62 - The last sentence
should read 'The progress indication shall be based upon the total
operation.'
50-(E) page 75 - note 39 - The second sentence should read 'However,
since for example format time...'
51-(E) page 84 - 7.23.1 - 3rd paragraph - The last sentence has an
undefined cross reference.
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.
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'.
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.
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.
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.
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 on 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.
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 (eg 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.
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.
60-(E) page 119 - 8.3.8 -The following statement needs to be added
after the second paragraph:
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.
61-(E) page 120 - figure 2 - Make the decision boxes into the
traditional shape.
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.'
63-(E) table 110 - table 111 - The values should be 0h,1h,2h,3h,and 4h.
64-(T) 9. - This section should be removed. See comment 1.
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.
2) Normative requirements should not be included in the Foreword.
3) There is a grammatical error in the first line of the Revision Information
but it will soon disappear.
4) Referring to the first footnote, what are the changes that affect SBC?
5) What is the meaning of the last line of the Introduction?
6) The second sentence of the second paragraph of clause 1 Scope is
confusing, possibly redundant to the third sentence, and should be
deleted.
7) In the second paragraph move the "also" from the first sentence to the
last sentence.
8) Add "host" to the definitions.
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.
10)In 3.1.13 make "sets" singular.
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".
12)Why does 3.1.14 preclude parallel processing by a target (LUN?)? Perhaps
this is a SAM comment.
13)In 3.1.18 "illegal" and "reserved" should not be synonyms.
14)Referring to 3.1.25, what are the definitions of the other usages?
15)Referring to 3.1.28, move "optional" to keywords and change "must be" to
"shall". (A global search should be done on "must".)
16)In 3.1.30 change "Implementation of the reference item is defined" to
"Requirements for the reference item are defined".
17)In 3.1.32 replace "clause ?" with the definitive clause.
18)In 3.1.42 replace "to initiators" with "to one or more initiators".
19)In 3.1.43 replace "may be used differently in various implementations" to
"may be vendor defined".
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.
20)In that clause, as an acronym definition, I think SCSI-3 should be dropped
from the MMC definition.
21)In 3.3 I think the definition of hexadecimal should be changed from
"Numbers immediately" to "Numbers or upper case letters immediately".
22)In clause 4 delete the second, confusing, sentence in favor of the third
sentence which correctly states the requirement.
23)In 4.1 "Status" does not match the convention defined by 3.3.
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.
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.
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.
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.
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."
29)In 5.2 replace "is responsible to" with "should".
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.
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".
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.
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".
34)Change "command's operations contains" to "command contains".
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.
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.
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.
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.
Gene Milligan
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
2. (E) 2nd page
In the Patent Statement, "holder's" should be "holders".
3. (E) Pages x & xi
Consider deleting these two pages; they add almost no value.
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 as follows (I can provide the line-drawing version of this ASCII
figure):
+-------------------------------------+
- - - - - - - - - -| SCSI-3 Common Access Method (CAM-3) |- - - - - - - - - -
+-------------------------------------+
+--------+ +--------+ +--------+ +--------+ +----------+ +--------+
|SCSI-3 | |SCSI-3 | |SCSI-3 | |SCSI-3 | | SCSI-3 | |SCSI-3 |
|Block | |Stream | |Graphic | |Medium | |Controller| |Multi- |
|Commands| |Commands| |Commands| |Changer | |Commands | |Media |
| (SBC) | | (SSC) | | (SGC) | |Commands| | (SCC) | |Commands|
+--------+ +--------+ +--------+ | (SMC) | +----------+ | (MMC) |
| | | +--------+ | +--------+
| | | | | |
+--------------------------------------------------------+
|
+-------------------------------+
| SCSI-3 Primary Commands (SPC) |
+-------------------------------+
|
+---------------------------------+
- - - - - - - - - - -| SCSI-3 Architecture Model (SAM) |- - - - - - - - - - -
+---------------------------------+
|
+---------------------------------------------------+
| | | | |
+-----------+ +--------+ +----------+ +------------+ +----------+
| SCSI-3 | | Fiber | | Serial | | SSA SCSI-3 | | Generic |
|Interlocked| |Channel | | Bus | | Protocol | |Packetized|
| Protocol | |Protocol| | Protocol | | | | Protocol |
| (SIP) | | (FCP) | | (SBP) | | (SSA-S3P) | | (GPP) |
+-----------+ +--------+ +----------+ +------------+ | Technical|
| | | | | Report |
+---------+ +-----------+ +--------+ +----------+ +-----------+ +----------+
| SCSI-3 | | SCSI-3 | | | |IEEE P1394| |SSA-TL1/TL2| |
| Fast-20 |--| Parallel | | Fibre | |High Perf.| |_ _ _ _ _ _| Almost any
|Par. I/F | | Interface | |Channel | |Serial Bus| | | Packet
|(Fast-20)| | (SPI) | |(FC-PH) | | (1394) | |SSA-PH1/PH2| Interface
+---------+ +-----------+ +--------+ +----------+ +-----------+
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).
6. (E) 7.13.3, Page 52, Table 38
Same error as described in comment #5.
Unitrode comment on SPC attached to Yes ballot:
Fast-20 1071D should be added to Section 1.
More information about the T10
mailing list