On Oct 17, 2017, at 4:08 PM, den is via db-wg <db-wg@ripe.net> wrote:
Hi Colleagues
Rob is correct, option 1 has been proposed before and it was opposed. Whilst neither supporting nor opposing anyone's views let me ask a couple of questions. I think these questions need addressing even if it is just to quote some historic facts and dismiss them. It's always good to document that all angles have been considered in a decision.
For those with long memories, why was authorisation required from the origin ASN and is that reason still valid? (I think it was this point that blocked the last attempt to take this option.)
Well, my memory is that the routing registry was designed to express the routing policy of an AS, and all other objects were authorized on the basis of the holder of the AS. Adding authorization of the prefix holder in addition to the AS was the new authorization step for the route object in RFC2725. But you should really ask Curtis Villamizar, who did all the heavy lifting of the writing for RFC2725. I recall sitting wide-eyed as Curtis and Carol Orange discussed thorny routing issues. There are probably people around from RIPE who needed to do the implementation of the trust model. They might remember more. RIPE-120 of Oct 1994 said: Special Rules in the Routing Registry Because routes are originated by autonomous systems the autonomous system concerned should be the only one maintain- ing route objects. The maintainer of a route object is thus expected to be the same as the one of the aut-num object referenced in its origin attribute. RFC1786 of Mar 1995 says: Route object update procedures Adding a route object will have to be authorised by the maintainer of the originating AS. The actual implementation of this is outside the scope of this document. This guarantees that an AS guardian has full control over the registration of the routes it announces [11]. where [11] is a pointer to RIPE-120. —Sandy P.S. Carol Orange’s name was on the first two versions of the RFC2725 draft, but disappeared in -02. I don’t know why.
It has been said several times in this thread that dropping the origin auth requirement will bring the RIPE Database IRR into line with other IRRs and RPKI. But are we losing something from authorisation by doing this and are we dropping to the lowest common denominator?
cheers denis
co-chair DB WG
On 17 October 2017 at 17:05, Rob Evans <rhe@nosc.ja.net> wrote:
Hi,
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 support both of those. I’ll observe that there have been attempts to do (1) in the past that have floundered.
3) Consider possible, simple options to allow non RIPE resource holders to 'approve' (if not authorise) the creation of a foreign ROUTE object.
I wouldn’t want to lose the ability to make progress on (1) and (2) because we end up getting bogged down in the details of (3), which is what I fear will happen, so I’d put something like this on the back burner for now.
Cheers, Rob