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] [anti-abuse-wg] abuse-c + org / inetnum
- Previous message (by thread): [db-wg] [anti-abuse-wg] abuse-c + org / inetnum
- Next message (by thread): [db-wg] [anti-abuse-wg] abuse-c + org / inetnum
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Elvis Velea
elvis at velea.eu
Thu Oct 10 18:08:48 CEST 2013
Hi, On 10/10/13 5:50 PM, Sebastian Wiesinger wrote: > * Gert Doering <gert at space.net> [2013-10-08 13:33]: >> Hi, >> >> On Mon, Oct 07, 2013 at 11:00:28PM +0200, Gilles Massen wrote: >>> Something else in mind: as before: allow abuse-c for inet*num. Prefer >> >> This. >> >> (But I've said this before :-) - I do not see it as a useful excercise >> having to create an organization: object for the sole purpose of being >> able to have a different abuse-c: for some inet(6)num object) > > ++++++1 I think that having the abuse-c role linked to the org object was a great idea. I also understand that some organisation may want to have different abuse contacts/roles defined for different IP blocks. One way on how this could be fixed, in my opinion, is by allowing an abuse-c role to be referenced in the inet*num object (but only if the inet*num object references an org that already has an abuse-c role referenced). In this case, the general abuse-c would be the one referenced in the org and the 'local' abuse-c would be the role referenced in the inet*num object. cheers, elvis
- Previous message (by thread): [db-wg] [anti-abuse-wg] abuse-c + org / inetnum
- Next message (by thread): [db-wg] [anti-abuse-wg] abuse-c + org / inetnum
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]