[db-wg] abuse-c + org

Hello,
in (not only) ORGANISATION object we had abuse-mailbox field available
already, even it was optional.

>From database point of view creates current implementation inefficient
overhead (both technical and administrative) - there's requirement of
new ROLE object containing abuse-mailbox insteand simple filling of
abuse-mailbox in ORGANISATION object. And only! role - even existing
PERSON has abuse-mailbox optional, too...

Even if we have abuse-mailbox filled in ORGANISATION object (and also
having IRT object with referencing mnt-irt containing similar
information), new abuse-c ROLE is _required_ in ORGANISATION object.
This require modification of _every_ ORGANISATION object, even if there
was reference of abuse-mailbox in other way already.

Mentioned mnt-irt was usable in INET(6)NUM object without any problems.
So your argumentation about abuse-c in INET(6)NUM doesn't make sense.
Why we cannot have here abuse-c role and/or abuse-mailbox fields? Why
abuse-mailbox in current PERSON fields (used in admin-c/tech-c) isn't
sufficient?

IRT object is - in the fact - also abuse contact point. We used it to
reference direct abuse contact to end-user of particular IP space
(because direct abuse-mailbox I cannot use in INET(6)NUM). New abuse-c
implements almost similar thing...

In general, I think it's wrong, when several working groups should
modify database scheme by their own policies. Not every person is
watching all RIPE mailing lists. DB-WG should be arbiter here in all
cases, and not only RIPE-NCC - i don't thing RIPE NCC / ANTI-ABUSE-WG
considered all existing possibilities (specially IRT, abuse-mailbox in
other objects...).

Current implementation is still inconsistent - somewhere I can use
abuse-c, somewhere abuse-mailbox directly, somewhere mnt-irt... but
there're objects, where some of fileds mentioned above I cannot use.

The goal is simple - publish abuse contact and I support this at all.
But from database point of view - there're several ways - and all should
be valid (not only abuse-c ROLE). Even adding abuse-mailbox and abuse-c
to INET(6)NUM. This goal can be reached by multiple ways. Requirement of
_new_ field, where existed other options already is wrong and unsystematic.

About documentitation you mentioned (this is job of RIPE NCC) - it
should be updated - not (only) archived. You used a lot of links for
your argumentation - this should be in _single_ place, in documentation
(not only in mailing list archives, not only in blogs etc).

In general - informations are on too many points and you described that
clearly (ANTI-ABUSE-WG, DB-WG, RIPE-LABS etc). One of RIPE-NCC role
should be some kind of coordination between all working groups.

I wrote this long email with one goal in the mind - things should be
kept simple and stupid...

With regards,
Daniel


On 07/01/2013 06:10 PM, Denis Walker wrote:
> These points were discussed on the Anti Abuse Working Group mailing
> lists quite extensively in June and December 2012. As you correctly
> pointed out policy ripe-563 says "This policy introduces a new contact
> attribute named "abuse-c:”, that can be included in inetnum, inet6num
> and aut-num objects." During the discussions last year it was asked if
> the RIPE NCC should 'interpret' policy. Our understanding is that this
> policy expresses the desire and goal of the RIPE community for a new
> feature in the RIPE Database. To achieve these goals this desire needs
> to be translated into, and incorporated in, an efficient, technical
> database design.
> 
> In the RIPE Labs article
> https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011-06
> we pointed out that there are about 3.7 million Internet resource
> objects in the RIPE Database. To add an "abuse-c:" attribute physically
> to each of these objects is unmanageable. Every users network is
> physically linked to their existing ORGANISATION object. Each user only
> needs to add one "abuse-c:" attribute in their ORGANISATION object and
> all their networks are covered.
> 
> When any address is queried in the RIPE Database, the software will find
> the related "abuse-c:" reference and return this information as part of
> the query. By returning this information as a default with each query we
> have satisfied the policy requirement that the "abuse-c:" is "included
> in inetnum, inet6num and aut-num objects". It is not physically stored
> in each object in an unmanageable way, but logically associated with
> each object in an efficient and manageable way.
> 
> This implementation was presented to and discussed by the community on
> the Anti Abuse Working Group mailing list last year and Brian declared
> that a consensus had been reached in his email on December 5, on behalf
> of the co-chairs of the DB and AA Working Groups:
> http://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2012-December/001993.html
> 
> 
> In a follow up RIPE Labs article
> https://labs.ripe.net/Members/denis/creating-and-finding-abuse-contacts-in-the-ripe-database
> the RIPE NCC explained how this implementation works in practise. You
> may recall that we discussed the details of how these references using
> the ORGANISATION object worked and how they can be fine tuned:
> http://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2012-December/001998.html
> 
> 
> The old RIPE Database reference manuals on the ripe.net web site still
> refer to the use of "abuse-mailbox:" attributes in other object types,
> but don't refer to "abuse-c:" at all. These attributes were never
> allowed to be added directly to the resource objects even in the legacy
> software. These old reference manuals are now out of date in many
> respects and should perhaps be clearly marked as archived documents.
> 
> I hope this answers your specific questions.
> 
> Regards
> Denis Walker
> Business Analyst
> RIPE NCC Database Team
> 
> 
> On 27/06/2013 10:06, Gilles Massen wrote:
>> Dear WG, and RIPE NCC staff,
>>
>> While trying to add an abuse-c to our resources, I was quite surprised
>> that you can only attach the abuse-c to an org object (while the policy
>> suggests otherwise and implementation notes are not very clear on the
>> limitation).
>>
>> So I'd like to ask why this restriction exists? What is wrong with
>> adding an abuse-c directly to an inet[6]num or aut-num?
>>
>> Best regards,
>> Gilles
>>
>