<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Dear All,<div><br></div><div>I am glad to see Ian Peter's article on "Lessons to be learned from Internet history."<div>Just preserving it, as you all are doing so thoroughly, is an important function, not to mention lessons that might be learned.</div><div>FYI, saving Internet History came up for discussion in Geneva in April this year, and is finally culminating in a History BOF at the upcoming IETF meeting in Orlando, Fl in March.</div><div>The BOF is being held:</div><div><div><br></div></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>IETF 86 Meeting </div><div><span class="Apple-tab-span" style="white-space:pre">        </span>Caribe Royale</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>8101 World Center Drive</div><div><span class="Apple-tab-span" style="white-space:pre">      </span>Orlando, FL</div><div><span class="Apple-tab-span" style="white-space:pre">  </span>Tel:  +1 407-238-8000</div><div><span class="Apple-tab-span" style="white-space:pre">   </span></div><div><span class="Apple-tab-span" style="white-space:pre">             </span>Monday, March 11, 2013</div><div><span class="Apple-tab-span" style="white-space:pre">               </span>1540-1710 pm, in room Carribean 1</div><div><span class="Apple-tab-span" style="white-space:pre">    </span></div><div><span class="Apple-tab-span" style="white-space:pre">     </span><a href="https://datatracker.ietf.org/meeting/86/agenda.html">https://datatracker.ietf.org/meeting/86/agenda.html</a></div><div><br></div><div>Marc Weber of the Computer History Museum here in Mountain View, CA has agreed to serve as Coordinator</div><div>Please come by if you are attending the meeting, or pass the word to those who will be there.</div><div><br></div><div>As a first step we would just like to identify who is seriously collecting Internet history, the extent of their collections, where located, and how best to interact with them if one has a donation of archives or artifacts - a kind of Internet History FYI or resource document.  Some of the major contributors/collectors, such as yourselves, are well known.   However, this is not necessarily true in Africa, Asia, the Middle East, and South America where so much is happening.  If you have contacts in these regions, please make them aware of the BOF.  We welcome their participation.</div><div><br></div><div>As we quickly transition from a paper world to a digital one, the question is will we build the Tower of Babel or the Great Library at Alexandria, Internet style?</div><div>Much work is now being done, but much is yet to come.  Very exciting stuff with no end of interesting problems to solve.!</div><div><br></div><div>Regards,</div><div><br></div><div>Jake Feinler</div><div>-------</div><div><br></div><div><div><blockquote type="cite"><div>Send internet-history mailing list submissions to<br><span class="Apple-tab-span" style="white-space:pre">        </span><a href="mailto:internet-history@postel.org">internet-history@postel.org</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br><span class="Apple-tab-span" style="white-space:pre">   </span>http://mailman.postel.org/mailman/listinfo/internet-history<br>or, via email, send a message with subject or body 'help' to<br><span class="Apple-tab-span" style="white-space:pre"> </span>internet-history-request@postel.org<br><br>You can reach the person managing the list at<br><span class="Apple-tab-span" style="white-space:pre">      </span>internet-history-owner@postel.org<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of internet-history digest..."<br><br><br>Today's Topics:<br><br>   1. Lessons to be learnt from Internet history (Ian Peter)<br>   2. Re: The story of BGP? (Noel Chiappa)<br>   3. Re: The story of BGP? (Noel Chiappa)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Sun, 10 Feb 2013 09:17:29 +1100<br>From: "Ian Peter" <ian.peter@ianpeter.com><br>Subject: [ih] Lessons to be learnt from Internet history<br>To: <internet-history@postel.org><br>Message-ID: <6B7D7170BF0B4BA6924309407E8D959C@Toshiba><br>Content-Type: text/plain; format=flowed; charset="iso-8859-1";<br><span class="Apple-tab-span" style="white-space:pre">  </span>reply-type=original<br><br>John Curran's comments below are leading me to think it would be worthwhile <br>to document some major lessons which can be learnt from Internet history. <br>Elsewhere, there are substantial efforts underway to define Internet Rights <br>and Principles, Internet Core Values etc, and these efforts hopefully will <br>be useful in internet governance evolution.<br><br>So what lessons could be learnt from Internet history which could inform <br>these efforts?  I'm happy to suggest a couple to get the ball rolling, but I <br>am sure there are many others.<br><br>Here's my start.<br><br>1. Think long term.<br><br>Plenty of examples discussed here (good and bad). We need to plan for an <br>Internet that is around forever, not for a quick fix that patches an <br>immediate problem while giving rise to longer term problems.<br><br>2. Keep it open.<br><br>Nothing demonstrates this more to me than the difference between an open <br>platform such as the World Wide Web and a proprietary application such as <br>Facebook (the latter now becoming a defacto Internet to a younger generation <br>whose only "Internet" access is via mobile apps). This proprietary ownership <br>raises a series of issues around privacy, access, rights, and jurisdiction <br>which are quite different on a open platform.<br><br>Anyway, that's a start. I am sure there are others and a couple are in my <br>mind as I write. But I would be interested to hear from this list as regards <br>the lessons which either have been learnt, or should have been learnt, from <br>Internet history thus far.<br><br>Ian Peter<br><br><br><br><br><br><br>Message: 2<br>Date: Fri, 8 Feb 2013 19:53:38 -0500<br>From: John Curran <jcurran@istaff.org><br>Subject: Re: [ih] The story of BGP?<br>To: Craig Partridge <craig@aland.bbn.com><br>Cc: internet-history@postel.org, Noel Chiappa<br><jnc@mercury.lcs.mit.edu><br>Message-ID: <7B5ECA4D-28BC-4E20-96A3-48D096519426@istaff.org><br>Content-Type: text/plain; charset=us-ascii<br><br>On Feb 8, 2013, at 7:14 PM, Craig Partridge <craig@aland.bbn.com> wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite">This doing it right long term versus doing something that solved an <br></blockquote><blockquote type="cite">immediate<br></blockquote><blockquote type="cite">need issue shows up repeatedly in IETF behavior the period 1989-1994 or <br></blockquote><blockquote type="cite">so.<br></blockquote><blockquote type="cite">Routing was one.  Network Management was another.  8-bit Email nearly got<br></blockquote><blockquote type="cite">wrapped around the axle too.<br></blockquote><br>"IPv4 to IPng" has definitely earned a spot on that list; we solved the<br>apparent immediate need, and decided not to undertake a loc-id split nor<br>variable/path-based locators.  I probably could live with this tradeoff<br>for getting it done fast, but we actually didn't get it done, instead<br>leaving transition out of the spec for the next generation and not even<br>getting any actual backward compatibility with IPv4 as a result.<br><br>If we're not going to "do it right for the long-term", it's kinda important<br>that we nail getting the "immediate" solution right...<br><br>/John<br><br>Disclaimer:  My $.02; YMMV.<br><br><br><br><br><br><br>------------------------------<br><br>Message: 2<br>Date: Sun, 10 Feb 2013 09:07:36 -0500 (EST)<br>From: jnc@mercury.lcs.mit.edu (Noel Chiappa)<br>Subject: Re: [ih] The story of BGP?<br>To: internet-history@postel.org, justine@eecs.berkeley.edu<br>Cc: jnc@mercury.lcs.mit.edu<br>Message-ID: <20130210140736.57CAC18C12A@mercury.lcs.mit.edu><br><br><blockquote type="cite">From: Tony Li <tony.li@tony.li<br></blockquote><br><blockquote type="cite"><blockquote type="cite">I'm not sure where 1994 comes from (that's the date on BGP-4, is that<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">it?), but it's wrong.<br></blockquote></blockquote><br><blockquote type="cite">The transition was more in the '91-'93 window. The urgency to publish<br></blockquote><blockquote type="cite">the RFC was far lower tha n the need to have working code and a working<br></blockquote><blockquote type="cite">network.<br></blockquote><br>Are you talking about the transition to BGP-4, or the transition to BGP? My<br>comment was about the transition to use of BGP, which my memory (perhaps<br>falsely) indicated had gotten a fair amount of use quite quickly.<br><br>However, it sounds like I may have relied too heavily on the RFC dates, and<br>that BGP came along much more slowly than that?<br><br><br><blockquote type="cite"><blockquote type="cite">Was the shutdown of the ARPAnet a big factor?<br></blockquote></blockquote><br><blockquote type="cite">Absolutely.<br></blockquote><br>I'm trying to see how this can be?<br><br>As far I as can work out, the need to move to something better than EGP was<br>driven by the growth of the network (growth both in terms of number of total<br>destinations, as well as the richness of the inter-connections), and that<br>growth was not driven in any way by the ARPANET (or its demise).<br><br>Rather, the growth was driven by the deployment of LAN technologies (which<br>provide very high speeds), and the increasing numbers of smaller machines<br>(initially mini-computers, and then personal machines), which provided a need<br>for LANs (and hence for the growth in the number of destinations). There was,<br>slightly later on, a parallel evolution in transmission technology (i.e.<br>fiber), which drove inter-connection richness (and higher long-distance<br>speeds).<br><br>(Simply speeding up the ARPANET, to avoid the growth of the alternate<br>backbones, was not an option. The ARPANET's whole architecture was just not<br>suitable for high speeds. In particular, the 8-outstanding-packet limit would<br>have been a killer - particularly as all IP traffic shared one 'link'.)<br><br>As far as I can see, the ARPANET was only important as the first<br>long-distance backbone, to tie together all the disparate sites - and thus<br>the need for a protocol family which could handle such a large network<br>(unlike other early protocol families like PUP and CHAOS, which were clearly<br>single-site oriented, although they eventually were used in slightly larger<br>contexts).<br><br>As best I can recall, when the ARPANET was finally turned off (after a long<br>process of shrinkage) it was pretty much a non-event, as was the process of<br>shrinkage - people just signed up with regionals - which had originally been<br>set up to serve those people who couldn't get on the ARPANET.<br><br><blockquote type="cite">The creation of the NSFnet regionals added thousands of prefixes to the<br></blockquote><blockquote type="cite">routing tables very quickly, causing EGP updates to grow rapidly.<br></blockquote><blockquote type="cite">...<br></blockquote><blockquote type="cite">This pain became obvious to everyone, and was coupled with the<br></blockquote><blockquote type="cite">significant pain of route filtering that had to be used to prevent the<br></blockquote><blockquote type="cite">looping that has already been discussed.<br></blockquote><br>All true, but this had nothing to do with the existence, or non-existence, of<br>the ARPANET (see above).<br><br><span class="Apple-tab-span" style="white-space:pre">     </span>Noel<br><br><br>------------------------------<br><br>Message: 3<br>Date: Sun, 10 Feb 2013 09:29:39 -0500 (EST)<br>From: jnc@mercury.lcs.mit.edu (Noel Chiappa)<br>Subject: Re: [ih] The story of BGP?<br>To: internet-history@postel.org<br>Cc: justine@eecs.berkeley.edu, jnc@mercury.lcs.mit.edu<br>Message-ID: <20130210142939.E0DB818C12A@mercury.lcs.mit.edu><br><br><blockquote type="cite">From: Guy Almes <galmes@tamu.edu><br></blockquote><br><blockquote type="cite">we were asked in 1988 to comment on a then-draft spec for a successor<br></blockquote><blockquote type="cite">to EGP2, viz. EGP3. EGP3 was, in many ways, well done and it was<br></blockquote><blockquote type="cite">incremental and thus might have scaled well with regard to the rapidly<br></blockquote><blockquote type="cite">growing number of networks.<br></blockquote><blockquote type="cite">But EGP3 remained 'flat' in the sense above.<br></blockquote><br>If this is true, it probably explains why EGP3 never got much traction.<br><br>I wish I had a later EGP3 draft spec to confirm this - I'm looking through my<br>pile of paper (and actually organizing and cataloging it!), but so far, no<br>luck.<br><br>I suspect that's why I went off to do FGP - I suspect I could see the need to<br>support cycles in the topology coming soon. (Proteon was heavily involved in<br>selling to the regionals, and tried to sell to the NSF backbone, so we knew a<br>lot about what they were all up to.)<br><br><br>And speaking of FGP, while setting up to file the stuff I was organizing, I<br>ran across a (thin!) folder labelled "FGP"! I won't bore you all with all the<br>details, but a few useful tidbits.<br><br>It does appear to date from the end of 1986; I see an email from Hans-Werner<br>Braun from October 1986, and a Proteon memo about a potential contract from<br>November, 1986. We had apparently discussed it with "Steve" at NSF (Steve<br>Wolff, I assume), to see if we could get money out of them to support the<br>effort, and Scott Brim had offered a chunk of money from NYSRENET.<br><br>A short (3-page) design note which I wrote indicates that it had the<br>following goals:<br><br>- Ability to handle a larger Internet<br>- Cycles - no topology restrictions<br>- Quick adaption to topology changes<br>- No counting to infinity<br>- Low overhead - updates not transmitted every N seconds<br>- Better metric than just hop-count<br><br>Actually, I guess the design note is of some interest, as it reveals how<br>limited my/our understanding of routing was at that date. It's clearly a<br>whole order of magnitude (or more) less advanced than Nimrod. But I<br>digress..:-)<br><br>Anyway, one other item of interest in the file is a timeline chart for the<br>proposed contract/effort. It shows things like 'Requirements [definition, I<br>asssume]', in December, 1986, 'Spec writing' in Feb/March 1987,<br>implementations in May/June, 'Trials' in June/July, 'Spec update' in August,<br>and 'Spec relase' in September.<br><br>Probably a little optimistic on the schedule... :-)<br><br><span class="Apple-tab-span" style="white-space:pre">     </span>Noel<br><br><br>------------------------------<br><br>_______________________________________________<br>internet-history mailing list<br>internet-history@postel.org<br>http://mailman.postel.org/mailman/listinfo/internet-history<br><br><br>End of internet-history Digest, Vol 71, Issue 8<br>***********************************************<br></div></blockquote></div><br></div></div></body></html>