[anti-abuse-wg] DRAFT: RIPE proposal - implementation of an
- Previous message (by thread): [anti-abuse-wg] DRAFT: RIPE proposal - implementation of an abuse
- Next message (by thread): [anti-abuse-wg] DRAFT: RIPE proposal - implementation of an
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Michele Neylon :: Blacknight
michele at blacknight.ie
Fri Apr 9 11:19:47 CEST 2010
On 9 Apr 2010, at 10:02, Frank Gadegast , Dipl-Inform. Frank Gadegast wrote: >> > > Thats up for discussion. > Preferably every incident will generate one mail to be qick as possible. > Surely its also possible to summarizereal outbreaks. OK > >>> >>> You can then look up the report (or even automate it), reset >>> his radius password and kick him out, waiting for him >>> to phone your support :o) >> >> Not everyone has the same business model > > Right, some members seem to make money with abuse ... Again - if you expect there to be ANY dialogue you need to drop that attitude It's offensive and totally unhelpful > >>> Or you could redirect him to a webpage describing that there >>> are too many reports coming in for his IP in a whatever time. >>> Its all up you. >>> >>> My dream system looks like this: >>> - abuse reports will get standarized >> >> that would be helpful > > Indeed. > >>> - monitoring systems will be developed at all RIRs >> >> Monitoring for what exactly??? > > abuse reports I'm having difficulty understanding this. If a RIPE member has an abuse contact and sets up abuse contact objects for every allocation, why do you need anything else? >> >> >> And again you are working under the false assumption that ALL RIPE members offer the same services as you do and in the same way. > > So we are even not clear that abuse is kind of "evil" and should be acceptable > because its the business of the member ? > > We should close this list, if we could not even have the same oppinion here. > > But feel free to explain these "business models" to me ... Again - drop the attitude You have to understand that not every RIPE member offers the same services or has the same resources at their disposal etc., > >>> "Bad providers" could be even published by RIPE :o) >> >> >> Are you insane? RIPE cannot open itself up for that kind of liability > > Why not, blacklists are doing the same, whats the difference ? Ask a lawyer. > >>> Well, thats only work at RIPE NCC, its not that complicated to >>> automated bounces ... >> >> So you say .. > > Yes, its quite easy. No it isn't. Either: - learn how to discuss this with other RIPE members or keep on with your stupid attitude and see how far it gets you > >> You cannot speak for all providers / RIPE members. > > Thats one of the reasons for a centralized system located at RIPE. > The system only needs to be implemented once, there will be nearly > no costs on the members side (except that they have > to deal with report, but they can still ignore them and except > the costs that might be added to RIPEs fees, but that should not be that > much. You do not know that. You have no way of knowing how much of a load would be placed on RIPE's systems > >> You are also suggesting putting a very heavy load on RIPE's systems which someone will have to pay for. Who? > > The member. > Simply add the costs to RIPE general costs and shared the along the members > with the current mechanism, small member pay less, big one more. > >>>> confirmation would be enough, although you'd need some way to deal with >>>> automated reports. >>> >>> Well, the monitoring system could send always the same backlink >>> for the same IP, so that the ISP could still count the amount >>> of incoming reports for one IP automatically and then >>> "answers" it as being closed with just clicking ONE link. >>> >>> Good idea ? >> >> So you expect RIPE members to completely rework their abuse desks to fit into your view of the world? > > Not MY VIEW, a standarized view. You're not a very good listener, are you? > Thats the goal. > > Lets see it this way: providers have to change their infrastructure > regulary for a couple or reasons and always have done. > Serverhousing changed pretty much during the last years. > There was the change from ISDN to DSL dialin, there are new > technologies for HTML, Flash and Mail every day. > > And do not forget IPv6, EVERY member has to change that in the new future. > >> I can't see that happening, because not all RIPE members are the same or work in the same way. > > Well they work on the same basics, what are allocations and other resources. > Resources cause traffic, and every members uses resources like nameservices, > webpages and email. And spam problem comes into play with the later. > > The difference isnt that big. > Business models have nothing to do with how to deal with resources the got from RIPE. Yes it does If you think that you can live in a world where business models have zero impact on reality then you are deluded > > > Kind regards, Frank > >> >> >> Mr Michele Neylon >> Blacknight Solutions >> Hosting & Colocation, Brand Protection >> ICANN Accredited Registrar >> http://www.blacknight.com/ >> http://blog.blacknight.com/ >> http://mneylon.tel >> Intl. +353 (0) 59 9183072 >> US: 213-233-1612 >> UK: 0844 484 9361 >> Locall: 1850 929 929 >> Twitter: http://twitter.com/mneylon >> ------------------------------- >> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty >> Road,Graiguecullen,Carlow,Ireland Company No.: 370845 >> >> > Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
- Previous message (by thread): [anti-abuse-wg] DRAFT: RIPE proposal - implementation of an abuse
- Next message (by thread): [anti-abuse-wg] DRAFT: RIPE proposal - implementation of an
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]