Phill, Excuse top posting as I'm about to head to the airport. Yes, and I was one of the first to rant about middleboxes (RFC 2775 and 3234). But ranting is very different from being able to describe a systems architecture, and I think RFC 1958 was correct to argue that constant change is the only certainty. I suspect that's why no IAB since 1996 has really tackled this question. Regards Brian On 15/10/2014 08:21, Phillip Hallam-Baker wrote: > On Tue, Oct 14, 2014 at 2:41 PM, Brian E Carpenter > <brian.e.carpenter@xxxxxxxxx> wrote: >> On 15/10/2014 06:33, Phillip Hallam-Baker wrote: >>> We have an Internet Architecture Board. But we don't have an >>> architecture document. >> I believe the reason for that is stated fairly clearly in >> http://tools.ietf.org/html/rfc1958#section-1 and >> http://tools.ietf.org/html/rfc1958#section-2 > > Well first that document was written in 1996. A lot has changed since. > And lets read what you wrote: > > "2.1 Many members of the Internet community would argue that there is > no architecture, but only a tradition, which was not written down for > the first 25 years (or at least not by the IAB). However, in very > general terms, the community believes that the goal is connectivity, > the tool is the Internet Protocol, and the intelligence is end to end > rather than hidden in the network." > > Do we really believe that is true? If so there would have been no > complaints about NAT boxen and the like 'spoiling' the Internet > architecture. We would be completely happy with the free for all that > has happened since. > > I don't think that is the case that nobody has complained. And right > now we are having a long discussion in DPRIVE over whether DNSCurve is > the answer or not and the major complaint being made against DNSCurve > is that it just doesn't fit the Internet architecture. > > Oh and one of the reasons DNSCurve does not fit the architecture is > precisely because it attempts to remove recursive resolvers from the > DNS architecture making it an end-to-end protocol! > > What you are doing there is essentially choosing one of the interfaces > that I described and asserting that is the Internet Architecture. > Which might work fine if you only work at the Network layer. It does > not work at all well for those of us who work above that layer. And > especially not for folk working in the constrained device world where > you want to work out how a device that is not capable of supporting IP > fits into the Internet architecture model. > > > There are two types of problems caused by middleboxen. The first is > the 'problems' resulting from their intended purpose. A firewall will > stop inbound connections to random hosts inside the corporate network. > That may violate some people's ideology but it is what the box was > intended to do and people should get over the fact people want that. > > The second set of problems are second order effects caused by the > implementation and these are much harder to deal with because they are > essentially random. The middleboxes that decide to truncate all > messages on port 53 to 500 bytes in length for example. > > So right now there are two types of middleboxes, those that perform > their intended function without causing second order issues (type 1) > and those that cause second order problems (Type 2). I can describe > the difference subjectively but I can't give an objective definition > of what a well-formed middlebox is because I don't have objective > definitions of what the interfaces should look like. And without that > I can't eliminate Type-2 middleboxes. >