Hello, Thanks for looking into the 'more specific abuse-c', and presenting a solution. Technically it would solve the "subnet issue" in our case. However, the proposed solution strikes me as really weird: it does not scale, is hard to parse, and breaks with almost everything I'd expect from the RIPE DB syntax- and usage-wise. Scaling might not be important for the projected use-case - but with every extension you could run into trouble (cf. extending the abuse role project, from your upcoming presentation). If I understood your earlier mails correctly, having stronger heritage and less different objects is intentional (and I can certainly agree with that idea). But I would apply that thinking rather to all contact objects, and not single the abuse-c out. Please keep the contact syntax coherent. On 05/10/2014 05:46 AM, Denis Walker wrote:
On 09/05/2014 19:26, Gert Doering wrote:
Having an optional abuse-c: in the more-specific inet(6)num: would be a nice and low-effort solution.
And I'd add: low-effort for everyone: the one running with the default org-attached abuse-c, the one needing more specific, and the data-requester with the whois client. I'd also believe that it is an additional workload NOT to use the default, and that's why I find it difficult to share you concern of bad data. Besides, why is the abuse-c so special that is warrants all the added technical barriers around it? After all, it is just a contact. Yes, it is mandatory, but that alone does not make it special. And whatever rules you put around it, you cannot force an abuse-c to be useful - which by the end of the day is the only thing that matters.
If you are not concerned with accountability in the database for management of Internet resources, we can do anything. Right now we have a default abuse handler for the LIR. We know who you are and you are accountable. Once you start adding abuse-c attributes all over a large network, referencing ROLE objects that we don't know who maintains (as MNTNER objects are pretty much anonymous), then we have lost a degree of accountability. It is very easy to hide behind an email address when you don't have to provide any other information in the public domain. What you want means all we have in the public domain for these End Users who manage the abuse reports for a resource is an email address.
Personally I don't feel strongly about the described accountability in the database. I'd rather have flexible ease of use, along with a comprehensive toolset for the RIPE NCC to enforce policy. You can put useless data in the DB anyway, so if any data is so important that it deserves special care or even validation, make the validation out of band: you'd have to anyway, so you can be more liberal on the business logic and not annoy the rest of the rule-abiding world.
When someone is held publicly accountable and has to provide additional information, which the LIR can validate as you know who the End User is, they are more likely to provide a working email address. We can always provide a low effort solution....but they have consequences.
[...]
If you want to know where localised abuse contacts have been set up in your network (by whatever method we end up with), how are you going to find them? How can you get a clear overview of abuse handling in your network? Currently there is no query that gives you this overview.
Which, in turn, would be nice feature for the lirportal. Along with the 'do it right'-wizard. Actually, the proposed solution for the "subnet-issue" is very appealing to do the "end-user issue" wrong: what would prevent a LIR to put an abuse-c per end-user assignment in it's org-object? It would probably be easier than to create the organisation objects... All in all, fragmenting the syntax of objects depending on their intented use seems a too high cost for the presented benefits... Best regards, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473