> 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.
not positive i get your intent here. but seems a lot as if you are hoping to apply an external formally defined authorisation structure to add artistic verisimilitude to an otherwise bald and unconvincing narrative, the irr. it is amusing to watch, after decades of failure on intra-irr authentication and authorisation, we are now going to a new fantasy where we restrict a registry to 'our' data; when the quality of the various rirs' data are mediocre at best. mr trump, the problem isn't nasty 'foreign' irr data raping our route6: objects. the problem is all irr data. folk are trying to whitewash quality and security decades ex post facto; a well known joke. what we need is a formally verifyable hierarchy whch matches the actual delegations, iana on down. oh, wait... randy
