[db-wg] abuse-c: proposal

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