[db-wg] abuse-c: proposal
- Previous message (by thread): [db-wg] abuse-c: proposal
- Next message (by thread): [db-wg] abuse-c: proposal
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hank Nussbacher
hank at att.net.il
Thu Jan 29 12:52:24 CET 2004
At 12:42 PM 29-01-04 +0100, Niall O'Reilly wrote: Excellent. The sooner the better. -Hank >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] abuse-c: proposal
- Next message (by thread): [db-wg] abuse-c: proposal
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]