Subject: RE: accusations of cluelessness

From: "Christian Huitema" <[email-masked]>
Date: Sat, 11 Oct 2003 21:31:53 -0700

> > 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

---

From: Keith Moore <[email-masked]>
Date: Sun, 12 Oct 2003 01:18:05 -0400

> preventing publication of the specification or by trying to prevent

On the contrary, it is our duty to do all of these things.

What is not fine is for participants to expect IETF to lend its support to bad
designs.