[db-wg] Re: abuse-c: proposal

Hi Marco,


> 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?

> 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.

>
> 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.

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
object it should have a normal mnt-by attribute and the following fields
either removed or made optional: address, signature, encryption, auth.

I can appriciate the need for the features of the IRT object, but WHY can't
the rest of us get a working solution to our problem? It doesn't necessarily
mean that we can't preserve the features of the IRT.



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