[AfriNIC-rpd] Re: Return of Policy Proposal RPD Mailinglist: Abuse Contact Information in the AfriNIC Service Region

[Tobias Knecht]

Hi,

>>> It is my belief that the IRT object would result in this type of duplication
>>> and loss of synchronization regardless of the front-end implementation.
>>> If not immediately (assuming a perfect initial implementation of the
>>> front-end), then, likely in the longer term as the synchronization
>>> requirement gets forgotten in some future update to the front-end.
>>
>> The point is, that we are not bringing up all our policy proposals at
>> once, so we would like to go step by step. And the problem you are
>> mentioning is not a problem of having a dedicated abuse contact object,
>> it's more a problem of data accuracy and people forgetting about
>> updating their objects.
>>
> The IRT object being used would create exactly the problem I am
> describing. I'm not sure why you can't see the correllation between
> the action (requirng an IRT object) and the result (duplication of
> data and loss of synchronization).

Sorry for not understanding it. But I can only duplicate data that is
already there. But abuse specific data is not there. There are no places
to put in non filtered abuse@ addresses. There are no places to add a
communication address. There is no single point I can look at and find
everything I need.

>> Just have a look at this:
>> http://www.apnic.net/policy/proposals/prop-084
>>
>> This would be the next step after the abuse contact object.
>>
> I'm having trouble understanding how your next proposal is
> supposed to somehow cause me to ignore the problems with
> your current proposal.

In my opinion the duplication problem is not a problem and the loss of
synchronization will be faced by this next proposal.


Thanks,

Tobias


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20100707/865e7e06/attachment.sig>