In message <563EB931.9030405@yahoo.co.uk>, denis <ripedenis@yahoo.co.uk> wrote:
... {lengthy discussion of contractual issues snipped} ...
I think we may be getting lost in the weeds here, so I'd like to back up and just briefly summarise the view from 30,000 feet, and then make a rather simple informal proposal. Firstly, things have gotten a bit confused (and confusing)... for which I take responsibility... because I've jumbled together several different very imformal proposals which I have either stated clearly, or implied by my previous comments in this thread. I'd like now to separate those (3) all out and state each one clearly, and then summarize the main objections (4), and finally propose a simple solution that may lay to rest many of the objections. My three informal proposals are basically as follows: 1) That RIPE NCC should be tasked to attempt to verify, preferably via automated means, the actual existance of the snail-mail addresses given in those RIPE WHOIS data base objects that contain such addresses, and to take some (as yet unelaborated) appropriate action in cases where said addresses appear to be un-real. This could be done either for all RIPE WHOIS data base objects that contain a snail-mail addresses or else optionally (and less effectively) only for new ones created after some given date. This process would not involve any kind of contact whatsoever between RIPE NCC and any individual resource holder(s). In those cases where snail-mail addresses were found to be invalid, RIPE NCC might undertake one or more of the following remedial actions, depending on community preferences: a) Attempting to make direct contact with either the relevant end-user, or the relevant LIR, or both, to encourage them to correct the relevant (snail-mail address) data. b) Inserting into the relevant WHOIS data base record an annotation indicating that the mailing address associated with that record cannot be verified as being legitimate. (I believe that ARIN has already been doing something along these lines for some time now.) 2) That RIPE NCC should be tasked to attempt to verify, preferably via automated means, the actual existance of (and simple operability of) the voice and/or FAX telephone numbers given in those RIPE WHOIS data base objects that contain such numbers, and to take some (as yet unelaborated) appropriate action in cases where said numbers appear to be either un-real or non-functioning. This could be done either for all RIPE WHOIS data base objects that contain phone numbers or else optionally (and less effectively) only for new ones created after some given date. As for proposal (1) above, RIPE NCC would also be tasked with attempting to effectuate some kind of remediation of the problem in those cases where the telephone numbers involved appear to be either un-real or non-functioning. That remediation might consist only of attaching annotations to the relevant data base records that fail the simple "is it working" test, or might optionally involve RIPE NCC contact with either the relevant end-user or the relevant LIR or both to encourage them to correct the relevant phone number data. In this case, RIPE NCC would have virtually no direct contact with the end users, other than placing an outbound call to each one and then, via automated means, detecting either "disconnected" or "continuously busy" results. (It would also be worthwhile, I think to automatically detect cases where alleged voice numbers actually go to FAX machines, or where alleged FAX numbers go to something other than a FAX machine.) 3) That RIPE NCC should be tasked to attempt to _validate_, preferably via automated means, the actual association of the voice and/or FAX telephone numbers given in those RIPE WHOIS data base objects that contain such numbers, and to take some (as yet unelaborated) appropriate action in cases where it is unable to validate said telephone numbers. (Note that this is an arguably more invasive, and thus perhaps also a more controversial proposal which, if adopted, would supplant proposal (2) above.) This could be done either for all RIPE WHOIS data base objects that contain phone numbers or else optionally (and less effectively) only for new ones created after some given date. As for proposals (1) and (2) above, RIPE NCC would also be tasked with attempting to effectuate some kind of remediation of the problem in those cases where the telephone numbers involved cannot be validated. That remediation might consist only of attaching annotations to the relevant data base records that fail the validation test, or might optionally involve RIPE NCC contact with either the relevant end-user or the relevant LIR or both to encourage them to correct the relevant phone number data. Those are the proposals. (It may seem as if I have couched them in very formal terms, but these _are_ still very strictly, and very obviously, only informal ideas, and I present them only for discussion purposes.) Now that I've clarified what I believe has been discussed in this thread... or at least my personal hopes relevant to the general notion of data base consistancy checking, I will summarize what I believe are, very broadly, the four types of objections to any or all of the above three proposals: 1) None of these 3 things _should_ be done, e.g. due to privacy concerns. 2) None of these 3 things _should_ be done, e.g. due to costs involved. 3) None of these three things _can_ be done, due to insurmountable technical issues. 4) None of these three things _can_ be done, due to insurmountable legal issues. If there is a community consensus supporting objection (1) above, then that pretty well ends the discussion right there. If on the other hand, there is _not_ a community consensus supporting objection (1) above, then I would put forward the following rather modest proposal: Be it resolved that RIPE NCC staff, both technical and legal, shall be tasked to prepare a report, to be delivered to the entire RIPE membership within 30 days, in which RIPE NCC staff will provide their professional evaluations of the both the technical and legal feasibility (or lack thereof) of each of the three proposals set forth above, together with preliminary (and non-binding) cost and schedule estimates for the implementations of each. All of us armchair lawyers and technical experts can, if we choose, spend (waste?) a lot more bits here, arguing ad infinitum about our various opinions about either the technical or legal challenges to a project of this type. But I personally discount a lot of that, perticularly when it comes to our discussion of the legal issues, because we simply do not have the facts. (And as it is often said, anyone can have an opinion.) My modest proposal above would seek the facts from the people who actually know them. This seems a prudent way to proceed, especially as it does not actually commit anybody to doing anything in particular, other than to study and report on the possible implementation issues. Regards, rfg