<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <tt>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 - "</tt>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.... <tt> </tt> <div class="moz-cite-prefix">On 12/05/2014 16:09, Gilles Massen wrote: </div> <blockquote cite="mid:5370D605.1010908@restena.lu" type="cite"> <pre wrap="">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).</pre> </blockquote> 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). <blockquote cite="mid:5370D605.1010908@restena.lu" type="cite"> <pre wrap=""> 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.</pre> </blockquote> 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. <blockquote cite="mid:5370D605.1010908@restena.lu" type="cite"> <pre wrap=""> On 05/10/2014 05:46 AM, Denis Walker wrote: </pre> <blockquote type="cite"> <pre wrap="">On 09/05/2014 19:26, Gert Doering wrote: </pre> </blockquote> <pre wrap=""> </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Having an optional abuse-c: in the more-specific inet(6)num: would be a nice and low-effort solution. </pre> </blockquote> </blockquote> <pre wrap=""> 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.</pre> </blockquote> 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. <blockquote cite="mid:5370D605.1010908@restena.lu" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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.</pre> </blockquote> 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. <blockquote cite="mid:5370D605.1010908@restena.lu" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> [...] </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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...</pre> </blockquote> 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 <blockquote cite="mid:5370D605.1010908@restena.lu" type="cite"> <pre wrap=""> 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 </pre> </blockquote> </body> </html>