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
>target device.  

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..


Charles Monia









More information about the T10 mailing list