ATA Project Proposals

[jmcgrath at qntm.com]

                      Subject:                              Time:  11:01 AM
  OFFICE MEMO         ATA Project Proposals                 Date:  3/18/94

This is a follow up to the conversation we had in Newport Beach concerning the 
current drafts of the ATA project proposal(s).  I am very concerned about the 
relative lack of specific constraints on the scope, especially in light of our 
recent problems in approving a GPP standard.  I am also convinced that a broad 
scope allows us to prolong the development of a standard by incrementally adding 
new stuff over time.  I would rather limit the scope of the projects, and 
authorize either new projects of modify the scope of an exisiting project at a 
later time than run the risk of delaying the completion of the standard.

Some suggestions and comments:


Physical

"Provide a means to support the AT Attachment protocol on a variety of physical 
interfaces such as that for the newly-emerging requirements for memory cards."

The only specific item mentioned is support for ATA on memory cards.  I am not 
even sure this is needed - do we really want to define physical characteristics 
of ATA memory cards independent of those defined by PCMCIA?  And what is meant 
by PHYSICAL anyway?  Connectors?  Electrical requirements?

If we just want to separate out the physical elements of the ATA-2 document, 
then why not say this?  If we want to define physical requirements for new 
interconnects (e.g. PCI), then say that.  I  am against incorporaing PCI 
material into any of these SD3s, since I think there is a lot of work needed in 
that area which would surely keep the standards in development for a long time 
to come.


Transport

"Provide a means to support the AT Attachment protocol on a variety of physical 
interfaces such as that for the newly-emerging requirements for memory cards."

This is the same scope as the Physical SD3.  In reading this, the Physical SD3 
appears to be a subset of the Transport SD3.  I suggest eliminating this element 
of the scope - physical stuff belongs in the physical SD3 only.

"Provide a means to support a variety of device types on the AT Attachement 
interface"

This comes about through the strange dual use of this standard by the Block 
Command and Packet Interface standards.  I have no idea how this operates in 
practice.  Once again, what is transport?


Block and Packet Interface

I have the same concerns about the lack of specifics in the scope for these 
SD3s, but I also have 2 global issues.  First, no where does it state whether 
Packet Interface is to be SAM compliant.  I would argue for making it SAM 
compliant (the whole point of SAM is to allow the device command sets to be used 
on alternate physical interconnects without requiring software rewrites - a 
highly desirable goal for any market, but especially for the PC market).  But at 
least the issue of compliance should be addressed.

Second, there is an inherent conflict between the Block and Packet interface 
standards regarding disk drives.  It may be unavoidable to continue independent 
development of capabilities for disk drives in two different standards - but I 
am not convinced of this.  I do not want to support two different efforts over 
time in a market which has always been intolerant of multiple solutions to a 
single problem.  We should  limit our scope (e.g. Packet is not to be used for 
disks, or Block is to be limited to existing functions with no more 
improvements) in order to make our work manageable.

I realize that many of these issues have been raised in the ATA working group 
(which I have not been regularly attending due to scheduling conflicts - that 
should be resolved with the new meeting time).  But I feel they have been 
deferred rather than resolved.  Since many of them are issues of policy 
direction or simple definition, we should (and in the interest of smooth 
operations must) resolve them now.  For these reasons I would have to vote NO on 
the proposed letter ballot for the current revisions of all 4 SD3s.

Jim McGrath
Quantum






I