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] More-specific abuse-c
- Previous message (by thread): [db-wg] More-specific abuse-c
- Next message (by thread): [db-wg] More-specific abuse-c
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Sebastian Wiesinger
sebastian at karotte.org
Fri Nov 4 13:38:08 CET 2016
Hi David, thank you for the in-depth answer! * fransossen at yahoo.com <fransossen at yahoo.com> [2016-11-03 12:12]: > A) Being able to indicate the AS and prefixes covered by a specific > abuse email directly in the role object used as abuse-c: . > > Annoying to set up, not very intuitive at first, but less annoying > than having to create new org objects per network segments requiring > different role objects as abuse-c: each time. Covers the need of > LIRs with PA, AS number and PI resource holders in terms of > potential granularity. I personally would also find this annoying and quite a bit unintuitive. ;) I *DO* like the granularity but I don't think it outweighs having all of that pushed to a single object instead of having multiple abuse-c's that are probably managed by different maintainers (giving customers the opportunity to manage their own abuse-c object). Also I would image this would necessitate quite a bit of special parsing in the database software. > B) Allow abuse handler to be added directly on the > Inet(6)num/Aut-num entries in the DB. This is what I would prefer right now. It is low cost to implement, it is easy to parse (use abuse-c: if available, else go to the organisation abuse-c). > I am not quite having any other ideas on how to proceed that would > fit within the current RIPE DB rules...route objects pop to mind, > but would also have their quirks. I would prefer to have option B) right now. *If* we need more granularity it would probably need to be a full fledged (meaning: more complicated) solution. I imagine a new object-type that can be a CIDR less-or-equal your allocation/assignment that references a abuse contact (which would bring in all sort of questions regarding authorization etc.) or an inet(6)num: with special type ABUSE-CONTACT (or something else). I think that this is a special case that probably not many people have use for. Right now having abuse-c at inet(6)nums would ease the pain for quite a few people. Best Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 581 bytes Desc: Digital signature URL: </ripe/mail/archives/db-wg/attachments/20161104/5bd38535/attachment.sig>
- Previous message (by thread): [db-wg] More-specific abuse-c
- Next message (by thread): [db-wg] More-specific abuse-c
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]