Search RPD Archives
[AfriNIC-rpd] Re: Return of Policy Proposal RPD Mailinglist: Abuse Contact Information in the AfriNIC Service Region
tk at abusix.com
Wed Jul 7 07:36:17 UTC 2010
>>> 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:
>> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 262 bytes
Desc: OpenPGP digital signature
More information about the RPD