In message <563eb931.9030...@yahoo.co.uk>,
denis <ripede...@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
