John Green wrote:
Menno Pieters (Stelvio) wrote:
The object itself is not so complicated. The mechanism to create it is,
and that has a purpose (see above).
I can't see anything "above" which explains why the creation purpose should be complicated.
Well, "above" I wrote:
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. The LIR cannot simply make the IRT responsible 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.
To elaborate on that, the complications for creating an IRT object are: - You need a maintainer for an IRT object (which is not required for an extra attribute or a person/role object); - Strong authentication from both the IRT and the LIR is required to link an IRT object to the inet[6]num object. The reasons to do it this way is to prevent that the IRT mentioned in the IRT object gets complaints about abuse made form IP ranges that they are not responsible for, simply because "Evil Company" put the e-mail address of the IRT in its inet[6]num object (or as Daniel Karrenberg suggested in on of the maintainer objects protecting the object). So both the IRT and the LIR (even if they are in the same room or just next door), must agree. In a small organisation it is possible that it's the same (group of) person(s), using the same PGP key and the problem is void, because the request needs to be signed only once. Regards, Menno Pieters -- Menno Pieters - Stelvio Postbus 215, 3740 AE Baarn phone: +31-35-5.429.324 / fax: +31-35-5.429.327 XOIP: +31-84-8.720.349 / Web: http://www.stelvio.nl/