Hi Gert On 07/03/2016 13:33, Gert Doering wrote:
Hi,
On Mon, Mar 07, 2016 at 12:14:36PM +0000, Niall O'Reilly wrote:
I???m glad to see various people step up and reject abuse-c but is there a workable suggestion?
I think Peter Koch, Gert Doering, and Gilles Massen have answered this question adequately already.
Admittedly, I just stated my dislike for abuse-c: in its current implementation and did not suggest alternatives.
But seems I should so :-)
I would like abuse-c: much more if it were changed in two ways:
- permit abuse-c: in inet(6)num: objects
This could be done, although I think there are other ways to improve the implementation of abuse-c. I specified some options on RIPE Labs 2 years ago https://labs.ripe.net/Members/denis/suggestions-for-improving-abuse-handling
- permit abuse-c: to point to a normal person: object, not only role:
my main issue is the forced indirection through organisation: objects which might not exist ("because there is no need to create a separate organisation: object just to earmark a specific inetnum: so abuse could go somewhere else").
The reason I proposed this implementation is because I expected, at the time, we would go on to do a review of the data model. At that time many people were interested in doing that. But, alas, not now it seems.
The requirement for role: objects is also annoying if all there is is just a single person - so admin-c:, tech-c: point to "the person that is responsible for everything", while abuse-c: needs a new object.
Please learn from past mistakes. When this database was first deployed in 2001 it lacked a lot of important business rules that should have constrained some functions to work in the way they were designed to work. A PERSON object was/is intended to define a real person. It should ONLY be referenced in a ROLE object. PERSON objects should never be referenced from anywhere else. Most 'functions' in an organisation equate better to a 'role' than a single 'person'. Often an abuse desk or tech support has several people 'behind' the contact details. Usually someone asking for help or making a complaint does not care who the person is as long as they solve the issue. So it is better to define a single ROLE object and not define any PERSON objects. This maps the database more closely to reality.
All in all, these requirements force me to add and maintain extra objects for every abuse-c: I want to register, which annoys me enough to just not do so - for the PI stuff, I just let the NCC go ahead and create needless role: objects that point to the e-mail of the admin-c/tech-c, and for our allocations I registered a "master" abuse-c: and do not bother to register more-specifics even if that would make sense for certain projects.
As for determinism, I do not see this as much different from today - the sequence for finding the abuse contact for a specific IP address could be:
- if the inet(6)num has an abuse-c:, use that - if it has an org: object, and that one has an abuse-c:, use it - find the closest less specific inet(6)num: object that either has its own abuse-c: or has an org: object with an abuse-c:
- if the topmost inet(6)num: object has status: LEGACY, point to admin-c:/tech-c: (objects that the NCC has assigned/allocated would always have an org: and abuse-c:-in-org:, so this is the fallback clause for legacy objects)
- stop there (DO NOT RETURN ARBITRARY CONTACTS OF MAINTAINER OBJECTS THAT HAVE BEEN USED FOR MAINTENANCE OF REFERENCED PERSON: OBJECTS ETC.)
Yes this can be done. My argument against this is you may end up with lots of useless, redundant information in the database that will not be used by the tools the NCC provides (they use the proper search sequence) but may well be 'found' by people like Suresh who seems to think he has to dig into the database manually looking for contact details.
As for legacy object holders: I think "more talking to them" is more useful than mandating stuff that there is no contractual authority backing it - and with the flow suggested above, you'd get a contact back that at some point in time was accepting responsibility for the network in question.
If everything to do with legacy resources has to be done by "more talking to them" why did you bother to create policy ripe-639 RIPE NCC Services to Legacy Resource Holders? I thought one of the points of that was to be able to do things by general agreement with representatives of the collective of legacy resource holders rather than talk to each one individually.
If that contact is stale, mandating a new database field ("abuse-c:") is not going to make it less stale.
Maybe some extended outreach activity could be started to actually ensure that some human is alive at ERX holders that the NCC had no contact anymore since <x> years - but friendly, not pushy. They have been here first, we have no authority over them.
2007-01? cheers denis
Gert Doering -- NetMaster