Missing org: fields for direct allocations from RIPE
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.
Ronald This is more of an Address Policy issue than Database. But as you have raised it here, I will respond. You suggested that "I" told you to shut up and go away. If you have ever felt anything I have said gave you that impression I apologise. In fact for years I have been trying to do the opposite. I want more people involved in discussions about internet operations and decision making. So legacy space. I am sure addressing experts will correct me if I am wrong. As I understand it, the 'owners' of legacy space have 3 options. They can convert it to ALLOCATED PA and it becomes RIPE NCC allocated space. Or they can have a contract with the RIPE NCC to get some benefits but it remains legacy space and their property. Or they can just document it's existence in the RIPE Database and remain completely anonymous. In this latter case they don't have to identify themselves, follow any RIPE policies or procedures or link the address space to any organisation. They just exist in the shadows. I didn't realise this latter case still existed to the extent it does. I was told recently that there is still a lot of legacy address space in the RIPE Database that the RIPE NCC has no idea who is accountable for it and has no means of contacting anyone in relation to it. Now personally I totally agree with you. I think it is crazy to have address space documented in the RIPE Database that is owned by unidentified and unaccountable people. When writing policy proposals we have to be clear that it will only apply to legacy space that is subject to a contract with the RIPE NCC. We can't impose policies on this unaccountable space. A lot of this legacy space is owned by honest people and used responsibly, but for some reason they still wish to remain anonymous. It makes no sense to me at all. Every IP address is identical to every other IP address in terms of how it is used. There should be no difference in how it is accounted for. I don't care how they own it or by what contract terms. If it is used for a public network then the public should have the same information about who is using it. I have been told many times that even if the RIPE community was to approve a policy requiring all legacy space to be fully documented and accountable for in the RIPE Database, there is no legal means to enforce such a policy. cheers denis co-chair DB-WG On Fri, 29 Apr 2022 at 00:50, Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
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
In message <CAKvLzuEjrfJ6zxuxOffwV+iwvSviyAObVdnGiQ96keybezH3uQ@mail.gmail.com>, denis walker <ripedenis@gmail.com> wrote:
Now personally I totally agree with you. I think it is crazy to have address space documented in the RIPE Database that is owned by unidentified and unaccountable people. When writing policy proposals we have to be clear that it will only apply to legacy space that is subject to a contract with the RIPE NCC. We can't impose policies on this unaccountable space.
Excuse me denis, but we Americans like to call a spade a spade, and this... everything you've written and that I've quoted above... is all nothing but bovine excrement, sleight of hand, and legalistic obfuscation. You throw up irrelevant arguments about who owns the IP space, when everything that *I* have said makes it clear that I don't give a damn about THAT can of worms. The *real* question has nothing whatever to do with who owns or who controls the various chunks of legacy IP space in question. The *actual* question is just this: Who owns the RIPE data base? Does that belong to RIPE, or what? Can RIPE from time to time make adjustments in the contents of the data base, e.g. it order to regularize and normalize it, as may be either necessary or convenient FOR THE USER BASE, or is either RIPE or RIPE NCC, actually, formally, and (most importantly) *legally* constrained and prevented from ever even sweeping out the ancient, annoying, and counterproductive cobwebs from its own data base? You know... the one that it maintains and that it publishes for the benefit of every Internet user on planet earth? As long as RIPE and RIPE NCC do not materially screw around with the alleged legal (or extra legal) rights of the alleged "owners" or "registrants" (as you may prefer), e.g. "rights" (asserted but never even proven) to the full use and enjoyment of said IP address blocks, then who the hell gives a damn if RIPE performs a small amount of data base clean-up, adjustment, or modernization from time to time? Nobody, that's who. And to be clear, I have *not* made *any* suggestion that RIPE or RIPE NCC should do anything whatever that might have *any* material impact on, or effect on *any* of the alleged rights of *any* legacy block registrant. To suggest otherwise is to grossely mischaracterize both my goals and what I have actually said. The data base may be brought into a more consistant and regularized state without having any effect whatsoever on *any* registrant... except that it may make their stuff a bit easier to find via WHOIS queries, as I have illustrated. Have you ever gone to a dentist and had your teeth cleaned? Or are you walking around now with the most smelly and unsightly mouth on your side of the Atlantic? Routine maintenance and/or periodic upgrades destroys nothing of value. Quite the opposite. These things -preserve- a resource so that it will have lasting value. Have there not been, over time, innumerable other "enhancements" made to the data base to make it more internally consistant or more useful? If so, then what is the problem with simply arranging that every IP block allocation has an associated org: field and an associated organisation: record? What makes this simple, reasonable, and minimal adjustment into some sort of inviolable sacred cow? Is it just the fact that this rather obvious fix was suggested by one of those brutish, ill-mannered and ill-tempered Americans that makes the idea unacceptable? I say again, EVERY OTHER ONE of the other four Regional Internet Registries support WHOIS queries that make it trivially easy to obtain lists of ALL of the IP blocks currently assigned to a given organization. Every one. But as is often the case, Europe insists of its right to make things more complicated than they either need to be or than they should be. I suppose that by now I should not be surprised. I'm sorry, but I am short on patience these days, and I'm frankly offended that I find myself obliged to kill quite this many electrons just to defend an altogether simple and indeed trivial proposition that in any sane world would require no defense. Regards, rfg P.S. I am *still* waiting for my suggestion to force all handles in the data base to upper case to receive at least some comment. But I guess that I shouldn't get my hopes up. P.P.S. What the devil ever happened to plan to cease publishing the so- called NOAUTH data base? My dim recollection is that that was supposed to happen at the end of the first quarter of 2020, or at the end of the first quarter of 2021, or at the end of the first quarter of 2022. I confess that I don't even remember anymore, because the past 2+ years have all been kind of a blur for me. I feel quite sure however that this was supposed to have been completed by now, and yet it appears that the NOAUTH data base is still being published.
Ronald This style of email achieves nothing and is unacceptable on this mailing list. Most people don't read long emails at all. The language you use like "bovine excrement", "You throw up irrelevant arguments", "do not materially screw around" has no place in a professional discussion. You are insulting the entire RIPE community by your domineering attitude, suggesting we are all idiots for not listening to some great American prophet who knows better. You also ignore the fact that the majority of the RIPE community are not native English speakers, so your use of fancy words and expressions is totally wasted. On Fri, 29 Apr 2022 at 12:02, Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
In message <CAKvLzuEjrfJ6zxuxOffwV+iwvSviyAObVdnGiQ96keybezH3uQ@mail.gmail.com>, denis walker <ripedenis@gmail.com> wrote:
Now personally I totally agree with you. I think it is crazy to have address space documented in the RIPE Database that is owned by unidentified and unaccountable people. When writing policy proposals we have to be clear that it will only apply to legacy space that is subject to a contract with the RIPE NCC. We can't impose policies on this unaccountable space.
Excuse me denis, but we Americans like to call a spade a spade, and this... everything you've written and that I've quoted above... is all nothing but bovine excrement, sleight of hand, and legalistic obfuscation.
You throw up irrelevant arguments about who owns the IP space, when everything that *I* have said makes it clear that I don't give a damn about THAT can of worms. The *real* question has nothing whatever to do with who owns or who controls the various chunks of legacy IP space in question. The *actual* question is just this: Who owns the RIPE data base? Does that belong to RIPE, or what?
"irrelevant" in your opinion. " everything that *I* have said makes it clear that I don't give a damn about THAT can of worms" and of course YOU are always right...
Can RIPE from time to time make adjustments in the contents of the data base, e.g. it order to regularize and normalize it, as may be either necessary or convenient FOR THE USER BASE, or is either RIPE or RIPE NCC, actually, formally, and (most importantly) *legally* constrained and prevented from ever even sweeping out the ancient, annoying, and counterproductive cobwebs from its own data base? You know... the one that it maintains and that it publishes for the benefit of every Internet user on planet earth?
As long as RIPE and RIPE NCC do not materially screw around with the alleged legal (or extra legal) rights of the alleged "owners" or "registrants" (as you may prefer), e.g. "rights" (asserted but never even proven) to the full use and enjoyment of said IP address blocks, then who the hell gives a damn if RIPE performs a small amount of data base clean-up, adjustment, or modernization from time to time?
Nobody, that's who.
And to be clear, I have *not* made *any* suggestion that RIPE or RIPE NCC should do anything whatever that might have *any* material impact on, or effect on *any* of the alleged rights of *any* legacy block registrant. To suggest otherwise is to grossely mischaracterize both my goals and what I have actually said. The data base may be brought into a more consistant and regularized state without having any effect whatsoever on *any* registrant... except that it may make their stuff a bit easier to find via WHOIS queries, as I have illustrated.
To be. clear this is exactly what you are suggesting. You are demanding that the RIPE NCC adds personal data relating to the owners of legacy address space into a public database without the consent of those natural persons or any community agreed policy. This would be in violation of European privacy laws and the rights of those individuals.
Have you ever gone to a dentist and had your teeth cleaned? Or are you walking around now with the most smelly and unsightly mouth on your side of the Atlantic? Routine maintenance and/or periodic upgrades destroys nothing of value. Quite the opposite. These things -preserve- a resource so that it will have lasting value.
Have there not been, over time, innumerable other "enhancements" made to the data base to make it more internally consistant or more useful? If so, then what is the problem with simply arranging that every IP block allocation has an associated org: field and an associated organisation: record? What makes this simple, reasonable, and minimal adjustment into some sort of inviolable sacred cow? Is it just the fact that this rather obvious fix was suggested by one of those brutish, ill-mannered and ill-tempered Americans that makes the idea unacceptable?
I say again, EVERY OTHER ONE of the other four Regional Internet Registries support WHOIS queries that make it trivially easy to obtain lists of ALL of the IP blocks currently assigned to a given organization. Every one. But as is often the case, Europe insists of its right to make things more complicated than they either need to be or than they should be.
I suppose that by now I should not be surprised.
I'm sorry, but I am short on patience these days, and I'm frankly offended that I find myself obliged to kill quite this many electrons just to defend an altogether simple and indeed trivial proposition that in any sane world would require no defense.
Community consensus requires patience. Your lack of patience is no excuse to offend an entire professional community. cheers denis co-chair DB-WG
Regards, rfg
P.S. I am *still* waiting for my suggestion to force all handles in the data base to upper case to receive at least some comment. But I guess that I shouldn't get my hopes up.
P.P.S. What the devil ever happened to plan to cease publishing the so- called NOAUTH data base? My dim recollection is that that was supposed to happen at the end of the first quarter of 2020, or at the end of the first quarter of 2021, or at the end of the first quarter of 2022. I confess that I don't even remember anymore, because the past 2+ years have all been kind of a blur for me. I feel quite sure however that this was supposed to have been completed by now, and yet it appears that the NOAUTH data base is still being published.
--
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
participants (2)
-
denis walker -
Ronald F. Guilmette