Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucbvax!FTP.COM!jbvb
From: jbvb@FTP.COM ("James B. Van Bokkelen")
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: ODI?
Message-ID: <9008160142.AA06081@ftp.com>
Date: 16 Aug 90 01:42:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: jbvb@ftp.com
Organization: The Internet
Lines: 30

I appreciated the existence of ASI; Up till now there has been a
single standard way to talk to 802.5 boards, and it was available
from all vendors.  IBM only broke my code once, by not obeying their
own spec in the LAN Support Program.  Now, however, NDIS v1 for 802.5
has reared its head (sans any un-bind support), and so a Class 3
packet driver is under test and will see the light of day next month.

I looked at ODI early on, and found that it had some advantages over
NDIS, and some disadvantages:

As Geoff says, the demultiplexing method is "you ask for the packet
types you want", but the last draft I saw specified a fixed 6-byte
field for the demultiplexing information.  This is insufficient for
RFC 1042, and I told the people at Novell, but I assume they chose to
hack around it instead of allocate more space.

ODI provides a good deal of buffer management functionality, which is
good if you can use it effectively.  It is also likely to be
handicapped in somewhat the same way as NDIS was initially, in that
the buffer management layer is only available from Novell or Netware
OEMs as part of Netware (as the NDIS Protocol Manager was initially
bundled with LAN Manager).

We may do an ODI interface if there is demand, but so far we haven't
seen any ODI hardware drivers.  Maybe I should hassle some of the
board vendors, because it sounds like Leo has seen at least one.
We're far away from most of them, and sometimes they forget...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901