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.


On Wed, Feb 14, 2018 at 1:59 PM, Randy Bush via db-wg <> 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

Reply via email to