Re: RIPE Whois database is not being maintained

On Sat, 18 Mar 2006, in the Usenet newsgroup comp.security.firewalls, in article
<EGYSf.154284$sa3.93412@pd7tw1no>, Walter Roberson wrote:

>JC <jhoppyc@westnet.com.invalid> wrote:

>> roberson@hushmail.com (Walter Roberson) wrote:
>>> JC <jhoppyc@westnet.com.invalid> wrote:

[contact details for an address allocation problem]

>>>> There may be options we could pursue to check the validity of the contact
>>>> data in the objects in the RIPE Database. Where we have a direct
>>>> relationship with the owners of these objects we could request that they
>>>> update this information.
>>>> But we do not have a mandate from the RIPE community to allocate any
>>>> resources to this activity.

Not quite enough details to make heads/tails out of the problem. The original
error seems to be a DNS problem (quoting)

   emails to the contact email address were returned with the comment "Name
   service error for name, type=A: Host found but no data record of requested
   type".

>>>> In simpler terms - our database is out of date but we couldn't care less
>>>> about updating it even when you point out an obvious error.

The message above would _appear_ to be a DNS error - there's a MX record
pointing to a non-existent host. That certainly wouldn't be RIPE's problem
if that is the case..

>>> In my experience, when someone says that they don't have a mandate
>>> to do something, it is often (but not always) code for
>>> "*We* think it should be done, but we haven't been able to convince the
>>> people who control the budgets or set the priorities."

I'd tend to agree with this.

>> I realise that money is ultimately the reason.

It does make the world go round

>> What is the point to having the database, and making its data available to
>> users, if the database is not being maintained?
>
>You haven't presented any indication that the database is not being
>maintained. The discussion you presented was evidence only that
>third-party- initiated changes are not processed.

I haven't had much difficulty in getting RIPE to at least look at the
problem, and correcting things that they had control over - mainly
inconsistent data between databases.

> APNIC
>
>The accuracy and concurancy of APNIC data is a farce, particularily
>with respect to systems in China, even those at universities.

Not only. Trying to get information on a registration in Myanmar (Burma)
is virtually impossible, but this is true for a lot of other places as well.

>The difference is that sometimes APNIC puts up notices along the
>lines of "This data has been reported to be inaccurate, and
>we've tried and tried and we haven't been able to find anyone
>with authority over this data".

I've also seen such notices in RIPE, ARIN, and LACNIC query results.

>It is my belief

[...]

>we only want you {the RIPE staff} to take action where the owning
>party initiates the change. Don't waste your time trying to clean
>up the thousands of bad entries: it isn't worth the effort!"

One also has to look at the charter they are working from. RIPE is
somewhat better than (say) ARIN in that there is some relatively
low level contract law involved. But the whole Internet thing has
no legal basis - and virtually nothing is enforceable in a court of
law. About the best thing that can be done is peer pressure. I don't
have a URL handy, but there are some documents on the RIPE ftp server
that discuss this problem. They may be mirrored at the other RIRs, and
those RIRs may have published similar documents.

>And it is my further belief that the RIPE staff responded
>along the lines of "But trying to keep the database up-to-date
>is important!!", and the management responded

as pointy haired managers often will. Sometimes they are seeing "the
big picture" - sometimes not.

>These are -beliefs-, and could be wildly wrong.

I don't think they are that far out of line with reality.

>And even the RIPE management might abstractly care about the bad data,
>but be in a position of having to choose between the abstract principle
>of "best possible data" and the practical reality of limited staff and
>budgets, in which spending the time on fixing bad data might the
>difference between surviving and not.

I doubt it would degrade to a survival issue, but I suspect that if they
did put the effort into fixing errors that are not under their direct
control, they'd let the ball drop elsewhere.

        Old guy
Received on Mon May 1 00:59:44 2006