> > I don't have any problem with IETF/IANA saying "the addresses formerly > > allocated to site-local will never be re-assigned". I do have > > a problem with IETF giving any support to the notion that it's > > reasonable to use site-local addresses. > > In the real world among adults and outside the delusions of those > who think standards committees are Powerful and In Charge, having > the IETF/IANA say "the addresses formerly allocated to site-local > will never be re-assigned" is indistinguishable from having the > IETF/IANA say "here are some site-local addresses; have fun." I think Vernon hits the nail on the head. A lot of the IETF's energy appears to be now devoted to shutting down someone else's ideas, on the basis that we, the clueful, must protect the Internet against the attacks of greedy and incompetent amateurs. In short, I see a lot of negative energy floating around. It is perfectly fine to review a specification, understand the intent of the original designer, and suggest ways to better achieve the same result. That is exactly what working groups are supposed to do. It is also perfectly fine, if the original designer won't change their design, to publish an alternative design that hopefully works better, and then rely on market forces to sort it out. But it is not fine to try to prevent the original designer from actually shipping products, either by preventing publication of the specification or by trying to prevent deployment. The publication game can be played in the working group, but the best tricks are used by the IESG. The two delaying tactics that I have seen so far are to request complete consensus on a "requirement document" before any progress can be made on a system design, or by simply sitting on a document submitted by the working group and let it rot in the IESG queue. The requirement trick is probably the most efficient: in practice, it can delay any work by two or three years. However, in the days of the web, the IESG can only control publication as an RFC; the unloved specification most often ends up published elsewhere. There is a lot of damage done to the IETF, but the ideas, good or bad, get documented. To really exercise power, one has to prevent deployment. The practical way to prevent deployment is to control the assignment of a resource required for the unloved design. The normal loop is through requiring IANA that some numbers can only be allocated following publication of an RFC. For example, a new MIME type can only be registered that way. Very often, this control is only nominal. Fore example, nothing prevents consenting software implementations to use unregistered MIME types. One of the remaining strongholds of the IESG, however, is the assignment of a range of addresses for a specific purpose. Today, the IANA will not do that without IESG approval, hence all the hoopla about site local addresses. I wish the attitude would change, but I am not too hopeful. So, maybe a solution is to as much as possible remove blocking powers from the IETF process. In particular, we should do something about the control of address ranges assignment. OK, for IPv4 that will be hard, but IPv6 has more resource. But maybe we should have a specific registry that assigns ranges of addresses to specific purposes, and have that registry managed in much the same way as the current registry of port numbers. -- Christian Huitema