In message <1478836722.4807768.1564661218800@mail.yahoo.com>, "ripedenis@yahoo.co.uk" <ripedenis@yahoo.co.uk> wrote:

I am sure the more searching you do you may find more cases like this. But you are still making the same point. We hear you. Can you suggest any improvements to the process that will address any of the cases you have already highlighted?

I'm not sure that I've made, or been making only one point. More like three, if you count the extra one that somebody else (Nick?) raised in response to me recent posts here. I'll just give my views on these in order, from easy to hard... 1) There are some (arguably small) "inconsistancies" in the data base that could, and maybe even should be cleaned up. The upper/lower case of the field values for things like org-type: is perhaps the most minor and inconsequential of these. But to the extent possible, even small nits like this that might possibly hinder automated analysis could be and should be eliminated. The resource records that don't have org: fields is another example of this. I'm not sure if that should even be fixed, but I don't think that it would -hurt- anything if it were to get fixed. Software hates exception cases, and so do I. Call me anal retentive if you like. I don't mind. Anyway that data to fix these cases already does seem to be there, e.g. in the associated person; and role: records, so it is just a question of will and manpower. Some folks will feel it is worth it to fix this, and as surely as night follows day, other won't. I could probably find other oddities and seeming deviations from the "norm" in the data base records, given a few days, but who knows if any of those are worth even remarking on, let alone fixing. I sure don't. Not yet anyway. 2) Somebody (Nick) suggested a field to indicate whether or when a given ORG had been vetted. I think that's a damn fine idea, and I would certainly argue in favor of a date stamp and not just a binary flag. If there's a date stamp, then nosey busybodies (aka independent researchers) such as myself could look at that, and if we happen to notice that a given ORG was last vetted 7 years ago, but there are press reports that it went bankrupt or was bought out 4 years ago, then we can suggest to NCC that it may be time for another look at that ORG and its contact info, etc. 3) As I've pointed out, there are lots of cases (countries) in the RIPE region where it isn't clear how the bleep NCC could possibly vet the ORGs that claim to be incorporated there, other than asking the ORG itself for documents, and then just trusting that those haven't been forged and/or that the party preseting them does in fact have some actual, finite, and non-zero connection to the relevant ORG. Even though I may bitch about this... because it DOES worry me... I don't have anything I can put forward as a possible viable solution. I have no shortage of ideas of what I personally would *like* to see done with respect to either new or existing ORG registrations that arise from countries that are "hiding the ball" with respect to their national corporate registries, but based on my experience so far with the RIPE community and its requirements of near-universal consensus (for any change proposal) all of the ideas I might propose for dealing with this issue would have, I'm sure, about the same chances of being adopted as the proverbial "lead balloon". Just as significantly, or perhaps even moreso, if even the anti-money- laundering advocates in the EU can't manage to wedge open these national corpoarate registries, I'm not persuaded that RIPE could do any better, no matter kind of draconian measures it might adopt to try to encourage or even force such openings. What I do know, and what I can say is that it is self-evident that the current NCC vetting process, such as it is, is prone to abuse and must necessarily involve a great deal of blind trust in the parties claiming to represent the ORGs being vetted. Quite obviously, few other folks see this as a problem. I however do. My only hope is that by bringing the problem out of the shadows and throwing it onto the table, maybe someone, here or elsewhere, will suggest something viable that might improve, even if only incrementally, the current situation. Regards, rfg