So, we already have the irt object and the trouble attribute. Additionally, abuse is often reported based on admin-c, tech-c, changed, remarks and $DEITY knows what. Please let's not add to the confusion by creating even more attribute or object types. As for the irt object requiring a maintainer, that requirement exists for security, the need for which should be obvious in the context of abuse reports as well. The obvious hardliner approach would be to require future inetnum updates to carry valid mnt-irt attributes. Thor -- http://thorweb.anta.net/
On Mon, Jan 12, 2004 at 06:59:15PM +0200, Thor Kottelin wrote:
So, we already have the irt object and the trouble attribute. Additionally, abuse is often reported based on admin-c, tech-c, changed, remarks and $DEITY knows what. Please let's not add to the confusion by creating even more attribute or object types.
As for the irt object requiring a maintainer, that requirement exists for security, the need for which should be obvious in the context of abuse reports as well.
The obvious hardliner approach would be to require future inetnum updates to carry valid mnt-irt attributes.
So we make the presence of an irt-object and for a mnt-irt attribute mandatory and in the meantime start working on a "how to write a tool to get abuse addresses" manual... Like Daniel already suggested, creating or changing an atrribute to mandatory means a lot of work from the NCC and all registries. Adding an optional attribute to the inetnum, inet6num and mntner objects, maybe making it mandatory for any new and/or updated mntner object, is probably much easier to implement and we don't need to resort to "mnt-irt: NO-IRT" on all objects who are not maintained and where the contact hasn't responded as this is the only way we will get the mandatory field on all objects. This is not because I don't like the irtobject, the thing I hate is that the amount of abuse complaints I get to my personal email-address is slowly approaching the volume of spam I get at the same mailbox. And everytime I get such a report I need to forward it to our abusedesk which migth already got it directly and/or from a bunch of collegaeus who also recieved a personal copy of the complaint. Not forwarding results in not taking complaints seriously, forwarding them means extra load to our absue dept, longer response times and thus more people trying other ways to send abuse complaints. I'm waiting for the first user to pick a phonenumber from my person object and calling me up in the middle of the night to complain about some spam with a spoofed header which didn't even passed our infrastructure. So if somebody can come up with a decent way to get all the registries to create an irt-object and an easy way to tell the public to use it when looking for an abuse contact, I'm happy to support that proposal. In the meantime, I think that Daniel had a nicely formulated proposal. Grtx, MarcoH
Hi Marco,
So we make the presence of an irt-object and for a mnt-irt attribute mandatory and in the meantime start working on a "how to write a tool to get abuse addresses" manual...
Like Daniel already suggested, creating or changing an atrribute to mandatory means a lot of work from the NCC and all registries. Adding an optional attribute to the inetnum, inet6num and mntner objects, maybe making it mandatory for any new and/or updated mntner object, is probably much easier to implement and we don't need to resort to "mnt-irt: NO-IRT" on all objects who are not maintained and where the contact hasn't responded as this is the only way we will get the mandatory field on all objects.
I think its very important to both make the abuse attribute mandatory on maintainer objects and initiate a project to add this attribute to all existing maintainer objects so we end up with an abuse address associated with ALL inetnum objects, if this isn't the goal, I don't really see the reason for trying to improve the current situation.
This is not because I don't like the irtobject, the thing I hate is that the amount of abuse complaints I get to my personal email-address is slowly approaching the volume of spam I get at the same mailbox. And everytime I get such a report I need to forward it to our abusedesk which migth already got it directly and/or from a bunch of collegaeus who also recieved a personal copy of the complaint.
Exactly, Im getting enormous amounts of spam/abuse complaints on my personal mail address, Im trying to move it to our abuse address, but its really hard since the whois data is simply scanned for any valid mail address... As I've said a couple of times I don't think this will change until a standard for abuse addresses is implemented into all inetnum objects. The problem I see with the irt object is that a very simple thing (email address associated with an IP address) is made way to complicated. I don't see any need for an individual object just for abuse/irt, instead of referencing this object, just put in the abuse address!! I do understand the irt concept has some interesting advanced features, but could somebody please explain how these benefit smaller LIRs who do not have special abuse teams/outsourced abuse? The priority has to be to get a system working which can tell the abuse address of a given IP address, then advanced (optional) features can be added later.
So if somebody can come up with a decent way to get all the registries to create an irt-object and an easy way to tell the public to use it when looking for an abuse contact, I'm happy to support that proposal.
In the meantime, I think that Daniel had a nicely formulated proposal.
Yes, I think the proposal which Daniel formulated combined with the above could solve the problem. I must admit however that it might be kind of a quick solution, and I understand the arguments about abuse-addresses doesn't belong in a maintainer object, but I still don't see this as a very big problem compared to the current situation. An interesting point was raised about the reasons for admin-c and tech-c, in case these attributes are changed, then perhaps the abuse concept had to be reconsidered as well. 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 Tue, Jan 13, 2004 at 10:29:45AM +0100, Christian Rasmussen wrote:
So we make the presence of an irt-object and for a mnt-irt attribute mandatory and in the meantime start working on a "how to write a tool to get abuse addresses" manual...
Like Daniel already suggested, creating or changing an atrribute to mandatory means a lot of work from the NCC and all registries. Adding an optional attribute to the inetnum, inet6num and mntner objects, maybe making it mandatory for any new and/or updated mntner object, is probably much easier to implement and we don't need to resort to "mnt-irt: NO-IRT" on all objects who are not maintained and where the contact hasn't responded as this is the only way we will get the mandatory field on all objects.
I think its very important to both make the abuse attribute mandatory on maintainer objects and initiate a project to add this attribute to all existing maintainer objects so we end up with an abuse address associated with ALL inetnum objects, if this isn't the goal, I don't really see the reason for trying to improve the current situation.
This can be put up as the proposal for abuse(-c) attribute. When we introduce something new it will probably be easier to make it mandatory oposed to changing existing attributes. If possible I would like it to be mandatory on all new or updated objects (modify syntax check on auto-dbm), so we don't end up with abuse: handles pointing to a default which would be the case when we decide to make it mandatory on all objects.
This is not because I don't like the irtobject, the thing I hate is that the amount of abuse complaints I get to my personal email-address is slowly approaching the volume of spam I get at the same mailbox. And everytime I get such a report I need to forward it to our abusedesk which migth already got it directly and/or from a bunch of collegaeus who also recieved a personal copy of the complaint.
Exactly, Im getting enormous amounts of spam/abuse complaints on my personal mail address, Im trying to move it to our abuse address, but its really hard since the whois data is simply scanned for any valid mail address... As I've said a couple of times I don't think this will change until a standard for abuse addresses is implemented into all inetnum objects.
The problem I see with the irt object is that a very simple thing (email address associated with an IP address) is made way to complicated. I don't see any need for an individual object just for abuse/irt, instead of referencing this object, just put in the abuse address!!
I do understand the irt concept has some interesting advanced features, but could somebody please explain how these benefit smaller LIRs who do not have special abuse teams/outsourced abuse? The priority has to be to get a system working which can tell the abuse address of a given IP address, then advanced (optional) features can be added later.
I'm not proposing to leave the irt scheme, as you said it's just to big/complicated for the information most people need. So everybody resorts to remarks to list the abuse address and this is not usable for automation as it is freeform.
So if somebody can come up with a decent way to get all the registries to create an irt-object and an easy way to tell the public to use it when looking for an abuse contact, I'm happy to support that proposal.
In the meantime, I think that Daniel had a nicely formulated proposal.
Yes, I think the proposal which Daniel formulated combined with the above could solve the problem. I must admit however that it might be kind of a quick solution, and I understand the arguments about abuse-addresses doesn't belong in a maintainer object, but I still don't see this as a very big problem compared to the current situation.
An interesting point was raised about the reasons for admin-c and tech-c, in case these attributes are changed, then perhaps the abuse concept had to be reconsidered as well.
Yep, but this is more of a legal issue as I understand it as some parties would like to know who is 'responsible' for an ip-address. I would say, the owner of the registry to which it is allocated. It would be nice to list this person as an admin-c, but I don't think our CEO would be happy if I put his details in the ripe-db or request our share holders to register themselves as they have the final 'ownership'. So please keep the discussion focussed on "is there a need to implement an extra way of listing abuse contacts directly on the inetnum". MarcoH
participants (3)
-
Christian Rasmussen -
MarcoH -
Thor Kottelin