[acm-tf] Abuse Contact Information - Policy Proposal

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

I fully agree to the part with not promoting design information within
the proposal. How RIPE NCC is keeping their things together is imho
nothing that should be under discussion. As far as I know we do not
discuss which hardware they use, which programming language they use and
we should not discuss which database and which database model they use.
I agree with Denis that we can talk through this in this TF, but not in
the community. Community had the chance to be part of the TF and join
the discussion. That's why we are here, because we took the chance.

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

Changing the abuse-mailbox attributes name or not is not that important
in my opinion. It can lead to clarification, but it also can lead to
confusion and the "wtf, yet another abuse thing in the whois?" feeling.

And imho abuse-mailbox or postmaster-mailbox are common known wordings.
Changing it leads probably to confusion.


I will send another message within the next minutes which contains a
version of the policy text with hopefully all discussed changes.

Thanks,

Tobias

-- 
abusix












-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: OpenPGP digital signature
URL: <https://www.ripe.net/ripe/mail/archives/acm-tf/attachments/20111015/8ed93943/attachment.sig>