[acm-tf] Abuse Contact Information - Policy Proposal

HI Alessandro

As far as I understand the proposal you are considering is to add the
"abuse-mailbox:" attribute to the ROLE object, along with a new
attribute "role-type:". Business rules in the software will make sure
that "abuse-mailbox:" must be added to any ROLE object used for abuse
handling and referenced by an "abuse-c:" attribute.

Then as a follow up, after this policy implementation has been deployed,
there will be a clean up phase where all "abuse-mailbox:" attributes in
other object types will be migrated/merged/deleted. The syntax of the
other object types can then be changed to deprecate this attribute from
anywhere other than the ROLE object. So in the end you only have the
"abuse-mailbox:" attribute in one place.

With the attribute in only one place and implemented using the
hierarchical nature of the resources, the workload on resource holders
will be kept to a minimum.

In my previous email you can replace 'LIR' with 'holder of a less
specific resource'.

regards
denis


On 10/10/11:42 7:12 PM, Alessandro Vesely wrote:
> On 10/Oct/11 16:50, Denis Walker wrote:
> 
>> On 10/10/11:42 4:24 PM, ale at tana.it wrote:
> (oops, sorry I picked up the wrong From:)
> 
>>> 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.)
>>>
>>> Do we expect that some end-users will apply for overriding an abuse-c
>>> with the data of their own abuse-teams?
>>
>> 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.
> 
> Yeah, it sounds tricky.  Right now one can set abuse-mailbox in a
> number of objects.  We want to add yet another role object for abuse
> contacts.  I have two questions:
> 
> 1.  How does it reduce the workload on resource holder?
> 
> 2.  Is there a plan to change the intended use of the abuse-mailbox
>     attribute at some point in time after the introduction of abuse-c?
> 
>> 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.
> 
> Fine, I'd propose to add some text similar to the last quoted
> paragraph as well.  I say /similar/ because of the LIR; do you
> actually mean the mntner?
> 
> 
>