Proposal to clean up historical "abuse-mailbox:" attributes
On Thu, May 07, 2015 at 07:15:41PM +0200, denis wrote: Dear Denis and DB-WG Members
Tools provided by the RIPE NCC to find the abuse contact for a resource (RIPEstat, Abuse Finder) only search for "abuse-c:" data.
Just to clarify - I'm affraid that this looks like not being correct. First of all, this topic was discussed at RIPE69 and it was declared by RIPE NCC Staff Member that RIPEstat is still using more sophisticated way to look for abuse contact. Moreover, at the RIPEstat Abuse Contact Finder webpage (https://stat.ripe.net/specials/abuse) there is still present link to RIPE Labs article describing how this tool works (https://labs.ripe.net/Members/cteusche/finding-anti-abuse-contact-informatio...). All above are of course just kind of hints. However, one can check this in practice, looking for Abuse Contact for 155.202.0.0/16 (being just an example here). Both whois client and Abuse Finder says that there is no abuse contact registered for 155.202.0.0/16, whereas RIPEstat reports abuse@produban.com with 4/5 quality rating as an Abuse Contact. This looks like those tools are based on different alghoritms and RIPEstat doesn't _only_ search for "abuse-c" data.
A cleanup was proposed in the impact analysis for ripe-563 https://www.ripe.net/participate/policies/proposals/2011-06 " In order to clean up existing data, the RIPE NCC will notify the users and convert "abuse-mailbox:" attributes into "remarks:" in any object other than role objects."
As it is now a few years since this was discussed and agreed I think it wise to propose the cleanup again and reaffirm this is the way to go.
I therefore propose the RIPE NCC converts all "abuse-mailbox:" attributes into "remarks:" attributes in PERSON, MNTNER, ORGANISATION and IRT objects. Then deprecates this attribute from these object types.
Although I like this idea, I would prefer that RIPE NCC first address the problem of missing abuse-c attributes.
I further propose that any "abuse-mailbox:" attribute in a ROLE object, where the ROLE object is not referenced by any "abuse-c:" attribute, and has not been referenced for at least 90 days, is also converted into "remarks:". This will help to clean up historical "abuse-mailbox:" attributes that existed in ROLE objects before "abuse-c:" was introduced.
Is this going to be one-time action or periodic, scheduled procedure? Best regards, Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi Piotr On 07/05/2015 22:24, Piotr Strzyzewski wrote:
On Thu, May 07, 2015 at 07:15:41PM +0200, denis wrote:
Dear Denis and DB-WG Members
Tools provided by the RIPE NCC to find the abuse contact for a resource (RIPEstat, Abuse Finder) only search for "abuse-c:" data. Just to clarify - I'm affraid that this looks like not being correct.
First of all, this topic was discussed at RIPE69 and it was declared by RIPE NCC Staff Member that RIPEstat is still using more sophisticated way to look for abuse contact. Moreover, at the RIPEstat Abuse Contact Finder webpage (https://stat.ripe.net/specials/abuse) there is still present link to RIPE Labs article describing how this tool works (https://labs.ripe.net/Members/cteusche/finding-anti-abuse-contact-informatio...).
You are right, RIPEstat still uses an algorithm looking for email addresses that may not be correct, whereas the database Abuse Finder tool only uses the official abuse contact mechanism. I would disagree that this is 'more sophisticated'. It is a crude attempt to rate historical contact information that simply does not fit into a sliding scale of reliability. This algorithm has been criticised by members in the past who have received abuse reports to wrong email addresses or relating to resources they are not responsible for, simply because a complex web of references has changed over time. The problem is when someone uses a tool that has been provided to return an abuse contact and it gives you an email address, people will use that address. It does not matter how many stars it has, they will use it. Given a choice between a 1 star address or nothing...it is not a choice to the user.
All above are of course just kind of hints. However, one can check this in practice, looking for Abuse Contact for 155.202.0.0/16 (being just an example here). Both whois client and Abuse Finder says that there is no abuse contact registered for 155.202.0.0/16, whereas RIPEstat reports abuse@produban.com with 4/5 quality rating as an Abuse Contact.
This looks like those tools are based on different alghoritms and RIPEstat doesn't _only_ search for "abuse-c" data.
But now you have a dilemma. This example you referred to is a top level legacy object. They are not subject to the policy and do not have to set up "abuse-c:". In this example there is no referenced ORGANISATION object, no "abuse-c:", just a historical "abuse-mailbox:" in a referenced ROLE object. So it does not follow the accepted "abuse-c:" mechanism. As long as they are allowed to continue to do this they may never change anything and never set up an "abuse-c:" correctly. If you decide not to do a cleanup because legacy space is not set up with "abuse-c:" and RIPEstat still tries to track vague references, then legacy space holders will not change anything and you will never be able to do a cleanup. It is a vicious circle. That means one of the main aims of the "abuse-c:" has failed - to have one single place to record abuse contact details and one single way of finding and reporting it. Apart from the few missing "abuse-c:" that Tim referred to, it is ONLY legacy space that does not have "abuse-c:" now.
A cleanup was proposed in the impact analysis for ripe-563 https://www.ripe.net/participate/policies/proposals/2011-06 " In order to clean up existing data, the RIPE NCC will notify the users and convert "abuse-mailbox:" attributes into "remarks:" in any object other than role objects." As it is now a few years since this was discussed and agreed I think it wise to propose the cleanup again and reaffirm this is the way to go. I therefore propose the RIPE NCC converts all "abuse-mailbox:" attributes into "remarks:" attributes in PERSON, MNTNER, ORGANISATION and IRT objects. Then deprecates this attribute from these object types. Although I like this idea, I would prefer that RIPE NCC first address the problem of missing abuse-c attributes.
For the missing "abuse-c:" in RIPE allocated/assigned address space, this should be a simple process to fix. Notify the holders to remind them of their responsibilities, allow them a short period to set it up, then enforce it where necessary. This should not be a blocker on a cleanup.
I further propose that any "abuse-mailbox:" attribute in a ROLE object, where the ROLE object is not referenced by any "abuse-c:" attribute, and has not been referenced for at least 90 days, is also converted into "remarks:". This will help to clean up historical "abuse-mailbox:" attributes that existed in ROLE objects before "abuse-c:" was introduced. Is this going to be one-time action or periodic, scheduled procedure?
It could be a one off to delete the historical data, or it could be built into the automated cleanup process to clean out redundant abuse contacts that are not referenced anywhere. I suggest you go ahead with the cleanup despite all the above. The information currently in objects is not lost, but changed into "remarks: abuse-mailbox:". So if RIPEstat still wants to search for and report this information it is still there. But it makes a clear statement that the database only supports one method of recording abuse contact details. cheers Denis Walker Independent Netizen
Best regards, Piotr
On Fri, May 08, 2015 at 01:14:53AM +0200, denis wrote: Dear Denis
On 07/05/2015 22:24, Piotr Strzyzewski wrote:
On Thu, May 07, 2015 at 07:15:41PM +0200, denis wrote:
Dear Denis and DB-WG Members
Tools provided by the RIPE NCC to find the abuse contact for a resource (RIPEstat, Abuse Finder) only search for "abuse-c:" data. Just to clarify - I'm affraid that this looks like not being correct.
First of all, this topic was discussed at RIPE69 and it was declared by RIPE NCC Staff Member that RIPEstat is still using more sophisticated way to look for abuse contact. Moreover, at the RIPEstat Abuse Contact Finder webpage (https://stat.ripe.net/specials/abuse) there is still present link to RIPE Labs article describing how this tool works (https://labs.ripe.net/Members/cteusche/finding-anti-abuse-contact-informatio...).
You are right, RIPEstat still uses an algorithm looking for email addresses that may not be correct, whereas the database Abuse Finder tool only uses the official abuse contact mechanism. I would disagree that this is 'more sophisticated'. It is a crude attempt to rate historical contact information that simply does not fit into a sliding scale of reliability. This algorithm has been criticised by members in the past who have received abuse reports to wrong email addresses or relating to resources they are not responsible for, simply because a complex web of references has changed over time. The problem is when someone uses a tool that has been provided to return an abuse contact and it gives you an email address, people will use that address. It does not matter how many stars it has, they will use it. Given a choice between a 1 star address or nothing...it is not a choice to the user.
This is all true and we can look at this situation from different perspectives. Suffice to say, that I was one of those moaning members and the situation pushed me to put VR2736-RIPE into the database. I don't want to start a debate about meanings of the words. Just to be clear - the term "more sophisticated" was used only to note the fact that it is something more than simple select from database.
All above are of course just kind of hints. However, one can check this in practice, looking for Abuse Contact for 155.202.0.0/16 (being just an example here). Both whois client and Abuse Finder says that there is no abuse contact registered for 155.202.0.0/16, whereas RIPEstat reports abuse@produban.com with 4/5 quality rating as an Abuse Contact.
This looks like those tools are based on different alghoritms and RIPEstat doesn't _only_ search for "abuse-c" data.
But now you have a dilemma. This example you referred to is a top level legacy object. They are not subject to the policy and do not have to set up "abuse-c:". In this example there is no referenced ORGANISATION object, no "abuse-c:", just a historical "abuse-mailbox:" in a referenced ROLE object. So it does not follow the accepted "abuse-c:" mechanism. As long as they are allowed to continue to do this they may never change anything and never set up an "abuse-c:" correctly.
I see this more like an opportunity and not a problem. From my point of view, we do want to change _schema_. Just like we did with created:, last-modified: and others. If we make a consensus about removing abuse-mailbox: from certain objects this will not be a policy and will not affect in any way ripe-639 (at least the way I understand it). Moreover, the obligation mentioned in ripe-639: "the responsibility of the resource holder to maintain accurate data in the registry in respect of each resource identified" _could_ be interpreted in this context as obligation to follow the community's wish to include abuse-c for legacy resources.
If you decide not to do a cleanup because legacy space is not set up with "abuse-c:" and RIPEstat still tries to track vague references, then legacy space holders will not change anything and you will never be able to do a cleanup. It is a vicious circle. That means one of the main aims of the "abuse-c:" has failed - to have one single place to record abuse contact details and one single way of finding and reporting it. Apart from the few missing "abuse-c:" that Tim referred to, it is ONLY legacy space that does not have "abuse-c:" now.
Don't be so pessimistic. ;-) Correct me if I'm wrong, but RIPE NCC and RIPE community at large emerge mostly from academic community. Those are smart guys and organizations who/which are still here, support us and engage in the community. And mostly they are the legacy resource holders. Did we talk with them and asked them if they have any opinion about this idea of abuse-c? It is not a secret that there is an mailing list gathering LRHs. My organization holds legacy resource and I set up the abuse-c not only because I was a member of the ACM-TF but mostly because this saves a lot of work for me and my team. This was smart choice.
A cleanup was proposed in the impact analysis for ripe-563 https://www.ripe.net/participate/policies/proposals/2011-06 " In order to clean up existing data, the RIPE NCC will notify the users and convert "abuse-mailbox:" attributes into "remarks:" in any object other than role objects." As it is now a few years since this was discussed and agreed I think it wise to propose the cleanup again and reaffirm this is the way to go. I therefore propose the RIPE NCC converts all "abuse-mailbox:" attributes into "remarks:" attributes in PERSON, MNTNER, ORGANISATION and IRT objects. Then deprecates this attribute from these object types. Although I like this idea, I would prefer that RIPE NCC first address the problem of missing abuse-c attributes.
For the missing "abuse-c:" in RIPE allocated/assigned address space, this should be a simple process to fix. Notify the holders to remind them of their responsibilities, allow them a short period to set it up, then enforce it where necessary. This should not be a blocker on a cleanup.
This could be done parallel to the cleanup. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi Piotr On 08/05/2015 10:44, Piotr Strzyzewski wrote:
On Fri, May 08, 2015 at 01:14:53AM +0200, denis wrote:
Dear Denis
On Thu, May 07, 2015 at 07:15:41PM +0200, denis wrote:
Dear Denis and DB-WG Members
Tools provided by the RIPE NCC to find the abuse contact for a resource (RIPEstat, Abuse Finder) only search for "abuse-c:" data. Just to clarify - I'm affraid that this looks like not being correct.
First of all, this topic was discussed at RIPE69 and it was declared by RIPE NCC Staff Member that RIPEstat is still using more sophisticated way to look for abuse contact. Moreover, at the RIPEstat Abuse Contact Finder webpage (https://stat.ripe.net/specials/abuse) there is still present link to RIPE Labs article describing how this tool works (https://labs.ripe.net/Members/cteusche/finding-anti-abuse-contact-informatio...). You are right, RIPEstat still uses an algorithm looking for email addresses
On 07/05/2015 22:24, Piotr Strzyzewski wrote: that may not be correct, whereas the database Abuse Finder tool only uses the official abuse contact mechanism. I would disagree that this is 'more sophisticated'. It is a crude attempt to rate historical contact information that simply does not fit into a sliding scale of reliability. This algorithm has been criticised by members in the past who have received abuse reports to wrong email addresses or relating to resources they are not responsible for, simply because a complex web of references has changed over time. The problem is when someone uses a tool that has been provided to return an abuse contact and it gives you an email address, people will use that address. It does not matter how many stars it has, they will use it. Given a choice between a 1 star address or nothing...it is not a choice to the user. This is all true and we can look at this situation from different perspectives. Suffice to say, that I was one of those moaning members and the situation pushed me to put VR2736-RIPE into the database.
I don't want to start a debate about meanings of the words. Just to be clear - the term "more sophisticated" was used only to note the fact that it is something more than simple select from database.
All above are of course just kind of hints. However, one can check this in practice, looking for Abuse Contact for 155.202.0.0/16 (being just an example here). Both whois client and Abuse Finder says that there is no abuse contact registered for 155.202.0.0/16, whereas RIPEstat reports abuse@produban.com with 4/5 quality rating as an Abuse Contact.
This looks like those tools are based on different alghoritms and RIPEstat doesn't _only_ search for "abuse-c" data. But now you have a dilemma. This example you referred to is a top level legacy object. They are not subject to the policy and do not have to set up "abuse-c:". In this example there is no referenced ORGANISATION object, no "abuse-c:", just a historical "abuse-mailbox:" in a referenced ROLE object. So it does not follow the accepted "abuse-c:" mechanism. As long as they are allowed to continue to do this they may never change anything and never set up an "abuse-c:" correctly. I see this more like an opportunity and not a problem. From my point of view, we do want to change _schema_. Just like we did with created:, last-modified: and others. If we make a consensus about removing abuse-mailbox: from certain objects this will not be a policy and will not affect in any way ripe-639 (at least the way I understand it).
Moreover, the obligation mentioned in ripe-639: "the responsibility of the resource holder to maintain accurate data in the registry in respect of each resource identified" _could_ be interpreted in this context as obligation to follow the community's wish to include abuse-c for legacy resources.
I was avoiding moving into the territory of ripe-639, but as you have mentioned it I would agree. if we can 'encourage' legacy resource holders to set up "abuse-c:" for all their resources then we have achieved the main goal of the "abuse-c:" principle - one location/method for abuse contact information.
If you decide not to do a cleanup because legacy space is not set up with "abuse-c:" and RIPEstat still tries to track vague references, then legacy space holders will not change anything and you will never be able to do a cleanup. It is a vicious circle. That means one of the main aims of the "abuse-c:" has failed - to have one single place to record abuse contact details and one single way of finding and reporting it. Apart from the few missing "abuse-c:" that Tim referred to, it is ONLY legacy space that does not have "abuse-c:" now. Don't be so pessimistic. ;-)
I was being more dramatic than pessimistic to stress the point...
Correct me if I'm wrong, but RIPE NCC and RIPE community at large emerge mostly from academic community. Those are smart guys and organizations who/which are still here, support us and engage in the community. And mostly they are the legacy resource holders. Did we talk with them and asked them if they have any opinion about this idea of abuse-c? It is not a secret that there is an mailing list gathering LRHs.
Maybe you can raise the issue there as your company has legacy space.
My organization holds legacy resource and I set up the abuse-c not only because I was a member of the ACM-TF but mostly because this saves a lot of work for me and my team. This was smart choice.
A cleanup was proposed in the impact analysis for ripe-563 https://www.ripe.net/participate/policies/proposals/2011-06 " In order to clean up existing data, the RIPE NCC will notify the users and convert "abuse-mailbox:" attributes into "remarks:" in any object other than role objects." As it is now a few years since this was discussed and agreed I think it wise to propose the cleanup again and reaffirm this is the way to go. I therefore propose the RIPE NCC converts all "abuse-mailbox:" attributes into "remarks:" attributes in PERSON, MNTNER, ORGANISATION and IRT objects. Then deprecates this attribute from these object types. Although I like this idea, I would prefer that RIPE NCC first address the problem of missing abuse-c attributes. For the missing "abuse-c:" in RIPE allocated/assigned address space, this should be a simple process to fix. Notify the holders to remind them of their responsibilities, allow them a short period to set it up, then enforce it where necessary. This should not be a blocker on a cleanup. This could be done parallel to the cleanup.
Agreed Good luck with the meeting and discussions next week. cheers Denis Walker Independent Netizen
Piotr
participants (2)
-
denis -
Piotr Strzyzewski