X3T10/95-202R0 -- Proposed Response to SAM Public Review Comments
monia at am.shrmsg.shr.mts.dec.com
Thu Apr 27 11:33:50 PDT 1995
The following is in reply to private email from Lansing Sloan and Rodney Van
Meter concerning the proposed responses to the SAM public review comments.
Their remarks are published with permission.
Lansing Sloan wrote:
>I've looked at your proposed responses to LLNL comments and, in a few
>cases, checked SAM Rev 016 again. In a number of cases, your responses
>explain why SAM is correct but, without the responses, I'd have a hard
>time being sure. (What would you expect, given the weakness of my
>SCSI background?) However, unless I mention such cases specifically
>below, consider me to be satisfied. There are a few other proposed
>responses that I think warrant some notes.
>I'm simply going to give the original comment number followed by
>my current ideas.
>Although the committee agreed to reject the comment, there are two
>sentences (second sentence, first paragraph and last sentence, second
>paragraph) where it appears a "server" is interacting with an
>"initiator". Upon rereading 5.5.1, it is far from clear that
>a "server" (generic) should be interacting with an "initiator" (SCSI
>specific context). There are enough words about "architecture model"
>and "SCSI-3 protocol standard" to suggest that SCSI specific contexts
>might be appropriate in those sentences, and also in the first sentence
>of paragraph 2.
>The bottom lines, though, are (a) the committee agreed to reject the
>comment and (b) I can't imagine anyone getting confused by this clause
>and creating an incorrect implementation as a consequence; so rejection
>is still acceptable.
>Since I am not the only person on the SCSI reflector who has at least
>wondered if linked commands could create indivisible complex operations,
>I think an explicit statement (maybe a note) should be added. I
>have no quarrel with your statement that "the use of linked commands
>in the manner described above is not supported by the architecture."
>However, I'd like SAM to be explicit in saying that it provides no
The problem is in explaining what's not being guaranteed.
Since the idea of command atomicity is not needed by the architecture, SAM has
no such concept. Consequently, to prevent confusion, the notion would have to
introduced and described with some rigor -- all for the purpose of explaining
it's not supported. Adding such complexity at this point is likely to
destabilize the document and add months to the review and approval cycle. For
that reason, inclusion of such a discussion in the standard should be deferred
to SAM -2.
If this issue arises subsequent to approval, a technical information bulletin
can be prepared to address it.
>In the proposed change, should "specifications" be "standards"?
>See the response to #024.
Yes, the proposal is in error. The wording should be modified as suggested
above. I consider this to be an editorial change.
>We agreed that this comment, whether one agreed with it or not,
>did not require any changes to SAM. Do you want to explicitly
>make a proposed response? (Right now, there's just the bare
>comment.) By the way, the SCSI minutes described this comment
>as "rejected," though I don't specifically recall that.
The minutes are correct. I will revise the proposal as follows:
The comment author should raise these issues in the form of specific change
proposals to be considered by the committee."
>Though the minutes described this comment as "accepted," my notes
>indicated that the change for #023 would also cover #022. So I'm
>a bit surprised, pleasantly. I have no problem with your response.
>When I wrote the comment, I was wondering whether each LUN could have
>its own task manager, in effect. The proposed cross reference will
>not hurt, but words saying that the task manager belongs in the target
>and not in a LUN would be more helpful in preventing the sort of
>confusion I had. (It's clear that my comment was itself not very
The clause will be modified to point to object definition (5) and figure 14. I
consider this to be an editorial change.
>I can't imagine the wording causing any implementation problems, but
>since "medium" is not in the glossary while "media information" is,
>that's why I asked if the change would not be appropriate. The
>committee, of course, said it's fine as is.
Unlike "media information", the term "medium" has the standard english meaning
and hence is not appropriate for inclusion in the glossary.
>Thanks for the good explanation. What was not clear is that, while
>a task exists but does not have a CDB to work on, there is space to
>put a CDB.
>I agree with the opinion of the technical editor.
>The proposed change to SAM is subtle, but someone sufficiently
>familiar with SCSI would probably never have been confused.
>I don't recall much in SAM that discusses in general the
>kinds of status and additional sense information that must be
>provided. Is some other document specifying that there shall
>be a sense code qualifier which shall be one byte long?
>Should SAM have some information, perhaps comparable to 6.1 and
>its subclauses, to discuss the various possible status and sense
No, these are covered by the SPC document.
>In your response to Intellistor, it appears as if either they
>made 3 comments #005 or else you split it into 3 parts to respond
>to each part cleanly. At first glance, though, it looked funny.
This was my error. I had intended to renumber the comments.
>It remains true that I have no serious disagreement with the
>working group's decisions in March.
End of Lansing Sloan response.
The following is extracted from private email sent by Rodney Van Meter.
>SAM defines a Target Identifier to be 64 bits. However, if we wish
>to run SCSI over IP (leaving aside for the moment the debate over
>whether this is a good idea, It _is_ covered in the GPP draft), 64
>bits will be an inadequate address when IPv6 (currently in the design
>phase) is deployed. IPv6 addresses are 128 bits. I suppose it's too
>late to change this, but it should be noted.
> Authentication is not mentioned anywhere. How are devices to know
>that they are receiving commands from initiators that they _should_
>listen to? Over SPI, not a problem, since connection via a physical
>SCSI bus implies ownership of the device, but over a network, it's
> Again in the case of networked SCSI (FC, SSA, GPP, what have you)
>resource discovery is also a significant problem. Over SPI,
>traditionally the host attempts to select all devices to establish
>what devices are present, but over other media this may not be
>These last two issues are so big that I don't believe that they
>haven't been addressed (in fact, I vaguely recall some discussion on
>the resource discovery problem a long time ago); forgive me if I'm
>beating a dead horse.
The overarching issue here is that there are a lot of implicit LLP functions
that are outside the scope of SAM. While a discussion of such issues would
serve as a useful guide to implementors and protocol designers, none of these
really effect the essential characteristics of the model. For that reason, an
in-depth discussion of these matters should de deferred to SAM -2. As mentioned
in a subsequent note, however, a few cursory remarks in SAM are in order.
End of Rodney Van Meter response.
Summary of changes to the proposed response:
Based on the above comments, I will send out a revised version of the proposal
with the following changes.
1. Modify responses to LLNL comments #011, #016, #018, #043, and #048 as
2. Correct the numbering of Intellistor comments.
3. Add the above text from Rodney Van Meter and the proposed response.
More information about the T10