[acm-tf] Abuse Contact Information - Policy Proposal

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

> 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 limk/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;

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).

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.

-Peter