[anti-spam-wg] Working Contact Information (Was: ..... NCC#2007083003 Fwd: DELIVERY FAILURE:)

[Jeroen Massar jeroen@localhost]

[re-ordering message flow so it makes sense again + reformat to 80c]

> Matthew Brown wrote:
>> I Matthew Brown, would like to request that there be some sort of
>> action, to allow the ripe database managers to contact ISP(s) when
>> someone reports incorrect or outdated information.

Jørgen Hovland wrote:
> I'm not sure if you have thought through your idea very thoughtfully,
> Mr Brown. The internet changes every second. It is more or less
> impossible to maintain proper information in ripe objects for
> end-users. An IP address can belong to customer A for 1 minute
> and then be taken over by customer B 5 seconds later in our net.
> If you want to contact the end-user directly, the RIPE whois server
> is not sufficient in the current state of today.
> Just keep contacting the ISP instead..

He actually mentioned contacting the ISP, not the end-user. They are the
ones responsible and they are also the ones that can act on problems.
The only way the end-user would be responsible is when they are in
effect the ISP.

BOTH inet[6]nums and domain.tld (different story I know) should have a
contactable address for technical and especially abuse issues.
This contact address should simply be the ISP NOC.

Indeed, I note that domain.tld should have two types of information:
'registrant', specifying who 'owns' the record. For all those whois
privacy freaks you can omit that, most likely the person who registered
it can't fix problems with it any way, but the Admin contact Tech can,
and that one should never be hidden.

Same for inet[6]nums, Tech contact should always be contactable, the
inet[6]num might/should contain a short description of who it is
assigned to, but most of the time it should not matter. They a hint of
'dynamic home user space' or something is appreciated by most people who
actually look up whois info to try and resolve issues. Again, the tech-c
should always be contactable, as that is the one who is responsible for
fixing problems. This problem might be for instance that you notice that
that prefix is unreachable or has other issues and just that you want to
help them out. And IMHO a tech-c should always point to a role account,
not to a single person. The Internet is a 24/7 hour business and nobody
is awake 24/7 ;)

By contact I mean three items: email + phone + street address
I note 'street address' as there is bound to be an office where this ISP
is located, POBOX's are just for hiding obscure companies. One should
not have nothing to hide. Note that a role can be updated really easily
and in one place, similar to a organization object.

I would suggest that there is like an easy way to trigger a process at
RIPE NCC when one could not contact a certain ISP by the means given,
phone being the most important one (note that it can be a VoIP one,
those have DIDs too). To limit overload of these requests, one could
require that the requester is an ISP itself (eg has an inet6num/tech-c
combo). Marking the data invalid can can be done when for instance the
phone still doesn't get picked up after X days one is really not running
a proper ISP business and certainly not taking responsibility for the
networks that one should be responsible for.

The sad part of course is that even when the data is marked invalid,
there is no way to actually come in contact with the ISP and/or getting
the ISP to fix the problems. Even a global BGP certificate setup won't
help, unless the larger transits and in effect the majority will adhere
to that and also allow RIRs toe revoke those certificates based on this.
As ISPs and especially also enterprises will never allow a small group
to have so much control over them, that will never ever happen :(

Actually what this really all comes down to is inter-ISP problem
reporting, which, like the above would definitely require agreement
between ISPs and also good communication. The problem there of course is
that the ISPs who act responsibly will cooperate in this, the ones that
are not, will not. Not even forgetting of course about the nasty fact
that it requires global

Greets,
 Jeroen

Attachment: signature.asc
Description: OpenPGP digital signature