Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
Hi Guys: How about not change any status in BD until we have an automated API to deal with this. How about Just simply send an email the the holder in foreign database to notify them properly. I think the biggest problem we have here is not foreign route object being created, but rather they being created without holder’s knowledge. On Tue, Oct 17, 2017 at 09:03 den is via db-wg <db-wg@ripe.net> wrote:
3) Consider possible, simple options to allow non RIPE resource holders to 'approve' (if not authorise) the creation of a foreign ROUTE object.
cheers denis co-chair DB WG
On 17 October 2017 at 01:23, William Sylvester via db-wg <db-wg@ripe.net> wrote:
---------- Forwarded message ---------- From: William Sylvester <william.sylvester@addrex.net> To: Database WG <db-wg@ripe.net> Cc: Bcc: Date: Mon, 16 Oct 2017 23:22:55 +0000 Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final
Db-wg members,
Now that there has been substantial discussion on this topic, I wanted to try to bring the conversation back to a more practical and actionable
decision? path forward. Clearly this is a topic where there are a lot of opinions. From seeing the discussion and receiving additional feedback, I wanted to point out some re-occurring themes and request a revised proposal for working group consideration.
1) Remove the "origin:" authorization requirement. RIPE is currently the
only RIR that requires this, the current implementation creates data concurrency issues across Internet databases by requiring the creation of duplicate autnums.
2) Flag "route:" objects for non-RIPE-managed space with "source:
RIPE-NONAUTH" to identify non-authoritative data.
I’d like to seek input from the group;
- Do you feel these options are straight forward and easy to understand? - Does this provide a reasonable security posture? - Will this make a positive impact for RIPE DB and the greater Internet? - Do you support these concepts?
Thanks, William Db-wg co-chair
-- -- Kind regards. Lu
participants (1)
-
Lu Heng