Hi Denis, On Tue, Oct 17, 2017 at 10:08:56PM +0200, den is via db-wg wrote: > Rob is correct, option 1 has been proposed before and it was opposed.
I am not sure 'opposed' is the correct word, throughout some of these processes trajectories, the lack of feedback proved to be a major obstacle. > 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.) I've never been able to figure out what the original reason was, other than that it was part of rfc2725. I do not know why it was put in RFC 2725. At the time (18 years ago) it probably seemed like a good idea. I cannot come up with reasons that were valid in the last 10 years, nor reasons that are valid now. There is one stubborn myth that if you can create a route object for an (any) origin ASN, that some ASNs will automatically start originating the prefix. I've not found evidence that this actually happens. Even if it did: if I as legitimate owner authorize an ASN to originate my prefix, and they do so, what is the issue? :) I'm sure we can find more myths, but the fact that aut-num authorisation is not required in virtually all other IRRs shows me that this there is no real necessity to do so. > 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? I think we are actually gaining something: we make it easier to correctly administrate resources. Right now We are in the awkward situation where it is easier to create a route object in RADB or NTTCOM than it is to create one in the RIPE DB. It is in everyone's interest to make it easy for RIPE stakeholders to create statements about routes. Kind regards, Job
