[AfriNIC-rpd] abuse contact information in whois database

[Tobias Knecht]

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 afrinic.net
> <mailto:auto-dbm at afrinic.net>:
> 
>     
> *_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
explanation.

Thanks,

Tobias

-- 
abusix.org



-------------- 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/20100706/fcae44cf/attachment.sig>