Hola all, Hanks message did make me think about something:
Why do RPSL objects not have a LIR identifier so that one can easily whois an object and see to which LIR it belongs to; as then a reverse search could be done on the LIR ID. We do have the 'org' and related 'organisation' objects but these do not directly map to a LIR. Thus have a 'lir-id' in the 'organisation' object would be very helpful too. Thus maybe, the better version is to always have an organisation object bound to each object and then a LIR linked to that? Thus something like: domain: 8.b.d.0.1.0.0.2.ip6.arpa descr: Example Reverse with LIR-ID nl.example admin-c: EXAMPLE1-RIPE tech-c: EXAMPLE1-RIPE zone-c: EXAMPLE1-RIPE nserver: ns1.example.net nserver: ns2.example.net ds-rdata: 44553 13 2 57a47aeb9e448adaef8b7d178e7b4bdc648b6663626a7f5f4fc4caef2e8bdb4f mnt-by: EXAMPLE1-MNT lir-id: nl.example created: 2021-07-04T22:41:34Z last-modified: 2024-07-05T09:47:38Z source: RIPE Note the 'lir-id' line added. And yes, for some historical/old data it might be tricky to add this, but for most objects it would be know what LIR an object belongs to. This would also make it clear which LIR is responsible for that object, especially useful in cases of connectivity issues or abuse; yes, abuse-c should exist; but that only helps if somebody answers..... at least now one can group objects to the same LIR easily, though of course mapping to ASN helps, an ASN can be under a different LIR. I would not be surprised that something like this was discussed when the 'organisation' object was introduced, but could not easily find something in $searchengine. Regards, Jeroen ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
