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

[AfriNIC-rpd] abuse contact information in whois database

Tobias Knecht tk at
Tue Jul 6 08:13:41 UTC 2010

Hi Alex,

thank you very much for your response. That is really helpful.
I will sum up all your feedback in another mail later.
Just a few comments directly on this feedback.

> To answer your question, the IRT object would be created in either of
> two ways:
> i) dbupdate or
> ii) myAfriNIC (currently unimplemented)
> much like we already do now for other objects. That is to say that the
> user won't have to jump through any additional hoops to get this done.
> To create an IRT object via the dbupdate the user will simply have to
> send an e-mail matching the template below to auto-dbm at
> <mailto:auto-dbm at>:
> *_irt_*:            [mandatory]  [single]     [primary/look-up key]
> address:        [mandatory]  [multiple]   [ ]
> phone:          [optional]   [multiple]   [ ]
> fax-no:         [optional]   [multiple]   [ ]
> e-mail:         [mandatory]  [multiple]   [lookup key]
> abuse-mailbox:  [optional]   [multiple]   [inverse key]

The policy proposal says the abuse-mailbox attribute has to be mandatory
and should be used as a mailbox for automatic generated abuse
complaints. While the e-mail attribute should be used for personal
communication, between abuse departments.

> signature:      [optional]   [multiple]   [ ]
> encryption:     [optional]   [multiple]   [ ]
> org:            [optional]   [multiple]   [inverse key]
> admin-c:        [mandatory]  [multiple]   [inverse key]
> tech-c:         [mandatory]  [multiple]   [inverse key]
> auth:           [mandatory]  [multiple]   [inverse key]
> remarks:        [optional]   [multiple]   [ ]
> irt-nfy:        [optional]   [multiple]   [inverse key]
> notify:         [optional]   [multiple]   [inverse key]
> mnt-by:         [mandatory]  [multiple]   [inverse key]
> changed:        [mandatory]  [multiple]   [ ]
> source:         [mandatory]  [single]     [ ]

So this is straight forward a normal object.

> In order to link the IRT object to the inetnum and inetnum6 objects an
> mnt-irt attribute will have to be added to the latter two and (perhaps)
> made mandatory. That; however, is a backend change and shouldn't unduly
> affect the users' experience at all. 

And this has to be done with an abuse-c as well. Which is not affecting
the users' experience as well.

> The steps to do this in myAfriNIC would be relatively painless- at least
> from a users' (rather than an implementers') point-of-view. The user
> would simply be presented with a form in which to enter the
> aforementioned information and, once its been validated, the data would
> be written to the WHOIS database. The process for creating inetnum and
> inetnum6 objects would then need to be modified to take into account the
> IRT object which has to have been created beforehand. Conceptually it
> might look something like this:
> *_inetnum_*:        [mandatory]  [single]     [primary/look-up key]
> netname:        [mandatory]  [single]     [lookup key]
> descr:          [mandatory]  [multiple]   [ ]
> country:        [mandatory]  [multiple]   [ ]
> org:            [optional]   [single]     [inverse key]
> admin-c:        [mandatory]  [multiple]   [inverse key]
> tech-c:         [mandatory]  [multiple]   [inverse key]
> status:         [mandatory]  [single]     [ ]
> remarks:        [optional]   [multiple]   [ ]
> notify:         [optional]   [multiple]   [inverse key]
> mnt-by:         [mandatory]  [multiple]   [inverse key]
> mnt-lower:      [optional]   [multiple]   [inverse key]
> mnt-domains:    [optional]   [multiple]   [inverse key]
> mnt-irt:	[mandatory]  [multiple]   [inverse key] # <---- this could be an additional field in a form in myAfriNIC tying the IRT and inetnum objects
> changed:        [mandatory]  [multiple]   [ ]
> source:         [mandatory]  [single]     [ ]

From a users perspective this looks straight forward again. So in my
opinion there is no reason to switch to a less comfortable solution
because of the IRT Object being to complicated, because it is not.

Thank you Alex for taking the time to provide us with your great




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the RPD mailing list