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