Hi Douglas, group, On Tue, Aug 23, 2022 at 03:03:31PM -0300, Douglas Fischer wrote:
I was thinking a little about this case...
I'm almost certain that this case cited by Siyuan would have been avoided if there was a cross-check between the items contained in the AS-SET objects (and others such as the Route-Set), and the "member-of" attributes of the referred objects.
You are right that stronger 'arcs' ("connections") between the various IRR objects at first glance potentially offer a solution; unfortunately the objects exist in separate databases ("namespaces"), one has to be cautious for object name collisions! Cross-references (through "member-of:" <> "members:" links) for RPSL objects only work within a single IRR source, in other words: if objects exist in the same database. An object in one database can't reference (through 'member-of:') an object in a different database.
I participated in a small exchange of ideas about this, and there were questions about whether this crosscheck should be done by the consumer of the IRR data, or if it should be validated at the time of insertion in the base through NRTM.
As far as I understand the data model, only the ultimate consumer of IRR data would be in a position to enforce some kind of policy (such as requiring cross-references both ways 'members:' <> 'member-of:'); the middle layer (software packages like IRRD) lack context. I know of examples where fairly robust RTBH filters were generated using members:/member-of pairing as a prerequisite; but I'm not aware of a "cross-RIR" solution. Kind regards, Job