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

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
>