[db-wg] Fw: Foreign ROUTE objects in RIPE Database - final decision?

Hi Job


I agree with your assessment and, although it should be in a separate thread later, I think it's worth having a discussion about notifying resource holders if a foreign ROUTE object is created in the RIPE Database. But lets focus on the main points for now.
cheersdenis
co-chair DB WG

      From: Job Snijders via db-wg <db-wg at ripe.net>
 To: den is <denis1 at gmail.com> 
Cc: Database WG <db-wg at ripe.net>
 Sent: Tuesday, 17 October 2017, 10:06
 Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
  
Dear Denis,

Just to make sure we are on the same page, the 2 items presented by Bill
are not two mutually exclusive options, I think both need to be done. 

On Tue, Oct 17, 2017 at 01:04:08AM +0000, den is via db-wg wrote:
> 3) Consider possible, simple options to allow non RIPE resource
> holders to 'approve' (if not authorise) the creation of a foreign
> ROUTE object.

An even simpler option is to not even attempt to authorize the creation
of non-RIPE route objects, but simply flag them as "RIPE-NONAUTH". If
people want to create authoritive route objects for non-RIPE-managed
space they can create those objects in the DB from the RIR where the
space is managed (APNIC, AFRINIC, etc).

While on the surface of things, it looks trivial to have the RIPE
database software fire off an email to what most probably is the
legitimate 'foreign' owner of the IP block, it introduces quite some
complexity such as "what if the resource is transfer to a new owner"
"what if the resource is transferred to a new owner and a new RIR". Even
though at some point in the past a form of approval was given, a day
later that approval may have been revoked. The RIPE DB would have to
continuously track movement of IP space. 

The continuously tracking of ownership aspects in other databases
certainly can be done, but now the project no longer is simple low
hanging fruit. 

I see some value if the RIPE DB could notify owners of non-RIPE IP
blocks when non-authoritative data is created in the RIPE DB, but I
think that would be something to consider in the future.

Kind regards,

Job




   

   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20171017/a4838984/attachment.html>