|
|
ARCHIVE: TCP-IP Distribution List - Archives (1984)
DOCUMENT: TCP-IP Distribution List for January 1984 (19 messages, 10572 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1984/01.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Wed, 4 Jan 84 9:38:18 EST From: Mike Brescia <brescia@BBN-UNIX> To: hu@columbia-20 Cc: mrc@su-score, brescia@BBN-UNIX Subject: bug associated with tops-20 release 5.3
There appears to be a bug in tops-20 release 5.3 which causes some bits to be garbled in the IP leader of internet messages. The possible effect is that mail or connections to UCL-CS or NTA-VAX may fail. Mark Crispin has sent some info to the tops-20 implementers mailing list about a fix for this problem. If you are having traffic failures, you should look into the fix soon. Mike Brescia (big gateway is watching you)
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Wed 4 Jan 84 16:40:08-PST From: Allan M. Schiffman <Schiffman at SRI-KL> To: tcp-ip at SRI-NIC Subject: The best way to use TCP with VMS?
I would appreciate advice on what software I should get to run TCP on VMS systems. I'm interested in connecting a bunch of Vaxen running VMS to a bunch of Vaxen and Suns running 4.2 (and TCP, of course) with Ethernet hardware. I've heard that there is stuff available from Wollagong and Compion (sp?). How do I contract these companies? Any experience with either of these? Are there other vendors? Please reply directly to me, I am not on the list. Allan M. Schiffman Fairchild AI Lab, Palo Alto -------
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 8 Jan 1984 1831 PST From: Eric P. Scott <EPS@JPL-VAX> To: TCP-IP@SRI-NIC Cc: Info-VAX@SRI-KL,TOPS-20@SU-SCORE Subject: Spreading the gospel
To them, TCP/IP is an "alternative network technology," "internet software" means IBM protocol emulator, X.25 is THE way to achieve multi-vendor compatibility, and understanding of networking internals is a black art. We who (of course) know better once again have the opportunity to liberate misguided little minds from such nonsense. Yes kids, I refer to none other than the 1984 Spring DECUS U.S. Symposium! Being the good (hah!) volunteer that I am, I'll request a VAX/VMS ARPANET/DDN Users session, try to schedule it early in the week, and not against the TOPS-20 session. I need additional speakers, so let me know before the deadline if you're willing. What I really want to see this time is some other sessions for the benefit of those who don't know what TCP/IP is all about. The deadline for abstracts is January 20, so let's try to develop a workable plan of attack reasonably soon so we can submit several together with appropriate scheduling constraints. Am I talking conspiracy here? You bet. -=EPS=- ------
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 18 January 1984 13:17 EST From: dca-pgs @ DDN1 To: ddn-nl @ DDN1, feinler @ sri-nic, leiner @ sri-nic, tcp-ip @ sri-nic Cc: maybaum@dca-ems,mcduffie@dca-ems,dca-pgs Subject: Tymnet Hardware Product; DDN Host Interface; DCA/Tymnet Meeting Report
Date: January 18, 1984
Comment:
As reported earlier, Tymnet has made a corporate decision and
commitment to produce and market a DDN interface product, which would
be offered to DoD DDN subscribers for the purpose of interfacing to DDN.
This interface product would have a Tymnet implementation of TCP/IP and
would be fully DDN compatible.
The undersigned hosted a meeting with Tymnet personnel on 17 Jan
at the DDN/PMO. Purpose was to obtain more details on the Tymnet product
concept and to provide informal public-domain information and public-
domain protocol spec documentation to Tymnet.
Besides offering their well-known packet-switched network services,
Tymnet has been independantly marketing interface hardware components
(the so-called Engine family) since summer 1983, offering Engines as
a stand-alone product separate from Tymnet networking services.
Tymnet plans to implement TCP/IP and make it available as an option
in the Engine line.
Two types of host interfaces will be offered:
(1)Network Front-End Processor - This would provide a host with
a TCP/IP+X.25 interface to DDN.
(2)Terminal Emulation Processor - In this approach, the host would
interface DDN in a "dumb-TTY" mode; the Tymnet interface would
present the host with a field of TTY ports. Host-host connections
would not be supported under this arrangement.
Terminal interface products would also be available. The Terminal
Emulation Processor mentioned above would necessarily function as an
inverse Terminal Access Processor. Both devices would need to
incorporate the Telnet Network Virtual Terminal protocol.
The Tymnet network supports synchronous terminals at this time.
(IBM 3270 Bisync & SNA, Honeywell VIP 7705)
It is thought that Tymnet's work in this area may be of value in
developing synchronous terminal interfaces for DDN.
A question was also raised concerning the following scenario:
Would it be desirable for a capability to exist whereby a terminal
could access Tymnet via a local Tymnet X.25 network facility, then
would pass through a Tymnet/DDN X.75 gateway and access DDN?
The payoff of this capability is that this would greatly expand
local terminal access capability to DDN in a short time, since Tymnet
local terminal access facilities are already in operation.
Issues:
(1) Should this be done?
(2) What initiatives would DDN undertake in the development of
Tymnet (or VAN) terminal gateways?
(3) What should such a VAN terminal gateway look like, besides
X.75? Probably TCP/IP and Telnet would be introduced at this
point.
(4) What about TACACS? Likeliest approach would be to
put it in the VAN terminal gateway. Access control is seen
to be the most sensitive issue arising from the VAN terminal
gateway concept; of course, it is well known that host security
must be implemented at the host level. Putting TACACS in
the VAN terminal gateway would provide the same level of
protection that TACACS in the TAC's provides; only difference
is that the terminal accessor would reach TACACS via VAN instead
of via dial-up phone circuit.
Tymnet was supplied at subject meeting with a full set of public-domain
DDN specs (X.25, IP, ICMP, TCP, SMTP, FTP, Telnet). It was also strongly
recommended that Tymnet pursue getting an Arpanet electronic mail account,
such as that available to DoD-sponsored customers from Tymshare. A follow-up
meeting was tentatively scheduled for the second week in February.
The undersigned wishes to thank Mr. Rod Richardson and MAJ Mike Allen of
the DDN/PMO, and Messrs. Len Ghiorsi and Pat Plunkett of Network Strategies,
Inc. for their valuable participation at the meeting. The undersigned also
would like to commend Tymnet, for their initiative in pursuing this venture.
Sincerely,
Pat Sullivan
DCA/DDN/PMO
<dca-pgs@ddn1>
Forwarded message(s):
-----------------------------------------------------
Date: Tue, 17 Jan 84 16:12:00 EST
From: dca-pgs @ ddn1
Subject: Attendance List for Tymnet/DCA Meeting, 17 Jan 1984, DDN/PMO
To: dca-pgs @ ddn1
Text:
NAME ORG'N PHONE
Pat Sullivan DCA/B616 (703)285-5036
Linda Berdine Tech. Mgr., Tymnet (703)827-9110
Jerry Edgerton Tymnet Federal Mgr. (703)827-9110
Frank Tapsell Tymnet Federal
Marketing Staff (703)827-9110
Rod Richardson DCA/B616 (703)285-5137
Len Ghiorso NSI (703)425-7440
Pat Plunkett NSI (703)425-7440
MAJ M. Allen DCA/B616 (703)285-5025
-------------END OF FORWARDED MESSAGE(S)-------------
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 19 January 1984 08:16 EST From: mundy @ DDN1 To: dca-pgs @ DDN1 Cc: ddn-nl @ DDN1, feinler @ sri-nic, leiner @ sri-nic, tcp-ip @ sri-nic, maybaum@dca-ems,mcduffie@dca-ems,dca-pgs Subject: Re: Tymnet Hardware Product; DDN Host Interface: DCA/Tymnet Meeting Report
Date: January 19, 1984 Text: Pat, The Tymenet development has lots of potential (mostly good, some not so good) and I thank you for the good summary. As the JCS guy who is supposed to be tracking our future data communications systems, I would like to participate in future meetings on this subject if I can. If possible I'd like to get some advance notice to fit them into my schedule. Thanks, Russ Mundy
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 19 Jan 1984 1636 PST From: Eric P. Scott <EPS@JPL-VAX> To: TCP-IP@SRI-NIC Cc: Info-VAX@SRI-KL,TOPS-20@SU-SCORE Subject: ARPAnet/DDN Session at Spring DECUS
I received quite a bit of positive feedback (from DEC even!) to my "Spreading the gospel" query, but alas no one seems prepared this early in the game to make firm commitments. Unless I hear a bunch of "I'll help!"'s by tomorrow afternoon, I will request 2 hours for "Internetworking the ARPA way," a series of mini- sessions tied together by a common theme. Some of these will be geared toward the pagan masses, some will be presentations on work done and in progress (using DEC computers), and somewhere in there will be a users panel. I expect representatives from the DDN-PMO and Digital to be in attendance. I need volunteers, I need volunteers, I need volunteers... -=EPS=- ------
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 84 07:13:37 EST From: Charles Hedrick <HEDRICK@RUTGERS.ARPA> To: EPS@JPL-VAX.ARPA Cc: TCP-IP@SRI-NIC.ARPA, Info-VAX@SRI-KL.ARPA, TOPS-20@SU-SCORE.ARPA Subject: Re: ARPAnet/DDN Session at Spring DECUS
I would certainly be happy to help. I will definitely be at DECUS, since it is in my home town! [You will finally get a list of good restaurants.] Anything in particular you would like from me. I know, or can find out by then, about most of the software and protocols commonly used on the 20. I don't know as much as some of the folks at Stanford, BBN, and ISI, and I use only DDN itself, I don't use TCP for local networking [yet]. -------
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 20 Jan 1984 1727 PST From: Eric P. Scott <EPS@JPL-VAX> To: TCP-IP@SRI-NIC Cc: TOPS-20@SU-SCORE,Info-VAX@SRI-KL Subject: "Internetworking the ARPA Way" at Spring DECUS
I have requested two hours sponsored by the Networks SIG for "Internetworking The ARPA Way" with the following abstract: Originally designed to replace the traditional Host-to-Host protocol used on the ARPAnet until 1983, TCP/IP is rapidly gaining acceptance outside the ARPA community due to its inherent suitability to local area networks and independence from any particular manufacturer, machine architecture, or operating system, as well as bundled support in Berkeley's 4.2 VAX Unix distribution. The specifications for the DoD Standard Protocol Suite of which TCP/IP is the most well-known are in the public domain; implementations for various systems are available from several vendors. This session will consist of several back-to-back subsessions intended to introduce newcomers to the ARPA philosophy, current R&D in the field, current concerns and future directions, and Digital's commitments to support this technology. Time will be provided for questions and general discussion, but it is suggested that experiences with particular hardware/software combinations be the subject of Birds-of-a-Feather sessions. Listed speakers are myself, Mark Crispin of Stanford University, Charles Hedrick of Rutgers University, an unnamed representative of the DDN Program Management Office, and an unnamed Digital Person. All that has been accomplished is that a block of time has been requested for scheduling. Between now and June we have to work out the details of how that time will be used. Eric P. Scott Networked Computer Systems Group Computer Science and Applications Section Jet Propulsion Laboratory ------
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 23 Jan 1984 11:48:16 PST From: POSTEL@USC-ISIF To: dewolf@COMPION-VMS, tcp-ip@SRI-NIC Cc: POSTEL@USC-ISIF Subject: Re: IP options and gateways
In response to the message sent Mon, 23 Jan 84 12:14:11 CST from dewolf@compion-vms Peter DeWolf: Hi: We have done some source route testing from a Perq at ISI and found that most of the BBN operated Gateways did perform the source routing correctly. Also many of the TOPS20 hosts will do source routing. If you want to arrange a joint testing session send a note to Alan Katz (KATZ@USC-ISIF). --jon. -------
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Jan 84 12:14:11 CST From: dewolf@compion-vms To: tcp-ip@sri-nic Cc: dewolf@compion-vms Subject: IP options and gateways
I am looking for a gateway that is known to properly implement IP route options. I am trying to test our implementation of such options. I have a test program which tells our IP to send packets with specified (loose or strict) routes. I have verified that our IP handles such packets properly itself -- it will forward such packets among out locally connected networks just fine, advancing the route pointer, decrementing TTL. In other words, behaving as one would expect a gateway to act. I examined the bytes being sent out, and all looks to be in the proper order. I then decided to see if my implementation agrees with the rest of the world's interpretation by sending packets to other gateways with source routing that specifies that the packet be sent back to compion-vms. I sent to the following gateways: 26.0.0.29 26.0.0.58 26.0.0.81 26.0.0.103 26.0.0.104 26.0.0.105 26.0.0.106 26.1.0.40 26.2.0.49 26.2.0.57 26.2.0.73 26.3.0.29 26.3.0.75 26.3.0.81 26.7.0.8 26.8.0.65 I never received anything back from any of the gateways. My packets were never routed back to me. No ICMP messages (parameter problem, whatever) were returned to me. Does anybody know if any of these gateways are supposed to process IP loose source route or strict source route options? Does anybody know of ANY gateway that supposedly processes such options? Thank you! Peter DeWolf Compion Corporation dewolf@compion-vms
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Jan 84 14:57:22 EST From: Mike Brescia <brescia@BBN-UNIX> To: dewolf@compion-vms Cc: tcp-ip@sri-nic, brescia@BBN-UNIX Subject: Re: IP options and gateways
P. DeWolf,
The following gateways from your list are claimed to implement source route
options, both strict and loose. We have run a test program against the
gateway implementation, and the same test program works against the
independent implemention on the BBNF tops20.
aerospace milarpa milbbn mildcec milisi milsac milsri minet yuma
The same code also runs in the rest of the gateways listed in the NIC
data base as "IP/PRIME".
The one problem you will find is that the record route stored by these
gateways is incorrectly marked as the address on which the gateway received
the packet rather than the address which the gateway uses for output.
Mike Brescia
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 23 Jan 1984 23:26:06 PST From: MILLS@USC-ISID To: brescia@BBN-UNIX, dewolf@COMPION-VMS Cc: tcp-ip@SRI-NIC, MILLS@USC-ISID Subject: Re: IP options and gateways
In response to the message sent Mon, 23 Jan 84 14:57:22 EST from brescia@BBN-UNIX Peter, DCN-GATEWAY (10.3.0.17, 128.4.0.1, 128.5.0.1, 128.8.0.1) shares the smae attributes with the gateways Mike mentions. In addition, all the DCN fuzzballs scattered over the globe implement source route along with the record-route limitation Mike mentions. Dave -------
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Fri 27 Jan 84 20:44:00-PST From: Mark Crispin <MRC@SU-SCORE.ARPA> To: TCP-IP@SRI-NIC.ARPA Subject: FTP implementation questions
I have the following questions for the Internet community regarding
FTP. Instead of hearing a chorus of "no"s I would rather just hear from
those who can answer "yes" to any or all of the following questions:
. Does your FTP implementation implement TYPE L with bytesizes OTHER than
8, 32, or 36? If so, is it useful or necessary to transfer with such a
bytesize?
. Would you consider as deficient an FTP implementation which did not
support a TYPE L bytesize other than 8, 32, or 36? Would a useful data
transfer be prevented by this deficiency? Give examples.
. Considering that PDP-10's store ASCII text as 5 7-bit bytes packed from
MSB in a 36-bit word, would you consider it incorrect for a PDP-10 FTP
implementation to treat TYPE L 7 as TYPE A? Remember that while purists
will argue that TYPE A should be more or less equivalent to TYPE L 8,
such a transfer would not produce a meaningful "ASCII text file" on a
PDP-10. If you disagree, please give examples. [Note that this is the
way the present Tenex/TOPS-20 FTP software works!]
. The current FTP standard does not define the 0xx FTP reply codes the way
the previous one did. Do you feel that an FTP server should be prevented
from issuing any unsolicited or "irrelevant" replies, or that it is
alright to continue to use a 0xx FTP reply code? What will your FTP user
software do when it encounters a 0xx reply code (I feel that the "right
thing" is to ignore it, optionally printing it on the user's terminal).
. Consider an FTP implementation where the REIN command is not implemented
and you cannot change your USER once you have logged in. Suppose this
implementation allows an unlogged-in RETR by doing an implicit login of
ANONYMOUS (the special account which allows retrieval of public-access
files). Should the FTP implementation announce the auto-login? If 0xx
codes are allowed, 030 is the obvious code. If 0xx is not allowed, what
would you consider valid for it to use to announce the auto-login
(remember, this will prevent a login as something else).
. Does your FTP user process change the port after each data transfer in
Stream mode?
. Does your FTP user process implement a mode other than Stream mode? If
so, which?
-------
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 28-Jan-84 02:21:38-UT From: mills@dcn6 To: saltzer@multics Cc: tcp-ip@nic Subject: DCN time server ticks again
For Jerry and the rest of you pinging the DCN1 (128.4.0.1) time server: that clock is once again ticking to the WWVB tocks following our move to a new office location. The precision should be within a couple of milliseconds relative to NBS time when the 'gram leaves our shop. I encourage our clock watchers, in particular the horde at BBN, to use UDP in preference to TCP, since the former are faster, more accurate and use fewer fuzzball resources. Dave -------
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: 30 Jan 84 1040 PST From: Joe Weening <JJW@SU-AI> To: Hornig%SCRC-QUABBIN@MIT-MC Cc: MRC@SU-SCORE, TCP-IP@SRI-NIC Subject: Re: FTP implementation questions
I am interested to hear how you implement TYPE L for various byte sizes other than multiples of 8 bits. My interpretation of "TYPE L n" is that you read or write n-bit bytes from the host file system in whatever way is standard, and transmit them packed as tightly as possible in the 8-bit TCP transmission bytes. Certainly this is what most PDP-10 implementations do for TYPE L 36, making it equivalent to TYPE I (at the PDP-10 end). When the byte size is not a multiple of 8, the packing and unpacking of the transmission bytes requires extra work in most machines. On the other hand, Mark Crispin has proposed that TYPE L 7 imply the transmission of each 7-bit byte in an 8-bit byte. This can be generalized to using the least multiple of 8 bits greater than or equal to the byte size. This avoids the packing/unpacking overhead, but it requires a larger number of transmission bits to send the same information. If this interpretation is adopted, is there agreement on whether the unused transmission bits are placed to the left or the right of the data bytes? A further question arises for bytes sizes of 4 or less: Should as many data bytes as possible be packed into each 8-bit transmission byte?
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Mon, 30 Jan 84 11:05 EST From: Charles Hornig <Hornig%SCRC-QUABBIN@MIT-MC.ARPA> To: Mark Crispin <MRC@SU-SCORE.ARPA>, TCP-IP@SRI-NIC.ARPA Subject: FTP implementation questions
Date: Fri 27 Jan 84 20:44:00-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
I have the following questions for the Internet community regarding
FTP. Instead of hearing a chorus of "no"s I would rather just hear from
those who can answer "yes" to any or all of the following questions:
Answers are for the Symbolics Lisp Machine FTP server.
. Does your FTP implementation implement TYPE L with bytesizes OTHER than
8, 32, or 36? If so, is it useful or necessary to transfer with such a
bytesize?
We implement byte all byte sizes between 1 and 16 bits. We do NOT
implement 32 or 36. We use TYPE L 16 for our executable code files,
which have a natural byte size of 16 bits. (Our user end falls back to
TYPE I when storing such a file somewhere which doesn't support TYPE L
16, but that leads to byte-swapping problems in some cases.)
. Would you consider as deficient an FTP implementation which did not
support a TYPE L bytesize other than 8, 32, or 36? Would a useful data
transfer be prevented by this deficiency? Give examples.
Yes. If our byte size above hadn't happened to be a multiple of 8 bits,
we wouldn't be able to fall back to TYPE I without possibly losing
information when the length of the file is rounded in the image transfer
process. As it is, when you look at our executable file transferred in
TYPE I to a big-ender machine the 16-bit bytes appear with their 8-bit
bytes reversed.
. Considering that PDP-10's store ASCII text as 5 7-bit bytes packed from
MSB in a 36-bit word, would you consider it incorrect for a PDP-10 FTP
implementation to treat TYPE L 7 as TYPE A? Remember that while purists
will argue that TYPE A should be more or less equivalent to TYPE L 8,
such a transfer would not produce a meaningful "ASCII text file" on a
PDP-10. If you disagree, please give examples. [Note that this is the
way the present Tenex/TOPS-20 FTP software works!]
Assuming that the PDP-10 uses NVT ASCII to store files internally, this
is correct. PDP-10's should always use the format produced by DPB for
odd byte sizes.
. Does your FTP user process change the port after each data transfer in
Stream mode?
Yes. Otherwise you lose big with TCP.
. Does your FTP user process implement a mode other than Stream mode? If
so, which?
Yes, Block mode. Much good it does us, as the only only other Block
mode implementation I have found is on Multics, and it is broken.
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Mon, 30 Jan 84 14:14 EST From: Charles Hornig <Hornig%SCRC-QUABBIN@MIT-MC.ARPA> To: Joe Weening <JJW@SU-AI.ARPA> Cc: MRC@SU-SCORE.ARPA, TCP-IP@SRI-NIC.ARPA Subject: Re: FTP implementation questions
Date: 30 Jan 84 1040 PST
From: Joe Weening <JJW@SU-AI>
I am interested to hear how you implement TYPE L for various byte sizes
other than multiples of 8 bits. My interpretation of "TYPE L n" is that
you read or write n-bit bytes from the host file system in whatever way is
standard, and transmit them packed as tightly as possible in the 8-bit TCP
transmission bytes. Certainly this is what most PDP-10 implementations do
for TYPE L 36, making it equivalent to TYPE I (at the PDP-10 end). When
the byte size is not a multiple of 8, the packing and unpacking of the
transmission bytes requires extra work in most machines.
This is the interpretation we use. Due to the tagged machine
architecture, we have to do the packing/unpacking for any byte size
other than 8.
On the other hand, Mark Crispin has proposed that TYPE L 7 imply the
transmission of each 7-bit byte in an 8-bit byte. This can be generalized
to using the least multiple of 8 bits greater than or equal to the byte
size. This avoids the packing/unpacking overhead, but it requires a
larger number of transmission bits to send the same information. If this
interpretation is adopted, is there agreement on whether the unused
transmission bits are placed to the left or the right of the data bytes?
A further question arises for bytes sizes of 4 or less: Should as many
data bytes as possible be packed into each 8-bit transmission byte?
This is not a change in interpretation, it is an incompatible change in
the specification. The existing document states quite clearly that the
data bytes are packed without regard to the transfer byte boundaries.
If you want to add it to FTP, I suggest that you add a new type rather
than trying to redefine TYPE L.
Also, this change does not avoid the packing/unpacking overhead, it
merely changes the algorithm to be used to one which is supposedly
easier to implement on some computers. I would have to be convinced
that itis worth changing this at this point in the life of FTP. The
effort would better be invested in designing a good file access
protocol.
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 30 Jan 1984 17:38-PST From: LEINER@USC-ISI To: EPS@JPL-VAX Cc: TCP-IP@SRI-NIC, TOPS-20@SU-SCORE, Info-VAX@SRI-KL Subject: Re: "Internetworking the ARPA Way" at Spring DECUS
Eric, Small but not minor correction. TCP/IP was not designed for the purpose of replacing NCP but was designed to support an environment consisting of multiple heterogeneous networks each capable of providing datagram service at a minimum. IP provides the means for interconnecting the networks and TCP provides the means for providing a virtual circuit using that datagram service. Barry
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 30 Jan 1984 17:40-PST From: LEINER@USC-ISI To: EPS@JPL-VAX Cc: TCP-IP@SRI-NIC, TOPS-20@SU-SCORE, Info-VAX@SRI-KL Subject: Re: "Internetworking the ARPA Way" at Spring DECUS
Eric, I'd like to ask you to provide a pre-pub copy of what you are planning on presenting if you intend (as it sounds from the aabstract) to represent the ARPA philosphy, approach, etc. Thanks much. Barry
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |