Mandatory and Optional Features in SAM
Charles Monia, SHR3-2/W3, 237-6757 02-Sep-1994 1649
monia at starch.enet.dec.com
Fri Sep 2 13:47:13 PDT 1994
Quoting from Gene Milligan's reply:
>>1. A conflict between standards shall be resolved according to the
>> following precedence:
>> Other command standards
>> Protocol standards
>> Interconnect standards
> This would be an excellent idea if we had defined SAM first, CAM, second, SPC
>third, OCS fourth, Protocol standards fifth, Interconnects, sixth, and
>Applications last. My comment is offered in regard to mandatory and optional.
As I see it, the order in which standards are developed is not the issue. In my
mind, precedence addresses the following problems:
1. How does the commitee define requirements that apply
across standards as well as products?
2. How are conflicts between standards resolved?
While standards are in development, issues of consistency can be addressed by
modifying any standard in the hierarchy. -- ie. the tail can wag the dog if
needed. The intent of the hierarchy is to maintain consistency after approval.
>(No matter how many votes we may muster, SAM can not define Isochronous as
>mandatory and sue the Interconnect standards save 1394 and FDDI (for now - stay
>tuned to FC and SSA).
It's not a matter of "suing the standard". Implementations are affected.
The way precedence would work works is that, in the event of a conflict,
the provisions in SAM (or SPC etc) take precedence over conflicting
provisions in some "lower priority" standard. Thus, if the product complied
with SPC at the expense of a lower priority standard, the product would be
in compliance with SCSI-3. The converse holds true as well. If
a product complied with some protocol or interconnect standard at the
expense of SPC etc, the product would not be SCSI-3 compliant.
It's the job of the committee to make sure the standards are consistent
with one another and that the scope is appropriate. Once the committee
gives it's seal of approval, then the precedence rules become the
basis for insuring consistency thereafter.
BTW: Another function of precedence is to give the commitee a way to express
it's intent regarding the kinds of behevior that should be common to all
implementations, whether they are based on SIP, SSA, Fibre Channel
>If the conflict is addressing redundant definitions or overlapping definitions
>I would support having a precedence statement but bowing to silicon I would
>make it Interconnect standards, SAM, Other command standards (OCS) , SPC, and
>Protocol standards the order of precedence.....
In my opinion, the way to deal with such issues is not by turning precedence
upside down, as you suggest, but by selectively generalizing features present
in existing silicon IF APPROPRIATE. The generalized feature is then written
into the higher level standard.
>Replace "subject to" with "claiming compliance with" and delete everything
>after "standard". We don't actually have the concept of subsidiary standards.
>The standards referred to as subsidiary are actually just standards which may
>if their developer's wish call out another (i.e. superior) standard as being a
>Normative reference. The tone of all Charles is offering appears to be a
This hits the nail right on the head.
However, I believe we need to go a bit further and require a standard
claiming to be an SCSI-3 standard in some category to automatically have certain
implicit normative references.
>The standards should merely indicate what is mandatory and what is optional
>within the given standard. It is up to application profiles, purchase
>specifications and/or implementors to determine which of the standards and
>options play together. Obviously since the implementors are energetically
>supporting the development of the standards they will be keeping the interplay
>in mind while choosing between mandatory and optional.
I agree...provided the precedence rules and requirements for normative
standards are included as noted above
More information about the T10