[db-wg] [anti-abuse-wg] objection to RIPE policy proposal 2016-01

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: </ripe/mail/archives/db-wg/attachments/20160307/071747d0/attachment.sig>