This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[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 ]