Proposed response to Panasonic Comments on Revision 12 of SAM

Charles Monia, SHR3-2/W4, 237-6757, monia@starch.enet.dec.com 03-Jan-1994 1508 monia at starch.enet.dec.com
Mon Jan 3 12:08:12 PST 1994


From: Charles Monia
  To: Members of X3T9.2

Subject: Proposed Response to Panasonic Comments on SAM, revision 12


The following is my proposed response to the comments received from
Panasonic on revision 12 of SAM.

The comments are included verbatim. .Proposed replies are preceded by a
right arrow ">".


R1.  Though the SAM document has been through several major revisions there is
     still significant work needed for the document valuable to the industry. 
This is
     particularly the case with Annexes A and C which represent a significant
     amount of committee effort but are not consistent with the remainder of the
     document. Concepts like queuing and terminology such as "execute", "task",
     "response", "confirmation"  are not consistent. The document will confuse
     readers in its present state.


> SAM must, of course, be in full technical agreement with the queuing
> model passed by the commitee. Any discrepancies or inconsistencies betweem
> the body of the document and the queuing model will be corrected. In that
> regard, please cite specific instances where the draft is either
> unclear or at variance with the queuing model.
>
> It is my understanding that once such corrections are made annex C will be
> deleted. The commitees' intent regarding the alternate task set descriptions
> in annex A, however, is not clear to me. I propose that the issue of
> whether or not to retain annex A be resolved in the working group."


R2.  The document requires the use of "Per Logical Unit Task Set Boundaries" but
     discusses and provides for other implementations. This is very confusing. 
My
     experience is that these options in a standard will become requirements in 
the
     marketplace and therefore should be better documented in the standard. If 
the
     intent is to provide extensibility through these options it should be 
clearly stated.
>
> I believe the discussion of other alternatives in annex A was in accordance
> with the commitees' wishes. Please see the previous response.
>


R3.  I am confused by the requirement in clause 4.6 that all transactions be 
received
     in the order they were sent. My understanding was that some of the SCSI-3
     transports do not maintain order (i.e. P 1394, Fibre Channel and possibly 
SSA).

>
> I believe that, although some physical transports, such as Fibre
> Channel, may reorder data in transit, the ordering specified by the
> sender is restored before the transaction is presented to the consumer.
>
> In any event, ordering is implicit in SCSI-2 today. Therefore
> placing a new ordering burden on the application client (e.g., the
> device driver) may lead to implementations that break existing
> code that would otherwise be portable.
>
> I suggest this issue be left open for discussion
> at the next working group.
>

Charles Monia







More information about the T10 mailing list