Proposed Responses to IBM Comments on Revision 12 of SAM.
Charles Monia, SHR3-2/W4, 237-6757, email@example.com 03-Jan-1994 1539
monia at starch.enet.dec.com
Mon Jan 3 12:38:57 PST 1994
From: Charles Monia
SAM Technical Editor
To: Members of X3T9.2
Subject: Proposed Respones to IBM Comments on Revision 12 of SAM.
The following contains the proposed responses to IBM's comments
on SAM revision 12. Each comments is included verbatim, followed,
when appropirate, by the proposed response, which is denoted by a
right arrow ">".
A comment with no response will be incorporated as specified.
Begin Proposed response
1 * There is a fundamental change between the Queueing Model and
the way SAM defines Queueing. It is that the Queueing Model
assumes the target is the 'owner/manager' of the task sets.
This allows the possibility of task set boundaries other than
on a per Logical Unit with no change to rules of the queuing
model other that the boundary definition.
SAM defines the 'owner/manager' of task sets to be the device
server. There is one device server per Logical Unit. And
the device server has no knowledge of or control over other
logical units within a target. Because of this there is no
way a device server could manage a task set which crosses
There is nothing 'wrong' with the way SAM has defined the
task set control because the 'one task set per logical unit'
was what the committee voted to support. I am only pointing
out that with SAM it will require a much greater effort to
change to a different or support for multiple task set
boundaries. I other words we are burning bridges.
> The definition of "task set" will be decoupled from the
> definition of logical unit while retaining the concept of
> one task set per logical unit.
2 * Through out SAM there are references to the confirmation of
services and the response to services. This is confusing:
Are services confirmed or responded to?
> Two kinds of services are defined:
> 1. Distributed services performed by servers within the the target
> 2. Protocol services provided by the lower layer protocol.
> Distributed services consist of a request which elicits a server response.
> Protocol services consist of a protocol request which may elicit a
> confirmation from the lower layer.
> The editor will review the specification and correct any ambiquities
> in terminology.
3 Page 10 Section 2: TBD Must be removed
4 Page 11 Section 3.1.11: The sentence 'A command has than
has..' should be changed to 'A command that has...'
5 Page 12 Section 3.1.21: The sentence '...for the next in a
series...' is not clear and should be changed to '...for the
next task in a series...'
6 * Page 12 Section 3.1.26: This definition implies that
application clients are part of initiators. I do not agree.
application clients are the originators of commands and
initiators do not originate commands.
Page 23 section 4.2.1: Again refers to the application client
residing in initiator devices.
> The working group agreed that the definition in the specification was
7 Page 12 Section 3.1.28: What is an integrated path? I can
find no definition of it.
> The working group agreed to the following modified definition:
> Interconnect subsystem: One or more physical interconnects which
> appear as a single path for the transfer of information between
> between SCSI devices in a domain.
8 Page 12 Section 3.1.30: The sentence '...commands executed by
a single task..' is not correct. Tasks do not execute
things. I suggest changing 'executed' to 'contained within'
or 'bounded by'.
9 Page 13 Section 3.1.41: The sentence '...devices in a
domain.' should be changed to '...devices within a domain.'
> The working group agreed to accept the wording in the specification.
10 Page 14 Section 3.1.61: Why is this definition even in SAM?
None of the other protocols are defined. If this definition
stays then all the other protocols need to be defined. If it
stays the the definition should be 'A protocol defined by the
SIP standard.' nothing more.
> The referenced definition will be deleted.
11 Page 14 Section 3.1.63: This is a GS definition. Remove
everything after '...device delivery subsystem.'
12 Page 15 Section 3.1.73: What is a 'constituent system'? What
is a 'related system'? What has this definition have to do
> The word "constituent" will be deleted.
13 Page 15 Section 3.1.74: The sentence '...the data was
addressed.' should be '...the data is associated.'
14 Page 15 sections 3.1.77 and 3.1.79: The first word of both
sentences should be 'An'.
15* Page 15 section 3.1.84: The logical unit does not define the
boundaries of the task set. The sentence '...grouped by the
logical unit so...' should be '...grouped so...'.
16 Page 15 section 3.1.85: Task slots do not 'represent' tasks.
I think think of task slots 'holding' tasks.
> The working group agreed to the following revised definition:
> "task slot: Resources within the logical unit that may be used to
> contain a task."
17 Page 19 figure 1: The is a line missing on the 'section'
18* Page 33 section 4.7.1: Pending is being used but it is not
clear what is meant. What does not mean to have a 'pending
task management function'? Depending on the definition of
'pending' it may or may not be possible to have pending task
> A task managment function is pending from the time it is issued by
> the application client to the time when a target response is received.
19 There seems to be an inconsistency in the usage of 'task' and
'command'. If I read the definitions of each it would not be
possible for the application client to deal with tasks. But
for linked commands I know this not the case because there
are many commands which make up a single task. So if I ignore
the definitions then the description of 'Application Client'
on page 33 is OK. But now I go to page 34 and read the
description of 'Logical Unit' and it talks about commands not
tasks. How is anyone supposed to understand this.
> As explained during the working group, the application client issues
> commands and task management functions. In response to a command,
> the device server may create a task that provides the context within
> which a command executes.
> The working group felt that the definitions and usage seemed
20 Page 34 section 4.7.2: The sentence in 'Logical Unit'
'...request are directed.' should be '...requests are
21 Page 35 section 4.7.3: The sentence in 'Device Server' should
be '...SCSI commands and manages the task set.'
22 Page 35 section 188.8.131.52: The last sentence in the second
para. the 'should' should be 'shall'. And here is the
undefined pending task management again.
> The working group agreed to retain the wording of "should".
23 Page 36 section 184.108.40.206: In the 'Tagged task ' section: Why
not make life a little less complicated and change
'initiator-specified component (tag)' to 'tag' or at least
24 Page 39 section 6: In the 'autosense data' section there is
an undefined cross reference.
25 Page 39 section 6: In the 'Austosense Return Flag' section
there is a missing ')'.
26 Page 39 section 6: In the 'Status' section: When is the
> As stated in the argument description, status is undefined whenever
> the command fails to complete with a service response of command complete.
27 Pages 40,41, 42, 43, and 44: All the Tables on these pages
are messed up.
28* Page 44 table 8:The committee requested that this table be
changed to remove the possibility that anyone would interpret
status codes as being bit sensitive but coding the statuses
as hex values.
> The change will be made as stated above.
29* Page 45 section 6.3: In the 'ACA Active' section the two
places where 'command' is stated should be 'task'.
> I believe the references to "issuing a command" in the first
> sentence and item b are correct. In item C, the reference to command
> should be changed to task.
30* Page 46 section 6.4.1: Bullet number 2 talks about a task
being created when it is received by the device server.
Again; how can the application client know about some that
does not exist?
> It's not clear to me what the problem is here.
> As I read it, there is nothing in item 2 that implies or requires such
> knowlege on the part of the initiator. I suggest discussing this matter
> at the January Working Group.
31* Page 49 section 220.127.116.11: Paragraph 2: The sentence '...was
created by the initiator...' should be changed to '...was
created for the initiator...'. An ACA is not created by an
initiator, it is created for an initiator.
32* Page 49-50 section 6.5.22: This is section is a disaster.
There appears to be an attempt to redefine how SCSI-2 CA
should work and it is not right. I will argue that it is a
bad idea to try to define a SCSI-2 function is SCSI-3. We
should just say 'see SCSI-2'. Look at the 'Queueing Model
document to see how this is handled'
> The working group agreed that behavior must be described explicitly
> without refererence to SCSI-2.
> Subsequently, the editor agreed to modify 18.104.22.168 to delete item B
> and revise item C to unconditionally clear the ACA when any new task
> is created, regardless of task atttribute.
33* Page 50 section 6.5.3: This section is not reflect the
committees desires for overlapped commands. See section 2.2
of the queueing model for the latest information.
> This will be corrected to agree with 92-141R8.
34 Page 50 section 6.5.4: Bullet b - The sentence ' ...the
logical unti...' should be '...the logical unit...'.
35* Page 52 section 6.5.7: Is Asynchronous event reporting per
> Asynchronous event reporting is per logical unit.
36 Page 53 section 6.6: In the first paragraph there is a '[to
be specified]': What is that all about?
> A protocol-independant definition of hard reset will be added.
37 Page 53 section 6.6: Bullet h: What is 'Any other event'?
That statement could imply that an unit attention could
legally occur on any event. (eg command complete, check
> This itemization will be changed to:
> "Any other event requiring the attention of the initiator."
38* Page 54 section 7.1: The 'Ordered Blocked Boundary' section
looks to be an attempt to combine the 'Ordered Blocking' and
'Task Set Boundaries' concepts. These two concepts are
important to understand and should be separately defined.
> The definition of Ordered Blocking Boundary in SAM will be
39 Page 55 section 7.2: In the 'task abort' section and
elsewhere the message names have changed from Queue to Task.
I do not think this is a good idea and yes in know task is
the 'correct' term but if this change is made it will be
> Since the SCSI-3 queuing model replaces "queue" with
> "task set", the working group agreed to the names for task
> management functions that are currently in the specification.
40 Page 56 section 7.2 last sentence: The sentences read '... to
the commands it completes...' What is the 'it' this section
of the sentence is referring to?
> "It" refers to the antecedent "task". The sentence will be reworded
> to replace the pronoun.
41 Page 58 table 58: In the Dormant row under the 'All prev. HOQ
and previous ORDERED tasks ended' column 'tasls' should be
42 Pages 61,63,65, and 67: The Black background with white
lettering is in many cases almost unreadable.
43* Page 73 section 9.1: The send SCSI command looks allot like
the execute command service response but some of the
parameters are in different locations. Are there supposed
to be two different services that are almost the same? If so
> The paramaters in the Send SCSI Command service will be changed to agree
> with the parameters of the Execute Command remote procedure call.
End proposed response
More information about the T10