System Issues: Processes
Duncan.Penman at netcom.com
Duncan.Penman at netcom.com
Tue Jan 24 20:03:50 PST 1995
System Issues: Processes
Leaving aside for a moment the question of what system issues need to
worked on, these are some seed thoughts on where and how the work
should be done. Please offer your own opinions.
An observation: Just as all our companies are having to change the ways
they do business to keep up with relentless technology advances and
ever shortening product cycles, standards bodies need to overhaul their
processes in order to effectively serve those companies.
Faster generation and approval of standards is necessary, yes. But just
doing the same old thing better is only part of the answer.
What Fits Where?
1. Formal Standards
No question, these should be worked out under the auspices of
ANSI. ATA and SCSI belong to X3T10. A project has been
approved for ATAPI but there has been a lot of resistance to doing
anything with it, partly because many of the players have been tied up
on other work.
Speaking of workload...if we seriously address ATAPI, there will be
2 generations of that standard and 2 or 3 generations of ATA all on
the table at the same time. Can we realistically tackle even this much
with the 20% of X3T10 bandwidth left over from SCSI? Is it
realistic to even think about standards for OS or hardware platform
issues for SCSI, ATA, or ATAPI, even if we decide it is within the
scope of X3T10? My opinion is No..
2. De facto standards
There are several reasons for de facto standards, but the primary
motivation in contrast to formal standards is speed. If those with a stake
in the outcome can get together, agree on the points that are critical, and
move on, you have accomplished something valuable. Sometimes there
is enough self discipline among the participants to cover all the issues
and document the results. Understandably, it causes gnashing of teeth
among those who come along later when a complete job was not done.
Barring the rare cases where someone is so dominant that their design
becomes the standard (e.g. the original INT 13 interface), I believe the
following steps are necessary in successfully defining an informal (de
a. Clearly stated scope and purpose
b. Written output that is readily available to those who need it
c. Widespread review with an attempt to resolve disputed issues before
it is declared done.
There are several models for informal standards. ANSI has annexes to
standards, and Technical Reports. Several groups have produced
profiles describing minimum and recommended characteristics for
devices in certain applications. SFF has produced a raft of connector
specifications, as well as several specifications for ATA and ATAPI
interfaces. Several of the latter were later submitted to X3T10 for
inclusion in a formal standard. That is a source of controversy today as
we face the prospect of further informal standards being developed.
One could reasonably argue that items which will eventually be covered
in a formal standard should be developed with the involvement of those
who are responsible for the standard. It minimizes the risk of unpleasant
compatibility surprises later on and adds a necessary discipline to the
work. The contrary argument is that formal standards activities take too
long because they are heavily proceduralized and broadly focussed.
Companies who wait for formal standards bodies to develop even usable
working drafts of new standards will simply be bypassed by those who
My opinion? We need both approaches. X3T10 (and maybe some
sibling organizations) needs to be more flexible than it historically has
been, getting involved early in new technical initiatives and finding ways
to provide interrim guidance while initial designs are still evolving. SFF
or a similar body is needed to work in areas outside the scope or
resourcesof X3T10, as well a providing a sounding board for off-the-
wall proposals and a publishing capability for items that might violate
ANSI policy in some area. Both groups need to expand their circles of
participation if we hope to address system issues successfully.
3. Compatibility problem resolution
The acid test of whether a problem is a system issue rather than just a
difference in vendors implementations is whether it affects
interoperability between systems. While BIG system issues are few,
small compatibility problems pop up all the time. I think we need a
place to bring those that cant be either solved locally or just ignored.
Those that call for an interpretation of a formal standard should be
referred to X3T10, but that shouldnt be someones first stop when they
recognize a problem.
SFF is a useful prototype for this type of function, but the $2500 entry
fee is pretty stiff for small players. Some creative organizational work is
4. Information transfer
Cross reference what is available elsewhere. Publish (in some electronic
form) the core set of relevant documents plus whatever is useful but not
readily available elsewhere. Our virtual library consists of FTP sites,
new or existing BBSs, new or existing usenet newsgroups, Compuserve
forums, WWW, and no doubt other things as well. Even paper as a last
resort. Stay focussed, or were lost, because there are terabytes of text
out there with most of it being irrelevant, at best.
I think we proceed incrementally with this. Its clear that there are some
electronic literacy skills required to participate, as well as some
investment in hardware and software. Welcome to the world of 1995.
Id like to see us break some new ground in effectively using these tools
as we address system issues in ATA, ATAPI, and SCSI.
* Duncan Penman *
* IIX Consulting/ENDL Associates *
* penman at netcom.com *
* ph: (408)730-2565, fax: (408)730-5527 *
More information about the T10