[anti-abuse-wg] [db-wg] Options for extending "abuse-c:"

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