{'Borrowing' a new, more appropriate Subject: from a private reply...} > From: John C Klensin <john-ietf@xxxxxxx> > What does this say about the IETF and how we make decisions? Does that > need adjusting? Perhaps, but even I shrink from tackling that particular windmill! > while ... recriminations based on hindsight may be satisfying in some > ways, the question is what to do going forward. I couldn't agree with your latter point more. > There are communities out there who believe that we have managed to > "prove" that datagram networks, with packet-level routing, are a > failure at scale and that we should be going back to an essentially > connection-oriented design at the network level. I (perhaps obviously) think that's a rash conclusion: the circa 1975 Internet architecture was never intended to grow to this size, and that it has done so at all (albeit via the use of a number of hacks, some merely kludgy, others downright ugly) is a testament to how well the basic concept (of unreliable packets, and minimal state in the network) works. I do think that the architecture does require some work, though, and for a number of reasons. For one, the real requirements have become more complex as the network has grown, and a number that have arrived (e.g. provider independence for users; the need for ISP's to be able to manage traffic flows; etc) aren't really handled well (or at all) by the existing architecture. For another, we need to bring some order to the cancerous chaos that has resulted from piecemeal attempts to deal with the previous point. Finally, it's a truism of system design that arrangements that work at one order of scale don't at another, and as the network has grown beyond almost our wildest expectations - and certainly larger than it was ever designed to - I think we're seeing that too. > If not, then there are other focused discussions that would be helpful. > The latter discussions that have almost started in this and related > threads, but have (I believe) gotten drowned out by the noise, personal > accusations about fault, and general finger-pointing. Well, sometimes one has to clear the air (or underbrush, if you will), and get everyone's minds open, before one can make forward progress. But I agree, 'hah-hah, your end of the ship is sinking' rapidly becomes totally unproductive. > How would you propose moving forward? Well, IMO there are a number of things we need to do, which can be done all in parallel. The first is to be honest with ourselves, and with the people out there who depend on us to set direction, about what's really likely to happen out in the network; e.g. a very long period during which we are stuck with multiple naming realms with various kinds of translators (NATxx) gluing them together. This whole 'don't worry, everything will be fine' schtick has got to go - we're now in what I call "The Emperor's New Protocol" land, where (almost) everybody knows the theoretical plan isn't going to work, and major revisions are needed, but nobody wants to come right out and say so formally. We need to do that. I think a group (set up by the IAB, who make these kind of pronouncements) should sit down and draw up a _realistic_ picture of what the future over the next couple of years (say, up to 5 years out - 5 only, because of a second parallel effort, below) is likely to be, and get that out, so people have a realistic appraisal of how things stand (and restore a little bit of the I*'s credibilty, in the process). That group (or perhaps a sister group) should produce a formal statement covering the implications for IETF work of that present/future; i.e. about the _existing_ architectural environment in which the protocols the IETF designs have to operate, and thus have to be designed for. E.g. a formal IETF policy statement 'all IETF protocols MUST work through NAT boxes'. Etc, etc. The second is to set up a group (and again, this is the IAB's job) to try and plan some sort of evolutionary architectural path, which would have two phases: i) to survey all classes of stakeholders (ISP's, content providers, users) to see what the network needs to be able to do that it can't now, and ii) provide both a) an architecture that meets those needs, and b) a _realistic_ plan for getting there. Realistic in economic, interoperability, etc terms - all the things we have learned (painfully) are so critical to the viable roll-out of new stuff. Do note that that effort implies that the current solution _doesn't_ provide all those things. So we might as well swallow hard and admit _that_ publicly too. Whether all the above is politically feasible in the current IETF - who knows? If not, it's back to 'The Emperor's New Protocol' for another year or so, I guess, by which time the environment may be a bit more receptive. Noel _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf