Re: 2010-08 New Policy Proposal (Abuse contact information)
Sorry for not replying in-thread, I don't have the correct email in this account. I whole-heartedly agree with 2010-08, though I still think abuse-c would have been a better name. While the person object of an abuse-c is not 100% appropriate for a group, itr expands to incident response team. What is an incident that needs to be reported to the itr? Spam, yes. Cracking, yes. DoS, yes. But what de-announcing a prefix? That would need to go to the NOC. admin-c would perfectly describe this distinction. All that being said, what's done's done. To get to the part where I stop babbling and give (hopefully) useful feedback: I really like the proposal, but I think the English could be improved. As it is, it reads a bit strained and is not 100% correct, imo. As it is, the text can be interpreted to require an update of irt on all updates of referencing objects which is obviously not Tobias' intention. Anyway, here goes: ---8<--- 1. Compulsory IRT Object A reference to an irt object is mandatory for the following RIPE database objects: inetnum, inet6num, and aut-num. All newly created and updated objects of these types must reference an irt object. The "abuse-mailbox" attribute is mandatory for all irt objects. Addition of an "abuse-mailbox" attribute in a non-irt object will be rejected. All "abuse-mailbox" attributes in non-irt objects will be deleted by the end of 2012. ---8<--- As an aside, what happens when I update a non-irt object which has a legacy abuse-mailbox attribute without touching it? Will this be rejected or allowed? 2010-08 does not answer this question. which should be fixed, imo. Thanks, especially to Tobias, Richard
Thank you for your feedback.
I whole-heartedly agree with 2010-08, though I still think abuse-c would have been a better name. While the person object of an abuse-c is not 100% appropriate for a group, itr expands to incident response team.
We had the the idea of an abuse-c as well, but we decided to stay with the IRT object and not create another object again. This makes the implementation process easier for RIPE NCC. If you create a abuse-c and link any object to it, you can have different persons in one whois with different abuse-mailbox attributes. And the other intention was, in our opinion, the abuse contact should be related to the inet(6)num and aut-nums. And the IRT Objects shows this relation better than an abuse-c that is linked to a person, org or role account.
To get to the part where I stop babbling and give (hopefully) useful feedback: I really like the proposal, but I think the English could be improved. As it is, it reads a bit strained and is not 100% correct, imo. As it is, the text can be interpreted to require an update of irt on all updates of referencing objects which is obviously not Tobias' intention.
Hmmm but this might be a good idea and could improve data accuracy. But there will be another proposal in the next days facing this. ;-)
---8<---
1. Compulsory IRT Object
A reference to an irt object is mandatory for the following RIPE database objects: inetnum, inet6num, and aut-num. All newly created and updated objects of these types must reference an irt object.
The "abuse-mailbox" attribute is mandatory for all irt objects.
Addition of an "abuse-mailbox" attribute in a non-irt object will be rejected.
All "abuse-mailbox" attributes in non-irt objects will be deleted by the end of 2012.
---8<---
Sounds good for me.
As an aside, what happens when I update a non-irt object which has a legacy abuse-mailbox attribute without touching it? Will this be rejected or allowed? 2010-08 does not answer this question. which should be fixed, imo.
That is a good point. I would not touch it. Leave it. It will be deleted at latest in 2012 and it makes no sense to reject working abuse contacts. But you are right. This should be mentioned. Thanks for your feedback Tobias
On Monday 08 November 2010 22:35:38 Tobias Knecht wrote: Tobias, as a person who does not know very much about the internal workings of the RIPE-DB and all the policies involved, I find your proposal a very good step towards a correct direction. We should at least agree, I believe, that all IP operators should provide an abuse contact for the address ranges they are "responsible" for. And this has to happen in a clear, consistent way. I can't imagine any reasons of why this would create any problems we cannot overcome for the "greater good". Of course, I am all ears for any arguments against :) Nice to see some work affecting policies coming out of the anti-abuse WG. Regards, Kostas Zorbadelos
participants (3)
-
Kostas Zorbadelos -
Richard Hartmann -
Tobias Knecht