Hi Denis, On 05/12/2014 05:32 PM, Denis Walker wrote:
Sorry, another long email. Maybe at some point we have to accept that email discussions are not going to resolve this matter :)
I'd have loved to be in Warsaw and bug you directly :) Thanks for enlighten me, and from your answer I think we are not in wild disagreement.
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.
So your wish is to take the current abuse-c implementation as a model for other contacts, is that correct? I would see merit in that - but I'm still not wild about the fragmentation: either it is the way forward, then it should have been said so, and be brought explicitly before the DB-WG. Before the implementation. Because if it is not (or there is too much resistance against applying the model to other contacts) then you're stuck with the two kinds of contacts: to me as a user of the database (reader or writer) as well as part time DBA that is hugely annoying. Supposing I did not misread your intentions, and the abuse-c model is the right:
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.
Ok, I didn't know about mnt-routes, and I agree that the subnet case _should_ be limited. However, it needs to scale if applied to admin-c and tech-c's, at least much more than for the abuse-c. Maybe the proposal is enough - you have better data on that than I do - but in any case we should end up with the same for all contacts. And keep the necessary flexibility to allow database user to represent their reality. For example, the possible copyright-abuse-mailbox you are about to present (I had a peak at the slides): great idea. But in our case (the 'subnet case') that would be a company wide contact, whereas the 'real' abuse-c is network specific. We are small enough that it does not really matter (i.e. I'd duplicate the data and be done with it) - but the use case for flexibility exists. [...]
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).
In my particular case we can live with about anything: not many objects, infrequent updates. But even then I'd really love coherence in the DB structure and logic.
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.
Sounds like interesting times ahead :) What's wrong with trying to get back there?
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.
As not all aspects of an organisation are alike (subnet case), and duplicating organisations is a mess (and even impossible in cases like anycast assignments) sub-organisations or departments would be an way to solve this, within the basic database model?
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?
I'd always follow basic logic: the most specific contact adapted to my request. In this case: the tech-c related to the internet resource or it's closest parent, because that seems obvious without reading the database documentation. Any other address only in case of no-reaction / despair - and then all bets are off anyway.
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.
I completely agree. On the other hand, and that might be personal preference, about the only thing I'd value above the database model is coherence in the entries. If only because it is easier to migrate a coherent mess than half a mess :)
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.
My point exactly. And I'll always value flexibility about over-tight rules. If life has taught me anything it's that if the 'wrong' way is too easy compared to the 'right' (and doesn't come with serious inconvenience) it will be used. Sometimes only by ignorance. But that's not something I have to tell the RIPE NCC database team :) cheers, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473