LDAP is where this kind of technology is going, I agree. But until such time as this is deployed, we'll still be using email and publishing information on the website. It can also be noted that those that create filters, have to get the information from somewhere - they most likely got it from email and website and these are the places where updates should go (and on websites listing currently allocated blocks, there should be BIG notice that information here will change and those using it should come back and check on it every few months) Also in my view it is responsibility of whever has the filters to keep them updated - they are taking a chance that this might not remove legitimate traffic (and take their time to create and deply the filter) and so they should have the time to maintain the same filter. In my view the whole point of discussion here was that 1 month is NOT enough for everybody involved to know about new block being made available for allocations by RIR. What has been suggeted which is good is to have large RIRs (ARIN, APNIC, RIPE) keep one class-A on reserve ready for new allocations and when they begin allocating from such block, then there would be 6 month or year in advance notice about next block that allocation would be made from. Such policy of having one "extra" class-a allocated to RIRs should be discussed by either ICANN ASO or by yet-to-be-formed NRR (number resource registry). On Mon, 9 Dec 2002 Michael.Dillon@radianz.com wrote:

...

That is a good point, but you are talking about a periodic notification when new blocks are allocated. Michael is talking about an automated feed of all unallocated blocks.

I'm talking first of all, about a directory listing all the unallocated space that people can query. Secondly, I'm suggesting that this same set of data could be published by ARIN using BGP to make it easier for people to monitor changes.

...

If we were to invert this and say that ARIN will provide a list of all blocks that are allocated to it, then that might be worth doing.

I specifically suggested that ARIN provide a list of unallocated blocks because otherwise everyone else has to suck down the entire database of allocated blocks and invert it themselves. If they screw up their inversion algorithm that creates further problems.

In an ideal world, IANA would provide a top-level LDAP directory of the entire IPv4 address space with referrals for each large allocation to the RIR LDAP servers just like the DNS delegates a domain to other DNS servers. But it is just as workable for the 4 RIRs to work out some other way of synchronizing the top level of the IPv4 address space and for all 4 of them to publish the entire data set in their local (topologically speaking) servers.

...

However, I get back to my original question. For people who insist on filtering unallocated address space, is it too much to ask that they either subscribe to NANOG, or potentially subscribe to an RIR-specific announce-only mailing list for such things?

Yes. This is the 21st century. Mailing lists are a 19th century technology (memorandums) dressed up with a bit of 20th century technology. We can do better. If we can create routing protocols that dynamically distribute routing topology data, then we can surely come up with an automated way of distributing the IPv4 allocation data. People who are scared of automation can insert the human being inside their own domains of control. But let's use some network protocols for the core distribution of the data.

...

It seems really silly to me for the registries to spew a mailing to their entire contact database just to reach a handful of people who actually do route filtering.

Yes, spewing out email to solve a simple database synchronization problem seems counter-productive to me. Even a plain ASCII text file mirrored with rsync polling would be a vast improvement over email. But LDAP is proving to be the direction that the world is moving in for this type of directory service so why not leverage the tools and expertise that are available out there?

-- Michael Dillon