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