This message is from the T13 list server.
Don, You did not read my message carefully. I said that it was obsolete in ATA-4, approved in August 1997, but first finds its way into the working draft in June of 1996 with revision 5. It was submitted as a proposal in February of 1996 (D96125), which was revised 5 times before being included in the working draft. The issue of obsolescing commands was discussed in the minutes of March 27-29, 1996, and indeed a vote was taken at that time on also including the SEEK command (which lost). All of these documents are on the web site. The way standards bodies work is that proposals are submitted (and available on the web site) on a specific topic, and then are debated. Almost all proposals go through several iterations as a standalone document (some have taken up to 10 revisions) before the committee accepts it. This one went through 5 revisions, not uncommon. At that point the editor of the draft document will schedule its inclusion in the next revision of the working draft. Once that is produced, it becomes the baseline that future proposals reference. At this stage a question may come up from the editor or people reviewing the working draft that was not apparent in the original proposal (for instance, a subtle interaction with another section of the document). These are then resolved, sometimes by the editor taking direction from the committee, sometimes by a new proposal (if the changes are significant). Note that it is still possible to submit a proposal reversing the original proposal, although obviously doing that earlier would have had more of a chance of success (typically new information is needed to justify a reversal). Finally, a draft is produced that is reviewed on a line by line basis. For ATA-4 this happened in March of 1997 with revision 10. The committee spends several meetings (often special extra meetings) reviewing the draft document before "forwarding" it to the parent committee. So these reviews produced more drafts, up to draft revision 16 in August of 1997. Forwarding produces letter ballot comments and the public review stage, which generated revision 17 in October of 1997. Finally, revision 18 incorporated editorial changes people later discovered in August of 1998. And then the process begins again. The committee has actually been revising the standard on a 12-18 month of so cycle. Too long a cycle and things get approved as proposal, but not communicated as a standard (we had a bad experience once with SCSI-2 that took 5 years to approve). To short a cycle, and people get confused and not enough change is presented to really warrant a new standard. This is why I take exception to some concept that the committee acts on a "whim." It takes so long to get something in the standard, from concept to publishing, that frequently the "new" topics covered in ATA-(N) were originally presented to the committee while it was still working on ATA-(N-1)! Their are several layers of review, all of the meetings are public, all paperwork is posted on the web site. In this particular case the topic was begun in February of 1996 and concluded (with forwarding ATA-4) the following summer - 15 months. It took 18 months if you include the comment resolution phase. Hardly a "whim." Jim PS I was actually on the committee at the time, although I was transitioning my more active duties to others. The people on T13, particularly the officers and editors, work quite long and hard and produce something of substantial value to the industry. -----Original Message----- From: don clay [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 20, 2002 7:59 AM To: ata reflector Subject: [t13] Re^19 R/W (Long) Commands This message is from the T13 list server. On the experience issue, I have been intimately involved in product planning both with manufacturing and with customers as well and am just as well versed with those costs and implications as well. Once again, the R/W Long command in all of these considerations as well as all others is insignificant (that's as in zero, not measurable, nada, doesn't count, any way that you want to say it!!!) when compared to the whole of an ATA Interface. When you obsolete a command that is currently being used by those in the ATA Community, you put them at risk to the whims of the committee. Since you say that R/W Long was obsoleted in August 1997, I went back to June 1997 and re-read all of the reflector email from 6/97 through the end of 10/97. There was no mention of any discussion of R/W Long in either the reflector email, the meeting minutes, nor any of the ad hoc meetings, 3/19/02 6:08:05 PM, "McGrath, Jim" <[EMAIL PROTECTED]> wrote: > >Don, > >The ATA committee regularly exercises due diligence - all proposals are >available on the T13 web site for public viewing long before they are >approved by the committee. All meeting minutes are also posted on the web >site. This is usual practice for most standards bodies, which are required >by law to be public bodies (since otherwise standard setting in private by >companies could be considered an antitrust violation). > >On the experience issue, the problem is that I think you are looking at it >from an engineer's perspective (my experience has been in program management >and marketing as well as engineering). The cost of getting products to >market is far higher than just the direct engineering cost. And once again, >the risks of making changes when there is no benefit is too high for our >business. By making these commands obsolete the standard gives comapanies >the freedom to make those tradeoff themselves. > >Jim > > > >
