[db-wg] [anti-abuse-wg] abuse-c + org

Hi Tobias,

>> What I was trying to point out is that the current implementation 
>> does not implement the policy correctly as it does not *allow* to 
>> attach an abuse-c to an inet[6]num or aut-num. The indirection via 
>> the ORGANISATION is fine and efficient, but constraining.
> 
> That was in some ways wanted that way.
> 
> The biggest challenge was to find a way that makes 100% sure that 
> there will be no way to what so ever it will be to start creating a 
> new mess in the RIPE DB. So we had to keep very strict.

You are quite optimistic :) You cannot design anything foolproof - fools
are much too inventive. :)

> If we allow direct multiple references and multiply org references we
> would end up in a mess again.

I can see why you wouldn't want multiple references but I don't buy that
a direct reference would create a mess. The concept of 'more specific'
should be somewhat obvious to this community.

> So since I was the proposer of the policy, the implementation impact
>  showed me that this indirect allocation over ORG is a much better 
> way. That's why I agreed on this way and it was reached consensus.

I wouldn't want to challenge the policy process based on my inattention,
but considering that the policy text explicitely mentions inetnum and
aut-num, I never understood the proposed implementation as the only way,
only as a facilitating workaround to inetnum-referenced abuse-c. But
that's probably only me...

> One of the main goals imho of the RIPE DB has to be not ending up in 
> a mess. Because this leads to a unusable DB.

I think the main goal of the RIPE DB is to serve the data that the data
provider wants to be served.

> Having an abuse-c referenced in an asn-num is a "relict" from one of 
> the first proposals I wrote. And I'm fully responsible for
> forgetting about this issue.
> 
> I'm at the moment wondering if there is really a need to have an 
> abuse-c referenced by an aut-num. After the transition phase we 
> should end up with an abuse-c for every single ip-address. So is it 
> necessary?

Frankly: unsure. But in a setup with anycasted IP addresses, maybe
different addresses served by different ASs, I can imagine a situation
were it would be useful.

>> Fully agree - it's probably the most efficient way to do it, but I 
>> see no reason for it to be the only one.
> 
> There is. As described above if we allow direct multiple references 
> and multiply org references we would end up in a mess again.

As I said: not multiple references, only more specific.

>> Well, the policy is met in so far that all queries do return an 
>> abuse-c. However if I, the resource holder, can not chose 
>> accurately which one should be displayed the aim of the policy 
>> (having a good abuse-c) is missed.
> 
> You can in regards of all inet(6)nums. You just have to use ORGs.

In theory yes, but as the ORG is the same, only the abuse handler
different that would mean creating an duplicate of the ORG for the sole
purpose of referencing a different abuse-c. There is a lot potential for
creating a mess in that workaround. (and one of the use cases I have in
mind is a direct anycast assignment - not even sure that I'm allowed to
do that)

More generically I could also imagine having a different abuse handler
for, say, dynamic DSL ranges than for web hosting: having an efficient
abuse handling is obviously also in the interest of the submitter.

>> (and to be honest, returning real data in the 'comment' section of 
>> the result gives me the shivers)
> 
> brrrrrr :-) No please don't do that. :-)

Like:

% Abuse contact for '193.0.0.0 - 193.0.7.255' is 'abuse at ripe.net'

? :)

> I was already talking to some people and tried to find a way to solve
> your requests. We are working on it.

One thing that annoys me in this is that the implementation does not
match the (my?) understanding of the policy text. Whatever the outcome
of this discussion is, I would welcome if they were more aligned (and
yes, I know that the boundaries between policy and implementation are
not always clearly cut).

Best,
Gilles