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 ]