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/db-wg@ripe.net/
[db-wg] abuse-c: proposal
- Previous message (by thread): [db-wg] [announce] releasing a tool to help LIR visualizing IPv4 LIR-as signments vs RIPE-allocations
- Next message (by thread): [db-wg] abuse-c: proposal
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Niall O'Reilly
niall.oreilly at ucd.ie
Thu Jan 29 12:42:04 CET 2004
Co-authors: Randy Bush, Niall O'Reilly
Proposal for Adding Abuse Contact to inet*num: Objects in RIPE Database
Requirement:
Net users who perceive abuse from some net source wish to contact some
service which has officially agreed to deal with the abuse. Currently,
they seem to scan the inet*num: objects and send mail
to any or all contacts
in that object, including strange things such as the email address in
the changed: attribute.
This need seems to be clearly applicable to the inetnum: and inet6num:
objects, so those objects are addressed by this proposal. Should there
be similar needs in other object types, it is anticipated that the
abuse-c: attribute would be added
to those objects as appropriate.
Two things are needed:
o The inetnum: and inet6num: objects are enhanced with an optional
attribute "abuse-c:". The value of the attribute is a nic-handle:
which must refer to an extant person: or role: object. There may be
zero or more abuse-c: attributes in an inet*num: object.
The value of the abuse-c: attribute MAY be extended by appending a hint
string. This is expected to be useful to organizations who wish to
advertise more than one abuse contact, and to give guidance as to which
of these is the appropriate notification target in particular
circumstances.
In case a hint string is specified, it MUST be discarded when forming
inverse keys.
Therefore, the syntax of the inetnum: object would become
inetnum: [mandatory] [single] [primary/lookup key]
netname: [mandatory] [single] [lookup key]
descr: [mandatory] [multiple] [ ]
country: [mandatory] [multiple] [ ]
admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]
abuse-c: [optional] [multiple] [inverse key]
rev-srv: [optional] [multiple] [inverse key]
status: [mandatory] [single] [ ]
remarks: [optional] [multiple] [ ]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
mnt-lower: [optional] [multiple] [inverse key]
mnt-routes: [optional] [multiple] [inverse key]
mnt-irt: [optional] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
o Document and Publish that the abuse-c: contact is the one and only
contact that should be used to report spam and other forms of
abuse. This documentation should be made prominently available so
that manual seekers and creators of automated reporting tools will
all clearly know that the abuse-c: is the one and only place at
which abuse should be reported, and that other contacts in the
objects should not be abused.
The documentation should make it clear that automated reporting
tools MAY always ignore the hint string, but SHOULD search the
advertised abuse-c: attributes to find a hint string that matches
the circumstances of the abuse to be reported.
The hint string specified SHOULD be taken from a limited vocabulary.
This vocabulary SHOULD be reviewed from time to time. It contains
initially the following terms, treated as case-insensitive, and
with the indicated semantics:
'' Always notify this contact
'Spam' Notify this contact for spam abuse ONLY
'Security' Notify this contact for DDoS and intrusion abuse ONLY
-- End --
- Previous message (by thread): [db-wg] [announce] releasing a tool to help LIR visualizing IPv4 LIR-as signments vs RIPE-allocations
- Next message (by thread): [db-wg] abuse-c: proposal
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]