Hi all,
Isn't LIRs already subject of auditing? Is the frequency of auditing too
low perhaps?
If Ripes new abusefinder tool isn't sufficient enough I am sure they
welcome feedback. It is quite funny that the term webform has been
brought up. Previous abuse-discussions had topics like "we want to
require every abuse contact to be reachable by email". This only tells
me that there will never ever be any consensus about abuse contact
methods or standards this century.
I have no idea of the RIPE country restrictions, but forcing a LIR to go
to a certain RIR when requesting resources - isn't that monopoly? Since
when is that good for anyone?
I don't really want a public database of our LIRs allocations with
timestamped inetnums that goes back in time. If you want that kind of
information you can contact us directly, and if you do I might tell you
to contact the authorities first to get a warrant. I can't think of very
many reasons, if any at all, why you would need such information without
it having something to do with illegal activities anyway. And that is
someone elses job.
We sometimes receive contact information requests from the authorities.
We receive these requests even though the contact information is already
available in the RIPE db or a simple webbrowse to the IP-adress return
the companys website with full contactinfo. I am pretty sure this will
never change even if RIPE was forced and punished to make sure their
database was correct. So in my country, a public RIPE database with
end-user allocation information is probably only good for spamming. I
would rather see it more restrictive supporting internal identificators
that can be used in some sort of report system to a particular LIR
instead of requiring real contact information which is constantly
subject to change anyway.
J
On 09/29/10 09:01, Aftab Siddiqui wrote:
> Hello Tobias,
> yes, to my surprise as well the proposal didn't reach the consenses at
> APNIC. But in my personal experience most of the abuse reports we send
> are undelivered due to bad/incorrect address. The reason for policy or
> web reporting is there, lets see if majority acknowledges it or not.
>> Regards,
>> Aftab A. Siddiqui
>>> 2010/9/29 Tobias Knecht <tk at abusix.com <mailto:tk at abusix.com>>
>> Hi,
>> >>> There's no webform for this, no, but if you email ncc at ripe.net> <mailto:ncc at ripe.net>
> >>> and/or abuse at ripe.net <mailto:abuse at ripe.net>, this should get
> things to the right
> >>> person and it can go from there.
> >>
> >> Given the number of cases I've reported to RIPE, and the apparent
> >> inaction, I'm not convinced that either of those would be a viable
> >> communications channel. Perhaps we do need a webform. No doubt
> >> the RIPE NCC will protest that since there isn't a policy that
> tells
> >> them to actually do anything about such cases, there's no point us
> >> having a webform anyway.
> >
> > Hummm... OK. I didn't realize things were that bad.
>> It is! ;-)
>> > So, ah, maybe the Right Place To Start would be for somebody
> (perhaps
> > even this working group?) to propose at least some sort of a policy
> > (e.g. on hijacked ASNs and/or address blocks) for RIPE's
> consideration (?)
> >
> > I do agree that in the absence of any policy to even
> investigate, a web
> > form for submissions isn't going to help a lot.
>> I have done a policy proposal for APNIC which was discussed in the
> last
> meeting, but didn't find consensus. See more about this here:
>http://www.apnic.net/policy/proposals/prop-084>> I think we should change that a bit and say: "RIPE is responsible to
> keep up accuracy for the data held in the whois database!" The means
> that RIPE has to find ways to do so.
>> The above mentioned proposal by the way is in a similar way in process
> at ARIN.
>> If this working group thinks the policy proposal would be nice for
> RIPE,
> let me know and I will make the needed changes.
>> Thanks,
>> Tobias
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/attachments/20100929/2dc6ed26/attachment.html