Re: Merging RRP and Whois

On Fri, 26 Jan 2001, Bill Manning wrote:

> % 
> % I have envisioned the following rough sequence of events/solution as
> % minimizing the required effort (by the ProvReg group and others) while
> % maximizing the achieved benefits.  I want to make this explicit, in
> % case some of the discussion here resulted because of confusion.
> % 
> %   1. The ProvReg group designs a protocol.  This protocol allows/assumes:
> %       * A centralized object repository (registry) is assumed.
> 
> 	Why is this assumption in place?
> 	One could (rightly) argue that the single largest cause of
> 	instability and scaleability is the insistance on using 
> 	"A centralized ... repository".  The problems with that 
> 	tactic caused the original IR to segment into multiple
> 	regional IRs, each retaining/maintaining "A centralized
> 	repository". Its gotten worse with the addition of each new
> 	"routing database" & whois service by agency.  Each presumes
> 	a single "centralized repository".
> 
> 	I'd rather see a protocol to allow a composite, non authoritative
> 	structure be fabricated from collections of hundreds/thousands 
> 	of broadly distributed attributes. That way I would own my 
> 	data and be able to direct its distribution to/through others
> 	non-auth copies of my data.

Agreed.  As a simplifying assumption, a master data source is nice.  
But I can see a migration path from the current RIR (APNIC, ARIN, and
RIPE NCC) and IRR (RADB, RIPE NCC, etc.) registries to a system that
doesn't involve a centralized, or even a heirarchical, structure.  Some
centralization may end up being required (e.g. the standardized NIC
handle format you mentioned earlier), but that doesn't mean we need a
Registry/Registrar setup for all data sets.

Again, RRP evolved into a Faster, Stronger, Smarter RRP doesn't really
do anything for non-domain Whois users.

Shane