[anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database)

Hi Leo

I am not aware of any formal big picture, but I follow the mailing list
as closely as I am sure you and many others do. As you will know many of
these issues invoke much discussion on the list. It might not be a bad
idea to improve the structure and start working on cleaning up the
existing mess. This cleanup in itself is going to take quite some time.
During that time I am sure there will be much discussion on the next
step(s) to further improve any bigger picture.

Regards,
Denis

On 16/04/12:17 11:19 PM, Leo Vegoda wrote:
> Hi Denis,
> 
> I don't think I've seen anyone suggest that improving the structure is a bad thing to do. However, adding new structure before anyone has even had an opportunity to look at the proposals for maintaining the mandatory new data seems at least less than ideal.
> 
> If this is part of a grand plan, it would be nice if the grand plan could be shared.
> 
> Is there a reason for not sharing the big picture?
> 
> Regards,
> 
> Leo
> 
> -----Original Message-----
> From: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg-bounces at ripe.net] On Behalf Of Denis Walker
> Sent: Monday 16 Apr 12 2:13 pm
> To: anti-abuse-wg at ripe.net
> Subject: Re: [anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database)
> 
> Hi Leo
> 
> If you remember back to an earlier RIPE Meeting (some time ago) three
> policies were proposed including where to put the abuse data and how to
> validate it. These were withdrawn to allow a Task Force to look at the
> issues. The first policy from the Task Force is to have a single
> location in the RIPE Database to store abuse contact details.
> 
> You can debate which should come first, a place to store the details or
> a means of validating/enforcing accuracy of the data. But what you have
> right now in the RIPE Database for abuse contacts is a mess. Many
> details are still stored in remarks. When we wrote the Abuse Finder tool
> we could not even find these contacts by scripting. The best we could
> offer is a pointer to where you might find something useful.
> 
> If you can't reliably find the data you have little chance of validating
> it. The whole point of this proposal is to fix the abuse contact details
> in one easy to find place in the database, by humans and scripting. Far
> from putting off the day when the mess has to be cleared up, this is the
> first step in cleaning up the already existing mess.
> 
> Regards,
> Denis Walker
> Business Analyst
> RIPE NCC Database Group
> 
> On 16/04/12:17 9:13 PM, Leo Vegoda wrote:
>> Hi Frank,
>>
>> Frank wrote:
>>> Leo Vegoda wrote:
>>>> Marco Schmidt wrote:
>>
>> [...]
>>
>>>> It is disappointing that this new proposal is still focused on a one-time 
>>>> process of adding additional contact information and does not address 
>>>> ongoing management of the published information. Until there is a policy 
>>>> requiring contact information to be regularly maintained, proposal 
>>>> 2011-06 is of limited value.
>>>>  
>>> Not at all, its good to seperate definitions and other procedures like
>>> management or validation of abuse contacts, if you remember how hard
>>> it is to achive consensus.
>>>
>>> Lets starts simple and lets add other parts later.
>>>
>>> I will be happy to prepare a validation draft, if the community
>>> wants it.
>>
>> My issue is mainly with the way the proposals are ordered. Creating new requirements for types of contact data to be published before agreeing on a contact data management policy risks creating a situation where a new layer of contact information of questionable quality is added as a one-time only event. Unless you have a pre-existing contact data management policy you are just making the problem bigger and putting off the day when the mess has to be cleared up.
>>
>> Agreeing a way to manage contact data should be a prerequisite to the creation of new contact types.
>>
>> Regards,
>>
>> Leo Vegoda
>>
>>
> 
> 
>