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] Re: abuse-c: proposal
- Previous message (by thread): [db-wg] Re: abuse-c: proposal
- Next message (by thread): [db-wg] Re: abuse-c: proposal
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Marco d'Itri
md at Linux.IT
Mon Feb 9 15:25:12 CET 2004
On Feb 09, Christian Rasmussen <chr at jay.net> wrote: >> I looked at the inetnum object CISBRD-CUST-ADSL-113, one of these >> created by you for your broadband customers: it contains in the remarks >> attributes a well visible notice about where complaints should be sent, >> yet you say that you still get them at your personal email address. >> Do you really think that users would understand better if they read >> "abuse-mailbox: user at example.com" instead of that sentence in english >> which explains what the allocation is for and who should be notified of >> abuse? >Of course not. But how many inetnum objects have these remarks? How is this relevant to what we are discussing? >> I do not pretend to be an expert in user interfaces, but I think that, >> for a random user, natural language should be easier to understand than >> something like "abuse-mailbox". >Agreed. But the primary concern is the applications used to find an abuse >address for a specific IP address, they have a hard time finding anything in >a freetext format... We have to make sure these applications find the >correct mail address, if they don't, we haven't solved anything. This is true, I agree that this must be a goal, but abuse-mailbox is not the only way to reach it. Maybe RIPE could provide a web page to query the DB for abuse desk addresses (which would report no other data), or maybe the port 43 server could be modified to always check for IRT objects for inetnum/inetnum6 queries and report the address in a comment at the top of the reply with big eye-catching ASCII art. So far only one tool writer contributed to this thread, and he reported that both abuse-mailbox and irt could be used by his tools. >> I think that there is a consensus that there is the need for a method to >> look up the abuse desk address for an IP address, and I believe that irt >> objects (which have the big advantage of existing) are fit to this. >> >> Creating irt objects is not any harder than creating a new maintainer, >> maybe the documentation should focus more on this and less on marketing >> the TI concept (which apparently only NRENs care about). > >First problem with IRT is that in order for it to have any value every LIR >has to actively modify ALL their inetnum objects......... Now that must mean >that the intention has never been to make sure all LIRs implement it. No, you are getting it backward: this is the problem with abuse-mailbox or abuse-c. With IRT you only need to tag the top level allocation object and the attribute will be inherited by all end users assignments, while with abuse-* you need to add the attribute to every inetnum/inetnum6 object. This is a fundamental propriety of the IRT object and the main reason for which I consider it superior to the other proposals. >Next problem is the idea behind IRT, apparently it is to be used by >companies who outsource handling of abuse - we don't. If I should use this It may support outsourcing, but I can't see why this would be a problem. I set up an IRT object for an ISP with an internal abuse desk and found it appropriate for my needs. Can you be more clear? >object it should have a normal mnt-by attribute and the following fields >either removed or made optional: address, signature, encryption, auth. I would not strongly oppose to this, but I can't see how it would make easier to deploy IRT objects. It's not like you do not already have an address or a PGP key... -- ciao, | Marco | [4511 dinMaQK0OHrNc]
- Previous message (by thread): [db-wg] Re: abuse-c: proposal
- Next message (by thread): [db-wg] Re: abuse-c: proposal
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]