Re: [anti-abuse-wg] [db-wg] objection to RIPE policy proposal 2016-01
HI Elvis On 10/03/2016 11:39, Elvis Daniel Velea wrote:
Hi Gert,
I agree with you that the implementation of abuse-c was 'poor'.
Sorry Elvis but you are neither a software engineer nor a regular user inputting data into the RIPE Database. So your unsubstantiated statement of 'poor' does not carry much weight.
On 3/10/16 1:57 AM, Gert Doering wrote:
Hi,
On Wed, Mar 09, 2016 at 11:36:48PM +0100, Horváth Ágoston János wrote:
It's not enough to state "let's add abuse-c here and here and here". Also think about how one is supposed to return the abuse contact afterwards. It should be algorithmically feasible to fetch the abuse contact from the RIPE DB. Should inet(6)num take precedence? Should the role object? or the organisation? or maybe a route? Or a combination of these, with their parents involved? This is why I've detailed a possible and very well-defined search order in my proposal.
And one more thing. As far as data quality goes, users are not known to keep their data up to date (sorry for the few exceptions - you're not the rule). Then you will have to start to figure out which abuse-c is outdated and which isn't; which one is still relevant and which is not. That's NOT a database, that's a job for google. So, why is "require indirection via a organisation: and role: object" going to help with stale data?
Except by making it so complicated that nobody is willingly going to use it to document abuse-handling exception for more specific subnets - in which case you've succeeded... abuse-c should have been implemented just like admin-c and tech-c is, as an attribute to the resource (inet(6)num and aut-num) objects.
As a massive over duplicated pile of repetitive data in 3+ million objects. Really good idea Elvis. That is good database design...No one ever checks if the admin-c and tech-c point to the right objects in their 10s of thousands of resource objects.
It is easier for the LIR to have it in one place only, but you need to register an organisation and role object for each customer... if you want them to handle the abuse themselves. or if you have different departments handling abuse for different (parts of your) resources.
I will say it again, again, again....I wrote a labs article with some ideas on this 2 years ago which may not be the best ideas, but as no one has even commented on them in 2 years who knows....
Maybe we should talk about changing the implementation of abuse-c such that you can not register a resource (allocation or assignment) unless you use the mandatory abuse-c (person or role) object, just as you do with admin-c and tech-c today.
Maybe we should talk about making admin-c and tech-c work like abuse-c. That would be a step in the right direction. cheers denis
Gert Doering -- NetMaster regards, elvis
Hi, On Thu, Mar 10, 2016 at 06:50:52PM +0100, denis wrote:
Maybe we should talk about making admin-c and tech-c work like abuse-c. That would be a step in the right direction.
So you want to add millions of unmaintained organization: objects to the millions of unmaintained admin-c:/tech-c: references? Sounds like a very good plan to improve data quality! What?! (I wouldn't mind the hierarchical lookup capability that abuse-c: has, so "if an inetnum has no tech-c:, find the next less specific and use that", but the indirection via org and mandatory role is way too silly to be extended further. Maybe you should start *using* the database for a while, like, "work at an ISP", so you can see which ideas are just not practical from a user point of view?) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi Gert I know we have a fundamental difference of opinion here but I will try to be constructive. On 10/03/2016 19:00, Gert Doering wrote:
Hi,
On Thu, Mar 10, 2016 at 06:50:52PM +0100, denis wrote:
Maybe we should talk about making admin-c and tech-c work like abuse-c. That would be a step in the right direction.
So you want to add millions of unmaintained organization: objects to the millions of unmaintained admin-c:/tech-c: references?
For a start there would not be millions of unmaintained admin-c and tech-c references if they were used hierarchically. The problem here is that they are both mandatory in the inet(6)num objects. But for many organisations they don't need a different reference for every resource. This just generates massive amounts of unmaintained references. It gets even worse when the reference PERSON objects instead of ROLE objects. So for many organisations to define just one admin-c and one tech-c in their ORGANISATION object would be all they need. I know there are power uses who don't follow the simple model. But so many members (who don't seem to be represented on these mailing lists) would benefit from such simplifications. Secondly you would only need more ORGANISATION objects for these power uses who have more complex business models.
Sounds like a very good plan to improve data quality!
What?!
(I wouldn't mind the hierarchical lookup capability that abuse-c: has, so "if an inetnum has no tech-c:, find the next less specific and use that", but the indirection via org and mandatory role is way too silly to be extended further. Maybe you should start *using* the database for a while, like, "work at an ISP", so you can see which ideas are just not practical from a user point of view?)
There must be a middle ground here between my desire to simplify the data model and use a lot more inheritance and your desire not to have to duplicate ORGANISATION objects. But no one is willing to talk about the bigger picture. This database design is almost 20 years old. The abuse-c and irt object are the only things that use inheritance in this hierarchical structure. The majority of the 12k+ members are not like many of the people on these mailing lists. They have not been using this database for the last 20 years. They really do struggle to understand it and use it. Technology that gets stuck in a time warp is bad technology. But there is no vision about what to do with this registry database. The RIPE NCC has had, has and will have some very good engineers, analysts and designers. You are paying for them. But they are too scared to propose a big change in case the 'community' just says NO. So instead they try to slip in little changes to nudge it along in a better direction. Changes they hope won't rock any boats and will get approved. That is why abuse-c works the way it does. I had a much bigger vision at the time but was not able to say it. So it is a little bit of a bigger plan which on its own may not be the best solution. This is why I keep banging my head against the wall about the data model. I have nothing personally to gain or lose either way. But professionally I want to see this product move forward for the good of the internet community. The data model is way past the stage of little changes and tweaks now. What it needs now is a revolution...even if that is done in small backwards compatible steps....at least have a vision about where it is going. The last revolution was 17 years ago and deployed in a big bang 15 years ago....it is time for another one. cheers denis
Gert Doering -- NetMaster
Hello Denis,
Sorry Elvis but you are neither a software engineer nor a regular user inputting data into the RIPE Database. So your unsubstantiated statement of 'poor' does not carry much weight.
Excuse me, but you do not get to decide that a fellow working group member's contribution does not carry much weight. That is the working group chairs' job when deciding on consensus, and from experience I know that even the chairs only do that in very rare circumstances. Consensus is based on content and supporting arguments, not on whether you judge somebody worthy... Cheers, Sander
participants (3)
-
denis -
Gert Doering -
Sander Steffann