The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: TCP-IP Distribution List - Archives (1985)
DOCUMENT: TCP-IP Distribution List for March 1985 (48 messages, 33261 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1985/03.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Fri 1 Mar 85 09:24:03-PST
From:      Jake Feinler <FEINLER@SRI-NIC.ARPA>
To:        contr23@NOSC-TECR.ARPA
Cc:        feinler@SRI-NIC.ARPA, nic@SRI-NIC.ARPA, red@SRI-NIC.ARPA, ole@SRI-NIC.ARPA, cain@EDN-UNIX.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   DoD Reference Model
Paul,

I would suggest that you check with Ed Cain, Chairman of the Protocol
Standards Technical Panel to see what the status of the latest DoD
Reference Model is.  The work was being done (I believe) through that
group with SDC participating.  There is also a useful article in
Computer Networks, Vol. 7, 307-318 (1983) by Cerf and Cain discussing
the DoD Internet Architecture Model.

The NIC would be glad to make such a document available if Ed agrees.

Regards,

Jake Feinler/NIC
-------
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Sun, 3 Mar 85 13:21:56 EST
From:      cadtroy!schoff@cadmus
To:        cadmus!tcp-ip@sri-nic
Subject:   tftp useful on localnets?

Does anyone use tftp?  Do you find the security implications reasonable?
In what situations do you normally use tftp?
How many implementations are there of TFTP?  I have heard of one
for the IBMPC done by a university, one done by TWG for the IBMPC, one
by Berkeley, another by TWG for VMS, another at Stanford for the MAC
......  Are there any more?

Please respond directly to me and I will summarize if it seems resonable to
do so.


marty
schoff@cadmus.ARPA


-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Monday,  4 Mar 1985 12:41-PST
From:      imagen!geof@Shasta
To:        shasta!cadtroy!schoff@cadmus.ARPA
Cc:        shasta!tcp-ip@sri-nic.ARPA
Subject:   Re: tftp useful on localnets?

There are several TFTP implementations that I know of.  Most are at MIT,
where TFTP originated:
	- Three in CLU (two on tops-20, one on Unix4.1/BBN-networking)
	- Three in C (two on V6 Unix, (one ported to IBM-PC); one in 2K rom's
	  for LSI-11 gateway's)
	- One in BCPL (on Alto)
	- One in PL/I (on Multics)

There is also an implementation at ISI, on a tops-20.  I think it is
written in BCPL.  Berkeley 4.2 comes with a version of TFTP, but I think
there are some problems with the implementation.

Uses:
	At MIT (this is 1.5 years out of date), we used TFTP for
general file transfer between many machines (for a long while (perhaps
still) it was the only protocol that was common to every machine the
system's groups used, see above list).  Also, it was used for netmail
between a unix system and Multics.  An Alto spooler program existed
that received files in TFTP and sent them to the Dover in EFTP (a Pup
protocol).  The gateways used TFTP to netboot off one of a number of
cooperating hosts.  Many machines used TFTP to communicate with the
line printer spooler on the V6 machine, and remotely print files.

Performance:
	The best performance I can remember was between cooperating Vax
750's running 4.1 -- 200Kb/s.  The V6/PDP-11 system could TFTP at the
full speed of its filesystem - about 130Kb/s, so testing results were
inconclusive.  Typical results were in the range of 100Kb/s between
most machines, with the exception of Multics and tops-20's.  Both of
these were on the Arpanet, which has 50Kb/s links.

	TFTP is a lock-step protocol, i.e., a protocol with sliding
window flow control with a fixed window size of 1.  The packet size is
fixed at 512 data bytes per packet.  TCP implementations should perform
much better than TFTP implementations, since TCP allows use of larger
packets and a greater degree of parallelism.  A side note on this is
that most TCP implementations average about the same transfer rates as
the TFTP rates we saw from well-tuned TFTP implementations at MIT.

Complexity:
	From the number of TFTP implementations there were at MIT, I
hope that I convey the impression that TFTP is T (trivial) to
implement, compared to TCP.  I've brought up an implementation
(although not the best implementation) in a day, from scratch to
working code.

Security:
	TFTP provides for none.  This was not considered to be a
problem at MIT.  The server's were all set up to be willing to transfer
any file if you gave a full name for it and it was globally accessible
on the system.  Since TFTP has no directory services, I guess this is a
kind of capability protection system.  The servers would only create a
file if the lowest access user on the system could create it, and would
not allow a file to be overwritten.  On multics, user's had to
explicitly expose their files to the tftp server.  Typically, users
send a file to a system by running a user process that uses their login
priviledges to transfer the file to a public directory on that system.
Then they login on the second system and move the file to where it is
supposed to go.  This is the same mode of operation as UUCP on most
systems.

- Geof
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Mar 85 11:08:52 EST
From:      cadtroy!schoff@cadmus
To:        cadmus!tcp-ip@sri-nic
Subject:   tftp implementation summary (long)
The following is a summary of responses to my request on tftp implementations.
I had asked this question looking to see how many people used this protocol
as a way to communicate with small machines.  I was surprised to see it used
for mail and gateway loading...............

marty
schoff@cadmus.ARPA
{seismo,wanginst}!ucadmus!schoff
***************************************************************************
***************************************************************************
From: Charles Hornig <Hornig@SCRC-STONY-BROOK.ARPA>

Symbolics has implemented TFTP for the Symbolics 3600, mainly so we
could talk to IBM PC's.

From: Christopher A Kent <cak@Purdue.ARPA>

We find it very useful for two things. One is IBM PCs used for
classroom instruction (the code is from MIT) sitting on an ethernet.
THe other is for booting diskless staions -- they have a prom that
understands how to get the bootload from a host via tftp.

The security problems are not too bad -- we tightened up the server a
bit. If you're really paranoid, you can just make files in a certain
area accessible, and force users to put things there.

chris
----------
*****************************************************************************
From: gillies.osbunorth@XEROX.ARPA



Re: TFTP use.  I used TFTP while at MIT (I was working in the group that
developed TFTP).  We were developing Arpanet C programs for IBM PC's,
and writing and compiling C on a Vax running 4.2BSD. TFTP was used to
download software (extremely quickly, I might add), and was invaluable
because there are very few FTP's available for the IBM PC.  FTP takes 2
connections, which highly complicates its implementation on a
single-tasking system.  And, after doing some TCP benchmarks, I can say
that FTP for an IBM PC would probably have run much more slowly.  I was
developing a multi-connection TCP for the IBM PC.

Doing cross development without TFTP would have been unbearably slow.
And to automate the debug cycle using FTP would have compromised a
computer password (because you must log in with FTP, which would have
been held in MS-DOS jcl files).  It did necessitate that I make my UNIX
files "public access", but since our software is distributed publicly to
universities, security was not a top priority.

				Don Gillies

*****************************************************************************
From: Rudy.Nedved@CMU-CS-A.ARPA

CMU CS/RI has it and uses it between small research computers like the
ones that control robot arms and some of the IBM PCs we have. It is
too insecure for us and in the future we may modify the protocol or
restrict what hosts can use it. It really needs to send USER/PASSword
down the line.

Rudy Nedved
Facilities Staff
Computer Science Department/Robotics Institute
Carnegie-Mellon University

*****************************************************************************
From: root%bu-cs.UUCP@harvard.ARPA (BostonU SysMgr)

I have used TFTP for one major reason, a workstation that only had
UDP/IP up. For that purpose I took a liberal reading of the RFC (it is
*very* liberal) and extended a filename to mean:

	path\0user\0password\0

and modified the 4.2 tftpd to look for (demand) this and if found the
transfer fork would setuid()/setgid() and chdir() into the user's area
[and no longer demand that the pathname be root-relative]. Seems within
reason as I would not run the daemon at all w/o at least this much
security. The RFC seems to encourage such local extensions.

I like TFTP because on a local net with files it can be naturally buried
into applications (it is much more like a subroutine call than an
interactive utility like FTP) such as a print server (one can add 'print'
to the list 'netascii', 'binary', such an extension also is encouraged
by the RFC) where completely reliable transfers are not that critical
usually (just print it again.)  The obvious extension would be to add an
XMODEM-like checksum to each block which would probably make it reliable
enough for general usage.  When serious errors *do* occur though the
protocol is not very robust and will tend to just give up.

	-Barry Shein, Boston University


*****************************************************************************
From: Glenn Gribble <GLENN@CIT-20.ARPA>

We have TFTP servers on 4.2 Vaxes, 4.2 Suns, and a Dec-20.  We have user
programs on the Vaxes and Suns, a PDP11, and HP9836s.  TFTP is usefull because
it is reasonably reliable and simple to implement.  We had to rewrite the
berkeley implementation of TFTP since theirs was not correct.  Security is
simply to the level of allowing only world-readable files to be read, and
only files owned by the TFTP server to be written (or a new file may be
created in a world-writeable directory).

glenn  {@cit-20.arpa}
-------

*****************************************************************************
From: Bob Walsh <walsh@bbn-labs-b.ARPA>


We use TFTP for downloading the Butterfly here at BBN.  We get speeds as
good as FTP over TCP, and speed seems to be limited by the share of the
CPU that the TFTP demon gets.

The Berkeley 4.2 tftp/tftpd are improperly written and do not conform to
the TFTP spec since the tftp conversation does not continue with the server
on a port != 69.  Also, the code does not work well on multi-homed hosts
unless it is fixed to use unconnected system calls.  I added another
security check:  /etc/hosts.tftp is read on start up and upon "kill -1 ..."
This, combined with requirements of file existence and public read/write
should make for a reasonable and secure enough system.

bob walsh

*****************************************************************************
From: Bill Croft <croft@safe.ARPA>
  
Marty,  I hope you will 'resummarize' when you get some responses
to your query.  The Mac TFTP you speak of was done by Mark Sherman
of Dartmouth, NOT Stanford.  Stanford just did the AppleTalk-Ethernet
gateway.  Mark ported the MIT (IBM PC) TFTP to the Mac.

>
> My apologies! (marty)
>

Also, I suspect TWG (The Wollengong Group?) just has ported over the
Berkeley 4.2 BSD TFTP from UNIX to run on VMS under Kashtan's Eunice.

As far as security goes, I know another university (name escapes me
at the moment) has added a name/password scheme to the TFTP protocol.
This was done with a simple extension to the initial RRQ or WRQ blocks.

****************************************************************************
From: POSTEL@USC-ISIF.ARPA

Marty:

At ISI, TFTP is available on TOPS20, Unix (on 780's, 750's, SUNs),
IBM-PCs, Xerox Dandelion's (in Lisp and in Mesa), EPOS (on 11/40, 11/44),
Perq (Pascal).

--jon.
-------

****************************************************************************
From: imagen!geof@Shasta.ARPA

There are several TFTP implementations that I know of.  Most are at MIT,
where TFTP originated:
	- Three in CLU (two on tops-20, one on Unix4.1/BBN-networking)
	- Three in C (two on V6 Unix, (one ported to IBM-PC); one in 2K rom's
	  for LSI-11 gateway's)
	- One in BCPL (on Alto)
	- One in PL/I (on Multics)

There is also an implementation at ISI, on a tops-20.  I think it is
written in BCPL.  Berkeley 4.2 comes with a version of TFTP, but I think
there are some problems with the implementation.

Uses:
	At MIT (this is 1.5 years out of date), we used TFTP for
general file transfer between many machines (for a long while (perhaps
still) it was the only protocol that was common to every machine the
system's groups used, see above list).  Also, it was used for netmail
between a unix system and Multics.  An Alto spooler program existed
that received files in TFTP and sent them to the Dover in EFTP (a Pup
protocol).  The gateways used TFTP to netboot off one of a number of
cooperating hosts.  Many machines used TFTP to communicate with the
line printer spooler on the V6 machine, and remotely print files.

Performance:
	The best performance I can remember was between cooperating Vax
750's running 4.1 -- 200Kb/s.  The V6/PDP-11 system could TFTP at the
full speed of its filesystem - about 130Kb/s, so testing results were
inconclusive.  Typical results were in the range of 100Kb/s between
most machines, with the exception of Multics and tops-20's.  Both of
these were on the Arpanet, which has 50Kb/s links.

	TFTP is a lock-step protocol, i.e., a protocol with sliding
window flow control with a fixed window size of 1.  The packet size is
fixed at 512 data bytes per packet.  TCP implementations should perform
much better than TFTP implementations, since TCP allows use of larger
packets and a greater degree of parallelism.  A side note on this is
that most TCP implementations average about the same transfer rates as
the TFTP rates we saw from well-tuned TFTP implementations at MIT.

Complexity:
	From the number of TFTP implementations there were at MIT, I
hope that I convey the impression that TFTP is T (trivial) to
implement, compared to TCP.  I've brought up an implementation
(although not the best implementation) in a day, from scratch to
working code.

Security:
	TFTP provides for none.  This was not considered to be a
problem at MIT.  The server's were all set up to be willing to transfer
any file if you gave a full name for it and it was globally accessible
on the system.  Since TFTP has no directory services, I guess this is a
kind of capability protection system.  The servers would only create a
file if the lowest access user on the system could create it, and would
not allow a file to be overwritten.  On multics, user's had to
explicitly expose their files to the tftp server.  Typically, users
send a file to a system by running a user process that uses their login
priviledges to transfer the file to a public directory on that system.
Then they login on the second system and move the file to where it is
supposed to go.  This is the same mode of operation as UUCP on most
systems.

- Geof

****************************************************************************
From: J. Noel Chiappa <JNC@MIT-XX.ARPA>

	TFTP is much used around here for booting things like
gateways, and also for talking to spoolers: it's nice and simple to
implement.  Also, it's common for simpler machines (e.g. IBM PC's) to
have TFTP and not a full blown FTP, since it's so simple. Also, we use
it to bring new machines on the net; we get TFTP up and then ship the
source for everything else in via TFTP! Finally, it's used a great
deal in an 'rcp' (4.2ism) mode for simply getting a single file from
somewhere known: it's not limited to 4.2 machines like 'rcp' is.
	We deal with the security problems by running TFTP servers
under a 'guest' (i.e. ANONYMOUS equivalent) ID; anything requiring
security stuff you FTP or TELNET to do.
	MIT has TFTP for the UNIX V6 IP layer it has, and also has
TFTP for TOPS-20 (as does ISI). We have worked on the 4.2 ones to
make them work (better); at one point the Berkeley release did not
work according to spec. We also did the ICMPC version.

	Noel
-------

****************************************************************************
From: John Leong <leong%CMU-ITC-LINUS@CMU-CS-PT.ARPA>


         We (some sites within CMU) uses TFTP quite a bit for file transfer
	 between our PC and Unix 4.2 and TOPS-20 hosts over general purpose
	 LANs (Ethernet and ProNet). The software package we used ish
more liberal and more conservative-- by that, I mean:
1) We restrict tftp access to other hosts on the local ethernet, and
2) We liberalized the conditions for writing a file: whereas before the
file had to exist and be world-writable, we only require the normal Unix
world write conditions now: either the above, or a new file in a 777
directory, i.e. /tmp.

There were quite a few bugs in the 4.2 implementation which hve mostly
been fixed by now, by various people....
Geoff Cooper thinks that TCP ought to be faster, but I think you can
make a strong case that on a single local network a simple lockstep
protocol with fairly big packets can do just as well, or better, because
the "in transit time" is so short.  If one tried tftp with 1K data
packets as 4.2 tcp uses, I bet it would beat it locally.  Of course, one
should hack it so it's process-to-process and not to files in order
measure it accurately.

Actually, a tftp implementation on Tops-20 would be useful to us now,
because ftp is so #@*&!^%.  Of course, localnets?

>
> edited by marty.
>

****************************************************************************
From: paul@rice


Marty:

I have written TFTPs for UNIX (4.1 Sys.10, 4.2 on VAXen and SUNs) and
VMS (with Phoenix), including some extensions to handle a more
reasonable mail protocol and remote command execution.  They're
actually all the same program compiled with different flags.  We use it
for file transfer, mail, remote command execution, and print spooling.

TFTP's lack of security is a problem, but not in the sense that we
worry about people stealing files.  Rather, it is an annoyance for
users that they cannot read their private files with TFTP, nor can they
send files into their directories on remote hosts, as these are rarely
world-writeable.  Also, I keep telling myself that one of these days I'm
going to add code to reject connection requests from outside Rice, but
I have much more enthusiasm for providing functionality than for
limiting it.

At any rate, TFTP is invaluable for us, as it is the only protocol that
some of our hosts have in common (such as IBM PC's and, one day soon,
Macintoshes).

Oh, to add to your survey, the CMU ITC wrote a TFTP for VM/CMS.
Unfortunately, it's incompatible with the WISCNet TCP/IP, which we use.

				Paul

****************************************************************************
From: lepreau@utah-cs.ARPA (Jay Lepreau)

We used to use it quite a bit before TCP was avail on some of our
smaller machines, such as Apollos and PC's, and we still use it some for
that.  It's easy to hack up a version fast. I made it much more useful
to us by modifying the security provisions in the 4.2 tftpd to be both
more liberal and more conservative-- by that, I mean:
1) We restrict tftp access to other hosts on the local ethernet, and
2) We liberalized the conditions for writing a file: whereas before the
file had to exist and be world-writable, we only require the normal Unix
world write conditions now: either the above, or a new file in a 777
directory, i.e. /tmp.

There were quite a few bugs in the 4.2 implementation which hve mostly
been fixed by now, by various people....
Geoff Cooper thinks that TCP ought to be faster, but I think you can
make a strong case that on a single local network a simple lockstep
protocol with fairly big packets can do just as well, or better, because
the "in transit time" is so short.  If one tried tftp with 1K data
packets as 4.2 tcp uses, I bet it would beat it locally.  Of course, one
should hack it so it's process-to-process and not to files in order
measure it accurately.

Actually, a tftp implementation on Tops-20 would be useful to us now,
because ftp is so fucked.  Of course, on the Unix systems we
use rcp (and on the Apollos too).


-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 1985 04:33-EST
From:      CERF@USC-ISI.ARPA
To:        CONTR23@NOSC-TECR.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Info on DoD protocol reference model?
Paul,

there is a published paper on the DOD Architecture which was presented
at a NATO conference late in 1982 (or early 1983?). Ed Cain and I wrote
that paper. It is not as detailed as the SDC material.  Mike Padlipsky
has written several papers comparing the DOD and ISO reference models.
Finally Jon Postel and Danny Cohen have likewise published commentary
on this subject.  Ed Cain may have reprints of the NATO articles -
unfortunately I do not. If Ed does not have them, Bob Lyons at DARPA
may have some since I remember sending mine to DARPA for their use.

If not Bob Lyons, then perhaps Barry Leiner.

Vint Cerf
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 1985 14:05 PST
From:      Art Berggreen <ART@ACC>
To:        dca-pgs@ddn1
Cc:        info-unix@brl,tcp-ip@sri-nic
Subject:   RE: 1822 I/F for SUN


> Does anyone know if there is such a thing as 
> an LH/DH 1822 Host-IMP interface for the Sun, whereby
> a Sun WS could interface directly to an IMP?
> I have a co-worker who asks me about this,
> and don't know what to tell him.

ACC makes an 1822 board for MULTIBUS.  The board has the same basic
fuctionality of the LH-DH/11.

I personally don't know what machines have support for the board.

Contact ACC sales (not me please) for more info.

    					Art@ACC.ARPA
------
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Mar 85 14:24:03 pst
From:      E. Howard Alt <alt%sri-lanka@sri-tsc>
To:        dca-pgs@DDN1.ARPA, sun-spots@rice.ARPA
Cc:        info-unix@brl.ARPA, sullivan@sri-tsca, tcp-ip@sri-nic.ARPA
Subject:   Re:  Query - Host-IMP Interface for SUN?
There is an 1822 board for the Sun.  Glenn Hastie (hastie@sri-spam)
wrote a driver for it. ACC makes the board.  I believe that the
no one has actually tested the board hooking it up to an IMP,
it has been tested with Packet Radio, though.

				Howard.

PS it should work just fine -- the sun has all of the berkeley IMP
software in it.
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 1985 1502-PST (Thursday)
From:      medin%ucbarpa@Berkeley (Milo Medin)
To:        dca-pgs@DDN1.ARPA
Cc:        sullivan@SRI-NIC.ARPA, tcp-ip@sri-nic.ARPA, info-unix@brl.ARPA, sun-spots@rice.ARPA
Subject:   Re: Query - Host-IMP Interface for SUN?

Uh... I dont think so.  You really don't want to do this.  If money
is an object, build a fuzzball or something as a gateway machine
that plugs into the IMP and have it output packets on the ethernet.

That way you don't have to kludge up the sun and it'll offload the
gateway functions onto the fuzzware...

						Milo
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 85 13:53 EST
From:      dca-pgs @ DDN1.ARPA
To:        sun-spots @ rice.arpa
Cc:        sullivan,tcp-ip@sri-nic.arpa,info-unix@brl.arpa
Subject:   Query - Host-IMP Interface for SUN?

Does anyone know if there is such a thing as 
an LH/DH 1822 Host-IMP interface for the Sun, whereby
a Sun WS could interface directly to an IMP?
I have a co-worker who asks me about this,
and don't know what to tell him.

Thanks,
Pat Sullivan
DCEC
Reston, VA

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Mar 85 17:15:11 pst
From:      E. Howard Alt <alt%sri-lanka@sri-tsc>
To:        dca-pgs@DDN1.ARPA, medin%ucbarpa@Berkeley
Cc:        info-unix@brl.ARPA, sullivan@SRI-NIC.ARPA, sun-spots@rice.ARPA, tcp-ip@sri-nic.ARPA
Subject:   Re: Query - Host-IMP Interface for SUN?
Actually, I think it would be much cheaper to buy the 1822 board
for a Sun (I assume they already have one and are asking if
they can connect it up to the arpanet) than to buy the hardware
for a fuzzball, or a normal gateway... unless they already have the
right hardware laying around.


				Howard.
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Mar 85 21:57 EST
From:      Mike StJohns <StJohns@MIT-MULTICS.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   ISO TP-4 report.
Having just read the executive summary of the ISO TP-4 vs DOD TCP and
not being at all familiar with TP-4 I have a few questions:

1) Is there any major problem in running TP-4 above DOD IP?  (I.e.  how
much of a hassle would it be to run tp-4 in parallel with TCP?)

2) Like wise, how much pain and anguish would there be running FTP,
SMTP, and TELNET above TP-4 (while still being able to communicate
between disparate hosts via a gateway) (This seems to me to be about the
same type of problem the net experienced when it converted from NCP to
TCP)


Mike
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Wed 20 Mar 85 02:08:22-EST
From:      "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        JNC@MIT-XX.ARPA
Subject:   Re: ISO TP-4 report.
	This is a very depressing document, but it's not completely
the fault of the NRC (although they did miss some extremely important
points). I do understand their motivations for the switch in terms of
using the same standard as everyone else. However, NBS and ISO lost
incredibly badly. They came up with a design which is different but no
better. I cannot imagine why, except to postulate a bad case of
'not-invented-here' ego gratification.

	To make the points the NRC missed, the most important one is
precisely that the TCP/IP architecture is not mature. There are major
problems yet to be tackled, and it will not work when scaled up. The
NRC group points out that since the two protocols are so alike, the
change will be easy. The flip side of that is that the switch won't
fix any of the current deficiencies. What's even worse is that since
the ISO thing is an international standard, changing it to fix the
problems is going to be even more of a hassle due to the immense user
base.
	Second, the NRC group is completely off base in its assement
of the risks. They make the naive (at best) assumption that if there
are performance problems it is in the implementation (page 21). They
completely fail to address the possibility that performance problems
may be inherent in the protocol architecture. This is actually just
a specific instance of the general point above.

	Service performance levels in the network have still not
really recovered to those of the NCP days. There are a variety of
reasons for this, some inherent in the architecture and others of a
transitory nature associated with the upheaval. Now, when we need to
be devoting skilled manpower to examining the problems and attacking
them, we will be forced to go through yet another upheaval, thereby
draining the manpower needed for improvement as well as setting us
back almost to ground zero on the honing of our implementations.
	One facet of the second point above is that one thing we
learned from TCP is that conventional operating system structures do
not mesh well with high-speed networks. However, we haven't really
been able to capitalize on that yet; the common systems on the
network (UNIX, TOPS-20) are dinosaurs. Once again, attacking this
needs skilled people who will be sunk into a semi-pointless conversion
effort.

	I wouldn't have minded converting to an international standard
if we got some good new technical capabilities out of it. The painful
(and in a much smaller system) NCP to TCP transition had that
characteristic; TCP was radically more powerful. The claimed
'advantage' of the TP-4 switch, which is that the two are so similar,
is precisely the largest disadvantage. Too bad standards committees
didn't go on the B Ark.

		Noel
-------
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Mar 85  8:58:35 EST
From:      Alex McKenzie <mckenzie@BBNH.ARPA>
To:        tcp-ip@sri-nic.arpa
Subject:   Re Comments on NRC Report
I won't try to defend either TCP or TP4.  I will comment on a few of the recent
comments.

1) There should be no major problem in running TP4 above DoD IP.  BBN, under
contract to NBS, has done so (in a prototype implementation).  However, my
understanding of the NRC report is that the ISO "IP" (actually called something
like "Protocol for Providing the Connectionless Network Service" - see RFC 926)
should replace DoD IP at the same time TP4 replaces TCP.  NBS has tried very
hard to have DoD IP serve as the foundation for ISO IP, and in my biased
judgement has mostly succeeded.

2) There should be no major problem running the higher-level DoD protocols
above TP4, since (in my judgement) TP4 and TCP provide equivalent
functionality.

3) Noel perhaps misunderstands the nature of ISO, and the NBS role.  ISO, like
any other group, has a certain amount of NIH syndrome - it would be naive to
suspect otherwise.  But the committees had large numbers of technical
participants from manufacturers, trying to solve real engineering problems
according to their best technical judgement.  NBS participated in ISO via its
participation in ANSI (i.e. NBS belongs to ANSI which belongs to ISO).  NBS's
mission (as I understand it) was to try to influence the formulation of ANSI
(and by extension ISO) standards which meet government needs.  One of the major
contributors to NBS when it asked the rest of the government what its needs
were was DoD, and the expression of needs, I think, was of the form 'we need
what TCP provides'.  Maybe that shouldn't have been so, I don't know, but given
that it was it is a measure of NBS's success that TP4 lookes so much like TCP.
Why isn't it a verbatim copy?  I can mention at least 3 factors which in my
opinion bear on this question.

a. TP4 is intended to be one of a family of protocols satisfying different
needs and making different assumptions about the network services underneath.
So it should have a similar style of command names, field structures, etc. to
the other members of the family (this may not be an interesting [or valid]
objective, but it is not motivated by NIH.)

b. Most manufacturers were unable to swallow the idea of intentionally sending
into a closed window.  They imagine their software will close a window because
they really don't want to expend ANY resources processing input.  Therefore the
protocol needs a reliable way of announcing that a previously-closed window is
now open.

c. Most manufacturers were unable to swallow the concept of beginning a
retransmission at any arbitrary byte boundary.  The imagined that once the data
stream had been fragmented into a given set of transmission buffers they would
want to send AND RECEIVE retransmissions in those units. (Maybe they had heard
of things like silly window syndrome?) They felt their implementations would
have better performance doig thing this way.

DISCLAIMER: I was involved in the development of NCP and TCP.  My employer has
a vested interest in TCP.  For the past several years I have been the manager
of a group which, under NBS contract, has participated in the ANSI and ISO
committeees responsible for the development of TP4.  Therefore I am probably
unable to make unbiased statements about any of these things.

Regards,
Alex McKenzie

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Wed 20 Mar 85 13:03:58-PST
From:      C. Cutler <CUTLER@SU-SIERRA.ARPA>
To:        herb@WISC-RSCH.ARPA
Cc:        JNC@MIT-XX.ARPA, nrc-committee@WISC-RSCH.ARPA, tcp-ip@SRI-NIC.ARPA, CUTLER@SU-SIERRA.ARPA
Subject:   Re: ISO TP-4 report.
Well said, Herb.  Tnx.   CCC
-------
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Wed 20 Mar 85 11:53:54-EST
From:      "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
To:        mckenzie@BBNH.ARPA, tcp-ip@SRI-NIC.ARPA
Cc:        JNC@MIT-XX.ARPA
Subject:   Re: Re Comments on NRC Report
	It's quite true that you can look at any change and point out
valid reasons for it; the change to variable length addresses has
clear motivations and in fact TCP2 (how ancient!) had them. I could
argue about some of the TP-4 decisions (especially the true cost of
probing closed windows) but these minor technical points aren't the
real issue.
	I also think the NRC underestimated the costs by quite a long
ways, perhaps an order of magnitude. There are a lot more machines out
there than they seem to think there are (page 32). They may have
correctly figured out the cost to the DoD, but there are a lot more
people using TCP.
	I guess the whole thing was a no-win situation. The result was
actually about what some people have been predicting for a long time;
given the circumstances, the result was predictable. The whole thing
is schizoid; as you correctly point out, NBS should get some points
for making sure the ISO didn't go off the deep end. However, it is
also true that the change buys us little except compatability.

		Noel
-------
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Mar 85 13:52:26 cst
From:      herb@wisc-rsch.arpa (Benington Herb)
To:        JNC@MIT-XX.ARPA
Cc:        nrc-committee@wisc-rsch.arpa, tcp-ip@SRI-NIC.ARPA
Subject:   Re: ISO TP-4 report.
I'm sorry we depressed you but let me comment as an individual who was
a member of the NRC panel, who entered the arena with relatively little
knowledge of either DoD or ISO standards, and who works for an organization
(System Development Corporation/Burroughs) which has very extensive
activities in both standards.

Your most challenging point is that the TCP/TP/IP architecture is immature,
that "it will not work when scaled up", and that "conventional operating
system structures do not mesh well with high-speed networks".  Except for
the issue of internetting and gateways, I can recall no evidence or opinions
being presented to the committee which supported your point.  I did sense that  
many members of the committee were concerned that DoD seemed to have placed 
little priority on measuring performance, on establishing standards and
objectives for performance, and on defining an R&D program to improve and 
assess performance.  However, I believe that the committee was satisfied that
TP4/IP are mmature enough at this stage to support its recommendations
for the following reasons:

	o  Most of the committee members who work for or with large
	   commercial vendors were well aware of the extensive experience
	   of these vendors in developmental implementations of TP4/IP
	   including integration of these implementations with commercial
	   operating systems.  The commercial vendors are well aware of the
	   importance of performance and they work hard to achieve it
	   (recognizing the high market demand for more functionality).

	o  Most of these individuals and organizations participated in
	   the ISO process which developed TP/IP and they contributed their own 
	   extensive experience with vendor specific protocols.  I believe
	   that there has been more protocol R&D associated with SNA, DECNET,
	   DSA, BNA and others than has been conducted by ARPA.  (Witness the
	   eventual adoption of X.25 by DDN.)

	o  The fundamantal purpose of the current ISO protocols is to
	   facilitate interconnection of products from different vendors--
	   it is not to define protocols that will be universally used
	   throughout each vendor's products.  (IBM will put "open"
	   protocols within SNA when it makes economic and architectural
	   sense within SNA.  It already has gateway products from SNA to ISO.)
 	   There is significantly growing demand for "openness" between vendors
	   which will not wait for perfection.  R&D must be continued,
	   diverse applications must be experienced and evaluated, standards
	   must evolve, but there is demand for standards now and suppliers
	   believe they are ready to provide them.  1984 NCC was a major
	   milestone in the development of the industry.  Protocol maturity
	   must be judged in the context of this climate:  many vendors,
	   much system software already developed and operating.

I believe that protocol implementation (including integration with
commercial operating systems) is the key factor now in achieving performance.
I would be interested in specific arguments and evidence to the contrary.

I mentioned above that the committee was well aware of some architectural
and research issues associated with internetting and gateways.  These 
present some tough issues but they don't seem central to transport and
the internet protocol itself.

You are concerned that much effort will now be diverted to conversion
rather than R&D.  The committee had many conversations about the DoD
R&D program but it didn't attempt to crystalize some conclusions and
recommendations.  The DoD is and will be acquiring many data networking
systems for operational (rather than developmental) applications.  The
committee unanimously felt that when it is appropriate to use TP4 in these
systems, only commercially available, off-the-shelf implementations should
be used--i.e., vendor standard products.  DoD shouldn't spend any
developmental resources to bring along the ISO products for its own use.
Also, the report concludes that TCP communities and TP4 communities can
coexist on common data networks.

The DoD research community is now TCP based.  If the DoD buys the report's
recommendations, what should the research community do?  Certainly it
shouldn't spend its time developing TP4 implementations.  In the near term,
where standards are needed, TCP seems fine.  In cases where major new
R&D subnetworks are needed, ISO should receive strong consideration if the
application needs commercial products and openness.  For example, such
a network could be used for the extensive simulations and gaming that are
needed for the Strategic Defense Initiative.

Finally, a comment on ISO and "not invented here".  Alex McKenzie has done
a fine job in commenting both organizationally and technically.  I want to add
two comments which don't conflict with his perspective:

First, NBS did a valiant job of pushing for TCP.  It wouldn't sell at the
time because:

Second, an international standards organization is often understandably
motivated to want to treat equally all proponents.  It's my understanding
that in the 1980 time-period, the British, Germans, and the US all had
proposals for transport layer protocols.  Equity prevailed--hopefully,
so did common sense.

Herbert Benington

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Mar 85 13:59:25 EST
From:      Jim Berets <jberets@bbn-vax>
To:        info-nets%mit-oz@mit-mc.arpa
Cc:        tcp-ip@sri-nic.arpa, jberets@bbn-vax.arpa
Subject:   Intel ISO Transport product
I have heard that Intel is offering an ISO Transport layer product.
Is this true?  Can anyone offer any additional information?

Please reply directly to me, as I am not on the list.
Thanks,

Jim
jberets@bbn-vax
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Mar 85 15:02:35 cst
From:      lhl@wisc-rsch.arpa (L.H. Landweber)
To:        tcp-ip@sri-nic
Subject:   ISO TP-4
The following describes our ISO TP-4 implementation. Experiments
to date indicate that, with the possible exception of the checksum 
algorithm, there is likely to be little difference in performance
between mature TCP and TP-4 implementations. Furthermore, existing
DoD applications will not be affected by the underlying transport
protocol.

More complete performance results will be available in about 3 to 6 months. 

   We have implemented the NBS version of the ISO Transport
   Protocol - Level 4 (TP-4) for BSD 4.2 Unix. It resides in the
   kernel and interfaces down to IP and upward to the socket
   facilities the same way as TCP. We currently have SMTP,
   Telnet, FTP and rlogin working with it. Since the socket
   interface is the same, changing these programs to use TP-4
   instead of TCP involved changing only one constant.

   The implementation is completely new and does not include any
   code from the NBS implementation.

   Currently our implementation supports connection establishment
   data transfer, disconnect and graceful close.  We are in the
   process of completing expedited data.  At present, it handles
   only the normal (7 bit) TPDU sequence space and always uses
   checksums.

   We have a joint project with MITRE Corporation to study
   performance of TP-4 in the Internet environment. The TP-4
   software has been installed at MITRE and will soon be
   installed at a university Arpanet site.


   Larry Landweber  (lhl@uwisc)
   Al Bricker (bricker@uwisc)
   Tad Lebeck  (tadl@uwisc)

   Computer Science Department
   University of Wisconsin
   1210 W. Dayton St.
   Madison, WI
   (608) 262 1204
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 1985 1021 GMT
From:      WIECLAWEK, JOE <JAW@JPL-MILVAX.ARPA>
To:        TCP-IP@SRI-NIC
Subject:   ISO TP-4
     How can I obtain the "ISO TP-4 vs DOD TCP" report and other
TP-4 specs and info.????
     Is it available by FTP ???

Thanks,
Joe
------
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 85 08:44:10 EST (Fri)
From:      Dave Farber <farber@UDel-Huey.ARPA>
To:        JAW@JPL-MILVAX.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: ISO TP-4
I gather that the report will be distributed as an RFP. In the meantime
I have a LIMITED number of reproductions I can send desperate people.

Dave
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Mar 85 11:54 PST
From:      Provan@LLL-MFE.ARPA
To:        tcp-ip@nic.arpa
Subject:   Why did ISO choose TP-4 instead of TCP?

I finally finished RFC942, the report on DoD transport protocols.  I've
got some comments on it that I'll wait a while to make, but one thing
about the report struck me and I feel a need to comment on it separately.

One of the major theses of the report is that TCP and TP-4 aren't
significantly different.  If they're so similar, why was TP-4 accepted
over TCP as the OSI standard transport protocol?  I've heard a little
mumbling about this or that being a little better, but the differences
outlined in the report seem to favor TCP in my eyes.  TP-4 reminds me of
NCP.  The flow control by segment comes immediately to mind.  I'm too
young to remember the TCP design days, but I assume they had good
reasons based on experience and experimentation to reject the NCP
segment flow control in favour of the byte oriented control.

But anyway, we have these two basically equivalent protocols.  One has
many implementations on several operating systems, the other isn't even
a final protocol yet and already has variations.  Why would even
consider using the second one as an international standard?

Well, the first explanation we hear is that the Europeans don't like to
admit that the Americans can do things better, so they had to claim it
was bad and redo it.  That probably has a lot to do with it (although
*I* certainly have no interest in using a protocol based on those
grounds), but it doesn't explain why there's so much American support.

The second explanation that occurred to me was that it was a communist
plot.  No, really, it makes a lot of sense that the Soviet Union would
want the United State's Defense Department to spend millions of dollars
unnecessarily to develop more network code.  Obviously I was beginning
to clutch at explanations.

But I can't shake the third explanation that occurred to me.  Look at
who's on this committee: DEC, IBM, AT&T, CDC, and Honeywell.  I don't
recognize *any* name from Internet discussions.  Well, I suppose I
should be honoured that they're all so interested in what protocol we
use, but anytime a bunch of corporations all agree on something, it
must be because they want to sell me something.  Sure enough, after
thinking a little it seemed obvious: the only reason we're being
convinced to change to TP-4 is that they can't sell us anything if we
continue using TCP.  Look at DEC: if they came out with a TCP
implementation for VMS and sold it for $80k, who'd buy it?  The
Wollongong code it much cheaper and probably better.  IBM is in even
more trouble, since it doesn't have a significant number of machines on
the Internet to begin with, and those are PCs with third party TCP
software.  Is this true with the other three?  AT&T doesn't get anything
for the UNIX TCP implementation, does it?  If these companies are really
just interested in a standard, why didn't they implement TCP years ago?

If someone could give me *any* good arguments for adopting TP-4 instead
of TCP, I'd love to have my mind changed.  But when I see things like
required fields of variable length and NBS arbitrarily adding graceful
close in defience of the standard, little flags go up telling me
something's not hip with this protocol.  When I hear rumours that DEC
and IBM and all the European phone companies are duking it out in ISO
committees to get as much of their protocols as possible, no matter how
shabby, into the standard, I lose confidence.  Now they're telling us
that it's obvious that we should adopt a suite of protocols that are 5
to 10 years behind in design and development from the one we're using.
And the best feature they can mention is that the only protocol level
that's anywhere near completion is equivalent to the matching level in
our protocol.  Who are they trying to kid?

Sorry for flaming off.  I was really excited about the entire OSI effort
when I first heard of it, but now I'm disappointed and angry.  I feel
like I'm being sold a bill of goods.  I'm sure there are lots of
qualified, confident people trying hard to produce a good protocol
suite, but I'm convinced that these protocols are being designed with
goals in mind other than that of making a good set of protocols.

						don provan
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1985 13:50:39 PST
From:      POSTEL@USC-ISIF.ARPA
To:        TCP-IP@SRI-NIC.ARPA
Subject:   re: TCP vs TP4

The US should use TP4 for the same reasons the US uses all the other 
International Standards. Like the Metric System, like the Centigrade
temperature scale, like A4 paper, like 220 volts, like....

--jon.
-------
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Mar 85 19:32:25 EST
From:      bellcore!karn@umd5
To:        umd5!tcp-ip@nic.ARPA
Subject: TP-4
Don, your second explanation may not be so far fetched. The USSR *does*
sit on the ISO, and I'm sure they took considerable pleasure in their
role in causing the DoD to spend millions to convert to TP-4 instead of
funding research on Star Wars. (Then again, given the way things are,
I'm sure the money won't come out of the existing DoD budget.)

I am very puzzled and confused by the whole TP-4 thing. In amateur packet
radio we recently went through a very similar trauma. Somebody came
up with a different link level protocol and insisted that we convert to
it. We heard him out and concluded that his protocol worked fine, but since
it was functionally equivalent to what we already had, a conversion would
be pointless. It is not too late for ARPA and the DoD to do the same thing.

Has anyone sat down and written a detailed, technical, side-by-side
comparison of TP-4 vs TCP? The only difference which I've become aware of is
byte-vs-packet sequence numbering, something I think favors TCP.

The industry press is getting a lot of mileage out of this thing, much
of it consisting of hype and misinformation ("TCP/IP's days are numbered!
Berkeley Unix's days are numbered!"). Many people who are not familiar with
the field are taking this to mean that datagrams are on their way out, since
ISO has long stood for uprightous VC protocols like X.25.

Phil
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 85 2:36:51 PST
From:      donwinter.pasa@XEROX.ARPA
To:        POSTEL@USC-ISIF.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: TCP vs TP4
Touchy, touchy, . . . . 
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Sat, 23 Mar 85 14:17 EST
From:      David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
To:        POSTEL@USC-ISIF.ARPA, donwinter.pasa@XEROX.ARPA, TCP-IP@SRI-NIC.ARPA
Subject:   re: TCP vs TP4
    Date: 22 Mar 1985 13:50:39 PST
    From: POSTEL@USC-ISIF.ARPA

    The US should use TP4 for the same reasons the US uses all the other 
    International Standards. Like the Metric System, like the Centigrade
    temperature scale, like A4 paper, like 220 volts, like....

That's one of the most enlightened observations I've seen on this
subject yet!  (Seriously!!)

    Date: 23 Mar 85 2:36:51 PST
    From: donwinter.pasa@XEROX.ARPA

    Touchy, touchy, . . . . 

But can you blame him??

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 85 18:18:18 PST
From:      DonWinter.pasa@XEROX.ARPA
To:        David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Cc:        POSTEL@USC-ISIF.ARPA, donwinter.pasa@XEROX.ARPA, TCP-IP@SRI-NIC.ARPA
Subject:   Re: TCP vs TP4
Jon has obviously never had to carry with him the array of plugs and
transformers neessary to run my contact lens sterilizer on international
travel. 220V is NOT a standard.

Why should the US NOT join in the International Standards? As long as
this doesn't imply that we end up with a centralized PTT.
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Sat, 23 Mar 85 19:22 PST
From:      Provan@LLL-MFE.ARPA
To:        tcp-ip@nic.arpa
Subject:   Comments on RFC942

I've finally finished rfc942, so now I'm ready to comment on it.  Y'all
sure are fast readers.  I'll try not to duplicate the comments I made
in the previous note, but some of the points have application here.

First of all, this entire report is based on the assumption that the
OSI is going to be the wave of the future and the NBS protocols are
going to be right up there surfing it.  I hear this over and over from
the people involved in OSI work (so much that I'm starting to believe
it), but I still haven't heard much more than yawns from anywhere
else.  And just the simple question of the graceful close versus the
sudden abort makes me wonder what NBS has to do with OSI.  Is the idea
that this is such a trivial difference that manufacturers are going to
have one version of their software for NBS believers and another for
all the others?  This issue really has me confused.

The report often says that if only DoD would jump on the bandwagon,
everything would get done licketysplit.  DoD has been on the TCP
bandwagon for several years now, yet there isn't universal vendor
support for TCP.  I'm only aware of one situation (TOPS-20) where TCP is
supplied by the manufacturer that sells the operating system.  I see no
difference between this state of affairs and the OSI IP.  It'll be the
same network trying to get it produced.  Why waste time on that if we
can get TCP vendor supported?  Well, the real answer is we can't get
either supported, probably.  And my experience tells me that a user will
probably be unable to insert his own network layer in a vendor supplied
TP-4, so the TP-4 implementations will probably be useless to DoD until
OSI IP is implemented.  All we'll accomplish is to waste as much time
implementing TP-4 as we spent implementing TCP in the first place.

I love the cavalier attitude the committee takes toward the unspecified
addressing format.  Sure it'll be good enough.  Of course it will handle
the DoD networks.  Well, unless they limit the number of networks or the
number of hosts or don't allow a protocol field.  But I suppose NBS will
ignore any difficulties here in the same way they added graceful
closes.  Nothing like an international standard, eh?

I think it's ridiculous to claim that OSI will satisfy DoD's needs.
Routing is a perfect illustration.  ISO hasn't even begun to do anything
concerning routing.  A lot of work has been done in the Internet.  What
are these people supposed to do?  Continue developing gateway protocols
and then throw them all out like TCP when ISO comes out with its
standard?  Or just stop working on the problem until ISO comes up with
it?  I don't think the Internet can wait 5 or 10 years for that to
happen.  If the Internet continues on the course it's taking now, in 5
years we'll be done with routing and be off solving new problems that
the ISO will just be realizing exist.  We can't just stop and wait for
ISO to catch up.  And if they're so intent on ignoring work done in the
Internet, we can't really be expected to work along with them, either.

Another point the report makes is that DoD has very special
requirements that the rest of the world doesn't have.  I think this is a
bogus point on two counts.  First of all, the DoD requirements are
quantitative, not qualitative.  It's not that other networks don't
require reliability, for example, it's just that they don't need to be
reliable during a nuclear attack.  Other networks need to handle sudden
surges in loads, too, just not as sudden or as great as the load on the
military nets when the first missles are launched.  I look at it like
military quality micro-chips: the military chips don't do anything
different, they're just more likely to do it correctly under fire.  In
other words, the DoD requirements are a question of implementation, not
of the protocols used.

Secondly, for any given point in the past, the DoD requirements have
merely been a few years more advanced than anyone else's.  A few years
ago, DoD had a requirement to hook many hosts together when noone else
did.  They went out and made a network that could do it.  Nowadays,
everyone needs to hook many hosts together.  Meanwhile, DoD has
developed a need to communicate across many networks, requiring an IP
level protocol along with all the stuff that people are working on now.
It doesn't take much of a brain to realize that most other networks
will need the same ability in the near future.  Many universities
already depend on it.  It's blatantly obvious that DoD must be the
leader in the network field.  That's why the ARPAnet was established.  It
can't afford to follow someone else, especially a body with the kinds
of delays ISO has.  In fact, the ISO can't afford not to follow the
Internet, although they obviously don't see it that way.

Finally, who *are* these people trying to sell us this line?  I don't
recognize a single name as having a pratical knowledge of the Internet.
But I do see DEC, IBM, AT&T, CDC, and Honeywell.  Does anyone on this
committee, or in any of the ISO committees, have any experience with
multi-vendor networks?  If there's one thing I've learned working on the
Internet, it's that the best way to deceive yourself about the quality
of a network implementation is to test it against itself.  Once you
start trying to work with other implementations, it's an entirely
different ball game.  What does DEC or IBM know about that?  They're the
*worst* people to judge what will make a good multi-vendor transport
protocol.
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 85 23:18:44 EST (Sat)
From:      mrose@UDel-Dewey.ARPA
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: TCP vs TP4
Gee, I thought the whole point of internetting was to let heterogeneous
networks communicate.  Why don't we just build some gateways instead of
converting to TP4?  If the claim is made that protocol translation isn't
advanced enough as a technology, then this is a good opportunity to start
doing research in it.  I don't know about you guys, but this business about
"you can have any car you want as long as it's a model-T, and any color you
want as long as it's black" begins to wear thin after a while in an area
where inter-operability is the name of the game.

/mtr
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 85 01:00:05 EST
From:      Charles Hedrick <HEDRICK@RUTGERS.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   support for TCP/ISO
There is probably at least something to the argument that vendors will
support the ISO protocols better than they support TCP.  I am trying to
hook all of our campus machines together using TCP. I find that a number
of the vendors I talk to regard TCP as temporary, and are putting their
work into ISO.  DEC seems to have a commitment to support ISO.  They are
trying to make sure that TCP support is available for their major
machines, but trying not to do any more than the bare minimum needed.  I
have heard (but more indirectly -- I don't have any close contact with
IBM) that IBM's attitude is similar.  Intel and Prime seem to be
ignoring TCP almost completely, but are doing ISO support.  

Indeed my major problem with the proposal is that it seems to be
unrealistic in its view of the short-term.  The report says, in effect,
that TCP is now in reasonable shape, so we can afford to continue using
it until ISO is developed by vendors.  I'm not sure that my experience
supports that. Here are the results of attempting to use TCP on all of
our systems:
  - VMS.  This is probably in the best shape, though for some purposes
	the DEC-20 implementation is better.
  - Unix. This works, too.  Telnet connections have incredibly high
	overhead, which is a serious problem for us.
  - DEC-20.  This is in fairly good shape.  We are seeing a number of
	crashes due to TCP support, but it should be possible to fix
	these.
  - IBM MVS.  No implementation of TCP for Ethernet currently exists.
	Several are on the horizon, but we have been sitting here in
	"just another 2 months" since last summer.
  - Prime.  No implementation of TCP for Ethenet currently exists.
	There may be an implementation for X.25.  Prime seems to be
	concentrating on ISO, or at least such is the rumor.
  - Intel.  Intel themselves seem strongly committed to ISO.  It seems
	to be possible to get TCP from third parties, but we haven't
	yet.  Even if we do, it may not talk to our other TCP's because
	of the Ethernet/IEEE incompatibility.
By the way, I am being charitable in saying that VMS, Unix, and DEC-20
have TCP implementations at all.  None of them generates "sync" when
clearing terminal output, nor do they negotiate binary on when going into
a program such as EMACS.  Unix has adopted the incredible strategy of
implementing these features using a different, but incompatible protocol
(RLOGIN), even though the facilities to do it are present in the Telnet
protocol.  The DEC-20 appears to generate the DM part of the sync, but
not the Urgent.  As we don't have source for Wollongong, we can't tell
what is wrong there.

This is not a terribly encouraging situation.  I certainly wouldn't
want to sit in this situation for a few years, waiting for ISO to take
over the world.
-------
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Sun, 24 Mar 85 16:30:30 est
From:      BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa>
To:        tcp-ip@sri-nic.csnet
Subject:   Re:  support for TCP/ISO

I too am trying to hook all our campus systems together using
primarily TCP. Adding a few more vendors:

	IBM/VM - Two implementations each with their merits
		(Spartacus/WiscNet), quality not yet known
		[we are putting up both right now, hardware
		is in, software mostly in]
	DG:AOS/VS - They are testing the software here, seems
		very promising and I *certainly* believe DG
		is serious about supporting TCP/IP native.
	AT&T 3Bx - Rumour has that AT&T has a contract in
		progress to host TCP/IP under SYSV (very strong
		rumour -- I believe it's almost done)
	4.2bsd - certainly many vendors (including DEC/ULTRIX)
		supporting this for their systems (eg. SUN.)
	IBM/PC - Fusion has an implementation (I have never tried it)
	Cray (II) - I believe their intention is to support it (?)

Added into the comments by Chuck, I find the sum of the same to be
very encouraging. Yes, there are a few bugs and misfeatures. I think
the purpose of the 4.2bsd RLOGIN protocols had more to do with a
new (un-RFC'd) security scheme allowing login to 'equivalent' hosts
without passwords rather than the similarities it had to telnet
(remember, most importantly RLOGIN was part of their RSH and REXEC()
scheme of remote execution and multi-host, user-easy extension of pipes.)

You add all of these vendors together and I believe you're talking
'reasonable' TCP/IP support for what? 97% of the systems out there?
How far off could I be? What's missing? MVS (serious, but yes, there
are projects out there), PR1ME and, and...? Atari? Apple? Harris?

I think that unless we have a mass exodus (read: mass hysteria)
away from TCP the bugs will get fixed long before ISO is running.

The only major hole I see is a DEC supported VMS TCP. Now DEC is
supporting TCP on TOPS-20 and ULTRIX, how much would users really
have to hammer on them to convince them to do it with all three
systems that could do that (I assume RSX, RSTS and RT11 to be effectively
dead and a non-issue, users of those systems will live with whatever
can be scrounged together.) I think we just have to convince DEC of
the obvious: That DECNET (like SNA) is a wrong thought and we will
*never* buy it, period, so they stop holding out hoping someday people
will 'see the light' and start screaming for DECNET. I personally
suspect that DEC will one of these days just bless the Wollongong
TCP/IP for VMS (whatever they call that, 'Approved Vendor' or some such.)

		-Barry Shein, Boston University

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Sun, 24 Mar 85 20:24 EST
From:      David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
To:        DonWinter.pasa@XEROX.ARPA, David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Cc:        POSTEL@USC-ISIF.ARPA, TCP-IP@SRI-NIC.ARPA
Subject:   Re: TCP vs TP4
    Date: 23 Mar 85 18:18:18 PST
    From: DonWinter.pasa@XEROX.ARPA

    Jon has obviously never had to carry with him the array of plugs and
    transformers neessary to run my contact lens sterilizer on international
    travel. 220V is NOT a standard.

    Why should the US NOT join in the International Standards? As long as
    this doesn't imply that we end up with a centralized PTT.

Sigh...  I'm all in favor of supporting a good, usable, featureful,
standard.  Jon's comment was about the arrogance of the US, which I
found to be a healthy and refreshing dose of cynicism (and/or sarcasm).
[The US isn't the only country with arrogance; I'm told speaking English
in certain parts of France will get you nowhere.]

Admissions: I implemented TCP for the Symbolics 3600 and I know a
moderate amount about IP.  There are glaring problems and deficiences,
so the only reason I am in favor of supporting them is because everybody
else does (modulo TP-4 on the horizon).  I have not read the TP-4
document, nor will I in the near future.  I have skimmed these discussions
and have the following, mostly non-technical, comments to make:

 * I think it would be great to have an international, good, usabable,
   featureful, standard.
 * TCP/IP fails in the good and featureful aspects, in my opinion.  (TCP
   has several advantages to the upper levels of the CHAOSNET protocol,
   but CHAOS routing has several advantages to IP routing.)
 * TP-4, as gleaned from the discussion, is mostly TCP with
   modifications to make even more people happy.  (My opinion of TCP is
   that it was designed by a committee where any feature anybody wanted
   was put in, regardless of worth or value.  By saying "more people
   happy" for TP-4, I mean that the committee is international instead
   of national and therefore prone to yet more randomness.)
 * TP-4 seems to have a bit of arrogance itself about it; namely "TCP
   wasn't good enough, so we fixed it up.  <Rude noise.>"
 * I've seen comments about address formats (or lack thereof).  Hell,
   bite the bullet, go to 64 bit addresses and come up with a
   hierarchical (like the mail domain system (with its problems fixed,
   of course) subnet routing scheme with redundant paths that WORKS.
   The first 16 bits can be a country code, the next 8 can be a type of
   customer (commercial, university, government, etc), the next 16 can
   be a super-group (e.g., which company, which university, which
   government branch) and the last 24 bits (accidentally the same size
   as the company-flexible part of Ethernet addresses) be allocated
   within the super-group.

If even half of this is true, I expect TP-4 does not differ in any
profound ways with TCP, and therefore it is not good nor featureful.  The
ONLY reason to convert is because "everybody else is using it and it is
no worse than what we have now" and not because "it is obviously the
right thing".  That in itself should be persuasive enough for the US
to convert.

For the record, here are some of my complaints about TCP/IP:

 * Last I knew, IP routing does not support redundant routes. 
   Therefore, the graph of gateways is acyclic (the IMPs are cyclic, but
   as far as IP is concerned, the collection of IMPs is ONE gateway) and
   any gateway going down segments the network.  [Maybe I'm just
   confused.]
 * I think SYN and FIN taking up segment space is a bit silly.
 * I think RST packets should contain textual data which is the reason
   for the reset.
 * I think FIN should contain textual data which is the reason for
   closing.
 * I would like to get rid of these silly port numbers.  A request (SYN)
   should have a symbolic contact name that identifies the service,
   e.g., "TELNET", "SUPDUP", "FTP", "TFTP", "NAME", etc.  The port
   number slot gets recycled into local-index.  See the CHAOSNET
   protocol.
 * I think the urgent pointer was not thought out well.  The ONLY
   application I know of for this is TELNET, and I don't know who uses
   it these days.  (One version of the 4.2bsd TCP implementation
   actually treated urgent in the lowest levels, regardless of the user
   side, and treated it wrong, I think.)
 * There should be an in-sequence out-of-band provision; ASCII
   terminals have a BREAK key, CHAOSNET has an EOF packet.  TCP has an
   urgent pointer, but that is an out-of-sequence out-of-band signal,
   i.e., a subsequent urgent supersedes previous ones.
 * Adaptive retransmission is one order of magnitude harder than
   on-the-ball people think it is, and two orders harder than the TCP
   spec implies.  Sorry, I don't have any solutions.  I've thought about
   it for a long time and every scheme is meta-stable.  At a minimum, I
   think the problem, even if it can't be solved, is wothy of a master's
   degree, which, in theory, means more thinking than anybody has yet
   given to the problem.

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 85 10:09 EST
From:      dca-pgs @ DDN1.ARPA
To:        tcp-ip @ sri-nic.arpa
Subject:   IBM-Supported TCP/IP for VM - Reforwarded
Comment: 
Forwarded message(s):  
-----------------------------------------------------
Received:  from su-shasta.arpa by SRI-NIC.ARPA with TCP; Thu 27 Dec 84 10:04:47-PST
Received-2:  from imagen by Shasta with UUCP; Thu, 27 Dec 84 10:05 PST
Date:  Thursday, 27 Dec 1984 09:27-PST
To: shasta!TCP-IP @ SRI-NIC
Subject:  "TCP/IP for VM Systems Available Commercially"
From: imagen!cpr @ su-shasta.arpa
Text: 

FYI, the following article appeared in the latest CSNET News, Fall,
1984, No.  6, and is reprinted without permission in its entirety
(please, someone at the CIC let me know if this is Bad Practice):

"IBM has formally announced that it will market the software known as
''The VM Interface Program for TCP/IP,'' developed jointly by IBM and
the University of Wisconsin.  With this software, IBM VM hosts can
connect to CSNET X25Net and use the ARPANET/DoD protocols for mail,
file transfer, and remote login.  Previously, the software was
available to universities and colleges only, as the ''WISCNET''
package.  (See CSNET News, No.  5.)

"The VM Interface Program for TCP/IP provides the following functions:
 - An implementation of the standard DoD protocols TCP and IP under
   VM/SP Release 2 or 3.
 - File transfer to and from remote sites using file transfer protocol
   (FTP)
 - Electronic mail to remote sites using the VM NOTE facility as an
   interface to simple mail transfer protocol (SMTP)
 - Remote terminal login using the TELNET protocol

"Sample programs are also provided for the Series/1 EDX system,
Series/1 RPS system, or Device Access Control Unit to support
interfaces to local area and packet-switched networks, including
ProNet, Ethernet, and X.25.

"There is a one-time chare of $17,000 for the software.

"If you would like more specific information about the net TCP/IP
interface software, please contact your local IBM sales representative
and refer to Availability Notice G320-9219."
 
-------------END OF FORWARDED MESSAGE(S)-------------

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 85 11:11 EST
From:      dca-pgs @ DDN1.ARPA
To:        root%bostonu.csnet @ csnet-relay.arpa, tcp-ip @ sri-nic.arpa
Cc:        dca-pgs @ DDN1.ARPA
Subject:   Vendor Support for TCP/IP (MVS and Others)

For IBM/MVS, a 3rd-party vendor, Network Solutions Inc.,
provides installation and product-level support with the
public-domain DARPA/UCLA TCP/IP networking package, using
ACC hardware at the networking level. If that sounds like
a funny way to do business, not to worry...it's the same
thing Wollongong does, and that seems to work all right.
I don't know if the package has an Ethernet driver&hardware
available or not, but that would appear to be an easy fix.
The DDN PMO has awarded a contract to Network Solutions and
ACC to interface "1 or more" MVS/TSO systems to Milnet.
By the way, we do have a MVS host here at DCEC connected
to Milnet with the UCLA package; I think there's a total of
5 connected to Milnet & Arpanet at present.

The DDN PMO has awarded interface contracts (based on TCP/IP)
for other machines: CDC, Honeywell, Sperry, and IBM VM.

It should also be noted that CDC, Sperry, and Burroughs have
made public commitments to support TCP/IP-based interfaces as
a DoD requirement (which it still very much is). A real good
source of this kind of info is the TCP/IP Implementors &
Vendors List, FTPable from the NIC under 
log anonymous
pathname: <netinfo>tcp-ip-implementations.txt
If someone is not on Milnet or Arpanet and wants a copy,
I'll E-mail them one.

I'm afraid that the NAS report may have greatly underestimated
the installed investment in TCP/IP.

Best,
Pat Sullivan
DCEC, Reston, VA.

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 85 12:57:41 EST (Mon)
From:      Mike O'Brien <obrien@CSNET-SH.ARPA>
To:        imagen!cpr@SU-SHASTA.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: IBM-Supported TCP/IP for VM - Reforwarded
	No problem.  CSNET allow reprinting of anything in the
CSNET News so long as proper credit is given.
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Mon 25 Mar 85 17:59:23-PST
From:      Francine Perillo <PERILLO@SRI-NIC.ARPA>
To:        dca-pgs@DDN1.ARPA, root%bostonu.csnet@CSNET-RELAY.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Vendor Support for TCP/IP (MVS and Others)
Better yet, if you cannot FTP a copy of the TCP/IP Implementations
and Vendors Guide, the NIC will mail you a pretty hardcopy.  Send
your requests to NIC@SRI-NIC.

-Francine Perillo
-------
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 1985 17:24-EST
From:      John Leong <leong%CMU-ITC-LINUS@CMU-CS-PT.ARPA>
To:        tcp-ip@nic.arpa
Subject:   TP-4
         Whether TCP is a good protocol or not, there is all likelyhood
	 that it will be supported by a lot of manufacturers as a
	 standard. The reason can  be found by tracing the history
	 of the ISO standard.  ISO themselve did not really do any
	 development as such. Of the different TP's, TP0 comes from
	 CCITT and the rest, including TP-4, is heavily influenced by 
         ECMA (European	 Computer Manufacturers Association).

         The composition of ECMA is quite interesting.  Besides a
	 collection of European companies like Philips, Siemen, ICL,
	 Olivette, Ericsson,  etc. the rest are composed of all the
         US companies such as IBM, DEC, etc.  Since TP-4 comes out
	 of this group (after more than 3 years of effort), the
	 implication is that all the major US companies will at least
	 not against it if not actively supporting it. 

         Realistically, however, TP-4 implementations will unlikely to
         become offical product for most companies within the next few 
	 years - unless there are some explicit incentives (e.g.: DoD 
	 insists that all suppliers must have TP-4). Most companies will
	 likely to be busy doing other more financially rewarding
	 things such as interfacing to SNA's latest child - LU6.2 (boring).
         In the longer term, it looks like it will fly : even if it is
	 yet another designed by committe protocol. 

         An interesting observation is that while both TP-4 and X25 are
         ISO protocols; TP-4 does not have as strong a clout as X25. 
         X25 comes from CCITT and defines the network interface. Since
	 networking is PTT (government)  monopoly in Europe you must play
         by the rule or you dont play at all  ... and even IBM have to 
	 comply. Since TP-4 is an end-to-end (ISO level 4) protocol, 
	 that is a different story.

        
         leong


-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 1985 08:35-EST
From:      CERF@USC-ISI.ARPA
To:        Provan@LLL-MFE.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Why did ISO choose TP-4 instead of TCP?
Don,

To add to your observations, there are fairly good indications that
the major vendors have already or are in the process of putting together
TCP/IP implementations for their commercially available operating systems.

I do not mean that they are expecting to sell these products to the
general public, but they do plan to sell them to DOD, at least, because
this is what DOD has asked for and is willing to acquire.  In general,
DOD benefits from using supported products - the maintenance for which
the vendor picks up the tab.  These TCP/IP products will be supported,
so far as I know.

there is even one vendor who is planning to make TCP/IP an internal
standard. Since this information is privileged, I cannot say which
vendor.

If the primary argument for adopting TP-4 is that it will be
supported as a product by the vendors, this may be less a consideration
today than it was even a year ago, given vendor initiatives and DOD
initiatives to acquire or arrange implementations.  There remains the
international standard argument, interoperability with NATO. This is
still a strong political argument for which I do not know of a good
counter-argument since the NATO countries are, indeed, relying on the
ISO protocols, as untested as they are.

I do not agree with the recommendation of the committee that the US DOD
should adopt TP-4 as a co-standard. My more cautious view is that one
should wait until commercially available implementations are available
and then test them.  The TP-4 is still in its infancy and is likely to
change, just as X.25 has changed rather a lot since 1975.  It is hard
to adopt a moving target as a standard, it seems to me.

Vint
-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Mar 85 14:51 EST
From:      "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: TCP vs TP4
Hell, throw in the english to russian automatic translator.  It can't be
any harder than X.400-SMTP.
-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Mar 85 11:22:18 BST
From:      Robert Cole <robert@ucl-cs.arpa>
To:        TCP-IP@sri-nic.arpa
Subject:   Re:  TCP vs TP4
Whilst your out there hacking interoperability gateways I would like
a SNA/DECNET gateway, TCP-IP/XNS gateway, TCP-X25 gateway, TELNET-X.29
gateway, SMTP-X.400 gateway etc, etc....

Robert Cole,

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Mar 85 00:38:46 EST
From:      Tom Hutton <hutton@seismo.ARPA>
To:        tcp-ip@sri-nic
Cc:        hutton@css-s3sun
Subject:   imp interface for gould powernode series

Im not sure if this is the proper list for this item but I thought
I would start here.

I have a Gould powernode 6000 series system on order and
have been trying to figure out if it can support the required
interface to an imp.  So far Ive gotten conflicting responses from
Gould reps, and the documentation also conflicts.  Its supports 
goulds version of 4.2BSD, and it mentions the imp in several manual
pages but dosent go into details on the sync interface to the net routines.

Anyone have any experience with these systems.


					Thanks,
						Thomas Hutton
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Mar 85 13:37:50 EST
From:      Mike Muuss <mike@BRL-TGR.ARPA>
To:        Tom Hutton <hutton@SEISMO.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA, hutton@CSS-S3SUN.ARPA
Subject:   Re:  imp interface for gould powernode series
Tom -

I have a Gould PN 6080 here on the network (BRL-SEM).  However, it is
attached via an Ethernet to one of our local gateways.

At present there is no way to attach a Gould machine to an IMP;
however, we plan to help Gould develop an HDH interface using an
SCM board;  don't expect this to be availible until Q3 or so.
		-Mike
-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      29 March 1985 1057-PST (Friday)
From:      stanonik@nprdc
To:        tcp-ip@sri-nic
Subject:   domain name resolvers
The last schedule for implementing domains (RFC921)
set 15 May 1985 as the date to begin significant use
of resolvers.  Are any resolvers available for 4.2bsd
Unix?

Thanks,

Ron Stanonik
stanonik@nprdc
-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Fri 29 Mar 85 12:33:22-PST
From:      C. Cutler <CUTLER@SU-SIERRA.ARPA>
To:        mike@BRL-TGR.ARPA
Cc:        hutton@SEISMO.ARPA, tcp-ip@SRI-NIC.ARPA, hutton@CSS-S3SUN.ARPA, CUTLER@SU-SIERRA.ARPA
Subject:   Re:  imp interface for gould powernode series


-------
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 85 16:07:22 EST (Fri)
From:      Mike O'Brien <obrien@CSNET-SH.ARPA>
To:        stanonik@NPRDC.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: domain name resolvers
	I think it's cute that we're supposed to start using this stuff
soon, but RFC 883, which is the Grand Master Specifier for all this stuff,
carries a big fat warning-in-a-box that it's preliminary only, and no one
should try to implement anything using it for a spec.

	Does anyone "authoritative" (pun intentional) have anything to
say about this?
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 1985 14:50:35 PST
From:      POSTEL@USC-ISIF.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   domain name resolvers

Two different domain name resolvers were developed and experimented with
for Berkeley Unix.  The DRUID system was developed by Peter Karp at
Stanford University.  The BIND system was developed by Doug Terry at
Berkeley.  The Unix support group at Berkeley is preparing a major revision
of the BIND system for inclusion in the next release of Berkeley Unix.
These systems (both DRUID and BIND) are not just the resolver, but include
servers as well.

--jon.
-------
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Sat, 30 Mar 85 12:12 EST
From:      Charles Hornig <Hornig@SCRC-STONY-BROOK.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   domain conversion
Can anyone offer guidance on the question:

"When can I start using my domain-style mail address
(Hornig@Stony-Brook.SCRC.Symbolics.COM) in mail headers sent to the
ARPANET?"

RFC 921 does not seem to mention this topic.

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 85 14:55:53 EST (Sun)
From:      Dave Farber <farber@rochester.arpa>
To:        dca-pgs@ddn1.arpa
Cc:        root%bostonu.csnet@csnet-relay.arpa, tcp-ip@sri-nic.arpa
Subject:   Re: Vendor Support for TCP/IP (MVS and Others)
I have tried to be quiet but.. The NAS committee did not operate
under the impression that the installed investment in TCP was not
great. If we had, we would have opted for different recommendations. We
understood and I believe stated so that there was a large base there.
HOWEVER, the argument made is that much of this software is special
systems produced not part of the normal commercial line of software
products and as such is and must be more expensive than normal
products of a vendor. 

Many of us believed that the adoption of international and national
standards (please remember that ISO TP4 is the draft Federal 
standard as published by NBS) will in the long run make for 
a lower cost and better more widely available products.

Dave
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Sun, 31 Mar 85 14:21 IST
From:      Henry Nussbacher  <vshank%weizmann.BITNET@WISCVM.ARPA>
To:        <tcp-ip@sri-nic.arpa>
Subject:   An analogy
On a planet far far away - in a time long long ago...

There were  two groups - one  called the Eups and  the other
group was known  as the Mericos.   The planet  they lived on
was called Urth and there were no seas or oceans, only land.
Neither group knew how they got there but when they did, the
entire planet was crisscrossed with railroad tracks.

Some Mericos decided one day to  build a railroad train that
would run around the entire circumference of the planet.  As
the  Merico train  passed  small  towns and  villages  other
Mericos would put wheels on their houses and hook up to this
very long train that had formed.

As time went by,  the train got longer and longer.   All the
Mericos had long since coated the wheels of their homes with
rubber and had  installed shock absorbers to  their homes so
as to minimize the jarring effects of riding railroad tracks
for months on end.

Life was good.   Suddenly, the railroad train passed through
Eup  country.    Since  this was  an  open-ended  train  and
discrimation did not exist,  the Eups decided they too would
like to connect to this worldwide train.

But they said, "Why do you need rubberized wheels and why do
you need shock absorbers?"

So the Mericos said,  "We have been living on this train for
2 years now and without it life would be intolerable!"

Well the Eups  didn't find the answer  suitable enough.   So
they said,  "We will join your train but we will not install
rubberized wheels or shock absorbers.  And since we think we
know a little more  than you,  we want all of  you to remove
your shock absorbers  and your rubberized wheels  since they
really are not needed."

The Mericos complied and the Eups joined in.   After a month
of  riding  on this  worldwide  train,   the Eups  called  a
meeting.   They said, "We have analyzed the recent vibration
problems  on  the  Urth  train,    and  have  the  following
recommendations to  make.   One  - every  house should  coat
their wheels with  high impact plastic.   Two  - every house
should install shock absorbers under their house."

The Mericos asked,   "But isn't that the way it  used to be?
Didn't we  tell you  we knew  better from  experience?"  The
Eups refused to listen and ended the meeting.

Nowadays,  the worldwide Urth train winds its way across the
planet and all houses connected to it are quite happy.

Morale:  Everything has  a way of working  out right.   It's
just the road getting there that is bumpy.

Hank

END OF DOCUMENT