Date: Oct,31 1993 X3T9.2/93-164r0 To: X3T9.2 Committee (SCSI) From: George Penokie (IBM) Subject: Comments on SAM Rev 12 Note: Comments marked with an * what I consider to be non-editoral issues, questions, etc.. I am having trouble seeing how I can vote yes on forwarding SAM with as many *s as I have. 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. 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? 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. 7 Page 12 Section 3.1.28: What is an integrated path? I can find no definition of it. 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.' 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. 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 with SCSI? 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. 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. 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. 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.' 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. 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'. 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? 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. 29* Page 45 section 6.3: In the 'ACA Active' section the two places where 'command' is stated should be '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? 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. 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' 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. 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? 36 Page 53 section 6.6: In the first paragraph there is a '[to be specified]': What is that all about? 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.) 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. 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. 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? 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?