Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!ut-sally!husc6!mit-eddie!genrad!decvax!ucbvax!STAR.STANFORD.EDU!JERRY From: JERRY@STAR.STANFORD.EDU Newsgroups: comp.protocols.tcp-ip Subject: RE: Wollongong TCP/IP for VAX/VMS Message-ID: <8707152153.AA04238@ucbvax.Berkeley.EDU> Date: Wed, 15-Jul-87 17:29:45 EDT Article-I.D.: ucbvax.8707152153.AA04238 Posted: Wed Jul 15 17:29:45 1987 Date-Received: Sat, 18-Jul-87 01:23:34 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 72 This is Dave Crocker, not Jerry Scott. I recently joined The Wollongong Group as Vice President, Software Engineering. We will soon be a host on MilNet, so I have not established an interim mailbox elsewhere. Please direct any short-term mail to me via Jerry at this address. The recent flurry of messages about Wollongong requires a formal response. As you are aware, The Wollongong Group has been selling TCP/IP-based products for some years. While we have been successful in doing so, we have been less successful in maintaining an unblemished reputation within the Internet community. Recently, we began taking actions to improve user perceptions. From a technical standpoint, the most significant of these actions involves upgrades to our VAX/VMS product called WIN/TCP, especially converting to the use of 4.3BSD as a code base for the TCP/IP implementation. By doing so, many long-standing problems were solved and performance has been substantially improved. On reviewing the messages that were sent to this distribution list, it appears that the basis for two of the three explicitly critical notes was a) system administration errors, and b) the use of very old software. At the present time, the new release (3.0) does not have any major TCP/IP bugs known to us, nor does it crash the operating system. The immediately previous version (2.3) has not had any bugs that crash VAXes for a time longer that any Wollongong personnel can remember. It is our policy to work closely with all users of our products to satisfy their needs. Mark Crispin's July 6 email message, while it contained no specific details, has been partially addressed in a public reply citing cockpit error, rather than faulty software. The message was sent by a system administrator whose contact with Mark triggered Mark's note. The system administrator cockpit error we identified does not involve any software bugs, but it does result in setting the hosts's own name to a constant ("Unknown"). To eliminate this confusion, we are changing the software to simply use the text version of the IP address, whenever a similar administrator error is made. As part of a test against one of the systems running Mark's TCP, we did encounter a client SMTP bug. WIN/TCP 3.1, which will be released shortly, fixes it. It was only discovered because of high delay in the Arpanet, thereby causing an extraordinary timeout. In addition to providing technically competent software, Wollongong must provide support for our products. This is critical. Although admittedly flawed in the past, this, too, is being significantly improved, as the recent TCP/IP activity cited above demonstrates. "Support" is a separate product and has to be purchased. There have been some customers who purchased the TCP product but did not, for whatever reason, purchase support. They then passed on the product to the real end-users and claimed, falsely, that we would not provide support. The cited case of our software crashing a VAX cluster appears to be an example of this. Although we subsequently established direct contact with a portion of the actual end-users affected in this way, we were unfortunately unable to find the remainder. The suggestion about our connecting the the Internet is extremely well- taken. Part of the reason I was asked to join Wollongong was to bring some Internet experience in-house. The wheels were already in motion, I discovered, to get a connection when I came on-board. We were supposed to be on MilNet about 4 months ago, and are in the final stages of debugging the telecom link. Lastly, with regard to our AT&T version of TCP/IP...it should be noted that we developed this product at the specification of AT&T and we are not free to add features on our own (AT&T markets the product; we do not). Hence, please ask them to suggest to us any changes that you deem appropriate. Dave