[db-wg] Proposal to clean up historical "abuse-mailbox:" attributes

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 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-information-with-ripestat).
>> 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 at 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
>