Proposed response to Panasonic Comments on Revision 12 of SAM
Charles Monia, SHR3-2/W4, 237-6757, email@example.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.
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.
experience is that these options in a standard will become requirements in
marketplace and therefore should be better documented in the standard. If
intent is to provide extensibility through these options it should be
> 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
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
> 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.
More information about the T10