From vint at google.com Tue Jan 1 12:40:54 2019 From: vint at google.com (Vint Cerf) Date: Tue, 1 Jan 2019 15:40:54 -0500 Subject: [ih] IEN 48 Message-ID: does anyone know whether there is a copy of IEN 48 with diagrams? v -- New postal address: Google 1875 Explorer Street, 10th Floor Reston, VA 20190 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.e.carpenter at gmail.com Tue Jan 1 19:01:13 2019 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 2 Jan 2019 16:01:13 +1300 Subject: [ih] IEN 48 In-Reply-To: References: Message-ID: <7fea8535-6a91-f45c-e5d6-5e4aba4fe6ae@gmail.com> www.postel.org/ien/pdf/ien048.pdf And a full set at https://www.rfc-editor.org/ien/scanned/ Regards & all the best for 2019 Brian Carpenter On 2019-01-02 09:40, Vint Cerf wrote: > does anyone know whether there is a copy of IEN 48 with diagrams? > v > > > -- > New postal address: > Google > 1875 Explorer Street, 10th Floor > Reston, VA 20190 > > _______ > internet-history mailing list > internet-history at postel.org > http://mailman.postel.org/mailman/listinfo/internet-history > Contact list-owner at postel.org for assistance. > From vint at google.com Tue Jan 1 19:15:50 2019 From: vint at google.com (Vint Cerf) Date: Tue, 1 Jan 2019 22:15:50 -0500 Subject: [ih] IEN 48 In-Reply-To: <7fea8535-6a91-f45c-e5d6-5e4aba4fe6ae@gmail.com> References: <7fea8535-6a91-f45c-e5d6-5e4aba4fe6ae@gmail.com> Message-ID: thanks Brian - needed to look at the figures again to see the Autonomous System implications. v On Tue, Jan 1, 2019 at 10:01 PM Brian E Carpenter < brian.e.carpenter at gmail.com> wrote: > www.postel.org/ien/pdf/ien048.pdf > > And a full set at https://www.rfc-editor.org/ien/scanned/ > > Regards & all the best for 2019 > Brian Carpenter > > On 2019-01-02 09:40, Vint Cerf wrote: > > does anyone know whether there is a copy of IEN 48 with diagrams? > > v > > > > > > -- > > New postal address: > > Google > > 1875 Explorer Street, 10th Floor > > Reston, VA 20190 > > > > _______ > > internet-history mailing list > > internet-history at postel.org > > http://mailman.postel.org/mailman/listinfo/internet-history > > Contact list-owner at postel.org for assistance. > > > -- New postal address: Google 1875 Explorer Street, 10th Floor Reston, VA 20190 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Wed Jan 2 04:51:01 2019 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 2 Jan 2019 13:51:01 +0100 Subject: [ih] "365 IETF RFCs: a 50th anniversary dive" Message-ID: <20190102125101.GA29143@laperouse.bortzmeyer.org> This author will write one article per day, starting with RFC 1, for the 50th anniversary. https://write.as/365-rfcs/365-ietf-rfcs-a-50th-anniversary-dive The first one was yesterday (note there is a question for us in it: does anyone have a copy of RFC 1, the original one, not the modern, retyped version?): https://write.as/365-rfcs/rfc-1 From fenwick.mckelvey at concordia.ca Sun Jan 6 19:15:56 2019 From: fenwick.mckelvey at concordia.ca (Fenwick Mckelvey) Date: Mon, 7 Jan 2019 03:15:56 +0000 Subject: [ih] New journal article on IMPs, modems and gateways Message-ID: Hi, Kevin Driscoll and I are happy to share our new article on the interface message processor, modems and gateways published in the special issue on ARPANET in the Internet Histories journal. You can view the article for free at: https://www.tandfonline.com/eprint/yMkaE54yuIerwcwViDnE/full Our article focuses on the IMP?s relation to the telephone system ? all its work connecting nodes through long lines and modems ? and to the history of gateways. We hope the article inspires more interest in our fields on gateways and other devices at the margins that connected computer networks over the years. As media historians, we are hoping to collect more examples, especially specific gateways, and welcome suggestions of where to look next. For me, the article was also a chance to focus more on IMPs in context, building on some insights from my new book Internet Daemons, http://internetdaemons.com. If you have any questions or comments, we?d love to hear them. Finally, a big thanks to Dave Walden for his feedback in writing this manuscript. His website, book and comments made this publication possible. All our errors are our own. Hope you enoy! Best, Fenwick Associate Professor, Communication Studies Concordia University http://www.fenwickmckelvey.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From internet-history at gtaylor.tnetconsulting.net Mon Jan 7 15:51:28 2019 From: internet-history at gtaylor.tnetconsulting.net (Grant Taylor) Date: Mon, 7 Jan 2019 16:51:28 -0700 Subject: [ih] New journal article on IMPs, modems and gateways In-Reply-To: References: Message-ID: <210b695d-fc7e-ac55-b56a-1073d8b2b346@spamtrap.tnetconsulting.net> On 01/06/2019 08:15 PM, Fenwick Mckelvey wrote: > Hi, Hi, > Kevin Driscoll and I are happy to share our new article on the interface > message processor, modems and gateways published in the special issue on > ARPANET in the Internet Histories journal. Intriguing. > You can view the article for free at: > https://www.tandfonline.com/eprint/yMkaE54yuIerwcwViDnE/full Thank you for the link. > Our article focuses on the IMP?s relation to the telephone system ? all > its work connecting nodes through long lines and modems ? and to the > history of gateways. We hope the article inspires more interest in our > fields on gateways and other devices at the margins that connected > computer networks over the years. As media historians, we are hoping to > collect more examples, especially specific gateways, and welcome > suggestions of where to look next. I will definitely be making time to read your article. > For me, the article was also a chance to focus more on IMPs in context, > building on some insights from my new book Internet Daemons, > http://internetdaemons.com. Oh. That looks promising. }:-) I'm hoping that this ends up being a companion to Where Wizards Stay Up Late - The Origins of the Internet, a book that I've quite enjoyed. I love technical details and history of how things came about. > If you have any questions or comments, we?d love to hear them. Where would you like questions or comments sent to? - I've been accused of being wordy and I doubt this mailing list is the best place. > Finally, a big thanks to Dave Walden for his feedback in writing this > manuscript. His website, book and comments made this publication > possible. All our errors are our own. *salute* > Hope you enoy! :-) -- Grant. . . . unix || die From jack at 3kitty.org Tue Jan 15 16:19:44 2019 From: jack at 3kitty.org (Jack Haverty) Date: Tue, 15 Jan 2019 16:19:44 -0800 Subject: [ih] Internet Path Analysis Tool? Message-ID: <054bba0e-be19-038b-eb31-4cf872866d32@3kitty.org> Memories fade... I vaguely remember a discussion, decades ago, about a tool to analyze Internet behavior. But I don't remember where, when, or even if it was a meeting or a conversation at a hotel bar, or whether anything happened afterwards. The problem was how to qualitatively evaluate how a specific Internet path behaved. The concept was to have a packet-trace tool (think something like Etherwatch) at each end, capturing all packets transiting between 2 endpoints (PCs probably), and filtering to extract only the packets associated with a particular "connection" (not necessarily TCP). So you would capture two sets of data, one representing everything that got sent, and the other everything that got received. There have been tools for a long time that do such captures. The "analysis" part was to create a tool that took that capture data from the two ends, and correlated the two sets of data to analyze what happened to the packets along the way. How many got dropped? Delivered out of order? How wide was the dispersion of delivery times? Duplicates? How did behavior change with size, or rate of sending? Etc. If a TCP connection was involved, how many packets were retransmitted? How may were retransmitted needlessly because the "lost" packet arrived later? Etc. The goal was to develop a set of such metrics which would effectively measure the "quality" of a particular Internet path, track it over time, day-to-day, month, etc., and be able to set trigger points where that path would be considered "normal" or "degraded" or "unusable". Did such a tool ever get implemented? Best of course would be a link to a place to download it....one can dream. Tnx, /Jack Haverty From shane at mcewan.id.au Tue Jan 15 20:18:11 2019 From: shane at mcewan.id.au (Shane McEwan) Date: Wed, 16 Jan 2019 15:18:11 +1100 Subject: [ih] Internet Path Analysis Tool? In-Reply-To: <054bba0e-be19-038b-eb31-4cf872866d32@3kitty.org> References: <054bba0e-be19-038b-eb31-4cf872866d32@3kitty.org> Message-ID: <2cbbbc0a-897b-00a9-03c0-d6838406dc79@mcewan.id.au> On 16/1/19 11:19 am, Jack Haverty wrote: > The goal was to develop a set of such metrics which would effectively > measure the "quality" of a particular Internet path, track it over time, > day-to-day, month, etc., and be able to set trigger points where that > path would be considered "normal" or "degraded" or "unusable". I used to work for a company that did this. Although not with captured data (and not free :-P). They use techniques similar to traceroute to discover the path and targeted HTTP requests for bandwidth and server measurements. After some calculations it gives a "user experience score" at the end that can be tacked over time. https://www.actual-experience.com/ Shane. From jack at 3kitty.org Thu Jan 17 13:37:50 2019 From: jack at 3kitty.org (Jack Haverty) Date: Thu, 17 Jan 2019 13:37:50 -0800 Subject: [ih] Internet Path Analysis Tool? In-Reply-To: <054bba0e-be19-038b-eb31-4cf872866d32@3kitty.org> References: <054bba0e-be19-038b-eb31-4cf872866d32@3kitty.org> Message-ID: Thanks everyone. I received several offline replies pointing me to Van Jacobson's path analysis tool, and even a pointer to a downloadable more recent (2005) reimplementation (Thanks to Mike Brescia!) FYI, it's at: http://www.kitchenlab.org/www/bmah/Software/pchar/ Unfortunately that tool doesn't seem to be very useful anymore since it's based on pinging and many parts of the Internet seem to have disabled the ability to be pinged. I downloaded and ran the tool to several sites just now and it reports 100% loss rate (nobody responds to pings, at least in my neighborhood of the Internet). I was really searching for a different tool, not based on pinging. It would require access to both ends of the path you're testing, e.g., the ability to hang some kind of packet-capture device on a LAN at each end. That could be as simple as a Raspberry Pi running Etherape or similar software, plugged in to the same LAN as your user machines so the Pi could see the packets. The packet capture would be carried out while you were using the Internet in some fashion between points A and B. It might be an application using TCP/IP, like simple browsing, or an application using IP with some kind of streaming protocol, or anything else that would exchange IP packets. The captured data would characterize how the Internet was behaving as that real application was being used, and the data would be analyzed "offline" (at least delayed a few seconds), with the timelines of the two endpoints correlated. Each end could see what it sent, and what it received from the other end, and when. In addition each end could see any kind of control packets that it received from somewhere else - e.g., a Source Quench (assuming anybody actually sends those any more). There could be many ways to display, extract statistics, and otherwise view the captured data. But one interesting way would be be show the packets as blips on a timeline, much like an oscilloscope or datascope display. What I'm remembering is a display similar to what you see using audio tools like Audacity, where you can see the actual waveform of audio, zoom in and out, etc. The difference is that the path tool could do things like color-code dropped packets, duplicates, Source Quenches, as well as graph things like current window size if it's a TCP packet stream. By displaying the point A and point B timelines one above the other (like a dual-trace scope), it could also highlight how packets were delayed, reordered, or duplicated by drawing lines between the sender's timeline and the receiver's. Of course you could also load up the same test results but from yesterday or last week or whatever, and compare with other test sessions. One use would be to take a dataset while everything was considered "normal", to be used for comparison with a dataset taken when "it's broken", to see what has changed. I can "see" this tool in my head ... but I don't know if I'm remembering something that I actually used, or just imagined years ago while trying to debug Internet performance issues. Perhaps I'm remembering some vendor's in-house tool? Or it might just be historical Internet vaporware..... Mike pointed me to some more recent IETF work, but so far I've found a lot of proposals, frameworks, protocols, metrics, et al but no actual implementations of anything, at least not publicly available. /Jack On 1/15/19 4:19 PM, Jack Haverty wrote: > Memories fade... > > I vaguely remember a discussion, decades ago, about a tool to analyze > Internet behavior. But I don't remember where, when, or even if it was > a meeting or a conversation at a hotel bar, or whether anything happened > afterwards. > > The problem was how to qualitatively evaluate how a specific Internet > path behaved. The concept was to have a packet-trace tool (think > something like Etherwatch) at each end, capturing all packets transiting > between 2 endpoints (PCs probably), and filtering to extract only the > packets associated with a particular "connection" (not necessarily TCP). > So you would capture two sets of data, one representing everything that > got sent, and the other everything that got received. > > There have been tools for a long time that do such captures. The > "analysis" part was to create a tool that took that capture data from > the two ends, and correlated the two sets of data to analyze what > happened to the packets along the way. How many got dropped? Delivered > out of order? How wide was the dispersion of delivery times? > Duplicates? How did behavior change with size, or rate of sending? > Etc. If a TCP connection was involved, how many packets were > retransmitted? How may were retransmitted needlessly because the "lost" > packet arrived later? Etc. > > The goal was to develop a set of such metrics which would effectively > measure the "quality" of a particular Internet path, track it over time, > day-to-day, month, etc., and be able to set trigger points where that > path would be considered "normal" or "degraded" or "unusable". > > Did such a tool ever get implemented? Best of course would be a link to > a place to download it....one can dream. > > Tnx, > /Jack Haverty > > _______ > internet-history mailing list > internet-history at postel.org > http://mailman.postel.org/mailman/listinfo/internet-history > Contact list-owner at postel.org for assistance. > From brian.e.carpenter at gmail.com Thu Jan 17 15:45:53 2019 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 18 Jan 2019 12:45:53 +1300 Subject: [ih] Internet Path Analysis Tool? In-Reply-To: References: <054bba0e-be19-038b-eb31-4cf872866d32@3kitty.org> Message-ID: <7da03242-c170-3708-c60c-4873884d7d3a@gmail.com> Jack, I think you're looking for RIPE Atlas: https://labs.ripe.net/atlas And there's a *lot* of stuff at http://www.caida.org/home/, of course. Regards Brian Carpenter On 2019-01-18 10:37, Jack Haverty wrote: > Thanks everyone. I received several offline replies pointing me to Van > Jacobson's path analysis tool, and even a pointer to a downloadable more > recent (2005) reimplementation (Thanks to Mike Brescia!) FYI, it's at: > http://www.kitchenlab.org/www/bmah/Software/pchar/ > > Unfortunately that tool doesn't seem to be very useful anymore since > it's based on pinging and many parts of the Internet seem to have > disabled the ability to be pinged. I downloaded and ran the tool to > several sites just now and it reports 100% loss rate (nobody responds to > pings, at least in my neighborhood of the Internet). > > I was really searching for a different tool, not based on pinging. It > would require access to both ends of the path you're testing, e.g., the > ability to hang some kind of packet-capture device on a LAN at each end. > That could be as simple as a Raspberry Pi running Etherape or similar > software, plugged in to the same LAN as your user machines so the Pi > could see the packets. > > The packet capture would be carried out while you were using the > Internet in some fashion between points A and B. It might be an > application using TCP/IP, like simple browsing, or an application using > IP with some kind of streaming protocol, or anything else that would > exchange IP packets. > > The captured data would characterize how the Internet was behaving as > that real application was being used, and the data would be analyzed > "offline" (at least delayed a few seconds), with the timelines of the > two endpoints correlated. Each end could see what it sent, and what it > received from the other end, and when. In addition each end could see > any kind of control packets that it received from somewhere else - e.g., > a Source Quench (assuming anybody actually sends those any more). > > There could be many ways to display, extract statistics, and otherwise > view the captured data. But one interesting way would be be show the > packets as blips on a timeline, much like an oscilloscope or datascope > display. > > What I'm remembering is a display similar to what you see using audio > tools like Audacity, where you can see the actual waveform of audio, > zoom in and out, etc. > > The difference is that the path tool could do things like color-code > dropped packets, duplicates, Source Quenches, as well as graph things > like current window size if it's a TCP packet stream. > > By displaying the point A and point B timelines one above the other > (like a dual-trace scope), it could also highlight how packets were > delayed, reordered, or duplicated by drawing lines between the sender's > timeline and the receiver's. > > Of course you could also load up the same test results but from > yesterday or last week or whatever, and compare with other test > sessions. One use would be to take a dataset while everything was > considered "normal", to be used for comparison with a dataset taken when > "it's broken", to see what has changed. > > I can "see" this tool in my head ... but I don't know if I'm remembering > something that I actually used, or just imagined years ago while trying > to debug Internet performance issues. Perhaps I'm remembering some > vendor's in-house tool? Or it might just be historical Internet > vaporware..... > > Mike pointed me to some more recent IETF work, but so far I've found a > lot of proposals, frameworks, protocols, metrics, et al but no actual > implementations of anything, at least not publicly available. > > /Jack > > > On 1/15/19 4:19 PM, Jack Haverty wrote: >> Memories fade... >> >> I vaguely remember a discussion, decades ago, about a tool to analyze >> Internet behavior. But I don't remember where, when, or even if it was >> a meeting or a conversation at a hotel bar, or whether anything happened >> afterwards. >> >> The problem was how to qualitatively evaluate how a specific Internet >> path behaved. The concept was to have a packet-trace tool (think >> something like Etherwatch) at each end, capturing all packets transiting >> between 2 endpoints (PCs probably), and filtering to extract only the >> packets associated with a particular "connection" (not necessarily TCP). >> So you would capture two sets of data, one representing everything that >> got sent, and the other everything that got received. >> >> There have been tools for a long time that do such captures. The >> "analysis" part was to create a tool that took that capture data from >> the two ends, and correlated the two sets of data to analyze what >> happened to the packets along the way. How many got dropped? Delivered >> out of order? How wide was the dispersion of delivery times? >> Duplicates? How did behavior change with size, or rate of sending? >> Etc. If a TCP connection was involved, how many packets were >> retransmitted? How may were retransmitted needlessly because the "lost" >> packet arrived later? Etc. >> >> The goal was to develop a set of such metrics which would effectively >> measure the "quality" of a particular Internet path, track it over time, >> day-to-day, month, etc., and be able to set trigger points where that >> path would be considered "normal" or "degraded" or "unusable". >> >> Did such a tool ever get implemented? Best of course would be a link to >> a place to download it....one can dream. >> >> Tnx, >> /Jack Haverty >> >> _______ >> internet-history mailing list >> internet-history at postel.org >> http://mailman.postel.org/mailman/listinfo/internet-history >> Contact list-owner at postel.org for assistance. >> > _______ > internet-history mailing list > internet-history at postel.org > http://mailman.postel.org/mailman/listinfo/internet-history > Contact list-owner at postel.org for assistance. > From jhlowry at mac.com Fri Jan 18 05:06:06 2019 From: jhlowry at mac.com (John Lowry) Date: Fri, 18 Jan 2019 08:06:06 -0500 Subject: [ih] Internet Path Analysis Tool? In-Reply-To: References: <054bba0e-be19-038b-eb31-4cf872866d32@3kitty.org> Message-ID: <753C7EB1-9EF6-4284-8D04-98F6A81959D1@mac.com> You might look at what RIPE Atlas is doing. https://atlas.ripe.net/landing/about/ John > On Jan 17, 2019, at 4:37 PM, Jack Haverty wrote: > > Thanks everyone. I received several offline replies pointing me to Van > Jacobson's path analysis tool, and even a pointer to a downloadable more > recent (2005) reimplementation (Thanks to Mike Brescia!) FYI, it's at: > http://www.kitchenlab.org/www/bmah/Software/pchar/ > > Unfortunately that tool doesn't seem to be very useful anymore since > it's based on pinging and many parts of the Internet seem to have > disabled the ability to be pinged. I downloaded and ran the tool to > several sites just now and it reports 100% loss rate (nobody responds to > pings, at least in my neighborhood of the Internet). > > I was really searching for a different tool, not based on pinging. It > would require access to both ends of the path you're testing, e.g., the > ability to hang some kind of packet-capture device on a LAN at each end. > That could be as simple as a Raspberry Pi running Etherape or similar > software, plugged in to the same LAN as your user machines so the Pi > could see the packets. > > The packet capture would be carried out while you were using the > Internet in some fashion between points A and B. It might be an > application using TCP/IP, like simple browsing, or an application using > IP with some kind of streaming protocol, or anything else that would > exchange IP packets. > > The captured data would characterize how the Internet was behaving as > that real application was being used, and the data would be analyzed > "offline" (at least delayed a few seconds), with the timelines of the > two endpoints correlated. Each end could see what it sent, and what it > received from the other end, and when. In addition each end could see > any kind of control packets that it received from somewhere else - e.g., > a Source Quench (assuming anybody actually sends those any more). > > There could be many ways to display, extract statistics, and otherwise > view the captured data. But one interesting way would be be show the > packets as blips on a timeline, much like an oscilloscope or datascope > display. > > What I'm remembering is a display similar to what you see using audio > tools like Audacity, where you can see the actual waveform of audio, > zoom in and out, etc. > > The difference is that the path tool could do things like color-code > dropped packets, duplicates, Source Quenches, as well as graph things > like current window size if it's a TCP packet stream. > > By displaying the point A and point B timelines one above the other > (like a dual-trace scope), it could also highlight how packets were > delayed, reordered, or duplicated by drawing lines between the sender's > timeline and the receiver's. > > Of course you could also load up the same test results but from > yesterday or last week or whatever, and compare with other test > sessions. One use would be to take a dataset while everything was > considered "normal", to be used for comparison with a dataset taken when > "it's broken", to see what has changed. > > I can "see" this tool in my head ... but I don't know if I'm remembering > something that I actually used, or just imagined years ago while trying > to debug Internet performance issues. Perhaps I'm remembering some > vendor's in-house tool? Or it might just be historical Internet > vaporware..... > > Mike pointed me to some more recent IETF work, but so far I've found a > lot of proposals, frameworks, protocols, metrics, et al but no actual > implementations of anything, at least not publicly available. > > /Jack > > >> On 1/15/19 4:19 PM, Jack Haverty wrote: >> Memories fade... >> >> I vaguely remember a discussion, decades ago, about a tool to analyze >> Internet behavior. But I don't remember where, when, or even if it was >> a meeting or a conversation at a hotel bar, or whether anything happened >> afterwards. >> >> The problem was how to qualitatively evaluate how a specific Internet >> path behaved. The concept was to have a packet-trace tool (think >> something like Etherwatch) at each end, capturing all packets transiting >> between 2 endpoints (PCs probably), and filtering to extract only the >> packets associated with a particular "connection" (not necessarily TCP). >> So you would capture two sets of data, one representing everything that >> got sent, and the other everything that got received. >> >> There have been tools for a long time that do such captures. The >> "analysis" part was to create a tool that took that capture data from >> the two ends, and correlated the two sets of data to analyze what >> happened to the packets along the way. How many got dropped? Delivered >> out of order? How wide was the dispersion of delivery times? >> Duplicates? How did behavior change with size, or rate of sending? >> Etc. If a TCP connection was involved, how many packets were >> retransmitted? How may were retransmitted needlessly because the "lost" >> packet arrived later? Etc. >> >> The goal was to develop a set of such metrics which would effectively >> measure the "quality" of a particular Internet path, track it over time, >> day-to-day, month, etc., and be able to set trigger points where that >> path would be considered "normal" or "degraded" or "unusable". >> >> Did such a tool ever get implemented? Best of course would be a link to >> a place to download it....one can dream. >> >> Tnx, >> /Jack Haverty >> >> _______ >> internet-history mailing list >> internet-history at postel.org >> http://mailman.postel.org/mailman/listinfo/internet-history >> Contact list-owner at postel.org for assistance. >> > _______ > internet-history mailing list > internet-history at postel.org > http://mailman.postel.org/mailman/listinfo/internet-history > Contact list-owner at postel.org for assistance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aamsendonly396 at gmail.com Thu Jan 24 16:14:26 2019 From: aamsendonly396 at gmail.com (Alex McKenzie) Date: Thu, 24 Jan 2019 19:14:26 -0500 Subject: [ih] New journal article on IMPs, modems and gateways In-Reply-To: References: Message-ID: Fenwick, Thank you for posting the pointer to this article to the Internet History list. I've finally had a chance to read it, and I have a few comments. 1. Your paper investigates ARPANET IMPs (and internet gateways) as boundary devices, insulating two technical spheres ("computer people" and "telephone people") from each other. This, in my opinion, is absolutely correct. But then you go on to suggest that these two spheres are not really so distinct, and that "it was not inconceivable that control of the publicly-funded ARPANET would be transferred to the national telecommunications monopoly. ... While it is unclear how seriously AT&T considered taking over ARPANET." I believe that AT&T DID seriously consider taking over ARPANET and firmly rejected the idea as of no practical interest to their mission. For example, in the Computer History Museum transcript of an interview with Dr. Lawrence "Larry" Roberts [ https://archive.computerhistory.org/resources/access/text/2013/04/102746626-05-01-acc.pdf], page 14, Larry says about AT&T: "They were formally approached. The Washington division was excited. They said to me there was a lot of revenue they were getting from the leased lines; they thought it was great. They got excited about it, and Bell Labs got involved, and they had a huge committee, and I presume they went over and over it, and they kept on looking at it, and eventually -- they never gave a response, because that was their way of doing business, but I found out that Bell Labs had said: 'No, it was not compatible with the plan.' " I understand this to mean that leasing lines with data modems was within the plan, but actually fussing with any of the data going over the lines was outside the plan. This seems to me entirely consistent with the AT&T philosophy of "carrying signals is our business, understanding the signals is NOT our business." 2. On page 14 you suggest that the "market-oriented logic" of the internet concept led to the break-up of the Bell monopoly. I believe this is incorrect. I believe AT&T proposed the break-up (to the court hearing a US Department of Justice lawsuit for antitrust violations against AT&T) as a strategy to avoid losing its anti-trust case. I do not believe the logic of the internet design had anything to do with the outcome of this case. Can you cite any evidence to support your viewpoint? 3. Your description of the TIP (page 8) is slightly incorrect. The TIP had 64 ports, but due to a program limitation only 63 of the ports could be used. Any port could be connected to either a modem or a directly-wired terminal. Your description suggests that at most 16 modems could be connected, but in fact 63 modems could be connected (if there were no directly-connected terminals) but this never happened. The directly-wired devices were not restricted to "teleprinter or video terminals"; some TIPs had line printers or other non-interactive devices attached to some ports. I know this is all a bit pedantic and nit-picky, but I hate to have the historical record distorted by misunderstandings in the printed literature. Sincerely, Alex McKenzie BBN 1967-1996 On Sun, Jan 6, 2019 at 10:44 PM Fenwick Mckelvey < fenwick.mckelvey at concordia.ca> wrote: > Hi, > > Kevin Driscoll and I are happy to share our new article on the interface > message processor, modems and gateways published in the special issue on > ARPANET in the Internet Histories journal. > > > > You can view the article for free at: > https://www.tandfonline.com/eprint/yMkaE54yuIerwcwViDnE/full > > > > Our article focuses on the IMP?s relation to the telephone system ? all > its work connecting nodes through long lines and modems ? and to the > history of gateways. We hope the article inspires more interest in our > fields on gateways and other devices at the margins that connected computer > networks over the years. As media historians, we are hoping to collect more > examples, especially specific gateways, and welcome suggestions of where to > look next. > > > > For me, the article was also a chance to focus more on IMPs in context, > building on some insights from my new book Internet Daemons, > http://internetdaemons.com. > > > > If you have any questions or comments, we?d love to hear them. > > > > Finally, a big thanks to Dave Walden for his feedback in writing this > manuscript. His website, book and comments made this publication possible. > All our errors are our own. > > > > Hope you enoy! > > > > Best, > > Fenwick > > Associate Professor, Communication Studies > > Concordia University > > http://www.fenwickmckelvey.com > > > > > _______ > internet-history mailing list > internet-history at postel.org > http://mailman.postel.org/mailman/listinfo/internet-history > Contact list-owner at postel.org for assistance. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at bennett.com Thu Jan 24 17:43:31 2019 From: richard at bennett.com (Richard Bennett) Date: Thu, 24 Jan 2019 18:43:31 -0700 Subject: [ih] New journal article on IMPs, modems and gateways In-Reply-To: References: Message-ID: <1518B5AA-6D99-4AF6-8F8B-14E4B12094FC@bennett.com> Given that the government filed its suit against AT&T in 1974, it?s pretty hard to attribute the outcome to the Internet. The version of the story I?ve heard is that AT&T wanted the ability to participate in the computer business all along, so it was willing to bargain with the government about the price for that right. Wasn?t that what the FCC?s Computer Inquiries were about? Computer I was in the 1966. RB > On Jan 24, 2019, at 5:14 PM, Alex McKenzie wrote: > > 2. On page 14 you suggest that the "market-oriented logic" of the internet concept led to the break-up of the Bell monopoly. I believe this is incorrect. I believe AT&T proposed the break-up (to the court hearing a US Department of Justice lawsuit for antitrust violations against AT&T) as a strategy to avoid losing its anti-trust case. I do not believe the logic of the internet design had anything to do with the outcome of this case. Can you cite any evidence to support your viewpoint? ? Richard Bennett High Tech Forum Founder Ethernet & Wi-Fi standards co-creator Internet Policy Consultant -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanjour at comcast.net Thu Jan 24 18:38:21 2019 From: jeanjour at comcast.net (John Day) Date: Thu, 24 Jan 2019 21:38:21 -0500 Subject: [ih] New journal article on IMPs, modems and gateways In-Reply-To: <1518B5AA-6D99-4AF6-8F8B-14E4B12094FC@bennett.com> References: <1518B5AA-6D99-4AF6-8F8B-14E4B12094FC@bennett.com> Message-ID: <82536F34-5D48-4A81-AA67-97F751F7ABE1@comcast.net> That is what I thought it was too. And why they went out and bought NCR. > On Jan 24, 2019, at 20:43, Richard Bennett wrote: > > Given that the government filed its suit against AT&T in 1974, it?s pretty hard to attribute the outcome to the Internet. The version of the story I?ve heard is that AT&T wanted the ability to participate in the computer business all along, so it was willing to bargain with the government about the price for that right. Wasn?t that what the FCC?s Computer Inquiries were about? Computer I was in the 1966. > > RB > >> On Jan 24, 2019, at 5:14 PM, Alex McKenzie > wrote: >> >> 2. On page 14 you suggest that the "market-oriented logic" of the internet concept led to the break-up of the Bell monopoly. I believe this is incorrect. I believe AT&T proposed the break-up (to the court hearing a US Department of Justice lawsuit for antitrust violations against AT&T) as a strategy to avoid losing its anti-trust case. I do not believe the logic of the internet design had anything to do with the outcome of this case. Can you cite any evidence to support your viewpoint? > > ? > Richard Bennett > High Tech Forum Founder > Ethernet & Wi-Fi standards co-creator > > Internet Policy Consultant > > _______ > internet-history mailing list > internet-history at postel.org > http://mailman.postel.org/mailman/listinfo/internet-history > Contact list-owner at postel.org for assistance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vint at google.com Thu Jan 24 18:54:37 2019 From: vint at google.com (Vint Cerf) Date: Thu, 24 Jan 2019 21:54:37 -0500 Subject: [ih] New journal article on IMPs, modems and gateways In-Reply-To: References: Message-ID: AT&T was not approached to take over the ARPANET as far as I know - they were invited to participate in it and declined. Around 1972 Paul Baran and I did a study for ARPA about distributing its IMP assets to various parties rather than making it monolithic. ARPA declined that idea. Eventually it was handed to DCA in 1975 to operate as a service. Bell Labs was interested in its own Bell Data Network design but not interested in taking over ARPANET. v On Thu, Jan 24, 2019 at 7:43 PM Alex McKenzie wrote: > Fenwick, > > Thank you for posting the pointer to this article to the Internet History > list. I've finally had a chance to read it, and I have a few comments. > > 1. Your paper investigates ARPANET IMPs (and internet gateways) as > boundary devices, insulating two technical spheres ("computer people" and > "telephone people") from each other. This, in my opinion, is absolutely > correct. But then you go on to suggest that these two spheres are not > really so distinct, and that "it was not inconceivable that control of the > publicly-funded ARPANET would be transferred to the national > telecommunications monopoly. ... While it is unclear how seriously AT&T > considered taking over ARPANET." I believe that AT&T DID seriously > consider taking over ARPANET and firmly rejected the idea as of no > practical interest to their mission. For example, in the Computer History > Museum transcript of an interview with Dr. Lawrence "Larry" Roberts [ > https://archive.computerhistory.org/resources/access/text/2013/04/102746626-05-01-acc.pdf], > page 14, Larry says about AT&T: "They were formally approached. The > Washington division was excited. They said to me there was a lot of > revenue they were getting from the leased lines; they thought it was great. > They got excited about it, and Bell Labs got involved, and they had a > huge committee, and I presume they went over and over it, and they kept > on looking at it, and eventually -- they never gave a response, because > that was their way of doing business, but I found out that Bell Labs had > said: 'No, it was not compatible with the plan.' " I understand this to > mean that leasing lines with data modems was within the plan, but actually > fussing with any of the data going over the lines was outside the plan. > This seems to me entirely consistent with the AT&T philosophy of "carrying > signals is our business, understanding the signals is NOT our business." > > 2. On page 14 you suggest that the "market-oriented logic" of the internet > concept led to the break-up of the Bell monopoly. I believe this is > incorrect. I believe AT&T proposed the break-up (to the court hearing a US > Department of Justice lawsuit for antitrust violations against AT&T) as a > strategy to avoid losing its anti-trust case. I do not believe the logic > of the internet design had anything to do with the outcome of this case. > Can you cite any evidence to support your viewpoint? > > 3. Your description of the TIP (page 8) is slightly incorrect. The TIP > had 64 ports, but due to a program limitation only 63 of the ports could be > used. Any port could be connected to either a modem or a directly-wired > terminal. Your description suggests that at most 16 modems could be > connected, but in fact 63 modems could be connected (if there were no > directly-connected terminals) but this never happened. The directly-wired > devices were not restricted to "teleprinter or video terminals"; some TIPs > had line printers or other non-interactive devices attached to some ports. > > I know this is all a bit pedantic and nit-picky, but I hate to have the > historical record distorted by misunderstandings in the printed literature. > > Sincerely, > Alex McKenzie > BBN 1967-1996 > > > > On Sun, Jan 6, 2019 at 10:44 PM Fenwick Mckelvey < > fenwick.mckelvey at concordia.ca> wrote: > >> Hi, >> >> Kevin Driscoll and I are happy to share our new article on the interface >> message processor, modems and gateways published in the special issue on >> ARPANET in the Internet Histories journal. >> >> >> >> You can view the article for free at: >> https://www.tandfonline.com/eprint/yMkaE54yuIerwcwViDnE/full >> >> >> >> Our article focuses on the IMP?s relation to the telephone system ? all >> its work connecting nodes through long lines and modems ? and to the >> history of gateways. We hope the article inspires more interest in our >> fields on gateways and other devices at the margins that connected computer >> networks over the years. As media historians, we are hoping to collect more >> examples, especially specific gateways, and welcome suggestions of where to >> look next. >> >> >> >> For me, the article was also a chance to focus more on IMPs in context, >> building on some insights from my new book Internet Daemons, >> http://internetdaemons.com. >> >> >> >> If you have any questions or comments, we?d love to hear them. >> >> >> >> Finally, a big thanks to Dave Walden for his feedback in writing this >> manuscript. His website, book and comments made this publication possible. >> All our errors are our own. >> >> >> >> Hope you enoy! >> >> >> >> Best, >> >> Fenwick >> >> Associate Professor, Communication Studies >> >> Concordia University >> >> http://www.fenwickmckelvey.com >> >> >> >> >> _______ >> internet-history mailing list >> internet-history at postel.org >> http://mailman.postel.org/mailman/listinfo/internet-history >> Contact list-owner at postel.org for assistance. >> > _______ > internet-history mailing list > internet-history at postel.org > http://mailman.postel.org/mailman/listinfo/internet-history > Contact list-owner at postel.org for assistance. > -- New postal address: Google 1875 Explorer Street, 10th Floor Reston, VA 20190 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fenwick.mckelvey at concordia.ca Thu Jan 24 19:41:10 2019 From: fenwick.mckelvey at concordia.ca (Fenwick Mckelvey) Date: Fri, 25 Jan 2019 03:41:10 +0000 Subject: [ih] New journal article on IMPs, modems and gateways In-Reply-To: References: , Message-ID: <1548387670744.306@concordia.ca> Hi all, Thanks Alex for the comments. I really appreciate the 'nit-picky'-ness. We posted the article on the list to get feedback, so the comments are wonderful. I'll reply in-line. 1. We struggled when writing the paper about how serious AT&T considered taking over ARPANET. We eventually cut this argument, because it was beyond its scope and we didn't have a clear opinion. Howard Frank's quote at the start of the paper suggests there were meeting that didn't go anywhere. In JCR Licklider's archive, I found a mention that AT&T didn't like the idea of taking over the ARPANET because of privacy, but I could never check or qualify the comment. For discussion, the note was a summary of a panel discussion on National Networks held at the Interuniversity Communication Council Annual Meeting on 15 October 1970. It noted that AT&T did not want to take ownership of ARPANET because its design violated the company?s privacy obligations as a common carrier. A summary of the panel states, "the design of the IMPs creates a special security problem. On its way from the sender to the recipient, data pass through an IMP in the possession of a third party, who has access to it. The carrier traditionally has responsibility for the security of transmission; thus AT&T find the current situation unacceptable". I never found any more details or context for that quote. 2. Agreed, that sentence is unclear. We're not claiming ARPANET's design led to the break up of AT&T. We're providing some context about the broader movement toward decentralization and markets not ARPANET itself. 3. I'll look into how I can revise that description. Much appreciated. Reading the old documentation is great, but it can be a challenge to interpret. Vint, are you referring to the ARPANET: A Management Study: https://apps.dtic.mil/dtic/tr/fulltext/u2/777747.pdf You given some context, but I'd welcome any more details. Best, Fenwick McKelvey http://www.fenwickmckelvey.com Associate Professor, Communication Studies, Concordia University Director of the Algorithmic Media Observatory http://www.amo-oma.ca/en/ Member of the Center for the Study of Democratic Citizenship http://csdc-cecd.ca/ ________________________________ From: Vint Cerf Sent: Thursday, January 24, 2019 9:54 PM To: Alex McKenzie Cc: Fenwick Mckelvey; kdriscoll at virginia.edu; internet-history at postel.org Subject: Re: [ih] New journal article on IMPs, modems and gateways AT&T was not approached to take over the ARPANET as far as I know - they were invited to participate in it and declined. Around 1972 Paul Baran and I did a study for ARPA about distributing its IMP assets to various parties rather than making it monolithic. ARPA declined that idea. Eventually it was handed to DCA in 1975 to operate as a service. Bell Labs was interested in its own Bell Data Network design but not interested in taking over ARPANET. v On Thu, Jan 24, 2019 at 7:43 PM Alex McKenzie > wrote: Fenwick, Thank you for posting the pointer to this article to the Internet History list. I've finally had a chance to read it, and I have a few comments. 1. Your paper investigates ARPANET IMPs (and internet gateways) as boundary devices, insulating two technical spheres ("computer people" and "telephone people") from each other. This, in my opinion, is absolutely correct. But then you go on to suggest that these two spheres are not really so distinct, and that "it was not inconceivable that control of the publicly-funded ARPANET would be transferred to the national telecommunications monopoly. ... While it is unclear how seriously AT&T considered taking over ARPANET." I believe that AT&T DID seriously consider taking over ARPANET and firmly rejected the idea as of no practical interest to their mission. For example, in the Computer History Museum transcript of an interview with Dr. Lawrence "Larry" Roberts [https://archive.computerhistory.org/resources/access/text/2013/04/102746626-05-01-acc.pdf], page 14, Larry says about AT&T: "They were formally approached. The Washington division was excited. They said to me there was a lot of revenue they were getting from the leased lines; they thought it was great. They got excited about it, and Bell Labs got involved, and they had a huge committee, and I presume they went over and over it, and they kept on looking at it, and eventually -- they never gave a response, because that was their way of doing business, but I found out that Bell Labs had said: 'No, it was not compatible with the plan.' " I understand this to mean that leasing lines with data modems was within the plan, but actually fussing with any of the data going over the lines was outside the plan. This seems to me entirely consistent with the AT&T philosophy of "carrying signals is our business, understanding the signals is NOT our business." 2. On page 14 you suggest that the "market-oriented logic" of the internet concept led to the break-up of the Bell monopoly. I believe this is incorrect. I believe AT&T proposed the break-up (to the court hearing a US Department of Justice lawsuit for antitrust violations against AT&T) as a strategy to avoid losing its anti-trust case. I do not believe the logic of the internet design had anything to do with the outcome of this case. Can you cite any evidence to support your viewpoint? 3. Your description of the TIP (page 8) is slightly incorrect. The TIP had 64 ports, but due to a program limitation only 63 of the ports could be used. Any port could be connected to either a modem or a directly-wired terminal. Your description suggests that at most 16 modems could be connected, but in fact 63 modems could be connected (if there were no directly-connected terminals) but this never happened. The directly-wired devices were not restricted to "teleprinter or video terminals"; some TIPs had line printers or other non-interactive devices attached to some ports. I know this is all a bit pedantic and nit-picky, but I hate to have the historical record distorted by misunderstandings in the printed literature. Sincerely, Alex McKenzie BBN 1967-1996 On Sun, Jan 6, 2019 at 10:44 PM Fenwick Mckelvey > wrote: Hi, Kevin Driscoll and I are happy to share our new article on the interface message processor, modems and gateways published in the special issue on ARPANET in the Internet Histories journal. You can view the article for free at: https://www.tandfonline.com/eprint/yMkaE54yuIerwcwViDnE/full Our article focuses on the IMP?s relation to the telephone system ? all its work connecting nodes through long lines and modems ? and to the history of gateways. We hope the article inspires more interest in our fields on gateways and other devices at the margins that connected computer networks over the years. As media historians, we are hoping to collect more examples, especially specific gateways, and welcome suggestions of where to look next. For me, the article was also a chance to focus more on IMPs in context, building on some insights from my new book Internet Daemons, http://internetdaemons.com. If you have any questions or comments, we?d love to hear them. Finally, a big thanks to Dave Walden for his feedback in writing this manuscript. His website, book and comments made this publication possible. All our errors are our own. Hope you enoy! Best, Fenwick Associate Professor, Communication Studies Concordia University http://www.fenwickmckelvey.com _______ internet-history mailing list internet-history at postel.org http://mailman.postel.org/mailman/listinfo/internet-history Contact list-owner at postel.org for assistance. _______ internet-history mailing list internet-history at postel.org http://mailman.postel.org/mailman/listinfo/internet-history Contact list-owner at postel.org for assistance. -- New postal address: Google 1875 Explorer Street, 10th Floor Reston, VA 20190 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vint at google.com Thu Jan 24 20:02:04 2019 From: vint at google.com (Vint Cerf) Date: Thu, 24 Jan 2019 23:02:04 -0500 Subject: [ih] New journal article on IMPs, modems and gateways In-Reply-To: <1548387670744.306@concordia.ca> References: <1548387670744.306@concordia.ca> Message-ID: yes that is the repot- i see I was off by a couple of years! It was requested by DARPA and we offered a way to distribute ownership of the ARPANET but ARPA rejected the idea and handed control to DCA in 1975. v On Thu, Jan 24, 2019 at 10:41 PM Fenwick Mckelvey < fenwick.mckelvey at concordia.ca> wrote: > Hi all, > > Thanks Alex for the comments. I really appreciate the 'nit-picky'-ness. We > posted the article on the list to get feedback, so the comments are > wonderful. I'll reply in-line. > > > 1. We struggled when writing the paper about how serious AT&T considered > taking over ARPANET. We eventually cut this argument, because it was beyond > its scope and we didn't have a clear opinion. Howard Frank's quote at the > start of the paper suggests there were meeting that didn't go anywhere. In > JCR Licklider's archive, I found a mention that AT&T didn't like the idea > of taking over the ARPANET because of privacy, but I could never check or > qualify the comment. For discussion, the note was a summary of a panel > discussion on National Networks held at the Interuniversity Communication > Council Annual Meeting on 15 October 1970. It noted that AT&T did not want > to take ownership of ARPANET because its design violated the company?s > privacy obligations as a common carrier. A summary of the panel states, > "the design of the IMPs creates a special security problem. On its way from > the sender to the recipient, data pass through an IMP in the possession of > a third party, who has access to it. The carrier traditionally has > responsibility for the security of transmission; thus AT&T find the current > situation unacceptable". I never found any more details or context for that > quote. > > > 2. Agreed, that sentence is unclear. We're not claiming ARPANET's design > led to the break up of AT&T. We're providing some context about the > broader movement toward decentralization and markets not ARPANET itself. > > > 3. I'll look into how I can revise that description. Much appreciated. > Reading the old documentation is great, but it can be a challenge to > interpret. > > > Vint, are you referring to the ARPANET: A Management Study: > https://apps.dtic.mil/dtic/tr/fulltext/u2/777747.pdf You given some > context, but I'd welcome any more details. > > > Best, > Fenwick McKelvey > http://www.fenwickmckelvey.com > > Associate Professor, Communication Studies, Concordia University > > Director of the Algorithmic Media Observatory > http://www.amo-oma.ca/en/ > > Member of the Center for the Study of Democratic Citizenship > http://csdc-cecd.ca/ > ------------------------------ > *From:* Vint Cerf > *Sent:* Thursday, January 24, 2019 9:54 PM > *To:* Alex McKenzie > *Cc:* Fenwick Mckelvey; kdriscoll at virginia.edu; > internet-history at postel.org > *Subject:* Re: [ih] New journal article on IMPs, modems and gateways > > AT&T was not approached to take over the ARPANET as far as I know - they > were invited to participate in it and declined. > Around 1972 Paul Baran and I did a study for ARPA about distributing its > IMP assets to various parties rather than making > it monolithic. ARPA declined that idea. Eventually it was handed to DCA in > 1975 to operate as a service. > > Bell Labs was interested in its own Bell Data Network design but not > interested in taking over ARPANET. > > v > > > > On Thu, Jan 24, 2019 at 7:43 PM Alex McKenzie > wrote: > >> Fenwick, >> >> Thank you for posting the pointer to this article to the Internet History >> list. I've finally had a chance to read it, and I have a few comments. >> >> 1. Your paper investigates ARPANET IMPs (and internet gateways) as >> boundary devices, insulating two technical spheres ("computer people" and >> "telephone people") from each other. This, in my opinion, is absolutely >> correct. But then you go on to suggest that these two spheres are not >> really so distinct, and that "it was not inconceivable that control of the >> publicly-funded ARPANET would be transferred to the national >> telecommunications monopoly. ... While it is unclear how seriously AT&T >> considered taking over ARPANET." I believe that AT&T DID seriously >> consider taking over ARPANET and firmly rejected the idea as of no >> practical interest to their mission. For example, in the Computer History >> Museum transcript of an interview with Dr. Lawrence "Larry" Roberts [ >> https://archive.computerhistory.org/resources/access/text/2013/04/102746626-05-01-acc.pdf], >> page 14, Larry says about AT&T: "They were formally approached. The >> Washington division was excited. They said to me there was a lot of >> revenue they were getting from the leased lines; they thought it was great. >> They got excited about it, and Bell Labs got involved, and they had a >> huge committee, and I presume they went over and over it, and they kept >> on looking at it, and eventually -- they never gave a response, because >> that was their way of doing business, but I found out that Bell Labs had >> said: 'No, it was not compatible with the plan.' " I understand this >> to mean that leasing lines with data modems was within the plan, but >> actually fussing with any of the data going over the lines was outside the >> plan. This seems to me entirely consistent with the AT&T philosophy of >> "carrying signals is our business, understanding the signals is NOT our >> business." >> >> 2. On page 14 you suggest that the "market-oriented logic" of the >> internet concept led to the break-up of the Bell monopoly. I believe this >> is incorrect. I believe AT&T proposed the break-up (to the court hearing a >> US Department of Justice lawsuit for antitrust violations against AT&T) as >> a strategy to avoid losing its anti-trust case. I do not believe the logic >> of the internet design had anything to do with the outcome of this case. >> Can you cite any evidence to support your viewpoint? >> >> 3. Your description of the TIP (page 8) is slightly incorrect. The TIP >> had 64 ports, but due to a program limitation only 63 of the ports could be >> used. Any port could be connected to either a modem or a directly-wired >> terminal. Your description suggests that at most 16 modems could be >> connected, but in fact 63 modems could be connected (if there were no >> directly-connected terminals) but this never happened. The directly-wired >> devices were not restricted to "teleprinter or video terminals"; some TIPs >> had line printers or other non-interactive devices attached to some ports. >> >> I know this is all a bit pedantic and nit-picky, but I hate to have the >> historical record distorted by misunderstandings in the printed literature. >> >> Sincerely, >> Alex McKenzie >> BBN 1967-1996 >> >> >> >> On Sun, Jan 6, 2019 at 10:44 PM Fenwick Mckelvey < >> fenwick.mckelvey at concordia.ca> wrote: >> >>> Hi, >>> >>> Kevin Driscoll and I are happy to share our new article on the interface >>> message processor, modems and gateways published in the special issue on >>> ARPANET in the Internet Histories journal. >>> >>> >>> >>> You can view the article for free at: >>> https://www.tandfonline.com/eprint/yMkaE54yuIerwcwViDnE/full >>> >>> >>> >>> Our article focuses on the IMP?s relation to the telephone system ? all >>> its work connecting nodes through long lines and modems ? and to the >>> history of gateways. We hope the article inspires more interest in our >>> fields on gateways and other devices at the margins that connected computer >>> networks over the years. As media historians, we are hoping to collect more >>> examples, especially specific gateways, and welcome suggestions of where to >>> look next. >>> >>> >>> >>> For me, the article was also a chance to focus more on IMPs in context, >>> building on some insights from my new book Internet Daemons, >>> http://internetdaemons.com. >>> >>> >>> >>> If you have any questions or comments, we?d love to hear them. >>> >>> >>> >>> Finally, a big thanks to Dave Walden for his feedback in writing this >>> manuscript. His website, book and comments made this publication possible. >>> All our errors are our own. >>> >>> >>> >>> Hope you enoy! >>> >>> >>> >>> Best, >>> >>> Fenwick >>> >>> Associate Professor, Communication Studies >>> >>> Concordia University >>> >>> http://www.fenwickmckelvey.com >>> >>> >>> >>> >>> _______ >>> internet-history mailing list >>> internet-history at postel.org >>> http://mailman.postel.org/mailman/listinfo/internet-history >>> Contact list-owner at postel.org for assistance. >>> >> _______ >> internet-history mailing list >> internet-history at postel.org >> http://mailman.postel.org/mailman/listinfo/internet-history >> Contact list-owner at postel.org for assistance. >> > > > -- > New postal address: > Google > 1875 Explorer Street, 10th Floor > Reston, VA 20190 > -- New postal address: Google 1875 Explorer Street, 10th Floor Reston, VA 20190 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Fri Jan 25 05:23:04 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 25 Jan 2019 08:23:04 -0500 (EST) Subject: [ih] New journal article on IMPs, modems and gateways Message-ID: <20190125132304.2527418C0A9@mercury.lcs.mit.edu> > From: Alex McKenzie > The directly-wired devices were not restricted to "teleprinter or video > terminals"; some TIPs had line printers or other non-interactive devices > attached to some ports. Wow, that brings back some memories! The 5th-floor line-printer at Tech Sq was connected to an TIP port, and the print spooler on MIT-Multics knew how to connect to it and print things on it. Didn't work great, but it kinda worked. When we brought up Unix V6 on an -11/40 for early TCP/IP work, we connected the printer to it too, with an A/B switch. One had to run in, and flip the switch, but at least the people on the -11 had hardcopy! Once we finally got Internet (ARPANET) connectivity (which took a long time), we quickly converted things so the -11 controlled the printer (freeing the TIP port :-); Multics was changed to use TFTP (! - no TCP on the Unix yet) to print things. (It TFTP'd the file to be printed, and then a request file, into the spooler directory on the Unix machine; that required zero changes to the software on it, other than the TFTP server.) That was the very first operational application of IP internetting at MIT. Noel From bortzmeyer at nic.fr Fri Jan 25 08:24:20 2019 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 25 Jan 2019 17:24:20 +0100 Subject: [ih] Scans of early RFCs Message-ID: <20190125162420.GA26241@laperouse.bortzmeyer.org> https://write.as/365-rfcs/update-scans-of-early-rfcs "The Computer History Museum has just this month made the scans of RFCs 1 through 9 available!"