69/8 is harder to fix than it looks at first glance

the problem is simple: outdated filters.

Agreed, more or less.

the solution is simple: tell people that their filters are out of date

Sorry, but this fixes nothing. It notifies people that a problem exists
but it doesn't fix the filters.

Several things need to be done for a lasting fix.

- we need to identify where the broken filters are.
- we need to find contact information for all those places.
- we need to notify all the places that their filters are broken.

Already, this is a heck of a lot of work and I would not describe this as
a simple solution. But now the real fun begins because all of those people
that were notified will reply.

- some will tentatively accept your info but ask for proof that their
filter is broken.
- some will strongly deny that anything is wrong with their filters
- some will ask what will fix their broken filter
- some will ask whether your fix is short term or whether it is general
enough to handle similar issues

And therein lies the crux of the problem. We have no good answer to this
last one other than to tell these people to change their filters today and
then to regularly hunt through some mailing lists or websites to find
notifications that the filters need to be changed again. And again. And
again and again and again.

When does it stop?

The fact is that are operating these 21st century networks using 19th
century business technology. This does not scale. The net is too big to be
managed by person to person exchange of information. That's why we have
DNS protocols instead of issuing updated copies of the hosts file. And
that's why we need an automated system to publish current status of IP
address ranges in a format that would be acceptable to firewall admins and
firewall vendors.

These people already trust LDAP enough to use it for distributing keys and
certificates. IP address range attributes are similar sorts of out-of-band
information that is not essential to packet forwarding but needs to be
distributed in order to configure devices correctly. In this case, the
attribute that we are primarily interested in distributing is whether or
not an IP address range has been allocated by ARIN for use or not. But
there are other useful attributes that could be distributed as well such
as contact information.

Let's all stop this lazy style of knee-jerk engineering that assumes all
problems are simple and can be solved using a router and some PERL
scripts. Some problems are hard technically and socially. These kinds of
problems can only be solved if you are willing to look at the big picture
as well as the immediate impacts.

--Michael Dillon

The DNS is managed by person-to-person exchange of information, and it scales. HOSTS.TXT was an example of a centrally-managed database, which didn't scale. Your examples seem to be backwards in some way.

Most of the Internet operates on the basis of person-to-person (or router-to-router, or AS-to-AS) information exchange, a characteristic which has *allowed* it to grow. Information which cannot be distributed in this manner frequently becomes troublesome to administer and mired in policy discussion with little forward momentum (e.g. the contents of the root zone, IP address assignments).

Saying that the Internet is too big for distributed information processing to scale (and promoting centralised management of information as a preferred alternative) is just odd.