Any moving targets, such as prefixes for root NS connectivity, should be taken out of the document. A long time ago I have proposed to set up a registry for such prefixes roughly like this: specpref: 193.0.14.0/24 type: DNS ROOT descr: K Root Server admin-c: DK58 specpref: 128.250.0.0/16 type: DNS TLD descr: AU TLD Server admin-c: RE18 specpref: 193.0.0.0/22 type: WHOIS ADDRESS-REGISTRY descr: RIPE NCC Whois Service origin: AS3333 admin-c: DK58 specpref: 1.2.3.4/32 type: OTHER descr: The wrld's most important HTTP server admin-c: ABC789 one could add bogon filter info as well: specpref: 10.0.0.0/8 ORLONGER type: BOGON RFC1918 descr: Privaqte Address Space not to be routed on public Internet admin-c: IANA The beauty of this is that those responsible can dynamically update it. Those who want to make filters or flap dampening configs can do so using their own policies. Somehow this idea never caught on. I am not sure why because noone pointed out obvious flaws with it. The only slghtly hard thing about this is to agree on an initial set of "types". However once can limit this set initially and periodically look at the "OTHER" type entries to identify useful new categories. Also there needs to be someone verifying that entries for the defined types really match that type and some access-control preventing anyone to create entries. For authorisation of changes standard RIPE DB mechanisms can be used. I am sure we can find someone to do this initially. My suggestion for an initial list of types is DNS ROOT DNS TLD WHOIS TLD WHOIS ADDRESS OTHER If there are two others who would like to join writing this up as a spec I will be happy to donate a few spare minutes to contribute and to edit it. If there are serious flaws with this, let's hear them. Daniel