From amckenzie3 at yahoo.com Wed Jul 3 07:50:01 2013 From: amckenzie3 at yahoo.com (Alex McKenzie) Date: Wed, 3 Jul 2013 07:50:01 -0700 (PDT) Subject: [ih] BBN Internet Engineering Timeline Message-ID: <1372863001.69135.YahooMailNeo@web142406.mail.bf1.yahoo.com> Some former BBN employees, including me, have been working on a timeline of BBN activities in Internet Engineering.? This is an entirely BBN-centric effort; it does not attempt to include any of the myrid important contributions of the hundreds of other people and organizations involved with nurturing and creating the Internet. It has no official connection with any of the companies called BBN. It may be of interest to some of you.? It can be found at: http://xbbn.weebly.com/bbn-internet-engineering-timeline.html Cheers, Alex McKenzie BBN 1967-1996 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.n1vux at gmail.com Thu Jul 4 08:34:21 2013 From: bill.n1vux at gmail.com (Bill Ricker) Date: Thu, 4 Jul 2013 11:34:21 -0400 Subject: [ih] BBN Internet Engineering Timeline In-Reply-To: <1372863001.69135.YahooMailNeo@web142406.mail.bf1.yahoo.com> References: <1372863001.69135.YahooMailNeo@web142406.mail.bf1.yahoo.com> Message-ID: Alex, Thanks for sharing and for including disclaimer on the focus. Two questions. Do you have, and if not would you like, a copy of the Ted Kennedy telegram taped to the side of IMP#1 congratulating BBN on the Inter-Faith Message Processor ? (Is this the first Cupertino?) Second, do you or your co-historians have any memory or records of the original MALT-L or MALTS-L scotch collectors (D)ARPAnet e-mail list? I believe it was co-founded in the late 70's or early 80's by Padlipsky and a BBNnik and hosted at BBN until moved to U Edinborough when it was deemed too frivolous. -- Bill @n1vux bill.n1vux at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From detlef.bosau at web.de Tue Jul 16 08:55:00 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 16 Jul 2013 17:55:00 +0200 Subject: [ih] Why was hop by hop flow control eventually abandonded? Message-ID: <51E56CD4.4020008@web.de> I'm still to understand this decision. The more I think about it, the more I fear, that although the decision to abandon hop by hop flow control (which is still in Vint Cerf's catenet paper but is abandoned in RFC 791) may be the most seminal generator for PhD theses in the history of science, on the one hand, however I'm not quite sure whether this was one of the largest fallacies ever. Actually, the VJCC kludge turned to be quite successful up to now, however VJ himself admits some basic limitations in his well known talk "A New Way to look at Networking". Does anyone happen to know, whether this was decision for a concrete reason and the rational behind it? Or did this "simply happen"? -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From jtk at depaul.edu Tue Jul 16 10:35:45 2013 From: jtk at depaul.edu (John Kristoff) Date: Tue, 16 Jul 2013 12:35:45 -0500 Subject: [ih] Why was hop by hop flow control eventually abandonded? In-Reply-To: <51E56CD4.4020008@web.de> References: <51E56CD4.4020008@web.de> Message-ID: <20130716173545.GD12561@aharp.iorc.depaul.edu> On Tue, Jul 16, 2013 at 05:55:00PM +0200, Detlef Bosau wrote: > The more I think about it, the more I fear, that although the decision > to abandon hop by hop flow control [...] That was well before my time, but arguably versions of independent per-hop control has been attempted, if not widely implemented since then. Isn't a great deal of the CoS (aka, QoS) work, usually done with those magic few bits in the IP header, later finalized as DiffServ, a descadent form? In addition, much of the work on router queue management, usually done on a packet independent basis such as rudimentary implementations of RED do this as well, augmented with ECN signallying. Further, isn't much of the renewed interest in so-called "buffer bloat" a related area of work. It should seem like a small miracle, if not a bit scary, that the end host based flow and congestion control we have works as well as it does in this hugely autonomous system of networks and hosts. John From brian.e.carpenter at gmail.com Wed Jul 17 21:44:46 2013 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Thu, 18 Jul 2013 16:44:46 +1200 Subject: [ih] Why was hop by hop flow control eventually abandonded? In-Reply-To: <20130716173545.GD12561@aharp.iorc.depaul.edu> References: <51E56CD4.4020008@web.de> <20130716173545.GD12561@aharp.iorc.depaul.edu> Message-ID: <51E772BE.1030409@gmail.com> On 17/07/2013 05:35, John Kristoff wrote: > On Tue, Jul 16, 2013 at 05:55:00PM +0200, Detlef Bosau wrote: > >> The more I think about it, the more I fear, that although the decision >> to abandon hop by hop flow control Could somebody who was there at the time comment on whether the e2e argument (in its 1984 Saltzer et al form) was already part of the discussion then, or if it was a post hoc argument? Brian From jack at 3kitty.org Wed Jul 17 22:07:18 2013 From: jack at 3kitty.org (Jack Haverty) Date: Wed, 17 Jul 2013 22:07:18 -0700 Subject: [ih] Why was hop by hop flow control eventually abandonded? In-Reply-To: <51E56CD4.4020008@web.de> References: <51E56CD4.4020008@web.de> Message-ID: Well, I'll break the silence here and toss in my two cents (or pfennig or whatever)... There was a small group of people involved in creating the first implemerntations of TCP/IP, back in the 1977/78/79 timeframe. This was when TCP/IP evolved from TCP 2.x to TCP 4, with a lot of intermediate stages over a very short time. TCP 4 remains pretty much the same today. I was working at BBN and my assignment at the time was to be the implementer of the Unix TCP/IP. So I was in the email discussions, meetings, late-night napkin sessions at the hotel bars, etc. when a lot of such "decisions" were "made" - I'll get to that in a bit... This was the timeframe when some relatively major refinements were made to TCP, e.g., the separation of the TCP and IP headers. There was a lot of discussion about other mechanisms as well -- addressing, the creation of the "options" mechanism, the shift from "record-oriented" to "byte-stream" behavior (removal of the "rubber EOL" mechanism), and many others, including flow control. At the time, there were two schools of thought. The traditional methods of network internals incorporated rather strict control mechanisms within the network. For example, the ARPANET (almost ten years old then), was a "datagram network" at its periphery where the hosts interfaced, but if you looked at the actual internal mechanisms you'd see lots of resource management - flow control (RFNMs), memory management (ALLOCs), etc. That's the world where techniques like hop-by-hop flow control fit in naturally. The ARPANET was called a "datagram network", but if you looked just inside the shell you'd find virtual circuit stuff. The other school of thought, relatively new, was the "datagram" crowd, who said that a new way to design the internals of a network would be to take a hands-off approach and just send individual, independent, chunks of data into the system, and trust that enough would somehow survive and come out the other end to be useful. Of course, internally you could do hop-by-hop flow control in either a strict or loose fashion. You could do anything you wanted, as long as you delivered some packets out the other end. Good environmentj for experimentation. But there was another issue, namely the desire (especially from the guys paying the bills) to transmit data for which getting most of the data there quickly was more important than getting all of the data there eventually. This was motivated by the desire to send real-time material, i.e., voice, video, etc., where you could tolerate losing a few chunks of data and still get intelligible audio/video, but you couldn't tolerate getting no packets because they were held up as some internal control mechanism operated to get them all delivered intact, but possibly delayed a while. That desire meant that the internal mechanisms had to provide a way to send data in a "get as much of this data as you can from here to there, but get it there quickly" fashion. This argued against mechanisms such as hop-by-hop flow control, memory/buffer management schemes, and other typical "virtual circuit" mechanisms, since they would tend to delay data in order to make sure it all got delivered intact. That led to the split of the TCP and IP headers, which enabled the definition of UDP, which provided a basis for experimenting with voice and video. Of course there were some of us (guilty!) who said "Wait, we don't know how to do that. We do know how to do it with mechanisms like the ARPANET has been using since 1970 or so. Let's do it that way." The ARPANET did have a "datagram service" that hosts could use, called (IIRC) "Uncontrolled Packets", which would be sent through the ARPANET bypassing all of the internal virtual circuit machinery. However, to utilize that service, a Host had to get special permission, and the ARPANET NOC had to enable it in the specific IMPs involved, for the duration of the experiment. BBN was pretty reluctant to do that, since it wasn't clear what effect injecting such packets would have on the rest of the network traffic at the time. It could conceivably bring the whole network down. No one really knew. So it was rarely made available. The ARPANET had become an operational service. It was no longer an Experiment. The other somewhat unusual input to the decisions was from the nature of the people paying for the whole thing -- ARPA. ARPA's charter was to do leading-edge research (that's what the first A is for -- Advanced Research Projects Agency), and it was actually somehow politically embarassing to have too many successes. If you always win, it means you're not taking enough risks. So there was an implicit philosophy to do things in a new untried way, rather than in an old proven way. We pretty much knew we could do TCP/IP with a "virtual-circuit" approach (and proven mechanisms such as hop-by-hop flow control). We very much did not know if it was possible to build a workable, reliable system using the untried "datagram" philosophy of Anarchic Networking (you heard it here first!). Since the untried approach was riskier, that fit into the ARPA charter best. Since there was a strong desire to support voice and video, and in particular interactive multimedia, that seemed to be difficult with the controlled philosophy because of the delay issue. We of course didn't know that it would ever work in the "Anarchic Networking" schemes either, but that of course also fit into the "risk taker" category. Thinking back on it, I think those effects were the primary drivers of the decisions, including the abandonment of hop-by-hop flow control. Also, I don't recall *anything* that you might call a rigorous mathematical analysis and comparison of different techniques, or simulations, etc., etc., Those decisions were not made by anything remotely resembling rigorous scientific process. Remember also, that world at the time operated very much in conformance with the mantra of Jon Postel -- "rough consensus and running code". Rough consensus. Not decisions. So, I don't think there ever was an explicit "decision", or at least none that I remember. We just kept writing code and trying out different ideas (Dave Mills was especially prolific and creative in trying things that had never been tried before, and wreaking havoc with the gateways that my group at BBN was responsible for (the so-called "core gateways")) Out of all that came TCP4. Another interesting situation at the time... The neonatal Internet looked very much like a "fuzzy peach" model, where the peach was the ARPANET (and maybe SATNET too), and the "fuzz" were various peripheral networks and hosts. All of the people involved in implementing TCP were "host" people, i.e,. they were writing code that ran in some kind of box that attached to the ARPANET. Even at BBN, there were a handful of us doing TCP implementations, none of whom were "ARPANET guys", i.e., working also on IMP code. So, when a bunch of "host guys" try to "decide" how to implement something, guess where they're most likely to put the mechanisms that need to be built -- in the Hosts that they can write the code for, of course! There was a lot of experimentation and new ideas tried and tweaked until things more or less worked. My group at BBN had responsibility for the "operational" part of the initial Internet (Bob Hinden and others), so we probably experienced the brunt of the experimental fallout. A good example -- we knew we needed some kind of flow control mechanism, so the "Source Quench" mechanism was invented. The idea was that when a gateway got into trouble and had to discard a packet, it would send a "Source Quench" back to the source of that packet, telling it to "slow down". But no one could say what that meant exactly. If your TCP sends its first packet and receives a Source Quench back, exactly what should it do to "slow down"? Of course, as a Host implementer of a TCP, you were supposed to somehow "slow down" in whatever way you could. But another perfectly accurate way to interpret that Source Quench was as a message from the gateway informing you that it had definitely thrown away your precious packet. Slow down? Not on your life! Send that packet again! Immediately! The Packets Must Go Through. (Dave Mills, are you listening? I haven't forgotten....) Such was the experimentation in datagram flow control.... So, in retrospect, I doubt there was ever an explicit decision to choose to abandon hop-by-hop flow control. It's more that there was a rough consensus to try with absolutely minimal internal machinery (even so, IIRC the first gateways had room after all the code for only a single packet buffer!). So the minimalist code got written and tried out, and whatever didn't work triggered more discussion and consensus about something else to add (Van Jacobson's seminal work on TCP behavior seems to fit into that category) I must admit, I was one of the skeptics who didn't think a pure datagram approach was going to work, especially as you increased traffic to the point where resources got tight. It might work for a while, but it "wouldn't scale". Well, it's 2013, and I've heard there's something like 2 billion people using this beast. I was wrong, like many others. How much "scale" do you want? Hope this helps, /Jack Haverty On Tue, Jul 16, 2013 at 8:55 AM, Detlef Bosau wrote: > I'm still to understand this decision. The more I think about it, the more > I fear, that although the decision to abandon hop by hop flow control > (which is still in Vint Cerf's catenet paper but is abandoned in RFC 791) > may be the most seminal generator for PhD theses in the history of science, > on the one hand, however I'm not quite sure whether this was one of the > largest fallacies ever. > > Actually, the VJCC kludge turned to be quite successful up to now, however > VJ himself admits some basic limitations in his well known talk "A New Way > to look at Networking". > > Does anyone happen to know, whether this was decision for a concrete > reason and the rational behind it? Or did this "simply happen"? > > -- > ------------------------------**------------------------------**------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart Tel.: +49 711 5208031 > mobile: +49 172 6819937 > skype: detlef.bosau > ICQ: 566129673 > detlef.bosau at web.de http://www.detlef-bosau.de > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jack at 3kitty.org Fri Jul 19 18:15:52 2013 From: jack at 3kitty.org (Jack Haverty) Date: Fri, 19 Jul 2013 18:15:52 -0700 Subject: [ih] Why was hop by hop flow control eventually abandonded? In-Reply-To: <51E772BE.1030409@gmail.com> References: <51E56CD4.4020008@web.de> <20130716173545.GD12561@aharp.iorc.depaul.edu> <51E772BE.1030409@gmail.com> Message-ID: I guess I was "there at the time", so here's some thoughts...anybody else still around????? --------------------- In the late 70s/early 80s (pre-1984) there was a lot of discussion that involved a wide range of internal mechanisms for use in the early Internet. I don't recall that ever being organized at the time into any more formal "discipline" as described in Saltzer's paper. However, coauthors Dave Clark and Dave Reed were both also "there at the time", so it's likely that they took the experiences and discussions of the various brainstorming sessions involved in building that early Internet, and used those to sort out some more formal or broader principles of design for communications systems which appeared in the 1984 paper. I think most of those discussions never got written down. They occurred in email exchanges, or sessions at meetings, or around a table at a restaurant or bar. They were probably the primary driver to the "rough consensus" that was needed to get the Internet actually built and running. For example, there was at one point a general feeling that the basic service of the Internet should be the "best effort datagram" service, where the net simply tried to deliver as many datagrams as it could, but made no guarantees about what order, how long, or whether they would all get there at all. Then other services, like TCP's reliable-byte-stream, or the audio/video unreliable but undelayed bitstream, could be built on top of that basic service. Those discussions led to the "consensus" structure we see in TCP4, UDP, and IP. In that context, I remember discussions we had to try to figure out what mechanisms to implement. It wasn't done by exhaustive scientific analysis. E.G., one question was -- "How much datagram loss/corruption is acceptable as part of the normal service?" After much opining, someone just said 'How about 1%, that sounds reasonable?" and we all pretty much agreed since no one had any argument for a different number. Rough consensus. If you were seeing less than 1% datagram loss, things were working OK. There was also discussion of mechanisms for hop-by-hop transmissions. For example, it was obviously "bad" for a datagram to wend its way through a tortuous route only to get discarded because it was damaged in its final error-prone hop. So one option considered for use on individual error-prone hops was to put in some kind of ARQ scheme (Automatic ReQuest - the recipient on seeing a damaged datagram would immediately ask its neighbor to send it again). This kind of technique was used in the ARPANET environment, so it was part of the "let's do it the way we know works" philosophy. It was very difficult to come to consensus on any specific hop-hop mechanism that would be applicable everywhere. Different nets that gateways were communicating across had very different characteristics of errors, duplicating or reordering datagrams, etc. The "carrier pigeon net" was even discussed, as an extreme example. Yes, the Internet was actually designed to be able to utilize carrier pigeons as a component communications network if necessary. One datagram per leg, two legs per pigeon, with network performance measured in pps - pigeons per second. Bps was bits per pigeon. Kbps was too weird to imagine. (This was most likely at one of those late night sessions in the hotel bar....but the principle was a good one, anything that can carry a datagram should be usable) Of course, there were extreme constraints on the gateway hardware - not enough memory, processors too slow, etc., for anything fancy. So the only mechanisms that actually fit into the early hardware were the most simple ones. As I said before, we added mechanisms in response to problems that actually occurred. That was probably a basic, if unstated, design principle. Saltzer's paper describes an experience in an MIT network which motivated the inclusion of end-end error control, but that was a repeat of a similar earlier experience in the ARPANET where the checksum mechanisms on those error-prone phone lines was proved inadequate when a memory failure in one IMP caused widespread havoc one day when it corrupted a routing update. Later, the Internet architecture was pretty fundamentally restructured when we created EGP. (google "haverty kahn subway strap") That allowed the internet to be naturally composed not just of interconnected gateways, but of interconnected systems of independent gateways. This permitted different people/groups to pursue their own ideas about what kind of internal mechanisms to use (the so-call "IGP" or Internal Gateway Protocol" -- which wasn't restricted to routing although many people think of it that way). So if someone thought it was useful to put an ARQ mechanism to achieve desired reliability on hops, they could do so, inside their own autonomous system. This made experimentation with different ideas a lot easier, and better computers that became available made it feasible to play with other ideas that earlier were limited to thought experiments only. So, since Dave Clark was one of the first TCP implementers (he did Multics at the same time I was doing Unix TCP), and others in the MIT crew (e.g., Noel Chiappa) were also involved, I suspect all that experience got digested and fed into the 1984 "Saltzer et al form". These kinds of attempts to distill general principles from the crazy reality of early networks was an underlying theme. For example, see RFC 722 from 1976. The "end-end design principle" was important, and Saltzer/Reed/Clark captured it in words. But it was certainly discussed earlier. I remember that one of the notions that I promoted was that you had to carefully consider exactly where the "ends" really were. Most pieces of the TCP/IP datagram involve the host computers as the "ends", and that's the obvious way to think about it. But in reality some parts of datagram flows have one or more "ends" which are not at the hosts. For example, many IP header fields are intended for use by the gateways - so the gateway is actually one of the "ends" for that flow of information and that fact should be considered in designs. Vint told me at the time that I really should write that up -- well, here it is, only about 30 years later......oops. It is truly amazing that this stuff still works....! Hope this helps, /Jack Haverty On Wed, Jul 17, 2013 at 9:44 PM, Brian E Carpenter < brian.e.carpenter at gmail.com> wrote: > On 17/07/2013 05:35, John Kristoff wrote: > > On Tue, Jul 16, 2013 at 05:55:00PM +0200, Detlef Bosau wrote: > > > >> The more I think about it, the more I fear, that although the decision > >> to abandon hop by hop flow control > > Could somebody who was there at the time comment on whether the e2e > argument (in its 1984 Saltzer et al form) was already part of the > discussion then, or if it was a post hoc argument? > > Brian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Fri Jul 19 19:08:30 2013 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 19 Jul 2013 22:08:30 -0400 (EDT) Subject: [ih] Why was hop by hop flow control eventually abandonded? Message-ID: <20130720020830.2559B18C0E6@mercury.lcs.mit.edu> > From: Brian E Carpenter > Could somebody who was there at the time comment on whether the e2e > argument (in its 1984 Saltzer et al form) was already part of the > discussion then, or if it was a post hoc argument? To follow up on Jack's post, there were definitely instances of 'we talked about it at the time, but didn't write it down until later' back then. One good example is the 'fate-sharing' stuff - I distinctly recall first seeing that in a presentation that Dave Clark gave to some DoD people in the late 70s, but it didn't show up written in a paper until the 'Design Philosophy' paper, in 1988, about a decade later. As to the E2E argument: I personally don't recall that we had it in a very articulated form in the late 70s. Maybe some people had it in their heads (Dave Reed has indicated that he had it early on, and told others about it, and then Jerry decided it needed to be written up). However, I recall the SRC paper having a big impact on me when I read it, so I don't think I clearly understood the ideas in it until I read it. Noel From brian.e.carpenter at gmail.com Fri Jul 19 20:47:02 2013 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sat, 20 Jul 2013 15:47:02 +1200 Subject: [ih] Why was hop by hop flow control eventually abandonded? In-Reply-To: References: <51E56CD4.4020008@web.de> <20130716173545.GD12561@aharp.iorc.depaul.edu> <51E772BE.1030409@gmail.com> Message-ID: <51EA0836.5040802@gmail.com> > For example, many IP header > fields are intended for use by the gateways - so the gateway is actually > one of the "ends" for that flow of information and that fact should be > considered in designs. Vint told me at the time that I really should > write that up -- well, here it is, only about 30 years later......oops. Fascinating. fyi this relates to a current issue for the deployment of IPv6 - firewalls and load balancers need to inspect header fields that were designed specifically for end-host to end-host use. "Those who cannot remember the past are condemned to repeat it." Regards Brian Carpenter From jack at 3kitty.org Fri Jul 19 22:47:26 2013 From: jack at 3kitty.org (Jack Haverty) Date: Fri, 19 Jul 2013 22:47:26 -0700 Subject: [ih] Why was hop by hop flow control eventually abandonded? In-Reply-To: <51EA0836.5040802@gmail.com> References: <51E56CD4.4020008@web.de> <20130716173545.GD12561@aharp.iorc.depaul.edu> <51E772BE.1030409@gmail.com> <51EA0836.5040802@gmail.com> Message-ID: <51EA246E.2000106@3kitty.org> Hmmm. Maybe this was more important than I realized back then.... The basic idea was that for any chunk of information - bit, byte, field, header, etc., you need to identify the source of that information and also *all* of the consumers of that information. So a piece of data such as a field in an IP header is characterized both by its original source - wherever the contents were created, and by all of the destinations that in any way utilize that information. So some IP header field might get used not only by the host at the other end, but also by each of the gateways along the way -- anyone who looks at and uses that information in any way. So then *each* such information flow is a distinct end-end information flow. The communications mechanisms between any pair of ends must have the characteristics needed for that particular information flow - reliability, security, delay, privacy, integrity, etc. You need to put in mechanisms as needed to meet each flow's needs, so that the service it implements supports the needs of the other information flows. Something like a typical TCP connection thus actually involves a bunch of separate information flows among all of the players involved in performing that information transfer. So the aggregate characteristics of a TCP E2E information flow (reliability, delay, variance, integrity, etc.) depend on all of the characteristics of all the associated supporting information flows as well as what we think of as "the" end-to-end mechanisms themselves between hosts. I can see where firewalls and load balancers would be influenced by this. They need information to operate properly, so they are endpoints, as well as sources, of information flows. Headers are full of information that is intended for use by someone "along the way". Back in the 80s, I talked about this as "end-middle" communications - the notion that in addition to an end-end mechanism like the E2E TCP interactions, a bunch of end-middle communications flows were also involved in any TCP flow. So the whole system had to be designed to make everything work properly. This actually surfaced at one point when we realized that, no matter how robust the TCP/IP datagram transport service was, if the domain name system and servers weren't designed and operated properly, end-users wouldn't be able to open their telnet/ftp/mail connections -- since they relied on DNS to get the proper IP addresses. Similarly, if the gateway-gateway routing exchanges didn't work properly, nothing the TCPs could do would be able to compensate. Source quenches, whatever they accomplished, had to get to their destinations to have any effect. Etc. Etc. Better than "end-middle" is just to realize that the "middles" are just ends of other information flows. And all of the discipline of end-end mechanisms has to be applied there too, to each such E2E flow, regardless of where the End happens to be. I really should have written this down......it seems like it's important. Vint was right. /Jack Haverty On 07/19/2013 08:47 PM, Brian E Carpenter wrote: >> For example, many IP header >> fields are intended for use by the gateways - so the gateway is actually >> one of the "ends" for that flow of information and that fact should be >> considered in designs. Vint told me at the time that I really should >> write that up -- well, here it is, only about 30 years later......oops. > Fascinating. fyi this relates to a current issue for the > deployment of IPv6 - firewalls and load balancers need to > inspect header fields that were designed specifically for > end-host to end-host use. > > "Those who cannot remember the past are condemned to repeat it." > > Regards > Brian Carpenter From bortzmeyer at nic.fr Tue Jul 23 00:40:39 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 23 Jul 2013 09:40:39 +0200 Subject: [ih] History of .com seen by Verisign Message-ID: <20130723074039.GA6656@nic.fr> http://www.verisigninc.com/en_US/products-and-services/domain-names/com/what-does-com-mean/index.xhtml Note that the genesis of .com (and the names for the alternatives) is different from what Feinler told here From dhc2 at dcrocker.net Tue Jul 23 02:04:10 2013 From: dhc2 at dcrocker.net (Dave Crocker) Date: Tue, 23 Jul 2013 10:04:10 +0100 Subject: [ih] History of .com seen by Verisign In-Reply-To: <20130723074039.GA6656@nic.fr> References: <20130723074039.GA6656@nic.fr> Message-ID: <51EE470A.5090206@dcrocker.net> On 7/23/2013 8:40 AM, Stephane Bortzmeyer wrote: > http://www.verisigninc.com/en_US/products-and-services/domain-names/com/what-does-com-mean/index.xhtml > > Note that the genesis of .com (and the names for the alternatives) is > different from what Feinler told here > The Verisign article's attention to historical detail is nicely summarized by their using the term 'king' in place of the (numbers) czar term that was actually used. It's almost interesting to wonder whether casting the RFC Editor as "shaping" the Internet is reasonable phrasing... (We need to be careful to distinguish Jon's RFC Editor work from his many /non/-RFC activities, when considering this question.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From braden at isi.edu Tue Jul 23 13:11:30 2013 From: braden at isi.edu (Bob Braden) Date: Tue, 23 Jul 2013 13:11:30 -0700 Subject: [ih] internet-history Digest, Vol 76, Issue 6 In-Reply-To: References: Message-ID: <51EEE372.6040102@isi.edu> Dave Crocker wrote: ... It's almost interesting to wonder whether casting the RFC Editor as "shaping" the Internet is reasonable phrasing... (We need to be careful to distinguish Jon's RFC Editor work from his many /non/-RFC activities, when considering this question.) d/ Indeed. Besides his formal RFC Editor duties, Jon had the informal titles of "Protocol Czar", and "Guardian of Good [protocol] Taste". (Jon did not believe in czars, so I think he preferred the latter) On the other hand, it was largely his official RFC Editor role that gave Jon the leverage to actually guard the good taste of the Internet protocol suite. I think the rest of the reason he got away with being a protocol autocrat was that the rest of us had such deep respect for Jon's judgment. He set a standard of good sense and consistency that has served us well. He ironed out the wrinkles in the protocols, and he famously pronounced pithy principles. For example, I recall his saying that when you are deciding whether to include a particular field or bit in a protocol header, if you cannot explain fairly accurately what a receiver should do when it receives that field, you should deep-six it. I suspect he generalized this principle from the source quench example, but it might go back to the "rubber EOL" feature in early TCP. Bob Braden From mfidelman at meetinghouse.net Tue Jul 30 06:27:18 2013 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Tue, 30 Jul 2013 09:27:18 -0400 Subject: [ih] Fwd: [IP] OSI: The Internet That Wasn't In-Reply-To: References: Message-ID: <51F7BF36.2060702@meetinghouse.net> Figure some of you would enjoy this. Miles ------- forwarded ----- IEEE Spectrum just published online, titled "OSI: The Internet That Wasn't." OSI, of course, is the acronym for Open Systems Interconnection. The url is http://spectrum.ieee.org/computing/networks/osi-the-internet-that-wasnt, and I'm sure subscribers will receive paper copies soon. Particularly interesting for the early pictures of some folks we all know and love. From bernie at fantasyfarm.com Tue Jul 30 07:07:46 2013 From: bernie at fantasyfarm.com (Bernie Cosell) Date: Tue, 30 Jul 2013 10:07:46 -0400 Subject: [ih] Fwd: [IP] OSI: The Internet That Wasn't In-Reply-To: <51F7BF36.2060702@meetinghouse.net> References: , <51F7BF36.2060702@meetinghouse.net> Message-ID: <51F7C8B2.25320.155354F2@bernie.fantasyfarm.com> On 30 Jul 2013 at 9:27, Miles Fidelman wrote: > ------- forwarded ----- > > IEEE Spectrum just published online, titled "OSI: The Internet That > Wasn't." OSI, of course, is the acronym for Open Systems > Interconnection. Interesting stuff. I had virtually no interaction with the "International" stuff except for one thing: at some point [I can't remember when, but I suspect Dave can] they came out with a draft proposal for X.25 level 3. Since that would affect the TIP and I was TIP czar at the time, Dave [I think] asked me to critique the proposal. What it was, was HDLC kludged up to sort-of be full-duplex, but in a way that could never work. They seemed to have learned none of the lessons we [ARPAnet folk] had with redoing the TELNET protocol. I wrote a pretty scathing critique that I *think* got published [was it IEEE Comm?]. I believe that not long after that they withdrew the proposal...:o) It was kind of fun, but I never did get involved with it again [I was already off of the relevant projects before we [BBN] put in X.25 support in our systems]. /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:bernie at fantasyfarm.com Pearisburg, VA --> Too many people, too few sheep <-- From jeanjour at comcast.net Tue Jul 30 07:47:43 2013 From: jeanjour at comcast.net (John Day) Date: Tue, 30 Jul 2013 10:47:43 -0400 Subject: [ih] Fwd: [IP] OSI: The Internet That Wasn't In-Reply-To: <51F7C8B2.25320.155354F2@bernie.fantasyfarm.com> References: , <51F7BF36.2060702@meetinghouse.net> <51F7C8B2.25320.155354F2@bernie.fantasyfarm.com> Message-ID: Yea, the PTTs in Europe were pretty clueless in general. There is very little way that they could have known much about the ARPANET experience, nor would they have listened if they could. Remember the reaction ATT had to the ARPANET at ICCC '72. They thought it was a joke. Not an uncommon reaction to those in an old paradigm not seeing the elements of a new one in the first stages of formation. I have heard rumors that the Telenet guys had considerable input into X.25 but I don't know if that was true. Remi Despres wrote a fairly long article on it in IEEE Annals of Computing History. At 10:07 AM -0400 7/30/13, Bernie Cosell wrote: >On 30 Jul 2013 at 9:27, Miles Fidelman wrote: > >> ------- forwarded ----- >> >> IEEE Spectrum just published online, titled "OSI: The Internet That >> Wasn't." OSI, of course, is the acronym for Open Systems >> Interconnection. > >Interesting stuff. I had virtually no interaction with the >"International" stuff except for one thing: at some point [I can't >remember when, but I suspect Dave can] they came out with a draft >proposal for X.25 level 3. Since that would affect the TIP and I was TIP >czar at the time, Dave [I think] asked me to critique the proposal. > >What it was, was HDLC kludged up to sort-of be full-duplex, but in a way >that could never work. They seemed to have learned none of the lessons >we [ARPAnet folk] had with redoing the TELNET protocol. I wrote a pretty >scathing critique that I *think* got published [was it IEEE Comm?]. I >believe that not long after that they withdrew the proposal...:o) It >was kind of fun, but I never did get involved with it again [I was >already off of the relevant projects before we [BBN] put in X.25 support >in our systems]. > > /Bernie\ > >-- >Bernie Cosell Fantasy Farm Fibers >mailto:bernie at fantasyfarm.com Pearisburg, VA > --> Too many people, too few sheep <-- From jnc at mercury.lcs.mit.edu Tue Jul 30 11:21:36 2013 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 30 Jul 2013 14:21:36 -0400 (EDT) Subject: [ih] Fwd: [IP] OSI: The Internet That Wasn't Message-ID: <20130730182136.B117F18C112@mercury.lcs.mit.edu> > IEEE Spectrum just published online, titled "OSI: The Internet That > Wasn't" >From my perspective on those events, I think it's a pretty accurate history. aThe one comment I have about it is that I think it focuses a bit too much on the standards process stuff (including its effect on the design); there were other things that I think were significant contributors to OSI's failure. E.g. the TCP/IP world had a head-start on deployment (i.e. installed-base/user-community), and that was really a Big Deal. Metcalfe's Law does make sense when you think about it (the point of a communication network is to communicate, and on a bigger network, you can communicate with more people...) TCP/IP's head start meant that at point X, when the race began (for pretty much any X), it had a bigger user community, and that was a huge advantage. I mean, the average user didn't give two hoots about whether the TP0 .. TP4 siblings were duplicative, or whether the IETF process was more effective than ISO's, or whatever; they just wanted to use the network to communicate. And there were a lot of people on the Internet already... So when they had to decide which community to join (AKA which protocol family to bring up), the answer was fairly obvious. And of course, that effect fed back into itself rather directly... Noel From mfidelman at meetinghouse.net Tue Jul 30 12:55:52 2013 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Tue, 30 Jul 2013 15:55:52 -0400 Subject: [ih] Fwd: [IP] OSI: The Internet That Wasn't In-Reply-To: <20130730182136.B117F18C112@mercury.lcs.mit.edu> References: <20130730182136.B117F18C112@mercury.lcs.mit.edu> Message-ID: <51F81A48.7000100@meetinghouse.net> Noel Chiappa wrote: > > IEEE Spectrum just published online, titled "OSI: The Internet That > > Wasn't" > > TCP/IP's head start meant that at point X, when the race began (for pretty > much any X), it had a bigger user community, and that was a huge advantage. > > I mean, the average user didn't give two hoots about whether the TP0 .. TP4 > siblings were duplicative, or whether the IETF process was more effective than > ISO's, or whatever; they just wanted to use the network to communicate. And > there were a lot of people on the Internet already... So when they had to > decide which community to join (AKA which protocol family to bring up), the > answer was fairly obvious. > > Just to add to that a bit, I remember all the hoops that the MILDEPS went through to make sure that the TCP/IP stack could still be used, despite the OSI mandate coming down from the top (I was at BBN doing MILNET architecture at the time - supporting both DCA and various IT commands in the Air Force and Navy, plus the occasional system procurement that we subbed on). Sure, all the RFPs went out requiring OSI protocol support, but they ALSO required continued TCP/IP support. As I recall, it was a rare vendor who delivered a working OSI stack. (Parenthetical note: I'm convinced that Wang went from the Army's main computer vendor, to out of business, because they kept stalling on providing a TCP/IP stack, much less an OSI one - they just didn't want their stuff to interoperate, and it cost them.) Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From brian.e.carpenter at gmail.com Tue Jul 30 13:05:57 2013 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 31 Jul 2013 08:05:57 +1200 Subject: [ih] Fwd: [IP] OSI: The Internet That Wasn't In-Reply-To: <51F7BF36.2060702@meetinghouse.net> References: <51F7BF36.2060702@meetinghouse.net> Message-ID: <51F81CA5.8080202@gmail.com> "the OSI advocate Brian Carpenter" is slightly embarrassed. On 31/07/2013 01:27, Miles Fidelman wrote: > Figure some of you would enjoy this. > > Miles > > ------- forwarded ----- > > IEEE Spectrum just published online, titled "OSI: The Internet That > Wasn't." OSI, of course, is the acronym for Open Systems Interconnection. > > The url is > http://spectrum.ieee.org/computing/networks/osi-the-internet-that-wasnt, > and I'm sure subscribers will receive paper copies soon. > > Particularly interesting for the early pictures of some folks we all > know and love. > > > > > From vint at google.com Tue Jul 30 13:54:58 2013 From: vint at google.com (Vint Cerf) Date: Tue, 30 Jul 2013 16:54:58 -0400 Subject: [ih] Fwd: [IP] OSI: The Internet That Wasn't In-Reply-To: References: <51F7BF36.2060702@meetinghouse.net> <51F7C8B2.25320.155354F2@bernie.fantasyfarm.com> Message-ID: telenet led he development of x.25 (Larry Roberts and Barry Wessler) along with the British Post Office, the French Reseau Communication par Paquet from CNET (Remi Despres) and Dave(?) Horton of DATAPAC in Canada. On Tue, Jul 30, 2013 at 10:47 AM, John Day wrote: > Yea, the PTTs in Europe were pretty clueless in general. There is very > little way that they could have known much about the ARPANET experience, > nor would they have listened if they could. Remember the reaction ATT had > to the ARPANET at ICCC '72. They thought it was a joke. Not an uncommon > reaction to those in an old paradigm not seeing the elements of a new one > in the first stages of formation. > > I have heard rumors that the Telenet guys had considerable input into X.25 > but I don't know if that was true. Remi Despres wrote a fairly long > article on it in IEEE Annals of Computing History. > > > > At 10:07 AM -0400 7/30/13, Bernie Cosell wrote: > >> On 30 Jul 2013 at 9:27, Miles Fidelman wrote: >> >> ------- forwarded ----- >>> >>> IEEE Spectrum just published online, titled "OSI: The Internet That >>> Wasn't." OSI, of course, is the acronym for Open Systems >>> Interconnection. >>> >> >> Interesting stuff. I had virtually no interaction with the >> "International" stuff except for one thing: at some point [I can't >> remember when, but I suspect Dave can] they came out with a draft >> proposal for X.25 level 3. Since that would affect the TIP and I was TIP >> czar at the time, Dave [I think] asked me to critique the proposal. >> >> What it was, was HDLC kludged up to sort-of be full-duplex, but in a way >> that could never work. They seemed to have learned none of the lessons >> we [ARPAnet folk] had with redoing the TELNET protocol. I wrote a pretty >> scathing critique that I *think* got published [was it IEEE Comm?]. I >> believe that not long after that they withdrew the proposal...:o) It >> was kind of fun, but I never did get involved with it again [I was >> already off of the relevant projects before we [BBN] put in X.25 support >> in our systems]. >> >> /Bernie\ >> >> -- >> Bernie Cosell Fantasy Farm Fibers >> mailto:bernie at fantasyfarm.com Pearisburg, VA >> --> Too many people, too few sheep <-- >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanjour at comcast.net Tue Jul 30 13:58:02 2013 From: jeanjour at comcast.net (John Day) Date: Tue, 30 Jul 2013 16:58:02 -0400 Subject: [ih] Fwd: [IP] OSI: The Internet That Wasn't In-Reply-To: References: <51F7BF36.2060702@meetinghouse.net> <51F7C8B2.25320.155354F2@bernie.fantasyfarm.com> Message-ID: At 4:54 PM -0400 7/30/13, Vint Cerf wrote: >telenet led he development of x.25 (Larry Roberts and Barry Wessler) >along with the British Post Office, the French Reseau Communication >par Paquet from CNET (Remi Despres) and Dave(?) Horton of DATAPAC in >Canada. Right, Dave Horton. I was trying to remember that name. John > >On Tue, Jul 30, 2013 at 10:47 AM, John Day ><jeanjour at comcast.net> wrote: > >Yea, the PTTs in Europe were pretty clueless in general. There is >very little way that they could have known much about the ARPANET >experience, nor would they have listened if they could. Remember >the reaction ATT had to the ARPANET at ICCC '72. They thought it >was a joke. Not an uncommon reaction to those in an old paradigm >not seeing the elements of a new one in the first stages of >formation. > >I have heard rumors that the Telenet guys had considerable input >into X.25 but I don't know if that was true. Remi Despres wrote a >fairly long article on it in IEEE Annals of Computing History. > > > >At 10:07 AM -0400 7/30/13, Bernie Cosell wrote: > >On 30 Jul 2013 at 9:27, Miles Fidelman wrote: > > ------- forwarded ----- > > IEEE Spectrum just published online, titled "OSI: The Internet That > Wasn't." OSI, of course, is the acronym for Open Systems > Interconnection. > > >Interesting stuff. I had virtually no interaction with the >"International" stuff except for one thing: at some point [I can't >remember when, but I suspect Dave can] they came out with a draft >proposal for X.25 level 3. Since that would affect the TIP and I was TIP >czar at the time, Dave [I think] asked me to critique the proposal. > >What it was, was HDLC kludged up to sort-of be full-duplex, but in a way >that could never work. They seemed to have learned none of the lessons >we [ARPAnet folk] had with redoing the TELNET protocol. I wrote a pretty >scathing critique that I *think* got published [was it IEEE Comm?]. I >believe that not long after that they withdrew the proposal...:o) It >was kind of fun, but I never did get involved with it again [I was >already off of the relevant projects before we [BBN] put in X.25 support >in our systems]. > > /Bernie\ > >-- >Bernie Cosell Fantasy Farm Fibers >mailto:bernie at fantasyfarm.com >Pearisburg, VA > --> Too many people, too few sheep <-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From winowicki at yahoo.com Tue Jul 30 14:13:23 2013 From: winowicki at yahoo.com (Bill Nowicki) Date: Tue, 30 Jul 2013 14:13:23 -0700 (PDT) Subject: [ih] Fwd: [IP] OSI: The Internet That Wasn't In-Reply-To: <51F81A48.7000100@meetinghouse.net> References: <20130730182136.B117F18C112@mercury.lcs.mit.edu> <51F81A48.7000100@meetinghouse.net> Message-ID: <1375218803.15071.YahooMailNeo@web125405.mail.ne1.yahoo.com> ? ?Yes,?many of us probably?have anecdotes?that confirm what Noel and others are saying. The standards process might play a role, but working software also does. Here is my story. ? I was the lone TCP/IP person at Sun Microsystems in the 1980s. I would maybe buy Van Jacobson an espresso, and then integrate his improvements into Sun's OS along with other software from the BSD community as I found the time. Meanwhile there was a large (for Sun) dedicated group developing the ISO OSI stack. Marketing was convinced that only a few researchers might use TCP, while businesses would use OSI, so they wanted 20 times the people working on OSI. ? We published the NFS protocol as an "informational" RFC since it had not (yet) gone through any standards process. However, the implementations of?NFS worked with each other. In particular, I was called in on a support issue for one customer: the Corporation for Open Systems. They of course used NFS over TCP/IP to get their work done, which was ironically promoting OSI. It was I think Milo Medin who realized the letter of the GOSIP mandate was that federal agencies needed to have the OSI protocol "available" for any equipment they bought, but did not need to actually buy it, let alone use it. ? Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanjour at comcast.net Tue Jul 30 14:14:32 2013 From: jeanjour at comcast.net (John Day) Date: Tue, 30 Jul 2013 17:14:32 -0400 Subject: [ih] Fwd: [IP] OSI: The Internet That Wasn't In-Reply-To: References: <51F7BF36.2060702@meetinghouse.net> <51F7C8B2.25320.155354F2@bernie.fantasyfarm.com> Message-ID: At 4:58 PM -0400 7/30/13, John Day wrote: >At 4:54 PM -0400 7/30/13, Vint Cerf wrote: >>telenet led he development of x.25 (Larry Roberts and Barry >>Wessler) along with the British Post Office, the French Reseau >>Communication par Paquet from CNET (Remi Despres) and Dave(?) >>Horton of DATAPAC in Canada. > >Right, Dave Horton. I was trying to remember that name. I should explain. DATAPAC's coming out was at ICCC76 in Toronto. We were whisked across the street from the Royal York Hotel (it may have been a couple of blocks) for fancy whiz-bang film, all out demo of DATAPAC. But at the conference, I remember Horton giving a talk on Datapac and someone asking him what he would think of people marketing PADs (X.25 Terminal Concentrators). (It is important to understand that in CCITT think the PAD had been defined to be part of the network rather than as a limited function host and not "part of the network." It was clear that they were using the phone company beads-on-a-string model to define markets.) Horton in a moment of candor replied emphatically, "Not Very Much!" ;-) > >John > >> >>On Tue, Jul 30, 2013 at 10:47 AM, John Day >><jeanjour at comcast.net> wrote: >> >>Yea, the PTTs in Europe were pretty clueless in general. There is >>very little way that they could have known much about the ARPANET >>experience, nor would they have listened if they could. Remember >>the reaction ATT had to the ARPANET at ICCC '72. They thought it >>was a joke. Not an uncommon reaction to those in an old paradigm >>not seeing the elements of a new one in the first stages of >>formation. >> >>I have heard rumors that the Telenet guys had considerable input >>into X.25 but I don't know if that was true. Remi Despres wrote a >>fairly long article on it in IEEE Annals of Computing History. >> >> >> >>At 10:07 AM -0400 7/30/13, Bernie Cosell wrote: >> >>On 30 Jul 2013 at 9:27, Miles Fidelman wrote: >> >> ------- forwarded ----- >> >> IEEE Spectrum just published online, titled "OSI: The Internet That >> Wasn't." OSI, of course, is the acronym for Open Systems >> Interconnection. >> >> >>Interesting stuff. I had virtually no interaction with the >>"International" stuff except for one thing: at some point [I can't >>remember when, but I suspect Dave can] they came out with a draft >>proposal for X.25 level 3. Since that would affect the TIP and I was TIP >>czar at the time, Dave [I think] asked me to critique the proposal. >> >>What it was, was HDLC kludged up to sort-of be full-duplex, but in a way >>that could never work. They seemed to have learned none of the lessons >>we [ARPAnet folk] had with redoing the TELNET protocol. I wrote a pretty >>scathing critique that I *think* got published [was it IEEE Comm?]. I >>believe that not long after that they withdrew the proposal...:o) It >>was kind of fun, but I never did get involved with it again [I was >>already off of the relevant projects before we [BBN] put in X.25 support >>in our systems]. >> >> /Bernie\ >> >>-- >>Bernie Cosell Fantasy Farm Fibers >>mailto:bernie at fantasyfarm.com >>Pearisburg, VA >> --> Too many people, too few sheep <-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.e.carpenter at gmail.com Tue Jul 30 17:18:45 2013 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 31 Jul 2013 12:18:45 +1200 Subject: [ih] Fwd: [IP] OSI: The Internet That Wasn't In-Reply-To: <1375218803.15071.YahooMailNeo@web125405.mail.ne1.yahoo.com> References: <20130730182136.B117F18C112@mercury.lcs.mit.edu> <51F81A48.7000100@meetinghouse.net> <1375218803.15071.YahooMailNeo@web125405.mail.ne1.yahoo.com> Message-ID: <51F857E5.2090506@gmail.com> On 31/07/2013 09:13, Bill Nowicki wrote: > > Yes, many of us probably have anecdotes that confirm what Noel and others are saying. The standards process might play a role, but working software also does. Here is my story. > > I was the lone TCP/IP person at Sun Microsystems in the 1980s. I would maybe buy Van Jacobson an espresso, and then integrate his improvements into Sun's OS along with other software from the BSD community as I found the time. Meanwhile there was a large (for Sun) dedicated group developing the ISO OSI stack. Marketing was convinced that only a few researchers might use TCP, while businesses would use OSI, so they wanted 20 times the people working on OSI. > > We published the NFS protocol as an "informational" RFC since it had not (yet) gone through any standards process. However, the implementations of NFS worked with each other. In particular, I was called in on a support issue for one customer: the Corporation for Open Systems. They of course used NFS over TCP/IP to get their work done, which was ironically promoting OSI. It was I think Milo Medin who realized the letter of the GOSIP mandate was that federal agencies needed to have the OSI protocol "available" for any equipment they bought, but did not need to actually buy it, let alone use it. I was told by somebody, probably somebody in ESNET or at Fermilab, that they had to order GOSIP-compliant code and pay for it, but they didn't have to open the box (presumably a box of floppy disks in those days). Brian From dhc2 at dcrocker.net Tue Jul 30 21:36:50 2013 From: dhc2 at dcrocker.net (Dave Crocker) Date: Wed, 31 Jul 2013 06:36:50 +0200 Subject: [ih] Fwd: [IP] OSI: The Internet That Wasn't In-Reply-To: <51F7BF36.2060702@meetinghouse.net> References: <51F7BF36.2060702@meetinghouse.net> Message-ID: <51F89462.7080002@dcrocker.net> > IEEE Spectrum just published online, titled "OSI: The Internet That > Wasn't." OSI, of course, is the acronym for Open Systems Interconnection. The article's characterization of the IETF's activities in 1992 is, itself, a gross mischaracterization of what took place. I was on the IESG at the time and my own reading was that CLNP had a reasonable shot at being selected from amongst an array of contenders. However the IAB's premature selection of it -- rather than letting the community continue through an evaluation process -- finally brought to a head the continuing tension between the IAB's style of exercising authority and the community's festering frustration with it. More generally... The author interestingly entirely missed the real lessons for why OSI failed. As noted in some of the other postings here, TCP/IP had deployed useful code and OSI did not, except in very small scale and very strict operating conditions. Also it was, indeed, massively more complicated than the Internet stack, but it also was incomplete. In the late 1980s, I managed various efforts at developing commercial TCP/IP stacks. This also included an OSI stack. When we started to ask customers about their needs for our product support in transitioning from TCP to OSI, they said that what they actually needed was support from OSI to TCP. Perhaps as much as 25% of my customer base was in Europe, the hotbed of OSI. OSI created the market demand; TCP/IP satisfied it. (This is a commercial version of Stef's quoted comment.) One of my customers was... ISO, the home of OSI. I asked their IT manager whether he got criticized for supporting TCP/IP and in typical operations manager humorless pragmatics, he said "they gave me an operational requirement and this was the only way to satisfy it." In the early 1990s, I wrote some articles on the Internet standards process and tried to describe the apparent difference in the IETF's engineering style vs the world of OSI.[1] What I finally concluded was that both communities had serious, bright engineers who were trying to do good things. And both communities had engineers who would each bring long and different lists of requirements. The distinguishing characteristic between Internet and OSI engineering was/is how the sets of lists were processed. In the OSI world they would try to satisfy the union of the lists. This demands a large complicated system that takes a long time to produce. The Internet looked for the intersection, thereby permitting earlier delivery of an essential subset. And that, I believe, is the actual core lesson from this history: For a complex problem space, find a useful subset that can be delivered quickly. Deliver it and start gaining field experience. Based on that experience, then start extending the capabilities. /d [1] http://bbiw.net/musings.html#standards -- Dave Crocker Brandenburg InternetWorking bbiw.net From brian.e.carpenter at gmail.com Tue Jul 30 22:11:14 2013 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 31 Jul 2013 17:11:14 +1200 Subject: [ih] How OSI looked in 1988/89 Message-ID: <51F89C72.4030207@gmail.com> These two workshop papers are how the state of OSI looked from CERN in 1988/89. Before the second one, Tim Berners-Lee had circulated the original proposal for the Web to some of us. The references to "interim" solutions mainly meant DECnet and TCP/IP, with EARN/BITNET also part of the story. "COSINE" was a European Union project to deploy OSI services for the research community. http://cds.cern.ch/record/188252/files/CM-P00059890.pdf http://cds.cern.ch/record/197332/files/CM-P00059917.pdf Brian From joly at punkcast.com Tue Jul 30 23:36:44 2013 From: joly at punkcast.com (Joly MacFie) Date: Wed, 31 Jul 2013 02:36:44 -0400 Subject: [ih] Fwd: CFP: Comparative Internet Histories (edited collection) Message-ID: FYI, from the AoIR list http://aoir.org ---------- ---------- Comparative Internet Histories Gerard Goggin and Mark McLelland (editors) Overview Although the Internet is entering its fifth decade, the understanding and formulation of its histories outside of a Euro-American framework is very much in its infancy. In this collection, which arises from a workshop at the 2013 Association of Internet Researchers Conference: http://ir14.aoir.org/preconference-workshop-appropriating-the-internet-alternative-comparative-histories/, contributors explore some of the problems, questions, methods, biases, narratives, and metaphors that underlie research into the Internet?s diverse histories. Given that ?the Internet? is so often spoken of as a ?global? and ?deterritorialised? technology, it might be supposed that specific cultures of use can be replicated anywhere that has Internet connectivity. Yet what Internet technologies are available and preferred depends upon cultural factors as well as market and policy factors such as government regulation, competition between providers, and pricing. In its current phase of development -- often approached through ideologies and discourses such as ?web 2.0,? ?convergence culture,? and ?user-generated content? -- the Internet is dominated by social networking systems (SNS) and a focus on users? role in production as well as consumption. Far from one SNS dominating globally, however, the rise of this technology has been multiple and divergent, reflecting the localized adaptations of the Internet. To grasp the significance of web 2.0 features requires an acknowledgement of the existing media cultures influential upon users, as well as the effects of industry, policy, and social contexts, and the ways that imported ? and local ? technologies are being domesticated. The localised Internet histories that are emerging, and continue to evolve, need to be investigated through a cultural history of the development of the various aspects of the Internet in different regions and social contexts. This is evident in early applications such as email, BBS, and text-based online communities, through the adoption of the web and the rise of mass Internet, as well as more recent technologies such as blogs, SNS, and mobile and wireless technologies. This collection brings together researchers working on country-specific and regional histories of the Internet as well as those researching transnational platforms and communities, thus adding to our understanding of the different historical patterns of Internet development and deployment. Existing chapters ?Doing Internet Histories? Gerard Goggin (University of Sydney) ?Oral Histories of the Net: Australians Tell the Story of their ?Connection? via the Internet? Matthew Allen (Deakin University) ?A Decade of ?Social Media? and what to Do about It: Methodological Challenges of Historicising the Proprietary Web? Jean Burgess (Queensland University of Technology) ?The Forgotten Foreign Phase: Early BBS Systems in Japan? Mark McLelland (University of Wollongong) ?Challenging the Net: Japanese Political Campaigns and the Internet 1995 to 2013? Leslie M. Tkach-Kawasaki (University of Tsukuba) ?Japanese CMC as an Expanded Intimate Sphere: an Historical Analysis of Human Relationships Online? Takanori Tamura (Hosei University) ?Internet Memory of a Counter-Hegemonic Group: An Oral History Perspective on Chinese Internet History? Angela Xiao Wu (Northwestern University) ?Niche Goes Global: A History of a Digitised Musical Subculture? Andrew Whelan (University of Wollongong) We invite further chapter proposals including but not limited to the following topics: ? What are the challenges of doing Internet histories, and what are the particular issues for concepts, methods, tools, documentation, archives, interpretative strategies, and presentation of research findings? How do these factors differ across societies? ? What are the implication of specific cultural metaphors and ways of thinking about the Internet for the technology?s development in specific countries and regions outside North America and Western Europe? ? Forgotten phases of the Internet ? important developments that have not been recorded in mainstream accounts Internet history. ? Internet histories outside of North America and Western Europe. ? The oral history of the net outside of North America and Western Europe. ? The Internet and Social Activism outside of North America and Western Europe. Please send a brief bio, proposed title and a 250 word abstract to Mark McLelland (markmc at uow.edu.au) by 4 November 2013. Already coming to AoIR 2013? Then join us at the Internet Histories Workshop to discuss your proposal: http://ir14.aoir.org/preconference-workshop-appropriating-the-internet-alternative-comparative-histories/ Editors' contact details Professor Gerard Goggin, Department of Media and Communications, University of Sydney e: gerard.goggin at sydney.edu.au Web: http://sydney.edu.au/arts/media_communications/staff/gerard_goggin.shtml Professor Mark McLelland, School of Social Sciences, Media and Communication University of Wollongong e: markmc at uow.edu.au web: http://www.uow.edu.au/arts/ssmac/staff/UOW018742.html -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.brim at gmail.com Wed Jul 31 00:10:25 2013 From: scott.brim at gmail.com (Scott Brim) Date: Wed, 31 Jul 2013 09:10:25 +0200 Subject: [ih] [IP] OSI: The Internet That Wasn't In-Reply-To: <51F89462.7080002@dcrocker.net> References: <51F7BF36.2060702@meetinghouse.net> <51F89462.7080002@dcrocker.net> Message-ID: On Wednesday, July 31, 2013, Dave Crocker wrote: > ... and my own reading was that CLNP had a reasonable shot at being >> selected from amongst an array of contenders. However the IAB's premature >> selection of it -- rather than letting the community continue through an >> evaluation process -- finally brought to a head the continuing tension >> between the IAB's style of exercising authority and the community's >> festering frustration with it. > > Agreed. The timing and execution by CLNP promoters was weak throughout that entire period, otherwise "IPv6" could have been quite different. Although it was not _everyone_ who had a problem with the IAB - rather, their unexpected behavior wrt CLNP united different groups against them. > In the early 1990s, I wrote some articles on the Internet standards > process and tried to describe the apparent difference in the IETF's > engineering style vs the world of OSI.[1] What I finally concluded was > that both communities had serious, bright engineers who were trying to do > good things. And both communities had engineers who would each bring long > and different lists of requirements. The distinguishing characteristic > between Internet and OSI engineering was/is how the sets of lists were > processed. In the OSI world they would try to satisfy the union of the > lists. This demands a large complicated system that takes a long time to > produce. The Internet looked for the intersection, thereby permitting > earlier delivery of an essential subset. > > And that, I believe, is the actual core lesson from this history: For a > complex problem space, find a useful subset that can be delivered quickly. > Deliver it and start gaining field experience. Based on that experience, > then start extending the capabilities. > Is this where we segue to talking about the state of the IETF? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhc2 at dcrocker.net Wed Jul 31 01:06:55 2013 From: dhc2 at dcrocker.net (Dave Crocker) Date: Wed, 31 Jul 2013 10:06:55 +0200 Subject: [ih] [IP] OSI: The Internet That Wasn't In-Reply-To: References: <51F7BF36.2060702@meetinghouse.net> <51F89462.7080002@dcrocker.net> Message-ID: <51F8C59F.6060407@dcrocker.net> On 7/31/2013 9:10 AM, Scott Brim wrote: > > Is this where we segue to talking about the state of the IETF? Well, umm... In the early 1980s, there was a hot debate going on between DOS and Unix. I went and did other things for a few years; when I returned, I discovered that Unix had won and it was called DOS. DOS continued to dominate the market but all of its new features were taken from Unix. Too often, the same template applies for the IETF. That is, what I often see is that in many cases, OSI has won, and it is called IETF. Too often, work attempts the union of the feature lists, rather than the intersection, and therefore takes an overly long time to complete, produces massively complex specifications, and is not immediately useful. It is now not that unusual to hear -- such as yesterday morning -- someone (whose experience ought to have taught them better) that it is essential to do everything all at once, for example to make sure that all of the pieces work together. This is in marked contrast with essentially all of the major IETF successes over the last 25+ years. Aren't you glad you asked? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From scott.brim at gmail.com Wed Jul 31 01:16:32 2013 From: scott.brim at gmail.com (Scott Brim) Date: Wed, 31 Jul 2013 10:16:32 +0200 Subject: [ih] [IP] OSI: The Internet That Wasn't In-Reply-To: <51F8C59F.6060407@dcrocker.net> References: <51F7BF36.2060702@meetinghouse.net> <51F89462.7080002@dcrocker.net> <51F8C59F.6060407@dcrocker.net> Message-ID: Exactly why I mentioned it. TCP/IP won, but so did the OSI process. On Wednesday, July 31, 2013, Dave Crocker wrote: > On 7/31/2013 9:10 AM, Scott Brim wrote: > >> >> Is this where we segue to talking about the state of the IETF? >> > > > Well, umm... > > In the early 1980s, there was a hot debate going on between DOS and Unix. > I went and did other things for a few years; when I returned, I discovered > that Unix had won and it was called DOS. DOS continued to dominate the > market but all of its new features were taken from Unix. > > Too often, the same template applies for the IETF. That is, what I often > see is that in many cases, OSI has won, and it is called IETF. > > Too often, work attempts the union of the feature lists, rather than the > intersection, and therefore takes an overly long time to complete, produces > massively complex specifications, and is not immediately useful. > > It is now not that unusual to hear -- such as yesterday morning -- someone > (whose experience ought to have taught them better) that it is essential to > do everything all at once, for example to make sure that all of the pieces > work together. This is in marked contrast with essentially all of the > major IETF successes over the last 25+ years. > > Aren't you glad you asked? > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanjour at comcast.net Wed Jul 31 04:15:13 2013 From: jeanjour at comcast.net (John Day) Date: Wed, 31 Jul 2013 07:15:13 -0400 Subject: [ih] [IP] OSI: The Internet That Wasn't In-Reply-To: References: <51F7BF36.2060702@meetinghouse.net> <51F89462.7080002@dcrocker.net> <51F8C59F.6060407@dcrocker.net> Message-ID: No, it was not the OSI process. All consensus processes have these properties. They become more manifest with size and with time. It is the nature of the beast. However, I would offer that the particular organization of the IETF which lacks certain fundamental feedback mechanisms has more problems than those with those feedback mechanisms. There is a reasonable treatment of this in Federalist 10. As to IPv6 turning out different, ahh soon they forget. The ground rules were set so that the answer had to be anything but CLNP. CLNP fixed a problem we had seen in the ARPANET. I remember sitting in those meetings incredulous that a problem we had first seen 20 year before (now 40) was not being fixed. But we don't need to go there. At 10:16 AM +0200 7/31/13, Scott Brim wrote: >Exactly why I mentioned it. TCP/IP won, but so did the OSI process. > >On Wednesday, July 31, 2013, Dave Crocker wrote: > >On 7/31/2013 9:10 AM, Scott Brim wrote: > > >Is this where we segue to talking about the state of the IETF? > > > >Well, umm... > >In the early 1980s, there was a hot debate going on between DOS and >Unix. I went and did other things for a few years; when I returned, >I discovered that Unix had won and it was called DOS. DOS continued >to dominate the market but all of its new features were taken from >Unix. > >Too often, the same template applies for the IETF. That is, what I >often see is that in many cases, OSI has won, and it is called IETF. > >Too often, work attempts the union of the feature lists, rather than >the intersection, and therefore takes an overly long time to >complete, produces massively complex specifications, and is not >immediately useful. > >It is now not that unusual to hear -- such as yesterday morning -- >someone (whose experience ought to have taught them better) that it >is essential to do everything all at once, for example to make sure >that all of the pieces work together. This is in marked contrast >with essentially all of the major IETF successes over the last 25+ >years. > >Aren't you glad you asked? > >d/ > >-- >Dave Crocker >Brandenburg InternetWorking >bbiw.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhc2 at dcrocker.net Wed Jul 31 04:26:29 2013 From: dhc2 at dcrocker.net (Dave Crocker) Date: Wed, 31 Jul 2013 13:26:29 +0200 Subject: [ih] [IP] OSI: The Internet That Wasn't In-Reply-To: References: <51F7BF36.2060702@meetinghouse.net> <51F89462.7080002@dcrocker.net> <51F8C59F.6060407@dcrocker.net> Message-ID: <51F8F465.7060208@dcrocker.net> On 7/31/2013 1:15 PM, John Day wrote: > No, it was not the OSI process. All consensus processes have these > properties. Obviously they don't, since the IETF did not used to display it (very often.) > As to IPv6 turning out different, ahh soon they forget. The ground > rules were set so that the answer had to be anything but CLNP. Not prior to the Kobe blowup they weren't. I'm not saying they /were/ set up that way later; I'm saying they weren't for the period I was referencing. There was a vigorous and even healthy debate underway and I was finding myself impressed that CLNP seemed to be holding up quite well in my personal assessment of points on technical merit. With Kobe, the IAB prematurely terminated the community debate. The community then exercised the tend-available form of appeal against the IAB... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jeanjour at comcast.net Wed Jul 31 05:00:46 2013 From: jeanjour at comcast.net (John Day) Date: Wed, 31 Jul 2013 08:00:46 -0400 Subject: [ih] [IP] OSI: The Internet That Wasn't In-Reply-To: <51F8F465.7060208@dcrocker.net> References: <51F7BF36.2060702@meetinghouse.net> <51F89462.7080002@dcrocker.net> <51F8C59F.6060407@dcrocker.net> <51F8F465.7060208@dcrocker.net> Message-ID: At 1:26 PM +0200 7/31/13, Dave Crocker wrote: >On 7/31/2013 1:15 PM, John Day wrote: >>No, it was not the OSI process. All consensus processes have these >>properties. > >Obviously they don't, since the IETF did not used to display it (very often.) That was when the IETF was much more homogeneous. The greater the diversity, the wider the participation, the messier it gets. This phenomena has been known for centuries. > >>As to IPv6 turning out different, ahh soon they forget. The ground >>rules were set so that the answer had to be anything but CLNP. > >Not prior to the Kobe blowup they weren't. I'm not saying they >/were/ set up that way later; I'm saying they weren't for the period >I was referencing. > >There was a vigorous and even healthy debate underway and I was >finding myself impressed that CLNP seemed to be holding up quite >well in my personal assessment of points on technical merit. > >With Kobe, the IAB prematurely terminated the community debate. The >community then exercised the tend-available form of appeal against >the IAB... I agree. I was replying to Scott, I thought! ;-) John > > > >d/ > >-- >Dave Crocker >Brandenburg InternetWorking >bbiw.net From scott.brim at gmail.com Wed Jul 31 05:29:01 2013 From: scott.brim at gmail.com (Scott Brim) Date: Wed, 31 Jul 2013 14:29:01 +0200 Subject: [ih] [IP] OSI: The Internet That Wasn't In-Reply-To: References: <51F7BF36.2060702@meetinghouse.net> <51F89462.7080002@dcrocker.net> <51F8C59F.6060407@dcrocker.net> <51F8F465.7060208@dcrocker.net> Message-ID: On Wednesday, July 31, 2013, John Day wrote: > I agree. I was replying to Scott, I thought! ;-) > I pushed Dave's button. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhc2 at dcrocker.net Wed Jul 31 08:53:13 2013 From: dhc2 at dcrocker.net (Dave Crocker) Date: Wed, 31 Jul 2013 17:53:13 +0200 Subject: [ih] [IP] OSI: The Internet That Wasn't In-Reply-To: <229F34E5-BAA5-4BDB-9751-F512E6D816AC@pi-coral.com> References: <51F7BF36.2060702@meetinghouse.net> <51F89462.7080002@dcrocker.net> <51F8C59F.6060407@dcrocker.net> <51F8F465.7060208@dcrocker.net> <229F34E5-BAA5-4BDB-9751-F512E6D816AC@pi-coral.com> Message-ID: <51F932E9.9060802@dcrocker.net> On 7/31/2013 5:38 PM, Tony Li wrote: > > On Jul 31, 2013, at 4:26 AM, Dave Crocker wrote: > >> With Kobe, the IAB prematurely terminated the community debate. > > > That's one perspective. > > What they really did was to say that TUBA/CLNP was in the lead. Sorry. Hadn't realized the IESG and the community all heard the wrong message and that the IAB misrepresented itself in its minutes: http://www.iab.org/wp-content/IAB-uploads/2011/03/IABmins.1992-06-18.txt > B. IAB PROPOSAL ON ROUTING AND ADDRESSING > > During its meeting in Kobe, Japan on June 18 and 19, the IAB reviewed > the draft report of the ROAD group concerning the problems of "running > out of IP network numbers" and "Internet routing table size explosion", > and a companion report from the IESG, "IESG Deliberations on Routing > and Addressing". > > The IAB's analysis of the many possibilities led to the following > conclusions, which are documented in an Internet-Draft entitled "IP > Version 7": > > ... > 4) Based upon an analysis of the architectural requirements, > the IAB furthermore proposes using CLNP (the OSI internetwork > protocol defined by the ISO 8473 standard, which uses > variable-length addresses that may be up to 20 bytes long) as the > starting point for developing IPv7. RFC-1347 contains an initial > description of how CLNP could be used for this purpose within the > current TCP/IP architecture and with the existing Internet > applications. However, further engineering will be required to > meet the Internet requirements of efficiency and functionality. My own reading comprehension is indeed often quite poor, but I don't see how to successfully apply your interpretation to this text. > At that point, the thought that something from OSI might be useful > triggered a religious counter-reaction and rationality left the > process. The v6 decision then became a popularity contest. For this topic, that reaction had been ongoing since 1990, when the topic was first engaged. Long painful history. In spite of that, CLNP was getting an equal hearing by the community-in-toto, if not by each individual separately. Welcome to the IETF. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From scott.brim at gmail.com Wed Jul 31 09:35:33 2013 From: scott.brim at gmail.com (Scott Brim) Date: Wed, 31 Jul 2013 18:35:33 +0200 Subject: [ih] [IP] OSI: The Internet That Wasn't In-Reply-To: <51F932E9.9060802@dcrocker.net> References: <51F7BF36.2060702@meetinghouse.net> <51F89462.7080002@dcrocker.net> <51F8C59F.6060407@dcrocker.net> <51F8F465.7060208@dcrocker.net> <229F34E5-BAA5-4BDB-9751-F512E6D816AC@pi-coral.com> <51F932E9.9060802@dcrocker.net> Message-ID: Yah. Maybe they didn't mean to but what they said was that they had decided. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhc2 at dcrocker.net Wed Jul 31 11:01:44 2013 From: dhc2 at dcrocker.net (Dave Crocker) Date: Wed, 31 Jul 2013 20:01:44 +0200 Subject: [ih] [IP] OSI: The Internet That Wasn't In-Reply-To: <14BE774C-BAF2-44BD-AF1F-2FEA671A6050@pi-coral.com> References: <51F7BF36.2060702@meetinghouse.net> <51F89462.7080002@dcrocker.net> <51F8C59F.6060407@dcrocker.net> <51F8F465.7060208@dcrocker.net> <229F34E5-BAA5-4BDB-9751-F512E6D816AC@pi-coral.com> <51F932E9.9060802@dcrocker.net> <14BE774C-BAF2-44BD-AF1F-2FEA671A6050@pi-coral.com> Message-ID: <51F95108.8090202@dcrocker.net> On 7/31/2013 7:48 PM, Tony Li wrote: > I read the word "proposes". I think that's still an invitation to debate, not a closure of it. Ahh. I see the disconnect here. You don't remember the way the IAB asserted itself onto the community, with very significant regularity. Please note my earlier use of the word "festering". d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2 at dcrocker.net Wed Jul 31 14:49:51 2013 From: dhc2 at dcrocker.net (Dave Crocker) Date: Wed, 31 Jul 2013 23:49:51 +0200 Subject: [ih] [IP] OSI: The Internet That Wasn't In-Reply-To: <2DF72B57-BE3C-4FE3-86D7-15169BB23DE8@pi-coral.com> References: <51F7BF36.2060702@meetinghouse.net> <51F89462.7080002@dcrocker.net> <51F8C59F.6060407@dcrocker.net> <51F8F465.7060208@dcrocker.net> <229F34E5-BAA5-4BDB-9751-F512E6D816AC@pi-coral.com> <51F932E9.9060802@dcrocker.net> <14BE774C-BAF2-44BD-AF1F-2FEA671A6050@pi-coral.com> <51F95108.8090202@dcrocker.net> <2DF72B57-BE3C-4FE3-86D7-15169BB23DE8@pi-coral.com> Message-ID: <51F9867F.9060804@dcrocker.net> On 7/31/2013 8:20 PM, Tony Li wrote: > On Jul 31, 2013, at 11:01 AM, Dave Crocker wrote: >> You don't remember the way the IAB asserted itself onto the community, with very significant regularity. > > There you go again, telling me what's going on within my own head. And it's as offensive as ever. An IETFer being consistently offensive over the course of 25 years. Who'd have thought? Does this mean I now need to worry about another glove challenging me to a dual? > Yes, I do recall that. It was an old boy's network. They were very respected, even when we didn't agree with them. They were trying to walk the fine line between exerting leadership and building consensus. While they misstepped, the community overreacted. There was no balancing act displayed in Kobe. It was a spontaneous and preemptive termination of the consensus effort that had been underway and making progress. The personal respect was the only reason the IAB wasn't summarily disbanded by the community, although the community's emasculation of the IAB came arbitrarily close. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From scott.brim at gmail.com Wed Jul 31 19:36:06 2013 From: scott.brim at gmail.com (Scott Brim) Date: Thu, 1 Aug 2013 04:36:06 +0200 Subject: [ih] [IP] OSI: The Internet That Wasn't In-Reply-To: <51F9867F.9060804@dcrocker.net> References: <51F7BF36.2060702@meetinghouse.net> <51F89462.7080002@dcrocker.net> <51F8C59F.6060407@dcrocker.net> <51F8F465.7060208@dcrocker.net> <229F34E5-BAA5-4BDB-9751-F512E6D816AC@pi-coral.com> <51F932E9.9060802@dcrocker.net> <14BE774C-BAF2-44BD-AF1F-2FEA671A6050@pi-coral.com> <51F95108.8090202@dcrocker.net> <2DF72B57-BE3C-4FE3-86D7-15169BB23DE8@pi-coral.com> <51F9867F.9060804@dcrocker.net> Message-ID: On Wednesday, July 31, 2013, Dave Crocker wrote: > There was no balancing act displayed in Kobe. It was a spontaneous and > preemptive termination of the consensus effort that had been underway and > making progress. > ... done with the best interests of the community in mind, based on the responsibility they had been given. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhc2 at dcrocker.net Wed Jul 31 22:56:43 2013 From: dhc2 at dcrocker.net (Dave Crocker) Date: Thu, 01 Aug 2013 07:56:43 +0200 Subject: [ih] [IP] OSI: The Internet That Wasn't In-Reply-To: References: <51F7BF36.2060702@meetinghouse.net> <51F89462.7080002@dcrocker.net> <51F8C59F.6060407@dcrocker.net> <51F8F465.7060208@dcrocker.net> <229F34E5-BAA5-4BDB-9751-F512E6D816AC@pi-coral.com> <51F932E9.9060802@dcrocker.net> <14BE774C-BAF2-44BD-AF1F-2FEA671A6050@pi-coral.com> <51F95108.8090202@dcrocker.net> <2DF72B57-BE3C-4FE3-86D7-15169BB23DE8@pi-coral.com> <51F9867F.9060804@dcrocker.net> Message-ID: <51F9F89B.4080503@dcrocker.net> On 8/1/2013 4:36 AM, Scott Brim wrote: > On Wednesday, July 31, 2013, Dave Crocker wrote: > There was no balancing act displayed in Kobe. It was a spontaneous > and preemptive termination of the consensus effort that had been > underway and making progress. > > > ... done with the best interests of the community in mind, based on the > responsibility they had been given. In terms of personal intentions, absolutely correct. That's a given -- or at least it was for me and everyone I talked to about it -- but I think it often serves to /increase/ frustration and therefore anger, rather than to mitigate it. Really intense anger is personal. We often find crass intent less emotionally inciting than well-intentioned arrogance by those we are close to... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net