Re: [anti-abuse-wg] 2010-08 New Policy Proposal (Abuse contact
Piotr Strzyzewski wrote:
Im happy when we change the inetnum to have an mandatory abuse-mailbox-field, but thats nearly the same than the IRT-object.
Exept we will save some time and resources.
Really ? You cannot convert personal abuse-mail-fields to the inetnum automatically, this would be unlogical, because the intention of the LIR could have been different.
So, all LIRs will have the same work with an INETNUM-abuse-field then with an IRT object.
And then I like IRT better, because its intention was to take care of abuse anyway, and you need to change only ONE (or a couple) of IRT objects, when things changing ...
One more time - some pros from the original email:
- Reduced resource consumption: there will be no extra objects in DB (we save some disk space) and there will be no extra references (we save some whois servers' processors time). Both means: we save some money. :)
Not at all. Modern databases will use less resources when referencing objects from other tables instead of copying information to many other objects. Using the IRT object will save resources. Furthermore: the definition of the IRT object does not to be changed. Simply that the abuse-field is mandatory in the future, and that a link to all INETNUM objects to an IRT object is required. Sounds pretty easy to implement ...
- IRT object still can be used as it is used right now (if LIR want's to monitor abuse, even if the inet(6)num or aut-num is handled by its customer)
That will be confusing for everybody. What we want to achieve is a single place for the abuse contact, instead of spreading it in remarks, abuse-mailbox-fields in personal or INETNUM objects. Thats why a mandatory IRT object is the better solution to my opinion.
I personally simply want a mandatory abuse email address I can query without limitations, whatever way this is achieved, I will like it.
As Tobias said - we all agree about "single point of abuse contact information". What community disagree is this idea about IRT.
Dont think that the community dont like IRT, looks to me more that they prever it, instead of in INETNUM.
I don't agree with that point of view.
Maybe some mails from others should make that clear. What does everybody like more ? IRT ? INETNUM ?
Inserting it in INETNUM is no single point.
It is single for this inetnum. It is not single for you. That's true.
When I like to change our abuse@powerweb.de to lets say complain@powerweb.de, I will have to change ALL INETNUM objects. I would not like that ...
Good point - why not to mail it on the mailing list as a response to my email?
Just did.
But, I still believe this could be done relatively easy with simple script.
Yep, I thought that also for the needed updates with the IRT object, big LIRs should be able to insert the link and remove their remarks and other abuse-mailbox-fields pretty easily. But inserting the abuse email into the INETNUM object would mean, that nearly every small LIR also has to do scripting, it might be easier for the majority of the members to change their old objects once and then have a single IRT object for the future ... BTW: I have no opinion for you proposal under http://www.ripe.net/ripe/policies/proposals/2010-10.html yet, but find the following really interesting: "A clear statement that the resources will return by default to the RIPE NCC if the resource holder cannot be contacted". Im having hopes, if we put that together with Tobias' http://www.ripe.net/ripe/policies/proposals/2010-09.html (BIG SMILE) Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank@powerweb.de
On Fri, Nov 12, 2010 at 02:14:50PM +0100, Frank Gadegast wrote: Hi
One more time - some pros from the original email:
- Reduced resource consumption: there will be no extra objects in DB (we save some disk space) and there will be no extra references (we save some whois servers' processors time). Both means: we save some money. :)
Not at all. Modern databases will use less resources when referencing objects from other tables instead of copying information to many other objects. Using the IRT object will save resources.
What I was thinking about was that I'm affraid that a lot of LIRs will make a lot (with scripts, basing on current admin-c,tech-c) of IRT objects for its customers. This will consume resources.
Furthermore: the definition of the IRT object does not to be changed. Simply that the abuse-field is mandatory in the future, and that a link to all INETNUM objects to an IRT object is required. Sounds pretty easy to implement ...
Adding mandatory abuse-mailbox is as easy as that.
- IRT object still can be used as it is used right now (if LIR want's to monitor abuse, even if the inet(6)num or aut-num is handled by its customer)
That will be confusing for everybody.
Don't think so.
BTW: I have no opinion for you proposal under http://www.ripe.net/ripe/policies/proposals/2010-10.html yet, but find the following really interesting:
"A clear statement that the resources will return by default to the RIPE NCC if the resource holder cannot be contacted".
Im having hopes, if we put that together with Tobias' http://www.ripe.net/ripe/policies/proposals/2010-09.html
(BIG SMILE)
This is happening now. :D You should definately read things more carefull. This is a part of current "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region." Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Piotr Strzyzewski wrote:
Not at all. Modern databases will use less resources when referencing objects from other tables instead of copying information to many other objects. Using the IRT object will save resources.
What I was thinking about was that I'm affraid that a lot of LIRs will make a lot (with scripts, basing on current admin-c,tech-c) of IRT objects for its customers. This will consume resources.
Hm, but disk space is not really a resource these days. More important is the speed and consistency of the database, and with that, links are much better ...
Furthermore: the definition of the IRT object does not to be changed. Simply that the abuse-field is mandatory in the future, and that a link to all INETNUM objects to an IRT object is required. Sounds pretty easy to implement ...
Adding mandatory abuse-mailbox is as easy as that.
Sure, but when it equal, I would choose IRT, because of the other reasons.
- IRT object still can be used as it is used right now (if LIR want's to monitor abuse, even if the inet(6)num or aut-num is handled by its customer)
That will be confusing for everybody.
Don't think so.
Multiple please have to be confusing. The aim is the "single place". Multiple place are also a problem for typos ...
BTW: I have no opinion for you proposal under http://www.ripe.net/ripe/policies/proposals/2010-10.html yet, but find the following really interesting:
"A clear statement that the resources will return by default to the RIPE NCC if the resource holder cannot be contacted".
Im having hopes, if we put that together with Tobias' http://www.ripe.net/ripe/policies/proposals/2010-09.html
(BIG SMILE)
This is happening now. :D
You should definately read things more carefull. This is a part of current "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region."
Cannot find any difference for that point in your proposal. Your proposal says nothing about the introduction of an mandatory abuse-mailbox-field into INETNUM objects. Its just about the link to the sponsoring LIR or RIPE, what helps nothing to remove resources without a working contact. Your "pro" is: Another point of contact is known in case of any abuse. I bet there are LIRs that have no valid abuse contact either. And it does not help a lot to send abuse reports to RIPE NCC (maybe only to prove that the End User or LIR have no valid abuse contact). Please make that point more clear.
Piotr
Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank@powerweb.de -- Mit freundlichen Gruessen, -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank@powerweb.de
On Fri, Nov 12, 2010 at 02:42:16PM +0100, Frank Gadegast wrote: Hi Frank
Cannot find any difference for that point in your proposal. Your proposal says nothing about the introduction of an mandatory abuse-mailbox-field into INETNUM objects.
Unfortunately you are mixing two things. My official 2010-10 proposal and my question/proposal send as a discussion point to 2010-08 in my email to this mailing list. Both proposals have nothing in common with each other.
Its just about the link to the sponsoring LIR or RIPE, what helps nothing to remove resources without a working contact.
This proposal has nothing to do with such ideas.
Your "pro" is: Another point of contact is known in case of any abuse.
I bet there are LIRs that have no valid abuse contact either. And it does not help a lot to send abuse reports to RIPE NCC (maybe only to prove that the End User or LIR have no valid abuse contact).
Please make that point more clear.
Contractual relationship between End User and either LIR or RIPE NCC is stong (since it is contractual). Moreover - some obligations of those contracts are well known. This kind of link could be used by LEA as a solid connection for example. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
participants (2)
-
Frank Gadegast -
Piotr Strzyzewski