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.