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

Hi Gilles,

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

That is true and that was never the intend. But we tried to have 
something that can be checked with rules to find the fools. :-)

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

We would end up in some cases having 2 or more possibly different 
abuse-c objects for 1 resource.

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

I think I have to slightly disagree here. :-)
If every data provider can put whatever he wants in the DB ...
There are rules and these rules are usually policies. BUT the policies 
proposal process is a process that has the right to change policy texts 
while discussion is going on. And yes we or better I made the mistake to 
not adjust the policy text at the end completely to what the 
implementation process was. BUT never the less the policy as is worked 
for the majority of people otherwise it would not have been consensus 
called by Brian.

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

Maybe this is something we have to discuss further more.

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

You can be as specific as you want to be. you just have to go the way 
over the ORG. I'm not 100% but I think the ORG might be a bit misleading 
here. ORG doesn't mean a company. It can be different divisions of an 
Organisation.

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

To be honest I'm not sure either with the anycast assignments.

As already mentioned: ORG is not a company. It can be a division of a 
company.

So if you are talking about dynamic DSL ranges and hosting ranges, you 
can create an ORG for Hosting and DSL. In future, when you add new 
resources or change stuff in the abuse-c you will have to change it at 
one single point. and not in all ranges. So this leads to a much easier 
way of maintaining it. Yes the pain now will be bigger until everybody 
has build up the new structure and has it in place.


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

As mentioned, my fault. I will check if we can change the policy text in 
a few points to match the real world plan we have agreed on as a policy. 
Otherwise, there will be some more policy proposals coming up soon so 
maybe we have the chance to get things straitened out a bit.
Sorry again for that.

Thanks,

Tobias