The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1982)
DOCUMENT: TCP-IP Distribution List for January 1982 (8 messages, 22047 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1982/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:      Tue Jan  5 03:01:41 1982
From:      ucbvax!tcp-ip
To:        fa.tcp-ip
Subject:   TCP-IP Digest, Vol 1 #10

>From tcp-ip@brl Tue Jan  5 02:51:29 1982
TCP/IP Digest             Tuesday, 5 Jan 1981      Volume 1 : Issue 10

Today's Topics:
                              Administrivia
                   ComputerWorld on the TCP/IP Cutover
                   Amateur Packet Radio using InterNet
                      Overloading the Poor Dot (.)
----------------------------------------------------------------------

From:      Mike Muuss <Mike@BRL>
Subject:   Administrivia

Folks -

	It looks like somebody on this list is feeding copies of the TCP/IP
Digest to ComputerWorld magazine, which seems delighted with this
newfound source of "inside" information.  While it is my intention that
this list receive as broad a distribution as possible, several
tightropes must be carefully traversed:

	Networking plays a vital part in the Mission of the Ballistic Research
Laboratory (BRL), which fully supports the distribution of the TCP/IP
Digest.  However, the ArpaNet is intended for U.S. Government business,
and is not supposed to compete with commercial packet networks.  This
has a rather limiting effect on the group of people who can freely use
the ArpaNet.

	More importantly, though, is a question of content.  If it becomes
known that contributions to the TCP/IP Digest will appear in ComputerWorld,
possibly verbatim, or perhaps cast in the wrong light, then I suspect that
there will be a marked decrease in the quantity of information that is offered.
Few of us expect our net mail to wind up published in the commercial press,
and only the brave will knowingly open themselves up to this kind of direct,
external exposure.  And the cost?  Those readers who desperately need the 
information on what is happening may find their information sources again
reduced to RFC's and official notices, carefully worded for public scrutiny.

	This digest was intended as an open forum?  Is a direct pipeline
to the outside world too open?  I solicit discussion on this matter.
Maybe we can reach a consensus?
					Happy New Year!
					  -Mike Muuss

------------------------------

From: chico!duke!unc!grumpy.smb at Berkeley
Subject: Computerworld on the TCP/IP cutover

Well, they're at it again.  Here are some excerpts from the December 14
issue:

	Arpanet, the Pentagon-sponsored packet network that supports U.S.
	computing research, is slated for Jan. 1, 1983 cutover to two
	protocols that some experts predict will revolutionize
	commercial data communications.

	Considered the world's first packet network, Arpanet is expected
	to become an internet -- a network of networks -- ... said an
	informed source, who revealed the cutover date.

It was secret?

	...  Arpanet was not built to support wartime communications
	among the military, but the planned cutover to TCP/IP -- roughly
	a year away -- suggests that computer scientists have a lot of
	confidence in the protocol pair.  An Arpanet crash would
	seriously disrupt American research and development in many
	fields of science and technology, one expert maintained.

	...  A number of TCP/IP developers seem to believe that Arpanet
	will be ready Jan. 1, 1983 cutover [sic] -- but not all of them,
	Arpanet correspondence revealed.

	Available to all Arpanet subscribers, electronic mail files on
	TCP/IP include the following dispatch by a Stanford University
	researcher:

	"Some people [believe] that TCP work on [Digital Equipment
	Corp.'s] Tops-20 [operating system] is 'done.'... I believe
	the 1983 deadline for TCP conversion will not be met.  I have
	worked on BBN's TCP at the user program level; specifically, I
	have implemented general user Telnet for TCP as part of a
	general multiple-network Telnet for Tops-20.

	"Briefly, the Tops-20 TCP implementation in its present form is
	unacceptable to Stanford and many othe Tops-20 sites.  It is sad
	that so many bright people at BBN have had to maintain this dog
	instead of working on a complete rewrite."

	This critic wrote, in his Arpanet communique, that "the TCP
	process consumes between 40% and 60% of the CPU.  We simply
	cannot sacrifice that much of an already-loaded CPU to implement
	a network ."

[ I suppose that the TCP Digest quoting ComputerWorld quoting the TCP Digest
  is only fair!  -Mike ]

------------------------------

From: John C. Gilmore <GNU at MIT-AI>
Subject:  Amateur Packet Radio using Internet
To: CERF at USC-ISI
cc: Tcp-ip at BRL

    From: CERF at USC-ISI

    Your TCP-IP digest entry caught my attention concerning
    addressing capability in the IP protocol. I'd like to know
    more about your "internet packet radio" since it isn't
    one of the projects ARPA is supporting. Is this something
    you are pursuing as a graduate or undergraduate effort
    or supported by another funding agency?

    Vint Cerf
    DARPA/IPTO

Amateur Packet Radio is an experimental networking implementation
among Amateur Radio Operators under the regulation of the FCC.  It
is a group of "hams" creating a network for digital communication
among citizens.  It is not supported by ARPA or any government agency
(although AMRAD hosted an "Amateur Radio Computer Networking
Conference" in conjunction with NBS in October).

We currently favor the Internet Protocols, with minimal modifications,
to encourage timely comprehension, software development, and
extramural connection.  Our network has two constraints that we hope
are not unique, which is why I sent my query to TCP-IP, hoping for
known solutions.  They are:

	There is no underlying software protocol; IP Datagrams are
	transmitted without enclosure at the lowest level. (This
	is not, so far, a problem, but we're wondering if anyone else
	is doing similarly.)  The medium is broadcast and there are 
	contention problems.

	There is no central authority; no user sign-up; no fixed
	connectivity or user location.  Each terminal node runs the
	same program with a small number of variables different (at
	least one unique).  Nodes can appear, disappear, and move at
	any time; connectivity depends on electromagnetic weather.
	We had trouble with 24-bit addresses in this environment,
	since we have no way to create unique addresses that short.

If the TCP-IP mailing list is for Official U. S. Government users
only, rather than for the clarification, distribution, evolution, and
improvement of the standard among all who are gaining experience with
it, then please excuse my assumption and have me removed from it.

[ Nope, you are in the right place.  -Mike ]

------------------------------

Subject: Re:  Amateur Packet Radio using Internet
From: CERF at USC-ISI
To: GNU at MIT-AI
Cc: Tcp-ip at BRL
In-Reply-To: Your message of 30 December 1981 05:51-EST

1. TCP-IP Digest is an open forum and your entry was perfectly
valid - just caught my attention since I didn't know about the
internet protocol choice by the Amatuer Packet Radio group. I did
know a little about the private Packet Radio work.

2. Use of raw IP formats could cause you some trouble. The current
  architectural assumptions are that a gateway can "direct" an
  IP THROUGH another gateway, but to do this, it uses a lower
  layer of addressing (encapsulation philosophy). This seemed
  quite natural to us during design of IP since all the nets we
  were concerned with or knew about had a lower layer format with
 local addressing - even Ethernets.

  In a single network architecture, populated with a blizzard
  of private packet radios, you are faced with a number of
  challenges. First, the generation of unique identifiers.
  Second, the use of these identifiers to aid in routing
  decisions.  I am not entirely convinced that a geographic
  basis is necessarily helpful - in the ARPA packet radio net,
  for example, the actual location of a radio is not always a
  good indicator of its radio connectivity into the system.
  Routing towards its geophysical location may in fact fail
  while routing "away" toward the high mountain peak which is
  in LOS may help.  

  In your case, some geographic knowledge may help to structure
  the system hierarchically - this is sometimes used to effect
  "area routing."

3. As long as you stay within the confines of a single net,
   24 bits allows some 16 million destination identifiers
   which seem to me to be quite a few for a respectable amateur
   packet radio network. One might artificially use up several
   network numbers if it appeared that 16 million wasn't enough.
   The harder problem is to make these numbers useful for routing
   purposes and to do this, one obviously needs to bind the
   identifiers to some location.  Clearly you have attempted to
  do this with the lat/long strategy.

4. Quite frankly, we didn't envision this particular use when
   we designed IP - and your trick of using an option format
   to provide more detailed information is certainly the kind
  of extension we designed options for - even if it does strain
  your esthetic senses.

5. As to handling true internetting and providing for routing
  THROUGH gateways without losing track of the final net/destination,
   either the amateur packet radio network needs to define a lower
  level addressing structure, or you need to consider another option
  which identifies not only the source and destination but also
  the "next" gateway.  This is really just a form of source
  routing.

6. The hardest problem, really, is going to be handling the
  area routing and dissemination of routing information
  throughout the system. If connectivity changes frequently
  for physical reasons (propagation effects) or because repeaters
  go up and down whimsically, then managing the routing problem
  is going to be quite a challenge.

Vint Cerf

------------------------------

From:  Schauble.Multics at MIT-Multics
Subject:  Overloading the .

Tops-20 isn't the only system that has problems with that use of the
period. Multics does also. Notice, for instance, the sender of this
message.
			Paul

END OF TCP-IP DIGEST
********************

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 82 3:07:55-EST (Tue)
From:      Mike Muuss <tcp-ip@brl>
To:        list:
Subject:   TCP-IP Digest, Vol 1 #10
TCP/IP Digest             Tuesday, 5 Jan 1981      Volume 1 : Issue 10

Today's Topics:
                              Administrivia
                   ComputerWorld on the TCP/IP Cutover
                   Amateur Packet Radio using InterNet
                      Overloading the Poor Dot (.)
----------------------------------------------------------------------

From:      Mike Muuss <Mike@BRL>
Subject:   Administrivia

Folks -

	It looks like somebody on this list is feeding copies of the TCP/IP
Digest to ComputerWorld magazine, which seems delighted with this
newfound source of "inside" information.  While it is my intention that
this list receive as broad a distribution as possible, several
tightropes must be carefully traversed:

	Networking plays a vital part in the Mission of the Ballistic Research
Laboratory (BRL), which fully supports the distribution of the TCP/IP
Digest.  However, the ArpaNet is intended for U.S. Government business,
and is not supposed to compete with commercial packet networks.  This
has a rather limiting effect on the group of people who can freely use
the ArpaNet.

	More importantly, though, is a question of content.  If it becomes
known that contributions to the TCP/IP Digest will appear in ComputerWorld,
possibly verbatim, or perhaps cast in the wrong light, then I suspect that
there will be a marked decrease in the quantity of information that is offered.
Few of us expect our net mail to wind up published in the commercial press,
and only the brave will knowingly open themselves up to this kind of direct,
external exposure.  And the cost?  Those readers who desperately need the 
information on what is happening may find their information sources again
reduced to RFC's and official notices, carefully worded for public scrutiny.

	This digest was intended as an open forum?  Is a direct pipeline
to the outside world too open?  I solicit discussion on this matter.
Maybe we can reach a consensus?
					Happy New Year!
					  -Mike Muuss

------------------------------

From: chico!duke!unc!grumpy.smb at Berkeley
Subject: Computerworld on the TCP/IP cutover

Well, they're at it again.  Here are some excerpts from the December 14
issue:

	Arpanet, the Pentagon-sponsored packet network that supports U.S.
	computing research, is slated for Jan. 1, 1983 cutover to two
	protocols that some experts predict will revolutionize
	commercial data communications.

	Considered the world's first packet network, Arpanet is expected
	to become an internet -- a network of networks -- ... said an
	informed source, who revealed the cutover date.

It was secret?

	...  Arpanet was not built to support wartime communications
	among the military, but the planned cutover to TCP/IP -- roughly
	a year away -- suggests that computer scientists have a lot of
	confidence in the protocol pair.  An Arpanet crash would
	seriously disrupt American research and development in many
	fields of science and technology, one expert maintained.

	...  A number of TCP/IP developers seem to believe that Arpanet
	will be ready Jan. 1, 1983 cutover [sic] -- but not all of them,
	Arpanet correspondence revealed.

	Available to all Arpanet subscribers, electronic mail files on
	TCP/IP include the following dispatch by a Stanford University
	researcher:

	"Some people [believe] that TCP work on [Digital Equipment
	Corp.'s] Tops-20 [operating system] is 'done.'... I believe
	the 1983 deadline for TCP conversion will not be met.  I have
	worked on BBN's TCP at the user program level; specifically, I
	have implemented general user Telnet for TCP as part of a
	general multiple-network Telnet for Tops-20.

	"Briefly, the Tops-20 TCP implementation in its present form is
	unacceptable to Stanford and many othe Tops-20 sites.  It is sad
	that so many bright people at BBN have had to maintain this dog
	instead of working on a complete rewrite."

	This critic wrote, in his Arpanet communique, that "the TCP
	process consumes between 40% and 60% of the CPU.  We simply
	cannot sacrifice that much of an already-loaded CPU to implement
	a network ."

[ I suppose that the TCP Digest quoting ComputerWorld quoting the TCP Digest
  is only fair!  -Mike ]

------------------------------

From: John C. Gilmore <GNU at MIT-AI>
Subject:  Amateur Packet Radio using Internet
To: CERF at USC-ISI
cc: Tcp-ip at BRL

    From: CERF at USC-ISI

    Your TCP-IP digest entry caught my attention concerning
    addressing capability in the IP protocol. I'd like to know
    more about your "internet packet radio" since it isn't
    one of the projects ARPA is supporting. Is this something
    you are pursuing as a graduate or undergraduate effort
    or supported by another funding agency?

    Vint Cerf
    DARPA/IPTO

Amateur Packet Radio is an experimental networking implementation
among Amateur Radio Operators under the regulation of the FCC.  It
is a group of "hams" creating a network for digital communication
among citizens.  It is not supported by ARPA or any government agency
(although AMRAD hosted an "Amateur Radio Computer Networking
Conference" in conjunction with NBS in October).

We currently favor the Internet Protocols, with minimal modifications,
to encourage timely comprehension, software development, and
extramural connection.  Our network has two constraints that we hope
are not unique, which is why I sent my query to TCP-IP, hoping for
known solutions.  They are:

	There is no underlying software protocol; IP Datagrams are
	transmitted without enclosure at the lowest level. (This
	is not, so far, a problem, but we're wondering if anyone else
	is doing similarly.)  The medium is broadcast and there are 
	contention problems.

	There is no central authority; no user sign-up; no fixed
	connectivity or user location.  Each terminal node runs the
	same program with a small number of variables different (at
	least one unique).  Nodes can appear, disappear, and move at
	any time; connectivity depends on electromagnetic weather.
	We had trouble with 24-bit addresses in this environment,
	since we have no way to create unique addresses that short.

If the TCP-IP mailing list is for Official U. S. Government users
only, rather than for the clarification, distribution, evolution, and
improvement of the standard among all who are gaining experience with
it, then please excuse my assumption and have me removed from it.

[ Nope, you are in the right place.  -Mike ]

------------------------------

Subject: Re:  Amateur Packet Radio using Internet
From: CERF at USC-ISI
To: GNU at MIT-AI
Cc: Tcp-ip at BRL
In-Reply-To: Your message of 30 December 1981 05:51-EST

1. TCP-IP Digest is an open forum and your entry was perfectly
valid - just caught my attention since I didn't know about the
internet protocol choice by the Amatuer Packet Radio group. I did
know a little about the private Packet Radio work.

2. Use of raw IP formats could cause you some trouble. The current
  architectural assumptions are that a gateway can "direct" an
  IP THROUGH another gateway, but to do this, it uses a lower
  layer of addressing (encapsulation philosophy). This seemed
  quite natural to us during design of IP since all the nets we
  were concerned with or knew about had a lower layer format with
 local addressing - even Ethernets.

  In a single network architecture, populated with a blizzard
  of private packet radios, you are faced with a number of
  challenges. First, the generation of unique identifiers.
  Second, the use of these identifiers to aid in routing
  decisions.  I am not entirely convinced that a geographic
  basis is necessarily helpful - in the ARPA packet radio net,
  for example, the actual location of a radio is not always a
  good indicator of its radio connectivity into the system.
  Routing towards its geophysical location may in fact fail
  while routing "away" toward the high mountain peak which is
  in LOS may help.  

  In your case, some geographic knowledge may help to structure
  the system hierarchically - this is sometimes used to effect
  "area routing."

3. As long as you stay within the confines of a single net,
   24 bits allows some 16 million destination identifiers
   which seem to me to be quite a few for a respectable amateur
   packet radio network. One might artificially use up several
   network numbers if it appeared that 16 million wasn't enough.
   The harder problem is to make these numbers useful for routing
   purposes and to do this, one obviously needs to bind the
   identifiers to some location.  Clearly you have attempted to
  do this with the lat/long strategy.

4. Quite frankly, we didn't envision this particular use when
   we designed IP - and your trick of using an option format
   to provide more detailed information is certainly the kind
  of extension we designed options for - even if it does strain
  your esthetic senses.

5. As to handling true internetting and providing for routing
  THROUGH gateways without losing track of the final net/destination,
   either the amateur packet radio network needs to define a lower
  level addressing structure, or you need to consider another option
  which identifies not only the source and destination but also
  the "next" gateway.  This is really just a form of source
  routing.

6. The hardest problem, really, is going to be handling the
  area routing and dissemination of routing information
  throughout the system. If connectivity changes frequently
  for physical reasons (propagation effects) or because repeaters
  go up and down whimsically, then managing the routing problem
  is going to be quite a challenge.

Vint Cerf

------------------------------

From:  Schauble.Multics at MIT-Multics
Subject:  Overloading the .

Tops-20 isn't the only system that has problems with that use of the
period. Multics does also. Notice, for instance, the sender of this
message.
			Paul

END OF TCP-IP DIGEST
********************

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 82 17:52:48-EST (Mon)
From:      Mike Muuss <tcp-ip@brl>
To:        list:
Subject:   TCP-IP Digest, Vol 1 #11
TCP/IP Digest            Monday, 11 Jan 1981       Volume 1 : Issue 11

Today's Topics:
                   Administrivia && The Use of Dot (.)
                   Languages for Implementing TCP-IP?
                  Common Law Copyrights for the Digest?
    Formal Copyrights for the Digest? && TCP Digest as a Public Forum
                        COMSAT Information Update
----------------------------------------------------------------------

From: Mike Muuss <Mike@BRL>
Subject: Administrivia

Well, the source of the leak to ComputerWorld has been found, so that
we have some breathing space to mull over the implications (it was an
ArpaNet recipient, so USENET sites need not worry).  It is certainly
clear that anything that goes out in a Digest will reach a large audience,
not all of whom are involved with the ArpaNet (USENET, for example).  At
some time, material WILL fall into "outside" hands.  The question becomes
a choice between:

    1)  Being more careful, so that anything said is quotable, or
    2)  Publishing a "restricted rights" notice on the top of the digest
	as a deterent to re-publication.

Under no circumstances do I want to restrict the membership or distribution
of this Digest.  I hope that we can get over these political problems, and
get back to discussing technical issues once again.
					Thoughts?
					  -Mike

------------------------------

From: ROODE at SRI-KL (David Roode)
Subject: use of .

Why not use ! instead of . for routing in network addresses.
It seems a much wiser choice.

------------------------------

From: cak at PURDUE
Subject: Overloading .

Many other systems use . as a separator; PhoneNet for CSNET uses it
as in cak.purdue@udel, the Berkeley local network can use it, as in
csvax.cak, PUP uses it, as in clark.WBST@Parc-Maxc, ad nauseum....

Chris Kent

[ I believe that the CSNET usage of User.Host@Forwarder is the RFC733
  approved addressing format for sites which can't take User@Host@Forwarder.
  The choice of the dot does seem rather unfortunate.  The British have
  adopted RF733 for their mail standard, but selected the percentage symbol
  "%" rather than the dot ".".  -Mike ]

------------------------------

Subject: TCP-IP implementations
From: AVRUNIN at USC-ECLB

In implementing TCP-IP in various computer systems it would be helpful
to have an implementation to start with.  There seems to be severaly "C"
versions.  I would like to know what other languages have
been used for implementations.  I would especially like to know if anyone
has or is using Fortran 77 for implementation.

Thanks

Larry Avrunin

[ I believe that the Tektronix implementation for the CDC NOS system is
  written in RATFOR (Rational FORTRAN).  -Mike ]

------------------------------

From: Walt <Haas at UTAH-20>
Subject: Re:   TCP-IP Digest, Vol 1 #10
To: tcp-ip at BRL

Would claiming a common law copyright on this digest stop ComputerWorld
from printing quotes?

------------------------------

From: Geoffrey H. Cooper <GEOF at MIT-XX>
Subject: Re:   TCP-IP Digest, Vol 1 #10

    If there is really a concern about having TCP-IP entries published
on paper-based media, it would help some to put a copyright notice on
each digest:
	(C) Copyright 1982, DARPA, all rights reserved.  The material
	    in this digest may not be copied, in whole or in part, for
	    purposes of commercial publication without the written
	    permission of the moderator.  Individual sections of the digest
	    may contain copyright notices which supercede this notice.
This would at least make editors of computerworld and the like hesitate if
given the entire digest.
				- geof cooper

------------------------------

From: cbosgd!mark at Berkeley
To: ucbvax!tcp-ip@Berkeley
Subject: TCP digest as a public forum

I just want to make sure the people on this list are aware that each
TCP digest is fed into USENET on newsgroup fa.tcp-ip.  This is sent to
(currently) about 120 machines across the US and Canada.  (For those
who don't know about USENET, it's a distributed bulletin board system.)
USENET specifically has a policy that anything posted to net and fa
newsgroups is public information that can be redistributed to whoever
wants it.  The point is that if you have anything you consider secret,
it probably shouldn't be mailed to the list.

While I am under the impression that this policy is consistent with the
intent of the TCP-IP digest, if I'm wrong, it may be necessary to
remove the USENET feed from the mailing list.

It is possible that ComputerWorld got their information from USENET,
but from the wording of the article, they seem to have gotten it from
somewhere on the Arpanet.

It is easy to confuse private mail and public mailing lists/newsgroups,
and it seems clear that the quote from the digest was written in a
"I'm talking privately to friends" frame of mind.  Clearly he didn't
intend his words to be printed in ComputerWorld.  But it is important
to remember that anything which is mass-mailed is effectively published.

	Mark Horton

------------------------------

Return-path: Mills@COMSAT
Mail-from: [29.4.6.2] received at USC-ISIE  5-Jan-82 11:46:01
From: Mills at COMSAT
Subject: IP-TCP Digest info update
cc:   Mills at ISIE
Via:  Usc-Isie; 5 Jan 82 18:28-EDT

Mike,

Following is an extract of a recent report on the status of our
IP/TCP implementation which may be of interest to your readers.

The COMSAT IP/TCP implementation, which was sponsored by DARPA,
was developed over the last three years and used extensively for
testing, evaluation and experimentation with other
implementations. This implementation runs in a sizable number of
PDP11s and LSI-11s with varying configurations and applications.
It consists of a package of MACRO-11 modules structured into
levels corresponding to local-net, IP and TCP levels, with user
interfaces at each level. It is designed to be incorporated
either into a special operating system built for a multi-media
internet workstation (so-called "fuzzball," based on RT-11
emulation) or into the RSX-11 operating system as part of a
package to support the INTELPOST electronic-mail network.

The local-net level supports several comunication devices,
including synchronous and asynchronous serial lines, 16-bit
parallel links and 1822 interfaces. Hosts using this package have
been connected to ARPANET IMPs, Satellite IMPs, internet
gateways, port expanders and to the DCNET local network. It
provides optional automatic routing, time synchronization and
error-reporting functions. The IP level conforms to the RFC-791
specification, including fragmentation, reassembly, extended
addressing and options, but currently does not interpret options.
A full set of ICMP features compatible with RFC-792 is available,
including destination-unreachable, timestamp, redirect and
source-quench messages. Support for an IEN-142 compatible time
server and an IEN-109 (as amended) compatible internet gateway
can be included on an optional basis. The internet-gateway
support can be configured to include hierarchically structured
gateways and subnets. Destination-unreachable and source-quench
information is conveyed to the user level via the TCP and
raw-datagram protocol modules.

The TCP level conforms to the RFC-793 specification, including
PUSH, URGENT and options, but currently does not interpret
options. Its structure is based on circular buffers for
reassembly and retransmission, with repacketizing on each
retransmission. Retransmission timeouts are dynamically
determined using measured roundtrip delays, as adjusted for
backoff. Data flow into the network is controlled by measured
network bandwidth, as adjusted by source-quench information.
Features are included to avoid excessive packet fragmentation and
retransmission into zero windows. The user interface level
provides error and URGENT notification, as well as a means to set
outgoing IP/TCP options.

A raw-datagram interface is available for XNET (IEN-158), UDP
(RFC-768) and similar protocols. It includes internal congestion
and fairness controls, multiple-connection management and
timestamping. A number of user-level protocol modules have been
built and tested with other internet hosts, including user/server
TELNET (RFC-764) user/server FTP (RFC-765), user/server MTP
(RFC-780) and various utility file-transfer, debugging and
control/monitoring protocols.

Code sizes and speeds depend greatly on the system configuration
and features selected. A typical 30K-word LSI-11/2 single-user
configuration with all features selected and including the
operating system, device drivers and all buffers and control
blocks, leaves about 16K words for user-level application
programs and protocol modules. A typical 124K-word LSI-11/23
configuration provides the same service to a half-dozen
individually relocated users. Disk-to-disk FTP transfers across a
DMA interprocessor link between LSI-11/23s operate in the range
20-30 Kbps with 576-octet packets. The 124K-word PDP11/34
INTELPOST adaptation supports two 56-Kbps lines and a number of
lower-speed lines.

Further information is available from D. Mills (Mills@ISIE) on
the IP/TCP implementation and D. Jupin (Jupin@ISIE) on the RSX-11
adaptation.

Regards,
Dave Mills

END OF TCP-IP DIGEST
********************

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Tue Jan 12 20:11:06 1982
From:      ucbvax!tcp-ip
To:        fa.tcp-ip
Subject:   TCP-IP Digest, Vol 1 #11

>From tcp-ip@brl Tue Jan 12 17:57:58 1982
TCP/IP Digest            Monday, 11 Jan 1981       Volume 1 : Issue 11

Today's Topics:
                   Administrivia && The Use of Dot (.)
                   Languages for Implementing TCP-IP?
                  Common Law Copyrights for the Digest?
    Formal Copyrights for the Digest? && TCP Digest as a Public Forum
                        COMSAT Information Update
----------------------------------------------------------------------

From: Mike Muuss <Mike@BRL>
Subject: Administrivia

Well, the source of the leak to ComputerWorld has been found, so that
we have some breathing space to mull over the implications (it was an
ArpaNet recipient, so USENET sites need not worry).  It is certainly
clear that anything that goes out in a Digest will reach a large audience,
not all of whom are involved with the ArpaNet (USENET, for example).  At
some time, material WILL fall into "outside" hands.  The question becomes
a choice between:

    1)  Being more careful, so that anything said is quotable, or
    2)  Publishing a "restricted rights" notice on the top of the digest
	as a deterent to re-publication.

Under no circumstances do I want to restrict the membership or distribution
of this Digest.  I hope that we can get over these political problems, and
get back to discussing technical issues once again.
					Thoughts?
					  -Mike

------------------------------

From: ROODE at SRI-KL (David Roode)
Subject: use of .

Why not use ! instead of . for routing in network addresses.
It seems a much wiser choice.

------------------------------

From: cak at PURDUE
Subject: Overloading .

Many other systems use . as a separator; PhoneNet for CSNET uses it
as in cak.purdue@udel, the Berkeley local network can use it, as in
csvax.cak, PUP uses it, as in clark.WBST@Parc-Maxc, ad nauseum....

Chris Kent

[ I believe that the CSNET usage of User.Host@Forwarder is the RFC733
  approved addressing format for sites which can't take User@Host@Forwarder.
  The choice of the dot does seem rather unfortunate.  The British have
  adopted RF733 for their mail standard, but selected the percentage symbol
  "%" rather than the dot ".".  -Mike ]

------------------------------

Subject: TCP-IP implementations
From: AVRUNIN at USC-ECLB

In implementing TCP-IP in various computer systems it would be helpful
to have an implementation to start with.  There seems to be severaly "C"
versions.  I would like to know what other languages have
been used for implementations.  I would especially like to know if anyone
has or is using Fortran 77 for implementation.

Thanks

Larry Avrunin

[ I believe that the Tektronix implementation for the CDC NOS system is
  written in RATFOR (Rational FORTRAN).  -Mike ]

------------------------------

From: Walt <Haas at UTAH-20>
Subject: Re:   TCP-IP Digest, Vol 1 #10
To: tcp-ip at BRL

Would claiming a common law copyright on this digest stop ComputerWorld
from printing quotes?

------------------------------

From: Geoffrey H. Cooper <GEOF at MIT-XX>
Subject: Re:   TCP-IP Digest, Vol 1 #10

    If there is really a concern about having TCP-IP entries published
on paper-based media, it would help some to put a copyright notice on
each digest:
	(C) Copyright 1982, DARPA, all rights reserved.  The material
	    in this digest may not be copied, in whole or in part, for
	    purposes of commercial publication without the written
	    permission of the moderator.  Individual sections of the digest
	    may contain copyright notices which supercede this notice.
This would at least make editors of computerworld and the like hesitate if
given the entire digest.
				- geof cooper

------------------------------

From: cbosgd!mark at Berkeley
To: ucbvax!tcp-ip@Berkeley
Subject: TCP digest as a public forum

I just want to make sure the people on this list are aware that each
TCP digest is fed into USENET on newsgroup fa.tcp-ip.  This is sent to
(currently) about 120 machines across the US and Canada.  (For those
who don't know about USENET, it's a distributed bulletin board system.)
USENET specifically has a policy that anything posted to net and fa
newsgroups is public information that can be redistributed to whoever
wants it.  The point is that if you have anything you consider secret,
it probably shouldn't be mailed to the list.

While I am under the impression that this policy is consistent with the
intent of the TCP-IP digest, if I'm wrong, it may be necessary to
remove the USENET feed from the mailing list.

It is possible that ComputerWorld got their information from USENET,
but from the wording of the article, they seem to have gotten it from
somewhere on the Arpanet.

It is easy to confuse private mail and public mailing lists/newsgroups,
and it seems clear that the quote from the digest was written in a
"I'm talking privately to friends" frame of mind.  Clearly he didn't
intend his words to be printed in ComputerWorld.  But it is important
to remember that anything which is mass-mailed is effectively published.

	Mark Horton

------------------------------

Return-path: Mills@COMSAT
Mail-from: [29.4.6.2] received at USC-ISIE  5-Jan-82 11:46:01
From: Mills at COMSAT
Subject: IP-TCP Digest info update
cc:   Mills at ISIE
Via:  Usc-Isie; 5 Jan 82 18:28-EDT

Mike,

Following is an extract of a recent report on the status of our
IP/TCP implementation which may be of interest to your readers.

The COMSAT IP/TCP implementation, which was sponsored by DARPA,
was developed over the last three years and used extensively for
testing, evaluation and experimentation with other
implementations. This implementation runs in a sizable number of
PDP11s and LSI-11s with varying configurations and applications.
It consists of a package of MACRO-11 modules structured into
levels corresponding to local-net, IP and TCP levels, with user
interfaces at each level. It is designed to be incorporated
either into a special operating system built for a multi-media
internet workstation (so-called "fuzzball," based on RT-11
emulation) or into the RSX-11 operating system as part of a
package to support the INTELPOST electronic-mail network.

The local-net level supports several comunication devices,
including synchronous and asynchronous serial lines, 16-bit
parallel links and 1822 interfaces. Hosts using this package have
been connected to ARPANET IMPs, Satellite IMPs, internet
gateways, port expanders and to the DCNET local network. It
provides optional automatic routing, time synchronization and
error-reporting functions. The IP level conforms to the RFC-791
specification, including fragmentation, reassembly, extended
addressing and options, but currently does not interpret options.
A full set of ICMP features compatible with RFC-792 is available,
including destination-unreachable, timestamp, redirect and
source-quench messages. Support for an IEN-142 compatible time
server and an IEN-109 (as amended) compatible internet gateway
can be included on an optional basis. The internet-gateway
support can be configured to include hierarchically structured
gateways and subnets. Destination-unreachable and source-quench
information is conveyed to the user level via the TCP and
raw-datagram protocol modules.

The TCP level conforms to the RFC-793 specification, including
PUSH, URGENT and options, but currently does not interpret
options. Its structure is based on circular buffers for
reassembly and retransmission, with repacketizing on each
retransmission. Retransmission timeouts are dynamically
determined using measured roundtrip delays, as adjusted for
backoff. Data flow into the network is controlled by measured
network bandwidth, as adjusted by source-quench information.
Features are included to avoid excessive packet fragmentation and
retransmission into zero windows. The user interface level
provides error and URGENT notification, as well as a means to set
outgoing IP/TCP options.

A raw-datagram interface is available for XNET (IEN-158), UDP
(RFC-768) and similar protocols. It includes internal congestion
and fairness controls, multiple-connection management and
timestamping. A number of user-level protocol modules have been
built and tested with other internet hosts, including user/server
TELNET (RFC-764) user/server FTP (RFC-765), user/server MTP
(RFC-780) and various utility file-transfer, debugging and
control/monitoring protocols.

Code sizes and speeds depend greatly on the system configuration
and features selected. A typical 30K-word LSI-11/2 single-user
configuration with all features selected and including the
operating system, device drivers and all buffers and control
blocks, leaves about 16K words for user-level application
programs and protocol modules. A typical 124K-word LSI-11/23
configuration provides the same service to a half-dozen
individually relocated users. Disk-to-disk FTP transfers across a
DMA interprocessor link between LSI-11/23s operate in the range
20-30 Kbps with 576-octet packets. The 124K-word PDP11/34
INTELPOST adaptation supports two 56-Kbps lines and a number of
lower-speed lines.

Further information is available from D. Mills (Mills@ISIE) on
the IP/TCP implementation and D. Jupin (Jupin@ISIE) on the RSX-11
adaptation.

Regards,
Dave Mills

END OF TCP-IP DIGEST
********************

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 82 6:38:28-EST (Thu)
From:      Mike Muuss <tcp-ip@brl>
To:        list:
Subject:   TCP-IP Digest, Vol 1 #12
TCP/IP Digest           Thursday, 14 Jan 1982      Volume 1 : Issue 12

Today's Topics:
       Administrivia: Republication, Distribution, and Recipients
                        The Effect of Copyrights?
                Comments on the Article in ComputerWorld
                Comments on New Addition to the Masthead
                              TCP in RatFOR
            TCP/IP Installation Report from Purdue University
                          To TCP or Not To TCP?
              Continued Future for MIT ITS on the ArpaNet?
                UK Joint Network Team Mail Specification
                   "Standard" Network Mail Addressing?
                      Multiple Networks and RFC733
----------------------------------------------------------------------
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

From:      Mike Muuss <tcp-ip@brl>
Subject:   Administrivia

Folks -
	You probably noticed the new banner on the front of this issue
of the digest.  While a copyright would be even better, the Government
can not hold a copyright, and the mechanics of having somebody else
copyright the Digest were just too much.  So, the notice on the front.
The intention here is to warn readers of the digest that the material
contained herein is not for publication or other forms of public
distribution.  At least this will ensure that if copies get to
the outside world (and they undoubtably will), at least they will think
twice before printing it.  Authors of letters to the digest who want to
make a public statement may mark their submissions accordingly.
If this seems unnecessary, we can always be more informal later.

	In addition, I intend to try and filter submissions from
unexpected sources, such as the copy of the InterNet Monthly which
I published pieces of several issues back.  The intentions were all
good, but things didn't work out so well.  Politics.  Alas.

	In summary, then, I hope to wrap up discussion of the administrative
side of the digest in the next issue or two, and resume our devoted
discussion of Networking!

	I am interested in hearing from each USENET site which is
presently receiving the digest, to try and judge the size of the
readership.  (Also from any other "multi-level indirect" network
which may be distributing the digest).  Let's start hearing more
about networking concerns from the non-ArpaNet sites, too.

	It seems that there has been some trouble with Digests sent to
one site being truncated.  Each digest ends with "END OF TCP-IP DIGEST"
and a row of asterisks.  Please let me know of any transmission problems.

			A Happy New Year to All!!
				-Mike

				...!menlo70!hao!brl-bmd!tcp-ip
				...!duke!brl-bmd!tcp-ip
				TCP-IP@BRL

------------------------------

From: Bob Clements <CLEMENTS@BBNA>
Subject:   TCP-IP Digest, Vol 1 #11

No, a copyright would not stop a news journal from printing anything
they consider "news", and rightly so, per the first amendment.
The moral is that whoever put that large section of a private
working discussion onto this journal made a serious error, and that
includes both the editor and the person who gave it to him.

Hopefully, they have learned from the error and won't repeat it.
/Rcc

------------------------------

From:      Michael Muuss <mike@BMD70>
Subject:   Comments on ComputerWorld

Here is a comment from the person who released the Digest to
Brad Schultz of ComputerWorld.

------ Forwarded Message #1:

BTW, I talked with Brad Schultz today, and he is aware now of the
potential impacts of his "quoting" from what is actually an off
the record source.  He now regards it as such, and also he is not
getting any more information from the Digest, nor has he passed
on what his sources were.

He would be interested in conveying to the Digest participants
his concern over any inhibitions he may have initiated.  In our
discussion today, we decided that you should head each issue of
the Digest with a statement saying that it is an off the record
publication, as far as use by the press is concerned.  Perhaps we
should discuss with him exactly what the mast head disclaimer
should say so as to make very clear to anyone who sees it that it
is off the record and not to be used for quoting or direct
attribution by any member of the press.

----- End of forwarded messages

------------------------------

From: Christopher C. Stacy <CStacy at MIT-AI>
Subject: For Research Use Only --- Not for Public Distribution

The problem of ensuring that ARPAnet mail is not distributed outside
of the network community is a perpetual one, because many of the users
on the network are unaware of the restrictions on the material.

I beleive that the best solution is to educate the network community
to the problems which tend to arise when material is distributed
off the network.

There are several problems with people distributing material from the
network to the outside world.

There is always the threat of official or public accusations of misuse
of the network for certain mailing lists.  This actually happened with
a list called WINE-LOVERS and Datamation, which was just a hint of the
magnitude of SFL.  The fiasco nearly resulted in MIT being removed from
the network, and cost us several months of research time while we
fought legal battles to show why our machines should not be removed
from the ARPAnet.  Of course, with a mailing list such as TCP-IP that
particular sort of problem is very unlikely to occur. 

But there are still other problems.  One of the problems involves legal
liability for statements and opinions published on ARPAnet mailing
lists.  One of the classic scenarios of this sort of liability involves
the INFO-TERMS mailing list, which discusses and evaluates the
characteristics of various terminal devices.

Suppose someone were to state that Terminal Foo is better than Terminal
Bar, and that you should not bother with Terminal Bar.  Imagine now
that the message is republished or even casually redistributed outside
the ARPAnet.  The president of Bar Terminals Corporation sees the
message and writes to his Congressional representative for an
explanation as to why Government money from the taxpayer's pocket is
being used to induce people to buy his competitors product and not his.

Still further problems involve such issues as copyright and propriety.
The originator of a message to a mailing list does not expect that his
words will end up in Computerworld or elsewhere.

The Defense Communications Agency (DCA), which is responsible for
managing the ARPAnet has set down regulations and policies which are
designed to protect the network from some of these problems.  Naturally,
most people who use the ARPAnet are unaware of the reasons behind the
policies (or even that such policies exist!).  Here is a section from
a recent DCA memo on the subject:

       "Files should not be FTPed by anyone unless they are files
        that have been announced as ARPANET-public or unless
        permission has been obtained from the owner.  Public files
        on the ARPANET are not to be considered public files outside
        of the ARPANET, and should not be transferred, or their
        contents given or sold to the general public without
        permission of DCA or the ARPANET sponsors.  Hosts which use
        a "guest" or "anonymous" FTP login convention should inform
        their local users about the ramifications of this convention
        with respect to unprotected files, as the users are not
        always aware that their files can be FTPed."

But "laying down the law" is a fairly useless way of solving this sort
of problem.  The problem is one of awareness, cooperation and trust.
Only if people understand and care, will they take steps to protect a
fragile institution like the ARPAnet.

For the most part, the problem is that people are simply unsure about
releasing the material.  Frequently a subscriber will ask before trying
to redistribute material, sometimes they only come forward after it is
too late.  The only thing which a moderator can do is explain to people
individually, in the detail required by the particular situation, why
republishing the material is a bad idea.

I think that the explicit banner on the masthead of the Digest is a bad
idea, because this will cause many people to think that if such a banner
is NOT present (ie., on any other Digests or on future TCP Digests)
that it is alright to redistribute the material.

In short, we are all in the hands of our neighbors.  The best thing to
do is to ensure that we are all educated as to how to take care of each
other and ourselves.

Cheers,
Chris

------------------------------

From: Jeffrey P. Golden <JPG at MIT-MC>
Subject: For Research Use Only etc.

   Date: 14 January 1982 00:48-EST
   From: Christopher C. Stacy <CStacy at MIT-AI>
   Subject: For Research Use Only --- Not for Public Distribution
   To: Tcp-IP at BRL, Mike at BRL
   cc: DIGEST-PEOPLE at MIT-AI
   ...
   I think that the explicit banner on the masthead of the Digest is a bad
   idea, because this will cause many people to think that if such a banner
   is NOT present (ie., on any other Digests or on future TCP Digests)
   that it is alright to redistribute the material.

I don't agree.  If SOMEONE uses the banner, then at least those people 
who see it may stop and think about the issue, and other digests may 
choose to use such a banner as well.  If NO ONE uses it, then I think we 
are more likely to perpetuate the kinds of problems CStacy mentioned 
earlier in his note.  I think elucidating by example is a fine thing, 
and one usually doesn't wait for others to be consistent with one's 
good idea.

------------------------------

From: Bob Amsler <AMSLER at SRI-AI>

That's acceptable to me, [The new addition to the Digest Masthead,
starting this issue -Mike] though it might be toned down a little after
a while. Another approach might be to just include a copyright notice...
though that smacks of assuming official standing. (By "toned down" I
mean explicitly the double row of -----'s might be eliminated or
reduced in size). 

------------------------------

From: mo at LBL-UNIX (Mike O'Dell [system])
Subject: TCP in Ratfor

Tek Labs has done a TCP for the Cybers which is done in Ratfor.
If Clem Cole doesn't chime in with details, I can probably find
them.
	-Mike

------------------------------

From: cak at PURDUE

Just a quick note to let you all know that the department of
Computer Science at Purdue University has brought Rob Gurwitz's
VAX TCP/IP implementation up on our Research VAX, as a beta-test effort.
(This is the VAX implementation from BBN. The work was done
as part of the CSNET effort here at Purdue.)
We are apparently the first site to come up straight off the tape.
There were some problems, both hardware and software, but Rob was
very helpful in solving these. 
The implementation looks very clean, the distribution was very good,
and we are in general satisfied.

Rob mentioned the measurements he made on our system a couple of
issues ago, but I'll repeat them here:
	Loopback through the IMP: 120Kbps
	Transmission to BBN-VAX: 9.2Kbps
Please note that these are data rates only; add about 5% in each
direction for headers.
The first number measures DMA to and from the IMP; there is no
involvement with the net. 
The second number should be considered with the fact that our 
net links are 9.6Kbps lines.
We see about an order of magnitude increase in throughput over our
Greep 11/34 NCP front-end. (Not really surprising, though, since
it talks to the VAX via a 9600 baud line.) These numbers were
obtained on a 11/780.

We plan to bring up ProNet and Ethernet under this software in the
future for our own local use, as well as to continue to beta-test
future releases of the software.
Please direct inquiries about availability to Rob as gurwitz@bbn-unix;
I can't give it out.

You may not have Purdue in your host tables yet....we are host 0 on
imp 37 (decimal).

Looking forward to 56Kbps lines,
Chris

------------------------------

[ The following letter I wrote in response to a letter that I got
  suggesting that SMTP will be too far away to help sites that transmit
  to large mailing lists, and that the TCP/IP may never happen anyway.
  -Mike ]

From:      Michael Muuss <mike@BRL>
Subject:   To TCP or not to TCP?

	After having just about gotten over the 3-month mad dash to
switch to long leader LAST winter, I am not really looking forwards
to rushing into the conversion to TCP/IP, because of the work involved.
However, all up and down the line within the ranks of DoD management
inside both the Army and the Navy, everybody is backing up the decision
to stand firm with 1-Jan-83 for the conversion.  This is putting the
heat on those of us who actually try to make these things happen, and
the pressure is uncomfortable, but we will probably be able to make it.

	This type of edict is not uncommon when working for the DoD;
some manager will stipulate that something will happen "absolutely" by
a certain date.  All the technical people start worrying, and screaming,
and carying on, claiming that "it can't be done in time".  Management
usually dumps some enormous amount of money onto the project, and
wait and see.  By this time, all the tech people have lost about
20 lbs (all brown), and are running around going crazy.  Management
usually gets what it wants.  Of course, there are the occasional
projects where things got cut just a bit too tight, and eveything falls
down in flames....

	I happen to feel that TCP and IP are *good* protocols, and
certainly much better than what we are using now.  It seems something
of a miracle that they have been adopted as a standard;  usually
standards are things like COBOL that people go out of their way to
avoid.  It is merely unfortunate that the conversion timetable is
so optimistic.

	There exists AT LEAST one choice of software for UNIX systems
(all machines), T(w)enexes, Multics, and IBMs, so the majority of the
"ordinary" systems will at least be able to talk, even if not convieniently.
How we will get to MACSYMA on MIT-MC remains a mystery, unless some
briliant MIT student with a lot of time on his hands decides to power-code
a TCP/IP implementation for the ITS machines....
							-Mike

------------------------------

From: Christopher C. Stacy <CStacy at MIT-AI>
Subject: To TCP or not to TCP?

    -----
    How we will get to MACSYMA on MIT-MC remains a mystery, 
    unless some briliant MIT student with a lot of time on
    his hands decides to power-code a TCP/IP implementation 
    for the ITS machines....
    -----

It is pretty clear that all the ITS machines will go off the ARPAnet
when TCP/IP is implemented, as we are not interested in investing any
time in developing new network software for those machines.

------------------------------

From: lauren at UCLA-Security (Lauren Weinstein)
Subject: To TCP or not to TCP?

Is there some good reason that the ITS machines cannot be 
gatewayed through a supported machine?  Even little 11's like
the 24 should be able to run some sort of existing TCP/IP
implementation.  Rand-Unix currently talks to the ARPANET over
a 9600 baud tty line via an 11/34 running the NCP.

--Lauren--

------------------------------

[ The remainder of this digest is devoted to a discussion of mail and
  mail addressing in a multiple network / InterNet environment.  Because
  I mentioned that the British were adopting RFC733, it seems
  appropriate to pass along this anouncement.  -Mike ]

Date:  6 Jan 1982 1307-PST
From: UKSAT at USC-ISIE
Subject: JNT Mail Protocol spec available

A document describing the mail protocol which has been adopted as an
interim standard by the UK Joint Network Team (JNT) is online at ISIE.
   <ucl-netwiz>usjnt.txt

This file may be copied using FTP with login to anonymous with password guest.

Steve Kille and Bob Braden

------------------------------

From: decvax!watmath!bstempleton at Berkeley
Subject: standard net address

Excuse me if I enter a little late in the discussion, but I only heard
of these plans of late.

It seems to me that userid@site.forwarder is much more sensible than
userid.site@forwarder.  (this is a simple change that had better not
take more than 1 minute to implement in any already written code - or
else the code was badly done)

at sign is found rarely in userids, and almost never on the arpanet, if
at all.  Dot is found commonly.  It seems to make sense to say, you want
to join our net, here is a format for your site name, instead of "here
is a format for your userid names"

Aside from all that userid@location is much more readable than userid.location
if you ask me.  Here, our plan is not to have explicit site names given
for waterloo computers, but rather have a mail-server figure out who
is where.

Where can I get details on the syntax of the internet mail systems?

------------------------------

From: Robert W. Kerns <RWK at MIT-MC>
Subject: RFC733 mistatement

   [ I believe that the CSNET usage of User.Host@Forwarder is the RFC733
     approved addressing format for sites which can't take User@Host@Forwarder.
     The choice of the dot does seem rather unfortunate.  The British have
     adopted RF733 for their mail standard, but selected the percentage symbol
     "%" rather than the dot ".".  -Mike ]

RFC733 does not endorse this interpretation at all.  USER.HOST@FORWARDER
(or USER.HOST@FORWARDER as used by Berkeley) is a legal RFC733 recipient
by virtue of the fact that "USER.HOST" is a legal RFC733 personid ("."
is not a special character at all) and FORWARDER is the host to send it
to.  I know of no standard (other than local to one forwarder or
network) which officially adopts this syntax.  I am not sure, but I
believe that the addresses of the form CSVAX.drb@BERKELY are simply
TOPS-20 login directory names which happen to have their mail forwarded
to CSVAX.  [ Berkeley runs UNIX;  syntax is LocHost.User@Berkeley  -Mike]

On the other hand, see the description of host-indicator in RFC733 for
the FOO@BAR-HOST@BAZ-HOST syntax.  If mailers stripping off the hostname
do their search from right-to-left and treat the rest as the string to
be passed to the FTP server, this syntax is trivially supported and
uniformly extensible.

Being new to this group, I don't know why this was brought up here, but
I hope you're not duplicating discussions which belong in MSGGROUP or
HEADER-PEOPLE.

[ I am asking around for pointers to earlier discussions about message
  addressing, and will report the results here.  -Mike ]

END OF TCP-IP DIGEST
********************

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Thu Jan 14 16:20:33 1982
From:      ucbvax!tcp-ip
To:        fa.tcp-ip
Subject:   TCP-IP Digest, Vol 1 #12

>From tcp-ip@brl Thu Jan 14 09:47:22 1982
TCP/IP Digest           Thursday, 14 Jan 1982      Volume 1 : Issue 12

Today's Topics:
       Administrivia: Republication, Distribution, and Recipients
                        The Effect of Copyrights?
                Comments on the Article in ComputerWorld
                Comments on New Addition to the Masthead
                              TCP in RatFOR
            TCP/IP Installation Report from Purdue University
                          To TCP or Not To TCP?
              Continued Future for MIT ITS on the ArpaNet?
                UK Joint Network Team Mail Specification
                   "Standard" Network Mail Addressing?
                      Multiple Networks and RFC733
----------------------------------------------------------------------
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

From:      Mike Muuss <tcp-ip@brl>
Subject:   Administrivia

Folks -
	You probably noticed the new banner on the front of this issue
of the digest.  While a copyright would be even better, the Government
can not hold a copyright, and the mechanics of having somebody else
copyright the Digest were just too much.  So, the notice on the front.
The intention here is to warn readers of the digest that the material
contained herein is not for publication or other forms of public
distribution.  At least this will ensure that if copies get to
the outside world (and they undoubtably will), at least they will think
twice before printing it.  Authors of letters to the digest who want to
make a public statement may mark their submissions accordingly.
If this seems unnecessary, we can always be more informal later.

	In addition, I intend to try and filter submissions from
unexpected sources, such as the copy of the InterNet Monthly which
I published pieces of several issues back.  The intentions were all
good, but things didn't work out so well.  Politics.  Alas.

	In summary, then, I hope to wrap up discussion of the administrative
side of the digest in the next issue or two, and resume our devoted
discussion of Networking!

	I am interested in hearing from each USENET site which is
presently receiving the digest, to try and judge the size of the
readership.  (Also from any other "multi-level indirect" network
which may be distributing the digest).  Let's start hearing more
about networking concerns from the non-ArpaNet sites, too.

	It seems that there has been some trouble with Digests sent to
one site being truncated.  Each digest ends with "END OF TCP-IP DIGEST"
and a row of asterisks.  Please let me know of any transmission problems.

			A Happy New Year to All!!
				-Mike

				...!menlo70!hao!brl-bmd!tcp-ip
				...!duke!brl-bmd!tcp-ip
				TCP-IP@BRL

------------------------------

From: Bob Clements <CLEMENTS@BBNA>
Subject:   TCP-IP Digest, Vol 1 #11

No, a copyright would not stop a news journal from printing anything
they consider "news", and rightly so, per the first amendment.
The moral is that whoever put that large section of a private
working discussion onto this journal made a serious error, and that
includes both the editor and the person who gave it to him.

Hopefully, they have learned from the error and won't repeat it.
/Rcc

------------------------------

From:      Michael Muuss <mike@BMD70>
Subject:   Comments on ComputerWorld

Here is a comment from the person who released the Digest to
Brad Schultz of ComputerWorld.

------ Forwarded Message #1:

BTW, I talked with Brad Schultz today, and he is aware now of the
potential impacts of his "quoting" from what is actually an off
the record source.  He now regards it as such, and also he is not
getting any more information from the Digest, nor has he passed
on what his sources were.

He would be interested in conveying to the Digest participants
his concern over any inhibitions he may have initiated.  In our
discussion today, we decided that you should head each issue of
the Digest with a statement saying that it is an off the record
publication, as far as use by the press is concerned.  Perhaps we
should discuss with him exactly what the mast head disclaimer
should say so as to make very clear to anyone who sees it that it
is off the record and not to be used for quoting or direct
attribution by any member of the press.

----- End of forwarded messages

------------------------------

From: Christopher C. Stacy <CStacy at MIT-AI>
Subject: For Research Use Only --- Not for Public Distribution

The problem of ensuring that ARPAnet mail is not distributed outside
of the network community is a perpetual one, because many of the users
on the network are unaware of the restrictions on the material.

I beleive that the best solution is to educate the network community
to the problems which tend to arise when material is distributed
off the network.

There are several problems with people distributing material from the
network to the outside world.

There is always the threat of official or public accusations of misuse
of the network for certain mailing lists.  This actually happened with
a list called WINE-LOVERS and Datamation, which was just a hint of the
magnitude of SFL.  The fiasco nearly resulted in MIT being removed from
the network, and cost us several months of research time while we
fought legal battles to show why our machines should not be removed
from the ARPAnet.  Of course, with a mailing list such as TCP-IP that
particular sort of problem is very unlikely to occur. 

But there are still other problems.  One of the problems involves legal
liability for statements and opinions published on ARPAnet mailing
lists.  One of the classic scenarios of this sort of liability involves
the INFO-TERMS mailing list, which discusses and evaluates the
characteristics of various terminal devices.

Suppose someone were to state that Terminal Foo is better than Terminal
Bar, and that you should not bother with Terminal Bar.  Imagine now
that the message is republished or even casually redistributed outside
the ARPAnet.  The president of Bar Terminals Corporation sees the
message and writes to his Congressional representative for an
explanation as to why Government money from the taxpayer's pocket is
being used to induce people to buy his competitors product and not his.

Still further problems involve such issues as copyright and propriety.
The originator of a message to a mailing list does not expect that his
words will end up in Computerworld or elsewhere.

The Defense Communications Agency (DCA), which is responsible for
managing the ARPAnet has set down regulations and policies which are
designed to protect the network from some of these problems.  Naturally,
most people who use the ARPAnet are unaware of the reasons behind the
policies (or even that such policies exist!).  Here is a section from
a recent DCA memo on the subject:

       "Files should not be FTPed by anyone unless they are files
        that have been announced as ARPANET-public or unless
        permission has been obtained from the owner.  Public files
        on the ARPANET are not to be considered public files outside
        of the ARPANET, and should not be transferred, or their
        contents given or sold to the general public without
        permission of DCA or the ARPANET sponsors.  Hosts which use
        a "guest" or "anonymous" FTP login convention should inform
        their local users about the ramifications of this convention
        with respect to unprotected files, as the users are not
        always aware that their files can be FTPed."

But "laying down the law" is a fairly useless way of solving this sort
of problem.  The problem is one of awareness, cooperation and trust.
Only if people understand and care, will they take steps to protect a
fragile institution like the ARPAnet.

For the most part, the problem is that people are simply unsure about
releasing the material.  Frequently a subscriber will ask before trying
to redistribute material, sometimes they only come forward after it is
too late.  The only thing which a moderator can do is explain to people
individually, in the detail required by the particular situation, why
republishing the material is a bad idea.

I think that the explicit banner on the masthead of the Digest is a bad
idea, because this will cause many people to think that if such a banner
is NOT present (ie., on any other Digests or on future TCP Digests)
that it is alright to redistribute the material.

In short, we are all in the hands of our neighbors.  The best thing to
do is to ensure that we are all educated as to how to take care of each
other and ourselves.

Cheers,
Chris

------------------------------

From: Jeffrey P. Golden <JPG at MIT-MC>
Subject: For Research Use Only etc.

   Date: 14 January 1982 00:48-EST
   From: Christopher C. Stacy <CStacy at MIT-AI>
   Subject: For Research Use Only --- Not for Public Distribution
   To: Tcp-IP at BRL, Mike at BRL
   cc: DIGEST-PEOPLE at MIT-AI
   ...
   I think that the explicit banner on the masthead of the Digest is a bad
   idea, because this will cause many people to think that if such a banner
   is NOT present (ie., on any other Digests or on future TCP Digests)
   that it is alright to redistribute the material.

I don't agree.  If SOMEONE uses the banner, then at least those people 
who see it may stop and think about the issue, and other digests may 
choose to use such a banner as well.  If NO ONE uses it, then I think we 
are more likely to perpetuate the kinds of problems CStacy mentioned 
earlier in his note.  I think elucidating by example is a fine thing, 
and one usually doesn't wait for others to be consistent with one's 
good idea.

------------------------------

From: Bob Amsler <AMSLER at SRI-AI>

That's acceptable to me, [The new addition to the Digest Masthead,
starting this issue -Mike] though it might be toned down a little after
a while. Another approach might be to just include a copyright notice...
though that smacks of assuming official standing. (By "toned down" I
mean explicitly the double row of -----'s might be eliminated or
reduced in size). 

------------------------------

From: mo at LBL-UNIX (Mike O'Dell [system])
Subject: TCP in Ratfor

Tek Labs has done a TCP for the Cybers which is done in Ratfor.
If Clem Cole doesn't chime in with details, I can probably find
them.
	-Mike

------------------------------

From: cak at PURDUE

Just a quick note to let you all know that the department of
Computer Science at Purdue University has brought Rob Gurwitz's
VAX TCP/IP implementation up on our Research VAX, as a beta-test effort.
(This is the VAX implementation from BBN. The work was done
as part of the CSNET effort here at Purdue.)
We are apparently the first site to come up straight off the tape.
There were some problems, both hardware and software, but Rob was
very helpful in solving these. 
The implementation looks very clean, the distribution was very good,
and we are in general satisfied.

Rob mentioned the measurements he made on our system a couple of
issues ago, but I'll repeat them here:
	Loopback through the IMP: 120Kbps
	Transmission to BBN-VAX: 9.2Kbps
Please note that these are data rates only; add about 5% in each
direction for headers.
The first number measures DMA to and from the IMP; there is no
involvement with the net. 
The second number should be considered with the fact that our 
net links are 9.6Kbps lines.
We see about an order of magnitude increase in throughput over our
Greep 11/34 NCP front-end. (Not really surprising, though, since
it talks to the VAX via a 9600 baud line.) These numbers were
obtained on a 11/780.

We plan to bring up ProNet and Ethernet under this software in the
future for our own local use, as well as to continue to beta-test
future releases of the software.
Please direct inquiries about availability to Rob as gurwitz@bbn-unix;
I can't give it out.

You may not have Purdue in your host tables yet....we are host 0 on
imp 37 (decimal).

Looking forward to 56Kbps lines,
Chris

------------------------------

[ The following letter I wrote in response to a letter that I got
  suggesting that SMTP will be too far away to help sites that transmit
  to large mailing lists, and that the TCP/IP may never happen anyway.
  -Mike ]

From:      Michael Muuss <mike@BRL>
Subject:   To TCP or not to TCP?

	After having just about gotten over the 3-month mad dash to
switch to long leader LAST winter, I am not really looking forwards
to rushing into the conversion to TCP/IP, because of the work involved.
However, all up and down the line within the ranks of DoD management
inside both the Army and the Navy, everybody is backing up the decision
to stand firm with 1-Jan-83 for the conversion.  This is putting the
heat on those of us who actually try to make these things happen, and
the pressure is uncomfortable, but we will probably be able to make it.

	This type of edict is not uncommon when working for the DoD;
some manager will stipulate that something will happen "absolutely" by
a certain date.  All the technical people start worrying, and screaming,
and carying on, claiming that "it can't be done in time".  Management
usually dumps some enormous amount of money onto the project, and
wait and see.  By this time, all the tech people have lost about
20 lbs (all brown), and are running around going crazy.  Management
usually gets what it wants.  Of course, there are the occasional
projects where things got cut just a bit too tight, and eveything falls
down in flames....

	I happen to feel that TCP and IP are *good* protocols, and
certainly much better than what we are using now.  It seems something
of a miracle that they have been adopted as a standard;  usually
standards are things like COBOL that people go out of their way to
avoid.  It is merely unfortunate that the conversion timetable is
so optimistic.

	There exists AT LEAST one choice of software for UNIX systems
(all machines), T(w)enexes, Multics, and IBMs, so the majority of the
"ordinary" systems will at least be able to talk, even if not convieniently.
How we will get to MACSYMA on MIT-MC remains a mystery, unless some
briliant MIT student with a lot of time on his hands decides to power-code
a TCP/IP implementation for the ITS machines....
							-Mike

------------------------------

From: Christopher C. Stacy <CStacy at MIT-AI>
Subject: To TCP or not to TCP?

    -----
    How we will get to MACSYMA on MIT-MC remains a mystery, 
    unless some briliant MIT student with a lot of time on
    his hands decides to power-code a TCP/IP implementation 
    for the ITS machines....
    -----

It is pretty clear that all the ITS machines will go off the ARPAnet
when TCP/IP is implemented, as we are not interested in investing any
time in developing new network software for those machines.

------------------------------

From: lauren at UCLA-Security (Lauren Weinstein)
Subject: To TCP or not to TCP?

Is there some good reason that the ITS machines cannot be 
gatewayed through a supported machine?  Even little 11's like
the 24 should be able to run some sort of existing TCP/IP
implementation.  Rand-Unix currently talks to the ARPANET over
a 9600 baud tty line via an 11/34 running the NCP.

--Lauren--

------------------------------

[ The remainder of this digest is devoted to a discussion of mail and
  mail addressing in a multiple network / InterNet environment.  Because
  I mentioned that the British were adopting RFC733, it seems
  appropriate to pass along this anouncement.  -Mike ]

Date:  6 Jan 1982 1307-PST
From: UKSAT at USC-ISIE
Subject: JNT Mail Protocol spec available

A document describing the mail protocol which has been adopted as an
interim standard by the UK Joint Network Team (JNT) is online at ISIE.
   <ucl-netwiz>usjnt.txt

This file may be copied using FTP with login to anonymous with password guest.

Steve Kille and Bob Braden

------------------------------

From: decvax!watmath!bstempleton at Berkeley
Subject: standard net address

Excuse me if I enter a little late in the discussion, but I only heard
of these plans of late.

It seems to me that userid@site.forwarder is much more sensible than
userid.site@forwarder.  (this is a simple change that had better not
take more than 1 minute to implement in any already written code - or
else the code was badly done)

at sign is found rarely in userids, and almost never on the arpanet, if
at all.  Dot is found commonly.  It seems to make sense to say, you want
to join our net, here is a format for your site name, instead of "here
is a format for your userid names"

Aside from all that userid@location is much more readable than userid.location
if you ask me.  Here, our plan is not to have explicit site names given
for waterloo computers, but rather have a mail-server figure out who
is where.

Where can I get details on the syntax of the internet mail systems?

------------------------------

From: Robert W. Kerns <RWK at MIT-MC>
Subject: RFC733 mistatement

   [ I believe that the CSNET usage of User.Host@Forwarder is the RFC733
     approved addressing format for sites which can't take User@Host@Forwarder.
     The choice of the dot does seem rather unfortunate.  The British have
     adopted RF733 for their mail standard, but selected the percentage symbol
     "%" rather than the dot ".".  -Mike ]

RFC733 does not endorse this interpretation at all.  USER.HOST@FORWARDER
(or USER.HOST@FORWARDER as used by Berkeley) is a legal RFC733 recipient
by virtue of the fact that "USER.HOST" is a legal RFC733 personid ("."
is not a special character at all) and FORWARDER is the host to send it
to.  I know of no standard (other than local to one forwarder or
network) which officially adopts this syntax.  I am not sure, but I
believe that the addresses of the form CSVAX.drb@BERKELY are simply
TOPS-20 login directory names which happen to have their mail forwarded
to CSVAX.  [ Berkeley runs UNIX;  syntax is LocHost.User@Berkeley  -Mike]

On the other hand, see the description of host-indicator in RFC733 for
the FOO@BAR-HOST@BAZ-HOST syntax.  If mailers stripping off the hostname
do their search from right-to-left and treat the rest as the string to
be passed to the FTP server, this syntax is trivially supported and
uniformly extensible.

Being new to this group, I don't know why this was brought up here, but
I hope you're not duplicating discussions which belong in MSGGROUP or
HEADER-PEOPLE.

[ I am asking around for pointers to earlier discussions about message
  addressing, and will report the results here.  -Mike ]

END OF TCP-IP DIGEST
********************

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 1982
From:      TCP-IP at BRL
To:        TCP-IP at BRL
Subject:   TCP-IP Digest, Vol 1 #13
TCP/IP Digest             Monday, 18 Jan 1982      Volume 1 : Issue 13

Today's Topics:
                           New Digest Headers
                     Public Distribution of Digests
          Restricted Distribution of Mailing Lists/Digests/Etc?
            What is PUBLIC and What is PRIVATE Distribution?
                Precedent for Privacy of Electronic Mail
                  Related Discussion Group Information
                          To TCP or not to TCP?
                InterNet Addresses && Overloading the Dot
                            TCP/IP on a Cyber
----------------------------------------------------------------------
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

From:    Mike at BRL
Subject: New Digest Headers

This digest marks the first issue with the new headers people have been
asking for.  If this is not completely delightful to everybody, please
let me know.
					Cheers,
					 -Mike
------------------------------

From: Mike Peeler <Admin.MDP at SU-SCORE>
Subject: Public Distribution

    One way we could tell people that digest material is not public
would be first to announce the fact as an administrative note in the
digest and then to mention it whenever introducing a new member to the
list (by sending them a "welcome" note).  This approach is much less
distasteful than that of putting a warning on the label.

    The problem with it is that not all subscribers are added by one
list maintainer.  In fact, many of them get the digests by mechanisms
essentially equivalent to a bulletin board.  This means that a large
fraction of our new readers will never get a welcome note.

    If we regard the above as ineffective, then we want to make the
warning as unobtrusive as possible.  Two possibilities present them-
selves.  The first possibility would be to tuck it away in the header
instead of the banner; for example

        Date: Friday, 15 January 1982
        From: PCP-IV at BAL
        Private: Not for public distribution
        Subject: PCP-IV Digest  V9 #23
        To: PCP-IV at BAL

The second possibility would be to place the warning at the bottom of
the digest instead of the top; it might look like

        ------------------------------

        **************   End of PCP-IV Digest   **************
        *********   (Not For Public Distribution)   **********
        ******************************************************

or perhaps something less ostentatious to the same effect.

    The latter, like the warning in the banner, will break some
undigestifying programs, but probably in a milder and more easily
reparable way.  The former will not break most software, but may not
be as aesthetically acceptable.

                                    Yours very sincerely,

                                                      Mike

------------------------------

From: Paul A. Karger <KARGER at DEC-MARLBORO>
Subject: restricted distribution of mailing lists/digests/etc

While putting a restricted distribution statement on a digest may be a
psychological limitation on distribution, there a couple of problems.  First,
since ARPA and DCA are part of the DoD, there are specific regulations
on what may or may not be marked as FOR OFFICIAL USE ONLY.  The regulations
are in part designed to not let people invent other kinds of markings.
This dates back to the Ellsberg case and the desire to limit the ability
of govt people to conceal information from the "public" (whoever that is)

What happens if someone submits a Freedom of information Act request
for Volume 2, Issue 6 of TCP-IP Digest?  Worse still, what if someone
submits a FOIA request for SFL??

My familliarity with the applicable regs is a little stale, because I left
the Air Force over 2 years ago, but I would be very careful about developing
new ways to restrict distribution of government information.  

Paul Karger

------------------------------

From: V. Ellen Golden <ELLEN at MIT-MC>
Subject: [Paul A. Karger:  restricted distribution of mailing lists/digests]

THE ELLSBERG CASE?  Gosh... I am ancient.
Daniel Ellsberg made copies of the Pentagon Papers, which were
secret discussions about the Vietnam War.  He worked for a Harvard/MIT
institute for Government (Political Science) sort of thing.  He thought
"the people" should know what was going on, and so made copies of the
reports.  The CIA etc was not enthusiased.  The group who were involved
in stopping him were the same group which became familiar later:
The Plumbers (they invaded his psychiatrist's office, in California, yet).
The Pentagon Papers were published in the New York Times.  I admit I am
not sure if this was the event which triggered the Plumbers (of later
Watergate fame) to go to the psychiatrist's office, or if after all was
said and done, the stuff finally made it to the public eye. (Other ancients
like myself may recall better than I, and I beg them to correct my somewhat
sketchy remembrance of the events.)

anyway... in some way the Ellsberg case does have a bearing here in
the Digest-people discussion.  Do "the people" have a right to "know"
(what?).  I would say myself that what is in digests is not classified
in any sense of the word, but I have no idea how that relates to our
(ARPANET) status.

------------------------------

Subject: What is Public and what is Private distribution?
From: TMPL at BBNG

How my name got on the Digest list is a longish story, so I won't
go into it, except to say that it had to  do  with  my  exploring
some form of internetworking as a better way of accessing the net
than I do currently (corporate phone lines to Boston or Telenet).
My  main  use  of  the  net  is  as part of the computer security
community and is fully and properly justified by the right set of
letters from the Pentagon to BBN, DCA, etc.  ANYWAY, I have found
the Digest most interesting and have been circulating it  to  our
communications and systems research people, chiefly because it is
quite clear that at some point our products will have to  support
TCP  etc.   for our government customers at least.  I view such a
redistribution as an acceptable  way  of  communicating  research
results  to  those  who  can and ought to use them.  It certainly
isn't a public distribution in the sense of the mass media, but I
would like to be reassured that it is an acceptably private one.
	
Ted Lee
Manager, Systems Security
Sperry Univac
Roseville, Mn.

------------------------------

From:      Mike Muuss <tcp-ip@brl>
Subject:   Re:  What is Public and what is Private distribution?

Ted -

	I am pleased that a major manufacturer like Sperry Univac is
looking at the TCP/IP protocols (and the Digest).  It is groups just
like yours that everyone expects the Digests to go to.  Frequently,
the Digest will contain status reports about on-going
projects, or discussions of evolving featues/bugs/whatever.  This
type of "working notes" material can often be confusing or misleading
to the casual onlooker, and hence the concern that information which
is going to the general public be obtained through official channels
(Jon Postel or Vint Cerf, DCA/DARPA/ISI).

	Please do not re-publish materials or statements from the Digest,
but please DO feel free to distribute it to any interested people within
your organization.
					Sleepily,
					 -Mike

------------------------------

Sender: TMPL at BBNG
Subject: Precedent for Privacy of Electronic Mail

There does seem to be some sort of legal basis for claiming that
material such as the Digest is covered by existing privacy laws.
The report in Computerworld about the US Postal Service's new
Electronic Computer-Originated Mail (Ecom) contains the following
interesting observation:

"...because at least 50% of Ecom is electronically based, a part
of the operation is covered under the rules of the Communications
Act of 1934.  A sign is conspicuously posted in Ecom's Boston
center stating that anyone who violates a message's confidence or
removes a scrap of paper from the Ecom computer room will be
subject to a $10,000 fine, two years in jail or both.

"Once the messages are put in the bright blue and white Ecom
envelope, they are considered as mail and covered under the
standard postal regulations governing mail handling, an Ecom
spokesman said."

(from Computerworld, 11 Jan 1982, p. 12)

Ted Lee
Sperry Univac

------------------------------

From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Pointers to mail header discussions

Mike -

Hers is what I have on Header-People and MsgGroup lists and their
archives.  This information is from OFFICE-3 publicly-accessible file
<ALMSA>INTEREST-GROUPS.TXT  OFFICE-3 supports the net "standard"
ANONYMOUS login with password ARPA.

-Rich Zellich
 ALMSA
---

HEADER-PEOPLE at MIT-MC

   Interest specifically in the format of message headers and related issues 
   such as inter-network mail formats/standards, etc.

   Header-People messages are filed on MIT-MC:KSC;HEADER MINS [and MINS01, 
   MINS02, etc.].  The ones more than 3 years old have been "reaped" but could 
   be retrieved if anyone wants to see them.

   Coordinator: David A. Moon <MOON at MIT-MC>

MsgGroup at MIT-ML

   Interest in electronic mail, message formats, message systems, and the 
   sociological implications of the above.

   Coordinator: EStefferud at USC-ECL/MsgGroup at USC-ECL

[ In future discussions of these issues, please CC these other lists.
  I would like to see the meta-discussion migrate to a more appropriate
  place.  This does not remove it's vital importance to this list, however.
    -Mike ]

------------------------------

From: Christopher C. Stacy <CStacy at MIT-AI>
Subject: To TCP or not to TCP?

    Date: 14 January 1982 0206-PST (Thursday)
    From: lauren at UCLA-Security (Lauren Weinstein)

    Is there some good reason that the ITS machines cannot be 
    gatewayed through a supported machine?  Even little 11's like
    the 24 should be able to run some sort of existing TCP/IP
    implementation.  Rand-Unix currently talks to the ARPANET over
    a 9600 baud tty line via an 11/34 running the NCP.
    --Lauren--

No, there is not any real reason why we cannot set up some limited
gateway.  However, the design of really complete gateways with
protocol translation like one would want is an unsolved research
question.  

In fact we will probably implement some limited functionality to
connect our local network to the Internet, but we will not do any
development which requires a major software effort.  To implement a
real TCP for an ITS machine would require about two years of heavy
duty full time system programming, and since we are rapidly phasing
out our timesharing machines we are not going to undertake such work.
We are not going to do anything until we wake up one day and discover
our plug being pulled out.

------------------------------

From:      Hal.Cornell at UDel
Subject:   Internet addresses

I was bothered by the "user.host @ net" internetwork address for
another reason:  the meaning of "@ foo" is ambiguous.  Foo could be
either a network name or just the name of a regular ARPANET host.

How about using "user @ host @@ net" for internet addresses?  The
"@@ net" could be omitted if the user is on the same network, and
if the user is on the same host, "@ host" could be eliminated also.

                                  Hal Perkins
                                  (Hal.Cornell @ UDel)

------------------------------

From: POSTEL at USC-ISIF
Subject: Overloading the Dot

In the transition plan for converting from NCP to TCP (RFC801), the
plan for mail includes a provision for forwarding mail through a special
forwarder program from NCP/FTP mail hosts to TCP/SMTP hosts by using the
special forwarding address "user.host@fwdr".

After considering the comments in this digest and in other inputs I
have received, I do agree that the syntax "user.host@fwdr" will be
awkward for some hosts to handle.  We need to select a different
character for the separator between the "user" and "host" parts in
this special forwarding address.  My current candidate is per cent (%).
Are their any problems with this choice?

I have discussed this with the people developing the JNT mail system in
the UK, and this use of per cent fits in well with their syntax.

--jon.

------------------------------

From:      Crimmins at BRL-BMD
Subject:   TCP/IP on a CYBER

	I spoke with Tim Fallon of Tektronix about implementing
 TCP/IP on a CYBER 175 running NOS. The results of my conversation
 are as follows.

	DOCUMENTATION:
     
  All documentation is in the code and the Tektronix legal dept. is 
  not ready to release the code. Therefore, no documentation is available.

	IMPLEMENTATION:

  IP	implemented in a PP, ~4000 lines of PP assembler code.

  TCP	runs at a control point in NOS, written in SYMPL.
        SYMPL is a CDC product.
					TomC

------------------------------

[ The following letter arrived Via UUCP, and cannot be answered through the
  BRL-BMD machine.  -Mike ]

From:     steveg.Azure at BRL-BMD
Cc:       rickk.Teklabs at BRL-BMD, timf.Teklabs at BRL-BMD,
          clemc.Teklabs at BRL-BMD
Subject:  Tek's implementation of tcp-ip for Cyber

The statement in the digest was somewhat wrong. [Volume 1 : Issue 12]

The TCP implementation is done in SYMPL (an implementation language for
the Cyber).  The IP implementation is in Cyber Peripheral Processor
assembler (and possibly some SYMPL code).  The upper level stuff (FTP
et. al) is being done in Ratfor.  There are no plans to do a telnet
server as Cyber timesharing is too heavily bound into the front-end
hardware (psuedo terminals are very difficult to implement).  We are
using Hyperchannel hardware and have not done any work with any other
hardware.  Throughput looping back in the hyperchannel adapter on an
idle Cyber 175 is in the 1Mbit range.  This is all under NOS.

An implementation fo VMS is also underway here, but I'm not very up on
that one.  I think it's being done in Ratfor (so they can use the same
code for FTP as the Cyber).  We did write a hyperchannel driver for
3Com's UNET on both the 11/70 and Vax Unix systems.

The actual guys that did the work can be reached at:

	...!teklabs!rickk   (Rick Krull - FTP, Unix stuff)
	...!teklabs!timf    (Tim Fallon - Cyber IP, TCP, project mgr)
	[ snail mail:
		Box 500, M/S 50-454, Beaverton OR 97077
		(503) 644-0161
	]

Currently, they're working with 3Com to get the Unix-TCP flow control
code working fully as the Cyber can easily overdrive the Unix machines.

Steve Glaser

END OF TCP-IP DIGEST
********************

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Wed Jan 20 00:11:36 1982
From:      ucbvax!tcp-ip
To:        fa.tcp-ip
Subject:   TCP-IP Digest, Vol 1 #13

>From Mike@BRL Tue Jan 19 10:52:46 1982
TCP/IP Digest             Monday, 18 Jan 1982      Volume 1 : Issue 13

Today's Topics:
                           New Digest Headers
                     Public Distribution of Digests
          Restricted Distribution of Mailing Lists/Digests/Etc?
            What is PUBLIC and What is PRIVATE Distribution?
                Precedent for Privacy of Electronic Mail
                  Related Discussion Group Information
                          To TCP or not to TCP?
                InterNet Addresses && Overloading the Dot
                            TCP/IP on a Cyber
----------------------------------------------------------------------
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

From:    Mike at BRL
Subject: New Digest Headers

This digest marks the first issue with the new headers people have been
asking for.  If this is not completely delightful to everybody, please
let me know.
					Cheers,
					 -Mike
------------------------------

From: Mike Peeler <Admin.MDP at SU-SCORE>
Subject: Public Distribution

    One way we could tell people that digest material is not public
would be first to announce the fact as an administrative note in the
digest and then to mention it whenever introducing a new member to the
list (by sending them a "welcome" note).  This approach is much less
distasteful than that of putting a warning on the label.

    The problem with it is that not all subscribers are added by one
list maintainer.  In fact, many of them get the digests by mechanisms
essentially equivalent to a bulletin board.  This means that a large
fraction of our new readers will never get a welcome note.

    If we regard the above as ineffective, then we want to make the
warning as unobtrusive as possible.  Two possibilities present them-
selves.  The first possibility would be to tuck it away in the header
instead of the banner; for example

        Date: Friday, 15 January 1982
        From: PCP-IV at BAL
        Private: Not for public distribution
        Subject: PCP-IV Digest  V9 #23
        To: PCP-IV at BAL

The second possibility would be to place the warning at the bottom of
the digest instead of the top; it might look like

        ------------------------------

        **************   End of PCP-IV Digest   **************
        *********   (Not For Public Distribution)   **********
        ******************************************************

or perhaps something less ostentatious to the same effect.

    The latter, like the warning in the banner, will break some
undigestifying programs, but probably in a milder and more easily
reparable way.  The former will not break most software, but may not
be as aesthetically acceptable.

                                    Yours very sincerely,

                                                      Mike

------------------------------

From: Paul A. Karger <KARGER at DEC-MARLBORO>
Subject: restricted distribution of mailing lists/digests/etc

While putting a restricted distribution statement on a digest may be a
psychological limitation on distribution, there a couple of problems.  First,
since ARPA and DCA are part of the DoD, there are specific regulations
on what may or may not be marked as FOR OFFICIAL USE ONLY.  The regulations
are in part designed to not let people invent other kinds of markings.
This dates back to the Ellsberg case and the desire to limit the ability
of govt people to conceal information from the "public" (whoever that is)

What happens if someone submits a Freedom of information Act request
for Volume 2, Issue 6 of TCP-IP Digest?  Worse still, what if someone
submits a FOIA request for SFL??

My familliarity with the applicable regs is a little stale, because I left
the Air Force over 2 years ago, but I would be very careful about developing
new ways to restrict distribution of government information.  

Paul Karger

------------------------------

From: V. Ellen Golden <ELLEN at MIT-MC>
Subject: [Paul A. Karger:  restricted distribution of mailing lists/digests]

THE ELLSBERG CASE?  Gosh... I am ancient.
Daniel Ellsberg made copies of the Pentagon Papers, which were
secret discussions about the Vietnam War.  He worked for a Harvard/MIT
institute for Government (Political Science) sort of thing.  He thought
"the people" should know what was going on, and so made copies of the
reports.  The CIA etc was not enthusiased.  The group who were involved
in stopping him were the same group which became familiar later:
The Plumbers (they invaded his psychiatrist's office, in California, yet).
The Pentagon Papers were published in the New York Times.  I admit I am
not sure if this was the event which triggered the Plumbers (of later
Watergate fame) to go to the psychiatrist's office, or if after all was
said and done, the stuff finally made it to the public eye. (Other ancients
like myself may recall better than I, and I beg them to correct my somewhat
sketchy remembrance of the events.)

anyway... in some way the Ellsberg case does have a bearing here in
the Digest-people discussion.  Do "the people" have a right to "know"
(what?).  I would say myself that what is in digests is not classified
in any sense of the word, but I have no idea how that relates to our
(ARPANET) status.

------------------------------

Subject: What is Public and what is Private distribution?
From: TMPL at BBNG

How my name got on the Digest list is a longish story, so I won't
go into it, except to say that it had to  do  with  my  exploring
some form of internetworking as a better way of accessing the net
than I do currently (corporate phone lines to Boston or Telenet).
My  main  use  of  the  net  is  as part of the computer security
community and is fully and properly justified by the right set of
letters from the Pentagon to BBN, DCA, etc.  ANYWAY, I have found
the Digest most interesting and have been circulating it  to  our
communications and systems research people, chiefly because it is
quite clear that at some point our products will have to  support
TCP  etc.   for our government customers at least.  I view such a
redistribution as an acceptable  way  of  communicating  research
results  to  those  who  can and ought to use them.  It certainly
isn't a public distribution in the sense of the mass media, but I
would like to be reassured that it is an acceptably private one.
	
Ted Lee
Manager, Systems Security
Sperry Univac
Roseville, Mn.

------------------------------

From:      Mike Muuss <tcp-ip@brl>
Subject:   Re:  What is Public and what is Private distribution?

Ted -

	I am pleased that a major manufacturer like Sperry Univac is
looking at the TCP/IP protocols (and the Digest).  It is groups just
like yours that everyone expects the Digests to go to.  Frequently,
the Digest will contain status reports about on-going
projects, or discussions of evolving featues/bugs/whatever.  This
type of "working notes" material can often be confusing or misleading
to the casual onlooker, and hence the concern that information which
is going to the general public be obtained through official channels
(Jon Postel or Vint Cerf, DCA/DARPA/ISI).

	Please do not re-publish materials or statements from the Digest,
but please DO feel free to distribute it to any interested people within
your organization.
					Sleepily,
					 -Mike

------------------------------

Sender: TMPL at BBNG
Subject: Precedent for Privacy of Electronic Mail

There does seem to be some sort of legal basis for claiming that
material such as the Digest is covered by existing privacy laws.
The report in Computerworld about the US Postal Service's new
Electronic Computer-Originated Mail (Ecom) contains the following
interesting observation:

"...because at least 50% of Ecom is electronically based, a part
of the operation is covered under the rules of the Communications
Act of 1934.  A sign is conspicuously posted in Ecom's Boston
center stating that anyone who violates a message's confidence or
removes a scrap of paper from the Ecom computer room will be
subject to a $10,000 fine, two years in jail or both.

"Once the messages are put in the bright blue and white Ecom
envelope, they are considered as mail and covered under the
standard postal regulations governing mail handling, an Ecom
spokesman said."

(from Computerworld, 11 Jan 1982, p. 12)

Ted Lee
Sperry Univac

------------------------------

From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Pointers to mail header discussions

Mike -

Hers is what I have on Header-People and MsgGroup lists and their
archives.  This information is from OFFICE-3 publicly-accessible file
<ALMSA>INTEREST-GROUPS.TXT  OFFICE-3 supports the net "standard"
ANONYMOUS login with password ARPA.

-Rich Zellich
 ALMSA
---

HEADER-PEOPLE at MIT-MC

   Interest specifically in the format of message headers and related issues 
   such as inter-network mail formats/standards, etc.

   Header-People messages are filed on MIT-MC:KSC;HEADER MINS [and MINS01, 
   MINS02, etc.].  The ones more than 3 years old have been "reaped" but could 
   be retrieved if anyone wants to see them.

   Coordinator: David A. Moon <MOON at MIT-MC>

MsgGroup at MIT-ML

   Interest in electronic mail, message formats, message systems, and the 
   sociological implications of the above.

   Coordinator: EStefferud at USC-ECL/MsgGroup at USC-ECL

[ In future discussions of these issues, please CC these other lists.
  I would like to see the meta-discussion migrate to a more appropriate
  place.  This does not remove it's vital importance to this list, however.
    -Mike ]

------------------------------

From: Christopher C. Stacy <CStacy at MIT-AI>
Subject: To TCP or not to TCP?

    Date: 14 January 1982 0206-PST (Thursday)
    From: lauren at UCLA-Security (Lauren Weinstein)

    Is there some good reason that the ITS machines cannot be 
    gatewayed through a supported machine?  Even little 11's like
    the 24 should be able to run some sort of existing TCP/IP
    implementation.  Rand-Unix currently talks to the ARPANET over
    a 9600 baud tty line via an 11/34 running the NCP.
    --Lauren--

No, there is not any real reason why we cannot set up some limited
gateway.  However, the design of really complete gateways with
protocol translation like one would want is an unsolved research
question.  

In fact we will probably implement some limited functionality to
connect our local network to the Internet, but we will not do any
development which requires a major software effort.  To implement a
real TCP for an ITS machine would require about two years of heavy
duty full time system programming, and since we are rapidly phasing
out our timesharing machines we are not going to undertake such work.
We are not going to do anything until we wake up one day and discover
our plug being pulled out.

------------------------------

From:      Hal.Cornell at UDel
Subject:   Internet addresses

I was bothered by the "user.host @ net" internetwork address for
another reason:  the meaning of "@ foo" is ambiguous.  Foo could be
either a network name or just the name of a regular ARPANET host.

How about using "user @ host @@ net" for internet addresses?  The
"@@ net" could be omitted if the user is on the same network, and
if the user is on the same host, "@ host" could be eliminated also.

                                  Hal Perkins
                                  (Hal.Cornell @ UDel)

------------------------------

From: POSTEL at USC-ISIF
Subject: Overloading the Dot

In the transition plan for converting from NCP to TCP (RFC801), the
plan for mail includes a provision for forwarding mail through a special
forwarder program from NCP/FTP mail hosts to TCP/SMTP hosts by using the
special forwarding address "user.host@fwdr".

After considering the comments in this digest and in other inputs I
have received, I do agree that the syntax "user.host@fwdr" will be
awkward for some hosts to handle.  We need to select a different
character for the separator between the "user" and "host" parts in
this special forwarding address.  My current candidate is per cent (%).
Are their any problems with this choice?

I have discussed this with the people developing the JNT mail system in
the UK, and this use of per cent fits in well with their syntax.

--jon.

------------------------------

From:      Crimmins at BRL-BMD
Subject:   TCP/IP on a CYBER

	I spoke with Tim Fallon of Tektronix about implementing
 TCP/IP on a CYBER 175 running NOS. The results of my conversation
 are as follows.

	DOCUMENTATION:
     
  All documentation is in the code and the Tektronix legal dept. is 
  not ready to release the code. Therefore, no documentation is available.

	IMPLEMENTATION:

  IP	implemented in a PP, ~4000 lines of PP assembler code.

  TCP	runs at a control point in NOS, written in SYMPL.
        SYMPL is a CDC product.
					TomC

------------------------------

[ The following letter arrived Via UUCP, and cannot be answered through the
  BRL-BMD machine.  -Mike ]

From:     steveg.Azure at BRL-BMD
Cc:       rickk.Teklabs at BRL-BMD, timf.Teklabs at BRL-BMD,
          clemc.Teklabs at BRL-BMD
Subject:  Tek's implementation of tcp-ip for Cyber

The statement in the digest was somewhat wrong. [Volume 1 : Issue 12]

The TCP implementation is done in SYMPL (an implementation language for
the Cyber).  The IP implementation is in Cyber Peripheral Processor
assembler (and possibly some SYMPL code).  The upper level stuff (FTP
et. al) is being done in Ratfor.  There are no plans to do a telnet
server as Cyber timesharing is too heavily bound into the front-end
hardware (psuedo terminals are very difficult to implement).  We are
using Hyperchannel hardware and have not done any work with any other
hardware.  Throughput looping back in the hyperchannel adapter on an
idle Cyber 175 is in the 1Mbit range.  This is all under NOS.

An implementation fo VMS is also underway here, but I'm not very up on
that one.  I think it's being done in Ratfor (so they can use the same
code for FTP as the Cyber).  We did write a hyperchannel driver for
3Com's UNET on both the 11/70 and Vax Unix systems.

The actual guys that did the work can be reached at:

	...!teklabs!rickk   (Rick Krull - FTP, Unix stuff)
	...!teklabs!timf    (Tim Fallon - Cyber IP, TCP, project mgr)
	[ snail mail:
		Box 500, M/S 50-454, Beaverton OR 97077
		(503) 644-0161
	]

Currently, they're working with 3Com to get the Unix-TCP flow control
code working fully as the Cyber can easily overdrive the Unix machines.

Steve Glaser

END OF TCP-IP DIGEST
********************

END OF DOCUMENT