Towards a Disjoint IRR
Daniel Karrenberg
Mon May 1 15:54:53 CEST 1995
> Curtis Villamizar <curtis at ans.net> writes: > > Why doesn't this seem like a problem to me? The RADB concentrates > data from CANET, MCI, ANS, anyone else with a registry in North > America and also bring in data from the other continents. Well does it? Not in my view of the world. + There are multiple Routing Registries (RR) which combined form the Internet Routing Registry (IRR). + Each RR has a unique value of the source attribute. (The current implementation of the IRR is to copy all known RRs. A slight improvement allowing dynamic updates to these copies is currently being implemented. There had been a proposal for a RR object to describe each RR and an IRR object to list the currently known RRs. This never came to pass, or didi it?) + Ideally each object is registered only in one RR. This it appears only once in the IRR + Each object can be registered in multiple RRs. This means it appears multiple times in the IRR. + If an object appears multiple times in the IRR, it is a local matter which ones take precedence. A convention is to order the responses of a whois server and give earlier answers for the same object priority. The current RIPE DB software has two config file options for this: -------- # default databases to do lookups in DEFLOOK RIPE # if all databases are selected (-a switch) ALLLOOK RIPE INTERNIC MERIT ALTERNET NCC-AS-LIST -------- The latter probably needs cleaning up ;-) > This is a problem, but why is this a registery problem? Am I missing > something? The questions now are: Q1) Should users be allowed to register objects in multiple RRs? The answer is YES because: - some RRs may require local registration for getting service - some RRs may abuse a single registry requirement Q2) Should users be encouraged to register objects in multiple RRs. The answer is NO because - it creates inconsistency problems Q3) Should RR operators register objects in their RR on behalf of users without the user's knowledge? It does not matter whether this is by copying from another RR or by other means. The answer is NO because - it creates inconsistency problems - it confuses the users Daniel -------- Logged at Mon May 1 16:26:30 MET DST 1995 ---------
[ rr-impl Archive ]