Hi Menno, Thank you for your comments.
The LIR maintaing an address block is responsible for taking care of the related abuse cases. I see no problem in some LIRs outsourcing this to a third party (which I guess is what you mean by "other organisations of Incident Response Teams"), but I don't see it to be more trustworthy if a third party is involved than if the LIR takes care of it. But I do see it as a problem if such third party needs to be verified and such procedure makes this matter so complicated that almost no LIRs bother using it (as the case is today).
In the current implementation the IRT and the LIR (maintainer) are supposes to be different groups of persons, whether they are part of the same organisation of not.
This is where I disagree with the idea behind the irt implementation, I do not see the reason for making the distinction between LIR and IRT as it do not apply to all LIRs. In many LIRs abuse is handled by the same group (and sometimes even the same persons) as the ones handling general LIR functions.
for its IP range, but the IRT has to authorise this, by counter-signing the request to add an mnt-irt attribute to the inet[6]num object. Otherwise any maintainer of an inet[6]num (which could be delegated) could simply make the inet[6]num object point to any IRT for abuse complaints. The current mechanism is to protect the IRT form being blamed for things they are not responsible for simply because "Evil Company" points a finger towards them.
I very much agree with you that a LIR shall not be able to "forward the problem" by using another organsations irt object without permission. But the question is how many LIRs choose to "outsource" abuse, even to a group within the organization? I could have hoped this had been determined before implementing the IRT object. I understand that it is necessary for LIRs who prefer to use a seperate group within the organization or a third party to use encryption for authentication, but can we agree that for the rest of the LIRs it could just as easily be done by maintainer authentication like when creating route objects? If so what would the disadvantage be? Im not opposed that some LIRs can effectively outsource abuse even if it requires special objects/attributes in the Ripe database, but Im very much opposed that these special objects/attributes are mandatory meaning it becomes an obstacle for LIRs prefering to keep abuse within the organization.
The current problem is that the majority of LIRs have chosen not to use irt, probably both because it haven't been announced enough and because it is too complicated. As soon as an attribute is implemented in most inetnum objects, meaning people have a reason to trust that an abuse address actually works, then people will stop using any other address, simply because the abuse address will work and the others will not.
That is exactly why there must be double authorization for the relationship between IRT and inet[6]num: to ensure correctness and mutual agreement.
Only in cases where LIRs choose to outsource abuse, if it is within the same organzation, one LIR cannot (hopefully) hijack another LIRs maintainer, meaning an abuse object created and used by one LIR cannot be used by another.
I agree that there must be a better mechanism than the comments in the inet[6]num and maintainer objects, but I'm still in favor of promoting the existing one and perhaps explaining it a little better.
The reason why a better explanation is needed for the current IRT object is because it has extensive authentication, if many LIRs have no use for these extra features, can you find any reason for them to spent time finding out how to use/create this object? Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net