Proposed Responses to IBM Comments on Revision 12 of SAM.

Charles Monia, SHR3-2/W4, 237-6757, monia@starch.enet.dec.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
         logical units.

         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
>	   and
>
>	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...'
	
>
> Agreed.
>

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

     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'.
>
> Agreed.
>


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

>
> Agreed.
>

     12  Page 15 Section 3.1.73:  What is a 'constituent system'? What
         is a 'related system'?  What has this definition have to do
         with SCSI?

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

>
> Agreed.
>

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

>
> Agreed.
>

     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'
         block.

     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
         management functions.
>
> 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
> consistent.
>

     20  Page 34 section 4.7.2:  The sentence in 'Logical Unit'
         '...request are directed.' should be '...requests are
         directed.'

     21  Page 35 section 4.7.3: The sentence in 'Device Server' should
         be '...SCSI commands and manages the task set.'
>
> Agreed.
>

     22  Page 35 section 4.7.3.1: 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 4.7.3.2: In the 'Tagged task ' section: Why
         not make life a little less complicated and change
         'initiator-specified component (tag)' to 'tag' or at least
         'initiator-specified tag'.

>
> Agreed.
>


     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
         status undefined?

>
> 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 6.5.2.1: 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.

>
> Agreed.
>

     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 6.5.2.2 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
         target?

>
> 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
         condition, etc.)

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

     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
         forever confusing.

>
> 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
         'tasks'.


     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
         why?

>
> 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 mailing list