[acm-tf] Abuse Contact Information - Policy Proposal

HI Peter

On 17/10/11:43 11:52 AM, Peter Koch wrote:
> Hi Denis,
> 
>>>>> On 10/Oct/11 15:40, Denis Walker wrote:
>> One of the benefits of implementing this "role-type:" is that it is
>> extendible beyond just abuse handling. You can define whatever role you
>> need, abuse handling, csirt team, customer support, billing, sales, etc.
>> To define any new role, say abuse handling, you add a new type 'abuse'.
>> Optionally define a new "xxx-c:" attribute and which objects can include
>> it. Then define a set of business rules to apply to this role.
> 
> Do we have any precedent to this and does it increase operational clarity
> to have 'sub types' for db objects?  I'm not sure i understand the benefit
> that would go beyond the current limited scope.
> 
> -Peter
> 

In a way I would say we do have a precedence for this. The INET(6)NUM
objects have a "status:" attribute. Depending on the value of this we
have a whole series of different business rules that apply. So you can
'see' the status as a form of sub-type.

Also with MNTNER objects. Although they don't have a sub-type, they are
referenced in many different ways. Again depending on how you reference
a MNTNER different business rules apply. This is a form of (badly
designed) sub-typing by overloading the MNTNER object references with
different types of authorisation.

Personally I do think sub-typing can improve clarity and usability, if
done well. If you try to map an organisation onto the RIPE Database
there are many different uses for 'role'. This object is quite flexible,
but it has never been used properly since it was introduced. Maybe by
introducing sub-types we can 're-advertise' this object and finally get
people to group people (PERSON objects) into roles and reference the
ROLE object everywhere else.

cheers
denis