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 - 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 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. 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.) 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 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. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279