Definition of Mandatory
Charles Monia, SHR3-2/W3, 237-6757 06-Sep-1994 1436
monia at starch.enet.dec.com
Tue Sep 6 11:34:50 PDT 1994
Quoting from Jim McGrath's note:
>.............................................I have some difficulty with
?your set of standards and their relationships. First, I still feel that
>SAM is a "standard for standards", and that it has no direct
>controlling influence over implementations. Indeed, this is the key property
>of an architecture - it sets some boundaries on implementations, but does
>not directly address itself to implementation issues.
The fact is SAM is both a standard for standards and a 'controlling influence
over implementations'. When SAM talks about interactions between peers such as
application clients and device servers, then it's defining behavior that
applies directly to logical unit implementations. When SAM defines a model
interface between a higher layer and a lower layer, ( ie. an application
client and the protocol service layer) it's defining a make believe interface
which serves as a standard for standards. SAM then defines the agreements
between standards that exist on either side of that boundary.
Obviously, we can argue about the scope of the document. Setting that
aside for a moment, I believe there needs to be a single governing document of
some kind that defines a 'contract' between the system user (for example, the
person writing the device driver or the O/S) and the providers of SCSI
interconnects, adapters and target devices.
We could define yet another document that would deal with issues like the value
of status, the overall format of a CDB, queuing, ACA and other things that
directly affect implementations. The point is if SCSI is avoid devouring it's
children (SSA, FCP SBP...), such common requirements need to be captured in a
single controlling document somewhere. Given the way the current roadmap is
defined, I see no better place for that contract than 'SAM'.
(That document or contract can't be CAM or any other implementation
architecture that someone chooses to place in the public domain. Such
architectures start by assuming the behavior that SAM attempts to codify.)
>If you wanted to roll in some implementation requirements, then I could
>live with that. But your example wording implies that EVERYTHING in
>SAM automatically becomes an implementation requirement (or option).
Is that bad? I thought we wanted all implementations to behave the same,
regardless of their internals. I don't see how we can make that happen
without a specification that's binding for all.
>Moreover, SAM talks of entities such as the task set that does not have
>any discrete existance - parts of it exist in a host device, some in the
That's an issue to be addressed by protocol standards and implementations. The
point is that SAM requires the system, as seen by an application client looking
through the service delivery port, to behave in a certain way, in this case as
though the task set resides in the logical unit.SAM then delegates the
responsibility for correctly defining the corresponding enforceable behavior to
the protocol standards. SAM is the reference we use to decide whether or not a
given protocol complies with SCSI-3.
>At the end of the day, I am still concerned over possible confusion between
>things SAM requires of standards and things it requires of implementations.
>And since it is not focused on specific implementations, it is very hard
>for it to make implementation requirements in a manner that is clear and
>enforceable to the designer of a specific device.
It would help if you were to cite examples of requirements you feel might be a
potential source of confusion. In my opinion, it's the job of the
implementation standards and SAM to cooperatively address such issues on a case
by case basis..
More information about the T10