[db-wg] abuse-c + org

Hello Daniel,

a lot of your concerns, questions and misunderstandings are clarified in 
official documents provided by RIPE NCC. I will go through your email 
and try to clarify some of these things, since I have been the proposer 
of this policy.

> 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...

The main idea of the proposal was to have "_ONE_" single place to 
publish abuse contact information and not several. That means: 
implementation of abuse-c takes several steps. One of them is a cleanup 
phase. This cleanup will try to clean up RIPE DB as much as possible. 
Within this step it will for example made sure that abuse-mailbox 
attribute will only be shown in abuse-c contacts and not in admin-c or 
tech-c objects in future.

At the moment it is correct that it looks a bit messy. So please stay 
tuned a bit longer until clean up phases will start and show first results.

> 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...).

This is exactly what we didn't do. It was agreed by all involved WG that 
discussions will take place on AA-WG mailinglist. Updates about the 
policy proposal have been communicated on this list and in the sessions 
of all involved WG at every RIPE Meeting.

In addition to that we discussed this in a task force and with RIPE NCC 
technical staff and let them come up with an implementation plan that 
also fits their plan of future development. So all important parties 
have been involved and agreed at the end to the implementation plan, 
which was of course publicly available.

> 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.

Right. This is a cause of a not already started clean-up phase, which 
can not happen before some other steps that are already in process.

> The goal is simple - publish abuse contact and I support this at all.

Nearly right! The goal is to publish abuse contacts at "_ONE_" place 
that is always the same and does not let any space for discussions.

> 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.

This "all valid" ruleset lead to the "mess" we have in the database 
today. The mess you call inconsistency. ;-)

We ended up having several different contact information about the same 
ip-address/range/space. Several as abuse-mailbox in addition with 
mnt-irt. This lead to confusion of people who didn't know where they 
should publish their data and confused the requester about where to look.

abuse-c will fix all of these issues!


Thanks,

Tobias

-- 
being 50% AA-WG Chair and 50% Policy Proposer in this email :-)