On 2003-11-05 15:54:32 -0500, der Mouse wrote:
[...] "inetnum" objects with no valid email address cause grief. [...]
I would therefore like to suggest making the "e-mail" attribute mandatory for the "person" object. If this isn't acceptable, then maybe at least one of the "person" or "role" objects referred to by an "inetnum" object should carry an "e-mail" attribute.
For person objects, I see no particular reason to have email addresses. (While I see little use for a person object without one, I don't know what uses about which I know nothing person objects may be put to.)
But I strongly believe that every inetnum _needs_ an email address, one which reaches a human with authority to deal with abuse issues relating to that netblock.
Please be aware that there is an object that is available for documenting Computer Security Incident Response Team (CSIRT). This is the irt object, described in ripe-254: http://www.ripe.net/ripe/docs/irt-object.html These are specifically designed for handling abuse issues. It is possible to make these mandatory in inetnum objects, but that would have to be part of an effort taken in cooperation with the address policy working group. It is not currently a requirement to have a way to deal with abuse issues to be allocated or assigned IP space in the RIPE NCC service region.
Unfortunately, this is unlikely to happen. RIPE's own blocks fail the test; in the few cases where I've had to escalate all the way to them, (usually because a directly-allocated block has contact email addresses that bounce), RIPE has flatly refused to do any of
- Take the abuse report and see to it that the abuse stops - Ensure that the netblock's contact address(es) is(are) corrected - Deallocate the address space
The RIPE DBM mailbox does receive abuse complaints, and we direct the inviduals to the appropriate contacts as best that we are able. But AFAIK, there has not been a consensus in the RIPE community for the RIPE NCC to take any of the actions specified above. This is a reasonable forum for this discussion, although other RIPE working groups may also be useful. I thank you for raising the issue, and look forward to watching the thread progress. -- Shane Kerr RIPE NCC