[db-wg] abuse-c

> > And for having a usable, maintainable automated system, it is easier to
> > take what is there (IRT is not really hard to figure out - it _is_
> > basically like a maintainer), and write the apprpriate tools for that;
> > since you would have to write tools anyway.
> >
> > I hope that makes sense.
>
> It makes sense, but I have the feeling that the irt carries to much
> information or is to difficult for the average database user to use.

I would very much like a solution to this problem so if more LIRs would be
willing to accept modifying the current irt object I could support some kind
of compromise. The current irt object template:

irt:        [mandatory] [single]   [primary/lookup key]
remarks:    [optional]  [multiple] [ ]
address:    [mandatory] [multiple] [ ]
phone:      [optional]  [multiple] [ ]
fax-no:     [optional]  [multiple] [ ]
e-mail:     [mandatory] [multiple] [lookup key]
signature:  [mandatory] [multiple] [ ]
encryption: [mandatory] [multiple] [ ]
admin-c:    [mandatory] [multiple] [inverse key]
tech-c:     [mandatory] [multiple] [inverse key]
auth:       [mandatory] [multiple] [ ]
irt-nfy:    [optional]  [multiple] [inverse key]
notify:     [optional]  [multiple] [inverse key]
mnt-by:     [mandatory] [multiple] [inverse key]
changed:    [mandatory] [multiple] [ ]
source:     [mandatory] [single]   [ ]


The following is a modified version:

abuse       [mandatory] [single]   [primary/lookup key]
remarks:    [optional]  [multiple] [ ]
address:    [mandatory] [multiple] [ ]
phone:      [optional]  [multiple] [ ]
fax-no:     [optional]  [multiple] [ ]
e-mail:     [mandatory] [multiple] [lookup key]
signature:  [optional] [multiple] [ ]
encryption: [optional] [multiple] [ ]
notify:     [optional]  [multiple] [inverse key]
mnt-by:     [mandatory] [multiple] [inverse key]
changed:    [mandatory] [multiple] [ ]
source:     [mandatory] [single]   [ ]


The name: abuse is a much more common word, I don't really see the point in
using a word that most normal user doesn't understand and maybe even some
LIRs.

I don't think physical address is strictly necessary since people only look
for an email address, on the other hand its no bother to insert it.. (btw.
shouldn't country be included as mandatory if address is included?)

Signature and Encryption has to be optional, I only see a point with these
attributes in case abuse is handled by a different department. Im sure other
LIRs exists who doesn't need this.

admin-c and tech-c, email is mandatory on role object = a mail address
totally irrelevant to abuse/irt will show up if these attributes are
included meaning people will send to these as well = back to square one. It
doesn't help making them optional as I see it..?

I don't see the reason for auth? If its absolutely necessary it can be
optional.


As it is now it should still be referenced from inetnum objects. The
disadvantage is that all LIRs have to modify each and everyone of their
inetnum objects, and this object will not have much value until all inetnums
have been updated.. This is where the idea of having it in the maintainer
object has its advantage.


>
> That's why I proposed the alternative of creating more awarness of the irt
> object, what it does and how to use it, especially from the perspective of
> the bulk of the database users who just want some basic information on
> where to complain about a certain ip address.
>
> I don't know how others handle this, but the company I work for has some
> seperation between 'security' and 'abuse'. The irt object will probably
> point to our security department who handle the more serious incidents or
> things which need a fast response. Our abuse dept only works during office
> hours but takes care of all spammers, virusses and other stuff as from
> experience most of the spam is done batchwise mostly the damage is already
> done and the only thing the abuse dept does is taking care it won't happen
> again by disconneting the user and make sure they fix their security
> holes.
>
> The irt object doesn't allow for this seperation, you can create multiple
> objects and use remarks to explain where to send the complaint. This is
> the mechanism we already use on the inetnum and it doesn't work very well.

Im not sure its possible to solve this without getting into problems like
people using the wrong address anyway.



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