Some considerable time ago I previously noted here the fact that there exists in the RIPE WHOIS data base some WHOIS records for what I personally would refer to as "top level" IP address block allocations (i.e. ones which were assinged directly by RIPE NCC to some specific RIPE member organization) and that contain no org: field which would otherwise associate these blocks with a specific organisation having its own organisation: record in the data base.
At that time, I was basically told (by denis, as I recall) that this was a historical artifact in the data base, that it would absolutely NOT be rectified, and that I should go pound sand. Having long ago become resigned to this level of respectful helpfulness when raising legitimate issues relevant to the RIPE data base here, I let it go, and I have not raised the issue again since that itme. Now however I feel that I have some clear and concrete basis for doing so. I call everyone's attention to the following post that I just made to the mailing list of the RIPE Anti-Abuse Working Group: https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2022-April/006346.html I should say that it is my (naive?) belief that (a) every operator of an inbound mailbox or an inbound mail server should have the right to decide for themselves when any given network is not worthy of having its inbound emails accepted, and also (b) RIPE and the RIPE WHOIS data base should not make the task of locally filtering inbound packets or emails from a given network any harder than it needs to be. As noted in the mailing list post linked to above, it is my desire to locally block all further inbound emails from the entire set of IPv4 CIDRs currently associated with the Dutch network which is alternatively known as Signet B.V. and/or TransIP B.V. (These people are clearly lack the requsite minimal level of competence to run a network from which outbound emails emmanate.) In any universe guided by either reason or simplicity it should be easily possible to find the ORG handle for any given (offending) network and then to use that handle as a "reverse" lookup key in a query to the relevant RIR data base and thus automatically derive the full set of IP address blocks currently assigned to the given organization. Unfortunately, and for reasons that have yet to be adequately explained, we do not live in that simple or rational universe, at least not when it comes to the RIPE WHOIS�data base. For quite some time now I have had a relatively trivial Perl script that does this exact job. I call it "org2cidrs". It works flawlessly when provided an ORG handle known to any one of the five Regional Internet Registries, except in the case of RIPE where, as I have noted above, some IP block allocations have no org: field and thus no connection to any particular organisation... at least none that could be automatically determined by a reverse WHOIS query based on some ORG handle. The bottom line is that although I have found it quite easy to deduce that the handle ORG-SI6-RIPE represents the offending organization that I would now like to block, a reverse (org) WHOIS query against the RIPE WHOIS server using that handle yields only a subset of the IP block allocations currently assigned to that organisation. More specifically, although the vast majority of IP blocks assigned to this organization do in fact have corresponding WHOIS records in the data base that -do- contain an org: field designating ORG-SI6-RIPE as the registrant organization, the following two blocks, both marked as "status: LEGACY", have no org: field present in their respective RIPE WHOIS records, and thus these allocation records are effectively invisible to any reverse WHOIS query using -any- ORG handle (e.g. ORG-SI6-RIPE) as lookup key: 136.144.128.0/17 157.97.168.0/22 I don't know how to say this delicately, so I will just say it. It is, in my opinion, fundamentally idiotic that every other one of the five Regional Internet Registries make it trivially easy to find ALL of the IP allocations associated with a given ORG handle, but that RIPE, for reasons that are apparently shrouded in mystery and/or which have long ago been lost to the sands of time, continues to insist on making what should be simple difficult. The last time I checked there were only on the order of about 122 "top level" RIPE IP block allocations whose corresponding WHOIS records failed to include an org: field. In each of these cases it would be trivially possible for RIPE NCC to manufacture an appropriate organization: record out of the information already in the data bases and/or information which is readily available on the web or from the actual organizations themselves. Once these new organisation: records were created it would also be trivial for RIPE NCC to insure that every single IP block allocation in the data base is associated with some ORG handle, thus simplifying automated processing of the data base -and- bringing its functionality into line with that of the other four RIR data bases. The fact that this has not already been done, especially in a case like the legacy blocks which clearly belong to ORG-SI6-RIPE, is, I think, indicative of some narrow-minded insistance on the preservation of past practices, even when those practices are, as in this case, provably detrimental to reasonable and serious users of the data base. Regards, rfg P.S. I have always and will always argue in favor of anything that simplifies the parsing and/or automated processing of WHOIS data base records. Having *every* IP block allocation record include an org: field would do just that. Furthermore, quite frankly I am both flummoxed and flabberghasted that a call was made here, some time ago, for suggestions on how to make it simpler to parse the data base, EVEN AS my simple, straightforward, and (I would have thought) obvious suggestion to represent all handles in the data base only and consistantly in upper case garnered -no- response from this working group whatsoever.
-- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
