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

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