1999 Rebuttals to Negative Ballots

Sponsor Rebuttal to Negative Ballots

Negative Ballot #1
Dave Clemens
Hewlett Packard Co.
815 SW 14^th St.
Loveland, CO 80537

Answer to comment #1 from David Clemens entitled "Backward Compatibility is Not Ensured"

Addition of CF/SHE/AHE: The working group has verified that compatibility has not been comprised. The negative ballot points out that Section 5.1 of the original standard states " In order to provide system compatibility a designer shall not introduce new interface functions beyond those designed in Section 2." This statement is intended for the designer to ensure that he or she does not add functions that are not in the standard, therefore compromising compatibility. This comment is not intended for a standardization body because it is their task to carefully review standard modifications. Maintaining compatibility was a primary goal of the working group. If all existing standards were held to this stipulation then no standard could ever be improved by adding functionality.

Answer to comment #2 from David Clemens entitled "Cable Length Parameter - Usage Problems"

All interface and network standards have cable length restrictions thus users are used to taking this into account, also for the existing IEEE 488 standards. This was discussed at the working group meetings; however, there was no way to increase the speed of the existing standard without the user having the knowledge of the overall system cable length. In fact, the two other proposals considered also required knowledge of the system cable length. Since enabling the higher performance enhancements is an option the user decides, he or she will make that tradeoff. If he or she believes there is a risk that additional cabling may be added in the future, he or she can choose not to enable the enhancements, or may tell the system that there is more cable than what really exists in the system to protect against this scenario.

With respect to mechanisms for communicating with the controlling I/O software suggestion, the current IEEE488.1 spec does not standardize any aspect of the I/O software; hence, the proposed enhancements to IEEE488.1 should not attempt to standardize any aspects of the I/O software either.

Answer to comment #3 from David Clemens entitled "Divergence from IEC 625"

Multiple examples of asynchronous development of the IEC and IEEE standards have occurred throughout the years without detriment to users. Furthermore, proposed enhancements are compatible with IEC 625. This issue was raised before the IEEE New Standards Committee (NesCom) when this project received its Project Authorization Request. The NesCom decided to approve the PAR despite this objection. The rational behind this decision was that the IEEE Std 488.1 standard had been modified in the past by the IEEE, without working in lock step with the IEC. Furthermore, since the proposed enhancements to IEEE488.1 are compatible with existing IEEE488.1, and IEEE488.1 is equivalent to IEC 625, the enhancements will work with any existing IEC 625 instrument.

Answer to comment #4 from David Clemens entitled "Interoperability Testing"

The draft has been extensively tested through industry use. Implementations of the new draft have been extensively tested and used in hundreds of thousands of applications since 1993 without any compatibility issues. The existing IEEE Std 488.1 has been updated several times since its first publication to clarify issues that have arisen as implementations became more widespread. Several suggested clarifications have been received from balloters. These will be incorporated into the final standard. As implementations become more widespread the standard can be revised in the future as needed.

Negative Ballot #2
Nathan Berg
Hewlett Packard Co.
Measurement System Division
815 SW 14^th St.
Loveland, CO 80537

Answer to comment #1 from Nathan Berg entitled "Backwards compatibility with existing instruments"

New CF multi-line messages: This issue has already been evaluated by the working group and is not considered a risk. The working group raised this issue when we realized that we had to create new multi-line messages to implement the additional functionality. We believe this issue is not a risk. Section 5.7 of the original standard states "When the ATN message is true, a device SHOULD ignore all multi-line messages that are inappropriate given the current states of the implemented interface functions." This sentence encourages designers to ignore undefined messages; however, as some of the negative balloters point out, designers are not required to ignore undefined messages since the standard used the word SHOULD which implies it is only a recommendation. The very next sentence in the original standard states "A device SHALL handshake the inappropriate multi-line message, but should not take further action including recording an error, requesting service, or interrupting the exchange of remote messages." Through the use of the word SHALL this sentence makes ignoring inappropriate multi-line messages a requirement in existing devices; therefore, eliminating the risk of incompatibility with existing devices that comply with the original standard.

Answer to comment #2 from Nathan Berg entitled "Data integrity may be compromised when a controller interrupts a non-interlocked data transfer"

The new draft handles this in a manner that is consistent with the original standard. As with the original standard, a controller must be a listener if it wishes to be able to take control in the middle of a transfer. The controller asserts the local message tcs (take control synchronously) just like the original standard. This forces the AHE function to eventually move into the ANCS (accept non-interlocked configured state) which will force the data handshaking portion of the AHE into the original three wire handshake mode of operation via transfers from either ANES -> ACRS or ANDS->ANTS->AWNS. After this transition, a controller may interrupt the data transfer in the same manner it does with the original standard.

Answer to comment #3 from Nathan Berg entitled "Restricted performance and data integrity problems with legacy devices"

The effects on system performance are already explained. The negative ballot points out that Section 7.2.4 of the new draft states "If SHE and AHE functions are used to transfer data with non-interlocked handshake cycles, all guidelines of section 7.2.3 should be followed" and since the draft uses the words ‘should’ as opposed to ‘shall’ it is a strong recommendation but not a requirement; therefore, we should explain the affect of system performance and data integrity when these guidelines are not met. The guidelines of section 7.2.3 already explain the affect of system performance and data integrity when these guidelines are not met.

Answer to comment #4 from Nathan Berg entitled "Substantial changes to 488.1"

Negative Ballot #3
Robin Steele
Hewlett Packard Co.
815 SW 14^th St.
Loveland, CO 80537

Answer to comment #1 from Robin Steele entitled "Limited Need for Higher Speed"

The TC-8 committee has already addressed this issue. This issue was raised before the TC-8 Committee when we discussed whether we should proceed with the project and ask for a PAR. The TC-8 committee voted in favor of the project and proceeded with a PAR from the NesCom.

Answer to comment #2 from Robin Steele entitled "Divergence from the IEC"

Multiple examples of asynchronous development of the IEC and IEEE standards have occurred throughout the years without detriment to users. Furthermore, proposed enhancements are compatible with IEC 625. This issue was raised before the IEEE New Standards Committee (NesCom) when this project received its Project Authorization Request. The NesCom decided to approve the PAR despite this objection. The rational behind this decision was that the IEEE Std 488.1 standard had been modified in the past by the IEEE without working in lock step with the IEC. Furthermore, since the proposed enhancements to IEEE488.1 are compatible with existing IEEE488.1, and IEEE488.1 is equivalent to IEC 625, the enhancements will work with any existing IEC 625 instrument.

Answer to comment #3 from Robin Steele entitled "Consideration for other High Speed Alternatives"

The working group resolved these questions several years ago. The working group has considered multiple solutions as part of the standardization process. When the working group first convened there were two proposed specifications; SD488 developed and proposed by CEC, and HS488 developed and proposed by National Instruments. At a subsequent meeting, CEC withdrew their proposal from consideration and supported the HS488 proposal provided National Instruments gave up its patent rights to HS488 implementations. National Instruments gave up its patent rights and the group from that point on worked on reviewing the HS488 proposal. Chris McKenna, a member of the working group, submitted a new proposal to the working group just before the final working group ballot. I sent Chris McKenna's proposal to the working group members with the final draft for voting with instructions to either (1) vote for the proposed draft, (2) vote against the proposed draft with comments, or (3) vote to consider the new proposal submitted by Chris McKenna. The response to that ballot was overwhelmingly in favor of going with the existing working group proposal. Chris McKenna later submitted his proposal to the German National Committee (DKE).

Answer to comment #4 from Robin Steele entitled "Complexity"

The additional circuitry required to support higher performance is optional therefore the designer and marketplace will make this decision. This issue was raised at the working group level. The working group believed that the tradeoff between the increased performance of the proposed standard versus any additional complexity and cost to implement it should be determined by the marketplace, not a standardization committee. The proposed standard does not make it a requirement that new designs implement the new enhancements. It allows for the creation and co-existence of implementations that comply with the original standard. Therefore designers of new devices will make this decision based on market factors and cost constraints.

Answer to comment #5 from Robin Steele entitled "National Instrument's Patent"

The patent release was issued by National Instruments in conformance to IEEE rules in 1996. This issue was brought up at the NesCom hearing to approve the PAR and at a future working group meeting. The NesCom approved the PAR despite this objection for two reasons: (1) Hewlett-Packard owned the patent to the original three-wire handshake when the original version of the IEEE Std 488.1 was approved by the IEEE, and (2) National Instruments submitted a letter to the IEEE assuring that they would openly license the technology to anyone if the new standard utilized any of it’s patented technologies. In a meeting of the working group this issue was raised by Paul Skar; at that time, National Instruments issued a letter giving up it’s right to the patent covering the technology incorporated in the draft standard. A copy of that letter has been attached to this rebuttal for reference.

Answer to comment #6 from Robin Steele entitled "Specification Revision Process"

This typographical error has not resulted in any misunderstanding of the technical content of the draft standard. There was an inconsistency in the draft numbering between the last vote of the working group and the official IEEE sponsored ballot. The working group approved draft 1.3 and the ballot distributed by the IEEE was labeled draft 1.2. This was a simple typographical mistake on our part. The working group worked from a list of instructions that explained how the original standard should be modified. Between the time the working group voted to support draft 1.3 and when the IEEE conducted its ballot, we had to merge the instruction list into the original document. For that process we used draft 1.3 as approved by the working group; however, for some reason, most likely due to a typo, the draft sent to the IEEE stated it was draft 1.2. This will be corrected in the final draft, which we are currently working on that incorporates the editorial changes we received for balloters that voted to approve with comments.

Answer to comment #7 from Robin Steele entitled "Results of Previous Sponsor Ballot"

This re-circulation includes the results of the only IEEE ballot ever conducted; there was no previous ballot. If the balloter is referring to ballots taken by the working group, only working group members received those results.

Negative Ballot #4
Philip Fleming
Philip J. Fleming & Assocs.
4665 Newstead PI.
Colorado Springs, CO 80906-4867

Answer to comment #1 from Philip Fleming

Addition of CF/SHE/AHE: The working group has verified that compatibility has not been comprised.

Maintaining compatibility was a primary goal of the working group. Furthermore, not allowing introduction of new and previously undefined functions is a concept intended for the designer to ensure that he or she does not add functions that are not in the standard; therefore compromising compatibility. This concept is not intended for a standardization body because it is their task to carefully review standards. If all existing standards were held to this stipulation then no standard could ever be improved by adding functionality.

Answer to comment #2 from Philip Fleming

All interface and network standards have cable length restrictions thus users are used to taking this into account, also for the existing IEEE 488 standards. This was discussed at the working group meetings; however, there was no way to increase the speed of the existing standard without the user having the knowledge of the overall system cable length. In fact the two other proposals considered also required knowledge of the system cable length. Since enabling the higher performance enhancements is an option the user decides, he or she will make that tradeoff. If he or she believes there is a risk that additional cabling may be added in the future, he or she can choose not to enable the enhancements, or may tell the system that there is more cable than really exists in the system to protect against this scenario.

Answer to comment #3 from Philip Fleming

The additional circuitry required to support higher performance is optional therefore the designer and marketplace will make this decision. This issue was raised at the working group level. The working group believed that the tradeoff between the increased performance of the proposed standard versus any additional cost to implement it should be determined by the marketplace, not a standardization committee. The proposed standard does not make it a requirement that new designs implement the new enhancements. It allows for the creation and co-existence of implementations that comply with the original standard. Therefore designers of new devices will make this decision based on market factors and cost constraints. Furthermore, a publicly available solution exists at the same cost as solutions that only implement the original standards functionality.

With respect to the alternative proposals, please refer to the answer of your question #6.

Answer to comment #4 from Philip Fleming

Answer to comment #5 from Philip Fleming

Multiple examples of asynchronous development of the IEC and IEEE standards have occurred throughout the years without detriment to users. Furthermore, proposed enhancements are compatible with IEC 625. This issue was raised before the IEEE New Standards Committee (NesCom) when this project received its Project Authorization Request. The NesCom decided to approve the PAR despite this objection. The rational behind this decision was that the IEEE Std 488.1 standard had been modified in the past by the IEEE without working in lock step with the IEC. Furthermore, since the proposed enhancements to IEEE488.1 are compatible with existing IEEE488.1, and IEEE488.1 is equivalent to IEC 625, the enhancements will work with any existing IEC 625 instrument.

Answer to comment #6 from Philip Fleming

The working group resolved these questions several years ago. The working group has considered multiple solutions as part of the standardization process. When the working group first convened there were two proposed specifications; SD488 developed and proposed by CEC, and HS488 developed and proposed by National Instruments. At a subsequent meeting, CEC withdrew their proposal from consideration and supported the HS488 proposal provided National Instruments gave up its patent rights to HS488 implementations. National Instruments gave up its patent rights and the group from that point on worked on reviewing the HS488 proposal. Chris McKenna submitted a new proposal to the working group just before the final working group ballot. I sent Chris McKenna's proposal to the working group members with the final draft for voting with instructions to either (1) vote for the proposed draft, (2) vote against the proposed draft with comments, or (3) vote to consider the new proposal submitted by Chris McKenna. The response to that ballot was overwhelmingly in favor of going with the existing working group proposal. Chris McKenna later submitted his proposal to the German National Committee (DKE).

Answer to comment #7 from Philip Fleming

The scope of this effort was limited to modifying the existing standard. The project authorization request that was approved by NesCom limited the scope of the project to modifying the existing IEEE Standard 488.1 and does not allow the working group to create a new standard.

Negative Ballot #5
S. W. Lomas
Norton Green Road
Stevenage, Herts SG1 2BA
England, United Kingdom

Answer to comment #1 from S. W. Lomas entitled "Compatibility"

The working group has verified that compatibility has not been comprised. The draft has been extensively tested through industry use. Implementations of the new draft have been extensively tested and used in hundreds of thousands of applications since 1993 without any compatibility issues.

With respect to the IEC comment, multiple examples of asynchronous development of the IEC and IEEE standards have occurred throughout the years without detriment to users. Furthermore, proposed enhancements are compatible with IEC 625. This issue was raised before the IEEE New Standards Committee (NesCom) when this project received its Project Authorization Request. The NesCom decided to approve the PAR despite this objection. The rational behind this decision was that the IEEE Std 488.1 standard had been modified in the past by the IEEE, without working in lock step with the IEC. Furthermore, since the proposed enhancements to IEEE488.1 are compatible with existing IEEE488.1, and IEEE488.1 is equivalent to IEC 625, the enhancements will work with any existing IEC 625 instrument.

Answer to comment #2 from S. W. Lomas entitled "Complexity"

The additional circuitry required to support higher performance is optional therefore the designer and marketplace will make this decision. This issue was raised at the working group level. The working group believed that the tradeoff between the increased performance of the proposed standard versus any additional cost and complexity to implement it should be determined by the marketplace, not a standardization committee. The proposed standard does not make it a requirement that new designs implement the new enhancements. It allows for the creation and co-existence of implementations that comply with the original standard. Therefore designers of new devices will make this decision based on market factors and cost constraints.

Answer to comment #3 from S. W. Lomas entitled "Reliability"

Answer to comment #4 from S. W. Lomas entitled "User Benefit"

Answer to comment #5 from S. W. Lomas entitled "Conflict of Interest"

It is common that industry experts lead standardization groups. The rigorous review embodied in the IEEE standarization process ensures an even-handed handling of issues. With respect to the comment about the conflict of interest, this was brought up at the working group meeting in February 1996. At that time the chairperson offered to step down. However, no one volunteered to take on the chairperson role so the group decided to proceed with Robert Canik as chair. Everyone in the working group was aware of the issues and encouraged to object to any actions of the chairperson they perceived to be biased. The negative balloter raises no specific examples of any improper actions.

Also the purpose of a standardization body is to fully disclose how a protocol works so it can be implemented by anyone and ensure compatibility. Hopefully the publication of the new standard will encourage others to develop their own implementations.

Answer to comment #6 from S. W. Lomas entitled "Conflict of Interest"

The working group addressed this suggestion several years ago. The working group has considered multiple solutions as part of the standardization process. When the working group first convened there were two proposed specifications; SD488 developed and proposed by CEC, and HS488 developed and proposed by National Instruments. At a subsequent meeting, CEC withdrew their proposal from consideration and supported the HS488 proposal provided National Instruments gave up its patent rights to HS488 implementations. National Instruments gave up its patent rights and the group from that point on worked on reviewing the HS488 proposal. Chris McKenna, a member of the working group, submitted a new proposal to the working group just before the final working group ballot. I sent Chris McKenna's proposal to the working group members with the final draft for voting with instructions to either (1) vote for the proposed draft, (2) vote against the proposed draft with comments, or (3) vote to consider the new proposal submitted by Chris McKenna. The response to that ballot was overwhelmingly in favor of going with the existing working group proposal. Chris McKenna later submitted his proposal to the German National Committee (DKE).