Creating irt objects is not any harder than creating a new maintainer, maybe the documentation should focus more on this and less on marketing the TI concept (which apparently only NRENs care about).
First problem with IRT is that in order for it to have any value every LIR has to actively modify ALL their inetnum objects......... Now that must mean that the intention has never been to make sure all LIRs implement it.
Sorry, but this just wrong. It is exactly one of the advantages (of course you might want to have a different point of view :-) that modifying 1 (or a very small number of) object(s) would be sufficient - as long as we are talking hierarchical (i.e. LIR) address space. Tagging the _allocation_ object of an LIR would cover _all_ the _assignment_ objects in that block. With the added benefit that you can still have a "more specific" or 1st-line pointer in an assignment object.
Next problem is the idea behind IRT, apparently it is to be used by companies who outsource handling of abuse - we don't.
Out-sourcing would be supported, but it is a secondary issue. The primary issue is that it allows maintaining the data by the group being responsible for a certain function. There are real life situations where the role/group/team keeping track of address assignments is _different_ from the role/group/team being responsible for abuse or incident handling. If I should use this
object it should have a normal mnt-by attribute and the following fields either removed or made optional: address, signature, encryption, auth.
I can appriciate the need for the features of the IRT object, but WHY can't the rest of us get a working solution to our problem?
"You" (actually we ;-) can certainly get a solution, as soon as there is rough consensus in the WG that the approach proposed is _probably_ going to work and has a reasonable "price tag" (i.e. the implementation effort).
It doesn't necessarily mean that we can't preserve the features of the IRT.
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
-------------------------------------------------------------------------------- Wilfried.
Hi Wilfried,
First problem with IRT is that in order for it to have any value every LIR has to actively modify ALL their inetnum objects......... Now that must mean that the intention has never been to make sure all LIRs implement it.
Sorry, but this just wrong.
Not according to the Ripe documents, I've also seen an example on how to do a script to update all customer inetnum objects. But as I can see you're the author of one of these documents you must be correct!.. :)
It is exactly one of the advantages (of course you might want to have a different point of view :-) that modifying 1 (or a very small number of) object(s) would be sufficient - as long as we are talking hierarchical (i.e. LIR) address space.
Tagging the _allocation_ object of an LIR would cover _all_ the _assignment_ objects in that block. With the added benefit that you can still have a "more specific" or 1st-line pointer in an assignment object.
I wasn't aware of this, is it explained in ripe-254? But it does sound much better than modifying all customer objects. Still my suggestion with maintainer is easier, but I will acknowledge that its a good idea to use a hierachy in such a solution.
Next problem is the idea behind IRT, apparently it is to be used by companies who outsource handling of abuse - we don't.
Out-sourcing would be supported, but it is a secondary issue. The primary issue is that it allows maintaining the data by the group being responsible for a certain function. There are real life situations where the role/group/team keeping track of address assignments is _different_ from the role/group/team being responsible for abuse or incident handling.
ripe-254, 1. Motivation .... In many cases such incidents are handled by CSIRTs whose contacts are different from those listed in "admin-c:" and "tech-c:" attributes. That is my problem, this object is designed for making it possible to outsource handling of abuse. Its not a problem that the object has this feature, its a problem that its mandatory! "many cases" in the text sounds like majority, how did you come to this conclusion? Can you acknowledge that by making these features mandatory you put unnecessary work on LIRs not outsourcing abuse handling? In reality this means several of these will probably decide not to take the time to create these objects (as we know very few has been created). I know this is just my point of view and that all those LIRs who needs to outsource (would it be possible to get some numbers?) think very differently. I really do not want to make it problematic to outsource, but I would just like the rest of us to also be taken into consideration. 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
On Feb 09, Christian Rasmussen <chr@jay.net> wrote:
Tagging the _allocation_ object of an LIR would cover _all_ the _assignment_ objects in that block. With the added benefit that you can still have a "more specific" or 1st-line pointer in an assignment object.
I wasn't aware of this, is it explained in ripe-254?
With a quick look I've found it explained at least in section 7: The new query functionality allows searching for an inetnum object that contains the reference to an irt object representing CSIRT responsible for a given address or address range. It is implemented with a new '-c' flag that modifies the behaviour of a normal ip lookup, so that the Database will return the smallest less specific inetnum (inet6num) object containing the reference to an irt object.
In many cases such incidents are handled by CSIRTs whose contacts are different from those listed in "admin-c:" and "tech-c:" attributes.
That is my problem, this object is designed for making it possible to outsource handling of abuse. Its not a problem that the object has this No, it's not. It's made for sites which are not Joe's ISP and Grill, where the abuse desk is a different team from the one which manages routing.
Can you acknowledge that by making these features mandatory you put unnecessary work on LIRs not outsourcing abuse handling? In reality this Not really.
means several of these will probably decide not to take the time to create these objects (as we know very few has been created). I think the fault was in bad documentation, not in complexity of deployment.
-- ciao, | Marco | [4527 l'3KkkSJYlL.M]
participants (3)
-
Christian Rasmussen -
Marco d'Itri -
Wilfried Woeber, UniVie/ACOnet