Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[AfriNIC-rpd] abuse contact information in whois database (AFPUB-2010-GEN-002)

McTim dogwallah at
Tue May 25 18:02:06 UTC 2010


I tend to agree with Graham on all points made below.


"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel

On Tue, May 25, 2010 at 8:52 PM, Graham Beneke <graham-ml at> wrote:
> Hi All
> The RPD list has been off my radar for a little while and I have only
> recently become aware of this proposal. Below are my thoughts:
> On 18/04/2010 21:51, Tobias Knecht wrote:
>> 1.  Incentive:
>> This is a proposal to introduce a mandatory reference to IRT objects
>> in the inetnum, inet6num and aut-num objects in the AfriNIC Whois
>> Database.
>> It provides a more accurate and efficient way for abuse reports to reach
>> the
>> correct network contact.
> I fully support the concept of improved abuse reporting for netblocks and
> autonomous systems.
>> 4.  Details of the proposal:
>> It is proposed that AfriNIC:
>> 4.1 Institute a mandatory reference to an IRT object in inetnum,
>>     inet6num and aut-num objects.
> Having reviewed some of the available documentation[1] pertaining to the new
> IRT object I fail to see how introducing a new object and a far more complex
> schema is going to be the solution.
> Additionally - the requirements for trustbrokering and what appears to be a
> lengthy process to obtain an IRT object are likely to result in less and not
> more accurate data being captured into the whois db.
>>     In terms of implementing a mandatory IRT reference, it is
>>     suggested that this be part of two, established actions:
>>     - The next time an organization attempts to update an existing
>>       inetnum, inet6num or aut-num object
>>     - When new inetnum, inet6num or aut-num objects are added to the
>>       database
> This is a logical migration path.
>> 4.3 Delete abuse-mailbox fields in all objects that do not define an
>>     IRT, and delete the trouble field everywhere mid 2011.
> Not relevant since we don't currently support abuse-mailbox.
>> 5.1 Advantages
>>     - Networks will be able to supply their own, direct contact
>>       information for abuse departments.
>>     - Abuse complaints will not be sent to the "wrong" contact any
>>       more.
>>     - This permits greater administrative and operational flexibility,
>>       and faster abuse handling will be possible.
>>     - Since AfriNIC is using the same whois system as RIPE and APNIC,
>>       the IRT-Object and the abuse-mailbox attribute are already
>>       existant in the system. That makes implementing it very easy and
>>       fast.
> All valid points.
>> 5.2 Disadvantages
>>     - Introducing a mandatory reference to the IRT Object will establish
>>       a new object. This object, like all other existing objects, will
>>       face the data accuracy problem.
> This is my primary concern. Many LIRs in the AfriNIC region already struggle
> to maintain their objects correctly and with no perceived benefit to this
> new object I expect take up will be low or invalid data will be entered into
> the db in order to bypass the requirements.
> Is there any reason that the current 'role' and 'person' would not be
> sufficient for designating an abuse POC? They contain all the relevant
> email, phone and address details that are likely to be needed for dealing
> with an abuse incident.
> I propose that a far more useful addition to the AfriNIC whois would be an
> abuse-c link for inetnum, inet6num and aut-num objects. This link line could
> then reference any existing role or person objects.
> LIRs who have the requirement can then create role objects for their abuse
> team in order to direct the communication to the relevant POC.
> References:
> [1] IRT Object FAQ
> regards
> --
> Graham Beneke
> Apolix Internet Services
> E-Mail/MSN/Jabber: graham at   Skype: grbeneke
> VoIP: 087-550-1010                       Cell: 082-432-1873
> _______________________________________________
> rpd mailing list
> rpd at

More information about the RPD mailing list