This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
[db-wg] Re: abuse-c
- Previous message (by thread): [db-wg] Re: abuse-c
- Next message (by thread): [db-wg] abuse-c
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
MarcoH
marcoh at marcoh.net
Tue Jan 13 12:02:36 CET 2004
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
- Previous message (by thread): [db-wg] Re: abuse-c
- Next message (by thread): [db-wg] abuse-c
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]