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

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

Tobias Knecht tk at
Tue Jul 6 09:27:00 UTC 2010


after some more research and some really good conversations with several
people and the great feedback from Alex Lawani of AfriNIC I want to
start another discussion about the abuse contact information. So please
give feedback as good as you can, even if you agree with me on this
issue. ;-)

> The input from the community was as follows:
> 1. That a role handle (abuse-c) is used instead of an IRT Object

I first want to sum up the pros for an IRT Object, which will show as
well the cons against a role handle (abuse-c)

- The IRT Object is a dedicated Object just for security and abuse
handling purposes. This is the one and only place, where those
information should be published.

- The IRT Object is already in the AfriNIC Database, which allows
AfriNIC to implement this really fast without a waste of resources.

- The IRT Object is the "tailormade" object, which supports exactly the
needed things.

- In addition with a mandatory abuse-mailbox attribute it delivers all
the needed information, for personal communication and for automatic
abuse report processing. This feature of publishing 2 different contact
addresses is even wished by some ARIN members.

- The abuse-mailbox attribute can be queried with a -b whois option,
that way the query restrictions are not active.

- Why not allow the abuse-mailbox attribute in any other object? Because
than exactly the same thing will happen, that happened at RIPE. There
will be different abuse-mailbox attributes linked into one inet(6)num or
aut-num objects, which confuses and is making things more complicated
than they are today.

- This and the fact, that creating an IRT Object and linking it into the
inet(6)num and aut-num is as easy and straight forward as doing it with
any other object is debilitating the arguments about the IRT Object may
be to complicated.

- The fact that RIPE and APNIC are now using the IRT Object makes things
much more easy. Having AfriNIC

- ...

I hope I did not forget anything important. But I think as well, that
there are lots of good reasons to use the IRT Object and not an
suboptimal abuse-c solution.

> 2. That the role handle (abuse-c) is made optional.

I can partly understand the concerns about this. And so I thought about
a solution which I hope should be liked.

One of the reasons for this proposal is, to have one abuse contact for
every single ip address in the AfriNIC region.

So what about if we would say, the IRT Object is mandatory, but only for
direct by AfriNIC allocated netranges. What this would do, is giving us
an abuse contact for every single IP address and leaves the decision of
adding an IRT Object to the subdelegation in the netrange owners hand.

This way the "first level" netrange owner is receiving all the
complaints about the hole netrange and can decide if it is easier,
cheaper, ... to redirect the messages to the responsible parties, to add
an IRT Object for all or special subdelegations and handle the abuse
complaints about his customers.

At least asking all AfriNIC members having direct allocates netspaces to
create one IRT Object and link it to all their inet(6)nums should not be
a big deal.

For aut-nums I would stay with mandatory, because members who have their
own as-num should as well be able to create one IRT-Object and link it
to one aut-num.

How does this idea sounds like?

> Other than the above, it was apparent that majority of the community
>  did not clearly understand the policy proposal. The discussions that
>  have ensued after the AfriNIC 12 public policy meeting are an 
> attestation to this and have gone a long way in enhancing the 
> understanding of the community and thus the need or not for such a 
> policy in our region.

Are there any questions about the intent of this policy proposal? I'm
happy to answer all the questions you may have.

> I therefore appeal to the community to participate in the discussions
> on this (and other policy proposals) so that we can all contribute
> towards this all important process.

Yes please attend this discussion here and do not wait for the meeting,
because this is delaying the hole process and does not give you time to
think about the effects for you.

I hope this sum up and the new idea for the mandatory part of the
proposal is giving you more information to understand and review the

As already mentioned, if there are questions, please feel free to ask.

Thank you ver much for you patience.



More information about the RPD mailing list