Voting Results on forwarding RBC to public review

John Lohmeyer lohmeyer at ix.netcom.com
Sun Sep 6 12:10:06 PDT 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* John Lohmeyer <lohmeyer at ix.netcom.com>
*
Voting Results on T10 Letter Ballot 98-015r0 on
Forwarding RBC to first public review

Organization                      Name                 S Vote Add'l Info
--------------------------------- -------------------- - ---- ----------
Adaptec, Inc.                     Lawrence J. Lamers   P Yes  
AMP, Inc.                         Chuck Brill          P Yes  
Amphenol Interconnect             Michael Wingard      P Yes  
Ancot Corp.                       Bart Raudebaugh      P Yes  
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  
Compaq Computer Corp.             Rob Elliott          P YesC Cmnts 
Congruent Software, Inc.          Peter Johansson      P Yes  
Dallas Semiconductor                                     DNV  
Data General / Clariion           Greg McSorley        P Yes  
Distributed Processing Tech.      Roger Cummings       P Yes  
Eastman Kodak Co.                 Robert Reisch        P Yes  
ENDL                              I D Allan            P Yes  
Exabyte Corp.                     Tom Jackson          P Yes  
Fujitsu (FCPA)                    Don Vohar            P Yes  
Harting, Inc. of N. America       Marcos Barrionuevo   P Yes  
Hewlett Packard Co.               J. Robert Sims, III  P Yes  
Hitachi Cable Manchester,Inc      Zane Daggett         P Yes  
Hitachi Storage Products          Yang, Anthony        P Yes  
Honda Connectors                  Thomas J Kulesza     P Yes  
IBM Corp.                         George Penokie       P No   Cmnts 
Iomega Corp.                      Tim Bradshaw         P YesC Cmnts 
KnowledgeTek, Inc.                Dennis Moore         P Yes  
Linfinity Micro                   Louis Grantham       P Yes  
LSI Logic Corp.                   Ralph O. Weber       A No   IV Cmnts 
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  
Mylex Corp.                       Brian McKean         P Yes  
Ophidian Designs                  Edward A. Gardner    P No   IV Cmnts 
Philips Electronics               Bill McFerrin        P YesC Cmnts 
QLogic Corp.                      Skip Jones           P No   Cmnts 
Quantum Corp.                     Mark Evans           P YesC Cmnts 
Seagate Technology                                       DNV  
Silicon Systems, Inc.             Dave Guss            P Yes  
Sony Electronics, Inc.            Janek Rebalski       A Yes  
Storage Technology Corp.          Erich Oetting        P Yes  
Sun Microsystems Computer Co      Robert Snively       P No   Cmnts 
SyQuest Technology, Inc.          Pat Mercer           P Yes  
Toshiba America Elec. Comp.       Tokuyuki Totani      P Yes  
UNISYS Corporation                Ken Hallam           P Yes  
Unitrode Corporation              Paul D. Aloisi       P YesC Cmnts 
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:
 41 Yes
  5 No
  0 Abstain

  2 Organization(s) did not vote
 48 Total voting organizations
 10 Ballot(s) included comments

This 2/3rds majority ballot passed.

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

Comments attached to YesC ballot from Rob Elliott of 
Compaq Computer Corp.:


1.   title page  Revision 2 underneath 1240D should be 5
2.   title page  add spaces after each "(303)"
3.   second page The Vice-chair has changed
4.   fourth page change 1997 to 1998
5.   pg i    the first entry "Tables    Page"  should be "Tables"
6.   pg i    why doesn't "Annexes ... iii" show up too?
7.   pg iv   NCITS membership list is out of date; both Compaq and 
        Digital reps listed no longer seem to work here

8.   pg1 last line add "a" - "attached to a Serial Bus"
9.   pg2 2 unitalicize via
10.  pg3 3.1 add "vendor specific" keyword?  It's used in tables
        next to "reserved" but isn't defined.
11.  pg3 3.2.3 unitalicize e.g.
12.  pg6 table 1  remove extra space from "3B 16"
13.  pg7 4.1 first paragraph unitalicize bit in "Increment bit"
    Note: SPC-2 does not italicize bit names.  There seems to
    be a mix of conventions in this document.  I've assumed italics
    are desired for the rest of the comments.
14.  pg7 4.1 replace "FORMAT" with "FORMAT UNIT" everywhere
15.  pg7 4.1 sixth paragraph add of "Sens Key of UNIT ATTENTION"
16.  pg8 4.2 second paragraph italicize "Logic Block Address"
17.  pg8 4.3 third paragraph italicize "Transfer Length"
18.  pg9 4.3 last paragraph italicize "Block Length in Bytes"
19.  pg9 4.3 last paragraph italicize "Logical Block Address"
20.  pg9 4.3.1 italicize "Block Length in Bytes"
21.  pg9 4.3.1 italicize "Logical Block Address"
22.  pg11 table 7 change capitalization to "LOEJ"
23.  pg11 4.4 last paragraph add s and italicize "Power Condition"
24.  pg11 table 8 define M and O, or use Y and O which are used by
    most other tables
25.  pg12 4.4 3rd line remove extra space in "delay ."
26.  pg12 4.4.1 change "SLEEP" to "Sleep" (two places)
27.  pg14 4.6 italicize all bit/field names (6 places)
28.  pg15 4.7 italicize "Logical Block Address"
29.  pg15 4.7 italicize "Verification Length"
30.  pg16 4.8 italicize "Number of Logical Blocks" in note (twice)
31.  pg17 4.8 change "effected" to "affected", or
        change "effected by" to "considering"
32.  pg17 4.8.1 change "can not" to "cannot" (4 places)
33.  pg18 table 13 widen "Removeable" column so e fits on same line
        as "Removabl"
34.  pg18 table 13 remove extra space in "3B 16"
35.  pg19 5.1 first paragraph remove "either"
36.  pg19 table 14 formatting is messed up; bytes 7 and up
        seem broken
37.  pg19 5.1 unitalicize "(AERC)" 
38.  pg19 5.1 italicize "Normal ACA"
39.  pg20 5.2 italicize "Page Format"
40.  pg20 5.2 italicize "Save Pages"
41.  pg20 5.2.1 italicize "SP" (twice)
42.  pg21 5.3 italicize "Disable Block Descriptors"
43.  pg21 5.3 italicize "Page Control" (twice)
44.  pg21 table 17 most tables use Y, N, and O, not spell out
        mandatory, optional, and not supported
45.  pg21 table 17 italicize SP
46.  pg22 5.4 italicize Prevent (3 places)
47.  pg22 5.4 italicize "RMB" and "Mchngr"
48.  pg23 table 20 should all of the descriptions be capitalized?
49.  pg24 table 21 capitalize "Check Condition" (4 places)

50.  pg24 table 31 remove comman "threshold exceeded,"
51.  pg26 5.6.1 change "101  b" to "1012" (pg5 says 2 is the subscript
        used for binary numbers)
52.  pg26 5.6.1 uncapitalize "Unit Attention" (2 times)
53.  pg26 5.6.1 italicize "Parameter List Length"
54.  pg27 A.1.2 change "it's" to "its"
55.  pg28 A.1.2 second to last paragraph move comma after parenthesis
56.  pg29 A.2.3 capitalize and italicize "logic_unit_number"
57.  pg31 B.1 uncapitalize "Initiators"
58.  pg31 table B.1 add periods to each description (2 missing)
59.  pg31 B.1.1.1 remove commas around "that reports the unit
        attention condition"
60.  pg33 B.2.2 remove , from ",." at end
61.  pg33 B.2.3 make "Check Condition" and "Unit Attention" all caps

62.  pg34 B.2.3 add period after "requested"
63.  pg35 table B.5 add periods to each description (2 missing)
64.  pg36 B.2.3.2 change bold bit names to italics (and leave "bit"
        normal) (6 places)
65.  pg37 B.2.3.3 change bold "Time" to italics


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

Comments attached to No ballot from George Penokie of 
IBM Corp.:

Page 1

Note 1, George Penokie, 09/01/98 12:04:39 PM

(E)-Cover Page header - The Rev number states 2 instead of 5 and the date of
the rev looks wrong.

Page 2

Note 2, George Penokie, 09/01/98 12:04:55 PM

(E)-T10 Vice-chair is now George Penokie.

Page 9

Note 3, George Penokie, 09/01/98 12:05:23 PM

(E)-The vice-chair is not George Penokie

Page 10

Note 4, George Penokie, 09/01/98 12:04:22 PM

(E)-The revision history should be removed from the final draft. Which I
assume will be rev 6.

Page 14

Note 5, George Penokie, 09/01/98 01:39:57 PM

(E) - Section 2.1 - 3rd reference; The '(SBC 3)' should be '(SBC)'.

Page 15

Note 6, George Penokie, 09/01/98 01:50:12 PM

(E) section 3 - To be consistent with the other SCSI command set documents
section 3 should be titled 'Definitions, symbols, and abbreviations'.
Section 3.1 should be 'Definations'.
Section 3.2 should be 'Symbols and abbreviations'
Section 3.3 should be 'Keywords'.
Section 3.4 should be 'Conventions'.

Note 7, George Penokie, 09/01/98 01:52:01 PM

(E) - section 3.2 - This section should be titled 'Definations'.

Note 8, George Penokie, 09/01/98 01:56:35 PM

(E)- Section 3.2.3 , 2nd sentence - The statement 'Devices implement one or
more logical units;' does not make sense. 'In devices that implement one or
more logical units;' seems better.

Page 16

Note 9, George Penokie, 09/01/98 01:52:46 PM

(E) - Section 3.3 - This section should be titled 'Symbols and abbreviations'.

Page 17

Note 10, George Penokie, 09/01/98 02:03:06 PM

(E) - Section 3.4.2 - list entery b - Why does this standard use a notion that
is defferenct from every other SCSI standard? The notion for hex is 'h' in all
others and should be the same for this SCSI standard.

Note 11, George Penokie, 09/01/98 02:03:33 PM

(E) - Section 3.4.2 - list entery c - Why does this standard use a notion that
is defferenct from every other SCSI standard? The notion for binary is 'b' in
all others and should be the same for this SCSI standard.

Note 12, George Penokie, 09/01/98 02:16:18 PM

(E) - Why is the no model describing how RBC devices work as there is for
every other command standard?

Page 18

Note 13, George Penokie, 09/01/98 02:07:59 PM

(E) - Table 1 - All the Y should be M for mandatory.

Note 14, George Penokie, 09/02/98 09:25:23 AM

(T) - Table 1 - The 'N' should be changed to 'N/A'. Saying a command 'shall
not be supported' in not a good idea.

Note 15, George Penokie, 09/02/98 09:26:46 AM

(T) - Table 1 - The 'N' should be changed to 'N/A'. Saying a command 'shall
not be supported' in not a good idea. It makes no sense to prohibit a device
|from supporting a command. What you are saying is that any device that
supports it is in violation of the standard.

Note 16, George Penokie, 09/02/98 09:29:55 AM

(E) - Table 1, Note 1 - This Note is not needed. The commands are defined for
this device type therefore they have to be implemented per this standard there
is not need to justify the reasons.

Note 17, George Penokie, 09/02/98 09:31:27 AM

(T) - Section 4.1 - With the FORMAT UNIT name change recommended above the
statement '(removable medium devices only)' is no longer needed.

Note 18, George Penokie, 09/02/98 09:22:07 AM

(E) Table 1 - Format command - This is not the same format command as defined
in other command set standards. It should be renamed to avoid confusion. A
suggestion would be to call it the REMOVABLE MEDIA FORMAT command.

Note 19, George Penokie, 09/02/98 09:28:10 AM

(T) Table 1 footnotes - The N=shall not be supported should be changed to N/A
= Does not apply.


Page 19

Note 20, George Penokie, 09/01/98 02:19:50 PM

(E) - General - Italics are not liked by ANSII editors so don't be surprised
if they disappear during the ANSII edit. I would suggest not using them in the
drafts.

Note 21, George Penokie, 09/02/98 09:38:33 AM

(T) - Section 4.1 - 4th paragraph after table 2 - It states that an Increment
bit of 0 specifies a device report progress in 5 percent or 5 second
increments, depending on the value of the Percent/Time bit. But then it states
that Vendor specific applications may vary the larger percentage increment.
You cannot have it both ways either it is vendor specific or it is not.

Note 22, George Penokie, 09/02/98 09:40:35 AM

(E)-General - None of the standards call up the hex values for status, keys,
ASCs, or ASCQs. There is no reason for this standard to be different than all
the others.

Note 23, George Penokie, 09/02/98 09:45:42 AM

(E) - Section 4.1 - Because there is no model describing how format works. It
is not clear at all how progress can be reported on a command that is in
progress if that command has not ended. In the other command sets the command
is ended as soon as it starts executing and request sense commands are used to
determine progress.

Page 20

Note 24, George Penokie, 09/02/98 09:47:13 AM

(E) - All command tables that contain a transfer length. - Transfer Length
should only be listed one time in the field not twice.

Note 25, George Penokie, 09/02/98 09:57:28 AM

(E) Section 4.2.1 - This is the kind of thing that should be described in a
model section.

Page 23

Note 26, George Penokie, 09/02/98 10:06:40 AM

(E)-Section 4.4 Note under table 6 - This Note assumes an implementation or a
specific protocol and should be removed.

Page 24

Note 27, George Penokie, 09/02/98 10:10:18 AM

(E) Section 4.4.1 - This is the kind of thing that should be described in a
model section.

Page 27

Note 28, George Penokie, 09/02/98 10:14:38 AM

(E) Section 4.7 - table 11 - The name of the field verification length is
repeated twice in the field.

Page 28

Note 29, George Penokie, 09/02/98 10:14:28 AM

(E) Section 4.8 - table 12 - The name of the field logical block size is
repeated twice in the field.

Note 30, George Penokie, 09/02/98 10:15:17 AM

(E) Section 4.8 - table 12 - The name of the field number of logical blocks is
repeated twice in the field.

Page 29

Note 31, George Penokie, 09/02/98 10:19:08 AM

(E) - Section 4.8.1 - This section header is confusing and should be removed.

Page 30

Note 32, George Penokie, 09/02/98 10:27:12 AM

(E) Section 5 - 1st paragraph - The following statement: 'Support for various
bits and fields contained in those commands listed in Table 13 has been
restricted in order to conform to the goal of reduced complexity for RBC
devices. Bit and field restrictions are described in the following clauses.'
should be changed to 'Support for various bits and fields contained in those
commands listed in Table 13 has been restricted as described in the following
clauses.'

Note 33, George Penokie, 09/02/98 10:28:31 AM

(T) - Table 13 - The 'N' should be changed to 'N/A'. Saying a command 'shall
not be supported' in not a good idea. It makes no sense to prohibit a device
|from supporting a command. What you are saying is that any device that
supports it is in violation of the standard.

Note 34, George Penokie, 09/02/98 10:29:13 AM

(T) Table 1 footnotes - The N=shall not be supported should be changed to N/A
= Does not apply.

Page 31

Note 35, George Penokie, 09/02/98 10:31:10 AM

(E) Section 5.1 - table 14 - byte 7 - bit 7 - There is a formatting problem
that makes the '0' not visible in the pdf document.

Note 36, George Penokie, 09/02/98 10:33:32 AM

(E) Section 5.1 - table 14 - byte 3 - bit 7 - The AERC bit can be 0 or 1.
Therefore the '=1' (which implies that it can only be a value of 1) needs to
be removed.

Note 37, George Penokie, 09/02/98 10:36:26 AM

(E)- Section 5.1 - 4th paragraph after table 14 - The 1st and 2nd sentences do

not belong here. Either they are in a model section or they should not be in
the document at all.

Note 38, George Penokie, 09/02/98 10:39:46 AM

(E)- Section 5.1 - 4th paragraph after table 14 - last sentence - This
sentence should be change to. 'The NACA bit shall be set to zero. ACA is not
supported by RBC devices.'

Note 39, George Penokie, 09/02/98 10:41:18 AM

(E)- Section 5.1 - 7th paragraph after table 14 - The statement '...are not
specified in this document.' should be changed to '...are specified in the
SPC-2 standard.'

Page 32

Note 40, George Penokie, 09/02/98 10:44:41 AM

(E) -Section 5.2 - 1st paragraph - 1st sentence; The statement '...parameters
to the mass storage device. Devices...' should be changed to '...parameters to
SCSI devices. SCSI devices...'

Note 41, George Penokie, 09/02/98 10:48:28 AM

(T) Section 5.2 and 5.2.1 - 2nd paragraph under table 15 and 1st paragraph
after section 5.2.1 - There is a conflict here, In one place it is stated that
the SP shall be set to one. Then in another place it states the SP bit is
optional. It cannot be optional and required at the same time.

Page 33

Note 42, George Penokie, 09/02/98 11:34:48 AM

(E) - General - How does an initiator know if the RBC device has fixed or
removable media? There appears to be nothing in the inquiry data.

Note 43, George Penokie, 09/02/98 11:38:34 AM

(T) - Section 5.3 - table 17 - Based on above comments I believe the Current
parameter should be optional for fixed support. The reason given in the Note
in table 17 is not a reason to make it not supported and depending on the
answer to my comment above may not even be correct.

Note 44, George Penokie, 09/02/98 11:39:29 AM

(E) Section 5.3.1 - This section belongs in a model section.

Page 34

Note 45, George Penokie, 09/02/98 01:07:12 PM

(E) Section 5.4 - Title - There is no need to state that the command is
'(removable medium devices only)'. It is obvious by the nature of the command
it only applies to devices that have removable medium.

Page 35

Note 46, George Penokie, 09/02/98 01:13:05 PM

(E) -Section 5.4 - Table 20 - This table should be removed. It contains a list
of key/code/qualifiers that, in many cases, applies to any command. Also,
there is no way this can be a complete list as we are always adding new ASC
and ASCQs and some of those many be a valid response to this command.

Page 36

Note 47, George Penokie, 09/02/98 01:14:07 PM

(E) -Section 5.5 - Table 21 - This table should be removed. It contains a list
of key/code/qualifiers that, in many cases, applies to any command. Also,
there is no way this can be a complete list as we are always adding new ASC
and ASCQs and some of those many be a valid response to this command.

Note 48, George Penokie, 09/02/98 01:19:29 PM

(E) - Section 5.5 - 1st paragraph after table 21. The term SMART is used in
this paragraph and else where. SMART is a marketing term that has
intentionally not been used in SCSI standards. It needs to be replaced with
the term informational exception conditions or IEC to be consistent with the
rest of the SCSI standards.

Note 49, George Penokie, 09/02/98 01:22:00 PM

(T) - Section 5.5 - 1st paragraph after table 21. In previous sections AEN is
optional. But here it is strongly implied it is mandatory because no way is
defined on how to get the IEC information from/to a device that does not
support AEN.

Note 50, George Penokie, 09/02/98 01:23:35 PM

(E) - Section 5.5 - 1st paragraph after table 21. Why is the AEN function
supported by SBP-2 defined in SBP-2 instead of an annex to this standard?

Page 37

Note 51, George Penokie, 09/02/98 01:27:49 PM

(E) -Section 5.5 - Table 22 - This table should be removed. It really only
contains a list of /code/qualifiers that should be defined in the ASC/ASCQ
lists in SPC-2 so that any device type could use them as they could be valid
for device types other than RBC devices. Also, there is no way this can be a
complete list as we are always adding new ASC and ASCQs and some of those many

be a valid response in this case.

Page 39

Note 52, George Penokie, 09/02/98 02:08:04 PM

(E) Annexs - It seems that much of the information in the annexs should be, if
it is not already, part of SBP-2 and not part of this standard.

Page 43

Note 53, George Penokie, 09/02/98 01:35:46 PM

(E)-Section B.1 - 1st paragraph - 2nd sentence - Should be changed to start as
'SPC-2 devices...'.

Note 54, George Penokie, 09/02/98 01:38:21 PM

(E) - Section B.1.1 - Table B.1 the sense key and code values should be
removed from this document.

Note 55, George Penokie, 09/02/98 01:40:35 PM

Section B.1.1 - Table B.1 ; Does this list represent the entire list that will
never change? If not then wording should be added that makes it clear that
this list could be added to in the future.

Page 44

Note 56, George Penokie, 09/02/98 01:43:15 PM

(E) - Section B.1.1.3 - Table 24 the ASC and ASCQ values should be removed
|from this table.

Note 57, George Penokie, 09/02/98 01:44:02 PM

(E) - Section B.1.1.3 - Table 24 - This should be table B.2.

Note 58, George Penokie, 09/02/98 01:44:46 PM

Section B.1.1.3 - Table 24 ; Does this list represent the entire list that
will never change? If not then wording should be added that makes it clear
that this list could be added to in the future.

Note 59, George Penokie, 09/02/98 01:46:08 PM

(E) - Section B.1.1.4 - Per comment above the term SMART needs to be replaced
with IEC.

Note 60, George Penokie, 09/02/98 01:50:18 PM

(E) - Section B.1.1.4 ; The ASC is listed as SMART THRESHOLD EXCEED this is
not correct the 5Dh ASC is FAILURE PREDICTION THRESHOLD EXCEEDED.

Note 61, George Penokie, 09/02/98 01:56:21 PM

(E) - Section B.2 - 1st paragraph - The entire paragraph should be removed as
it add no value to the standard.

Page 45

Note 62, George Penokie, 09/02/98 01:53:26 PM

(E) Section B.2 - last sentence; This sentence should end as follows ' SBP-2
and RBC device that support SBP-2.'.

Note 63, George Penokie, 09/02/98 02:00:01 PM

(E) - Section B.2 - 2nd paragraph - 2nd sentence ; Should be changed from 'The
initiator need only process the status block to determine the cause of the
event.' to 'The initiator may then process the status block to determine the
cause of the event.'.

Note 64, George Penokie, 09/02/98 02:02:38 PM

(E) - Section B.2 - 2nd paragraph - 1st sentence ; The following should be add
to the end of the this sentence; 'simply by building and transmitting a status
block whenever an event occurs.'

Note 65, George Penokie, 09/02/98 02:03:12 PM

(E) - Section B.2 - 2nd paragraph - Last two sentences should be removed.



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

Comments attached to YesC ballot from Tim Bradshaw of 
Iomega Corp.:

1.  Under 4.6 WRITE (10) Command, paragraph 4 currently states: 
"The Logical Block Address field specifies the starting logical block
address on the device for the read data to be accessed."

This should probably read:
"The Logical Block Address field specifies the starting logical block
address on the device for the write data to be accessed."


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

Comments attached to No ballot from Ralph O. Weber of 
LSI Logic Corp.:

Note: It is not possible to represent subscripts in this reporting format. 
So, 02v16 is used to represent 02 subscript 16, 101v2 is used to represent
101 subscript 2 etc.

I have made every effort to provide comments that do not to change the
functional content of RBC.  It is not my goal to argue with the working
group over what should or should not be in RBC.

However, I wish to propose some structural changes in RBC that reduce the
dependence on SBP-2 in the RBC command set, better integrate RBC with other
SCSI-3 command standards and clarify (by indirect reference to the command
models in SPC-2) how someone might build an RBC device that uses FCP as the
transport protocol.  (Note: The requirement that RBC devices use autosense

prohibits RBC devices on SPI or SPI-2.  However, RBC devices could be
implemented on SPI-3 using its Information Unit, a.k.a. packatized,
features.)  These comments start near the end of this response and have
numbers such as 100, 101, etc. to make them easy to identify.  In my
opinion, these comments do not functionally alter the behavior of RBC
devices.  However, these comments are substantial to the extent that they
propose pervasive changes to the RBC draft.

I also have a modest number of specific substantial (technical) and
editorial comments that follow immediately and have numbers less than 100.

***Substantial Comments That May Change the Technical Content of RBC***

LSI#1 (T) Clause 4.1 - 1st para after table 2
Please change from:

"If this bit is set to one, then the device shall report format progress
based upon the status of the Percent/Time bit, and the Increment bit."

to:

"If this bit is set to one and asynchronous event notification is enabled,
then the device shall report format progress based upon the values in the
Percent/Time bit, and the Increment bit."

First, it appears to this reader that reporting is to be accomplishes using
asychronous event notification.  So, that requirement should be stated.

Second (and editorial), if at all possible, I'd like to reserve the word
status for that one byte of information that get returned when command
processing is completed (e.g., home of Good, Check Condition, Reservation
Conflict, etc.).

LSI#2 (T) Clause 4.1 - 4th para after table 2
Regarding, "The Increment bit default value shall be zero."

What does it mean for a bit in a CDB/ORB to have a default value?  The
initiator must set a value in this bit when preparing the CDB/ORB for
transmission to the device.  The initiator software cannot specify a
default behavior in such cases, it must put either a 0 or a 1 in the bit.

Here are a couple of possible meanings that need to be stated more
explicitly, if they apply.  Device support for the one value in the
Increment bit is optional.  Initiators should use the zero value in the
Increment bit to avoid performance penalties associated with the one value.

LSI#3 (T) Clause 4.1 - 5th para after table 2
Change from, "FORMAT progress (when requested by the initiator) ..." to
"FORMAT progress (when reqested by setting the Progress bit to one in the
CDB) ...".  I think this consistently reflects the ideas expressed in
comment 1.

Note: Comment 102 also concerns this sentence.

LSI#4 (T) Clause 4.1 - 9th para after table 2 (last on page 7)
Regarding, "The FORMAT command shall not be interrupted by the initiator."

I would prefer to replace this sentence with:

"While a FORMAT command is in progress, the device shall respond to any
command received with the progress report information described above."

Otherwise, RBC must describe in detail what actions an initiator must avoid
doing so as to not interrupt a FORMAT command, and what will be the
consequences of interrupting a FORMAT command.

LSI#5 (T) Clause 4.4 - Note
The following note should be removed:

"NOTE For RBC devices using SBP-2, the Immed bit has no meaning. There is
no mechanism for the initiator to detect when a device has begun executing
a command."

The statement is not true.  Even for an RBC/SBP-2 device Immed=0 means wait
until the drive has fully spun up before returning status, while Immed=1
means return status as soon as the drive starts spinning up.

LSI#6 (T) Clause 5.5 - 1st paragraph after table 21
Regarding: "The TEST UNIT READY status response shall include SMART
information only after a threshold has been exceeded and Asynchronous Event
Notification has been sent to the initiator."

First, this appears to be requiring that a condition cause multiple reports
(once as an Asynchronous Event Notification and again in response to TEST
UNIT READY commands).  Multiple reports for a single condition would be a
new concept for SCSI devices.

Second, as noted in comment 11, this sentence assumes that Asynchronous

Event Notification will always be enabled.

Would RBC be just as complete and correct if this sentence was deleted?

LSI#7 (T) Clause 5.6 - following table 23
Additional clarification is needed regarding the Mode field.  Two possible
clarification statements that could be added after table 23 are shown
below.  One of these two, or some other statement must be added after
table 23.

"RBC devices shall support only Mode=101v2.  Receipt of any other Mode
value shall result in a status of CHECK CONDITION (02v16) with a sense key
of ILLEGAL REQUEST (05v16)."

or

"RBC devices are required to support Mode=101v2.  Support for all other
modes is optional."

LSI#8 (T) Clause A.1.2
It appears to this reader that the Notify bit must be 1 in any ORBs
that contain SCSI commands.  Failure to set Notify to 1 (or to require
equivalent behavior) gives RBC a behavior other than command-response
(something more like command-silence).  Such behavior would be a dramatic
deviation from what I expect from a SCSI device.

This clause must be enhanced to describe how the SCSI command-response
communications model is achieved by RBC on the SBP-2 transport.

LSI#9 (T) Clause A.4
The status block format at the end of A.4 contains several fields that are
not defined in SBP-2 or elsewhere in RBC, specifically: sfmt, status, v, m,
e, i, sense key, sense code, sense qualifier, and information.  Since these
fields lie in what SBP-2 describes as the "command set-dependent" part of
the status block, their definitions must appear in RBC.

LSI#10 (T) Clause B.1
If I read the description of how Unsolicited Status operates correctly, it
is possible for an initiator to receive an unsolicited status block even if
no commands are outstanding in the device.  Further, an unsolicited status
block will NEVER be associated with a command.  The initiator simply writes
to the Unsolicited_Status_Enable CSR, and the next instant that the device
has unsolicited status, it queues a suitable constructed status block
(src=2) to the initiator.

If this understanding is correct, then the choice of AERC to represent it
is a good one.

However, is it truly desirable that all the status information presented
throughout Annex B be limited to devices that implement SBP-2?  It would
seem preferable to describe Unsolicited Status Operation as an SBP-2 method
for performing Asynchronous Event Reporting for Unit Attention or Deferred
Error information and put the majority of the Annex B information in a
(new) Clause 6 titled "Deferred Error and Unit Attention Information".

Note: This comment may belong with the 1xx comments at the end, but I feel
that the change is useful enough overall to justify including it here.

I have made a first pass proposal regarding the structure and content of
the proposed Clause 6 as comment 200 below.

LSI#11 (T) Clause B.1
B.1 contains no discussion of what a device does if the initiator does not
write to the Unsolicited_Status_Enable CSR, thus not enabling Unsolicited
Status operation.  Does the device fall-back to reporting these conditions
by returning CHECK CONDITION status, as an SBC device would?  Note, the
choice here is not trivial.  Unless this operation is very carefully
specified, there will be no difference between an initiator that never
writes the Unsolicited_Status_Enable CSR after a login and the initiator
that has failed to write the Unsolicited_Status_Enable CSR because it's
busy processing the most recent unsolicited event.

LSI#12 (T) Clause B.2
All the text in this clause should be removed from RBC.  This material does
not include any definitions of how event status notification works in RBC,
rather it serves mostly to denigrate the event reporting mechanisms used by
other command sets and protocols.  Such material is not appropriate to a
standard.

***Substantial (Technical) Comments***

LSI#13 (T) Clause 2.3
Add the following normative reference, which is required if EUI-64 is
normative to RBC as appears to be the case in Annex A.


ANSI/IEEE 394-1995, Extended Unique Identifier, 64-bit

LSI#14 (T) Clause 3.2
Add the following definition:

event field: Byte 0 of the sense data Information field (see {ref sense
data def}) when the EVENT STATUS NOTIFICATION additional sense code is used
(see {ref Event Status Notification clause, 6.3 in comment 200})

LSI#15 (T) Clause 4 - para 1 sentence 2
Regarding, "The SCSI Primary Commands (SPC-2) and Multimedia Commands
(MMC-2) required for RBC device implementation are also shown in Table 1."

I can find no MMC-2 commands referenced in table 1.  Would it be
appropriate to remove "and Multimedia Commands (MMC-2)" from the above
sentence?

LSI#16 (T) Clause 4.3
In the last sentence of the paragraph following table 4, change from:

"The Block Length in Bytes and the Logical Block Address of the last
logical block on the logical unit are returned."

to:

"The Block Length in Bytes and the Last Logical Block Address for the
logical unit are returned."

In table 4, change "Logical Block Address" to "Last Logical Block Address".

Immediately following table 4, add specific definitions for the contents of
the Last Logical Block Address and Block Length in Bytes fields.

Yes I know these are picky changes.  Still, I don't want people looking at
table 5 and thinking that the Logical Block Address field there is the same
thing as the Logical Block Address field in tables 3, 10, and 11.  Also,
since this is a standard, one needs to specify the contents of fields and
not let readers go around making up their own meanings.

LSI#17 (T) Clause 4.8 - 2nd para after table 12
Regarding, "Devices that are unable to prevent media removal (floppy
drives, PCMCIA drives, Flash cards, etc.) shall not support the WCD bit."

Please specify whether the write cache shall be disabled or (gag) enabled
in the case described by the sentence shown above.

LSI#18 (T) Clause 5.1
The Terminate Task has been made obsolete in SPC-2 (see revision 4 or
later).  Therefore, clause 5.1 should make no mention of the TrmTsk bit,
either in table 14 or in the second paragraph following table 14.

LSI#19 (T) Clause 5.2
I am very confused about what is required when on the MODE SELECT(6)
command.  Part of my confusion comes from the organization of the clauses
under clause 5.2.  To my reading, the following organization clarifies
the confusion without changing the intent.  Please consider the following
replacement for all the text following table 15 to the end of clause 5.2.

The Page Format (PF) bit shall be set to one.

The device shall ignore non-changeable parameters in the MODE SELECT
parameter data.

5.2.1 MODE SELECT Restrictions for Devices with Non-Removable Medium

The Save Pages (SP) bit shall be set to one, indicating that the device
shall perform the specified MODE SELECT operation and shall save, to a non-
volatile vendor-specific location, all the changeable pages, including any
sent with the command.

5.2.1 MODE SELECT Restrictions for Devices with Removable Medium

Support of the SP bit is optional for removable medium devices. Such
devices may be unable to save changeable information to a non-volatile
medium. Therefore, if the SP bit is set to one, removable medium devices
may return a status of CHECK CONDITION (02v16), and a sense key of ILLEGAL
REQUEST (05v16).

LSI#20 (T) Clause 5.2
There is one additional change in the text above that should be considered
separately.  Consider clarifying:

"The device shall ignore non-changeable parameters in the MODE SELECT
parameter data."

by adding a second sentence, to whit:

"The device shall ignore non-changeable parameters in the MODE SELECT
parameter data.  This shall not be considered an error."

LSI#21 Clauses B.2.3, B.2.3.1, B.2.3.2, B.2.3.3
As with comment 1, I'd like to reserve the word 'status' for that one byte
of information that comes with command completion.  To that end, please
change 'status' to 'state' as follows:

In tables B.2, B.3, B.6, and B.9, change the contents of byte 1 from

'status' to 'state'.  In the titles for tables B.5, B.8, and B.11, change
|from "- Status field" to "- State field".  In table B.4, change the 02
event field code from "... in the Power Status field" to "... in the Power
State field".  In table B.7, change the 00 event field code from "Media
status is unchanged" to "Media state is unchanged".  In paragraphs 3 and 4
after table B.8, change "... media status notification ..." to "... media
state notification ...".

More sweeping changes could be requested, but I feel that these changes are
sufficient. 

***Editorial Comments***

LSI#22 (E) throughout draft
SPC-2 uses "asynchronous event reporting" to differentiate the general
capability from its specific implementation in parallel SCSI, which is
usually called "asynchronous event notification".  RBC should change to the
more general "asynchronous event reporting" nomenclature.  Note, however,
that this change has NOT been reflected anywhere else in these comments,
several of which deal with AEN.

LSI#23 (E) Points of Contact
Lawrence J. Lamers is no longer T10 vice chair.  The new vice chair is:

George O. Penokie
IBM
Dept. 2B7
3605 Highway 52 N.
Rochester, MN 55901
USA
Telephone: 507-253-5208
Facsimile: 507-253-2880
Email: gop at us.ibm.com

LSI#24 (E) Points of Contact
The T10 FTP site should be changed from:
                     ftp.symbios.com/pub/standards/io/x3t10
to:
                     ftp.symbios.com/pub/standards/io/t10

LSI#25 (E) Points of Contact
The T10 Home page should be changed from: http://www.symbios.com/x3t10
to: http://www.symbios.com/t10/

LSI#26 (E) Clause 1.2 - para 1 sentence 1
Change from:

"The purpose of this document is to provide a command set of reduced
requirements and options from SCSI Block Commands for block devices."

to:

"The purpose of this standard is to provide a command set of reduced
requirements and options from SCSI Block Commands (ANSI NCITS.306:1998)
for block devices."

LSI#27 (E) Clause 1.2 - para 1 last sentence
Change from:

"The initial focus of this command set is rigid disks and removable media
devices attached to Serial Bus and utilizing SBP-2 for command and
control."

to:

"The initial focus of this command set is rigid disks and removable media
devices attached to Serial Bus and utilizing SBP-2 (ANSI NCITS.???:199x) as
a SCSI transport layer."

LSI#28 (E) Clause 2.1 last line in clause
Change "NCITS 306-1998, SCSI-3 Block Commands (SBC-3)" to "NCITS 306-1998,
SCSI-3 Block Commands (SBC)".  There is no SBC-3, yet.

LSI#29 (E) Clause 3.3 abbreviation EUI-64
Change from:

"EUI-64 Extended Unique Identifier, 64-bits"

to:

"EUI-64 Extended Unique Identifier, 64-bits (ANSI/IEEE 394-1995)"

LSI#30 (E) Clause 3.3 abbreviation ORB
Change from:

"ORB Operation request block"

to:

"ORB Operation request block (See SBP-2)"

LSI#31 (E) Clause 3.3 abbreviation RBC
Change from:

"RBC Reduced Block Commands"

to:

"RBC Reduced Block Commands (this standard)"

LSI#32 (E) Tables 3, 10, 11, & 12 (Clauses 4.2, 4.6, 4.7, & 4.8)
Please do not repeat a field name (such as Transfer Length or Logical Block
Size) twice in a multi-byte field.  If necessary, place it on the bottom
line of the field.  Note that in table 12, the Number of Logical Blocks
field can be represented once using the same technique employed for the
Logical Block Address field in table 11.

LSI#33 (E) Clause 4.8.1
Please remove the clause separation for "Removable Medium Device
Parameters".  Alternatively, add a new clause header immediately following
table 12, "4.8.1 Parameters for all RBC Devices", which will change clause
4.8.1 to 4.8.2.

LSI#34 (E) Clause 5.1 table 14
Change "linked" to "Linked" so that the spelling matches that used in the
paragraphs below the table and the spelling used in SPC-2.

LSI#35 (E) Clause 5.1 last paragraph
Change from:

"Support of other bits and fields in the Inquiry command and its associated
pages are not specified in this document."


to:

"Support of other bits and fields in the INQUIRY command and its associated
pages (see SPC-2) are not specified in this standard."

LSI#36 (E) Clause 5.3.1 - bullet b)
Change from:

"If the saved values of the mode parameters are not able to be accessed
|from the non-volatile vendor-specific location, terminate the command with
CHECK CONDITION status and set the sense key to NOT READY;"

to:

"If the saved values of the mode parameters are not able to be accessed
|from the non-volatile vendor-specific location, terminate the command with
CHECK CONDITION (02v16) status and set the sense key to NOT READY (02v16);"

LSI#37 (E) Clause 5.4 bullet b) after table 19
Since a hard reset is not the same as a bus reset in all cases and
protocols, change:

"b) upon a hard (or bus) reset condition."

to:

"b) upon a hard or bus reset condition."

LSI#38 (T) Clause 5.5 - 1st paragraph after table 21
Change from:

"The required Key, ASC, and ASCQ values are described in Table 22."

to:

"The required sense key and ASC/ASCQ values are described in Table 22."

Note: If the ASC/ASCQ related 1xx comments below are not accepted, then
changes will be required in the column headings in tables 21 and 21, and
the change described above would have to be to:

"The required sense key, sense code, and sense qualifier values are
described in Table 22."

LSI#39 (E) Clause 5.6 - table 23
In the mode field, change from "101vb" to "101v2".

LSI#40 (E) Clause B.1 - 1st paragraph
Change from:

"Devices shall notify Initiators of unsolicited status support by setting
the Asynchronous Event Reporting Capability (AERC) bit to one in the
standard data format of the INQUIRY command"

to:

"Devices shall notify initiators of unsolicited status support by setting
the Asynchronous Event Reporting Capability (AERC) bit to one in the
standard data format of the INQUIRY command (see SPC-2)."

Note the change in the capitalization of "initiators", it's easy to miss.

LSI#41 (E) Clause B.1 - 2nd paragraph
Change from:

"Typically, devices default to unsolicited status disabled and only send
unsolicited status following a write to the Unsolicited_Status_Enable CSR.
The Unsolicited_Status_Enable CSR is actually a handshake mechanism and
must be written after every unsolicited status event in order to enable
another such event."

to:

"Devices default to unsolicited status disabled and only send unsolicited
status following a write to the Unsolicited_Status_Enable CSR. The
Unsolicited_Status_Enable CSR is a handshake mechanism and must be written
after every unsolicited status event in order to enable another such
event."

The description of this feature in SBP-2 unambiguously states that this is
the required (and only allowed) behavior.  Therefore, qualifier words such
as "typically" and "actually" are inappropriate.

LSI#42 (E) Clause B.1.1 - 1st paragraph
Change from, "... UNSOLICITED_STATUS_ENABLE register." to,
"... Unsolicited_Status_Enable CSR ."  The latter is the more frequently
used terminology.

Note: This comment can be ignored if comment 10/200 is adopted.  The
proposed changes in comment 200 do not include this text, effectively
deleting it.

LSI#43 (E) Clause B.1.1 - table B.1
In the first row, change: "SMART THRESHOLD EXCEEDED" to either "SMART
threshold exceeded" or "FAILURE PREDICTION THRESHOLD EXCEEDED".  The
latter is the SPC-2 definition of the 5D(hex) ASC, but the former would
be acceptable since it cannot be confused with any SPC-2 defined names
for ASC/ASCQ values, which are all upper case.

See also comment 117.

LSI#44 (E) Clause B.1.1.3 - 1st paragraph
Change from "... CHECK CONDITION (06v16) ..." to "... CHECK CONDITION
(02v16) ...".

LSI#45 (T) Clause B.1.1.4 - 1st paragraph
Change from "... SMART THRESHOLD EXCEEDED ..." to "FAILURE PREDICTION
THRESHOLD EXCEEDED ..." since the latter is the name assigned to ASC
5D(hex) by SPC-2.

See also comment 119.

***Substantial (Technical) Changes That Reduce RBC Command
***Set Dependence on SBP-2


LSI#100 (T) Clause 3.2 and Annex A
Create a new clause in Annex A, A.1 Glossary and move the following
definitions from 3.2 to A.1: command block, login, quadlet, register,
status block, system memory, transaction, unit, unit architecture, and
unit attention.

In clause 3.2, add the following definitions:

additional sense code: A field in the sense data. See {ref sense data
glossary def} and SPC-2.  Equivalent to the sense code field in an SBP-2
status block (see A.5 {ref RBC status block, after renumbering, I think}).

additional sense code qualifier: A field in the sense data. See {ref sense
data glossary def} and SPC-2.  Equivalent to the sense qualifier field in
an SBP-2 status block (see A.5 {ref RBC status block, after renumbering, I
think}).

command descriptor block: A structure up to 16 bytes in length used
to communicate a command from an application client to a device server.

sense data: Data describing an error or exceptional device condition that a
device delivers to an initiator (see SPC-2).

sense key: A field in the sense data. See {ref sense data glossary def} and
SPC-2.  Equivalent to the sense key field in an SBP-2 status block (see A.5
{ref RBC status block, after renumbering, I think}).

status: Response information sent from a device to an initiator upon
completion of each command.

unit attention condition: A state that a logical unit maintains while it
has asynchronous status information to report to one or more initiators.

In clause 3.3 add the following abbreviations:

ASC   Additional Sense Code
ASCQ  Additional Sense Code Qualifier
CDB   Command Descriptor Block

LSI#101 (T) Clause 4 - first sentence after table 1
Change from:

"The Control byte (the last byte of the Command Descriptor Bytes) shall be
set to zero."

to:

"The Control byte (the last byte of the CDB) shall be set to zero."

LSI#102 (T) Clause 4.1 - 5th paragraph after table 2
Change from:

"FORMAT progress (when requested by the initiator) shall be reported with
a status of CHECK CONDITION (02v16), a sense key of NOT READY (02v16), a
sense code of 04v16, and a sense qualifier of 04v16, LOGICAL UNIT NOT
READY, FORMAT IN PROGRESS, and the INFORMATION field shall contain ..."

to:

"FORMAT progress (when requested by the initiator) shall be reported with
a status of CHECK CONDITION (02v16), a sense key of NOT READY (02v16), an
ASC/ASCQ of LOGICAL UNIT NOT READY, FORMAT IN PROGRESS (04v16/04v16), and
the sense data Information field shall contain ..."

Note: Comment 3 also concerns this sentence.

LSI#103 (T) Clause 4.1 - 6th paragraph after table 2
Change from:

"Upon successful completion of the FORMAT command, status information shall
be sent to the initiator with a status field of CHECK CONDITION (02v16), a
Sense Key UNIT ATTENTION (06v16), sense code of EVENT STATUS NOTIFICATION
(38v16), a sense qualifier of MEDIA CLASS EVENT (04v16), and an event field
of NEW MEDIA READY FOR ACCESS (02v16)."

to:

"Upon successful completion of the FORMAT command, the status shall be
CHECK CONDITION (02v16), the sense data shall be set as follows; sense key
UNIT ATTENTION (06v16), ASC/ASCQ of EVENT STATUS NOTIFICATION - MEDIA CLASS
EVENT (38v16/04v16), and an event field of NEW MEDIA READY FOR ACCESS
(02v16)."

Would it also be correct to note that the statement above applies only if
asynchronous event notification is enabled?

LSI#104 (T) Clause 4.1 - 7th paragraph after table 2
Change from:

"If the FORMAT command fails, the device shall return a status block with a
status of CHECK CONDITION (02v16), a sense key of MEDIA ERROR (03v16), a
sense code and sense qualifier of FORMAT COMMAND FAILED (31v16, 01v16)."

to:

"If the FORMAT command fails, the device shall set a status of CHECK
CONDITION (02v16), a sense key of MEDIA ERROR (03v16), and an ASC/ASCQ
of FORMAT COMMAND FAILED (31v16/01v16)."

LSI#105 (T) Clause 4.2.1 - 1st paragraph
Change from:

"Until the removable medium device and media are ready to be accessed, a

READ(10) command shall cause the device to return status of CHECK CONDITION
(02v16), sense key of NOT READY (02v16), and sense code of LOGICAL UNIT NOT
READY (04v16). The sense code qualifier shall reflect the current state of
the device/media."

to:

"Until the removable medium device and media are ready to be accessed, a
READ(10) command shall cause the device to return status of CHECK CONDITION
(02v16), sense key of NOT READY (02v16), and an ASC of LOGICAL UNIT NOT
READY (04v16). The ASCQ shall reflect the current state of the
device/media."

LSI#106 (T) Clause 4.2.1 - 2nd and 3rd paragraphs
Change from:

"When the device becomes ready, and the initiator supports asynchronous
event notification, the device shall send unsolicited status with a status
field of CHECK CONDITION (02v16) a sense key of UNIT ATTENTION (06v16), a
sense code of EVENT STATUS NOTIFICATION (38v16), a sense qualifier of MEDIA
CLASS EVENT (04v16), and an event field of NEW MEDIA READY FOR ACCESS
(02v16).

"If the initiator does not support asynchronous event notification,
alternative methods must be used to determine the state of the device/media
combination. Refer to the GET EVENT STATUS NOTIFICATION command contained
in the MMC-2 specification for a description of those alternative methods."

to:

"When the device becomes ready, a unit attention condition shall be
establish with a sense key of UNIT ATTENTION (06v16), ASC/ASCQ of EVENT
STATUS NOTIFICATION - MEDIA CLASS EVENT (38v16/04v16), and an event field
of NEW MEDIA READY FOR ACCESS (02v16).  When the unit attention condition
is delivered, the status shall be CHECK CONDITION (02v16)."

Note: the current text describes a classic unit attention condition, with
the additional feature that use of asynchronous event notification is used. 
Once the report is described as a unit attention condition (which is what
it is) there is no need to describe ways to report the information in the
absence of asynchronous event notification, those mechanisms are already
covered in SPC-2.

LSI#107 (T) Clause 4.3.1 - 1st paragraph
Change from:

"If the device does not contain media then it shall return status of CHECK
CONDITION (02v16), sense key of NOT READY (02v16), sense code of LOGICAL
UNIT NOT READY (04v16), and sense code qualifier shall reflect the current
state of the device/media."

to:

"If the device does not contain media then it shall return status of CHECK
CONDITION (02v16), sense key of NOT READY (02v16), ASC of LOGICAL UNIT NOT
READY (04v16), and the ASCQ shall reflect the current state of the
device/media."

LSI#108 (T) Clause 4.4 - 2nd to the last paragraph
Change from:

"The device shall terminate any command received that requires more power
than allowed by the START STOP UNIT command's most recent power condition
setting with a status of CHECK CONDITION (02v16), a sense key of ILLEGAL
REQUEST (05v16), and sense code and qualifier of ILLEGAL POWER CONDITION
REQUEST (2Cv16, 05v16)."

to:

"The device shall terminate any command received that requires more power
than allowed by the START STOP UNIT command's most recent power condition
setting with a status of CHECK CONDITION (02v16), a sense key of ILLEGAL
REQUEST (05v16), and ASC/ASCQ of ILLEGAL POWER CONDITION REQUEST
(2Cv16/05v16)."

LSI#109 (T) Clause 4.4.1 - 2nd paragraph
Change from:

"If the removable medium device is in either PREVENT state 01v2 or 11v2
and receives a START STOP UNIT command with the Power Condition field set
to the SLEEP state (5), the device shall respond with status of CHECK
CONDITION (02v16), sense key of ILLEGAL REQUEST (05v16), and sense code
and qualifier of ILLEGAL POWER CONDITION REQUEST (2Cc16, 05v16)."

to:

"If the removable medium device is in either PREVENT state 01v2 or 11v2
and receives a START STOP UNIT command with the Power Condition field set
to the SLEEP state (5), the device shall respond with a status of CHECK
CONDITION (02v16), sense key of ILLEGAL REQUEST (05v16), and an ASC/ASCQ
of ILLEGAL POWER CONDITION REQUEST (2Cc16/05v16)."


LSI#110 (T) Clause 5.1 - 4th paragraph after table 14
Change from:

"Since RBC devices report sense information as part of the STATUS delivery
function, and all tasks are cleared as the result of a device error,
Automatic Contingent Allegiance is not supported. Since the Normal ACA
(NACA) bit is not supported in the Control Byte of the CDB, the NACA bit in
Inquiry data shall be set to zero."

to:

"RBC devices shall report sense data using the autosense method (in the
case of SBP-2 in the status block, see Annex A).  RBC devices shall clear
all tasks as the result of any device error.

"RBC devices shall not support Auto Contingent Allegiance and ignore the
Normal ACA bit in the CDB Control byte.  Therefore, RBC devices shall
return a zero in the NormACA bit in Inquiry data (shown as NACA in table
14)."

LSI#111 (T) Clause 5.4 - table 20
Change headings in the second and third columns from "Sense code" to "ASC"
and from "Sense code Qualifier" to "ASCQ", respectively.  Note: if this
change is not made exactly, it still would be necessary to change the
heading the third column from "Sense code Qualifier" to "Sense qualifier".

LSI#112 (E) Clause 5.5 - table 21
Change third column heading from "ASC, ASCQ" to "ASC/ASCQ".  Likewise,
change ASC/ASCQ numbers from ", " notation to "/" notation.  This is just
to be consistent with the other notation proposed in this comments.

LSI#113 (T) Clause 5.5 - 1st paragraph after table 21
Change from:

"RBC devices shall report SMART status via Asynchronous Event Notification
and the TEST UNIT READY status response."

to:

"RBC devices shall report SMART status via a unit attention condition (with
the associated asynchronous event notification, if enabled) and the TEST
UNIT READY status response."

LSI#114 (T) Clause 5.6.1 - 1st paragraph
Change from:

"When the download microcode and save command has completed successfully
the device shall generate a Unit Attention status block and send it, via
unsolicited status if enabled, to all initiators except the one that issued
the WRITE BUFFER command. When reporting the Unit Attention condition, the
device shall set the sense code and qualifier to MICROCODE HAS BEEN CHANGED
(3Fv16 , 01v16)."

to:

"When the download microcode and save command has completed successfully
the device shall generate a unit attention condition and send it, via
asynchronous event notification if enabled, to all initiators except the
one that issued the WRITE BUFFER command. When reporting the unit attention
condition, the device shall set the ASC/ASCQ to MICROCODE HAS BEEN CHANGED
(3Fv16/01v16)."

Note: the following minimal changes are required even if the "ASC/ASCQ" and
"unit attention condition" changes are not made.

"When the download microcode and save command has completed successfully
the device shall generate a unit attention status block and send it, via
unsolicited status if enabled, to all initiators except the one that issued
the WRITE BUFFER command. When reporting the unit attention condition, the
device shall set the sense code and qualifier to MICROCODE HAS BEEN CHANGED
(3Fv16 , 01v16)."

LSI#115 (T) Clause A.1.2 - after 1st paragraph
Insert the following paragraph after the first paragraph in the A.1.2.

"A SCSI command CDB is placed in command_block field of an SBP-2 command
ORB.  The SCSI status for the command is found in the status field of an
SBP-2 status block with resp field of REQUEST COMPLETE (0v16).  The six bit
status block status value is converted to an eight bit SCSI status by
adding two zero bits in the most significant bit positions of the byte."

LSI#116 (T) Clause A.4
This clause should contain a table showing how the fields in the SBP-2
status block can be used to construct the fields in SPC-2 sense data. 
At prototype for such a table is included here but is incomplete owing
to missing information in RBC r5.

Sense data field                    Status block usage
----------------------------------------------------------------------

Valid                               equals the contents of the v field
Response code                       ???
Segment number                      zero
Filemark                            equals the contents of the f field
EOM                                 equals the contents of the e field
ILI                                 equals the contents of the i field
Sense key                           equals the contents of the sense key
                                    field
Information                         equals the contents of the information
                                    field
Additional sense length             11(decimal) 0B(hex)
Command-specific information        zero
Additional sense code               equals the contents of the sense code
                                    field
Additional sense code qualifier     equals the contents of the sense
                                    qualifier field
Field replaceable unit code         zero
SKSV & Sense-key specific           zero

The prototype table above needs to be checked for accuracy and the ???
descriptions need to be added.

LSI#117 (T) Clause B.1.1 - Table B.1
Change the second column heading from "Sense code" to "ASC".

See also comment 43.

LSI#118 (T) Clause B.1.1.3 - Table 24
Change the first and second column headings from "Sense code" to "ASC" and
|from "Sense code Qualifier" to "ASCQ", respectively.  Note: if this change
is not made exactly, it still would be necessary to change the heading the
second column from "Sense code Qualifier" to "Sense qualifier".

LSI#119 (T) Clause B.1.1.4 - 1st paragraph
Change from:

"The status field shall be set to CHECK CONDITION (02v16), the sense key
to RECOVERED ERROR (01v16), the sense code to SMART THRESHOLD EXCEEDED
(5Dv16), and the sense qualifier to the SMART threshold descriptor value."

to:

"The status value shall be set to CHECK CONDITION (02v16), the sense key
to RECOVERED ERROR (01v16), the ASC to SMART THRESHOLD EXCEEDED (5Dv16),
and the ASCQ to the SMART threshold descriptor value."

See also comment 45.

LSI#120 (T) Clause B.2.2 - 1st list item
Change from:

"When ready, the device shall issue unsolicited status with a status field
of CHECK CONDITION (02v16), a sense key of UNIT ATTENTION (06v16) a sense
code of EVENT STATUS NOTIFICATION (38v16), a sense code qualifier of MEDIA
CLASS EVENT (04v16), and an event field of NEW MEDIA READY FOR ACCESS
(02v16)."

to:

"When ready, the device shall issue an event status notification with a
status value of CHECK CONDITION (02v16), a sense key of UNIT ATTENTION
(06v16) a ASC of EVENT STATUS NOTIFICATION (38v16), a ASCQ of MEDIA CLASS
EVENT (04v16), and an event field of NEW MEDIA READY FOR ACCESS (02v16)."

Note the use of "status value" instead of "status field".

LSI#121 (T) Clause B.2.2 - 4th list item
Change from:

"If a START STOP UNIT command is issued, the device shall return
unsolicited status with a status field of (02v16), a sense key of UNIT
ATTENTION (06v16) and sense code of EVENT STATUS NOTIFICATION (38v16), a
sense qualifier of POWER MANAGEMENT CLASS EVENT (02v16), and an Event field
of DEVICE SUCCESSFULLY CHANGED POWER STATES (01v16),."

to:

"If a START STOP UNIT command is issued, the device shall return event
status notification with a status field of (02v16), a sense key of UNIT
ATTENTION (06v16) and ASC of EVENT STATUS NOTIFICATION (38v16), a ASCQ of
POWER MANAGEMENT CLASS EVENT (02v16), and an event field of DEVICE
SUCCESSFULLY CHANGED POWER STATES (01v16)."

Note the use of "status value" instead of "status field".

LSI#200 (T) Proposal for Clause 6 (see comment 10)

6 Deferred Error and Unit Attention Information

6.1 Deferred error conditions

{this text is mostly from B.1.1.2}

Deferred errors may be produced as a result of cached data management or
support of the Immediate function in commands such as START STOP UNIT or
FORMAT.  Table xx shows the sense key and ASC values that RBC devices may
return as deferred errors.


{reproduce table B.1 with only the first three rows}
{note: comments 43 and 117 concern table B.1 as it is used here}

When asynchronous event notification is enabled (see A.6), RBC devices
shall use it to report deferred errors.

6.1.1 SMART notification

{this text is mostly from B.1.1.4}
{comments 45 and 119 have been applied to this text}

RBC devices shall notify the initiator when a SMART threshold is exceeded
via a deferred error report (preferably as an asynchronous event
notification, if enabled). The status value shall be set to CHECK CONDITION
(02v16), the sense key to RECOVERED ERROR (01v16), the ASC to FAILURE
PREDICTION THRESHOLD EXCEEDED (5Dv16), and the ASCQ to the SMART threshold
descriptor value. Refer to Table 22 for SMART ASCQ values.

6.2 Unit attention conditions

{this text is mostly from B.1.1.1}

When initiators must perform a login function to access a device, a unit
attention condition shall persist for a logged-in initiator until a) an
asynchronous event notification reports the unit attention condition or
b) the initiator's login becomes invalid or is released.  When there is
no transport login function, a unit attention condition shall persist for
a initiator until a) an asynchronous event notification reports the unit
attention condition or b) a hard or bus reset occurs.

Logical units may queue unit attention conditions; more than one unit
attention condition may exist at the same time.

Table xx shows the sense key and ASC values that RBC devices may return for
unit attention conditions.

{reproduce table B.1 with only the last four rows}
{move the power status row to before the event status row}
{note: comment 117 concerns table B.1 as it is used here}

When asynchronous event notification is enabled (see A.6), RBC devices
shall use it to report unit attention conditions.

6.2.1 Power state change notification

{this text is mostly from B.1.1.3 1st paragraph}
{but, it has been changed slightly to be less SBP-2 specific}
{note: the change in comment 44 has been included here}

RBC devices shall notify an initiator of the intent to change power states
via a unit attention condition (preferably as an asynchronous event
notification, if enabled). The status value shall be set to CHECK CONDITION
(02v16), the sense key to UNIT ATTENTION (06v16), and the sense code to
POWER CONDITION CHANGE NOTIFICATION (5Ev16). The sense qualifier shall be
set to the value of the new power state plus 40v16 as shown in table xx.

{reproduce the remainder of B.1.1.3 unchanged, here}

6.3 Event status notification

{the following is new text, cloned from 6.2.1}

RBC devices shall notify an initiator of media, power management, and
device busy events via a unit attention condition (preferably as an
asynchronous event notification, if enabled).

6.3.1 Removable medium device initial response

{this is from B.2.2}
{comments 120 and 121 have been applied to the following text}

For removable devices the following sequence must occur at power on:

  - When ready, the device shall issue an event status notification with a
    status value of CHECK CONDITION (02v16), a sense key of UNIT ATTENTION
    (06v16) a ASC of EVENT STATUS NOTIFICATION (38v16), a ASCQ of MEDIA
    CLASS EVENT (04v16), and an event field of NEW MEDIA READY FOR ACCESS
    (02v16).

  - The initiator shall issue a MODE SENSE command followed by a READ
    CAPACITY command.

  - The initiator may issue a START STOP UNIT command with Power Condition
    values of one, two or three. If this command is not issued, the device
    shall assume Standby state (Power Condition = 3).

  - If a START STOP UNIT command is issued, the device shall return event
    status notification with a status field of (02v16), a sense key of UNIT
    ATTENTION (06v16) and ASC of EVENT STATUS NOTIFICATION (38v16), a ASCQ
    of POWER MANAGEMENT CLASS EVENT (02v16), and an event field of DEVICE
    SUCCESSFULLY CHANGED POWER STATES (01v16).

6.3.2 Event status sense information


{this is from B.2.3}
{There's rather heavy, but not substantive rewording here}

For the event status notification unit attention condition, the following
sense data shall be used.  The status value shall be CHECK CONDITION
(02v16), the sense key shall be UNIT ATTENTION (06v16), and the ASC shall
be EVENT STATUS NOTIFICATION (38v16).  The ASCQ shall be one of the values
shown in table xx.

ASCQ   Name               Description
-------------------------------------------------------------------------
02v16  POWER MANAGEMENT   indicates that a Power Management event has
       CLASS EVENT        occurred or is impending
04v16  MEDIA CLASS EVENT  indicates that a Media Class event has occurred
06v16  DEVICE BUSY        indicates that a Device Busy Class event has
       CLASS EVENT        occurred

For the sense key, ASC, and ASCQ values described above, the contents of
the sense data Information field further describe the event status.  The
general format of the sense data Information field is shown in table xx.

{reproduce table B.2 here}

The following clauses provide specific sense data Information field
definitions for each of the ASCQ values shown in table xx {the new table
sketch-out above}.

{reproduce B.2.3.1 as 6.3.2.1 with changes from comment 21}

{reproduce B.2.3.2 as 6.3.2.2 with changes from comment 21}

{reproduce B.2.3.3 as 6.3.2.3 with changes from comment 21}


{{{
Only a small volume of text from the former Annex B that is left after
Clause 6 is created.  Therefore, it seems sensible to append the remaining
text on Annex A, as follows.
}}}

A.6 Unsolicited Status Operation

{reproduce all the text from B.1 here.}
{note: comments 11, 40, and 41 propose needed changes in this text}

When enabled, RBC devices shall use unsolicited status to report unit
attention conditions and deferred errors (see clause 6).

A.7 Event status retention

{this text is mostly from B.2.1}

RBC devices using SBP-2 shall retain event status for a logged in initiator
if a bus reset occurs after the event has occurred but prior to the unit
attention information being sent to the initiator. If the initiator fails
to reconnect to the device within the reconnect time-out period (see
SBP-2), the retained event status information shall be discarded.

If the initiator successfully reconnects, it shall write to the
Unsolicited_Status_Enable register. The device shall transfer the retained
event status, via unsolicited status. Once the event status is
successfully transferred to the initiator, the device shall discard the
retained event status.

{{{
Note: The contents of B.2 have not been included anywhere in the comment
200 proposal, effectively deleting them from RBC.  See comment 12.
}}}


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

Comments attached to No ballot from Edward A. Gardner of 
Ophidian Designs:

I have six main comments that span substantial portions of the document:

A. When RBC was broken out as a project separate from SBP-2, the stated
rationale (as I remember it) was that RBC could and should be independent of
SBP-2 or any other SCSI protocol.  Unfortunately this document is only part
way there.  In some places it is specific to SBP-2 and 1394a, in others it
has been SAM-ized (pardon the expression).  The result is inconsistent and
needs to be fixed.  Either go back and make it totally SBP-2/1394a dependent
(with no formal relationship to the rest of SCSI), or adopt SAM or SAM-2
terminology throughout.  I advocate the latter; I believe it is an entirely
editorial task, albeit a rather large editorial task.

B. This needs a section describing the device model.  It suffers from the
same problem as SCSI-2, namely that bits and pieces of device model are
spread throughout the command descriptions, and many parts implicit and left
unstated.  I suggest you start with SBC clause 5.1, then edit it to get rid
of everything that is unnecessary or inappropriate.  Remove the description
of power conditions from the START STOP UNIT command and make it a separate

clause of the device model.  Probably do the same with the prevent flags,
removing its description from the PREVENT/ALLOW MEDIUM REMOVAL command to a
separate clause.

C. Similarly, much of the information in annex B should be moved to be body
of the document, either part of the device model or adjacent to it.  You
need a different name.  "Status" has a formal meaning in SCSI, and there's
no such thing as "unsolicited status".  I suggest you call this simply
"Event Information", referring to the value passed in the fourth quadlet of
an SBP-2 status block.  You need one or more clauses defining the contents
of the Event Information (tables B-2 through B-11).  You need one clause
defining how Event Information is passed within normal SCSI sense data (see
table 61, page 75, of SPC-r11a, I suggest using either Command-specific
information (bytes 8-11) or Additional sense bytes (bytes 18-n)).  You need
another clause, probably in Annex A, defining the special case for SBP-2,
where Event Information is passed in the SBP-2 status block.

D. It seemed to me that you had very nearly included or rewrote all relevant
portions of the SPC-2 command descriptions in clause 5.  Having 90% of a
command description here and 10% in SPC will, in my opinion, only lead to
confusion.  Consider including the entire command description here and
deleting the reference to SPC.

E.  This comment assumes you continue to reference SPC.  I found your
treatment of SPC commands in clause 5, listing only fields that were
restricted, quite confusing.  For all SPC commands in clause 5, please
exactly duplicate the CDB format or table from SPC or SPC-2.  In the text
following the CDB table, list all fields whose interpretation is unchanged
|from SPC.  Follow that with the text you have now.


F. The distinctions between fixed and removable media devices seem somewhat
arbitrary.  Many of the distinctions appear to add unnecessary special cases
and complexity to devices and/or host software.  Consider the following
thought experiment.  Take a removable device, install some media, then seal
it shut (e.g. glue the door closed or install it in an internal device bay).
>From a user's perspective, this is equivalent to a fixed media device.  From
the device's perspective, it shouldn't have to change any of its firmware or
command support.  Yet RBC does require changes between fixed and removable
devices.  Requiring changes serves no purpose, it merely complicates things,
such changes should be optional.


Specific comments:

1. Page 1, clause 1.2, delete last sentence ("The initial focus...").
Whatever may have motivated development of this standard, the standard is
what it is.  It is either
restricted to SBP-2 or potentially usable on other transports.

2. Page 2, reference to SBC-3.  This should refer to SBC, not SBC-3.  I
could find no references to SBC in the document.  Is this needed?

3. Page 2, references.  There are normative references to several standards
that in turn normatively reference SAM.  Including a direct reference to SAM
or SAM-2 will reduce confusion.

4. Pages 3-4, glossary.  I don't believe the following terms are used
anywhere except in the informative SBP-2 Storage Model (clause A.1).  And if
I missed a reference outside of Annex A, it should be changed or reworded as
these terms are 1394 / SBP-2 specific.  As such I think they can and should
be deleted from the glossary:  "register", system memory", "transaction",
"unit", "unit architecture"

5. Page 3, glossary.  "command block" should be replace with "Command
Descriptor Block" and that the definition from SPC is correct without
alteration.  True, that data structure is conveyed in a specific field
within an SBP-2 ORB, but it is conveyed by other means in other SCSI
protocols.

6. Page 3, glossary.  A "logical unit" is part of a SCSI target, not a "unit
architecture".

7. Page 3, glossary.  "login" needs to be qualified as applicable to SBP-2.

8. Page 4, glossary.  "status block" needs to be qualified as applicable to

SBP-2.  I would amend its definition to state that it is used to communicate
SCSI status and sense information to an initiator.  The statement that it is
used when an ORB has completed is incorrect, since it is used also for
unsolicited status/sense.

9. Page 4, glossary.  "unit attention" would be better defined identically
as in SPC.

10. Page 6, clause 4.  Table 1 lists no commands from MMC-2.  Why is that
mentioned in the text preceding the table?

11. Page 6, Table 1.  Comparing this table with the corresponding one in SPC
(Table 5, spc-r11a page 18) is instructive.  Two commands that are mandatory
in SPC are omitted here, REQUEST SENSE and SEND DIAGNOSTIC (used to invoke
device internal self-test).  These both provide functions that are necessary
for usable devices, yet are better performed by other mechanisms (not SCSI
commands) with 1394 / SBP-2.  These two commands are necessary if RBC is to

be used with any protocol other than SBP-2.  Please add those two commands
to this table, listing them as optional for SBP-2 devices, mandatory for all
other protocols.

12. Page 6, Table 1, and clause 4.1.  There is no good reason to prohibit
FORMAT UNIT with fixed media devices.  Many fixed media devices allow their
size to be altered to that they will appear, to host software, identical to
an older device.  The need for this is unlikely to go away.  The preferred
way to do this is with the FORMAT UNIT command, as the alternative would be
vendor unique.  FORMAT UNIT should be optional for fixed media as well as
removable.  See also comment on the mode page.

13. Page 6, Table 1, and clause 5.4.  There is no benefit to prohibiting
PREVENT/ALLOW MEDIUM REMOVAL for fixed media devices.  It is simpler to say
that the command shall be ignored (treated as a no-op).  See next comment.

14.  Page 6, Table 1.  Much as I regret complicating an ideally simple
command profile, it appears that persistent reservations are a de facto
requirement for multi-initiator devices.  I think you need to add those
command to this table, perhaps with a note recommending their implementation
by multi-initiator devices and saying they should be ignored by
single-initiator devices.

15. Page 6, Table 1.  What does it mean to say that a command "shall not be
supported"?  If such a command is issued to a device, what shall the device
do in response?  Since "shall" is used, the behavior is mandatory, yet it is
not specified anywhere in this document.  I recommend not using this
notation, since it calls into question what it means.  Adopting the two
preceding comments would accomplish this.

16. Page 6, clause 4.1.  If the statement that "This command is not defined
for..." is
taken literally, it implies that behavior when this command is received is
not defined and therefore vendor unique.  I doubt that is what is intended.
My recommendation (see above comments) is that this command be made optional
(and therefore well defined) for all devices.

17. Page 7, third paragraph, delete "The Percent/Time bit default value
shall be one".  This bit is provided in each and every FORMAT UNIT command,
therefore the idea of a default value is meaningless.

18. Page 7, paragraphs 5 and 6.  One of these refers to an "INFORMATION
field", the other to an "event field", I believe both are intended to be the
same.  Please reword these to refer to what I called "Event Information" in
general comment C above.

19. Page 7, paragraph 8, "is corrected (media replaced)".  This implies that
media replacement is the only way to correct the problem.  Either remove the
parenthetical phrase or make it clear that it is an example.

20. Page 7, paragraphs 6, 8 and 9.  Each of these uses "shall" to describe
initiator behavior ("shall respond" or "shall not be interrupted").  I am
uncomfortable with this wording, as it too often leads to unwarranted
assumptions.  For example, "the initiator shall issue a MODE SENSE command"
may lead to device firmware that doesn't bother to check the operation code

of the next command, since it's known to be MODE SENSE.  Yes, that's

obviously stupid design, but I've seen it occur in the past.  I recommend
replacing these uses of "shall" with either "should" or "will typically".
Alternately, spell out the possible consequences of the initiator not
complying with the "shall" (this might be particularly appropriate for
interrupting a FORMAT UNIT command).

21. All of the CDBs show "Control = 00".  The meaning of this is not
obvious.  If this is meant as a restriction or requirement, there needs to
be some text saying so (probably in the device model section).

22. Pages 8-9, clause 4.2.1.  Placing this matter here implies that it only
applies to READ.  That is, when new media has installed in a device, the
initiator may not READ it (per this section), but is allowed to WRITE it
(since no similar text appears there).  This material needs to be moved to
the device model section and made applicable to all data access commands.
Also, this appears to be merely redefining the unit attention condition and
reporting mechanisms already defined elsewhere (see SAM-2).  For what
purpose?  The only differences I see are that SAM-2 seems to be a much
clearer and more complete definition.

23. Page 9-10, clauses 4.3 and 4.3.1.  The first sentence below the CDB
requires returning read capacity data even when returning a check condition.
Many fixed media devices support varying formats, not just removable media
devices.  4.3.1 prohibits returning capacity information when no media is in
the device, even if the device supports only one media format.  I recommend
deleting 4.3.1 and replacing the text of 4.3 below the CDB with:  "READ
CAPACITY data (see Table 5) shall be returned to the initiator prior to
sending GOOD status for the command.  The Block Length in Bytes and the
Logical Block Address of the last logical block of the media contained in
the device shall be returned.  If the device does not contain media and
cannot determine the values to return by other means, then it shall return
status of CHECK CONDITION, sense key of NOT READY, sense code of LOGICAL
UNIT NOT READY and the sense code qualifier shall reflect the current state
of the device or media."

24. Page 11, clause 4.4, note at top of page 11.  This note seems completely
wrong or irrelevant.  The Immed bit specifies when the target shall return
status.  The ability of the initiator to detect target actions is
irrelevant.

25. Page 11, third paragraph, Load/Eject bit.  This paragraph uses
"ejecting" and "unloaded" as what I suspect are synonyms.  Discard one term
and use the other consistently.

26. Page 11, fourth paragraph.  The parenthetical phrase, "media shall not
be accessed by the initiator", places a restriction on the initiator, which
is pointless.  If the purpose of an initiator stopping a unit is to make
issuing device access commands a protocol violation, the initiator could
more simply refrain from issuing access commands.  I expect you mean to say
that this function renders the logical unit inaccessible for data transfers.

27. Page 12, definition of Sleep (state 5), second sentence, "A device reset
shall be required before access...".  This sentence prohibits a device from

responding until a device reset occurs.  I don't think this is what you
intend.  For example, if a user loads new media, device access is still
prohibited until after a device reset.  While an initiator must issue a
device reset to ensure access, the proper wording is "A device reset may be
required...".

28. Page 12, last paragraph.  This paragraph makes no sense.  When a device
is in sleep state, the operating system has no control over it.  It must
reset the device, removing it from sleep state, before doing anything.  Thus
saying that the operating system "shall allow" media ejection makes no
sense.  Perhaps this is a requirement on the device rather than the
operating system?

29. Page 14, first paragraph after CDB.  The wording of this paragraph

overrides or ignores the setting of the Write Cache Disable mode page flag.
That is, when FUA = 0, this paragraph specifies write caching is allowed
regardless of the state of WCD.  I don't think this is what is desired.

30. Page 14, third paragraph (the note) after CDB.  What is meant by "FUA
support"?  If a device does not support write caching, is it allowed to
reject as illegal a write command with FUA=0?  A write command with FUA=1?

31. Page 14, fourth paragraph after CDB (after the note).  "read data"?

32. Page 16, first paragraph (before CDB), last sentence.  What does the
presence or absence of the notation (c) mean?  This does not define it
adequately.  A mode page parameter might be (1) required to be not
changeable for all RBC devices, (2) either changeable or not changeable at
the device's option, or (3) required to be changeable for all RBC devices.
This paragraph says nothing about fields that do not have the (c) notation,
something explicit should be said to avoid confusion.  For fields with the
(c) notation, either (2) or (3) are plausible interpretations from the
existing wordings.  Also, note that the wording here implies that changeable
parameters may also be saved, whereas elsewhere there seems to be an
implication that removable media devices need not save changeable
parameters.

33. Page 16, Table 12.  Why is the logical block size not listed as
changeable?  Many hard drives support this and significant markets require
this.  While many devices
might choose to support only a single block size, others might support
several.

34. Page 16, Table 12.  The Read, Write, Format and Lock bits should be
changeable.

35. Page 16, first two paragraphs following Table 12.  The last sentence of
the first paragraph and the second paragraph appear to specify the same
thing, but with conflicting terminology.  Please make these consistent
and/or eliminate one.

36. Page 16, last paragraph.  The Power/Performance field does not specify a
"level of control", that comes from the Power Conditions field of the
Start/Stop Unit command.  Rather , the Power/Performance field specified the
guidelines or tradeoffs the device shall use when Power Conditions specify
Device Control.

37. Pages 16-17, Read, Write, Format and Lock flags.  These flags are
specified backwards, their polarity should be reversed.  They should also be
allowed (as options) for fixed media devices.  As currently specified, fixed

media devices "shall set these bytes [sic] to zero".  This zero setting
allows full access to the device.  The same zero setting allows no access
whatsoever to removable media devices.  That conflict is idiotic.  The same
default setting (I suggest zero) should allow full access to any device.

38. Page 19, formatting of RELADR bit in Table 14.

39. Page 19, second paragraph after CDB.  This paragraph discusses
asynchronous event reporting as an option, which appears to contradict the
table specifying AERC = 1.

40. Page 19, fourth paragraph after CDB.  The first clause (up to the comma)
of the first sentence is both irrelevant and wrong.  SBP-2 devices report
sense with status, but RBC devices on other protocols might not.  But sense
reporting is irrelevant to ACA support.

41. Page 20.  The second paragraph after Table 15 says SP shall be one, the
first paragraph of 5.2.1 says the SP bit is optional.  This conflict needs
to be reconciled.

42. Page 29, clause A.2.1.  Text describes entry key 3A, diagram shows key
39.

43. Page 29, clauses A.2.1 and A.2.2.  Were are "Command_set" and
"Command_set_revision" specified?

44. Page 29, clause A.3.  Delete first paragraph, irrelevant to non-SB-2
devices.



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

Comments attached to YesC ballot from Bill McFerrin of 
Philips Electronics:

1. Add a new value to the Event Field of Table B.10:
   0x02 - Progress of an immediate command.

2. Text below Table B.9:

   - Replace: The Time field is the predicted amount of time remaining for 

the device to become not busy, in units of 100 ms.

   - With: For events other than those with a value of 0x02, the Time field 
is the predicted amount of time remaining for the device to become not busy, 
in units of 100 ms.  For events with a value of 0x02, the Time (LSB) field 
is the predicted percent completion of a previously issued immediate command.
The frequency of reporting is unique for each command.

The motivation for adding this change is to provide a means to report 
progress of an immediate command without using REQUEST SENSE. While the 
change is not required for RBC, it is required for other device types that 
have legacy commands that cannot be changed but wish to use unsolicted 
status. This small change accomodates this situation.



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

Comments attached to No ballot from Skip Jones of 
QLogic Corp.:

It is my belief that having a new "Reduced" command set that is little more 
than a subset of a mature, proven command set induces more confusion and 
ultimately less interoperability than it does to serve any market.  The 
argument that current SCSI commands require too much code space to be used 
with minimal ROM space for near-commodity product is bogus.  SCSI has been 
and continues to be coded and booted from minimal ROM space in consumer-level 
electronic equipment at the required cost targets.  It is true that the 
current SCSI command set is complicated and mandates highly competent 
firmware engineering expertise, especially when reducing it's compiled space 
while preserving the necessary functionality.  I have no doubt that SCSI is 
much more difficult than ATA firmware and it is enormously difficult for ATA-
level and other low-end commodity product firmware engineers to learn how to 
proficiently and efficiently code SCSI.  However, I do not feel that 
retarding the command set is the best approach to solving such inadequacies. 

Skip Jones


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

Comments attached to YesC ballot from Mark Evans of 
Quantum Corp.:


The following are Quantum's letter ballot comments on RBC rev 5:

Global:  In most cases "initiator" should be changed to "application client" 
to be consistent with other T10 documents.

Global:  In most cases "device" should be changed to "device server" to be 
consistent with other T10 documents.

4.1 FORMAT UNIT, first paragraph:  For consistency, the table number should be

referenced in the first sentence.

4.2 READ CAPACITY, paragraph 2:  The sentence, "The Block Length in Bytes and 
the Logical Block Address of the last logical block on the logical unit are 
returned."  should be changed to, "The Returned Logical Block Address and the 
Returned Block Length in Bytes should be those of the last logical block on 
the logical unit."  [see sbc-r08c]

Table 5 - READ CAPACITY data: "Logical Block Address" should be changed to 
"Returned Logical Block Address" [see sbc-r08c].

4.4 START STOP UNIT, paragraph 2:  The order of the sentences should be 
reversed so the definition for the "zero" value is first, i.e.,

"An Immediate (Immed) bit of one indicates that status shall be returned as 
soon as the command descriptor block has been validated.  An Immed bit of zero

indicates that status shall be returned after the operation is completed."

would become,

"An Immed bit of zero indicates that status shall be returned after the 
operation is completed.  An Immediate (Immed) bit of one indicates that status

shall be returned as soon as the command descriptor block has been validated."

4.4 START STOP UNIT:  The Power conditions descriptions table (numbered as 
Table 8 in this revision) the sentence preceding the table, and the relevant 
descriptive text that follows the table should be moved up in the document to 
immediately follow the paragraph describing the Power Conditions field.

4.4 START STOP UNIT:  In the Power conditions descriptions table and the 
descriptive paragraphs that follow, "state" should be changed to "condition" 

[see sbc-r08c].

4.4 START STOP UNIT:  In the descriptive paragraphs that follow the Power 
conditions descriptions table, "[condition name] (state [code number])" should

be changed to "[condition name] condition (code 0xh)" where "x" is the 
condition code value.

4.4 START STOP UNIT:  In the descriptive paragraphs that follow the Power 
conditions descriptions table, "...lower power level than [condition name]..."

should be changed to "...lower power consumption level than when in [condition

name] condition..." throughout.

4.4 START STOP UNIT:  The last paragraph should be changed from, "It is not an

error to request a device be placed into the same power state that it 
currently occupies" to, "It is not an error to request a device be placed into

the same power state in which it currently resides" (as was mentioned at the 
last working group meeting).

4.4.1 START STOP UNIT Removable...:  In the paragraphs that follow, "state" 
should be changed to "condition".

4.6 WRITE (10), paragraph 4:  This sentence should be changed from, "The 
Logical Block Address field specifies the starting logical block address on 
the device for the read data to be accessed."  to either, "The Logical Block 
Address field specifies the starting logical block address on the device for 
the WRITE data to be written." or (as it is in SBC-2), "The LOGICAL BLOCK 
ADDRESS field specifies the first logical block of the range of logical blocks

for this command."

5.2 MODE SELECT, first paragraph:  For consistency, the table number should be

referenced in the first sentence.

5.3 MODE SENSE:  A paragraph should be inserted before the first table.  This 
paragraph should say something like, "The MODE SENSE(6) command (see table 
[table number]) provides a means for a device server to report parameters to 
an application client. It is a complementary command to the MODE SELECT(6) 
command."

5.6.1 Download Microcode and Save Mode, first sentence:  I think that "device"

should be changed to "logical unit."



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

Comments attached to No ballot from Robert Snively of 
Sun Microsystems Computer Co:

I have the following comments on the RBC document, revision 5.  Most of
these came from study of revision 4, but have been checked to see if they
are still valid for revision 5.  While I am favorably impressed with the
correctness of this document and with the simple structure defined by RBC,
I believe that there are still a few problems in the documentation
of the functions and details of the architecture and have provided the 
following comments.

The correction of the following comments is very important to approval 
of this standard:


	1)  FORMAT UNIT should be mandatory
	
	4)  Model of FORMAT UNIT progress reporting is not clear
	
	6)   Note on START STOP command is incorrect
	
	8)   Incomplete specification of VERIFY
	
	13)   INQUIRY command should support Device Identification page of VPD.
	
	16)   The page control support table needs to be corrected.

	17)   Remove descriptive text from PREVENT/ALLOW MEDIA REMOVAL
	
	18)   SMART model required

	20)   Annexes need to be reformatted for clarity

	21)   Incomplete information about command set

	22)   Security key
	
	23)   Clarification of status presentations
	
COMMENTS:

1)  FORMAT UNIT should be mandatory

	Technical,  4.0, pdf 18, table 1
	
	FORMAT UNIT is a command commonly used by low-level utilities for
	both removable and fixed devices.  It should be a mandatory
	command, but it should be clearly indicated that no action is
	required take place during the successful completion of the 
	command for those devices not requiring or supporting actual
	medium formatting.  This actually applies to both removable
	and fixed devices, since even removable devices may come with
	pre-formatted media.
	
    Proposed Change:
	
	Change N to Y in line 1 of table 1.  

	
	Change O to Y in line 1 of table 1.
	
2)  Implement tolerance for commands

	Technical, 4.0, pdf 18, table 1
	
	The PREVENT/ALLOW MEDIUM REMOVAL and SYNCHRONIZE CACHE commands
	are presently not mandatory for various combinations of
	fixed and removable support.
	
	I would propose that these commands be mandatory regardless of
	the type of RBC medium, and implemented such that no action is
	required to take place for those media that do not require
	that function.  This would allow utilities to be constructed
	largely independent of whether the device is fixed or removable
	and would allow the "correct" behavior (which might be no operation
	at all) to be performed by the device.
	
    Proposed Change:
	
	Change N to Y in line 7 of table 1.
	
	Change O to Y in line 9 of table 1.
	
	Make any modifications in the descriptive text necessary to indicate
	that these commands may be completed without executing any operation
	on the device or medium for those devices where the instructions
	have no meaning.
	
3)  READ(6) should be mandatory

	Technical, 4.0, pdf 18, table 1
	
	Many out-of-date utilities use READ(6) to read such items as
	boot records, volume labels, partition information, and directories.  
	If there is any chance that such out-of-date utilities may still be 

	required in SBP attached devices, READ(6) should be included as 
	a mandatory compatibility feature.
	
    Proposed Change:
	
	Add READ(6) to pdf 18, table 1.
	
	Add a clause describing the RBC usage of READ(6)
	
4)  Model of FORMAT UNIT progress reporting is not clear

	Technical, 4.1, pdf 19, all
	
	I was unable to determine from this document what mechanism
	was used for format progress updates.  In older SCSI devices,
	the mechanism was polling using REQUEST SENSE.  In this one,
	I assume that Unsolicited Status is used, but I was
	unable to find a clear statement to that effect. 
	
	If unsolicited status is used, but no status_FIFO location is
	available to the LUN, it should additionally be clearly specified
	that only the latest value of progress is provided at the time
	the location becomes available.
	
    Proposed Change:

	Specify the FORMAT UNIT progress indication model.  I assume that
	this would require modification to paragraphs 1, 2, 3, 4, and 5
	of clause 4.1, but I am not sure of the intended model, so cannot
	make any recommendation for the text.

	Note that there is a bug in SBP-Rev4, pdf page 48 that specifies
	an incorrect src code for unsolicited status.

5)   REQUEST SENSE requirements?

	Technical, 4.x, pdf 18
	
	This is actually a question.  Does the provision of a
	write to the Unsolicited_Status_Enable CSR constitute a request
	for any status that may be lieing around in the device?
	If so, REQUEST SENSE is probably not needed.  However, if there
	is a requirement for soliciting current status that is not
	met through the CSR mechanisms (something that must be included
	in another document, since it does not appear to be included here),
	then REQUEST SENSE might become a required command.
	
    Proposed Change:
	
	Specify and reference the mechanism by which status may be solicited 
	from a target, indicating that it is a functional substitute for
	REQUEST SENSE in either 4.0 or a sub-clause of 5.
	
6)   Note on START STOP command is incorrect

	Technical, 4.4, pdf 23, first paragraph
	
	The note indicates that the Immediate bit has no meaning for RBC.
	This is not correct.  The Immediate bit should be used, although
	its meaning can be somewhat loosely interpreted by an RBC device.
	There is no need to have a mechanism to determine when a device
	has begun executing a command, since the Immediate bit references
	only the relative timing by the target.
	
	The previous paragraph correctly describes the behavior of the
	Immediate bit for a generic SCSI device.  I believe that the
	correct interpretation would slightly modify the paragraph
	previous to that and remove the note.
	
    Proposed Change:
    
    	The last paragraph of pdf page 22 should be rewritten as follows:

    	
    	"An Immediate (Immed) bit of zero indicates that status shall be 
    	returned after the operation is completed.  An Immed bit of one
    	indicates that status may be returned as soon as the command
    	descriptor block has been validated and shall be returned as soon
    	as the RBC device implementation allows."
    	

    	The note contained in the first paragraph of pdf page 23
    	should be entirely deleted.
    	
7)   Incorrect ASC/ASCQ

	Technical, 4.4, pdf 24, paragraph 7.
	
	The specified ASC/ASCQ is incorrect.
	
	The value should be LOW POWER CONDITION ACTIVE, as specified in SBC.
	
    Proposed Change:
    
    	Change ILLEGAL POWER CONDITION REQUEST (2C16, 0516) 
    	to LOW POWER CONDITION ACTIVE, supplying the correct values.
    	
8)   Incomplete specification of VERIFY

	Technical, 4.7, pdf 27, all
	
	The VERIFY command has rarely been used by any programs and
	often not implemented by disk drives because it is so poorly 
	defined.  In particular, there is no specification as to what
	sort of verification is performed and what should happen if 
	the verification is in whole or part unsuccessful.
	
	I would propose that this be specified or the command be removed
	from the document.
	
    Proposed change:
	
	Add the following new paragraph at the end of 4.7.
	
	"The VERIFY command verifies that the data written on the
	media by a previous WRITE command is readable without any
	uncorrectable errors at the time of execution of the command.  
	It does not guarantee the information is complete or valid."

9)   Write Cache Disable bit interacts too rigorously with removability.

	Technical, 4.8, pdf 28, second and third paragraph.
	
	There are statements that indicate that the WCD (Write Caching Disable)
	bit cannot be supported by devices that cannot physically lock
	the medium.  In addition, devices that cannot prevent medium
	removal are not allowed to support the WCD bit.
	
	Unfortunately, the "unsupported" zero state of the WCD bit is
	the active state of supporting the caching function.

	Rather than change the caching control function, making the cache
	enabled behavior vendor and device specific would be a superior
	change.

    Proposed Change:

	Change the last sentence of the second paragraph of clause 4.8
	on pdf page 28 ("Devices .... Write Caching.") to read:

	"Devices that cannot physically lock the media may ignore the
	state of the WCD bit and always disable write caching if
	information sent by a successful WRITE(10) command would be
	lost from the media when the media is removed."

	Remove the next paragraph ("Devices that ... WCD bit.").

10)   Number of blocks note should be normative.

	Technical, 4.8, pdf 28, sixth paragraph

	There is no reason to make the text a note.  It should be
	simply included as a description of the model of 
	MODE SELECT/SENSE operation.

    Proposed Change:

	Make the text part of the main text, removing it from the state
	of a note.

11)    Power/Performance effects are vendor specific

	Technical, 4.8, pdf 28, last paragraph on page.

	It should be clarified that the actual boundaries of
	power/performance values and relative performance and power
	characteristics are vendor specific and need only change
	monotonically at certain numeric boundaries.

    Proposed Change:

	Add the following line to the paragraph which ends on the first
	lines of pdf page 29.

	"The changes in the value of power and performance for various
	values of the Power/Performance field are vendor specific."


12)   Format should be allowed, even if not executed

	Technical, 4.8.1, pdf 29, 4th paragraph of clause.

	The FORMAT UNIT function should complete successfully even if
	the media cannot be formatted and even if no action takes place
	when the FORMAT UNIT command is executed.

    Proposed Change:

	Add the following sentence to the paragraph describing the format bit.

	"The device shall accept a FORMAT UNIT command whether or not

	any actual formatting function is performed by the command."

	Alternatively, remove the Format bit from the standard and use
	the information contained in the FORMAT UNIT to carry that
	implication.
	
13)   Table format needs to be corrected

	Editorial, 5.0, pdf 30, table 13
	
	Correct table cell borders
	
14)   Allow PREVENT/ALLOW MEDIA REMOVAL for fixed devices

	Technical, 5.0, pdf 30, table 13
	
	Since it is desirable to create common utilities where possible,
	why not simply allow fixed devices to implement the 
	PREVENT/ALLOW MEDIUM REMOVAL command to be executed without
	performing any operation?
	
   Proposed Change:
   
   	Change N on line 4 of table 13 to Y.
   	
13)   INQUIRY command should support Device Identification page of VPD.

	Technical, 5.1, pdf 31, last paragraph
	
	The Vital Product Data Device Identification page has proven to
	be a very useful function in all SCSI drivers.  It allows SCSI
	utilities direct access to the device identification information
	that is normally hidden away in vendor specific driver managed
	configuration information.  I believe it is very desirable to either
	require or strongly encourage disk drives and most other block
	oriented devices implementing RBC to support the Device
	Identification page as an alternate mechanism for reaching the
	identification information normally available through the CSRs.
	
   Proposed Change:
   
   	Change the last paragraph on pdf page 31 to read as follows:
   	
   	The Vital Product Data Device Identification page should be
   	supported by RBC devices.  Support of other bits and fields
   	in the INQUIRY command and associated pages is optional.

14)    MODE SENSE/SELECT Device Specific Parameter not defined

	Technical, 5.3, pdf 33, all
	
	Neither this section nor the page definition in clause 4.8
	defines the device specific parameter for the RBC devices.
	
	I believe that the device specific parameter should be similar
	to the SBC device specific parameter defined in SBC, pdf page 105
	of SBC rev 8c, table 72, page 88.
	
	I would suggest that the DPOFUA bit be reserved and set to zero.
	
	I strongly believe that the WP bit should be implemented.  
	This is especially key for blocked devices that are removable.
	
   Proposed change:
   
   	Where the overall mode page format is considered (probably 
   	section 4.8), the Device Specific Parameter should be defined.
   	
   	The following text stolen from SBC would be appropriate:
   	
   	    [Install table 72, with bits 6-0 marked as reserved]
   	    
   	"When used with the MODE SELECT command the write protect (WP) bit 
   	is not defined."
   	

   	"When used with the MODE SENSE command a WP bit of zero indicates 
   	that the medium is write enabled. A WP bit of one indicates that 
   	the medium is write protected."

15)   Question about Block Descriptors in MODE SENSE/SELECT

	Technical, 5.3, pdf 33, first paragraph of clause
	
	The Disable Block Descriptors (DBD) bit keeps you from using
	the block descriptors.  As far as I can see, the only significant
	difference between the RBC device parameters page (4.8) and the 
	direct access device mode parameter block descriptor (SBP 8.3.2.2)
	is that the RBC has a five byte block count.  Is it really true
	that a four byte block count does not provide enough range for
	RBC devices?  If there is a convincing arguement that 4 bytes is
	not enough (i.e. 4+ Gigablocks will be exceeded on an RBC device
	in the next 10-15 years), locking DBD to 1 is appropriate.  If there 
	is not such a convincing arguement, the block length and number of block
	fields should be removed from the RBC mode page and placed in the
	more standard data descriptor block.
	
   Proposed change:
   
   	Remove block length and block count numbers from RBC mode page
   	and place them in the more standard block descriptors location
   	using the format defined by SBC.  This effects 4.8 as well as
   	5.3, first paragraph.

   	
16)   The page control support table needs to be corrected.

	Technical, 5.3, pdf 33, Table 17
	
	The table is in conflict with the 4.8 and does not provide the
	necessary information to use the standard SCSI MODE SENSE/SELECT
	management algorithms.
	
	One powerful advantage of MODE SENSE/SELECT is that it can
	ignore and emulate any undesirable requests.  Examples in non-RBC
	SCSI devices include parameter rounding and ignoring parameters that
	are not meaningful.  If the same philosophy is allowed in 
	RBC, then the table can be removed and replaced with simple textual
	descriptions of the effects of the states.  In particular, all
	parameter displays should be supported to allow the standard
	protocol which determines what is current, what is default, what is
	changeable, then sets what is desired.
	
	The nice thing about RBC is that the simplified page definitions
	make the function quite simple.  Default values and Changeable values
	are simply constants provided to the initiator.  Current values
	are the values that are active and by definition are identical to the
	saved values, since the SP bit is specified as one.  
	
   Proposed change:
   
   	Replace table 17 with the following text:
   	
   	"The page control field is supported as specified in SPC-2."

	5.3.1 will also require minor editorial modifications to reflect
	this improvement.

17)   Remove descriptive text from PREVENT/ALLOW MEDIA REMOVAL

	Editorial, 5.4, pdf 34, all
	
	The text of PREVENT/ALLOW MEDIA REMOVAL appears to be identical to
	the text of the same command in SPC, except for the recommended
	sense information.  The descriptive text should be removed and
	reference made to SPC-2.
	
	This avoids possible inadvertent conflicts with the standard text.
	

   Proposed change:
   
   	Replace entire text of 5.4, except table 20, with the following
   	text:
   	
   	"The PREVENT/ALLOW MEDIA REMOVAL command shall be implemented as
   	specified by SPC-2.  The error codes in table 20 are recommended
   	for various conditions that may occur during execution of the command."

18)   SMART model required

	Technical, 5.5, pdf 36, all
	
	It is not clear how often SMART information is presented, how
	it is reset, or what use is expected to be made of it.  
	If this is not specified in a standard or
	controlled document somewhere, it must be specified here.
	If it is specified in such a document, the document must be
	placed among the references in clause 2.
	
    Proposed change:
    
    	Install a descriptive clause that includes how SMART information
    	is expected to be created, reset, and used.  If this is already
    	available in a controlled document, reference the document and
    	indicate any RBC variations from the standard behavior expressed
    	by the document.

19)   Download with offsets should be allowed

	Technical, 5.6, pdf 38, all
	
	The 111 mode, Download Microcode with Offsets and Save option
	should be allowed, since microcode sizes will often exceed
	normal write buffer sizes for simple machines.
	
    Proposed change:
    
    	Place the corresponding text from 7.24.7 of SPC-2 in this
    	section to allow the Download microcode with offsets and save
    	function to be performed.
    	
    	This also requires table 23 to be updated to contain the
    	buffer offset parameter.
    	
20)   Annexes need to be reformatted for clarity

	Editorial, All annexes, pdf 39-49, all
	
	There is a great deal of confusion possible about the normative
	and informative state of various paragraphs in the annexes.
	
	With little effort, the annexes can be modified and reformatted to
	correct this potentially serious ambiguity.  See the proposal below.

    Proposed change:
    
    	New annexes should be generated to separate unambigously normative
    	and informative information.  I will name the new annexes A', B'
    	etc and indicate what should go in each one:
    	
    	A'  RBC Storage model (informative)

    	
    		Should include A.1, A.2, A.1.2
    		
    	B'  RBC requirements for SBP and CSR objects (normative)
    	
    		Should include A.2, A.2.1, A.2.2, A.2.3
    		Should include A.3
    		Should include A.4
    		
    	C'  Unsolicited status (I assume this is probably normative)
    	
    		Should include all of Annex B.
    		
21)   Incomplete information about command set

	Technical, A.2, pdf 41, several clauses
	
	The values that specify the RBC command set and revision
	should be specified in A.2.1 and A.2.2 unless they are
	specified in another document.  In that case, the document
	should be referenced.
	
     Proposed change:
     
     	Place proper values in Command_Set and Command_Set_Revision fields
     	in A.2.1 and A.2.2
    			
22)   Security key

	Technical, A.3, pdf 41, all
	
	The vital product data page that is defined as mandatory by
	this section is not included in the INQUIRY command description

	in section 5.1.
	
	In any case, what has this publicly available constant to do with
	security?  A security model should be described to specify this
	relationship unless the relationship is clearly described by another
	controlled document.
	
     Proposed change:
     
     	Place requirement for vital product data page 80hex in section 5.1.
     	
     	Describe the relationship between serial number (specified in
     	page 80hex) and the master password.  Explain how the 
     	public availability of the master password accomplishes the security
     	goals.
    		
23)   Clarification of status presentations

	Technical and editorial, B, pdf 43-49, all
	
	The model here is not very clear.  It is my impression that
	Unsolicited Status handles the following conditions:
	
		Unit Attention
		Deferred Errors
		Power State Change notification
		SMART notification
		Event status notification
		
	However, the paragraphing would indicate that Unsolicited
	Status and Event Status are somehow different in their
	presentation mechanism or somehow not related.
	
	In addition, you should not bother to have a single sub-clause
	under another sub-clause.  An example is B.1.1.1 which should
	be included in B.1.1
	
    Proposed change:
    
    	Rewrite as necessary to properly relate the clauses:
    	
    	B.1 ->  B  Unsolicited Status Operation
    			include B.1.1 directly in this section.
    			
    	B.1.1 -> B.1  Unit Attention presentation and retention
    	
    	B.1.1.2 -> B.2  Deferred error presentation
    	
    	B.1.1.3 -> B.3	Power state change notification
    	
    			Include references to or the actual values for
    			power state change notification YY field here.
    			
    	B.1.1.4 -> B,4	SMART notification/presentation
    	
    	B.2	-> B.5  Event Status Notification
    	
    			Include in this section B.2.1, event status retention
    			
    	B.2.2 -> B.5.1	Removable medium event status notification algorithm
    	
    	B.2.3 -> B.5.2  Event status sense information
    	
    	B.2.3.1 -> B.5.2.1  Power management information values
    	
    			Note that it is not very clear how this relates back
    			to the standard formats required by SBP-2 and
    			unsolicited status.  A table showing the complete
    			content would be a great help in placing this
    			properly in context.
    			
    	B.2.3.2 -> B.5.2.2  Media event information values
    	
    			Here too, the context must be properly provided.  If
    			this is made more clear in either the new B.1 or
    			the new B.5, it could be omitted from B.5.2.1 and
    			B.5.2.2, but now it is difficult to create
    			unambiguous representations of the proper status.
    			
    	B.2.3.3 -> B.5.2.3  Device Busy Event information values
    	
    			Note that SCSI device busy management overlaps with
    			this function.  The relationship must be clarified.
    	
    	
    	
    	To really clarify this, it may require the rather special behavior
    	of the power notification protocol to be included and separately 

    	described in a separate annex, which would become annex D, normative.
	


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

Comments attached to YesC ballot from Paul D. Aloisi of 
Unitrode Corporation:

The vice chair is George Penokie, Not Larry Lamers.


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

--
John Lohmeyer                  Email: lohmeyer at ix.netcom.com
LSI Logic Corp.                Voice: +1-719-533-7560
4420 ArrowsWest Dr.              Fax: +1-719-533-7036
Colo Spgs, CO 80907              BBS: +1-719-533-7950

*
* 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