[AfriNIC-rpd] Staff Comments & Implementation Impact Analysis for Policy - Abuse Contact Information in the AfriNIC Service Region (AFPUB-2010-GEN-006)

[Tobias Knecht]

Hello everybody,

>> 1.) If you use normal person or role objects we will run into whois
>> query restrictions. Same problem RIPE is having at the moment.
> 
> There will always be Whois query restrictions as there are operational
> considerations to take into account.  If you plan to do a high number of
> queries, it is better to talk to AfriNIC so that it can provision
> resources accordingly, assuming that it agrees to your request.

I fully understand that you will have query restrictions on personal
data and I understand that you have query restrictions at all, but there
must be a much higher threshold for abuse contact information as for
personal data.

>> 2.) If you allow to add an abuse-mailbox attribute to every person or
>> role object it will lead into a big mess. At the end you have an
>> admin-c, tech-c and abuse-c with different abuse-mailbox attributes
>> referenced by the same inetnum. So whois will show you 3 different
>> abuse-mailbox attributes and that will lead into the same confusion as
>> it does at RIPE at the moment.
>>
>> To avoid the above mentioned problems I would take the abuse-c link it
>> to a "special" role account that has to have an abuse-mailbox attribute
> 
> Section 2.a of the analysis mentions that:
> 
>   "It is envisaged that each object above will be modified to include an
>    extra optional attribute that could be called "abuse-c", and that it
>    would be a reference to a normal person or role object."
> 
> That object can only be referenced once (Section 2.b) and it points to
> abuse-mailbox. As there would be only one abuse-c, the person or role
> used does not matter as you will be able to locate the required mailbox.

So you have a person or role object that can not be linked by admin-c or
tech-c? And can only be linked by abuse-c?

Or do you mean that such an object can only be referenced once within an
inetnum?

What happens if John Doe has an object and he is admin-c of an inetnum.
Can he add an abuse-mailbox to his object an be admin-c and abuse-c in
the same inetnum?

What happens if John Does object has an abuse-mailbox attribute and
Charly Chaplins object has an abuse-mailbox attribute as well. Can John
Doe be the admin-c and Charly Chaplin be the abuse-c in the same
inetnum? Showing 2 different abuse-mailbox attributes while quering one
an the same inetnum?


> You mentioned some problems with RIPE.  Could you provide some details
> bout that?

Abuse contact information are messed up in the RIPE database. There are
too much possibilities (IRT, abuse-mailbox within person, role, irt and
org objects, remark fields, ...). Those possibilities can not be parsed
in an easy way. There is no way to check data accuracy.

All this makes things worse and complicated to handle for both sides,
reporter and receiver of complaints.

So I think there is a little bit room for implementation and that was
exactly what I felt the community wanted, when I published the 1st
version of the proposal, which was very clear and tried to specify
everything. So the community wanted me to make it less specific and give
you more space.

Now in my opinion you have a lot of space to do an okay, a good or a
really good implementation. In my opinion the mentioned plan is a good
one, but there is space for improvement.

Thanks,

Tobias

-- 
abusix.org











-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20110118/219e6cdc/attachment.sig>