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/[email protected]/
[db-wg] abuse-c
- Previous message (by thread): [db-wg] abuse-c
- Next message (by thread): [db-wg] abuse-c
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Christian Rasmussen
chr at jay.net
Wed Jan 14 10:27:04 CET 2004
Hi, > On Tue, Jan 13, 2004 at 05:11:18PM +0100, Sebastian Abt wrote: > > > Im not sure why it should be multiple? But I think most of us on this > > > list can agree with you that a valid abuse email address associated > > > with each inetnum in the database would be very welcome. > > > > That's quite simple: I'd like to insert my customers abuse desk as well > > as my own abuse desk to at least keep track of any incidents. Actually I kind of have the same need!.. :) But my idea would be to insert our abuse address in the maintainer so it defaults to this one, and then insert customer (more specific) abuse address in the inetnum.. The only reason I can see for inserting multiple abuse addresses in the inetnum object would be if you, beside a customer abuse address, need to override the address in the maintainer... If some LIRs have this need then we of course need to make the abuse attribute in the inetnum multiple. > > So we end up with extending the inet(6)num template to include: > > abuse: [optional] [multiple] > > Extend mntner template with: > > abuse: [mandatory] [multiple] hm.. again, why multiple in the maintainer? > > And possibly modify the database software to always list the abuse: field > when not present on the inetnum resolve the mnt-by: and include the > information in the inetnum response. > > The user will always find at least one abuse: line (or whatever we decide > to call it) directly on the inet(6)num. > > The only thing we need then is to come up with a default on the mandatory > field. I hereby suggest to copy them from the (mandatory) upd-to > attributes. This will probably get people to update their mntner to > include the correct information in short time. Yes, upd-to might be a good idea to copy, still it would be a good idea if Ripe NCC performs periodically checks and informs the LIRs who haven't updated their maintainer until a certain percentage has been reached. Aside from my comments above I fully support this. Do we now have something which a larger group could support?? Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc at jay.net Personal email: chr at corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net
- Previous message (by thread): [db-wg] abuse-c
- Next message (by thread): [db-wg] abuse-c
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]