Voting Results on Forwarding SCC-2 to first public review

John Lohmeyer John.Lohmeyer at symbios.com
Thu Sep 4 08:42:52 PDT 1997


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* John Lohmeyer <John.Lohmeyer at Symbios.com>
*
                                                           T10/97-031 r0
Voting Results on T10 Letter Ballot 97-029r0 on
Forwarding SCC-2 to first public review

Organization                      Name                 S Vote Add'l Info
--------------------------------- -------------------- - ---- ----------
Adaptec, Inc.                     Lawrence J. Lamers   P Yes  
AMP, Inc.                         Charles E. Brill     P Yes  
Amphenol Interconnect             Michael Wingard      P Yes  
Ancot Corp.                       Gary Porter          P YesC Cmnts 
Apple Computer                    Ron Roberts          A Yes  
Berg Electronics                  Doug Wagner          P Yes  
Cable Design Technologies         Richard Wagner       P Yes  
Ciprico Inc.                      gerry Johnsen        P Yes  
Circuit Assembly Corp.            Ian Morrell          P Yes  
Cirrus Logic Inc.                                        DNV  
CMD Technology                    Edward Haske         P Yes  
Congruent Software, Inc.          Peter Johansson      P Yes  
Dallas Semiconductor              Charles Tashbook     P Yes  
Data General / Clariion           Greg McSorley        P Yes  
Digital Equipment Corp.           Charles Monia        P Yes  
Diogenes SCSI                     Keith W. Parker      P Yes  
Distributed Processing Tech.      Roger Cummings       P Yes  
Eastman Kodak Co.                 Robert Reisch        P Yes  
ENDL                              Dal Allan            P Yes  
Exabyte Corp.                     Constance Kephart    P Yes  
FSI Consulting Services                                  DNV  
Fujitsu                           Chris Nieves         P Yes  
Harting Elektronik Inc.                                  DNV  
Hewlett Packard Co.               J. R. Sims, III      P Yes  
Hitachi Cable Manchester,Inc      Zane Daggett         P Yes  
Hitachi Micro Systems, Inc.       Paul Boulay          A Yes  
Hitachi Storage Products          Anthony Yang         P Yes  
Honda Connectors                  Thomas J. Kulesza    P Yes  
IBM Corp.                         George Penokie       P Yes  
KnowledgeTek, Inc.                Dennis Moore         P Yes  
Linfinity Micro                   Dean Wallace         P Yes  
LSI Logic Corp.                   Alan Littlewood      P Yes  
Madison Cable Corp.               Robert A. Bellino    P Yes  
Maxtor Corp.                      Pete McLean          P Yes  
Methode Electronics, Inc.         Bob masterson        P Yes  
Molex Inc.                        Joe Dambach          P Yes  
Oak Technology, Inc.              Lam Dang             A Yes  
Ophidian Designs                  Edward A. Gardner    P Yes  IV 
Philips Key Modules               Bill McFerrin        P Yes  
QLogic Corp.                      Skip Jones           P Yes  
Quantum Corp.                     Mark Evans           A Yes  
Seagate Technology                Gene Milligan        P YesC IV Cmnts 
Silicon Systems, Inc.             Dave Guss            P Yes  
Sony Electronics, Inc.            Jan F. Rebalski      A Yes  
Storage Technology Corp.          Erich Oetting        P Yes  
Sun Microsystems Computer Co      Bob Snively          P YesC Cmnts 
Symbios Logic Inc.                Ralph Weber          A No   Cmnts 
SyQuest Technology, Inc.          Pat Mercer           P Yes  
Tandem Computers                  Pete Tobias          P Yes  
Toshiba America Info Sys          Tokuyuki Totani      P Yes  
UNISYS Corporation                Ken Hallam           P Yes  
Unitrode Corporation              Paul Aloisi          P Yes  
Western Digital Corporation       Jeffrey L. Williams  P Yes  
Woven Electronics                 Doug Piper           P Yes  

Key:
P       Voter indicated he/she is principal member
A       Voter indicated he/she is alternate member
O       Voter indicated he/she is observer member
?       Voter indicated he/she is not member or does not know status
YesC    Yes with comments vote
Abs     Abstain vote
DNV     Organization did not vote
IV      Individual vote (not organizational vote)
Cmnts   Comments were included with ballot
NoCmnts No comments were included with a vote that requires comments
DUP     Duplicate ballot (last ballot received from org. is counted)
PSWD    The password was not correct (vote not counted)
ORG?    Organization is not voting member of T10 (vote not counted)

Ballot totals:
 50 Yes
  1 No
  0 Abstain
  3 Organization(s) did not vote
 54 Total voting organizations
  4 Ballot(s) included comments

This 2/3rds majority ballot passed.

**************************************************************

Comments attached to YesC ballot from Gary Porter of 
Ancot Corp.:

In my judgement, all of the following comments are editorial in 
nature, not technical.
1. The draft standard has a clause 0, which is not mentioned in the 
foreword where the clauses are described.
2. On page 12, section 5.1.4b, the text says there are two devices but 
the figure shows 3.
3. Same area, the text is missing the word "bus" which should follow 
the words "single SCSI".
4. Page 12, section 5.1.4cb, the text says there is one device but the 
figure shows 2.
5. Page 20, section 5.2.1.2.2, in the first sentence, the word "using" 
should be removed.
6. Page 21, section 5.2.1.2.3, in the second paragraph after Table 7, 
in the last sentence, the word "to" should be removed after the word 
"command".
7. Same area, in the third and fourth paragraphs after Table 7, the 
acronym "SCAL" should be "SACL" (three places).
8. Same area, in the fourth paragraph after Table 7, in the first 
sentence, there is poor agreement of singular and plural forms in the 
text. Perhaps this could be reworded as "Bus Identifier Field values 
greater than zero represent..."
9. Page 22, section 5.2.1.2.4, in the first paragraph after Note 5, 
the wording is completely different from that used for the other 
addressing methods, although the concepts and intent seem the same. I 
would suggest using the same wording as in the other addressing 
methods.
10. Page 44, Table 12, the key has an entry "S Mandatory when the 
Simple...", but that character does not appear anywhere in the table.

I got only as far as the 67th page in my scan. I may have more 
comments later, but wanted to get my vote recorded.


**************************************************************

Comments attached to YesC ballot from Gene Milligan of 
Seagate Technology:

1) Are the number of organizations submitting patent statements more 
than one? If so the statement "The known patent holder(s) has (have)," 
cpuld be pinned down. If it is just one the statement could also be 
less complicated.

2) Is the last paragraph of the patent statement, the correct one? It 
sounds contrary to the prior paragraph.

3) Referring to the table of contents should there be a Clause 0? Is 
this just a Frame artifact?

4) Also in the table of contents it appears that some clause titles 
are in small caps. Does this fir the Penokie originated small caps 
style guide?

5) In the Foreword I think "This foreword is not part of ANSI X3. - 
199x." should be "This foreword is not part of this standard." If not, 
it should be "This foreword is not part of ANSI NCITS.xxx - 199x." 
Another alternative would be "This foreword is not part of the SCSI 
Controller Commands standard." The guts of this comment is a global 
comment.

6) Although working groups do not have members per se, those that were 
the significant contributors should be recognized, I suggest changing 
"The joint T10 SCSI Controller Commands working group/RAID Advisory 
Board Host Interface working group, which developed this standard, has 
the following members:" to "The joint T10 SCSI Controller Commands 
working group/RAID Advisory Board Host Interface working group, which 
developed this standard, had the following principal participants:"

7) Why is "George O. Penokie, Chair" out in left field?

8) Does T10 approve standards? I thought they developed and reviewed 
standards. Perhpaps in this case it was just reviewed.

9) It seems odd to have normative requirements in the Introduction. Is 
this why it has been labled Clause 0?

10) It is certainly valid that "multiple operating systems must 
properly coordinate their actions" but it is not clear if "must" is a 
normative requirement or an act of God.

11) There are also musty requirements in 5.2.5.3 and B.1.9. In the 
case of B.1.9, if the must is a normative requirement, buring the 
normative requirement in a note of an example is not appropriate.

12) The technical editor should be able to determine if the pertaining 
clauses are more than one and fix "The clause(s) of this standard 
pertaining to the SCSI storage array device class," in the Scope 
clause.

13) "The objectives of the SCSI Controller Commands is to provide the 
following:" should be changed to "The objective of the SCSI Controller 
Commands is to provide the following:"

14) Figure 1 does not "indicates the applicability of a standard to 
the implementation of a given transport."

15) Many of the standards should have the T10 project number replaced 
with their NCITS number or the X3 number depending upon their vintage.

16) Although the Scope notes that "The Small Computer System Interface 
- 2 (ANSI X3.131-1994), is referred to herein as SCSI-2." SCSI-2 is 
not referred to in any of the requirements or descriptions of SCC-2 
and its only usage is in the tiltles of SSA and CAM. I suggest 
deleting the definition and the abbreviation to avoid the false 
impression that SCC-2 includes SCSI-2 related requirements.

17) Exchange was used in SCC presumably largely according to the 
dictionary meaning and did not have a special glossary term. Does the 
definition in the glossary of SCC-2 agree with the usage in SCC?

18) Since the acronym does not fit "3.1.37 SCSI storage array logical 
unit number (LUN_Z):" should be "3.1.37 SCSI storage array logical 
unit number zero (LUN_Z):". But since the Penokie proposal for LUN_Z 
was regretably accepted for all device types, it seems to me the 
definition should be changed to "3.1.37 logical unit number zero 
(LUN_Z):".

19) Does "3.1.51 zero: A false signal value or a false condition of a 
variable." fit the LUN-Z definition?

20) The addition of the abbreviation definition "ITTU I’m talking to 
you" does not seem to be wholey congruent with its only usage in SCC 
and SCC-2 in Table 46 as a component device state.

21) In the early days of SCSI-3 it was decided to not require that 
devices report errors when harmlessly exposed to reserved fields that 
they are willing to ignore. This decision was intended to facilitate 
evolutionary enhancements. The unsupported bit, byte, word, or field 
portion of the requirement "3.3.2 invalid: A keyword used to describe 
an illegal or unsupported bit, byte, word, field or code value. 
Receipt of an invalid bit, byte, word, field or code value shall be 
reported as error." appears contrary to that decision. The definition 
of reserved in SCC-2 is in accordance with the decision.

22) For should, I think "it is strongly recommended" should be "it is 
recommended".

23) I do not think "NOTE 2 - There are types of layers other than 
generic and SACLs, however, they are not covered in this model." is in 
agreement with the definition for covered in the glossary.

24) What is the rightward pointing arrows in Figures 3 and 4? The 
question applies to both left and right in Figures 6-9.

25) In Table 2 OLD and NEW seem incorrect. I suggest ORIGINAL and 
CONVERTED.

26) Under Table 7 "(e.g, fans, cache, controllers, etc.)" does not 
need the "etc." since that is already the meaning of "e.g." which I 
think should have a period and rather than the comma.

27) Does the requirement in 5.2.1.3.2 "The format of a LUN_P or LUN 
field within a command descriptor block or a parameter list when 
addressing
a logical unit is defined in table 6." mean that it is always five 
bits?

28) Under Figure 12, I believe the list should not be enumerated since 
these are not steps but are independant choices.

29) The Scope indicated that SCC-2 defines the commands that a Storage 
Array may impliment. Consequently I am surprised that Table 12 does 
not include any SBC commands.

30) Referring to Table 26, does the LUN_Z LUN Type Code imply that 
LUNs in addition to LUN zero may be a LUN_Z? Does it allow a LUN with 
an address of zero to report a type other than LUN_Z?

31) Is deferred error reporting mandatory for SCC-2 devices? If so is 
this fact made a requirement other than as buried in Note 21?

32) It would be preferable to replace continuously with the real 
requirement rather than having such a complex note as Note 27.

33) Referring to Table 126. The definition for EQSPRD should be made 
active by changing "A EQSPRD bit of one indicates the target shall 
spread user data in a uniform manner over all the peripheral devices 
associated with the volume set being created or modified." to If the 
EQSPRD bit is equal to one the target shall spread user data in a 
uniform manner over all the peripheral devices associated with the 
volume set being created or modified."

34) In Table D.1 and D.3 what does "129 to 512 or 0" mean?






**************************************************************

Comments attached to YesC ballot from Bob Snively of 
Sun Microsystems Computer Co:

1)  This document is now the subject of further review as the
  basis for a profile.  It is likely that technical comments
  and corrections will be required as a result of the
  review, but I feel that it is acceptable to bring those
  comments in during the public review period.  Otherwise,
  I would have to vote no until the profile activity has
  reached a stable checkpoint.


**************************************************************

Comments attached to No ballot from Ralph Weber of 
Symbios Logic Inc.:

Symbios Logic Technical Comments

#1 (T) Sundry places throughout the document
The following additional sense codes do not appear to have definitions in
the ASC/ASCQ database:

     ASSIGN FAILURE OCCURRED
     MULTIPLY ASSIGNED LOGICAL UNIT
     VOLUME SET ASSIGNED

The following additional sense codes do not list array devices as a
possible source in the ASC/ASCQ database:

     OPERATOR SELECTED WRITE PERMIT
     OPERATOR SELECTED WRITE PROTECT

#2 (T) Clause 5.2.1.1 - para 1
The last sentence should be changed from:

"INQUIRY commands sent to LUN_Z shall return a device type of array
controller device."

to

"INQUIRY commands sent to LUN_Z shall return a Standard Inquiry Data with
the LUN_Z bit set to one (See SCSI Primary Commands - 2).  If the LUN_Z
supports only the array controller commands defined, INQUIRY commands sent
to LUN_Z shall return a device type of array controller device.  Otherwise,
INQUIRY commands sent to LUN_Z shall return a device type indicating the
model defining the additional commands supported.  Support for LUN_Z with
a device type other than array controller device is vendor specific."

This change is needed to give implementors the flexibility needed to
address non-negotiable boot-time configuration requirements specified by
various operating system developers.

#3 (T) Clause 6.3.1.8 - Table 45
Change code 05h from 'Spare in use' to 'Obsolete'.

After a spare is exchanged with a failed component that it is covering, it
no longer is a spare.  Therefore, a spare cannot be in the 'Spare in use'
state.  When spare is in use, it is in use it is not a spare.

#4 (T) Clause 6.4.1.1, 6.4.1.3, 6.4.1.4, 6.4.1.5, 6.4.1.7, 6.6.1.1, and
6.8.1.2

Several service actions that currently do not provide for unit attention
conditions to indicate changes in array operating conditions should do so. 
These defining clauses and service actions are:

     6.4.1.1   ADD PERIPHERAL DEVICE/COMPONENT DEVICE
     6.4.1.3   BREAK PERIPHERAL DEVICE/COMPONENT DEVICE
     6.4.1.4   EXCHANGE P_EXTENT
     6.4.1.5   EXCHANGE PERIPHERAL DEVICE/COMPONENT DEVICE
     6.4.1.7   REMOVE PERIPHERAL DEVICE/COMPONENT DEVICE
     6.6.1.1   CONTROL GENERATION OF CHECK DATA {redundancy group}
     6.8.1.2   CONTROL GENERATION OF CHECK DATA {volume set}

It should be noted that one might construe the BREAK PERIPHERAL
DEVICE/COMPONENT DEVICE service action to generate a unit attention
condition based on requirements in clause 5.2.4.  However, a less ambiguous
requirement, stated in clause 6.4.1.3 would be preferable.

#5 (T) Clause 6.7.1.2 - para 5 after table 108
Change:

     "The CAPACITY field indicates the size of the addressed volume set in
     logical blocks."

to:

     "The CAPACITY field indicates the size of the user data region in the
     addressed volume set in logical blocks."

Or, make other changes that clearly indicate whether or not CAPACITY is to
include the check data region.

#6 (T) Clause 6.7.1.2 - table 110 and table 111
       Clause 6.8.1.5 - table 136 and table 137
Does everybody realize that 0% is not expressible as the percentage of
sequential read or write transfers, as these tables are currently written? 
Is it generally acceptable to use 1% as the virtual equivalent of 0%?  Or,
would it be better to use (code value)-1 as the percentage?  Or, should
code 101 be used to indicate 0%?

#7 (T) Clause 6.7.1.3 - para 2 after table 115
       Clause 6.8.1.1 - para 2 after table 123
The following description is sufficiently ambiguous to insure several
totally incompatible implementations:

     "The IDENTIFIER field is defined in the vital products data device
     identification page (83h) (see SCSI-3 Primary Commands Standard)."

Here are two possible less ambiguous replacements for the description that
will produce more consistent, but radically different, implementations.

     "The IDENTIFIER field is the vital products data device identification
     page (83h) as defined in the SCSI-3 Primary Commands Standard."

     "The IDENTIFIER field shall contain exactly one IDENTIFICATION
     DESCRIPTOR field having the format defined in the vital products
     data device identification page (83h) (see SCSI-3 Primary Commands
     Standard)."

Many other specific definitions (and implementations) are possible; however
I suspect that one of the two shown above will be the committee's
preference.

#8 (T) Clause 6.8.1.3 - missing information
This clause should contain a description of the effect, if any, the CONTROL
WRITE OPERATIONS service action has on the WP bit defined in the device-
specific parameter filed in the mode parameter header by both disks and
tapes.

I believe that software will function best if disabling write operations
includes a requirement that the WP bit be set to one and enabling write
operations includes a requirement that the WP bit be set to zero.

One also might simplify the description by saying that setting DISWR to one
has the same effect as setting SWP to one in the control mode page.  But,
that could lead to questions about whether the CONTROL WRITE OPERATIONS
service action is needed since the control mode page SWP bit is available
for all devices that might be configured under an array controller device.

#9 (T) Clause 6.8.1.4 - para 3 after table 126
Change:

     "An IMMED bit of one indicates that the storage array shall return
     status as soon as the command descriptor block has been validated, and
     the entire CREATE/MODIFIY BASIC VOLUME SET parameters list has been
     transferred."

to:

     "An IMMED bit of one indicates that the storage array shall return
     status as soon as the command descriptor block and parameter list have
     been validated."

If this change is not made, the error described in paragraph 4 after table
130 cannot be reported using a CHECK CONDITION when IMMED=1.

#10 (T) Clause 6.8.1.4 - para 1 after table 129
The following statement doesn't make sense:

     "If the CREATE/MODIFY field is 10b the new size of the volume set
     being modified shall be set to the value in the CAPACITY field."

Why should a CREATE/MODIFY field code of 10b be any different from codes of
00b and 11b?  All three codes have the ability to modify the capacity of a
volume set.  Should the reference be to the CONFIGURE field instead of the
CREATE/MODIFY field?

#11 (T) Clause 6.8.1.5 - para 6 after table 131
                         (or para 2 before table 132)
Change:

     "An IMMED bit of one indicates that the storage array shall return
     status as soon as the command descriptor block has been validated, and
     the entire CREATE/MODIFIY STORAGE ARRAY CONFIGURATION parameters list
     has been transferred."

to:

     "An IMMED bit of one indicates that the storage array shall return
     status as soon as the command descriptor block and parameters list
     have been validated."

If this change is not made, the error described in paragraph 4 after table
138 cannot be reported using a CHECK CONDITION when IMMED=1.

#12 (T) Clause 6.8.1.5 - para 1 after table 134
Change:

     "The CAPACITY field contains the size to configure the volume set and
     the redundance group in logical blocks."

to:

     "The CAPACITY field contains the size of the combined user data and
     check data to configure the volume set and the redundance group in
     logical blocks."

Alternatively, any statement that clearly defines the data regions to be
accounted for by the CAPACITY field can be substituted.

#13 (T) Clause 6.8.1.5 - para 1 after table 134
The following statement doesn't make sense:

     "If the CREATE/MODIFY field is 10b the new size of the volume set
     being modified shall be set to the value in the CAPACITY field and
     the new size of the redundancy group shall be set to the value in the
     CAPACITY field."

Why should a CREATE/MODIFY field code of 10b be any different from codes of
00b and 11b?  All three codes have the ability to modify the capacity of a
volume set and redundancy group.  Should the reference be to the CONFIGURE
field instead of the CREATE/MODIFY field?

#14 (T) Clause 6.8.1.5 - table 135 code FFh
Change:

     "The sense key shall be set to ILLEGAL REQUEST, and the additional
     sense code set to LOGICAL UNIT NOT READY, REBUILD IN PROGRESS ..."

to:

     "The sense key shall be set to NOT READY, and the additional sense
     code set to LOGICAL UNIT NOT READY, REBUILD IN PROGRESS ..."

#15 (T) Clause 6.8.1.6 - para 3 after table 139
Change:

     "An IMMED bit value of one indicates that the target shall return
     status as soon as the command descriptor block has been validated,
     and the entire CREATE/MODIFIY VOLUME SET parameters list has been
     transferred."

to:

     "An IMMED bit value of one indicates that the target shall return
     status as soon as the command descriptor block parameters list have
     been validated."

If this change is not made, the error described in paragraph 2 after table
141 cannot be reported using a CHECK CONDITION when IMMED=1.

#16 (T) Clause 6.9.1.1 - para 3 after table 153
Regarding:

     "When the COVERALL bit is set to one the target shall return a COVERED
     LIST LENGTH of zero."

Should there also be a requirement that the COVERED LUN_R LIST LENGTH be
zero?

#17 (T) Clause 6.10.1.2 - para 2 after table 164
Delete the following sentences:

     "If the requested logical unit is not configurable the command shall
     be terminated with a CHECK CONDITION status. The sense key shall be
     set to ILLEGAL REQUEST, and the additional sense code set to LOGICAL
     UNIT NOT CONFIGURED."

These requirements are covered more completely and correctly in table 166.

end Symbios Logic Technical CommentsSymbios Logic Editorial Comments

#18 (E) Clause 6.3.1.5 - para 1 after table 29
After the first sentence: "A report multiple buses (RPTMBUS) bit of zero
indicates only one LUN_P shall be reported for each peripheral device
indicated by the SELECT REPORT field." add the following sentence:

"This has the effect of reporting only one bus identifier and target/lun
for each peripheral device regardless of the number of bus access paths
available to the controller."

The words 'bus identifier' and 'target/lun' should be in small caps, since
they are field names in table 7.

Unlike any of the information currently in the standard, the sentence
proposed for addition ties the function of the bit back to its name, the
report multiple busses bit.

#19 (E) Clause 6.7.1.1 - Note 28
        Clause 6.7.1.2 - Note 29
Change:

     c = capacity of the peripheral device selected in the LUN_P field
     assigned to the selected volume set,

to:

     c = that portion of the capacity from the peripheral device identified
     by the LUN_P field that is assigned to the selected volume set,

The current text causes this reader to believe that c should be equal to
the total capacity of the peripheral device, which I am told is not the
case.

#20 (E) Clause 6.7.1.2 - para 1 after table 108
Change "(table 71)" to "(see table 71)".

#21 (E) Clause 6.7.1.2 - para 8 after table 108
Change:

     "The REBUILD/RECALCULATE PRIORITY field indicates the length of time
     the target takes to do a rebuild operation or a recalculate
     operation."

to:

     "The REBUILD/RECALCULATE PRIORITY field indicates the priority the
     target places on doing a rebuild operation or a recalculate
     operation."

As evidenced in tables 109, and D.2, the REBUILD/RECALCULATE PRIORITY field
does not directly indicate a length of time.  Certainly, not seconds, nor
minutes, nor hours, nor any other units of time are attached to the value
found in the REBUILD/RECALCULATE PRIORITY field.  Rather, as the field name
suggests, the REBUILD/RECALCULATE PRIORITY field indicates a priority
placed on certain operations but the array controller device.

#22 (E) Clause 6.7.1.2 - table 109 code 00h
Change:

     "Shall indicate the target has received no direction on how long
     it will take to do rebuilds nor recalculates or that the associated
     redundancy group is configured as no redundancy."

to:

     "Indicates the target has received no direction on the priority placed
     on doing rebuilds or recalculates or that the associated redundancy
     group is configured as no redundancy."

This follows through on the changes in the definition of the REBUILD/
RECALCULATE PRIORITY field articulated in comment 21 and makes the wording
more consistent with the wording of the other code value descriptions.

#23 (E) Clause 6.7.1.2 - table 109 codes 02h - FEh
Change:

     "An indication of the length of time the target takes to do a rebuild
     operation or a recalculate operation. Generally, larger values
     indicate shorter rebuild and recalculate times."

to:

     "An indication of the priority the target places on doing a rebuild
     operation or a recalculate operation. Generally, larger values
     indicate a greater priority for the rebuild or recalculate operation
     over application client read/write requests and shorter rebuild and
     recalculate times."

#24 (E) Clause 6.7.1.2 - Immediately after table 111
Insert a paragraph describing the VOLUME SET PERIPHERAL DEVICE DESCRIPTOR
LIST LENGTH field.  This field appears in table 108, but its description,
which should appear at this point, is missing.


#25 (E) Clause 6.7.1.2 - para 1 after table 111 (in r3)
Change:

     "The VOLUME SET PERIPHERAL DEVICE DESCRIPTOR contains a list of
     peripheral devices associated with the addressed volume set."

to:

     "The VOLUME SET PERIPHERAL DEVICE DESCRIPTOR(S) are a list of
     peripheral devices associated with the addressed volume set."

This change makes the nomenclature in the text match that found in table
108.

#26 (E) Clause 6.7.1.3 - para 1
In the following sentence:

     "The REPORT UNASSIGNED VOLUME SETS service action (see table 113)
     requests that an identifier for each configured volume set, that does
     not ALREADY have a lun_v assigned within the target be sent to the
     application client."

The capitalization of "ALREADY" does not conform to the convention
described in the first paragraph of clause 3.3.  Perhaps, "ALREADY" could
be made lowercase and bold.

#27 (E) Clause 6.7.1.3 - para 1 after table 113
If the recommendation in comment 26 is accepted, perhaps the words "do not"
in the last sentence could be made bold too.

#28 (E) Clause 6.7.1.4 - para 4 after table 119
Change:

     "The LUN_R field specifies the address of the redundancy group that
     caused the formation of the ps_extent."

to:

     "The LUN_R field specifies the address of the redundancy group whose
     formation created the ps_extent."

Commands from an application client can cause things to happen, as can
sundry hardware events that happen from time to time.  However, I am
uncomfortable with the though that a conceptual entity such as a redundancy
group can cause something.

#29 (E) Clause 6.8.1.1 - para 1
Change "ASSIGN FAILURE OCCURED" to "ASSIGN FAILURE OCCURRED"

#30 (E) Clause 6.8.1.1 - para 1 after table 121
Change; "... and the additional sense code set to MULTIPLLY ASSIGNED
LOGICAL UNIT" to "... and the additional sense code set to MULTIPLY
ASSIGNED LOGICAL UNIT."

#31 (E) Clause 6.8.1.1 - table 122 (and throughout the draft)
The usage of lun_v (all lowercase) is very counter-intuitive.  First, LUN
is an acronym for Logical Unit Number and is capitalized throughout SCSI
standards.  Second, table 1 lists _V as a suffix, but not _v.  Third, the
base address LUN is denoted LUN_Z, not lun_z.  In this table, LBA_V is
used, which makes lun_v even more conspicuous.  (In fact, other uses of
lun_z can be found with a search command, but it was table 122 that
precipitated this comment.)


I recognize that small caps lun_z is a field name.  But, it would seem that
the contents of that field would be a LUN_V (full caps) or a volume set
logical unit number (the latter being my best attempt at transcribing the
wording found in other similar tables, e.g., table 87).  But, lun_v looks 
like a typographical mistake, regardless of the intent behind it.

#32 (E) Clause 6.8.1.2 - para 3 after table 124
In the following sentence:

     "A disable check data bit (DISCHK) of zero indicates the generation of
     check data contained within all of the underlaying redundancy group(s)
     of the selected volume(s) shall be enabled."

Change "... selected volume(s) ..." to "... selected volume set(s) ..." 
Volumes are a SSC and SMC concept.  The SCC entity is a volume set.

#33 (E) Clause 6.8.1.3 - para 1 after table 125
Change:

     "The LUN_V field specifies the address of the volume set that shall
     have write operations enabled or disabled."

to:

     "If the ALLVLU bit is zero, the LUN_V field specifies the address of
     the volume set that shall have write operations enabled or disabled."

#34 (E) Clause 6.8.1.4 - table 128 code 01b
The description of this code contains a missing clause cross reference.

#35 (E) Clause 6.8.1.4 - para 1 after table 125
In the sentence:

     "The CREATE/MODIFY BASIC VOLUME SET parameter list (see table 129)
     contains capacity and a list of BASIC VOLUME SET PERIPHERAL DEVICE
     DESCRIPTORS that are used to create or modify the addressed volume
     set."

Greater generality of the parameter list contents should be suggested by
changing; "... contains capacity and a list ..." to "... contains capacity
information and a list ..."

#36 (E) Clause 6.8.1.4 - para 4 after table 129
                       - para 5 after table 130
Change "... length on bytes ..." to "... length in bytes ..."

#37 (E) Clause 6.8.1.4 - para 6 after table 130
In the sentence:

     "Distribution of the volume sets user data between multiple redundancy
     groups is vender specific."

Volume sets must be possessive.  Change "... the volume sets user data ..."
to "... the volume sets' user data ..."

#38 (E) Clause 6.8.1.5 - para 1
Change:

     "A storage array configuration shall only be created or expanded using
     unassigned p_extents (see 5.2.2.10)."

to:

     "A storage array configuration volume set and redundancy group shall
     only be created or expanded using unassigned p_extents (see
     5.2.2.10)."

A storage array configuration contains much more than just volume sets and
redundancy groups, but those are the only entities that can be created or
expanded by the CREATE/MODIFY STORAGE ARRAY CONFIGURATION service action.

#39 (E) Clause 6.8.1.5 - para 6 after table 134
Change:

     "The REBUILD/RECALCULATE PRIORITY field contains the length of time
     the target should take to do a rebuild operation or a recalculate
     operation."

to:

     "The REBUILD/RECALCULATE PRIORITY field contains the priority the
     target should place on doing a rebuild operation or a recalculate
     operation."

As evidenced in tables 135 and D.2, the REBUILD/RECALCULATE PRIORITY field
does not directly indicate a length of time.  Certainly, not seconds, nor
minutes, nor hours, nor any other units of time are attached to the value
found in the REBUILD/RECALCULATE PRIORITY field.  Rather, as the field name
suggests, the REBUILD/RECALCULATE PRIORITY field indicates a priority
placed on certain operations but the array controller device.

#40 (E) Clause 6.8.1.5 - table 135 code 00h
Change:

     "The application client is providing no direction on the length of
     time for rebuilds or recalculates."

to:

     "The application client is providing no direction regarding the
     priority of rebuilds or recalculates."

This follows through on the changes in the definition of the REBUILD/
RECALCULATE PRIORITY field articulated in comment 39.

#41 (E) Clause 6.8.1.5 - table 135 codes 02h - FEh
Change:

     "An indication of the length of time the target takes to do a rebuild
     operation or a recalculate operation. Generally, larger values
     indicate shorter rebuild and recalculate times."

to:

     "An indication of the priority the target should place on doing a
     rebuild operation or a recalculate operation. Generally, larger values
     indicate a greater priority for the rebuild or recalculate operation
     over application client read/write requests resulting in shorter
     rebuild and recalculate times."

#42 (E) Clause 6.8.1.5 - table 135 note 35
Change:

     "The effect of different rebuild/recalculate times is to increase and
     decrease the performance of a target."

to:

     "The effect of different rebuild/recalculate priorities is to increase
     and decrease the performance of a target."

#43 (E) Clause 6.8.1.6 - para 1
Change:

     "If the modification operation fails to complete successfully the
     command shall be terminated with a CHECK CONDITION status."

to:

     "If the modification operation fails to complete successfully and
     the IMMED bit is zero the command shall be terminated with a CHECK
     CONDITION status."

#44 (E) Clause 6.8.1.6 - para 1
Change:

     "On successful completion of this service action a unit attention
     shall be generated for all initiators except the one that issued the
     service action."

to:

     "On successful completion of this create/modify volume set a unit
     attention shall be generated for all initiators except the one that
     issued the service action."

#45 (E) Clause 6.8.1.7 - para 1
Change:

     "The target shall maintain the deassigned volume set(s) configuration
     and identifier."

to:

     "The target shall maintain the configuration and identifier belonging
     to the deassigned volume set(s)."

As originally worded, "deassigned volume set(s)" is possessive and would
have to be punctuated "deassigned volume set(s)'"  Changing the wording to
eliminate the possessive usage seems like an easier read.

#46 (E) Clause 6.6.1.9 - para 1 after table 146
Change:

     "The START LBA_V field specifies the LBA_V(s) the target shall use to
     begin the recalculation."

to:

     "The START LBA_V field specifies the LBA_V the target shall use to
     begin the recalculation."

LBA_V cannot be plural in this case.

#47 (E) Clause 6.9.1.1 - table 153
        Clause 6.10.1.1 - table 163
Change: "COVERED LIST LENGTH (n-19)"
to:     "COVERED LIST LENGTH (n-m)"

#48 (E) Clause 6.10.1.1 - table 160
Add the SETLUN bit.

The paragraph immediately following table 160 and the paragraph following
table 161 reference and describe a SETLUN bit.  However, there is no SETLUN
bit identified in table 160.

#49 (E) Clause 6.9
Change: "Parameters for direct-access devices"
to:     "Parameters for storage array devices"

#50 (E) Clause 6.9.1.1 - para 1
Change "The LUN mapping page (see table 170) is only required for ..." to
"The LUN mapping page (see table 170) is required only for ..."

#51 (E) Clause 6.9.1.1 - para 5 after table 170
Append all the text in paragraph 5 after table 170 to the end of
paragraph 3 after table 170, with the resulting paragraph reading:

     "The LUN XX MAPPING fields specify the bus/target/LUN of a peripheral
     device or volume set. See table 3 for a definition of the LUN XX
     MAPPING field. A value of zeros in the LUN XX MAPPING field shall
     indicate an undefined bus/target/LUN.  Any attempt by an application
     client to address an undefined bus/target/LUN shall be terminated with
     a CHECK CONDITION status. The sense key shall be set to ILLEGAL
     REQUEST and the additional sense code shall be set to LOGICAL UNIT NOT
     SUPPORTED."

#52 (E) Clause D.0 - para 1 after table D.1
Change:

     "The contents of the REBUILD/RECALCULATE PRIORITY field is used by the
     target to determine the how long the a rebuild or recalculate
     operation will take to complete."

to:

     "The contents of the REBUILD/RECALCULATE PRIORITY field is used by the
     target to determine the relative priority of a rebuild or recalculate
     operation with respect to application client reads and writes."

#53 (E) Clause D.0 - table D.2 code 00h
Change "(default)" to "(action when the application client provides no
direction regarding rebuild priority)".

#54 (E) Clause D.0.1 - para 2
Change:

     "The SCSI storage array will create a volume set with a user data
     mapping as shown in figure D.1:"

to:

     "Following the principles described in this annex, the SCSI storage
     array would create a volume set with a user data mapping as shown in
     figure D.1."

end Symbios Logic Editorial Comments


******************** End of Ballot Report ********************

--
John Lohmeyer                 E-Mail: john.lohmeyer at symbios.com
Symbios Logic Inc.             Voice: 719-533-7560
4420 ArrowsWest Dr.              Fax: 719-533-7036
Colo Spgs, CO 80907-3444    SCSI BBS: 719-533-7950 300--28800 baud

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com




More information about the T10 mailing list