[anti-abuse-wg] Proposal for technical details for abuse contact information in the RIPE Database

Hi Shane

I answered your point about authorised references to PERSON objects
separately as I don't think it is directly related to the technical
proposal for this community policy proposal. The community may wish to
discuss it further, but it may be better in another thread. Let me now
answer the other half of this mail.

If there were only to be two types of ROLE objects then it may not make
sense to develop a generalised ROLE object. But as I illustrated in the
article on RIPE Labs, the IRT object would fit very easily into this model
as a third type of role.

We have listened to comments about the IRT object over the years from
people at RIPE Meetings and feedback from the trainers, who talk to many
members every week. There is only a small group of people who really
understand the complexity of the design of the IRT object. That is why for
many years there were probably more POEM than IRT objects in the RIPE
Database.

It is a good example of using over complicated exceptions to solve a
problem instead of generalising on an existing feature. However you look
at it, the IRT object simply provides contact details for a specific role
within an organisation. But it is not identical to the "admin-c:" role
which is not identical to the "abuse-c:" role. When you look at the wider
picture, an organisation has many role type functions. They may have
slightly different characteristics in terms of where they are referenced
from, the scope of the data they apply to (hierarchies for example), what
type of contact details they present, authorisation issues and how much of
the object should be displayed in different scenarios. But they are all
roles. These differences can be handled by clearly defined business rules.
They are by no means 'arbitrary'.

This is why we made the technical proposal to make that generalisation now
instead of building more one off exceptions. The article I wrote on RIPE
Labs may look a little complicated because I included some of the design
issues and background to explain how the RIPE Database developed into the
animal it is today. If the community accepts this technical proposal as
part of the policy under discussion, we will provide much simpler
documentation explaining how to manage all contact data in the RIPE
Database. This will include illustrated examples of the different role
types, when and how to use them, what needs to be in them and the
relationship between ROLE and PERSON objects.

As a further step we can then improve Webupdates to recognise the
different role types and present templates according to the type. This
would clearly show what attributes are mandatory, optional, (not)allowed
and required for a specific role type. Another step would then be for the
Web Query form and the Query API to also present templates based on role
type. In the long term we want to provide more modern tools for managing
your data in the RIPE Database. As we further develop the Query and Update
APIs we want to take away the need to remember what an RPSL object should
look like in any given situation.

It is a question of taking a series of small steps, each one to improve
some aspect of using the RIPE Database. So rather than leading to
'confusion and frustration' we expect to provide clarity and calmness. It
may look like a big change, but in reality it is a straight forward
cleanup of the software to handle generalised roles and the final
documentation will be much clearer than the article on RIPE Labs.

When the community makes a decision on the policy, if we have the go ahead
to implement this we will develop and deploy it quite quickly. As we now
work with agile software development nothing is ever final. When a
solution is deployed, if the community has any concerns or issues we can
adapt it quite quickly. The aim is to work towards the perfect solution in
a series of small, deployed steps. Then the community can review progress
more often and see if it is the direction you want to be moving in. Change
is much easier with small steps than a giant leap.

I hope this answers some of the concerns over the technical details behind
the communities policy proposal.

Regards
Denis Walker
Business Analyst
RIPE NCC Database Group

> Denis,
>
> On Wed, 2011-11-30 at 16:25 +0100, Denis Walker wrote:
>> The RIPE NCC Database Group has now published an article on RIPE Labs
>> with a detailed explanation of how we propose to implement abuse
>> handling with an "abuse-c:" attribute referencing a ROLE object.
>>
>> https://labs.ripe.net/ripe-database/abuse-handling-in-the-ripe-database
>
> Thanks for putting this together.
>
> Basically, I think that the basic split between ABUSE and STANDARD ROLE
> objects does not make a lot of sense, and will likely lead to user
> confusion and frustration. Some of the ideas you've presented do make
> sense, but make sense for any contact data rather than restricting them
> via arbitrary business rules.
>
> One thing that I think would be a positive step forward for the RIPE
> Database is *not* to restrict references to ABUSE ROLE, but rather to
> restrict *all* references to person or role objects. I believe the
> database currently still allows me to reference any person/role object
> if I want to. This is a bug, not a feature, and I think adding
> "mnt-ref:" to person/role objects would be a better way forward than
> adding yet another special case. (This was introduced as a special case
> to the irt type, but then generalised in the organisation object.)
>
> I also suggest that normal access controls should apply to roles when
> used for abuse. Abuse desks don't like spam either.
>
> --
> Shane
>
>
>
>