[anti-abuse-wg] WHOIS (AS204224)

In message <563EB931.9030405 at yahoo.co.uk>, 
denis <ripedenis at 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