[routing-wg] [db-wg] Solving the issue of rogue ROUTE objects in the RIPE Database

Hi,

On Sat, Nov 07, 2015 at 01:15:37AM +0100, Job Snijders wrote:
> My question from earlier in the thread still stands: should RIPE IRR
> attempt to be a global IRR and do its best to authenticate data itself
> (as per Denis' proposal), or should RIPE IRR continue to work to
> transfer objects to the appropiate RIR's IRR and let their respective
> communities work with those RIRs to authenticate the data (if needed)?

The way the question is phrased imlies some bias :-)

No, the RIPE IRR should not attempt to be a global IRR.  *But* there is
benefit for network that exclusively operates in the RIPE region to tell
its peers and upstreams "my prefixes are registered in the RIPE DB!",
even if they have the oddball prefix or customer that is from a foreign
RIR.

So, *short term*, I'd like to see support in the RIPE DB for registering
out-of-region prefixes (and I think Denis' proposal has merits, technical
details to be fine tuned by the NCC).  We have a data integrity problem
right now, and this needs to be solved short term without losing 
functionality.

*Long term*, we need something better, for world wide route registration
and authentication.  If we can solve the short-term issue quickly, we can
build something good, in the time scales it takes if 5 RIRs are involved,
one of them having too many lawyers and being not really trusted by its own 
members.

Gert Doering
        -- network operator
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: </ripe/mail/archives/routing-wg/attachments/20151107/c437472c/attachment.sig>