jbvb@WHIPPED-CREAM.FTP.COM ("James B. VanBokkelen") (02/23/89)
Sorry for the delayed response: Our serial line has chosen to get flakey this week, and this Saturday's move has taken priority over getting it fixed, especially since my PC can get out much better than our Ultrix 2.0 can (in other words, reply to "ftp.com", not "cream.ftp.com"). I am pleased to see TWG support for the Packet Driver spec, and I agree that a central clearinghouse is a good idea. I don't have a strong opinion yet as to how it should be arranged, but here are some issues: 1. Internet FTP access is one thing. We have files up for anonymous access already, as do Clarkson and NCSA. I don't know about TWG, but presumably it wouldn't be too hard. Our Internet connection is slower than some other sites, but I don't know how important this is. 2. There are a lot of people who aren't on the Internet. We already sell a couple of diskettes of "public-domain" (most of it is copyrighted, but freely copyable) software, (part PC-800 has a working Unix TFTP, a Time server and SLIP, Part PC-801 has Bind 4.7.3 and the matching MX Sendmail). We would probably add a part containing all Packet Drivers with suitable copyrights (distribution for "avoidable cost" duplication fee allowed). 3. Freeware distribution implies source code. However, I know of about a dozen vendors who wrote their own Packet Drivers, and they may not want to release source (lest someone else re-use their 82586 or 8390 driver, or clone the board, or something). Also, we have a couple of Packet Drivers that we can't disclose source code to, whether we want to or not, because of licensing agreements we signed in order to see the relevant specs. Thus, our own products will include a mixture of source and binary-only drivers, but we will only support binary drivers we wrote ourselves. Cramming a couple of other items into one message: I am about to release v1.09 of the spec. Changes include some clarification of set/get_address() and reset_interface(), one new error, and some new interface types. If you have a Packet Driver whose interface type you pulled out of the air, rather than getting it from me, please get in touch and reserve a type value. If people think it is time to try to get an independent organizaiton (e.g. SRI) to allocate interface types, let me know. In my opinion, as of v1.08, an "extended" Packet Driver now has fairly comprehensive multicasting support. If you disagree, let me know, and I'll try to fix it in 1.09. I am recomending that vendors consider doing "extended" drivers these days, in preparation for IP multicast and some non-IP protocols that need it. Regarding non-Ethernet demultiplexing issues: The Packet Driver wasn't supposed to hide the MAC layer from the Protocol Stack, just hide different hardware implementations. I know that some people have written ARP emulations to use an Ethernet stack on non-Ethernet interfaces. I don't think this is the right approach, at least for a commercial vendor like us. Yes, you could put together a spec for an IP-to-MAC interface, which would include ARP where it was needed, but you might still stumble over MTU issues (SLIP wants 1005 bytes in many implementations, 802.5 is 2042 bytes, etc.). PCIP (and PC/TCP) have layering boundaries which allow a "net" layer for Ether, ProNET-10 or whatever to be built-in below IP. I don't know if KA9Q or NCSA have similar boundaries. If they do, I would suggest that effort be directed to complemeting the existing Ether/ARP versions with ProNET-10, SLIP and NETBIOS versions. On 802.5, emulations of IBM's "ASI" interface (TOKREUI) already exist for all the mainstream cards, so I might not bother to re-invent the wheel. jbvb@ftp.com 26 Princess St., Wakefield MA 01880 ...!ftp!jbvb (617) 246-0900, fax: (617) 246-0901