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

Dear Gilles

Sorry, another long email. Maybe at some point we have to accept that 
email discussions are not going to resolve this matter :)

To take your last point first - "All in all, fragmenting the syntax of 
objects depending on their intented use seems a too high cost for the 
presented benefits...". We have already done this in a way, which is why 
we are having this whole discussion. The ROLE and ORGANISATION objects 
had an intended use. But no business rules were added to the software to 
enforce the use and there were not even any best common practise rules 
documented. 10+ years down the line and most people have forgotten why 
these objects are there. Now we are trying to build a case to 'do things 
right' and it's seen as too much hassle.

More comments in line below....

On 12/05/2014 16:09, Gilles Massen wrote:
> 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).

As I understand it, the subnet case is not a large usage requirement, so 
scaling is not an issue. The same syntax is used by "mnt-routes:" so 
there is a precedent for the syntax and we already have the software to 
parse it.

If scaling became an issue we could solve that with proper tooling. I 
know we have not yet put a good case for tools to help you work with the 
RIPE Database and experienced users don't see a need for 'simple' tools. 
After all, you can do everything you want with a few keystrokes on a 
command line, right? I come from a generation that just about remembers 
writing software in assembler. Then we moved to high level (C like) 
languages. At the time programmers thought they were losing some power 
and control over the processor and it's internal registers. Then high 
level languages became the norm and now we have fully integrated 
development environments.....but you can still write in assembler if you 
want. We can always present you with a view of your low level data in 
RPSL format and accept input from you in that way. But don't forget what 
the 'RP' stands for - 'Routing Policy'. It does not mean 'Address 
Management'. To finally sum up this point for now - we can build and 
provide you with many tools to help you with address management 
information that don't have to work with RPSL format data (but can do).
>
> 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.

I agree absolutely with this and have said so on many occasions. A small 
organisation may only have one technical or admin team, but may still 
have many resources in the database. There is no need to duplicate these 
contact details every where. They can be managed in the same way as 
abuse contacts.

>
>
> 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.

Again you are right. The abuse contact is not special. It only seems 
special because we have applied the principles of the database model to 
it. These principles are sadly missing from so many other areas of the data.

Although it has been forgotten after 10+ years the basic database model 
is  - an organisation is the core of your data. That organisation has 
human resources and Internet resources. The human resources are grouped 
into roles and these roles manage the Internet resources. That is it in 
a nutshell. It sounds simple, but so many layers have been built on and 
around these principles, that the original principles have been 
partially lost.

That core organisation is anyone/thing that manages (some aspect of) an 
Internet resource. If it is an outsourced 24/7 team, an abuse handler or 
an End User doing their own routing. There should be an ORGANISATION 
object to identify them. Everything else hangs off that object.

For example, if an End User manages the routing for their resource, who 
do you want to contact if their is a routing problem? The End User who 
manages the routing or their LIR who assigned the resource? How are you 
going to contact that End User? From the MNTNER in the "mnt-routes:" of 
the assignment? Which email address should you use from the MNTNER or 
referenced PERSON objects? Or maybe the ROUTE object where all contact 
information is optional. Following the basic principles there should be 
an ORGANISATION object for the End User with clearly defined contact 
details. It makes sense to follow the basic design. It does not make 
sense to take short cuts and break the basic model.

>
>
>> 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.

We can provide tools to make it easy to manage data without breaking the 
model. Anyone who agrees to the Terms and Conditions of use of the RIPE 
Database agrees to enter valid and correct information.

>
>
>> 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...

Yes it would be easier, but wrong. Some things can be managed by 
software business rules, other things need to rely on members following 
the rules.

Regards
Denis Walker
Business Analyst
RIPE NCC Database Team
>
> 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20140512/58eabc47/attachment.html>