[ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di rectory

[Ian Baker]

----- Original Message ----- 
From: "Charles Scott" <cscott at gaslightmedia.com>
To: "Ian Baker" <ibaker at codecutters.org>
Cc: <ppml at arin.net>
Sent: Thursday, August 28, 2003 1:10 PM
Subject: Re: [ppml] Policy Proposal 2003-11: Purpose and Scope of WHOIS Di
rectory


> On Thu, 28 Aug 2003, Ian Baker wrote:
>
> > Chuck,
> >     I was thinking simply that mandating end-user records could be quite
a
> > mammoth task, and one that could stall the other, very worthy, points.
> >
> > I haven't run the latest bulk data through the scanner yet, but (from a
dim
> > memory) I think this would be on the order of a million organizations to
> > contact and correlate. A "click on the link" type of response /might/
work,
> > but I suspect that many people would just mentally filter it as
> > yet-another-spam.
> >
> > Manual replies would take some processing and, I suspect, a fair degree
of
> > manual intervention.
>
> Ian:
>   Of course I was not suggesting that end-user records be mandated nor
> necessarilly verified. I was suggesting that a particular provider might
> want to require their own customers to have verified reccords as part of
> their policy.
>   I would think that an automatic E-Mail to the listed contact for each
> reccord that needs to be verified and some means to automatically reply
> would not be too much of a burdon on ARIN. My only concern is that
> there be some way that whomever receives the E-Mail can verify that they
> are the correct person/entity in case the mail ends up with someone else.
> I like the web based verify link in the message, but wonder if there's an
> easy piece of information that could be entered into a field on that page
> that would verify the person responding. Perhaps even just the contact
> handle would select out most bogus responses.
>   Thinking about manual intervention, for provider assignments that opted
> into verification and don't verify, a message could be sent to their
> provider and the reccord marked as unverified. Only direct ARIN
> allocations that don't verify would require some action by ARIN, thus
> minimizing the load on ARIN.

Chuck,
    That's my view too (maybe I was being too judgemental about the
wording!)

Generating a token for use in a URL is fairly straightforward (and hopefully
uses something not easily publicly available, such as a combination of
contact email and ARIN organization code. This approach seems to be fairly
common, both in mailing lists, and, IIRC, Verisign (who do something similar
with their WHOIS reminders).

OTOH, I've no way of knowing the "hit rate" - most such messages that I
receive are spam, so there may be a credibility problem once one drops below
the professional techies and into end-users that may have bought-in
expertise.

Regards,

Ian