Re: Problems with RIPE210

[Daniel Karrenberg <]

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