SAM forwarding letter ballot results

John Lohmeyer jlohmeye at ncr-mpd.FtCollinsCO.NCR.COM
Tue May 24 16:22:58 PDT 1994

Attached are the results of the X3T10 letter ballot on forwarding the SAM
document to X3.  While the ballot passed, X3T10 must attempt to resolve the
negative comments.  Many comments were resolved at the SCSI working group
meeting last week.  Some are not resolved, yet.  If any cannot be resolved,
X3T10 may forward the SAM document with unresolved negatives to X3.  In this
case, the unresolved negatives and the committee responses accompany the
SAM document through the further processing.



SAM Letter Ballot Results:  49:3:0:7 = 59

Yes, with comment:  AT&T Global Information Solutions

No:  Hewlett Packard, IBM, Quantum

Did not respond: AMD, Apple, Compaq, Harbor Electronics, Maxtor,
P.E. Logic, Samsung

NCR comment: "Delete annex A since it is temporary."

HP comment:
                            SAM Review Comments
			        Revision 13

#001 (E)  Section 1, Page 8, Paragraph 3

SCSI-2 is listed as X3.131-1992.  I believe it is actually X3.131-1994.

#002 (E)  Section 1, Page 8, Paragraph 6

SCSI -2 should be SCSI-2.

#003 (E)  Section 2.1.12, Page 9, Paragraph 1

The term being defined and it's use should be "completed command", not
"command complete".  This is consistent with terms like "aborted commands".
It also removed the ambiguity between this term and "Command Complete".

#004 (E)  Section 2.1.14, Page 9, Paragraph 1

This term should be "ended command", not "command ended".

#005 (E)  Section 2.1.32, Page 10, Paragraph 1

This term should be "protocol indication", not "indication" in order to
be consistent with terms like protocol service request, protocol service
response and protocol service confirmation.

#006 (E)  Section 2.1.58, Page 11, Paragraph 1

Why is the term "queue" defined?  I thought we had purged the term
|from the document.

#007 (E)  Section 2.1.61, Page 11, Paragraph 1

This term is, or should be, redundant with "protocol service request".
In general, I noticed that request, indication, response, and confirmation
are all listed twice, once alone and once with the "protocol service"
added in front.  I don't see the distinction between the two.

#008 (E)  Section 2.1.62, Page 11, Paragraph 1

This term is redundant with confirmed protocol service.  

#009 (E)  Section 2.1.62, Page 11, Paragraph 1

This should be called "request-confirmation transaction".

#010 (E)  Section 2.1.72, Page 12, Paragraph 1

This term is redundant with "device server".

#011 (E)  Section 2.1.74, Page 12, Paragraph 1

Remove, "...while in transit".  There can be service delivery subsystem 
failure without the transaction ever being "in transit".  For example,
by differential transcivers may be disabled on a parallel bus when a 
single ended device is plugged into the bus.  The data was never sent
out of the local system.  I think that removing this part of the sentence
removes the requirement to define what "in transit" means in all cases.

#012 (T)  Section 2.1.81, Page 12, Paragraph 1

Pending task is undefined, yet it is used in this definition.

#013 (E)  Section 2.1.84, Page 13, Paragraph 1

"Task aborted" should be "Aborted Task".  I also see this as a redundant
definition of aborted task.

#014 (E)  Section 2.1.85, Page 13, Paragraph 1

"Task completed" should be "Completed Task".  I also see this as a redundant
definition of completed command.

#015 (E)  Section 2.1.86, Page 13, Paragraph 1

What is an ended task?  Is it an aborted task, or a completed task?  Is
it redundant with other definitions.

#016 (E)  Section 2.1.8x, Page 13, Paragraph 1

Task Management Indication and Task Management Confirmation are not

#017 (E)  Section 2.1.93, Page 13, Paragraph 1

Termination Pending should have (task state) listed after the term.  It
is one of the states in your task state machine definition.

#018 (E)  Section 2.4, Page 15, Paragraph 1

The sense key shall be either "INVALID FIELD IN CDB" or "INVALID FIELD
IN PARAMETER LIST" depending upon where the invalid field is found.  The
statement, as it appears, would cause me to issue "INVALID FIELD IN CDB"
even when there is an error in the parameter list of a command.

#019 (E)  Section 2.5.1, Page 15, Paragraph All

Clean up the format of the columns.  They are hard to read.

#020 (E)  Section 2.6, Page 18, Paragraph 2

"...([input1][,input2]...]||" should be "...([input1][,input2]...||".
Remove one "]" at the end of the input section.

#021 (E)  Section 2.6, Page 18, Paragraph 10

The bullet item on the brackets should not be here.  This is the same
as the definition in the notation section (2.5.1).  I assume that you
could also include curly brackets in a procedute notation, but this is
not included in the bullet list.

#022 (E)  Section 3.1, Page 22, Paragraph 4

The bullet should be "c." not "c)".

#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 descriptions.

#024 (E)  Section 3.2, Page 23, Paragraph 1

Replace "request-response transaction" with "confirmed protocol service".

#025 (E)  Section 3.2, Page 23, Paragraph 3

"..., the request becomes pending upon reciept and complete when the
response is passed..." should be, "..., the request becomes pending 
upon reciept and completes when the response is passed...".

#026 (E)  Section 3.2.1, Page 25, Paragraph 1

"reading or writing to the media." should be "reading from or writing to
the media.".

#027 (E)  Section 3.2.1, Page 26, Paragraph 2

First sentence should be removed.  It is the definition of a task and
is redundant with the definition in the definition section.

#028 (T)  Section 3.5.2, Page 31, 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 subsystem.  Removing the paragraph does not change the meaning
of arrival.

#029 (E)  Section 3.6, Page 32, Paragraph Fig 12

The service delivery interface is part of the device, but is described 
in the notation as being part of the service delivery subsystem.  Either
the figures need to change to reflect this, or the notation needs to 
move the SDI into the device rather than in the SDS.

#030 (T)  Section 3.6, Page 33, Paragraph 5

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 occured and abort the task due to the
detected error?

#031 (T)  Section 3.6.1, Page 34, Paragraph 1

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

#032 (T)  Section 3.6.2, Page 35, Paragraph 10

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

#032 (E)  Section, Page 36, Paragraph 1

The task manager also controls the tasks bsaed upon the ACA status, the
tasks attributes (HEAD, ACA TAG, SIMPLE, ORDERED).  It does not control
them based soley upon the task management functions.

#033 (T)  Section 3.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

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

#034 (E)  Section 3.6.3, Page 37, Paragraph 1

Remove the reference to queue.  "Task Set (queue)" should be "Task Set".

#035 (E)  Section 3.6.3, Page 37, Paragraph 15 and 16

Tagged Task Address and Untagged Task Address are not very useful and
cause confusion.  You are implying that there is some special method
used to refer to a task when using task management functions.  There
isn't.  You refer to it in the same manner in which you do when you
create the task.  Eliminate these two items from your notation.

#036 (E)  Section 3.6.3, Page 38, Paragraph 4 and 5

"..protocol service request, The initiato r's", should be "...protocol
service request, the initiator's...".

#037 (E)  Section 3.7, Page 39, Paragraph 4

Change "...clause ?" to the correct reference.

#038 (E)  Section 4, Page 42, Paragraph 1

"...sense data. returned..." should be "sense data returned..."

#039 (E)  Section 4.1, Page 42, Paragraph All

The section 4.1 on page 42 is duplicated on top of page 43.  Remove one
of them.

#041 (T)  Section 4.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?

#042 (T)  Section 4.1.2, Page 44, 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.

#043 (T)  Section 4.1.2, Page 44, Paragraph 3

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

#044 (E)  Section 4.2, Page 46, Paragraph 2

Update the reference.  "?" should be "5.6".

#045 (T)  Section 4.3.2, Page 48, Paragraph 

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

#046 (T)  Section 4.3.3, Page 49, Paragraph 

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

#047 (E)  Section 4.5.1, Page 51, Paragraph Last

"initiato r's" should be "initiator's".

#048 (T)  Section 4.5.2, Page 52, Paragraph

Considering the confusion over linked commands in the past, perhaps we
should add in a statement that clarifies whether or not the linked command
is an implied reservation or not.  We have argued this one in committee
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.

#049 (E)  Section, Page 53, Paragraph Last

"mode byte" should be "control byte".

#050 (T)  Section, Page 54, Paragraph 1

"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.

#051 (T)  Section, Page 54, Paragraph 2

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

#052 (E)  Section 4.6.4, Page 58, Paragraph 3

"initiato r's" should be "initiator's".

#053 (T)  Section 5, Page 60, Paragraph 12

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

#054 (E)  Section 5.1, Page 61, Paragraph 6

"A response of Function Complete indicates that the task is not in 
the task set." implies that there is some other response sent if the
task was aborted.  This should say that the function complete is sent
once the task is aborted.  Also, the task not being present is not
an error.

#055 (E)  Section 5.4, Page 63, Paragraph 1

"... in the specified task set shall be ."  Oops, shall be what?  Aborted.

#056 (T)  Section 5.4, Page 63, 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 implies that I must flush my buffers for any data 
that these tasks may use.  This is not the intent of the statement.

#057 (T)  Section 6.1, Page 67, Paragraph 5

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 transfer.

#058 (E)  Section 6.2, Page 67, Paragraph 2 and 3

"...that were in the task set before the referenced task." should be,
"...that were entered into the task set before the referenced task was
entered into the task set.".  Just saying before the referenced task
leaves the ambiguity that they could be before the referenced task in
the task set (i.e. HEAD).

Same comment for paragraph 3.

#059 (E)  Section 6.2, Page 68, Paragraph 2

4.6.2 is not a correct reference.  6.2.1 is the correct reference.

#060 (E)  Section 6.2, Page 68, Paragraph 3

"...or is unable to continue command execution because of task termination"
does not correlate with this state.  Task termination is a very orderly 
procedure.  This implies that the task can't be completed when it can,
and is, completed in a predefined fashion.

#061 (E)  Section 6.2.1, Page 68, Paragraph 3

This should also state that the ABORT TASK SET must also reference the
initiator identifier.  That is, an ABORT TASK SET from initiator 1 does
not effect the tasks of intiator 2.

#062 (T)  Section 6.2.1, Page 68, Paragraph 5

The occurance 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.

#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
"internally active", I just delete it and continue with the current 
task.  If I get a reset, I blow everything away, including the read
|from the disk.  These are very different, yet you are grouping them
into the same term.

#064 (T)  Section 6.3, Page 70, Paragraph All

This entire section is extrememly 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 model has put everything back
into the internals of a device.  I cannot vote to accept any model 
which is "device-centric" rather than "bus-centric".

IBM comment:

         Note: Comments marked with an * what I consider to be
         non-editorial issues, questions, etc..

     1. Page 9 Section 2.1.23 - When does execution start? (e.g. On
     a write command some or all of the data is moved across the
     interface. Has the write command started execution or not?)

     2. Page 11 - Pending Task should be defined in the glossary

     3. Page 15-16 - Several of the entries in the symbols list do
     not have any spaces between the second column and the third

     4. Page 39 Section 3.7 1st paragraph after figure 17 near the end
     of the paragraph there is an undefined cross-reference.

     5. Page 42 - The heading 4.1 and the two lines following it are
     duplicated on the top of page 43.

     6. Page 44 - 1st paragraph after table 3 - The second to the
     last sentence should have a cross-reference to clause 6.6.1.

     7.*Page 44 - 1st paragraph after table 3 - This is the start of
     the ACA description problems. There should be a statement in
     this paragraph that says that if the ACA bit is zero the SCSI-2
     rules for handing exception conditions shall be used by the
     Target. No further definition is required and in fact the
     definitions in clause 4.6.1 only confuse anyone who has
     implemented CA in SCSI-2.

     8. Page 46 - section 4.2 - command terminated paragraph - There
     is a undefined cross-reference at the end of the first sentence.

     9. Page 46 and other places throughout the document - 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.

     10. Page 50 list under entry b - There should be an 'or' between

     11. Page 53 section last paragraph - The first sentence
     should be changed from 'the mode byte of the' to 'the control
     byte of the'.

     12. *Page 53 section last paragraph - The statement
     'shall be unconditionally cleared upon receiving the next command
     from the faulted initiator' is not the behavior described in
     SCSI-2 for this condition. (See comment number 7 for the

     13. *Page 54 section first paragraph last sentence - What
     are the conditions for 'acceptance'? Where in the task set is
     the command placed; is the task treated as a Head of Queue,
     Simple, or Ordered task??   (See comment number 7 for the

     14. *Page 54 section 2nd paragraph 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
     Queuing Model but the message seems to have been lost.

     15. *Page 54 section 3rd paragraph first sentence should
     be changed to 'faulting command, then the auto contingent
     allegiance condition shall not be cleared and a new task shall be
     entered into the..'

     16. *Page 54 section 3rd paragraph last sentence: I have
     not idea what this sentence means.

     17. *Section 4.6.1: After careful study of this section there
     seems to be several concepts defined in the SCSI-3 Queueing
     Model that are not here. The Missing concepts are list below:

       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 suspended
       until the ACA is cleared.

       2.1.3 Auto Contingent Allegiance Processing

       All SCSI operations are permitted while processing an ACA

       2.1.4 Clear Auto Contingent Allegiance Task Management

       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 Allegiance
       Condition is in effect for that initiator on that task set,
       then the target shall complete the current Task.

       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
       Attempted shall be used.h then an ASC of Overlapped Commands

     18.* Page 54 section 4.6.2 last paragraph 2nd sentence should be
     changed to '...tasks for the initiator that caused the overlapped
     commands in the task set...'.

     19. section 4.6.2 - The list of things that can occur to free up
     tags is not listed. The list out of the SCSI-3 Queueing Model

       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
       -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
       -A unit attention of POWER ON, RESET or TARGET RESET is

     20.* Page 58 section 4.6.5 - 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.

     21. Page 62 section 5.3 last paragraph - The last sentence should
     be changed to ' ...subject to the task set management...' and the
     wrong clause os referenced; it should reference clause 6.

     22. *Page 67-74 sections 6.2 - - I attempted to
     understand this section to see if it matched the SCSI-3 Queueing
     Model but I could not. The problems I had were:
     -Cross-references in almost every sentence.
     -Figure 23 is incomprehensible to me (Bring back the bubbles).
     -The words previous and prior drive me crazy what's wrong with
     simple words like before and after.
     -Sections 6.3.1 to are frustrating trying to understand.

     To net it out: I cannot determine if SAM complies with the SCSI-3
     Queueing Model.  The only thing I can go by is section 6.5 which
     contains the task management examples.  Everything in the
     examples looks correct except for one minor editorial change (see
     below).  But those are only examples and I cannot assume the
     other sections correctly define the actions within the examples.

     23. Page 76 figure 29 - The lower left task set brackets for the
     enabled tasks should be extended to include the Head of Queue
     (Task 7).

Quantum comment: 

We do not believe that the compliance issues raised in X3T10/94-081R0 have 
been adequately addressed.

X3T10/94-081r0 is included here for reference:

Date:    March 17, 1994
To:      X3T10
From:    Jim McGrath (408-894-4504)
Subject: Optional and Mandatory in SAM


SAM is a standard for standards, and yet it is very unclear to me what is 
mandatory and what is optional within SAM, and whether the referenced item is 
one within a standard claiming SAM compliance or an implementation of that 


I therefore suggest the following modifications to SAM (rev 12A):

(new item) Page 12: 2.1.28 implemented: The referenced item from a standard is 
realized in the actualization of the standard.  For standards complying with 
SAM, an implemented item is an item in SAM realized within that standard.  For 
devices complying with a standard (e.g. products), an implemented item is an 
item in that standard which is realized within that device.

(new item) Page 13: 2.1.34 item: A feature defined within a standard.  The 
fundamental element for claiming compliance to a standard.

Page 13: 2.1.41 mandatory: The referenced item is required to claim compliance 
with the specified standard.

page 13: 2.1.44 optional: The referenced item need not be implemented to claim 
compliance with a specified standard.

(new item) page 13: 2.1.45 option set: A set of referenced items which 
individually are considered to be optional.  If all of the items are 
implemented, then the option set is implemented.  If any item is not 
implemented, then the option set is not implemented.

A new section should also be created (I suggest section 2.4) as follows:

Grounds for Compliance

SAM consists of a set of items, each of which is clearly noted as being 
mandatory (either explicitly or implicitly by the use of the word "shall") or 
optional (either explicitly  or implicitly by the use of the word "may").  
Optional items may be further grouped into sets of options ("option sets").

All standards claiming compliance with SAM shall implement within the 
standard all mandatory SAM items.  A standard may implement optional SAM 

All standards claiming compliance with SAM shall in turn consist or a set of 
items, each of which is clearly noted as being mandatory or optional.  
Optional items may be grouped together as optional sets.  Any implementation 
claiming compliance with that standard shall implement all mandatory items and 
may implement any optional items.

Any standard claiming compliance with SAM must provide a facility to allow the 
determination of whether an implementation of that standard implements 
specific optional items identified in SAM.  This determination shall typically 
be done during a configuration period.

John Lohmeyer                      E-Mail:  John.Lohmeyer at FtCollinsCO.NCR.COM
NCR Microelectronics                Voice:  719-573-3362
1635 Aeroplaza Dr.                    Fax:  719-597-8225
Colo Spgs, CO 80916              SCSI BBS:  719-574-0424 300--14400 baud

More information about the T10 mailing list