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