System Issues: Processes

Duncan.Penman at Duncan.Penman at
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.

Re-inventing X3T10!
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 
facto) standard.
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 can’t be either solved locally or just ignored.
Those that call for an interpretation of a formal standard should be 
referred to X3T10, but that shouldn’t be someone’s 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 
needed here.  

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 BBS’s, new or existing usenet newsgroups, Compuserve 
forums, WWW, and no doubt other things as well.  Even paper as a last 
resort.  Stay focussed, or we’re lost, because there are terabytes of text 
out there with most of it being irrelevant, at best.

I think we proceed incrementally with this.  It’s 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.
I’d 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                     *
* ph: (408)730-2565, fax: (408)730-5527 *

More information about the T10 mailing list