[anti-abuse-wg] [db-wg] objection to RIPE policy proposal 2016-01
- Previous message (by thread): [anti-abuse-wg] [db-wg] objection to RIPE policy proposal 2016-01
- Next message (by thread): [anti-abuse-wg] [db-wg] objection to RIPE policy proposal 2016-01
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
denis
ripedenis at yahoo.co.uk
Thu Mar 10 18:50:52 CET 2016
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 >
- Previous message (by thread): [anti-abuse-wg] [db-wg] objection to RIPE policy proposal 2016-01
- Next message (by thread): [anti-abuse-wg] [db-wg] objection to RIPE policy proposal 2016-01
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]