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]/
[anti-abuse-wg] [db-wg] Options for extending "abuse-c:"
- Previous message (by thread): [anti-abuse-wg] Options for extending "abuse-c:"
- Next message (by thread): [anti-abuse-wg] [db-wg] Options for extending "abuse-c:"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Aleksi Suhonen
ripe-ml-2012 at ssd.axu.tm
Wed May 7 03:27:25 CEST 2014
Hello, On 05/06/2014 06:01 PM, Denis Walker wrote: > Two issues have been identified that are seen to be difficult to handle > with the current model - partitioned subnets within one organisation and > adding abuse contacts to more specifics for End Users. The RIPE NCC has > considered these two issues and found what we believe to be practical > solutions, available within the current model. > More information about these solutions and the implementation of > "abuse-c:" is available on RIPE Labs: > https://labs.ripe.net/Members/denis/suggestions-for-improving-abuse-handling I find this suggestion clumsy. It adds hard to parse extraneous information to simple objects. The organization object for a very large organization would become unmanageable and unintelligible quickly. I would much rather like to see a new inetnum and inet6num object status "INFORMATIONAL" that only requires authorization of the immediately larger enclosing inet(6)num object, and doesn't represent an assignment or allocation at all. Such objects can then be used to redirect technical, administrative and abuse contacts to the proper places, as well as present their own remarks and descriptions. This solution would cover PI, PA and all other styles of address blocks equally well. I know this has been suggested many times before, but I still think it would be a much more elegant solution to this problem. Yours, -- Aleksi Suhonen
- Previous message (by thread): [anti-abuse-wg] Options for extending "abuse-c:"
- Next message (by thread): [anti-abuse-wg] [db-wg] Options for extending "abuse-c:"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]