as usual, i could be wrong, but ... i suspect that the reason euro ops think that 'foreign' objects are needed in the irr part of the ncc database is because foreign resources and foreign aut-num:s are used at euro ixen where there is a strong policy to be registered in the irr. combine this with the "if it is not done by our paternalistic ncc then we don't use it" culture, i.e. do not use radb etc., we're stuck with having the foreign stuff in the irr part of the ncc database. that the trustworthiness of these foreign data is no greater than if it was taken from its home irr, radb or whatever, should not surprise us. it is a global internet. when we 'regionalize' trust, the consequences become strange, though sometimes subtle. but then you know this quite well, being the rir with half a dozen rpki trust anchors. </sarcasm> randy

...

it is a global internet. when we 'regionalize' trust, the consequences become strange, though sometimes subtle. but then you know this quite well, being the rir with half a dozen rpki trust anchors. </sarcasm> Is this an ASO/ICANN issue?

no, it's an rir issue. the rirs get resources from the iana but are in stubborn denial that the iana is the root of the resource allocation tree. amateur power politics in a disfunctional family. randy

Dear George, From my lengthy article (trying to explain all the background) I think you picked out the two important words 'authority' and 'trust'. Having these 'foreign object copies' in the RIPE Database gives the perception of authority by the ASN resource holder and implies that they are an integral part of the routing integrity. In most cases that is probably true. But since 'anyone' can create these copies we allow authority to be bypassed. In some cases the actual resource holder may not even know these objects exist in the RIPE Database. In these cases the trust level is at best uncertain. It is difficult to see how you can weaken trust if the starting point is uncertainty. If we can remove the uncertainty, perhaps by adjusting the model, we increase the trust in the whole system. Regards Denis Walker Business Analyst RIPE NCC Database Team On 23/08/2013 02:07, George Michaelson wrote:

Thanks for writing this Dennis.

I brought a discussion up at the APNIC35 meeting, and from that into the RIPE66 meeting in Dublin, about the operational issues APNIC faces in region with route: objects requirements for co-signing by inetnum and aut-num holder, with low levels of participation and compliance in the region, compounded by the NIR model.

I realize its not identical to what you've written about, but I do think the problems co-relate: they come down to questions around the authority of creating data in IRR which relates to resources outside a strict control of that IRR, or not adequately maintained inside that IRR.

I am troubled by the aspect of the RIPE IRR which permits 'foreign' objects to be imported into the database, for use as referenced objects. It feels like this creates two classes of data authority: if the resources lie wholly inside RIPE NCC process management, they have strong visible authority to exist. If however, the RPSL object relates to an ARIN asn or an APNIC asn, you are in effect bypassing any access control over that object.

Yet, in my presentation in Dublin, the routing community present there very strongly objected to any weakening of trust in route: object protections and feel the ASN holder is an integral part of the protections of their routing integrity, and risks to router configuration.

I find these two situations contradictory. I'm not sure where to go with this thought, but its troubling.

I must point out that I work in the research section of APNIC and I am not involved in address policy, routing policy, or anything of that nature, and I am obviously outside the RIPE region and so don't have a direct role in the decision made in this community either.

cheers

George