My personal (and I stress personal) opinion moving forward, is that the use of an IRR really does not sit well with the management side of delegation of authority in a distributed model that we have right now.
If we move to a model where the IRR/RPSL "maintainer" is understood to be documentation and not the actual authority over change, we can discuss more rational mechanisms to certify (and I use that word deliberately) that a given person has shown their intent, and consent, to have a given IRR/RPSL statement made over their resources. If we did that, then any delegated authority over some INR should be able to make statements which validate the insertion into any IRR. The problem of course (wilfred: hello) is referential integrity. Which I cannot fix because this is a fundamental problem in distributed systems which have hierarchy of independent elements capable of withdrawing consent. I suspect the fix is to put maximum lifetime on things being retained without reference to an explicit permission granted from outside and then remove them. I don't configure routers. I therefore can't meaningfully comment on the costs on the configuration side, of this. -George On Wed, Feb 14, 2018 at 1:59 PM, Randy Bush via db-wg <db-wg@ripe.net> wrote: >>> This can be a separate effort. However, what I did not mention >>> earlier is that we probably should disallow the creation of new >>> out-of-region AUT-NUM objects if they are no longer required to >>> authorise ROUTE(6) objects. > > how long do you think it will be before there are no inter-region > barriers to AS transfers? add a year or so to that to give people > time to clean up the mess caused by this policy hole. > >> Yes, I support disallowing the creation of NEW out-of-region AUT-NUM >> and ROUTE objects. > > not exact;ly what tim was suggesting, see above. > >> I keep seeing route objects covering non-RIPE IP space popping up in >> the RIPE IRR for nefarious purposes. > > that may be the wrong question. are some appearing for legitimate and > useful purposes? if so, how will those needs be addressed going > forward? > > randy >
