----MESSAGE-BEGIN---- [anews.Aucbvax.5690] <1982010422014100> Message-ID: Newsgroups: fa.tcp-ip X-Path: utzoo!decvax!ucbvax!tcp-ip From: ucbvax!tcp-ip Date: Tue Jan 5 03:01:41 1982 Subject: TCP-IP Digest, Vol 1 #10 X-Google-Info: Converted from the original A-News header >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 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 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 ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982010422075500> Mail-from: ARPANET host BRL rcvd at 5-Jan-82 0340-PST Date: 5 Jan 82 3:07:55-EST (Tue) From: Mike Muuss To: list: Subject: TCP-IP Digest, Vol 1 #10 Bcc: 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 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 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 ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982011112524800> Mail-from: ARPANET host BRL rcvd at 11-Jan-82 1918-PST Date: 11 Jan 82 17:52:48-EST (Mon) From: Mike Muuss To: list: Subject: TCP-IP Digest, Vol 1 #11 Bcc: 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 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 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 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 ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- [anews.Aucbvax.5748] <1982011215110600> Message-ID: Newsgroups: fa.tcp-ip X-Path: utzoo!decvax!ucbvax!tcp-ip From: ucbvax!tcp-ip Date: Tue Jan 12 20:11:06 1982 Subject: TCP-IP Digest, Vol 1 #11 X-Google-Info: Converted from the original A-News header >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 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 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 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 ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982011401382800> Mail-from: ARPANET host BRL rcvd at 14-Jan-82 1202-PST Date: 14 Jan 82 6:38:28-EST (Thu) From: Mike Muuss To: list: Subject: TCP-IP Digest, Vol 1 #12 Bcc: 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 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 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 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 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 Subject: For Research Use Only etc. Date: 14 January 1982 00:48-EST From: Christopher C. Stacy 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 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 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 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. 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 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 ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- [anews.Aucbvax.5792] <1982011411203300> Message-ID: Newsgroups: fa.tcp-ip X-Path: utzoo!decvax!ucbvax!tcp-ip From: ucbvax!tcp-ip Date: Thu Jan 14 16:20:33 1982 Subject: TCP-IP Digest, Vol 1 #12 X-Google-Info: Converted from the original A-News header >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 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 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 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 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 Subject: For Research Use Only etc. Date: 14 January 1982 00:48-EST From: Christopher C. Stacy 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 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 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 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. 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 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 ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982011815380000> Mail-from: ARPANET host BRL rcvd at 18-Jan-82 2148-PST Sender: Mike Muuss From: TCP-IP at BRL To: TCP-IP at BRL Reply-To: TCP-IP at BRL Date: 18 Jan 1982 Subject: TCP-IP Digest, Vol 1 #13 Via: Brl; 18 Jan 82 19:38-EDT 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 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 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 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 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 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 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 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 ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- [anews.Aucbvax.5859] <1982011919113600> Message-ID: Newsgroups: fa.tcp-ip X-Path: utzoo!decvax!ucbvax!tcp-ip From: ucbvax!tcp-ip Date: Wed Jan 20 00:11:36 1982 Subject: TCP-IP Digest, Vol 1 #13 X-Google-Info: Converted from the original A-News header >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 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 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 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 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 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 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 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 ******************** ----MESSAGE-END----