[acm-tf] Abuse Contact Information - Policy Proposal

Hi Peter

My responses are inline below.

cheers
denis

On 14/10/11:42 5:20 PM, Peter Koch wrote:
> Denis, all,
> 
> On Mon, Oct 10, 2011 at 04:50:48PM +0200, Denis Walker wrote:
> 
>> On 10/10/11:42 4:24 PM, ale at tana.it wrote:
>>> On 10/Oct/11 15:40, Denis Walker wrote:
>>>> "The "abuse-c:" reference to an abuse handler should make use of the
>>>> hierarchical nature of the resource data to minimise the workload on
>>>> resource holders and facilitate good database design."
>>>
>>> +1, the above paragraph works for me (assuming abuse-mailbox does not
>>>     satisfy that criterion.)
> 
> I'm not sure who or what this principle would apply to:
> 
> 1) the proposal in general (motherhood and apple pie ...)
> 2) the maintainer when selecting the traget for abuse-c
> 3) the query strategy within the DB interface (assuming there are
>    objects inthe hierarchy with "abuse-c" and such without

My reasoning for suggesting something along these lines was to avoid the
situation in APNIC where they added a reference to every INET(6)NUM
object. This resulted in millions of repeated, redundant references.
That is a bad design from every angle. So my point was that if the
policy is going to include any details of design or implementation it is
better to promote good design than bad design. You may decide to keep
the policy to outlining the principles of what you want and not touch at
all on design. Then after the policy is approved, the RIPE NCC can
propose a detailed design to the TF for final consideration before we
implement anything.

> 
>> Just to be clear on what this means. The technical suggestion is for the
>> "abuse-c:" attribute to reference a ROLE object with a "role-type:" set
>> to abuse. In this ROLE object there will be an "abuse-mailbox:" attribute.
> 
> The per-object attribute "abuse-mailbox" was, IMHO, a design violation and therefore
> I support a per-object attribute "abuse-c" (where appropriate) with a link/handle
> to a role object.  Consolidation and migration strategy to be defined.
> 
> Making the "abuse-c" mandatory does still not sound convincing to me.
> For that "role" like object (somewhere between tech-c/role/irt) the details need
> to be hashed out, but i'm struggling with the attribute "abuse-mailbox"
> for two reasons: 1) it carries legacy; 2) it is inconsistent with other
> objects: we say email: in both tech-c and admin-c kind of objects and
> do not say  tech-mailbox or admin-mailbox;

As the new usage is similar but not identical to the current
"abuse-mailbox:" a new name may well help with clarity in explaining the
new design.

Mandatory or not is completely outside the technical scope so I will
keep out of that discussion. It is just a matter of defining appropriate
business rules when you decide what you want.

> 
> If we want to differentiate between plain text/prose (email:) and ARF like reporting,
> then let's define a second attribute, e.g., "automated-report" or the likes.
> 
>> Because of the hierarchical nature, if an end user has their own abuse
>> team, they can reference their own abuse type ROLE object with an
>> "abuse-c:" in the INETNUM object for their assignment. This will
>> override the LIRs abuse team reference only for this one assignment.
> 
> IRT objects used to be subject to a TI based oversight, but my understanding is
> we want these abuse-role objects to be freely creatable.
> 
> Creating a reference to an abuse-role will need authorization (either by maintainer or
> otherwise).

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.

So if you want an 'abuse' type role to be creatable by anyone, only
referenced by an "abuse-c:" in certain objects, requiring authorisation
to add a reference and searchable by some hierarchical way we can define
the business and syntax rules to do that.

If you then want an 'irt' or 'csirt' type role that requires
authorisation to create and reference, only referenced by a "csirt-c" in
certain objects, etc we can define the business and syntax rules to do that.

> 
> The question of a 'bottom up' or 'top down' search for the abuse-role reference
> is one of the presentation system, not necessarily inherent to the DB, unless the
> DB ought to support search advice. More precisely, is there a point in enabling,
> say, the ISP to add their abuse-object to responses where a customer provided their
> own. I think there are pros and cons in both directions.

Again with this role type model all this is just a matter of defining
the business rules. If the policy defines the responsibilities, we can
write the business logic to return the available data.

> 
> -Peter
> 
>