Summary of SAM Rev. 13 to Rev. 15 Changes (X3T10/94-173R0)

Charles Monia, SHR3-2/W3, 237-6757 01-Sep-1994 1432 monia at starch.enet.dec.com
Thu Sep 1 11:30:56 PDT 1994


From:     Charles Monia
To:  Members of X3T10

Subject:  Summary of SAM Rev. 13 to Rev. 15 Changes
          (X3T10/94-173R0)

Reference (a): Results of Working Group Discussion on SAM,
               Rev. 13 Review Comments (X3T10/94-129R0)

          (b): Dual Port ECO (X3T9.2/90-136R3, X3T9.2/91-
     149R0, X3T9.2/93-041R2)

This document contains the resolution status for
written technical comments received for SAM rev 13. It
also summarizes other technical changes between the
last formally reviewed version of SAM (revision 13) and SAM
revision 15 which was distributed in X3T10 1994 mailing 4.

In addition to comment resolutions, the changes in SAM rev 15
include the dual port ECO specified in (b) and the following:

     1.   Clause 2 was extended to define the criteria for
          SCSI-3 conformance that apply to implementa-
          tions and SCSI-3 standards.

     2.   The initiator identifier was redefined to be a
          protocol-specific task parameter internal to the
          logical unit. This change was made to support
          the dual port ECO and to properly reflect the
          way implementations, such as SBP, define this
          parameter.

     3.   As the result of the committee's decision to
          make CDB parameter checking optional, SAM
          requires all standards to specify commands for
          each option which return data indicating wheth-
          er or not that option is supported.

In revision 15 of SAM, alterations are indicated with change
bars and strike-through.

Status of Proposed Responses to SAM Rev. 13 Written
Comments

The status of technical or informative comments from reference
(a) is given here. Each is identified by the number from refer-
ence (a) and the initials of the company with which the com-
ment author is affiliated. I have combined comments from
different authors where appropriate.

The document references in parentheses refer to items within
SAM revision 15.

The status of editorial comments are not included in this sum-
mary.

Comment:  HP 012, IBM 2 - Section 2.1.81, Page 12,
          Paragraph 1 (clause 4.1.86, pp 15)

     Pending task is undefined, yet it is used in this defini-
     tion.

Proposed Resolution:
     
     Comment accepted.
     
     A definition for "pending task" will be added to the
     glossary.

Status:

     Definition added to glossary (see clause 4.1.51).

Comment: HP 023 (I)  Section 3.1, Page 22, Paragraph 5 

     Last sentence.  Everything humanly possible should be
     done to eliminate the use of internal behavior as a
     description of how something works.  Every item in this
     standard should use externally observable behavior to
     describe the implementations.  If internal behavior is
     required, then we have not done our jobs.

     Remove this sentence and all internal behavior descrip-
     tions.

Proposed Resolution:

     Comment rejected.
     
Status:

     No change made to document.


Comment:  028 (T)  Section 3.5.2, Page 31, Paragraph
          Last (5.5.2, pp 32, paragraph last)

     Remove this paragraph.  We state everything by arrival
     order so mentioning that we assume in order confuses
     and implies a requirement on the service delivery sub-
     system.  Removing the paragraph does not change the
     meaning of arrival.


Proposed Response:

     Comment rejected.

     This paragraph defines how the model deals with re-
     quest-response ordering. The second sentence in that
     paragraph states:

     "[The assumption of in-order delivery] is made to simpli-
     fy the description of behavior and does not constitute a
     requirement."

Status:

     No change made to document.

Comment: HP 030 (T)  Section 3.6, Page 33, Paragraph 5
(clause 5.6, page 33)

     The target is listed as not being able to originate task
     management functions.  What is the ruling then on the
     FCP target being able to issue an abort exchange?  Is
     it legal according to SAM for a target to detect that an
     error has occurred and abort the task due to the detect-
     ed error?

Proposed Response:

     A target-initiated "abort exchange" indicates that there
     is a problem which cannot be reported with a CHECK
     CONDITION status. This kind of error may be charac-
     terized as a "Service Delivery or Target Failure".

Status:

     No change to document.


Comment: HP 031 (T)  Section 3.6.1, Page 34, Paragraph 1
(clause 5.6.1, pp 34)

     Since an initiator can have more than one initiator
     identifier, how does a target tell the difference between
     initiators?  Is this going to be protocol specific, left
     undefined?  In FCP for example, a login can tell the
     difference.  In parallel it is more problematic since there
     is no way to tell if they are the same or if they are
     different.

Proposed Response:

     A target can't tell the difference and will implicitly con-
     sider two different initiator identifiers to represent two
     different physical devices.
Status:

     No change to document.


Comment: HP 032 (T)  Section 3.6.2, Page 35, Paragraph 10
(clause 5.6.2, pp 35)

     There is no need for a base logical unit.  It is no differ-
     ent than a logical unit zero.  As a matter of fact they
     both have the same LUN.

Proposed response

     Comment accepted.

Status:

     Deleted from revision 15.


Comment: HP 033 (T)  Section 3.6.3, Page 36, Paragraph 5
(clause 5.6.3, page 36, paragraph 5)

     The task set definition, as written, does not allow more
     than one untagged task in the task set at a time.  I
     would suggest the following notation:

          Task Set = 0{Tagged}+ 0{Untagged}

Proposed response:

     Comment accepted.


Status:

     Change made to object definition 6 (see clause 5.6.3,
     pp 36).


Comment: HP 041 (T)  Section 4.1, Page 43, Paragraph 3
(clause 6.1, page 43, paragraph 3)

     Why is the statement allowed that says that media may
     be modified even if there is an invalid parameter or
     invalid field in a CDB?  What cases would possibly
     allow you to modify media when the command is
     deemed to be incorrect?


Proposed Response:

     The invalid parameters referenced in the draft were
     incorrectly assumed to include command parameter
     data (i.e.. the parameter data sent during the Data Out
     phase). The requirement stated in  SAM should only
     apply to parameters in the CDB. In that case, SAM
     should require the logical unit to abort the command
     without modifying the media.

     The sentence will incorporate the following SCSI-2
     wording from clause 7.2, pp 79 of rev 10k.

     "For all commands, if there is an invalid parameter in
     the command descriptor block then the target shall
     terminate the command without altering the medium."

     The sentence will be changed to read:

     "For all commands, if the logical unit detects an invalid
     parameter in the command descriptor block then the
     logical unit shall end the command without altering the
     media."

Status:

     Change incorporated. See clause 6.1, page 44, para-
     graph 2.


Comment: HP 042 (T)  Section 4.1.2, Page 44, Paragraph 2
(clause 6.1.2, pp 45, paragraph 2)

     The first sentence, as worded, says that the ACA will
     never be cleared. It should simply say that if the bit is a
     one, then the ACA shall be  treated according 4.6.


Proposed response:

     Comment accepted.

Status:

     Change incorporated. See clause 6.1.2, pp 45, para-
     graph 2.


Comment: HP 043 (T)  Section 4.1.2, Page 44, Paragraph 3
(clause 6.1.2, page 45, paragraph 2)

     Why is ACA = 0 required?  If I want to build a SCSI-3
     device, you are requiring that I keep the old CA bag-
     gage even if I don't intend to  operate with any SCSI-2
     initiators.  This is an unnecessary requirement which
     prevents SCSI-4 (yikes!) from eliminating support for
     CA entirely.

Proposed response:

     Comment accepted.


     The draft standard will be revised to indicate that sup-
     port for an ACA bit value of zero is a logical unit option.

Status:

     Change incorporated. See clause 6.1.2, pp 45, para-
     graph 2.

Comment:     IBM 9. Page 46 and other places throughout the
document (clause 6.2, pp 46)

     Statuses and messages have been changed from
     'Queue' to 'Task Set'. Was this change agreed to by the
     committee? If so OK if not it should be voted on.

Proposed response:

     Comment rejected.

     1.   There are no messages defined in SAM.

     2.   The use of "task set" instead of "queue"
          throughout SAM was at the request of review-
          ers, who felt that  the task set concept more
          accurately reflected the new queuing model.
          The working group consensus reached in Janu-
          ary reaffirmed that decision (see X3T10/94-
          028R0 , response to item 39 on page 35).

Status:

     No change to document.

Comment: HP 045 (T)  Section 4.3.2, Page 48, Paragraph
(clause 6.3.2, pp 50)

     An indication and response are required.  The model
     you present here does not follow the confirmed servic-
     es model presented earlier.

Proposed response: 

     Comment rejected.

     1.   The only requirement for confirmed protocol
          services is the return of a confirmation. The
          model does not require a confirmed protocol
          service to generate an indication to or receive a
          response from the ULP. This is consistent with
          the protocol service interface defined for P1394
          and the definition of a confirmed protocol ser-
          vice presented in clause 3.7.

     2.   The model assumes that the application client
          is unaware of  the process of transferring data
          to or from it's data buffer. I believe this view
          reflects how initiators and host applications are
          implemented.

Status:

     No change to document.

Comment: HP 046 (T)  Section 4.3.3, Page 49, Paragraph
(clause 6.3.3, pp 50)

     An indication and response are required.  The model
     you present here  does not follow the confirmed servic-
     es model presented earlier.


Proposed response:

     See item HP 045.

Status:

     No change to document.


Comment: HP 048 (T)  Section 4.5.2, Page 52, Paragraph
(clause 6.5.2, pp 53)

     Considering the confusion over linked commands in the
     past, perhaps we should add in a statement that clari-
     fies whether or not the linked command is an implied
     reservation or not.  We have argued this one in com-
     mittee a number of times and concluded only that it
     was not clear in the current documents.  I suggest we
     try to add into the description the text to make it clear
     what we do in this case.

Proposed response.

     Issue to be resolved by the working group.

 Status:

     Open. No change to document.

Comment: IBM 17 Section 4.6.1 (clause 6.6.1)

     After careful study of this section there  seems to be
     several concepts defined in the SCSI-3 Queuing  Model
     that are not here. The missing concepts are list below:

     [Technical editor's note: the cited paragraph numbers
     and accompanying text within quotation marks are
     extracted from the queuing model description which
     appears in annex B of SAM, rev 15.]

       "2.1.2 Response to Auto Contingent Allegiance Condition

       If a Task becomes a current task because of a previous
       request for information that information shall be suspend-
ed
       until the ACA is cleared."


     Proposed response:

          This requirement is specified in clause 8.3.2 pp
          70.

     Status:

          No change to document.

       "2.1.3 Auto Contingent Allegiance Processing

     All SCSI operations are permitted while processing an
     ACA Task."

     Proposed response:

          It is not clear what is meant by "SCSI opera-
          tions". If this refers to task management func-
          tions then this concept is already included in
          SAM.

     Status:

          No change to document.

       "2.1.4 Clear Auto Contingent Allegiance Task Manage-
ment
             Function

       The target shall clear the Auto Contingent Allegiance and
       complete the current Task on acceptance of this task
       management function.

       If the target accepts a Clear Auto Contingent Allegiance
       Task Management Function and no Auto Contingent Alle-
giance
       Condition is in effect for that initiator on that task set,
       then the target shall complete the current Task."


Proposed response:

     Comment rejected.

     The behavior described above (clearing the current
     task) seems to reflect a SIP requirement. The existing
     text (clause 7.3, pp 63) describes the protocol-indepen-
     dent requirements.

Status:

     No change to document.


"Section 2.1.4

       If a Clear Auto Contingent Allegiance Task Management
       Function occurs when an ACA Task is pending then the
ACA Task
       shall be aborted and the auto contingent allegiance shall
be
       cleared."


Proposed response:


     Comment rejected.
 
Status:

     The required behavior is specified in clause 8.2.1, item
     f, pp 69.

Comment: IBM 7, IBM 12, IBM 13, HP 050 (T)  Section 4.6.1.1,
Page 54, Paragraph 1 (clause 6.6.1.1, pp 54)

     "The task shall then be entered into the task set if it
     meets all other conditions for acceptance."  This does
     not convey that the task is the first one to be executed
     as was done in SCSI-2 CA.  Stating that it is accepted
     is not sufficient.  It must be stated that it is executed
     next and that it is untagged.

Proposed Response:

     When describing logical unit behavior for the case
     where the ACA flag is clear, SAM will be modified to
     replace all behavioral descriptions with references to
     the SCSI-2 standard.

Status:

     Clause 6.6.1.1 on page 54 contains the changes de-
     scribed above.

Comment: IBM 14 *Page 54 section 4.6.1.1 2nd paragraph
(clause 6.6.1.1, pp 64)

     [The first sentence] states 'The completion of the new
     task with...'. I do not know what is meant by 'new task'
     in that sentence. I assume it is an attempt to reword
     the 2nd paragraph in section 2.1.1 of the SCSI-3 Queu-
     ing Model but the message seems to have been lost.

Proposed response:

     The draft will be modified to clarify the antecedent
     reference.

Status:

     Document modified. See SAM revision 15, clause
     6.6.1.1, pp 64, last paragraph.
 
Comment:   IBM 15. *Page 54 section 4.6.1.1 3rd paragraph (
clause 6.6.1.1, pp 55)

     [The] first sentence should  be changed to '...faulting
     command, then the auto contingent  allegiance condi-
     tion shall not be cleared and a new task shall be  en-
     tered into the...'

Proposed response:

     Comment rejected. The last sentence of the cited para-
     graph describes the required behavior.

Status:

     No change to document.

Comment:  IBM 16. *Page 54 section 4.6.1.2, 3rd para-
          graph last sentence (clause 6.6.1.2, pp 55)

     I have no idea what this sentence means.

Proposed response:

     The paragraph you refer to states:

     "The state of all tasks in the task set when an auto
     contingent allegiance condition is cleared shall be mod-
     ified as described in clause 6. A task having the ACA
     attribute shall be aborted".

     This paragraph will be reworded to delete the last sen-
     tence.

Status:

     Clause modified as described above ( see 6.6.1.2, pp
     55, last sentence).

Comment HP 051 (T)  Section 4.6.1.2, Page 54, Paragraph 2
(clause 6.6.1.2, pp 55)

     There should be no requirement for me to support the
     setting of the  ACA bit to zero.

Proposed response

     See response to item HP 043.

Status:

     See HP 043 status.


Comment:  IBM 19 section 4.6.2 (clause 6.6.2, pp 55)

The list of things that can occur to free up tags is not listed.
The list out of the SCSI-3 Queuing Model follows:

       "2.2 Duplicate Tag Handling

       When issuing a tagged task the initiator shall not
       reuse the tag to create a new task until:

       -A service response of Command Complete is received
with a
        status other than INTERMEDIATE or INTERMEDIATE-
CONDITION
        MET.
       -A service response of Service Delivery or Target Failure
is
        received. In this case, system implementations shall
        guarantee that the task associated with that command
has
        been terminated.
       -A power on condition occurs.
       -A Target Reset Task Management request occurs.
       -An Abort Task Management request occurs.
       -An Abort Task Set Management request occurs.
       -A Clear Task Set Management request occurs.
       -A unit attention of TASKS CLEARED BY ANOTHER
INITIATOR is
        reported.
       -A unit attention of POWER ON, RESET or TARGET
RESET is
        reported."


Proposed Response:

     Comment rejected. The above list is included in clause
     6.4 of SAM (pp 51).

Status:

     No change to document.

Comment: IBM 20, Page 58 section 4.6.5 (clause 6.6.5, pp 59).

     In this section it must me made clear that the clearing
     of the unit attention condition does not automatically
     clear the auto contingent allegiance condition if the
     ACA bit is set to one.

Proposed response:

     Comment accepted.

Status:

     Open. Proposed change was inadvertently omitted from
     revision 15.

Comment:  HP 053 Section 5, Page 60, Paragraph 12
          (clause 7, pp 61, paragraph 10)

     Abort Task should not be required.  It is only required if
     tagged tasks are supported.  Abort Task Set makes
     more sense to be required than does Abort Task

Proposed response:

     Comment accepted.

Status:

     Clause 7, paragraphs 10 and 11 on pp 61 contain the
     agreed change.


Comment: HP 056 (T)  Section 5.4, Page 63, Paragraph 1
(clause 7.4, pp 64, paragraph 1)

     "All data for all terminated tasks shall be cleared."  Two
     things.  First, it should be aborted tasks not terminated. 
     Second, the data cleared is the sense data.  This im-
     plies that I must flush my buffers for any data that
     these tasks may use.  This is not the intent of the
     statement.

Proposed Response:


     1.   "Terminated' will be replaced with 'aborted'.

     2.   The corresponding wording in the SCSI-2 spec.
          (rev 10k, section 6.6.4, pp 57, first paragraph)
          says:

     "....All pending status and data for that logical unit or
     target routine for all initiators shall be cleared."

     While the wording in SAM should be changed to agree
     with the above, it's not obvious that sense data is in-
     cluded. This item should be discussed at the May work-
     ing group.


 Status:

     1.   The issue of whether or not sense data is
          cleared was not resolved at the working group.
          The SAM technical editor will post a proposal
          on the reflector to explicitly include sense data
          in the above requirement.

     2.   The wording change in 1 above was incorporat-
          ed in revision 15 (see clause 7.4, pp 54, para-
          graph 1).

Comment:  HP 057 (T)  Section 6.1, Page 67, Paragraph 5
          (clause 8.1, pp 68, paragraph 3)

     Your current task definition does not include a task
     which is sending status.  Current does not mean only
     data, it includes status or any other information trans-
     fer.

Proposed response:

     Comment accepted.

Status:

     Incorporated in SAM revision 15 (see clause 8.1, pp
     68, paragraph 3 and clause 4.1.16).

Comment: HP 062 (T)  Section 6.2.1, Page 68, Paragraph 5
(clause 8.2.1, pp 69)

     The occurrence of the ACA condition with QErr set
     does not effect the task set.  The CLEARING of the
     ACA condition when the QErr bit is set  causes the
     tasks to be cleared.

Proposed response:

     Comment accepted.

Status:

     Change incorporated in SAM revision 15 (see clause
     8.2.1, pp 69).

Comment: HP 063 (I)  Section 6.2.1, Page 68, Paragraph All

     This list groups a lot of items into the category of abort. 
     Many of these have no correlation to an abort as it is
     known today.  For example, if I am reading from the
     media and get an Abort Task for a command not "inter-
     nally active", I just delete it and continue with the cur-
     rent  task.  If I get a reset, I blow everything away,
     including the read from the disk.  These are very differ-
     ent, yet you are grouping them into the same term.

Proposed Response:

     The paragraph will be reworded to clarify that the task
     abort events listed are relative to a specific task. The
     state diagrams show how the state of that task chang-
     es in response to these events.

Status:

     Open. The change called out in the proposed response
     was inadvertently omitted from revision 15. 

Comment: HP 064, IBM 22, Section 6.3, Page 70, Paragraph
All (clause 8.3, pp 69)

     This entire section is extremely confusing.  It is making
     assumptions about internal states of the device and is
     not a model based upon the externally observable
     behavior of the device.  When we started work on the
     queuing model, we assumed that the internal states of
     a device were out of bounds for discussion.  This mod-
     el has put everything back into the internals of a de-
     vice.  I cannot vote to accept any model which is "de-
     vice-centric" rather than "bus-centric".

Proposed Response:

     The section on task set management will be simplified
     by reducing the number of states and transitions. A
     section will be added for each task attribute which fully
     describes required task behavior.


Status:

     This clause has been rewritten as described above
     (see clause 8.3).


          Summary of Other Changes

Throughout:

     1.   Changed "Command Complete" service re-
          sponse to "Task Complete".

     2.   Changed "service delivery interface" to "service
          delivery port" for consistency with the dual port
          ECO terminology.


Page 8, clause 2

     Added requirements  precedence and policy for deter-
     mining whether or not standards and implementations
     conform to SAM and other SCSI-3 standards.

Page 12, clause 4.1.30

     Hard reset: Added dual port changes, replaced func-
     tional description with pointer to the applicable clause.

Page 13, clause 4.1.53

     Added definition for "port".

Page 23, clause 4.8

     The state table notation was deleted. This notation is
     no longer used by SAM. See the previous section for
     more information.

Page 44, clause 44, note:

     Added requirement for command standards to provide
     a way for an initiator to obtain information from a logical
     unit about the options it supports.

Page 47, clause 6.3, paragraph 1


     Definition of indication and response protocol services
     by a protocol standard is now optional.

Page 60, clause 6.6.6, paragraphs 2 and 3

     Added dual-port requirements.

Page 64, clause 7.6

     Added "TARGET RESET OTHER PORT" task manage-
     ment function.

Page 66, clause 7.8, paragraph 1

     Definition of indication and response protocol services
     by a protocol standard is now optional.

Page 68, clause 8, paragraph 3

     Defined conditions that prevent a task from being en-
     tered into the task set.

Page 78, Annex A

     Added SAM support for dual-port devices.

Page 81, Annex B

     Was previously annex A.





More information about the T10 mailing list