96-148R2 -- SPC Letter Ballot Comments Resolution

ROWEBER at acm.org ROWEBER at acm.org
Tue Jun 18 14:32:58 PDT 1996


* From the SCSI Reflector, posted by:
* ROWEBER at ACM.ORG
*
                                                                X3T10/96-148R2

To:       Membership of X3T10

From:     Ralph O. Weber
          Symbios Logic

Date:     June 18, 1996

Subject:  SPC Letter Ballot Comments Resolution


I received additional written comments from Seagate and a couple of
corrections to information in R1, so here's a new and hopefully final
resolution for the SPC letter ballot comments.

It must be noted that Seagate comment 1 requested a page-by-page editing
meeting.  That meeting was held over the course of three days; 17 and
18 April, and 10 May.  Numerous changes were made during the editing
meeting(s), and those changes can be found in SPC rev 9b but are not described
in this document.

Exabyte comments on SPC attached to No ballot:

I am voting NO to forwarding X3T10/995D rev 9 for further processing with the
following comments.

I tried to sort the comments into editorial and technical.  Anything requir-
ing clarification is included in the technical comments.  I am willing to
entertain the possibility of changing my vote to YES if the technical
comments are reasonably addressed.

Technical comments:
1. Page 10-11, Reservations.  The interactions between persistent and non-
   persistent reservations are not clear.  The last paragraph in the section
   talks about conflicts between the different reservations but does not 
   state what happens.
ACCEPT sort-of.  The descriptions of what happens when reservations are
       improperly mixed with persistent reservations will be described in the
       definitions of the RESERVE, RELEASE, PERSISTENT RESERVE IN, and
       PERSISTENT RESERVE OUT commands.

       The text to be placed in the RESERVE and RELEASE commands is:
       "If a device server has any reservation keys registered (see clause
       7.14.1.1) a RESERVE (or RELEASE) command shall be rejected with a
       RESERVATION CONFLICT status."

2. Page 50, PERSISTENT RESERVE IN command.  The first paragraph states "..
   and cannot be used with the RESERVE and RELEASE commands".  What does used
   with mean?  What if the logical unit is already reserved?  Conversely, 
   what if persistent reservations exist and the other reserve is used?  
   This information should be in section 5.3 reservations and referred to 
   by the PERSISTENT RESERVE IN command.
ACCEPT Add the following text to the PERSISTENT RESERVE IN, and PERSISTENT
       RESERVE OUT commands:  "When a PERSISTENT RESERVE IN command (or
       PERSISTENT RESERVE OUT command) is received and RESERVE(6) or
       RESERVE(10) logical unit or extent reservations are active (see
       clause 7.23), the command shall be rejected with a RESERVATION
       CONFLICT status."

3. Page 53, PERSISTENT RESERVE OUT command.  The first paragraph states
   "... and shall not be used with the RESERVE and RELEASE commands".  Same
   comments as before (note that Reserve Out states shall whereas Reserve In
   states cannot).  This information should be in section 5.3 reservations 
   and referred to by the PERSISTENT RESERVE OUT command.
ACCEPT see resolution for Exabyte comment #2.

4. Page 62, paragraph under table 46.  The first sentence states that a
   reservation conflict shall occur when a PREVENT ALLOW MEDIUM REMOVAL 
   command is received from an initiator other than the one holding a 
   logical unit reservation.  The last sentence states that a reservation 
   shall not occur when Prevent bit is zero for extent reservations.  This 
   is a conflict.  The blanket statement at the beginning of the paragraph 
   needs to be changed.
REJECT The first sentence in the paragraph is NOT a blanket statement.  It
       is specifically limited to "a logical unit reservation."  The last
       sentence in the paragraph covers "extent reservations."

5. Page 62, paragraph under table 46.  The case of prevent bit set to 0
   not causing a reservation conflict should not be restricted to extent
   reservations.  Any prevent must be releasable by an initiator regardless 
   of the reservation situation.
ACCEPT SCSI-2 clearly allows PREVENT ALLOW MEDIUM REMOVAL commands with
       Prevent=0 not to be blocked by any type of reservation.

6. Page 62, paragraph under table 46.  Thinking about the first sentence
   again, that sentence (which is used for many commands) implies that a
   reservation conflict occurs when NO initiator holds a reservation.   An
   initiator sending a command to a non-reserved target could be interpreted 
   as different than no initiator holding a logical unit reservation.  
   Therefore, a reservation conflict would exist, according to the first 
   statement.  Additionally, it states "holding a logical unit reservation", 
   not "holding a reservation on the logical unit".  This could be 
   interpreted as a reservation on a different logical unit affecting the 
   logical unit for which the command was sent.  A better statement would 
   be:

   A reservation conflict shall occur when a PREVENT ALLOW MEDIUM REMOVAL
   command is received with the Prevent bit set to one if the logical unit 
   is reserved by any initiator other than the one requesting the command.
   
   Similar text may fix the other commands using the reservation statement
   substituting the command name and removing the text about the Prevent bit.
ACCEPT Add the following sentence to the beginning of all command paragraphs
       describing reservations interactions: "If reservations are active, they
       shall affect the execution of the XXX command as follows."

7. Page 66, RECEIVE DIAGNOSTIC RESULTS command.  Didn't we add a page code
   to the RECEIVE DIAGNOSTICS command (or at least agree to the concept of 
   adding a page code)?  We talked about it in the November 1995 working 
   group when we talked about 95-324r1.  While the enclosure services are 
   not included in 995 r9, maybe we should add the page code to the command 
   in byte 2?
ACCEPT

8. Page 68, RELEASE(10) command.  Is support of the LongID bit optional?
   It should be and the standard text about ILLEGAL REQUEST needs to be 
   added if it is not supported.
ACCEPT Add the following text: "Device servers that support device IDs greater
       than 255 shall accept commands with LongID equal to one.  Device
       servers whose devices IDs are limited to 255 or smaller may reject
       commands with LongID equal to one with a sense key of ILLEGAL REQUEST."

9. Page 69, REPORT LUNS command.  No mention on affects of reservations is
   made.  State "The REPORT LUNS command shall not be affected by 
   reservations".
ACCEPT

10.Page 88, RESERVE(10) command.  Is support of the LongID bit optional?
   It should be and the standard text about ILLEGAL REQUEST needs to be 
   added if it is not supported.
ACCEPT Add the following text: "Device servers that support device IDs greater
       than 255 shall accept commands with LongID equal to one.  Device
       servers whose devices IDs are limited to 255 or smaller may reject
       commands with LongID equal to one with a sense key of ILLEGAL REQUEST."

11.Add "ANSI", "ECMA", and "ISO" to the list in Annex C.  This would help
   in the use of the Report Supported Densities command in SSC.
ACCEPT in part
       X3 was added to be used by Report Supported Densities.  Using ANSI
       is inappropriate because ANSI is not the standards developing body,
       generally an X3 technical committee develops standards that are later
       approved by ANSI.  Add ECMA and ISO to the table in Annex C to permit
       their use in reporting secondary identifications (standards references)
       for tape densities.


Editorial comments:

1. Page 9 has the usage of "may be" in the first sentence of 5.1.1.  Is
   the use of "may be" appropriate for a standard?
REJECT The statement in question is describing a possibility that may be
       exercised by the application client.  It must be noted that SCSI
       standards traditionally place the fewest possible number of
       requirements on the application client.  In this case, even
       "should" would be too strong a statement.

2. Pages 67 and 68, RELEASE(x) commands.  A reference to section 5.3,
   reservations, should be made, particularly in reference to Persistent
   reservations.
ACCEPT

3. Page 73, subsection d) under information field data.  For both cases 
   1) and 2), instead of stating what fixed block mode and variable block 
   mode indicate, direct the reader to SSC.  The text in parenthesis is not 
   exactly correct since the error could occur on a non-write command.  
   Being model dependent, the detailed text should not be stated here.
ACCEPT Add the following text at the end of bullet d) "For additional
       information see SSC."

4. Pages 84 and 88, Reserve(x) commands.  A reference to section 5.3,
   reservations, should be made, particularly in reference to Persistent
   reservations.
ACCEPT

5. Page 84, section 7.23.1, paragraph 3 has "See clause ?".  Should refer
   to section 5.3.
ACCEPT

6. Page 89, SEND DIAGNOSTICS command.  Too many references to RECEIVE
   DIAGNOSTICS RESULTS are made in the last sentence of the first paragraph.
   Should be clause 7.18.
ACCEPT

7. Page 91, TEST UNIT READY command.  The last sentence in the paragraph
   above table 73 states "Higher-priority responses (e.g. BUSY or RESERVATION
   CONFLICT) are also permitted.  In the paragraph above, text indicates that
   a reservation conflict shall occur.  Therefore, reference to RESERVATION
   CONFLICT in this sentence should be stricken.  Also, what is a higher-
   priority response if the only example is BUSY?
ACCEPT The critical thought in the sentence is that the table is not complete. 
       Other conditions may necessitate other responses.  Change the paragraph
       to read: "Table 73 defines the preferred GOOD and CHECK CONDITION
       status responses to the TEST UNIT READY command.  Other conditions may
       result in other responses (e.g., BUSY or RESERVATION conflict status)."


IBM comments on SPC attached to No ballot:

    1-(T) I do not think processor devices should be included in the SPC
    standard.  They should have their own command set document.  This is
    even more an issue with the newly proposed device for enclosures. The
    new device and processor devices should both be in the same command set
    document.
REJECT The SCSI working group continues to prefer including the processor
       commands in the SPC.

    2-(E) page i-1 - Abstract - The abstract does not include any comment
    about processor devices. One must be place here if they remain in this
    document.
REJECT During the editing meeting(s), two abstracts were discovered.  The
       front matter has been reorganized following the model in SBC and now
       there is only one abstract, which includes information about processor
       devices.

    3-(E) page 2 - 3.1.5 - This definition should be remove as the term is
    not used in SPC unless someone can point it out where it is used.
REJECT "Blocked task" is used in the description of the Qerr bit in the
       Control mode page (8.3.4).

    4-(E) page 3 - 3.1.14 - This definition should be remove as the term is
    not used in SPC unless someone can point it out where it is used.
REJECT "Enabled" (as in enabled task) is used in the description of the PROUT
       command Reserve function (7.14.1.2).  "Enabled task" is used in the
       description of deferred errors (7.22.2).

    5-(E) page 3 - 3.1.16 - The term I/O processes should be changed to
    tasks.
ACCEPT

    6-(E) page 4 - 3.1.25 - The statement 'Most usages of medium' should be
    change to 'Except where noted the usage of medium'.
ACCEPT

    7-(E) page 4 - 3.1.32 - There is a missing cross-reference.
ACCEPT

    8-(E) page 4 - 3.1.35 - This definition should be remove as the term is
    not used in SPC unless someone can point it out where it is used.
REJECT "Service delivery subsystem" is used in the definitions of SCSI Device
       and SCSI Domain.  "Service delivery subsystem" also is used in the
       description of Asynchronous Event Reporting (6.2.1), the description
       of the READ BUFFER command (7.16), the description of the REQUEST
       SENSE command (7.22), and the description of the WRITE BUFFER
       command (7.27).  There may be more; I stopped searching here.

    9-(E) page 6 - 4. - Need a comment about processor devices if they
    remain in this document.
ACCEPT

    10-(E) page 10 - 5.1.3 - Last sentence - The statement 'all is well'
    should be replaced with 'if the test is successful'.
ACCEPT

    11-(E) page 11 - 5.3 last paragraph - The term action is used here and
    in the persistent reserve sections.  This term needs to be added to the
    glossary.  For sample wording look in SCC at definition of service
    action.
ACCEPT

    12-(E) all - Replace SAM with SCSI-3 Architecture Model.
ACCEPT in part.  Change "the SAM" to "SAM" throughout.

    13-(T) page 16 - table 5 - Move Medium (attached) and Read Element
    Status (attached) commands should be removed. They are already defined
    in the SMC why are they redefined in SPC.  If other non-SMC devices
    need to use these commands then those devices command standards should
    reference the SMC.  If it is insisted these commands should be in SPC
    then they need to be removed from SMC. In any case they should only be
    defined in one place.
REJECT The SCSI working group agreed to leave these commands in table 5, but
       to make the references directly to SMC, instead of to clauses in SPC.

    14-(E) page 16 table 5 - What does (attached) mean in the Move Element
    Status and Move Medium commands mean?  Is it part of the command name
    or what. I see no value it should be removed.
ACCEPT Change "(attached)" to "ATTACHED" throughout.

    15-(E) page 32 table 19 - The use of italicized fonts should be removed
    from this table.
ACCEPT Return the SIP-specific bit names to table 19, but add a table note
       about their limited use.

    16-(E) page 33 table 21 - I do not remember approving a document called
    'here'. This should be a cross-reference to either SPC or the actual
    clause in SPC.
ACCEPT Change 'here' to 'SPC'.

    17-(T) page 34 - The second to last paragraph, third sentence should be
    removed.
ACCEPT

    18-(E) page 34 Last paragraph - page 35 first paragraph - page
    36 table 23 - page 36 third paragraph - The use of italicized fonts
    should be removed.
ACCEPT see resolution for IBM comment 15.

    19-(E) page 38 - second paragraph - It is not clear at all what the
    following statement means or why there is a requirement that the
    peripheral qualifier and type byte be followed by anything:  'the
    requested SCSI operation code it shall return the peripheral qualifier
    and type byte followed by a byte containing 01h.'
ACCEPT change 'followed by a byte containing 01h' to 'and all zeros in byte
       1 except for the Valid bit, which shall be set to one.'

    20-(E) page 38 - paragraph above note - The statement 'Except for group
    6 and group 7 operation code,' should be removed. All CDB lengths, even
    the vendor specific lengths are defined in SAM.
ACCEPT Delete all but the first sentence in the paragraph in question.

    21-(E) page 44 - second paragraph under table 29 - There are no more
    dual ports in SCSI. 'Dual port' should be removed or replaced with
    'multiple port' and 'both ports' should be replaced with 'all ports' or
    removed.
ACCEPT Make replacements for 'dual port'.

    22-(E) page 45 - 4th paragraph - last sentence - The list of standards
    should be (SBC,SSC,SGC,MMC,SCC, etc.).
ACCEPT

    23-(E) page 47 - table 32 heading - The table heading 'subclause'
    should be 'clause'.
ACCEPT change all instances

    24-(E) page 48 - 1st paragraph - last sentence - The list of standards
    should be (SBC,SSC,SGC,MMC,SCC, etc.).
ACCEPT

    24-(E) page 48 - 7.10.1 - 7.10.2 - 7.10.3 - 7.10.4 - The 0h, 1h, 2h,
    and 3h should be 00b, 01b, 10b, and 11b.
REJECT why change from SCSI-2?

    25-(T) page 49 - 7.12 - This sections should be removed see 13 above.
ACCEPT

    26-(E) page 50 to 61 - The acronym PRIN and PROUT serve on useful
    purpose other than making SCSI look more like a secret organization.
    Remove those acronyms and replace them with Persistent Reserve In and
    Persistent Reserve Out.
ACCEPT

    27-(E) page 53 table 39 - The field 'Reservation key under which the
    reservation is held' should be just 'Reservation key' and should be
    described in the text.  The field 'LBA of first block of Extent or
    Element Address' should be just 'LBA' or 'LBA_E or LBA_EA' and should
    be described in the text.  The field 'Extent length' is not defined
    anywhere.
ACCEPT in principle.  During the editing meeting(s), the names of the fields
       in table 39 were changed to match common practice in SCSI standards and
       suitable text definitions were added (or revised) for all fields.
  
    28-(E) page 50 to 61 - The term 'extent' and 'element' are not defined.
    They should be placed in the glossary.
ACCEPT

    29-(E) page 53 - The sections that define the fields 'scope' and 'type'
    should be move to this page under table 39.  This is the first place
    they are used and therefore should be defined here.
ACCEPT

    30-(E) page 54 - Table 40 - The parameter list length field is a fixed
    length so the length '18h' should be added to the field name in the
    table.
ACCEPT

    31-(E) page 54 - There must be a cross-reference to the scope and type
    fields under table 40.
ACCEPT

    32-(E) page 55 - 7.14.1.1 - Last paragraph - What does this sentence
    mean??  I see no value so it should be deleted.
ACCEPT

    33-(E) page 56 - third paragraph from top - The term 'active tasks' has
    no meaning in SCSI. I assume it should be 'current tasks'.
ACCEPT

    34-(E) page 57 - 7.14.1.5 - Last paragraph - What does this sentence
    mean??  I see no value so it should be deleted.
ACCEPT

    35-(E) page 57 - 7.14.1.6 - last paragraph - The statement 'Automatic
    Contingent Allegiance condition (ACA condition)' should be replaced
    with 'ACA condition'.
ACCEPT

    36-(E) page 58 - 1st paragraph from top - Remove '(AEN)'.
ACCEPT

    37-(E) page 58 - 4th paragraph from top - What does this sentence
    mean??  I see no value so it should be deleted.
ACCEPT

    38-(E) page 59 - The 4 paragraphs under table 43 need to be rewritten
    to define each code. For example 'A type code of Read Shared (0h) allows
    the execution of commands that perform....'
ACCEPT However, don't expect to see proposed new words in this document. 
       Check your next SPC revision.

    39-(E) page 60 - 7.14.4 - first paragraph - The second sentence that
    starts with 'Table 45 indicates..' should be moved to directly above
    table 45.
ACCEPT

    40-(E) page 60 - 7.14.4 - first paragraph - Remove the 3rd and 4th
    sentences that start with 'Two PROUT ..' and end with '...parameter
    description.' That information should be placed below table 44 and a
    cross reference to a specific clause must be given.
ACCEPT

    41-(E) page 60 - table 44 - The names of the first two fields should be
    changed see comment number 27.
ACCEPT in part.  During the editing meeting(s), the names of the fields in
       table 44 were changed to match common practice in SCSI standards.

    42-(E) page 60 - first paragraph after table 44 - The last sentence
    should have the phrase 'and expected' removed.
ACCEPT & change 'set' to 'valid'

    43-(E) page 60 - 2nd paragraph after table 44 - The third sentence
    should be changed to 'For Preempt and Preempt and Clear actions...'.
ACCEPT

    44-(E) page 60 - 3rd paragraph after table 44 - What are 'extent
    parameters'?
ACCEPT in principle.  During the editing meeting(s), the names of the fields
       in table 44 were changed to match common practice in SCSI standards and
       suitable text definitions were added (or revised) for all fields.

    45-(E) page 60 - 4th paragraph after table 44 - What are 'element
    address parameters'?.
ACCEPT in principle.  During the editing meeting(s), the names of the fields
       in table 44 were changed to match common practice in SCSI standards and
       suitable text definitions were added (or revised) for all fields.

    46-(E) page 60 - 5th paragraph after table 44 - The 2nd and 3rd
    sentences should read 'The APTPL bit shall be set only for the Register
    action. In all other cases, the APTPL bit shall be ignored.'
ACCEPT 'The APTPL bit shall be valid only for the Register action.  In all
       other cases, the APTPL bit shall be ignored.'

    47-(E) page 61 - table 45 - Remove from the heading the statement 'Set
    by initiator/expected by target'.  Remove from the table all
    'expected' and 'not set' and all '/'.  This information contains no
    useful information; everything that is set is expected and everything
    that in not set is ignored.
ACCEPT Use "valid" or "ignored".

    48-(T) page 65 - 7.17 - This sections should be removed see 13 above.
ACCEPT

    49-(E) page 75 - first paragraph after table 62 - The last sentence
    should read 'The progress indication shall be based upon the total
    operation.'
ACCEPT

    50-(E) page 75 - note 39 - The second sentence should read 'However,
    since for example format time...'
ACCEPT

    51-(E) page 84 - 7.23.1 - 3rd paragraph - The last sentence has an
    undefined cross reference.
ACCEPT

    52-(E) All - The left and right margins should be set to 1".  Right now
    the way they are set is causing words to be chopped of by the three hole
    punch.
ACCEPT

    53-(T) page 112 - 2nd and 3rd paragraphs - Should there even be a
    ByprtM bit and a BybthS bit in SCSI-3?  They appear to be from the dual
    port proposal that was removed from SCSI-3.  If they do remain then the
    word 'both' in those two paragraphs should be changed to 'all'.
ACCEPT

    54-(E) page 113 - first paragraph after table 98 - The terms 'Target
    Role Agent' and 'Initiator Role Agent' need to be defined in the
    glossary.
ACCEPT Get definitions from SIP.

    55-(E) page 113 - 3rd paragraph after table 98 - There is no such term
    as 'interconnect tenancy' in SIP so the last sentence for this
    paragraph should be removed.
ACCEPT

    56-(T) page 115 - 8.3.6 - First paragraph - The last sentence should be
    changed to '...sense code of FAILURE PREDICTION THRESHOLD EXCEEDED or
    WARNING to the applications client.'  This change should have been part
    of the proposal that added the WARNING ASC.
ACCEPT

    57-(T) page 117 - first paragraph after table 101 - In second to the
    last sentence the statement '...that the target shall only report the
    information exception condition one time.' should be changed to '...that
    the timer interval is vender specific.'  Without this change it is
    unclear what to do if both the interval timer and the report count
    fields are set to zero.
ACCEPT, however, the exact wording differs from what is proposed here.

    58-(E) page 119 - 8.3.8 - The following terms need to be added to the
    glossary: standby condition, idle condition, and active condition.

    Standby condition: When a logical unit is capable of accepting
    commands, but media is not immediately accessible (e.g., spindle is
    stopped).

    Idle condition: When a logical unit is capable of responding quickly
    to media access requests.  However, a logical unit in the Idle
    condition may take longer to complete the execution of a command
    because it may have to activate some circuitry.

    Active condition: When a logical unit is capable of responding
    immediately to media access requests, and operations complete execution
    in the shortest possible time.
ACCEPT

    59-(E) page 119 - 8.3.8 - The following statement needs to replace
    the first paragraph of this section:

    The power conditions page (Table 104) provides the application client
    the means to control the behavior of a logical unit in a manner which
    reduces the power required to operate.  There is no notification to the
    initiator that a logical unit has entered into one of the power
    conditions.  The power conditions may be controlled by the Start/Stop
    Unit command (See SBC) or the power condition page.  If both methods
    are being used on the same logical unit then any Start/Stop Unit
    commands power condition request will override the power condition
    pages power control.

    No power condition shall affect the supply of termination power to the
    SCSI bus.
ACCEPT

    60-(E) page 119 - 8.3.8 -The following statement needs to be added
    after the second paragraph (immediately before table 104):

    Logical units that contain cache memory shall implicitly perform a
    SYNCHRONIZE CACHE command (see SBC) for the entire medium prior to
    entering into any power condition which prevents access the media (eg
    the spindle being stopped).

    The logical unit shall use the power condition page to control the
    power conditions after a power on or a hard reset until a Start/Stop
    Unit command is received that sets power conditions.
ACCEPT

    61-(E) page 120 - figure 2 - Make the decision boxes into the
    traditional shape.
ACCEPT

    62-(E) page 123 - After table 109 the following statement needs to be
    added: 'The peripheral qualifier field and the peripheral device type
    field are defined in x.x.x.'
ACCEPT

    63-(E) table 110 - table 111 - The values should be 0h,1h,2h,3h,and 4h.
ACCEPT

    64-(T) 9. - This section should be removed. See comment 1.
REJECT 


Milligan (Seagate) comments on SPC attached to No ballot:

1) Two factors seem apparent upon review of the SPC. The editor has done an
   admirable job and X3T10 should have allocated time for a page by page
   review of the document. The latter factor has contributed to the fact I
   was unable to allocate sufficient time to do a complete the review. This
   has been further aggravated by mid-air turbulence during dinner performing
   a reset upon my unsaved comments during suspend mode.
ACCEPT The editing meetings were held on 17 and 18 April, and 10 May.

2) Normative requirements should not be included in the Foreword.
ACCEPT Remove every occurrence of "shall" from the Forward.

3) There is a grammatical error in the first line of the Revision Information
   but it will soon disappear.
NICE

4) Referring to the first footnote, what are the changes that affect SBC?
ACCEPT issues resolved with SBC editor.

5) What is the meaning of the last line of the Introduction?
ACCEPT Change the last sentence to: "The information in the Annexes applies to
       all the SCSI-3 command standards documents."

6) The second sentence of the second paragraph of clause 1 Scope is
   confusing, possibly redundant to the third sentence, and should be
   deleted.
ACCEPT Replace the last two sentences with: "This standard defines the SCSI
       commands that are mandatory and optional for all SCSI devices."

7) In the second paragraph move the "also" from the first sentence to the
   last sentence.
ACCEPT

8) Add "host" to the definitions.
ACCEPT Take the definition of host from 6.1.1 but add that the host typically
       functions as an initiator.

9) Referring to Figure 1, I thought SAM was "Architectural". Delete "P" from
   "P1394". Revise the SSA boxes to agree with the new revised SSA
   architecture.  Also delete X3T10.1.
REJECT SAM is Architecture.
ACCEPT changes to roadmap, see Symbios comments.

10)In 3.1.13 make "sets" singular.
ACCEPT

11)In 3.1.14 change "tast" to "task". This suggests that a spell check should
   be run. Also change "in which task may" to "in which a task may".
ACCEPT

12)Why does 3.1.14 preclude parallel processing by a target (LUN?)? Perhaps
   this is a SAM comment.
REJECT The current definition is ok.

13)In 3.1.18 "illegal" and "reserved" should not be synonyms.
ACCEPT Delete the "(reserved)".

14)Referring to 3.1.25, what are the definitions of the other usages?
ACCEPT Change as per the IBM comment.

15)Referring to 3.1.28, move "optional" to keywords and change "must be" to
   "shall". (A global search should be done on "must".)
ACCEPT

16)In 3.1.30 change "Implementation of the reference item is defined" to
   "Requirements for the reference item are defined".
ACCEPT

17)In 3.1.32 replace "clause ?" with the definitive clause.
ACCEPT

18)In 3.1.42 replace "to initiators" with "to one or more initiators".
ACCEPT

19)In 3.1.43 replace "may be used differently in various implementations" to
   "may be vendor defined".
ACCEPT

19)I think the title of 3.2 should be changed from "Symbols and
   abbreviations" to "Acronyms". There does not seem to any symbols or
   abbreviations in the clause.
ACCEPT

20)In that clause, as an acronym definition, I think SCSI-3 should be dropped
   from the MMC definition.
REJECT SCSI-3 is in the name of the MMC standard.

21)In 3.3 I think the definition of hexadecimal should be changed from
   "Numbers immediately" to "Numbers or upper case letters immediately".
ACCEPT

22)In clause 4 delete the second, confusing, sentence in favor of the third
   sentence which correctly states the requirement.
ACCEPT

23)In 4.1 "Status" does not match the convention defined by 3.3.
REJECT The current usage matches similar usage throughout the document.

24)Admittedly I remain somewhat confused by the obtuse language selected for
   SCSI-3, but as I have understood it, device server is more closely aligned
   with a LUN than with a target, especially when the LUNs are each different
   device types, consequently I question "in a target is a device server" in
   the last paragraph of 4.1.
ACCEPT The usage of target, LUN, and device server were reviewed at the
       editing meeting(s).

25)Beginning, I believe, with 4.2 the term "Data-Out buffer" is used. This
   term appears to be an inadvertent insertion of a vendor specific
   implementation detail that is inappropriate for the standard. This clause
   and other clauses revealed by a global search should be purged of the
   implementation detail.
REJECT The current wording is the correct SAMinizing of the SCSI-2 text.

26)In clause 5 the second  sentence states the model is not intended to
   define any requirements. The third  sentence defines a requirement. At one
   time I proposed that models should not include requirements. I believe I
   lost  this argument but I do not recall for sure. (Having lost the
   argument, I think, I am inclined to include requirements, not found
   conveniently in other clauses, in the model of SBC.) However, regardless
   of the X3T10 decision on the general issue, the last two sentences of
   clause 5 should not contradict each other.
ACCEPT Replace the paragraph with: "This model describes the general
       characteristics expected of SCSI-3 devices.  All SCSI-3 devices shall
       conform to the SCSI-3 Architecture Model (SAM)."

27)In 5.1.1 it is alleged that the INQUIRY includes the "standard level"
   implemented. This is not true, I lost on a proposal to do that. INQUIRY
   not only does not provide the standard level, it does not even include
   which standards are implemented. It is true that it allows a delinquent
   implementation to report SCSI-3 approved version (a meaningless
   definition) but it is not true that information is provided as to which
   SCSI-3 standard the implementation was referring to.
REJECT The ANSI approved version field remains in the standard INQUIRY data;
       however, the name was changed to ANSI version in the editing
       meeting(s).

28)"Powerful features" are in the eye of the beholder and part of the
   marketing boiler plate, in 5.1.3 replace "other powerful features when
   used in conjunction with the RECEIVE DIAGNOSTIC RESULTS command, but this
   capability is optional" with "other optional features used in conjunction
   with the RECEIVE DIAGNOSTIC RESULTS command."
ACCEPT  Delete the word powerful.

29)In 5.2 replace "is responsible to"  with "should".
ACCEPT

30)Referring to 5.3, I don't think reservations are used to protect from
   accidental modification. The modification is not accidental. I think they
   are used to protect the sequence of data modifications.
ACCEPT Change "to protect shared data from accidental modification" to "to
       share and protect data or resources."

31)Having read persistent  reservations, my impression is that the
   nonpersistent reservations are more persistent that the persistent
   reservations. I suggest replacing "nonpersistent" with "mandatory".
ACCEPT Delete the clause containing "nonpersistent".

32)Change "Extent reservations may place restrictions" to  "Extent
   reservations place restrictions". For the same reason delete "may" in the
   third paragraph of 5.3.
ACCEPT

33)In the third paragraph change "The reservations do persist" to  "The
   reservations persist" and delete ", so that recovery can be managed
   without requiring complete reinitialization of the system".
ACCEPT delete the "do".  Change "so that" clause as shown in notes.

34)Change "command's operations contains" to "command contains".
ACCEPT

35)Change "Commands that retrieve or alter information about the device
   server's operating state shall conflict with the logical unit reservation
   unless otherwise specified." to "Commands that retrieve or alter
   information about the device server's operating state shall be rejected
   with a reservation conflict response unless otherwise specified." Make a
   similar repair to the next sentence.
ACCEPT  Additional changes were made at the editing meeting(s).

36)I have many marks on other pages through page 72 but have not been able to
   allocate sufficient time to write them up. I hope to continue the write-up
   and mark up in preparation for the editing session requested by comment
   (1). My next comment is out of sequence with the remaining comments I have
   in the queue.
ACCEPT

37)Referring to Table 5 and the balance of the document I note that the SET
   CAPACITY command voted in by X3T10 has not yet been edited into the
   document.
WITHDRAWN

I apologize for not being able to provide a full review by the closing date 
of the letter ballot. To avoid such an apology in the future I do request 
that X3T10 establish, or reestablish an editing review session prior to the
forwarding of each proposed standard. In submitting these, and the pending
comments I am definitely not requesting a protracted delay in the forwarding
since I wholeheartedly support regular publication of the standards which 
have not become obsolete or academic.

Final Comments on SPC Revision 9

As I recall, the editing session in San Jose completed the comments through 
Table 104. These are the comments I had after Table 104 based upon Revision 9.

38) indicates a logical unit shall should be changed to indicates the logical
    unit shall.
ACCEPT

39) Regarding Figure 2 define Idle and Standby somewhere.
ACCEPT in part.  Definitions have been added to the glossary for 'idle
       condition' and 'standby condition'.  The idle bit and standby bit need
       no glossary definitions.

40) Regarding Table 105, what happened to John Lohmeyers universal
    identification page? Or is it 83h?
ACCEPT That's right, it's 83h.

41) The first paragraph of 8.4.1 states that the contents of this data is not
    defined. The last paragraph defines the contents of the data. I suggest
    deleting the last sentence of the first paragraph.
ACCEPT

42) Should the last phrase of clauses 8.4.1 and 8.4.2 instead be one or more
    null (00h) characters? In other words after a null is encountered can the
    balance of the logical block be something other than null?
REJECT The null character marks the termination of the string.  What
       appears after the null is irrelevant and not a proper subject
       for standardization.

43) In 8.4.2 replace returns with contains.
ACCEPT

44) 8.4.3 uses the phraseology optional device identification page which is
    good but why don't the other optional pages have similar phraseology?
ACCEPT Remove 'optional' from 8.4.3.

45) The first paragraph states zero or more identification descriptors. But
    the second paragraph states Device identifiers shall be assigned.
    Consequently how can there be zero?
ACCEPT add "if any" to the second paragraph.

46) Change the SCC to SCC.
ACCEPT

47) Note 58 allows device identifiers to be vendor-specific in their
    construction but device identifier is not actually a defined term. Does
    this mean they can construct a new definition for the elements of page
    code 83h?
ACCEPT Add reference information to note 58 to clarify the object being
       discussed.

48) In Table 110 deleted only as it sounds demeaning.
ACCEPT

49) Regarding Table 111 add IEEE EUI-64 and X3.230-1994 to the normative 
    references.
ACCEPT in part.  Normative reference added for X3.230-1994 but not for IEEE
       EUI-64.  It's unclear whether EUI-64 is a standard.

50) Should the example including Table 112 be part of a note or an annex?
REJECT the current format is the best we can do within the constraints of the
       word processing software being used for the SPC.

51) Which Table 111 value does this example apply to?
ACCEPT notes have been added to guide the reader through the example.

52) In table 112 why is the quotation mark ahead of the company name?
REJECT the quotation mark is the ASCII value for 22h.  Although 22h is the
       byte count for the name string, it must be translated into ASCII in
       accordance with the rules for this type of data presentation.  Most
       programming engineers recognize this data presentation method and will
       not be confused by the quotation mark.

53) In 8.4.4 change specified to defined.
ACCEPT

54) I think 8.4.5 should also reference Table 105 or if that is too many 
    pages away clause 8.4.
ACCEPT added reference to clause 8.4.

55) The first sentence of the last paragraph of 8.4.6 states the data is
    vendor-specific. The next sentence states a definition for the data.
    Either it is vendor specific or it is not. Choose one.
ACCEPT reworded to clarify that the serial number is vendor-specific, but the
       ASCII data used to represent it is not.

56) Change the title of clause 9 to Commands for processor device types.
ACCEPT

57) In 9.1 and 9.2 add the phrase If reserved.
ACCEPT

58) Why can the RECEIVE command be issued to any LUN but the SEND only to 
    LUN zero?
REJECT A SEND can be sent to any LUN, but a SEND with the AER bit set to one
       can only be sent to LUN 0.

59) Regarding 9.2, add SCSI-2 to the normative references.
ACCEPT

60) In 10.1 Table 120 states reserved for device type pages. This is a 
    device type page. I think in this table it should be just plain reserved.
ACCEPT

61) Table 121 also states see specific device type for definition. This is a
    device type page. I think in this table it should be just plain reserved.
ACCEPT

62) In the first paragraph of Annex A change conflict clause 7 to conflict
    with clause 7.
ACCEPT

63) Delete the last sentence of the first paragraph.
ACCEPT

64) In the first paragraph of A.2 change the application client to an 
    application client.
ACCEPT

65) Table A.1 has at least 10 shalls and nearly as many in Tables A.4,  A.6, 
    A.8  Delete them all and add an s to the following word. Except for the
    shall nots which should be replaced with does not.
ACCEPT

66) In Table A.1 replace in which log parameter value has changed with in
    which a log parameter value has changed
ACCEPT

67) In the first line above Table A.2 and several lines above Table A.3, A.4,
    A.5, A.6 change the possible to possible.
ACCEPT

68) Regarding binary format clause A.1.1 contradicts the last two rows (not
    lines) of Table A.2 and the last row of Table A.6, A.8.
ACCEPT

69) Three lines above Table A.5 replace selected for saving shall be saved 
    with selected for saving are saved.
ACCEPT

70) Eliminate the four shalls in Table A.6 with appropriate wording
    adjustments.
ACCEPT

71) In A.4 replace things with items. Replace What those things are is left 
    up to the imagination of implementors. with Items which are logged are
    vendor-specific. Delete the balance of the paragraph.
ACCEPT

72) Delete the next two sentences.
ACCEPT

73) In Table A.7 replace the application client with  an application client 
    in two places.

74) Above Table A.9 change describes how the target shall deal with exception
    conditions with describes target logging exception conditions.
ACCEPT however the editing meeting developed different wording changes.

75) The pseudo code in A.4.3 should have an ) at the end of (a).
ACCEPT

76) Item (f) addresses the condition of ACA supported. What if ACA is not
    supported?
ACCEPT added wording after table A.9 that describes the non-ACA case.

77) I think tables B.1, B.2 and B.3 should have a statement about blank codes.
ACCEPT

78) I think table B.2 should have a statement about how to deal with lack of 
     synchronization between SPC command code definitions and other command
     set code definitions.
ACCEPT however, we're still working on the details of this.


Symbios Logic comments on SPC attached to Yes ballot:


1. (E) 2nd page
    The internet address for subscribing to the SCSI Reflector
    is now: majordomo at symbios.com
ACCEPT

2. (E) 2nd page
    In the Patent Statement, "holder's" should be "holders".
ACCEPT

3. (E) Pages x & xi
    Consider deleting these two pages; they add almost no value.
ACCEPT Yes, the notes table of contents should be deleted (along with the
       revision information) prior to public review.

4. (E) 1, Page 1, Figure 1
    This figure is out of date.  Consider adding "at the time it was last
    revised" to the end of the sentence above the figure.  Consider updating
    the figure based on the file provided separately.
ACCEPT

5. (E) 7.13.2, Page 51, Table 37
    The "Additional length (n+8)" should be "Additional length (n-7)".  This
    error may have resulted from the second sentence in the description of 
    this field (which adds no real value and should be deleted).
ACCEPT

6. (E) 7.13.3, Page 52, Table 38
    Same error as described in comment #5.
ACCEPT


Unisys comments on SPC attached to Yes ballot:

1)  Section 7.13.2 PERSISTENT RESERVE IN - Page 52, first paragraph 
    following table 37.  "The Generation value is a 32-bit counter in the
    logical unit that shall be incremented every time a PROUT command
    requests a Register, a Preempt, or a Preempt and Clear operation."  
    This seems to exempt the Clear operation.  Or is the intention that
    reference to the "Preempt and Clear operation" also covers the Clear
    operation?
ACCEPT, provided the next General SCSI Working Group accepts the change.

2)  Section 17.3.3 PERSISTENT RESERVE IN - Page 52, second paragraph 
    following table 38. The additional length definition in this paragraph 
    is identical to that used in 17.3.2 only 3 paragraphs above, so why not
    reference it, rather than repeat it?
REJECT Why have the reader scanning the document for references when the text
       is present and ready to read.


Unitrode comment on SPC attached to Yes ballot:

    Fast-20 1071D should be added to Section 1.
ACCEPT


Late comment from Western Digital:

In SBC, the PREVENT ALLOW command is a TWO bit field, and in SPC 
it is a ONE bit field. It seems to me that the TWO bit SBC version 
should be moved into SPC.  The two bit field seems pretty generic; 
it has no inherent 'disk-ness'.
ACCEPT




More information about the T10 mailing list