Hello,
If I want to change stuff "in the abuse-c", I change it "in the abuse-c", so that argument just doesn't hold.
There are members that have just a few more resources than others and possibly a much more complicated structure. The new way is generalized and by this easier to maintain and more flexible without destroying structure.
This indirection, always using an org, is nice from a computer science and database design point of view, but if you want people to *accept* and *use* what you give them, you should design something that people like to use.
There were a few phases in the policy proposal process where exactly this could have happened. It did not! There have been a few cases which have been discussed on the mailing list and after all we asked for feedback of all people that brought up concerns if they are happy with the way we tried to solve them. The majority has been happy with it. Overall I got extremely good feedback from members in Dublin. Even the numbers tell us that it's not that people do not like the new way. Of course there will always be some that do not like it, but that's why this is a community and a democratic process.
I find the idea quite useful, and adding a single object (abuse-c) for a single purpose is perfectly fine, but having to add extra objects just to fulfill synthetic constraints is annoying me, so I don't do it, and the quality of the abuse-c: is not as good as it could be (because I don't bother to add more detailed information).
The intend was to put real life scenarios into database. You usually always have resources given to organizations. If it's different teams within a company or if it's business customers having their own ranges doesn't matter. Even both is easily doable with the new structure. The new structure seems in the first step a bit more complicated, but makes things so much easier over time. That's what I heard a lot from people by talking to them in Dublin. Funny enough a lot of members were already asking me why we are not doing the same with admin-c and tech-c. Not updating will lead into an automatic update by RIPE NCC. Data accuracy is another part we are working on at the moment. There will be some ideas coming up on the mailing list before Athens in October. We already have some ideas in mind, but I'd rather listen to the community discussion happening at the moment and figure out that we not missed something.
So, how exactly did anyone benefit from this "must have org!" constraint?
For huge organizations it's getting easier to manage and update their huge amounts of resources. For very small organizations it is very easy, because they have one single place to organize their objects. Easy to have everything setup in the same way. Easy to split and not getting confused. Midsize companies can maybe profit from both. And if somebody not benefiting from any of these things - I'm sorry. And as already mentioned: Majority of people I talked to like it a lot.
(And for the argument "it wouldn't be clear, then, which one takes precedence" - that's easy: document it - and it's quite obvious to anyone but a computer scientist, I'd say - "if there is an abuse-c:, take that one, if not, take the org:, if neither, go less specific and repeat")
I guess that would have been possible. But we (Proposer, Task Force, RIPE NCC DB Team, several WG Chairs, ...) didn't decide this way. We always communicated that this is only a first step of what we have on our agenda (Further clean up, data accuracy, ...). So I guess there will some thing coming up that make things more clear and some others that create different confusion again. Never the less our aim is to be as open as possible, what we always tried and try to be. So if there are further questions, concerns or ideas please let us know and we will do our best to answer them or take them in considerations and discuss them any further. Thanks, Tobias -- AA-WG Chair