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